Setting Kubernetes Labels and Annotations
In this article, we look at configuring labels and annotations. All Kubernetes objects should have a set of labels.
Join the DZone community and get the full member experience.Join For Free
Helm chart is a popular method of packaging applications to be installed on the Kubernetes cluster. As Helm chart developers, we have to decide what configurations need to be made available to the customer and how should they be offered. In this article, we look at configuring labels and annotations. All Kubernetes objects should have a set of labels for external tools to identify and use them in a consistent manner. Specifying labels and annotations involves solving some key challenges.
- What are the labels that should be common to all Kubernetes objects?
- How to expose labels and annotations configuration parameters in values.yaml?
- We cannot say upfront what all the possible labels and annotation parameter names that a customer might want for application Pods.
- Allow customers to expose the services externally in the various ways that they might want.
The first challenge is to come up with a list of required labels. The official documentation provides a list of recommended labels. These labels are recommended for every object that we create and have a shared prefix:
app.kubernetes.io . Prefixes ensure that recommended labels do not get mixed up with custom labels defined by the customers.
In addition to these, we need to have an organization-wide consensus on the mandatory set of labels.
Exposing Labels and Annotations Configuration
Next, we need to let customers specify their custom labels and annotations. This can be supported with
This allows the customer to set additional labels in the custom values file such as:
Exposing Services Externally
Customers need to expose some services externally to the cluster via a LoadBalancer. This requires the services to be annotated with annotations specific to that LoadBalancer. For example, a customer may require the following annotations to support the F5 Load Balancer and services that need to be exposed externally to the cluster.
This can be supported in a similar way as labels:
With this background, we can set the labels and annotations for different Kubernetes Objects.
Labels will have mandatory labels as decided by the organization and extra labels from the customers and the same for annotations. The deployment file for an application should have labels and annotations as illustrated below.
Service with mandatory labels required of all Kubernetes objects and customer provided annotations.
The other common Kubernetes Objects, e.g., Horizontal Pod Autoscalar, ConfigMap, Secrets should have the mandatory labels common to all objects.
Labels and annotations are one of the main foundations for Kubernetes. They are both ways of adding metadata to Kubernetes objects. Kubernetes labels allow us to identify, select, and operate on Kubernetes objects, whereas annotations are non-identifying metadata.
They are used by external tools to help them to provide extra functionalities. However, there are no standard practices enforced. In this article, we attempted to provide a guideline that will serve as best practices when labeling and annotating Kubernetes objects.
Opinions expressed by DZone contributors are their own.