When you create a deployment or simply are new pod with Kubernetes, you are expected to add some metadata, like semantic information in form of labels or deployment annotations. That´s because the amount of pods you need to run might grow a lot and you need a way to search through them.
It´s a mechanism for organizing the dozens of resources you are going to have.
LABELS
Labels are key-value pairs used mainly for grouping and selecting purposes.
For instance, you can use them to add information about the environment, the team or area of responsibility involved, the version, etc.
labels are not the same as “selectors”, but you can use the “-l” options For both, if you want to retrieve a set of resources:
$ kubectl get pods -l app=flask
You get:
Name: flask
Namespace: default
CreationTimestamp: Sat, 16 Sep 2017 08:31:00 -0700
labels: pod-template-hash=866287979
run=flask
Annotations: deployment.kubernetes.io/revision=1
kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1beta1","kind":"deployment","metadata":{"annotations":{},"labels":{"run":"flask"},"name":"flask","namespace":"default"},"spec":{"t...
Selector: app=flask
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
pod Template:
labels: app=flask
etc.
If you create a deployment using “kubectl run”, the level “run=flask” is added automatically.
the command assigns the keys run, pod-template-hash, and app For specific meanings.
To get the label values in the information view, use “–show-labels”.
$ kubectl get pods --show-lables
To query labeled pods:
$ kubectl get pods -L run,pod-template-hash
$ kubectl get po -l creation_method=manual
$ kubectl get po -l '!env'
Notice that also the “not” operator (!) can be used.
You can add a label to an existing pod:
$ kubectl label po kubia-manual creation_method=manual
Or you can overwrite an existing one:
$ kubectl label po kubia-manual-v2 env=debug --overwrite
Assign a label by searching two or possible values:
$ kubectl label pod -l "type in (worker,runner)" protected=true
SELECTORS
Labels can be used in selectors:
$ kubectl get deployments.app --selector nl=spook
For example, to find all the deployments that have the label “app” set to “nginx”:
$ kubectl get all --selector="app=nginx" -o wide
FIELD SELECTORS
all The fields you see in the yaml files can be used for querying with the “field-selector” options like:
$ kubectl get pods --field-selector status.phase=Running
$ kubectl get pods --field-selector metadata.namespace!=jupiter
$ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
You can also use the metadata as environment variables with “fieldRef” in the manifest file:
spec:
containers:
- image: nginx
name: nginx
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
ANNOTATIONS
Annotations are used to provide additional information related to an instance. They are intended as descriptions and are very useful when it comes to checking a rollout history.
For example:
$ kubectl annotate pod redis description="this is doc"
This will be added to the metadata of your yaml file.
To set an annotation for the deployment history:
$ kubectl annotate deployment flask kubernetes.io/change-cause='deploying image 0.1.1'
deployment "flask" annotated
Now, if we look at the history, you will see the following displayed:
kubectl rollout history deployment/flask
deployments "flask"
REVISION CHANGE-CAUSE
1 <none>
2 deploying image 0.1.1
The second revision now has a “change-cause” entry.
It´s important to know that you annotate a group of resources that have the same labels, especially if you have a lot of pods:
$ kubectl annotate pod -l protected=true protected="do not delete this pod".
