Kubernetes Basics #4 - Namespaces & Helm

DevOps

Last Edited: 3/30/2025

This blog post introduces namespaces and Helm in Kubernetes.

DevOps

In the last few articles, we've covered many of the fundamental components and resources for setting up a Kubernetes cluster. While it may seem straightforward at first glance, managing numerous resources for a cluster can be troublesome, especially when dealing with multiple versions of the same applications for different environments and when multiple developers are working on the same cluster. In this article, we'll cover some ways to organize and manage the cluster's resources in a clear and efficient manner.

Namespaces

Namespaces in Kubernetes are like virtual clusters within a cluster, used to organize various resources. There are four namespaces set up by default, visible when you run kubectl get namespace: kube-system (for system processes like the master and kubectl), kube-public (containing public information about the cluster, such as config maps), kube-node-lease (containing information about nodes), and default (the default namespace for user-created resources). When creating resources, they were initially created in the default namespace.

frontend-config.yaml
## frontend-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: frontend-config
  namespace: my-new-namespace
data:
  backend-url: backend-service

To create a new namespace, use the command kubectl create namespace <namespace-name> or specify the namespace field in the metadata section of your YAML configuration files. To view resources within a specific namespace, add -n <namespace-name> to your kubectl get commands. Namespaces allow you to separate resource types (logging, monitoring, databases, etc.), isolate resources for different teams, or share resources across different development and production clusters. Resources cannot be shared between namespaces unless explicitly configured, except for services, which can be accessed via <service-name>.<namespace-name>.

Helm

When working on a cluster with a team of developers, it's important to ensure that every team member can easily replicate the build configuration and apply it consistently. Sharing YAML files on GitHub is a good start, but ensuring that all team members apply the resources in the same way can become tedious, especially with many resources and different versions or stages. Helm is a package manager that bundles multiple YAML files into a Helm chart, enabling easy distribution, deployment, and destruction. The chart also includes templating capabilities for customizing deployments based on the environment.

To get started with Helm, you can install it using homebrew (brew install helm) or follow the installation scripts in the official documentation (cited at the bottom of the article). You can search for charts on the Artifact Hub (the official hub) via its website or using helm search hub <name>. You can add repositories to your local client using helm repo add <name> <url>. To install a Helm chart, use helm install <release-name> <chart-name>. To remove a deployment, simply run helm uninstall <release-name>. Use helm list with the --all flag to check existing releases.

chart-name/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
│   ├── resource.yaml
└── └── ... other resources

You can also create your own Helm charts, and the typical file structure for that looks like the above. The Chart.yaml file contains the chart's descriptions and metadata, values.yaml contains the default values used in the templates, the charts directory contains chart dependencies, the templates directory contains all the resource templates, and NOTES.txt is displayed during helm install. Values in Chart.yaml and values.yaml are accessible within templates using constructs like {{ .Chart.Version }} and {{ .Values.<key> }}. You can also access release information, such as {{ .Release.Name }}.

# In Chart.yaml
apiVersion: v2
name: chart-name
version: 0.0.1
# ...bunch of other optional fields
 
# In values.yaml
config:
  mypokemon: "Pikachu"
# ...other values
 
# In templates/config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  mypokemon: {{ .Values.config.mypokemon }}

You can check if a chart is properly formed with the helm lint command. When a chart is ready to be packaged, you can run helm package <chart-name>, which should create <chart-name>-<chart-version>.tgz. This file can then be pushed to a chart repository either with helm push <chart-name> <remote> or via its website using GitHub. To use a different set of values than those defined in values.yaml, you can create separate YAML files containing the desired values, such as my-values.yaml, and use the --values=my-values.yaml flag when installing the chart. You can upgrade and rollback releases using helm upgrade and helm rollback.

Helm charts are useful for easily managing resources by bundling them with templating functionality, distributing builds to public or private members, and leveraging existing charts to quickly deploy useful third-party software in your cluster (like running Prometheus for monitoring, which will be covered in the future). Many details have been omitted from this article, such as template functions for flexible builds, other Helm commands and flags, and built-in objects. You can learn more in the official documentation cited at the bottom of the article.

Conclusion

In this article, we covered namespaces in Kubernetes and Helm, which are helpful tools for organizing resources and clusters and making it easier to collaborate on a cluster. You can use namespaces and Helm charts simultaneously for clear organization and management. For example, you can use a namespace to isolate an environment for testing a newly installed Helm chart, and resources can be organized with namespaces within the chart.

Resources

Back to Top↑