Nowadays, there are so many files to manage different Kubernetes configurations, which is very overwhelming. These files are the building blocks of Kubernetes clusters and configurations. However, as the applications grow, so do YAML files, turning into a complex web of configurations that is very hard to manage and prone to errors.
One of the most challenging aspects of Kubernetes management is dealing with environment-specific configurations. Different configurations are needed for development, testing, staging, and production environments. The general approach can be to keep duplicating YAML files, which results in redundancy and increasing errors. Keeping these configurations in sync while ensuring each environment has unique customizations is a constant battle. Kustomize is here to save the day!
If you are wondering why we need multiple environments, check out A Guide to Dev, Test, Staging, and Production Environments.
What is Kustomize?
Kustomize is a CLI configuration manager for Kubernetes objects that leverage layering to preserve the application’s base settings. This is done by overlaying the declarative YAML artifacts to override default settings without changing the original manifest.
How does Kustomize work?
Think of it like you are at an airport. The airport has to handle flights from different airlines. Each flight has its respective destination, schedule, and services. To manage this, the airport has constant core infrastructure, like runways, baggage claim areas, and security checkpoints. However, different airlines and destinations require specific modifications and additions to this base infrastructure—such as check-in counters, boarding gates, sign gates, etc.
Kustomize works in the same way for Kubernetes configurations. The base infrastructure represents the core Kubernetes configurations, similar to standard airport facilities. Airlines and destinations symbolize the overlays, which customize the base setup for different environments, similar to adapting check-in counters for various airlines. Configuration management is handled by the kustomization.yaml file, which coordinates and combines the base and overlay configurations, ensuring a tailored setup for each specific environment.
Structure of Kustomize
Kustomize is structured around the concept of overlays and bases, as mentioned above. Below is a breakdown of the structure.
So, three main components make customising Kubernetes configurations easy.
- Base: This is the foundational set of Kubernetes manifests, which includes common configurations, such as deployments and manifests, that will be shared across different environments.
Let us imagine you have an app named Xapp. This is how a general base directory will look.
~/Xapp
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml- Overlay: Overlays are used to modify or extend the base configuration. They allow you to customize the base for specific environments, such as development, staging, or production. Overlays can adjust parameters, add labels, or even include additional resources.
For the same Xapp, this is what a general overlay will look like.
~/xapp
├── overlays
├── development-environment
│ ├── deployment-dev.yaml //this will have some changes in the base deployment
│ ├── kustomization.yaml|
└── production
├── deployment-prod.yaml //this will have some changes in the base deployement
├── kustomization.yaml- Kustomization.yaml: This file is the heart of Kustomize. It defines how the base and overlays should be combined and lists the resources, patches, and customizations to be applied. For example:
namespace: kustomize //specifies the kubernetes namespace for resources defined
resources: //paths to the base configurations that the current overlay depends on
- ../../base This is how the final structure looks like:
~/xapp
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── development
│ ├── deployment-dev.yaml
│ ├── kustomization.yaml
└── production
├── deployment-prod.yaml
├── kustomization.yamlHands-on with Kustomization
Prerequisites
Before diving into Kustomize, you should have:
- Basic understanding of Kubernetes and YAML
- A working Kubernetes cluster setup
- Kubectl installed in your machine (Kustomize has been included in kubectl since version 1.14)
Setting Up
We will be using the above directory structure to set up Kustomize.
- First things first, create the directory structure.
mkdir -p ~/xapp/base
mkdir -p ~/xapp/overlays/development
mkdir -p ~/xapp/overlays/production- Inside the base directory, create the deployment.yaml, services.yaml, and customization. yaml files. I am creating all the files according to a Fast API application.
i. deployment.yaml: This file creates and manages a single replica of a FastAPI application, defining its container image, exposed port, and resource allocation.
apiVersion: apps/v1
kind: Deployment
metadata:
name: fastapi
namespace: kustomize
spec:
replicas: 1
selector:
matchLabels:
app: fastapi
template:
metadata:
labels:
app: fastapi
spec:
containers:
- name: fastapi
image: <This is intentionally left blank, you can use your image>
ports:
- containerPort: 8000
resources:
limits:
cpu: "1"
memory: "512Mi"
requests:
cpu: "100m"
memory: "256Mi"ii. services.yaml : This file defines a Kubernetes Service named “fastapi”, and it acts as an internal load balancer.
apiVersion: v1
kind: Service
metadata:
name: fastapi
spec:
type: NodePort
selector:
app: fastapi
ports:
- protocol: TCP
port: 8000
targetPort: 8000
nodePort: 30001iii. kustomization.yaml: This file instructs Kustomize to include two specific Kubernetes resource files—deployment.yaml and service.yaml—within the “kustomize” namespace when generating the final manifests for deployment.
namespace: kustomize
resources:
- deployment.yaml
- service.yaml- Now, let us create the overlays/development files.
i. deployement-dev.yml: This file customizes the deployment configuration specifically for a development environment and works in conjunction with a base deployment.yaml file (mentioned earlier) to create the final deployment manifest for Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: fastapi
spec:
replicas: 2
template:
spec:
containers:
- name: fastapi
image: <This is intentionally left blank, you can use your image>
env:
- name: ENVIRONMENT
value: "development"
resources:
limits:
cpu: "500m"
memory: "256Mi"
requests:
cpu: "100m"
memory: "128Mi"- And in the end, let us create the files for overlays/production files.
i. deployment-prod.yaml: This file customizes the deployment configuration specifically for a Production environment. It likely works in conjunction with a base deployment.yaml file (mentioned earlier).
apiVersion: apps/v1
kind: Deployment
metadata:
name: fastapi
spec:
template:
spec:
containers:
- name: fastapi
image: fastapi-prod:latest
env:
- name: ENVIRONMENT
value: "production"
resources:
limits:
cpu: "2"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"- Open your terminal and run these commands to apply the configurations to the cluster.
kustomize build ~/Xapp/overlays/development | kubectl apply -f -
kustomize build ~/Xapp/overlays/production | kubectl apply -f - Conclusion
In the above blog, we learnt how Kustomize.io streamlines the management of Kubernetes configurations. It introduces Kustomize as a CLI configuration manager. The structure of Kustomize, including base, overlays, and kustomization.yaml is explained along with a practical hands-on guide for setting it up. Feel free to leave comments in case of doubts or further questions, if any.
For more information on cloud computing, Kubernetes, cloud technology, and security, visit the CloudZenia website.
Leave a Reply