Helm and Kustomization: A Tail of K8S Manifests Management

Helm and Kustomization: A Tail of K8S Manifests Management

This repository provide examples for you to code and play around for the concepts in the following articles.

It uses a demo backend application that would serve different API result when deployed with different environment variables. It uses k3d to create a k8s cluster in docker (using k3s), and uses justfile as the project interface. Users who have difficult installing justfile may refer to justfile for the equivalent commands for inteeracting with source codes.

The raw Kubernetes YAML declarations are commonly referred to as “Kubernetes manifests” or “Kubernetes YAML manifests.” These manifests are written in YAML,which is a human-readable data serialization format. The manifests define the desired state of Kubernetes resources such as pods, deployments, services, and more. These manifests serves as the programmer’s interface to a kubernetes cluster, with various kubernetes controller taking care of the actual resource (compute, storage, network) provisioning and orchastration logic.

Managing Kubernetes manifests at scale can become challenging, especially when dealing with a large number of YAML files. To address this issue, several tools and techniques have emerged to simplify the management of Kubernetes manifests. Three popular methods are raw YAML, Helm charts, and Kustomize. Let’s discuss each of them in more detail:

Raw YAML: Raw YAML manifests are the basic way of defining Kubernetes resources. Each resource is defined in a separate YAML file, and you apply them using kubectl apply -f <filename>. While this approach is straightforward, it can become cumbersome to manage and maintain a large number of individual files, especially in complex deployments.

Refer to https://github.com/schwannden/helm-and-kustomize/tree/main/raw_yaml to see how to deploy this demo backend with raw YAML files:

kubectl apply -f deployment.yaml -n demo 
kubectl apply -f service.yaml -n demo 
kubectl apply -f ingress.yaml -n demo

With raw YAML manifests

1. It requires manually updating in a complicated yaml file.
2. It requires operaator to update multiple locations if we decide to change some shared values like port, service name, …etc.
3. Not clear to operator as to which values are expose for customization.

Helm charts: Helm is a package manager for Kubernetes that provides a higher-level abstraction for managing applications. It introduces the concept of Helm charts, which are packages containing a set of pre-configured Kubernetes manifests. Helm charts are written in YAML and can encapsulate multiple resources, including deployments, services, config maps, and more. Helm allows you to define templates, values, and hooks, making it easy to parameterize and customize deployments.

Refer to https://github.com/schwannden/helm-and-kustomize/tree/main/chart to see how to deploy this demo backend with a helm chart.

helm install demo-backend . --namespace demo --create-namespace

WIth Helm chart,

1. It is much more convenient to change common values through values.yaml.
2. Shared configuration can be managed with the helm’s templating functions.

But still

1. It is not clear how to solve problems where you need to manage variations of the same application configuration for different environments or teams.

Kustomize: Kustomize is another tool for managing Kubernetes manifests. It is included in the kubectl command-line tool since Kubernetes 1.14. Kustomize allows you to customize and manage Kubernetes resources using overlays and patches without modifying the base manifests directly.

Kustomize uses a directory structure with a base and overlay approach. The base directory contains the original YAML manifests, and overlays contain patches or additional configuration that customize the base resources. Overlays can be used to modify labels, annotations, names, and other fields in the base manifests. With Kustomize, you can manage different configurations and environments without duplicating or modifying the original YAML files.

Refer to https://github.com/schwannden/helm-and-kustomize/tree/main/kustomize to see how to deploy this demo backend with Kustomization

kubectl apply -n demo -k overlays/demo

1. Kustomize works well with version control systems and is especially useful in scenarios where you need to manage variations of the same application configuration for different environments or teams.
2. But Kustomize lacks the version control, installation management features provided by helm.

Indeed, both Kustomize and Helm are valuable tools for managing Kubernetes manifests, and they approach manifest management in different ways. Kustomize focuses on customization and patching of base manifests, while Helm provides a higher-level package management approach.T

here might be scenario where you need the benefits of both, an example to do so with ArgoCD is documented here, but it is a more advanced topic that should not be covered in this article.