{"id":944,"date":"2023-06-24T11:16:22","date_gmt":"2023-06-24T11:16:22","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=944"},"modified":"2023-06-24T11:16:22","modified_gmt":"2023-06-24T11:16:22","slug":"kustomize-tutorial","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=944","title":{"rendered":"Kubernetes Kustomize Tutorial (Comprehensive Guide)"},"content":{"rendered":"

In this Kustomize Tutorial, you will learn all the Kustomize concepts and deploy an application using Kustomize on a Kubernetes cluster.<\/p>\n

Kustomize Use Case<\/h2>\n

Before diving into Kustomize, let\u2019s understand the problem with deploying applications using Kubernetes manifests.<\/a><\/p>\n

Suppose you want to deploy applications to Kubernetes<\/a> and you have multiple environments i.e. dev, uat, prod<\/strong> etc. In each environment, you might have different configurations<\/strong> for the deployments.<\/p>\n

For example, in dev and uat you might not need rolling updates however in prod you might need it. Also, you might want different replicas in each environment, different CPU & memory resources, annotations, etc. Not only that, applications could use properties through Configmaps and Secrets that change for every environment.<\/p>\n

Hence, you need to customize the deployments to accommodate the requirements for the respective environment.<\/p>\n

The simple solution to this problem is to create three separate directories, one for each environment, and add all the Kubernetes manifest in respective folders.<\/p>\n

But it is not a scalable solution. Because when new applications get onboarded or new configuration files get added, it would be hard to manually manage all the YAML files in the folders. This could also lead to configuration drift<\/strong> issues.<\/p>\n

You could create scripts to replace configs in the YAML but it would not be a good approach when you have many services.<\/p>\n

All these issues could be resolved using Kustomize<\/strong>. Also, one feature that sets it apart from other configuration tools is its tight integration with kubectl, the command-line interface for managing Kubernetes clusters.<\/p>\n

In the following topics, we will look at the Kustomize concepts and its benefits in detail. We will also look at a practical example of Kustomize using an Nginx Deployment to show you how it simplifies Kubernetes deployments.<\/p>\n

What is Kustomize?<\/h2>\n

Kustomize<\/a> is an open-source configuration management<\/a> tool for Kubernetes.<\/p>\n

It allows you to define and manage Kubernetes objects<\/a> such as deployments<\/a>, Daemonsets<\/a>, services, configMaps, etc for multiple environments in a declarative manner without modifying the original YAML files. To put it simply, you have a single source of truth for YAMLs, and you patch required configurations on top of the base YAMLs as per the environment requirements.<\/p>\n

Here is what the official documentation says<\/p>\n

\n
kustomize lets you customize raw, template-free YAML files<\/strong><\/b> for multiple purposes, leaving the original YAML untouched and usable as is.<\/div>\n<\/div>\n

Kustomize has two key concepts, Base and Overlays<\/strong>. With Kustomize we can reuse the base files (common YAMLs) across all environments and overlay <\/strong>(patches) specifications for each of those environments.<\/p>\n

Overlaying is the process of creating a customized version of the manifest file (base manifest + overlay manifest = customized manifest<\/strong> file).<\/p>\n

All customization specifications are contained within a kustomization.yaml<\/strong> <\/code>file.<\/p>\n

\"\"
Click to view in HD<\/span><\/figcaption><\/figure>\n

Kustomize Features<\/h2>\n

The following are the key features of Kustomize<\/p>\n

    \n
  1. Acts as a configuration tool with declarative configuration same as Kubernetes YAMLs.<\/li>\n
  2. It can modify resources without altering the original files.<\/li>\n
  3. It can add common labels and annotations to all the resources.<\/li>\n
  4. It can Modify container images based on the environment it is being deployed in.<\/li>\n
  5. Kustomize also ships with secretGenerator<\/code> and configMapGenerator<\/code> that use environment files or key-value pairs to create secrets and configMaps.<\/li>\n<\/ol>\n

    All these concepts and features will make more sense in the section where I practically show you<\/strong> how to use Kustomize using an nginx deployment.<\/p>\n

    Install Kustomize<\/h2>\n
    \n
    Note:<\/strong><\/b> Before installing Kustomize, you must have a Kubernetes cluster up and running and kubectl installed in our local machine and connected to the cluster.<\/div>\n<\/div>\n

    Kustomize is an open-source tool and is available as a standalone binary or as a plugin for kubectl. The installation of Kustomize is very easy.<\/p>\n

    Kubectl Kustomize<\/h3>\n

    The kustomize module is built into kubectl. You can use customize directly via kubectl. You can verify it using the following command.<\/p>\n

    kubectl kustomize --help<\/code><\/pre>\n
    Standalone Kustomize<\/h3>\n
    The below-mentioned script automatically detects the OS and installs the Kustomize.<\/p>\n
    curl -s \"https:\/\/raw.githubusercontent.com\/kubernetes-sigs\/kustomize\/master\/hack\/install_kustomize.sh\"  | bash<\/code><\/pre>\n
    After installation, verify it by running the below command. It will show you the latest appropriate version of Kustomize. If it’s not showing the version then close your terminal and run the command by opening a fresh terminal.<\/p>\n
    kustomize version<\/code><\/pre>\n
    If you are still getting bash: kustomize: command not found error<\/code> then run the below command and check again. This will set the path.<\/p>\n
    sudo install -o root -g root -m 0755 kustomize \/usr\/local\/bin\/kustomize<\/code><\/pre>\n
    We can also install Kustomize using brew<\/code> and chocolatey<\/code> on MAC and Windows respectively.<\/p>\n
    For MAC users:<\/p>\n
    brew install kustomize<\/code><\/pre>\n
    For Windows users:<\/p>\n
    choco install kustomize<\/code><\/pre>\n
    Understanding Kustomize<\/h2>\n
    First, you need to understand the following Key Kustomize concepts.<\/p>\n
      \n
    1. kustomization.yaml<\/code>file<\/li>\n
    2. Base and Overlays<\/li>\n
    3. Transformers<\/li>\n
    4. Patches<\/li>\n<\/ol>\n
      Let’s take a look at each concept.<\/p>\n
      kustomization.yaml <\/code>file<\/h3>\n
      The kustomization.yaml<\/code> file is the main file used by the Kustomize tool.<\/p>\n
      When you execute Kustomize, it looks for the file named kustomization.yaml<\/code>. This file contains a list of all of the Kubernetes resources (YAML files) that should be managed by Kustomize. It also contains all the customizations that we want to apply to generate the customized manifest.<\/p>\n
      Here is an example kustomization.yaml<\/code> file. Don’t worry about all the configurations. we will learn about all the fields in the following sections.<\/p>\n
      \"example<\/figure>\n
      Base and Overlays<\/h3>\n
      The Base folder represents the config that going to be identical across all the environments. We put all the Kubernetes manifests in the Base. It has a default value that we can overwrite.<\/p>\n
      On the other side, the Overlays folder allows us to customize the behavior on a per-environment basis. We can create an Overlay for each one of the environments. We specify all the properties and parameters that we want to overwrite & change.<\/p>\n
      \"\"<\/figure>\n
      Basically, Kustomize uses patch directive to introduce environment-specific changes on existing Base standard k8s config files without disturbing them. We will look at patches in a bit.<\/p>\n
      Transformers<\/h3>\n
      As the name indicates, transformers are something that transforms one config into another. Using Transformers, we can transform our base Kubernetes YAML configs. Kustomize has several built-in transformers. Let’s see some common transformers:<\/p>\n
        \n
      1. commonLabel<\/code><\/strong> – It adds a label to all Kubernetes resources<\/li>\n
      2. namePrefix<\/code><\/strong> – It adds a common prefix to all resource
        names<\/li>\n
      3. nameSuffix<\/code><\/strong> – It adds a common suffix to all resource
        names<\/li>\n
      4. Namespace<\/code><\/strong> – It adds a common namespace to all resources<\/li>\n
      5. commonAnnotations<\/code><\/strong> – It adds an annotation to all resources<\/li>\n<\/ol>\n
        Let’s see an example. In the below image, we have used commonLabels<\/code> in kustomization.yaml <\/code>where label env: dev<\/code> gets added to the customized deployment.yaml.<\/code><\/p>\n
        \"Kustomize<\/figure>\n
        Image Transformer<\/h4>\n
        It allows us to modify an image that a specific deployment is going to use.<\/p>\n
        In the following example, the image transformer checks the nginx<\/code> image name as mentioned  deployment.yaml<\/code> and changes it to the new name which is ubuntu<\/code> in the kustomization.yaml<\/code> file. We can change the tags as well.<\/p>\n
        \"Kustomize<\/figure>\n
        Patches (Overlays)<\/h3>\n
        Patches or overlays provide another method to modify Kubernetes configs. It provides more specific sections to change in the configuration. There are 3 parameters we need to provide:<\/p>\n
          \n
        1. Operation Type:<\/code> add or remove or replace<\/li>\n
        2. Target:<\/code> Resource name which we want to modify<\/li>\n
        3. Value:<\/code> Value name that will either be added or replaced. For the remove operation type, there would not be any value.<\/li>\n<\/ol>\n
          There are two ways to define the patch:<\/p>\n
            \n
          1. JSON 6902 and<\/li>\n
          2. Stragetic Merge Patching.<\/li>\n<\/ol>\n
            JSON 6902 Patching<\/h4>\n
            In this way, there are two details that we have to provide, the target<\/strong> and the patch details<\/strong> i.e. operation, path, and the new value.<\/p>\n
            patches:\n  - target:\n      kind: Deployment\n      name: web-deployment\n    patch: |-\n      - op: replace\n        path: \/spec\/replicas\n        value: 5<\/code><\/pre>\n
            The following image shows the JSON patching workflow.<\/p>\n
            \"Kustomize
            Click to view in HD<\/span><\/figcaption><\/figure>\n
            Stragetic Merge Patching<\/h4>\n
            In this way, all the patch details are similar to a standard k8s config. It would be the original manifest file, we just add the fields that need to be modified.<\/p>\n
            Here is an example of inline Stragetic Merge Patching.<\/p>\n
            patches:\n  - patch: |-\n      apiVersion: apps\/v1\n      kind: Deployment\n      metadata:\n        name: web-deployment\n      spec:\n        replicas: 5<\/code><\/pre>\n
            \"Kustomize
            Click to view in HD<\/span><\/figcaption><\/figure>\n
            Patch From File<\/h4>\n
            For both types of patching, instead of inline configs, we can use the separate file method. Specify all the patch details in a YAML file and refer it to the kustomization.yaml<\/code> file under the patches directive.<\/p>\n
            For example, in kustomization.yaml<\/code> you need to mention the patch file as follows. You need to specify the relative path of the YAML file.<\/p>\n
            patches:\n- path: replicas.yaml<\/code><\/pre>\n
            And we can put the changes in replicas.yaml<\/code> as given below.<\/p>\n
            apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: web-deployment\nspec:\n  replicas: 5<\/code><\/pre>\n
            Now that we have a good understanding of all the underlying Kustomize concepts, let’s put our learnings into a hands-on implementation.<\/p>\n
            Deploy Application Using Kustomize<\/h2>\n
            Let\u2019s see how Kustomize works using a real-world deployment scenario involving different environments.<\/p>\n
            \n
            Note<\/strong><\/b>: For demonstration purposes, we have given a simple YAML files with only two environments. In actual project, the YAML could be more complex with different objects and more deployment environemnts.<\/div>\n<\/div>\n
            Let’s assume the following scenario.<\/p>\n
              \n
            1. Nginx web server needs to be deployed in the dev and prod<\/li>\n
            2. In dev, we need only a deployment with 2 replicas, a Nodeport service, and less memory and CPU resources.<\/li>\n
            3. In prod, we need a deployment with 4 replicas, different CPU and memory limits, a rolling update strategy, and a service without NodePort.<\/li>\n<\/ol>\n
              Let’s see how we can achieve this using Kustomize.<\/p>\n
              \n
              Github Repo:<\/strong><\/b> All the manifest used in this guide are hosted in the Kustomize Github Repo<\/a>.<\/div>\n<\/div>\n
              Here is the directory structure for using Kustomize.<\/p>\n
              \u251c\u2500\u2500 kustomize\n  \u251c\u2500\u2500 base\n    \u2502   \u251c\u2500\u2500 deployment.yaml\n    \u2502   \u251c\u2500\u2500 service.yaml\n    \u2502   \u251c\u2500\u2500 kustomization.yaml\n    \u2514 overlays\n        \u251c\u2500\u2500 dev\n        \u2502   \u251c\u2500\u2500 deployment-dev.yaml\n        |   \u251c\u2500\u2500 service-dev.yaml\n        \u2502   \u2514\u2500\u2500 kustomization.yaml\n        \u2514\u2500\u2500 prod\n            \u251c\u2500\u2500 deployment-prod.yaml\n            \u251c\u2500\u2500 service-prod.yaml\n            \u2514\u2500\u2500 kustomization.yaml<\/code><\/pre>\n
              You can either use the GitHub repo files as a reference or create the respective folders and files using the following commands:<\/p>\n
              mkdir -p kustomize\/base && \n    touch kustomize\/base\/deployment.yaml \\\n         kustomize\/base\/service.yaml \\\n         kustomize\/base\/kustomization.yaml && \n    mkdir -p kustomize\/overlays\/dev && \n    touch kustomize\/overlays\/dev\/deployment-dev.yaml \\\n         kustomize\/overlays\/dev\/service-dev.yaml \\\n         kustomize\/overlays\/dev\/kustomization.yaml && \n    mkdir -p kustomize\/overlays\/prod && \n    touch kustomize\/overlays\/prod\/deployment-prod.yaml \\\n         kustomize\/overlays\/prod\/service-prod.yaml \\\n         kustomize\/overlays\/prod\/kustomization.yaml<\/code><\/pre>\n
              Let’s start with the base folder.<\/p>\n
              Base Folder<\/h3>\n
              The base folder contains the deployment, service, and kustomization files. In this base folder, we add the deployment and service YAML with all the configs which could be common for all the environments.<\/p>\n
              base\/deployment.yaml<\/code><\/strong><\/p>\n
              apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: web-deployment\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: web\n  template:\n    metadata:\n      labels:\n        app: web\n    spec:\n      containers:\n      - name: nginx\n        image: nginx:1.14.2\n        ports:\n        - containerPort: 80<\/code><\/pre>\n
              base\/service.yaml<\/code><\/strong><\/p>\n
              apiVersion: v1\n  kind: Service\n  metadata:\n    name: web-service\n  spec:\n    selector:\n      app: web\n    ports:\n    - name: http\n      port: 80<\/code><\/pre>\n
              base\/kustomization.yaml<\/code><\/strong><\/p>\n
              In the below file, we’re referring deployment.yaml<\/code> and service.yaml <\/code>as resources.<\/p>\n
              apiVersion: kustomize.config.k8s.io\/v1beta1\nkind: Kustomization\n  \nresources:\n- deployment.yaml\n- service.yaml<\/code><\/pre>\n
              Dev Overlay Folder<\/h3>\n
              Let’s define Dev overlays files. We only want to change in deployment.yaml<\/code> so we will only define it.<\/p>\n
              deployment-dev.yaml<\/code><\/strong><\/p>\n
              In dev deployment, we only want to increase the replicas from 1 to 2. You can see we only define the changes, not other things. Kustomize will check the base deployment file and compare it and patch the changes accordingly. That’s the beauty of Kustomize.<\/p>\n
              apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: web-deployment\nspec:\n  replicas: 3 # Update the replica count to 3\n  template:\n    spec:\n      containers:\n      - name: nginx\n        resources:\n          limits:\n            cpu: \"200\" # Lower CPU limit to 200m (0.2 CPU cores)\n            memory: \"256Mi\" # Lower memory limit to 256 MiB\n          requests:\n            cpu: \"100\" # Lower CPU request to 100m (0.1 CPU cores)\n            memory: \"128Mi\"<\/code><\/pre>\n
              service-dev.yaml<\/code><\/strong><\/p>\n
              In dev, we need the service with a nodeport. So we will create an overlay with the type Nodeport.<\/p>\n
              apiVersion: v1\nkind: Service\nmetadata:\n  name: web-service\nspec:\n  type: NodePort<\/code><\/pre>\n
              kustomization.yaml<\/code><\/strong><\/p>\n
              We’re using Strategic Merge Patching using the separate file method as we discussed earlier in the blog. You can also notice we have defined resources here also, this is why Kustomize needs to know the path of base files.<\/p>\n
              Note that in older Kustomize versions, bases can be used in place of resources here.<\/p>\n
              apiVersion: kustomize.config.k8s.io\/v1beta1\nkind: Kustomization\n\nresources:\n- ..\/..\/base\n\npatches:\n- path: deployment-dev.yaml\n- path: service-dev.yaml<\/code><\/pre>\n
              Review & Apply Patches<\/h4>\n
              Let’s review the patches. We can use the below command to review the patches and check whether everything is correct or not.<\/p>\n
              kustomize build overlays\/dev<\/code><\/pre>\n
              It will render the below Kubernetes manifest as shown below.<\/p>\n
              \"\"<\/figure>\n
              As you can see the number of replicas in deployment increased to 2<\/strong>, and different CPU and memory resources and service type changed to NodePort. Now this is the desired configuration for the dev environment.<\/p>\n
              We can deploy the customized manifest using the following command.<\/p>\n
              kustomize build overlays\/dev | kubectl apply -f -<\/code><\/pre>\n
              You can also use the following kubectl command.<\/p>\n
              kubectl apply -k overlays\/dev<\/code><\/pre>\n
              Prod Overlay Folder<\/h3>\n
              deployment-prod.yaml<\/code><\/strong><\/p>\n
              In prod deployment, we’re adding the RollingUpdate strategy with 4 replicas of the deployment and different memory and CPU resources.<\/p>\n
              apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: web-deployment\nspec:\n  template:\n    replicas: 4 # Update the replica count to 3\n    spec:\n      containers:\n      - name: nginx\n        resources:\n          limits:\n            cpu: \"1\" # Lower CPU limit to 200m (0.2 CPU cores)\n            memory: \"1Gi\" # Lower memory limit to 256 MiB\n          requests:\n            cpu: \"500\" # Lower CPU request to 100m (0.1 CPU cores)\n            memory: \"512Mi\" # Lower memory request to 128 MiB\n  strategy:\n    type: RollingUpdate\n    rollingUpdate:\n      maxSurge: 1\n      maxUnavailable: 1<\/code><\/pre>\n
              service-prod.yaml<\/code><\/strong><\/p>\n
              We’re changing the service type to NodePort.<\/p>\n
              apiVersion: v1\nkind: Service\nmetadata:\n  name: web-service\nspec:\n  type: NodePort<\/code><\/pre>\n
              kustomization.yaml<\/code><\/strong><\/p>\n
              In the kustomization.yaml<\/code><\/strong> I have added the absolute path of both files for patching as we want to make some changes in prod.<\/p>\n
              apiVersion: kustomize.config.k8s.io\/v1beta1\nkind: Kustomization\n\nresources:\n- ..\/..\/base\n\npatches:\n- path: deployment-prod.yaml\n- path: service-prod.yaml<\/code><\/pre>\n
              Run the below command again for reviewing the configuration and patches.<\/p>\n
              kustomize build overlays\/prod<\/code><\/pre>\n
              Alternatively, you can use Kustomize with the kubectl command as follows.<\/p>\n
              kubectl kustomize overlays\/prod<\/code><\/pre>\n
              Review & Apply Patches<\/h4>\n
              If everything looks good we can deploy it now by running the below command.<\/p>\n
              kustomize build overlays\/prod | kubectl apply -f -<\/code><\/pre>\n
              Alternatively, you can use the kubectl command as follows.<\/p>\n
              kubectl apply -k overlays\/prod<\/code><\/pre>\n
              After deploying it, we can check the objects by running the below commands.<\/p>\n
              kubectl get deployments\nkubectl get services\nkubectl get pods<\/code><\/pre>\n
              Use the following command to view all the objects at once.<\/p>\n
              kubectl get all<\/code><\/pre>\n
              \"Object<\/figure>\n
              Kustomize Configmap and Secret Generators<\/h2>\n
              Kustomize has the functionality to generate Configmaps and Secrets.<\/p>\n
              In Kustomization YAML there are two supported fields<\/p>\n
                \n
              1. configMapGenerator and<\/li>\n
              2. secretGenerator<\/li>\n<\/ol>\n
                Check out the Kuztomize Configmap Generators<\/a> guide where the use case and workflow are explained practically.<\/p>\n
                Kustomize Troubleshooting – Common Issues<\/h2>\n
                  \n
                1. Kustomize version should be compatible with the Kubernetes cluster’s version as Kustomize might introduce features or changes that aren’t supported by older Kubernetes versions.<\/li>\n
                2. If you’re using overlays to apply customizations, check if you’ve properly specified the overlays in your kustomization.yaml<\/code> file. Each overlay must be listed under the resources<\/code> field with the correct path. Make sure you’re running kustomize build<\/code> or kustomize build <overlay-path><\/code> to generate the final configuration with the applied changes.<\/li>\n
                3. If you’re encountering an error message like \"kustomize: command not found\"<\/code> make sure that Kustomize is installed and available in your system’s PATH.<\/li>\n
                4. Kustomize uses YAML files for defining configurations and customizations. Ensure that your YAML files are properly formatted, indented correctly, and have valid syntax<\/li>\n<\/ol>\n
                  Benefits of Using Kustomize<\/h2>\n
                  Below are the benefits of Kustomize<\/p>\n
                    \n
                  1. Simplified Configuration Management:<\/strong> Kustomize is easy to use and allows you to manage and customize your Kubernetes configurations more easily by enabling you to define your configuration in a structured and modular way.<\/li>\n
                  2. Reusability:<\/strong> With Kustomize we can reuse one of the base files across all environments and overlay specifications for each of those environments. This can save you time and effort by allowing you to reuse common configurations rather than having to create them from scratch for each new deployment.<\/li>\n
                  3. Version Control:<\/strong> Kustomize allows you to version control your Kubernetes configurations, making it easier to track changes and roll back to previous configurations if necessary.<\/li>\n
                  4. Template Free:<\/strong> Kustomize is template free. It expresses the full power of Kubernetes API, with no need to parameterize every single line compared to Helm.<\/li>\n
                  5. Kustomize <\/strong>can be run natively from the Kubernetes command line interface.<\/li>\n
                  6. Kustomize has built-in transformers to modify resources and It can be extended via a plug-in mechanism.<\/li>\n
                  7. Kustomize does not have any templating language so we can use the usual YAML to state our configurations rapidly.<\/li>\n
                  8. Kustomize is provided as a standalone Golang package and cli tool so it’s easy to integrate with users’ tools and workflows.<\/li>\n
                  9. We can use Kustomize without installing it if we have kubectl 1.14+ version. kubectl allows us to make declarative changes to our configurations without touching a template.<\/li>\n<\/ol>\n
                    Kustomize Best Practices<\/h2>\n
                    Here are some Kustomize best practices:<\/p>\n
                      \n
                    1. Keeping base resources, overlays, and patches in separate directories helps us to maintain clarity and separation between different configurations.<\/li>\n
                    2. While working with Kustomize, it’s essential to adhere to general Kubernetes best practices<\/li>\n
                    3. Try to keep the common values like namespace, and common metadata in the base file.<\/li>\n
                    4. While developing or before pushing to git, run kubectl kustomize cfg fmt file_name<\/code>  command to format the file and set the indentation right.<\/li>\n
                    5. Before deploying your Kustomize configurations, validate them and perform thorough testing to ensure that your configurations work as expected.<\/li>\n
                    6. Integrate Kustomize into your CI\/CD (Continuous Integration\/Continuous Deployment) pipeline to automate the deployment process.<\/li>\n
                    7. Kustomize provides the ability to imperatively update kustomization.yaml<\/code> files using the edit subcommand. So use the edit command in adding labels, namespaces, etc, and modify images and replicas.<\/li>\n<\/ol>\n
                      Kustomize vs Helm<\/h2>\n
                      Below are some differences:<\/p>\n
                        \n
                      1. Helm provides more advanced features like hooks and release management, making it suitable for complex deployments. Kustomize is simpler and more straightforward.<\/li>\n
                      2. Helm has complex templating, while Kustomize has no templating.<\/li>\n
                      3. Kustomize doesn’t need a separate setup. On the other hand, we need to set up Helm.<\/li>\n
                      4. Helm has a large collection of pre-built charts that can be easily shared and reused, while Kustomize allows you to share configurations but lacks a centralized repository.<\/li>\n
                      5. Kustomize has an easy learning curve, while Helm has difficulty as it introduces additional concepts like charts and templates.<\/li>\n
                      6. Kustomize uses overlays and patches to modify existing configurations, while Helm uses charts to package and manage applications.<\/li>\n<\/ol>\n
                        Kustomize FAQs<\/h2>\n
                        Let\u2019s look at some of the frequently asked Kutomize questions.<\/p>\n
                        How is Kustomize different from Helm?<\/h4>\n
                        While both Kustomize and Helm are configuration management tools for Kubernetes, they have different approaches. Kustomize focuses on providing a native and declarative way to manage configurations without using templates. Helm, on the other hand, uses charts and templates to package and deploy applications.<\/p>\n
                        How do I install Kustomize?<\/h4>\n
                        Kustomize is distributed as a standalone binary and can be easily installed on various platforms.<\/p>\n
                        curl -s \"https:\/\/raw.githubusercontent.com\/kubernetes-sigs\/kustomize\/master\/hack\/install_kustomize.sh\"  | bash<\/code><\/pre>\n
                        You can download the binary from the official GitHub repository or use package managers like Homebrew (for macOS\/Linux) or Chocolatey (for Windows).<\/p>\n
                        brew install kustomize    \/\/mac\nchoco install kustomize   \/\/windows<\/code><\/pre>\n
                        Can Kustomize be used with existing Kubernetes configurations?<\/h4>\n
                        Kustomize can be used to manage existing Kubernetes configurations. You can start by creating a Kustomization file in the directory containing your existing YAML files and define overlays to customize the configuration as needed.<\/p>\n
                        Can Kustomize handle secret management?<\/h4>\n
                        Kustomize provides support for managing secrets. You can define secret generators in your Kustomization file, which can create secrets dynamically based on the specified rules. This allows you to separate sensitive information from your configuration files.<\/p>\n
                        Is Kustomize compatible with GitOps workflows?<\/h4>\n
                        Kustomize is compatible with GitOps workflows. You can version control your base configuration, overlays, and Kustomization files and use tools like Git and CI\/CD pipelines to manage and deploy your Kubernetes configurations.<\/p>\n
                        Is Kustomize officially supported by Kubernetes?<\/h4>\n
                        Kustomize is an official sub-project of Kubernetes and is maintained by the Kubernetes SIG-CLI (Special Interest Group – Command Line Interface) community. It has gained popularity and is widely used in the Kubernetes ecosystem.<\/p>\n
                        Conclusion<\/h2>\n
                        In this Kustomize Tutorial, we have discussed what problem Kustomize solves along with its benefits. Further, we have checked the installation part and some key concepts of Kustomize.<\/p>\n
                        We also learned how to deploy applications on Kubernetes using Kustomize. Then we talked about the Secret\/Config Map generator and compared it with Helm.<\/p>\n
                        The main advantage of Kustomize is that it is very easy to start using as it’s integrated with kubectl<\/code> as well.<\/p>\n
                        If you are learning Kubernetes check out the Kubernetes learning roadmap<\/a> to deepen your Kubernetes knowledge.<\/p>\n
                        \n
                        Ngu\u1ed3n:<\/strong> Kubernetes Kustomize Tutorial (Comprehensive Guide) \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
                        Source: https:\/\/devopscube.com\/kustomize-tutorial\/<\/p>\n","protected":false},"author":1,"featured_media":945,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-944","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/944","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=944"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/944\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/945"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=944"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=944"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=944"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}