4

Rolling Updates & Rollbacks

 3 years ago
source link: https://www.briansdevblog.com/2021/06/ckad-prep-part-13-rolling-updates-rollbacks/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Rolling Updates & Rollbacks

Rolling updates provide a mechanism for updating containers in a cluster without downtime. This powerful Kubernetes feature allows you to update containers while maintaining high availability.

To see this in action we’ll create a

Deployment
Deployment consisting of 3 nginx Pods using the definition below. Note that the container image we’re going to run is
library/nginx:1.20.0
library/nginx:1.20.0.
apiVersion: apps/v1
kind: Deployment
metadata:
name: rolling-update-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: library/nginx:1.20.0
imagePullPolicy: IfNotPresent
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: library/nginx:1.20.0
          imagePullPolicy: IfNotPresent

Run

kubectl apply -f rolling-update-deployment.yaml
kubectl apply -f rolling-update-deployment.yaml to create the
Deployment
Deployment.  A quick listing will show 3 Pods running as follows.

Rolling Update

Now we’re going to use the

kubectl set image
kubectl set image command to perform a rolling update that will replace the 3 Pods running
library/nginx:1.20.0
library/nginx:1.20.0, with 3 new Pods running
library/nginx:1.21.0
library/nginx:1.21.0.  Kubernetes will perform these updates incrementally to ensure service availability is maintained.

The full command is

kubectl set image deployment/rolling-update-deployment nginx=nginx:1.21.0 --record
kubectl set image deployment/rolling-update-deployment nginx=nginx:1.21.0 --record.
  • deployment/rolling-update-deployment
    deployment/rolling-update-deployment is the name of the
    Deployment
    Deployment we want to update
  • nginx=nginx:1.21.0
    nginx=nginx:1.21.0 is the name of the container followed by the new image we want to run
  • --record
    --record tells Kubernetes to record the update information so that it can be used to roll back the update later, if needs be

After running the above command you can run

kubectl get pods -w
kubectl get pods -w to tail the Pod activity in the default namespace.

The screenshot above shows new Pods being stood up and the existing Pods being terminated. Note that existing Pods aren’t terminated until a replacement is running.

Rollbacks

Rollbacks allow you to revert changes by rolling back to a previous cluster state. The 

rollout history
rollout history command displays a list of previous updates. For example,
rollout history deployment/rolling-update-deployment
rollout history deployment/rolling-update-deployment.

To see detail for a specific deployment use the

--revision
--revision flag as follows. 
rollout history deployment/rolling-update-deployment --revision 2
rollout history deployment/rolling-update-deployment --revision 2 displays detail associated with revision 2.

To undo the last revision use the

kubectl rollout undo
kubectl rollout undo command. For example,
kubectl rollout undo deployment/rolling-update-deployment
kubectl rollout undo deployment/rolling-update-deployment. If you want to roll back to a specific revision you can use the
--to-revision=<revision_number>
--to-revision=<revision_number>, for example,
kubectl rollout undo deployment/rolling-update-deployment --to-revision=2
kubectl rollout undo deployment/rolling-update-deployment --to-revision=2

Rolling Update Strategy

Kubernetes allows you to control the minimum and maximum number of pods that will run as part of a rolling update or roll back, using

strategy.rollingUpdate
strategy.rollingUpdate. The
maxSurge
maxSurge attribute indicates the maximum number of Pods that should be created. In the
Deployment
Deployment below,
maxSurge
maxSurge is set at 50% which means that Kubernetes will not create more than 50% additional Pods as part of a rolling update. The
Deployment
Deployment specifies 4 Pod replicas by default, so no more than 6 Pods will ever run as part of a rolling update.

Similarly

maxUnavailable
maxUnavailable tells Kubernetes the maximum number of Pods that can be unavailable during a rolling update. In the
Deployment
Deployment below
maxUnavailable
maxUnavailable is set at 50% which means that Kubernetes will not allow the maximum unavailable Pods to fall below 50% of the specified number of replicas. Given that the
Deployment
Deployment specifies 4 Pod replicas, no more than 2 Pods will ever be unavailable as part of a rolling update.

Note that both

maxSurge
maxSurge and
maxUnavailable
maxUnavailable can be specified as a percentage of the number of Pod replicas, or as an absolute value.
apiVersion: apps/v1
kind: Deployment
metadata:
name: rolling-update-deployment
spec:
replicas: 4
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 50%
maxUnavailable: 50%
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: library/nginx:1.20.0
imagePullPolicy: IfNotPresent
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: library/nginx:1.20.0
          imagePullPolicy: IfNotPresent

The sample code for these notes is available on Github.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK