Templating Values in Kustomize: Unlocking the Potential of Dynamic Naming for Kubernetes Resources

In the world of Kubernetes, managing and customizing configurations across multiple environments or instances can be both crucial and complex. Enter Kustomize – a tool that enhances Kubernetes' native configuration management capabilities. Among its many features, one stands out for its potential to significantly streamline and dynamize configuration: the ability to template values using the replacements feature. Though not widely explored, this feature can be a very handy in DevOps life, particularly when it comes to dynamically building resource names and other values within Kubernetes manifests.

Understanding replacements in Kustomize

Before diving into examples, let's understand what replacements in Kustomize are. As detailed in the official documentation, replacements allow you to specify fields from one resource that should be used to replace fields in another. This can include anything from simple value substitutions to more complex scenarios like dynamically building names based on other resource attributes.

This feature opens up a variety of possibilities for making your configurations more flexible and adaptable to different environments, deployment scenarios, or naming conventions.

Dynamic naming with replacements

One of the most compelling applications of the replacements feature lies in constructing dynamic names for resources such as PersistentVolumeClaims (PVCs), ConfigMaps, Deployments, and more. This capability unlocks the potential to not only copy data from a single source manifest into multiple specified targets but also to refine selection with precision. Developers can specify targets using the select field and exclude specific matches by utilizing the reject field. This granularity introduces the flexibility needed to dynamically create manifests.

Let's explore some practical examples.

Example 1: Dynamically named PVCs

Consider a scenario where you have a PVC with a base name and want to append a dynamic segment to it based on the deployment name. For simplicity, let's say our base PVC name is fast-pvc-, and we want to create a naming convention like fast-pvc-{deployment-name}. In addition we want to append to PVC also a namespace from deployment.

Here's how you could achieve this using Kustomize replacements:

1. Define the base PersistentVolumeClaim in pcv.yaml file.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-pvc-
spec:
  capacity:
      storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: fast
  resources:
    requests:
      storage: 8Gi

2. Next create the deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
  namespace: ml-experiments
  labels:
    app: nginx
    type: server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25.4
          ports:
            - containerPort: 80
          resources:
            limits:
              memory: 512Mi
              cpu: "1"
            requests:
              memory: 64Mi
              cpu: "250m"

3. Lastly, create a kustomization.yaml file with an additional section that specifies the replacement rules:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - pvc.yaml
  - deployment.yaml

replacements:
  - source:
      kind: Deployment
      name: my-nginx-deployment
      fieldPath: metadata.namespace
    targets:
      - select:
          name: fast-pvc-
          kind: PersistentVolumeClaim
        fieldPaths:
          - metadata.namespace
        options:
          create: true
  - source:
      kind: Deployment
      name: my-nginx-deployment
      fieldPath: metadata.name
    targets:
      - select:
          name: fast-pvc-
          kind: PersistentVolumeClaim
        fieldPaths:
          - metadata.name
        options:
          delimiter: "-"
          index: 2

This configuration instructs Kustomize to perform two actions:

• Extract the metadata.namespace field from the Deployment manifest and replicate it within the PersistentVolumeClaim under the same metadata.namespace field. Notably, the options parameter is specified and set to true, enabling the addition of the field in the target if it is absent. Essentially, the value from the Deployment will either overwrite the existing one or be newly created in the PVC.
• Retrieve the metadata.name from a Deployment resource and concatenate it with the metadata.name of the PVC, leading to a dynamically generated PVC name: fast-pvc-my-nginx-deployment. This manipulation leverages optional parameters such as delimiter and index for partial string replacement.

To generate the Kustomize output, use the command below:

kubectl kustomize example-pvc

Please note that in this example, the relevant files are located within the example-pvc directory, and the kubectl command is executed from the parent directory.

The output of kustomize build will be as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-pvc-my-nginx-deployment
  namespace: ml-experiments
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  persistentVolumeReclaimPolicy: Recycle
  resources:
    requests:
      storage: 8Gi
  storageClassName: fast
  volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
    type: server
  name: my-nginx-deployment
  namespace: ml-experiments
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.25.4
        name: nginx
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: 250m
            memory: 64Mi

In the context of this example, dynamic naming and namespace adjustments were illustrated using the replacements feature. It's important to highlight that the specific action of namespace replacement serves merely as an example to showcase the versatility of Kustomize. This particular task of adjusting the namespace can also be directly achieved using a tool specifically designed for this purpose within Kustomize. The namespace transformer offers a straightforward method to set or change the namespace for all resources in a kustomization at once, simplifying the process for common namespace adjustments. For more details on this transformer and its usage, please refer to the official Kustomize documentation: Setting the Namespace with Kustomize. As always, developers should choose the most effective tool for their specific configuration needs.

Is your infrastructure Kubernetes-ready?

