Use Kustomize to patch across more than one dimension?

Question

I'm exploring Kustomize. I see how it is used to create base configuration files and patches to customize specific settings for different environments, such as Dev, Test, Prod. Can it be used to patch across multiple dimensions?

My project consists of multiple applications running in Kubernetes. I'd like to be able specify base settings and be able to tweak them in some cases based on environment, in some cases based on application, and in some cases both. Right now, I've got completely separate full configuration files for each environment/app combination, with huge amounts of dupliation. As simple examples of what I'm looking for:

There are values that are common across the entire project, such as the URL of the Splunk collector.
For logging to Splunk, there's an environment variable that specifies which index to log events to. For Dev and Test, events are added to a "sandbox" index, from which events are purged after two weeks. For Prod, they're logged to an index specific to our project, where the retention period is three months. So I'd like to be able to patch that variable according to the environment--the basic use case for Kustomize.
Also for logging to Splunk, there's an environment variable that specifies the value of an APP_NAME field to be added to each log entry. (While application-specific values can mostly be set within the application, suppose this value will be used for purposes external to the application as well.) So I'd like to patch that variable according to the application.
I'd like to be able to set minReplicas and maxReplicas for every environment/application combination independently. In addition, as each app has its own Dev, Test, and Prod databases, each environment/application combination has its own database connection string stored as an environment variable.

Can Kustomize handle this? Can someone point me to a resource illustrating a multi-dimension scenario? If there is one, I haven't managed to come up with a search string that leads me to it.

score 1 · Accepted Answer · answered Feb 23 '23 at 22:58

There are values that are common across the entire project, such as the URL of the Splunk collector.

Not sure what to do with this: if by values you mean "environment variables in our deployments" this is easy, but if the value is used in multiple places across multiple object types, you can't handle this with kustomize (unless you start involving helm templates as part of the process).

For logging to Splunk, there's an environment variable that specifies which index to log events to...So I'd like to be able to patch that variable according to the environment--the basic use case for Kustomize.

This is pretty easy to manage (as long as you're only trying to insert the variable into a single resource type, like a Deployment). A kustomization.yaml like this as part of each overlay would inject the SPLUNK_INDEX environment variable into the my-app container of a Deployment named example-app1:

patches:
  - patch: |
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: example-app1
      spec:
        template:
          spec:
            containers:
              - name: my-app
                env:
                  - name: SPLUNK_INDEX
                    value: dev

Also for logging to Splunk, there's an environment variable that specifies the value of an APP_NAME field to be added to each log entry...So I'd like to patch that variable according to the application.

You can target patches to resources using a variety of criteria, including name wildcards and label selectors. So for example, we can write this to inject the SPLUNK_APP_NAME environment variable only into Deployments with the label app: app1:

patches:
  - target:
      kind: Deployment
      labelSelector: "app=app1"
    patch: |
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: not-important
      spec:
        template:
          spec:
            containers:
              - name: my-app
                env:
                  - name: SPLUNK_APP_NAME
                    value: app1

I'd like to be able to set minReplicas and maxReplicas for every environment/application combination independently.

That seems the same as the previous example: each "environment" is an overlay, and you can target your patch to set minReplicas and maxReplicas using any of the available criteria.

In addition, as each app has its own Dev, Test, and Prod databases, each environment/application combination has its own database connection string stored as an environment variable.

This also doesn't seem to introduce any new requirements.

And I think that covers everything!

Use Kustomize to patch across more than one dimension?

1 Answers1