Umbrella Charts: Creating high-level charts to export global settings.
Umbrella charts offer various functionalities. In this article, we'll delve into the strategy of maintaining a Helm umbrella chart to manage multiple environments.
Helm
Kubernetes, a widely utilized system for container orchestration, provides an effective approach to managing and deploying applications in distributed environments. However, dealing with the complexity of Kubernetes deployments can pose a challenge. In this scenario, Helm Charts emerge as a solution, simplifying the process of defining, installing, and managing applications.
Helm is a package management tool for Kubernetes, designed to streamline the consistent deployment of complex applications. At the core of Helm are Helm Charts – packages that encapsulate the information and configurations necessary for deploying a Kubernetes application.
For more detailed information about the Helm project, please refer to the official CNCF report at CNCF Report
A Helm Chart is organized into structured directories, each playing a specific role in defining and configuring the application. The key components include:
- charts/ Optional directory that can contain dependencies of the Chart.
- templates/ Contains YAML files defining Kubernetes resources, such as pods, services, and ingress.
- values.yaml File containing configurable default values, allowing customization during installation.
- service.yaml Create a service to expose Nginx pods to the internal network of the cluster.
- deployment.yaml
- service.yaml
- values.yaml
- deployment.yaml
- service.yaml
- values.yaml
- Chart.yaml
- values.yaml
Installing Helm
In this article, we will use the script installation method, but you can choose your preferred installation option. For more details, please visit Helm installation.
First let's download the installation script
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
Let's add some permission.
chmod 700 get_helm.sh
And finally, we run the installation script
./get_helm.sh
If everything went well, you should have an output similar to this when checking the version.
helm versionversion.BuildInfo{Version:"v3.13.1", GitTreeState:"clean", GoVersion:"go1.20.8"}
Configuration files
First and foremost, it is essential to conduct a thorough analysis of the written file structure. Feel free to explore each file, examining the values stored within. This step is crucial for understanding the configuration and organization of the data present in the file tree.
Upon completing this detailed analysis, it becomes possible to delve into an understanding of the responsibilities of each component involved in the system. Each element plays a specific role in the overall functioning.
- deployment.yaml
- service.yaml
- values.yaml
- Chart.yaml
- deployment.yaml
- service.yaml
- values.yaml
- Chart.yaml
- Chart.yaml
- values.yaml
apiVersion: v2name: umbrella-chartdescription: A Helm chart for managing Nginx in different environments.type: applicationversion: 0.1.0appVersion: "1.0"dependencies: - name: dv version: "0.1.0" repository: "file://./charts/dv" - name: prd version: "0.1.0" repository: "file://./charts/prd"
Settings by environment
The existence of a directory named "charts" is observed, adopting a specific organizational approach by implementing the technique known as subcharts in the Helm context. This main directory is further subdivided into distinct environments, notably "dv" (development) and "prd" (production), each encapsulating a dedicated set of Helm artifacts.
Each environment subdirectory, such as "dv" or "prd," maintains its own Helm chart structure. This includes a "Chart.yaml" file describing the chart's properties, a "templates" subdirectory containing Kubernetes templates like "deployment.yaml" and "service.yaml," and a "values.yaml" file storing environment-specific configuration values.
Note that in our main Chart, we have configured the subcharts as dependencies to the main Chart. Dependencies specify the development ("dv") and production ("prd") environments in which Nginx will be managed by "umbrella-chart".
Kubernetes
After completing all the necessary configurations, we will install it on Chart using the following command:
Consider that the first parameter is the name of your Chart, and the second one is its path.helm install nginx-umbrella-chart ./umbrella-chart
After the installation, you should receive a response like this:
NAME NAMESPACE REVISION STATUS CHART APP VERSIONnginx-umbrella-chart default 1 deployed umbrella-chart-0.1.0 1.0
Examining our Kubernetes deployments now, it is evident that in the development environment, a single active pod can be observed. However, when scrutinizing the production environment, three instances are running. This discrepancy is attributed to the segregated configurations between the environments, employing the technique of subcharts and umbrella charts.
k get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEnginx-dv-deployment 1/1 1 1 23hnginx-prd-deployment 3/3 3 3 23h
Directly inspecting the pods, we can verify the behavior.
k get podsNAME READY STATUS RESTARTS AGEnginx-dv-deployment-c69bcd94-w7zjv 1/1 Running 0 23hnginx-prd-deployment-c69bcd94-fjxzx 1/1 Running 0 23hnginx-prd-deployment-c69bcd94-kxxc9 1/1 Running 0 23hnginx-prd-deployment-c69bcd94-tvnt5 1/1 Running 0 23h
Conclusion
By leveraging this approach, we achieve a notable level of abstraction, enabling the creation of custom charts tailored to specific needs and configurations. This not only enhances the overall manageability of environments but also promotes a modular and scalable structure, streamlining the deployment and maintenance processes. The magic of umbrella charts lies in their ability to simplify complex deployments and offer a flexible framework for orchestrating diverse charts within different environments, ensuring a more efficient and adaptable Kubernetes infrastructure.
Time is a precious commodity, and I appreciate you generously sharing a portion of yours with me.