Pod Design

Labels, Selectors, and Annotations¶

Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object.

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

You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify and select objects. The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels.

Resources¶

OpenShift - CLI Label Commands

IKS - Labels - Annotations

References¶

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: foo
    tier: frontend
    env: dev
  annotations:
    imageregistry: "https://hub.docker.com/"
    gitrepo: "https://github.com/csantanapr/knative"
spec:
  containers:
  - name: app
    image: bitnami/nginx

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: app
      image: busybox
  nodeSelector:
    disk: ssd

oc label <objectname>

oc get pods --show-labels

oc get pods -L tier,env

oc get pods -l app

oc get pods -l tier=frontend

oc get pods -l 'env=dev,tier=frontend'

oc get pods -l 'env in (dev, test)'

oc get pods -l 'tier!=backend'

oc get pods -l 'env,env notin (prod)'

kubectl create -f pod.yaml

kubectl apply -f pod.yaml

kubectl edit pod myapp-pod

kubectl get pods --show-labels

kubectl get pods -L tier,env

kubectl get pods -l app

kubectl get pods -l tier=frontend

kubectl get pods -l 'env=dev,tier=frontend'

kubectl get pods -l 'env in (dev, test)'

kubectl get pods -l 'tier!=backend'

kubectl get pods -l 'env,env notin (prod)'

kubectl delete pod myapp-pod

Deployments¶

A Deployment provides declarative updates for Pods and ReplicaSets.

You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

The following are typical use cases for Deployments: - Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not. - Declare the new state of the Pods by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment. - Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment. - Scale up the Deployment to facilitate more load. - Pause the Deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout. - Use the status of the Deployment as an indicator that a rollout has stuck. - Clean up older ReplicaSets that you don’t need anymore.

Resources¶

OpenShift

• Deployments
• Managing Deployment Processes
• DeploymentConfig Strategies
• Route Based Deployment Strategies

IKS

• Deployments
• Scaling Deployments

References¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: bitnami/nginx:1.16.0
        ports:
        - containerPort: 8080

oc apply -f <deploymentYAML>

oc get deploy my-deployment

oc describe deployment my-deployment

oc edit deployment my-deployment

oc scale deployment/my-deployment --replicas=4

oc delete my-deployment

kubectl apply -f <deploymentYAML>

kubectl get deployment my-deployment

kubectl describe deployment my-deployment

kubectl edit deployent my-deployment

kubectl scale deployment/my-deployment --replicas=4

kubectl delete my-deployment

Deployments rolling updates and rollback¶

Updating a Deployment A Deployment’s rollout is triggered if and only if the Deployment’s Pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.

Each time a new Deployment is observed by the Deployment controller, a ReplicaSet is created to bring up the desired Pods. If the Deployment is updated, the existing ReplicaSet that controls Pods whose labels match .spec.selector but whose template does not match .spec.template are scaled down. Eventually, the new ReplicaSet is scaled to .spec.replicas and all old ReplicaSets is scaled to 0.

Label selector updates It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front. In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped all of the implications.

Rolling Back a Deployment Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping. By default, all of the Deployment’s rollout history is kept in the system so that you can rollback anytime you want (you can change that by modifying revision history limit).

A Deployment’s revision is created when a Deployment’s rollout is triggered. This means that the new revision is created if and only if the Deployment’s Pod template (.spec.template) is changed, for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment, do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling. This means that when you roll back to an earlier revision, only the Deployment’s Pod template part is rolled back.

Resources¶

OpenShift

• Rollout
• Rolling Back

IKS

• Updating a Deployment
• Rolling Back a Deployment

References¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: bitnami/nginx:1.16.0
        ports:
        - containerPort: 8080

oc get deployments

oc set image deployment/my-deployment nginx=nginx:1.16.1 --record

oc get rs

oc describe deployment my-deployment

oc rollout status my-deployment

oc rollout history deployment my-deployment

oc rollback my-deployment

kubectl get deployments

kubectl set image deployment/my-deployment nginx=nginx:1.16.1 --record

kubectl get rs

kubectl describe deployment my-deployment

oc rollout status my-deployment

kubectl rollout history deployment my-deployment

kubectl rollout undo deployment my-deployment

Jobs and CronJobs¶

Jobs A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.

CronJobs One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.

All CronJob schedule: times are based on the timezone of the master where the job is initiated.

Resources¶

OpenShift - Jobs - CronJobs

IKS - Jobs to Completion - Cron Jobs - Automated Tasks with Cron

References¶

It computes π to 2000 places and prints it out

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Running in parallel

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 2
  completions: 3
  template:
    spec:
      containers:
        - name: pi
          image: perl
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

oc get jobs

oc describe job pi

oc get pods

oc delete job pi

oc get cronjobs

oc describe cronjobs pi

oc get pods

oc delete cronjobs pi

kubectl get jobs

kubectl describe job pi

kubectl get pods

kubectl delete job pi

kubectl get cronjobs

kubectl describe cronjobs pi

kubectl get pods

kubectl delete cronjobs pi

Activities¶