{"id":588,"date":"2023-06-28T15:52:45","date_gmt":"2023-06-28T15:52:45","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=588"},"modified":"2023-06-28T15:52:45","modified_gmt":"2023-06-28T15:52:45","slug":"kuztomize-configmap-generators","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=588","title":{"rendered":"Kuztomize Secret & Configmap Generators [Practical Examples]"},"content":{"rendered":"

In this guide, we will look at how to generate Kubernetes Configmaps and Secrets using Kustomize.<\/p>\n

If you are new to Kustomize, please check out the Kustomize tutorial <\/a>to learn the basics.<\/p>\n

Configmap & Secret Generator Use Case<\/h2>\n

Before looking into how a secret\/config generator works, let’s understand what problem it solves.<\/p>\n

When you update a configmap attached to a pod as a volume, the configmap data gets propagated to the pod automatically. However, the pod does not get the latest data<\/strong> in the configmap in the following scenarios.<\/p>\n

    \n
  1. If the pod gets environment variables from the configmap.<\/li>\n
  2. If the configmap is mounted as a volume using a subpath.<\/li>\n<\/ol>\n

    In the above cases, the pod will continue using the old configmap data until we restart the pod. Because the pod is unaware<\/strong> of what got changed in configMap.<\/p>\n

    Essentially, the data from the ConfigMaps (such as properties, environment variables, etc.) is used by applications during their startup<\/strong>. So even if the updated configmap data is projected to the pod, if the application running inside the pod doesn’t have any hot reload mechanism<\/strong>, you will have to restart the pod for the changes to take place.<\/p>\n

    What options do we have to solve this issue?<\/p>\n

      \n
    1. You can use Reloader<\/a> Controller.<\/li>\n
    2. Using Kustomize ConfigMap Generator<\/li>\n<\/ol>\n

      If you already use Kustomize for Kubernetes Deployments<\/a> or planning to use it, there is no need for any extra controllers to take care of Configmap rollouts.<\/p>\n

      Kustomize Configmap & Secret Generator<\/h2>\n

      Here is how the Kustoimize Configmap\/Secret generator work.<\/p>\n

        \n
      1. Kustomize generator creates a configMap and Secret with a unique name(hash) at the end. For example, if the name of the configmap is app-configmap<\/strong>, the generated one would have the name app-configmap-7b58b6ct6d<\/strong>. Here 7b58b6ct6d<\/strong> is the appended hash.<\/li>\n
      2. If you update the configmap\/Secret, it will create a new configMap\/Secret <\/strong>with the same name with a different hash(random sets of characters) at the end.<\/li>\n
      3. Kustomize will automatically update<\/strong> the Deployment with the new configmap name.<\/li>\n
      4. The moment Deployment is updated by Kustomize, a rollout will be triggered<\/strong> and the application runs on the pod and gets the updated configmap\/secret data. In this way, we don’t need to redeploy or restart the deployment.<\/li>\n<\/ol>\n

        The following image shows the Configmap create and update workflow with changes in hash during create and update stages.<\/p>\n

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

        Following are the important points you should know about the Kustomize generators.<\/p>\n

          \n
        1. Since Kustomize creates a new configmap every time there is an update, you need to garbage-collect your old orphaned Configmaps<\/strong>. If you have resource quota limits set for namespace, orphaned Configmaps could be an issue. Or you should use the –prune <\/strong>flag with labels in the kubectl apply <\/strong>command. Also, GitOps tools like ArgoCD<\/strong> offer Orphaned resource monitoring mechanisms.<\/li>\n
        2. You can use the disableNameSuffixHash: true<\/code> flag to disable creating new Configmaps on every update, but it does not trigger a pod rollout. You need to manually trigger a rollout for pods to get the latest configmap data. Or the application running inside the pod should have a hot-reload mechanism.<\/li>\n<\/ol>\n

          Now let’s look at practically how to use Configmap and Secret Generators.<\/p>\n

          Generate Configmap Using Kustomize<\/h2>\n

          We will look at an Nginx example where it uses a configmap content for its index.html<\/p>\n

          \n
          Note:<\/strong><\/b> The base and overlay YAMLs are part of the Kustomize Github repo<\/a>. Clone the repo to follow along the tutorial<\/div>\n<\/div>\n

          Here is the file structure of the repository. To understand the generators, we will use the generators overlay folder.<\/p>\n

          \u251c\u2500\u2500 base\n\u2502   \u251c\u2500\u2500 deployment.yaml\n\u2502   \u251c\u2500\u2500 kustomization.yaml\n\u2502   \u2514\u2500\u2500 service.yaml\n\u2514\u2500\u2500 overlays\n    \u251c\u2500\u2500 dev\n    \u2502   \u251c\u2500\u2500 deployment-dev.yaml\n    \u2502   \u251c\u2500\u2500 kustomization.yaml\n    \u2502   \u2514\u2500\u2500 service-dev.yaml\n    \u251c\u2500\u2500 generators\n    \u2502   \u251c\u2500\u2500 deployment.yaml\n    \u2502   \u251c\u2500\u2500 files\n    \u2502   \u2502   \u2514\u2500\u2500 index.html\n    \u2502   \u251c\u2500\u2500 kustomization.yaml\n    \u2502   \u2514\u2500\u2500 service.yaml\n    \u2514\u2500\u2500 prod\n        \u251c\u2500\u2500 deployment-prod.yaml\n        \u251c\u2500\u2500 kustomization.yaml\n        \u2514\u2500\u2500 service-prod.yaml<\/code><\/pre>\n
          generators\/deployment.yaml<\/code><\/strong><\/p>\n
          Here is the Overlay nginx deployment.yaml <\/code><\/strong>that uses a configmap named index-html-configmap<\/code><\/strong> mounted as a volume and env variable <\/strong>derived from a configmap named endpoint-configmap<\/code><\/strong>. I have highlighted the configs in bold.<\/p>\n
          apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: web-deployment\nspec:\n  replicas: 3\n  template:\n    spec:\n      containers:\n      - name: nginx\n        resources:\n          limits:\n            cpu: \"200m\"\n            memory: \"256Mi\"\n          requests:\n            cpu: \"100m\"\n            memory: \"128Mi\"\n        env:\n        - name: ENDPOINT\n          valueFrom:\n            configMapKeyRef:\n              name: endpoint-configmap\n              key: endpoint\n        volumeMounts:\n        - name: nginx-index-file\n          mountPath: \/usr\/share\/nginx\/html\/\n      volumes:\n      - name: nginx-index-file\n        configMap:\n          name: index-html-configmap<\/code><\/pre>\n
          files\/index.html<\/code><\/strong><\/p>\n
          We have the configmap file content in the index.html file under the files directory<\/p>\n
          <html>\n    <h1>Welcome<\/h1>\n    <\/br>\n    <h1>Hi! This is the Configmap Index file <\/h1>\n    <\/html<\/code><\/pre>\n
          generators\/kustomization.yaml<\/code><\/strong><\/p>\n
          The configmap generation options should be added to the kustomization.yaml<\/code><\/strong> file under configMapGenerator<\/strong> field.<\/p>\n
          In this example,  we are generating two types of Configmaps.<\/p>\n
            \n
          1. Configmap from a file (index.html) that will be mounted to the nginx \/usr\/share\/nginx\/html\/ <\/strong>directory.<\/li>\n
          2. Configmap from literals, that will set an environment variable named ENDPOINTS<\/strong><\/li>\n<\/ol>\n
            Under generatorOptions<\/strong> field, you can add the common labels that needs to be added to the Configmaps.<\/p>\n
            apiVersion: kustomize.config.k8s.io\/v1beta1\nkind: Kustomization\n\nresources:\n- ..\/..\/base\n\npatches:\n- path: deployment.yaml\n- path: service.yaml\n\ngeneratorOptions:\n  labels:\n    app: web-service\n\nconfigMapGenerator:\n- name: index-html-configmap\n  behavior: create\n  files:\n  - files\/index.html\n- name: endpoint-configmap\n  literals:\n  - endpoint=\"api.example.com\/users\"<\/code><\/pre>\n
            Let’s run the deployment using Kustomize.<\/p>\n
            kustomize build overlays\/generators | k apply  -f -<\/code><\/pre>\n
            Now if you list the Configmaps, you can see two Configmaps created with a hash appended to their name as shown below.<\/p>\n
            kubectl get cm <\/code><\/pre>\n
            \"\"<\/figure>\n
            As the deployment has a NodePort service, you can access the Nginx webpage that shows the content from the Configmap as shown below.<\/p>\n
            \"\"<\/figure>\n
            Also, if you login to the pod and echo the ENDPOINT<\/strong> environment variable, you will see the data from the configmap as shown below.<\/p>\n
            \"\"<\/figure>\n
            Now, to test the configmap update through the generator, lets update the index.html<\/strong> data to the following.<\/p>\n
            <html>\n    <h1>Welcome<\/h1>\n    <\/br>\n    <h1>Hi! This is the Updated Configmap Index file <\/h1>\n<\/html\n<\/code><\/pre>\n
            Let’s update the deployment using the following command.<\/p>\n
            kustomize build overlays\/generators | k apply  -f -<\/code><\/pre>\n
            Now if you list the Configmaps, you will see two index Configmaps as shown below. This is because, for every configmap update, Kustomize will create a new configmap.<\/p>\n
            \"\"<\/figure>\n
            If you want to prune the orphaned Configmaps, use the –prune<\/strong> flag with the configmap label as shown below. The --prune<\/code> flag instructs Kustomize to remove any resources from the final output that is no longer referenced or required.<\/p>\n
            kustomize build overlays\/generators | kubectl apply --prune -l app=web-service  -f -<\/code><\/pre>\n
            Now, due to the new configmap created by Kustomize, the deployment triggers a rollout and nginx will use the updated configmap. If you check the Nginx NodePort service, you will see the updated index page.<\/p>\n
            \"\"<\/figure>\n
            Next, we will look at how to disable Hashed configmap.<\/p>\n
            Disabling Hashed ConfigMap<\/h2>\n
            If you don’t want to create hashed Configmaps using the ConfigMap generator, you can disable it by setting the disableNameSuffixHash<\/code><\/strong> flag to true under generatorOptions<\/code><\/strong>. It will disable the hash for all the Configmaps mentioned in the kustomization.yaml <\/code><\/strong>file.<\/p>\n
            Here is an example.<\/p>\n
            generatorOptions:\n  labels:\n    app: web-service\n  disableNameSuffixHash: true<\/code><\/pre>\n
            \n
            Note<\/strong><\/b>: If you disable Configmap hash, you need to manually restart the pods for the configmap data to be consumed by the application.<\/div>\n<\/div>\n
            Generate Secrets Using Kustomize<\/h2>\n
            You can generate secrets the same way you generate Configmaps.<\/p>\n
            For generating secrets, you need to use the secretGenerator field.<\/p>\n
            Here is an example of generating a secret object from a file.<\/p>\n
            secretGenerator:\n- name: nginx-secret\n  files:\n  - files\/secret.txt<\/code><\/pre>\n
            If you want to generate secrets from literals, use the following format.<\/p>\n
            secretGenerator:\n- name: nginx-api-password\n  literals:\n  - password=\"myS3cret\"<\/code><\/pre>\n
            You can mount the secret as a volume or propagate it as an environment variable as per your requirements.<\/p>\n
            Conclusion<\/h2>\n
            In this blog, we looked at,<\/p>\n
              \n
            1. Generating Configmaps and secrets using Kustomize generator.<\/li>\n
            2. Configmap generator considerations related to orphaned Configmaps.<\/li>\n
            3. A practical example implementing the Kustomize Configmap generator.<\/li>\n<\/ol>\n
              Also, if you are learning Kubernetes, check out my 40+ comprehensive Kubernetes tutorials.<\/a><\/p>\n
              \n
              Ngu\u1ed3n:<\/strong> Kuztomize Secret &amp; Configmap Generators [Practical Examples] \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
              Source: https:\/\/devopscube.com\/kuztomize-configmap-generators\/<\/p>\n","protected":false},"author":1,"featured_media":589,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-588","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\/588","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=588"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/588\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/589"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=588"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=588"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=588"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}