Kubernetes is at the forefront of container orchestration, offering flexibility, resilience, and scalability. However, ensuring your infrastructure is ready for this transition is crucial. We offer comprehensive assessments and solutions to prepare your environment for Kubernetes, aligning with best practices and industry standards.

Contact Us

Example 2: ConfigMap values based on deployment environment

Suppose you aim to adjust ConfigMap values based on the deployment's environment (e.g., development, staging, production) and the parameter count of deploying a machine learning model. You can dynamically template these values using replacements.

1. Define your ConfigMap in configMap.yaml file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ai-app-config
data:
  environment: ""
  modelVersion: llm--v.05

2. Create a deployment in deployment.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-ai-app
  namespace: ml-experiments
  labels:
    environment: production
    modelParameters: 7B

3. Define replacements in a separate file, contrasting with the inline method used previously. Create a file named model-replacement.yaml with the following content:

source:
  kind: Deployment
  name: my-ai-app
  fieldPath: metadata.labels.modelParameters
targets:
- select:
    kind: ConfigMap
    name: ai-app-config
  fieldPaths:
    - data.modelVersion
  options:
    delimiter: "-"
    index: 1

4. Create the kustomization.yaml file as the final step:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - configMap.yaml
  - deployment.yaml

replacements:
  - source:
      kind: Deployment
      name: my-ai-app
      fieldPath: metadata.labels.environment
    targets:
      - select:
          name: ai-app-config
        fieldPaths:
          - data.environment
  - source:
      kind: Deployment
      fieldPath: metadata.namespace
    targets:
      - select:
          name: app-config
        fieldPaths:
          - metadata.namespace
        options:
          create: true
  - path: model-replacement.yaml

This configuration dynamically updates the ConfigMap's data.environment with the environment label from the Deployment, facilitating environment-specific settings. It demonstrates the use of inline replacements (directly in the kustomization.yaml file) and the capability to define replacements in an external file (model-replacement.yaml), specified by the path field. By leveraging optional delimiter and index fields, it also incorporates the machine learning model's parameter count into the modelVersion value.

Again, to generate the Kustomize output, use the command below:

kubectl kustomize example-configMap

Please note that in this example, the relevant files are located within the example-configMap directory, and the kubectl command is executed from the parent directory.

Kustomize build output this time as as follows:

apiVersion: v1
data:
  environment: production
  modelVersion: llm-7B-v.05
kind: ConfigMap
metadata:
  name: ai-app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    environment: production
    modelParameters: 7B
  name: my-ai-app
  namespace: ml-experiments

Advantages of Dynamic Naming

Implementing dynamic naming and value templating with Kustomize offers numerous advantages for Kubernetes configuration management:

• Consistency: Achieves naming consistency across Kubernetes resources, significantly reducing the risk of manual errors and inconsistencies in your deployments.
• Automation: Facilitates the automation of deployment processes across varied environments, ensuring that customizations are applied consistently and efficiently.
• Flexibility: Enables the modification of configurations dynamically without the need to directly alter the base manifests. This approach enhances the maintainability and scalability of your Kubernetes setup, allowing for easier adaptations as requirements evolve.

Wrapping Up

The replacements feature in Kustomize represents an exceptionally versatile yet underexploited capability within the Kubernetes ecosystem. As demonstrated through the examples of dynamically named PersistentVolumeClaims, ConfigMaps adjusted based on deployment environments, and the incorporation of deployment-specific parameters into ConfigMaps, this feature substantially augments the flexibility and dynamism of Kubernetes configurations.

By applying dynamic naming and value templating, you can more effectively manage and streamline complex Kubernetes environments. This encompasses everything from resource naming and configuration value adjustments to tailoring settings for specific deployment contexts. The ability to precisely control these aspects through Kustomize not only simplifies administrative tasks but also empowers developers and operators with a more resilient and adaptable infrastructure.

As Kubernetes continues to evolve, leveraging advanced features like replacements in Kustomize will be crucial for staying ahead in the fast-paced world of container orchestration. The potential for innovation is vast, and by incorporating these practices into your Kubernetes strategy, you can unlock new levels of efficiency and flexibility in your deployments.

As Kubernetes continues to evolve, the integration of advanced features like replacements in Kustomize becomes crucial, especially for staying at the forefront of container orchestration's rapid development. This is particularly true in fields like machine learning, where deploying and verifying models demand unparalleled efficiency and adaptability. By weaving these practices into your Kubernetes strategy, you're not just enhancing current deployment processes; you're also laying the groundwork for future innovations. This approach ensures that your infrastructure is primed for the dynamic needs of machine learning model deployment and verification, unlocking new potentials for automation and scalability.

We encourage you to experiment with these techniques, explore the capabilities of Kustomize further, and consider how dynamic naming and templating can enhance your Kubernetes projects. The journey towards more agile and responsive infrastructure management starts here.