Rolling Updates and Rollbacks¶

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¶

References¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: quay.io/nginx/nginx-unprivileged:1.28
          ports:
            - containerPort: 8080

oc apply -f deployment.yaml

oc get deployments

oc set image deployment/my-deployment nginx=quay.io/nginx/nginx-unprivileged:1.29

oc annotate deployment/my-deployment kubernetes.io/change-cause="Upgrade to nginx 1.29"

oc rollout status deployment/my-deployment

oc get rs

oc describe deployment my-deployment

oc rollout history deployment/my-deployment

oc rollout undo deployment/my-deployment

oc rollout undo deployment/my-deployment --to-revision=2

oc rollout pause deployment/my-deployment
oc rollout resume deployment/my-deployment

oc rollout restart deployment/my-deployment

oc delete deployment my-deployment

kubectl apply -f deployment.yaml

kubectl get deployments

kubectl set image deployment/my-deployment nginx=quay.io/nginx/nginx-unprivileged:1.29

kubectl annotate deployment/my-deployment kubernetes.io/change-cause="Upgrade to nginx 1.29"

kubectl rollout status deployment/my-deployment

kubectl get rs

kubectl describe deployment my-deployment

kubectl rollout history deployment/my-deployment

kubectl rollout undo deployment/my-deployment

kubectl rollout undo deployment/my-deployment --to-revision=2

kubectl rollout pause deployment/my-deployment
kubectl rollout resume deployment/my-deployment

kubectl rollout restart deployment/my-deployment

kubectl delete deployment my-deployment

Activities¶