Labels, Selectors and Annotations

Labels

Labels are key/value pairs that are attached to objects, such as pods. Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using annotations.

Here is an example on how to create a pod using kubectl and add a label to it

kubectl run test_pod --image=nginx --restart=Never --labels="country=united_kingdom" --dry-run -o yaml'

which results in the following yaml file

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    country: united_kingdom
  name: test_pod
spec:
  containers:
  - image: nginx
    name: test_pod
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

Selectors

Unlike names and UIDs, labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).

Via a label selector, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.

Here is an example of a nodeSelector which selects nodes with the label accelerator=nvidia-tesla-p100:

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Annotations

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata.

For example, here’s the configuration file for a Pod that has the annotation imageregistry: https://hub.docker.com/:

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

Deployments

A deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state and the deployment controller changes the actual state to the desired state at a controlled rate.

To create a deployment you can run:

kubectl create deployment my-dep --image=busybox

or create using a file using kubectl create -f <path_to_file.yaml>

The following is the resulting yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: test
  name: test
spec:
  replicas: 1
  selector:
    matchLabels: <----- defines how the Deployment finds which Pods to manage
      app: test
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: test
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

Rolling updates

We can do a rolling deployment update using
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record command, which results in the following output: deployment.apps/nginx-deployment image updated

Another way is to run kubectl edit deployment <my_dep_name> and update the image manually.

Once an update command is issued, we can keep track using kubectl rollout status deployment/<my_dep_name>

We can check status of rollout using kubectl rollout status deployment/<my_dep_name> or check history using kubectl rollout history deployment/<my_dep_name>.

Rollbacks

We can roll back a deployment using kubectl rollout undo deployment/<my_dep_name>

Jobs

A Job creates one or more pods and ensures that a specified number of them successfully terminate.

We can create a job using kubectl create job myjob --image=nginx --dry-run -o yaml -- /bin/sh -c 'echo hello;sleep 100;' which results in the following job being created:

apiVersion: batch/v1
kind: Job
metadata:
  creationTimestamp: null
  name: myjob
spec:
  template:
    metadata:
      creationTimestamp: null
    spec:
      containers:
      - command:
        - /bin/sh
        - -c
        - echo hello;sleep 100;
        image: nginx
        name: myjob
        resources: {}
      restartPolicy: Never
status: {}

Once created we can use kubectl describe job myjob and do kubectl get pods to get the list of running pods for that job.

# CronJob

A Cron Job creates a time-based schedule.