News



Insights

Learn Kubernetes Fast: Netron Connect You to The Cloud

 

In the current development process, it is often necessary to deploy similar code across different environments, e.g., develop, staging, production.

However, different configuration files need to be maintained when deploying to different environments. Kustomize aims to provide a simple and clear way for developers to use a consistent format for configuration files across different environments and keep them in one folder.

Kustomize provides functionality similar to sed to rewrite the configuration values into YAML files, enabling the same base YAML to generate different configurations in different environments.

You can also use envsubst to directly convert environment-related variables into YAML.

Installation

  1. Use Homebrew to install Kustomize (macOS only):
brew install kustomize
  1. Install via binary:
    https://kubectl.docs.kubernetes.io/installation/kustomize/binaries/

Introduction to Kustomize

1. Create kustomization file

Your folder should contain your YAML files, e.g., deployment, service, configmap, etc.
Create a kustomization file, which will contain the resources you want to define and the information you want to customize, essentially acting as a controller for the entire process.

The folder structure will look like this:

~/example
├── kustomization.yaml
├── deployment.yaml
└── service.yaml

The resources folder can be shared directly with others. If modifications are needed, you can update kustomization.yaml without directly modifying the resources.

Now you can use kustomize build to create a simple result. Here’s how to do it:

kustomize build ~/example

After running kustomize build, the YAML will be printed through stdout, which can then be directly used with kubectl to create resources.

kustomize build ~/example | kubectl apply -f -

You can also use the command kubectl apply -k directly to achieve the same result.
e.g. kubectl apply -k ~/example

2. Use overlays to create multiple environments

If you have multiple environments that need different configurations, kustomize can help you achieve this.
First, create base and overlays folders. Put the YAML files into base, and then create folders for each required environment under overlays. When modifications are needed for different environments, make changes only in the respective environment folders to minimize the risk of affecting other environments.

Your folder structure might look like this:

~/example
├── base
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays
    ├── development
    │   ├── cpu_count.yaml
    │   ├── kustomization.yaml
    │   └── replica_count.yaml
    └── production
        ├── cpu_count.yaml
        ├── kustomization.yaml
        └── replica_count.yaml

To build for a specific environment:

kustomize build ~/example/overlays/production

To deploy to Kubernetes, use it with kubectl, similar to the base:

kustomize build ~/example/overlays/production | kubectl apply -f -

Example

After going through the introduction, I believe everyone has some understanding of what Kustomize can do, but it may still be unclear how to actually write the configuration.
Don't worry~
Here’s a simple "Hello World" example that will clear things up for you.

The folder structure looks like this. We'll keep it simple, with two environments: develop and production. The current settings in the base folder represent the develop environment, allowing us to focus on setting up base and overlays.

~/example
├── base
│   ├── kustomization.yaml
│   └── deployment.yaml
└── overlays
    └── production
      ├── kustomization.yaml
      └── deployment.yaml

Below is the YAML file in the base:

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: arbitrary

commonLabels:
  app: hello      # This label will be applied to all resources

resources:        # YAML files to include
- deployment.yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      deployment: hello
  template:
    metadata:
      labels:
        deployment: hello
    spec:
      containers:
      - name: the-container
        image: nginx

Below are the YAML files in overlays:

kustomization.yaml

namePrefix: production-           # Prefix for all resource names
commonLabels:                     # These labels will be applied to all resources
  variant: production
  org: acmeCorporation
commonAnnotations:                # These annotations will be applied to all resources
  note: Hello, I am production!
resources:                        # Path to the base YAML files
- ../../base
patchesStrategicMerge:            # New configuration files to include
- deployment.yaml

deployment.yaml
This is the new deployment configuration. In the base, replicas is set to 1. After applying the configuration below, it will change replicas to 3.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  replicas: 3

Let's run the build with these settings and see the result:

$ kustomize build overlays/production
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    note: Hello, I am production!
  labels:
    app: hello
    org: acmeCorporation
    variant: production
  name: production-the-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
      deployment: hello
      org: acmeCorporation
      variant: production
  template:
    metadata:
      annotations:
        note: Hello, I am production!
      labels:
        app: hello
        deployment: hello
        org: acmeCorporation
        variant: production
    spec:
      containers:
      - image: monopole/hello:1
        name: the-container

Is the result what you expected?
Of course, Kustomize can do more complex operations, but that’s all for today’s lesson.

Think about how to integrate CI/CD pipelines to automatically replace image tags.

See you next time~

Reference

Contact
Contact