January 7, 2024

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.
              • filedeployment.yaml
              • fileservice.yaml
          • filevalues.yaml
              • filedeployment.yaml
              • fileservice.yaml
          • filevalues.yaml
  • fileChart.yaml
  • filevalues.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

helm-install.shcopy
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

Let's add some permission.

permission.shcopy
chmod 700 get_helm.sh

And finally, we run the installation script

install.shcopy
./get_helm.sh

If everything went well, you should have an output similar to this when checking the version.

version.shcopy
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.

fileumbrella-charts
              • filedeployment.yaml
              • fileservice.yaml
          • filevalues.yaml
          • fileChart.yaml
              • filedeployment.yaml
              • fileservice.yaml
          • filevalues.yaml
          • fileChart.yaml
  • fileChart.yaml
  • filevalues.yaml
fileChart.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 installcopy
helm install nginx-umbrella-chart ./umbrella-chart

After the installation, you should receive a response like this:

helm listcopy
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.

Deploymentscopy
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.

Podscopy
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.

For more thoughts like thisJoin the community
instagraminstagraminstagraminstagram