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.
Top comments (0)