Kubernetes滚动更新及回滚

1、简介

当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有Pod,然后重新拉取镜像并启动。如果集群规模比较大，则这个工作就变成了一个挑战，而且先全部停止然后逐步升级的方式会导致长时间的服务不可用。Kubernetes提供了rolling-update滚动升级功能来解决上述问题。

2、实战-Deployment、ReplicationController、ReplicaSet

rs是一种控制器，可以让pod多副本。rc也可以让pod多副本。deployment也可以让pod多副本。

     -  rs是rc的升级版，以后rc就不用了。

rs和deploy的区别:

     -  deploy又是rs的升级版。

     -  rs只能做到的效果就是副本。

3、ReplicationController

 # 和rs一模一样。但是不支持复杂的matchLabel机制
 [root@yygh-de rollback]# kubectl explain rc.spec
 KIND:     ReplicationController
 VERSION: v1
 
 RESOURCE: spec <Object>
 
 DESCRIPTION:
     Spec defines the specification of the desired behavior of the replication
     controller. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
 
     ReplicationControllerSpec is the specification of a replication controller.
 
 FIELDS:
   minReadySeconds<integer>
     Minimum number of seconds forwhich a newly created pod should be ready
     without any of its container crashing, forit to be considered available.
     Defaults to 0(pod will be considered available as soon as it is ready)
 
   replicas<integer>
     Replicas is the number of desired replicas. This is a pointer to
     distinguish between explicit zero and unspecified. Defaults to 1. More
     info:
     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller
 
   selector<map[string]string>
     Selector is a label query over pods that should match the Replicas count.
     If Selector is empty, it is defaulted to the labels present on the Pod
     template. Label keys and values that must match inorder to be controlled
     by this replication controller, ifempty defaulted to labels on Pod
     template. More info:
     https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
 
   template<Object>
     Template is the object that describes the pod that will be created if
     insufficient replicas are detected. This takes precedence over a
     TemplateRef. More info:
     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

4、ReplicaSet

 [root@yygh-de rollback]# kubectl explain rs.spec
 KIND:     ReplicaSet
 VERSION: apps/v1
 
 RESOURCE: spec <Object>
 
 DESCRIPTION:
     Spec defines the specification of the desired behavior of the ReplicaSet.
     More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
 
     ReplicaSetSpec is the specification of a ReplicaSet.
 
 FIELDS:
   minReadySeconds<integer>
     Minimum number of seconds forwhich a newly created pod should be ready
     without any of its container crashing, forit to be considered available.
     Defaults to 0(pod will be considered available as soon as it is ready)
 # Kubernetes在等待设置的时间后才进行升级
 # 如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
 # 如果没有设置该值，在某些极端情况下可能会造成服务服务正常运行
   replicas<integer>
     Replicas is the number of desired replicas. This is a pointer to
     distinguish between explicit zero and unspecified. Defaults to 1. More
     info:
 # 保证的副本数     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
 
   selector<Object> -required-
     Selector is a label query over pods that should match the replica count.
     Label keys and values that must match inorder to be controlled by this
     replica set. It must match the pod template's labels. More info:
     https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
 
   template<Object>
     Template is the object that describes the pod that will be created if
     insufficient replicas are detected. More info:
     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

5、Deployment

 [root@yygh-de rollback]# kubectl explain deploy.spec
 KIND:     Deployment
 VERSION: apps/v1
 
 RESOURCE: spec <Object>
 
 DESCRIPTION:
     Specification of the desired behavior of the Deployment.
 
     DeploymentSpec is the specification of the desired behavior of the
     Deployment.
 
 FIELDS:
   minReadySeconds<integer>
     Minimum number of seconds forwhich a newly created pod should be ready
     without any of its container crashing, forit to be considered available.
     Defaults to 0(pod will be considered available as soon as it is ready)
 
   paused<boolean>
     Indicates that the deployment is paused.
 # 用于暂停记录部署版本信息
   progressDeadlineSeconds<integer>
     The maximum time inseconds fora deployment to makeprogress before it is
     considered to be failed. The deployment controller will continue to process
     failed deployments and a condition with a ProgressDeadlineExceeded reason
     will be surfaced inthe deployment status. Note that progress will not be
     estimated during the time a deployment is paused. Defaults to 600s.
 # 等待多少秒才能确定Deployment进程是卡住的。如果卡住，这次部署失败，并汇报自己状态，我们可以用kubectl describe查看原因，进行手动修复等
   replicas<integer>
     Number of desired pods. This is a pointer to distinguish between explicit
     zero and not specified. Defaults to 1.
 # 副本
   revisionHistoryLimit<integer>
     The number of old ReplicaSets to retain to allow rollback. This is a
     pointer to distinguish between explicit zero and not specified. Defaults to
     10.
 # 历史总记录数
   selector<Object> -required-
     Label selector forpods. Existing ReplicaSets whose pods are selected by
     this will be the ones affected by this deployment. It must match the pod
     template's labels.
 
   strategy<Object>
     The deployment strategy to use to replace existing pods with new ones.
 # 滚动更新策略
   template<Object> -required-
     Template describes the pods that will be created.

6、滚动更新策略

 [root@yygh-de rollback]# kubectl explain deploy.spec.strategy
 KIND:     Deployment
 VERSION: apps/v1
 
 RESOURCE: strategy <Object>
 
 DESCRIPTION:
     The deployment strategy to use to replace existing pods with new ones.
 
     DeploymentStrategy describes how to replace existing pods with new ones.
 
 FIELDS:
   rollingUpdate<Object>
     Rolling update config params. Present only ifDeploymentStrategyType =
     RollingUpdate.
 #     Recreate 全部重新创建
 #     RollingUpdate 拉起一个停一个
   type<string>
     Type of deployment. Can be "Recreate"or "RollingUpdate". Default is
     RollingUpdate.

7、rollingUpdate的两种方式

 [root@yygh-de rollback]# kubectl explain deploy.spec.strategy.rollingUpdate
 KIND:     Deployment
 VERSION: apps/v1
 
 RESOURCE: rollingUpdate <Object>
 
 DESCRIPTION:
     Rolling update config params. Present only ifDeploymentStrategyType =
     RollingUpdate.
 
     Spec to control the desired behavior of rolling update.
 
 FIELDS:
   maxSurge<string>
     The maximum number of pods that can be scheduled above the desired number
     of pods. Value can be an absolute number (ex: 5) or a percentage of desired
     pods (ex: 10%). This can not be 0ifMaxUnavailable is 0. Absolute number
     is calculated from percentage by rounding up. Defaults to 25%. Example:
     when this is setto 30%, the new ReplicaSet can be scaled up immediately
     when the rolling update starts, such that the total number of old and new
     pods donot exceed 130% of desired pods. Once old pods have been killed,
     new ReplicaSet can be scaled up further, ensuring that total number of pods
     running at any time during the update is at most 130% of desired pods.
 
   maxUnavailable<string>
     The maximum number of pods that can be unavailable during the update. Value
     can be an absolute number (ex: 5) or a percentage of desired pods (ex:
     10%). Absolute number is calculated from percentage by rounding down. This
     can not be 0ifMaxSurge is 0. Defaults to 25%. Example: when this is set
     to 30%, the old ReplicaSet can be scaled down to 70% of desired pods
     immediately when the rolling update starts. Once new pods are ready, old
     ReplicaSet can be scaled down further, followed by scaling up the new
     ReplicaSet, ensuring that the total number of pods available at all times
     during the update is at least 70% of desired pods.

8、rollingUpdate的两种方式yaml演示

8.1编写yaml

 [root@yygh-de rollback]# vim test.yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: frontend-test
 labels:
   app: guestbook
   tier: frontend
 spec:
  # modify replicas according to your case
 strategy:
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 2
 replicas: 6
 selector:
   matchLabels:
     tier: frontend-test
 template:
   metadata:
     labels:
       tier: frontend-test
   spec:
     containers:
      -name: php-redis
       image: tomcat:6

8.2查看服务

 [root@yygh-de rollback]# kubectl apply -f test.yaml 
 deployment.apps/frontend-test created
 [root@yygh-de rollback]# kubectl set image deployment.apps/frontend-test php-redis=tomcat:777
 [root@yygh-de rollback]# kubectl get pod
 NAME                             READY   STATUS             RESTARTS   AGE
 frontend-test-6f8656f964-8lt6p   0/1     ImagePullBackOff   0        25s
 frontend-test-6f8656f964-j2d7s   0/1     ImagePullBackOff   0        25s
 frontend-test-6f8656f964-jcx6p   0/1     ImagePullBackOff   0        25s
 frontend-test-c986f4d7c-5qjqt    1/1     Running            0        48s
 frontend-test-c986f4d7c-7wgjz    1/1     Running            0        48s
 frontend-test-c986f4d7c-lbl6l    1/1     Running            0        48s
 frontend-test-c986f4d7c-nxr7r    1/1     Running            0        48s
 [root@yygh-de rollback]# kubectl get deployment
 NAME           READY   UP-TO-DATE   AVAILABLE   AGE
 frontend-test   4/6     3           4          43s

9、滚动升级策略演示

滚动升级通过执行kubectl rolling-update命令一键完成，该命令创建了一个新的RC，然后自动控制旧的RC中的Pod副本数量逐渐减少到0，同时新的RC中的Pod副本的数量从0逐步增加到目标值，最终实现了Pod的升级。系统会要求新的RC和旧的RC在相同的命名空间下:

9.1编写yaml

 [root@yygh-de rollback]# vim abcdocker-test.yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: nginx-deployment
 spec:
 replicas: 6
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
      -name: nginx
       image: nginx:1.13.0-alpine
       imagePullPolicy: IfNotPresent
       ports:
        -containerPort: 80

9.2打标签

 [root@yygh-de rollback]# kubectl apply -f abcdocker-test.yaml --record

9.3运行的Pod副本数量有6个

 [root@yygh-de rollback]# kubectl get pod
 NAME                               READY   STATUS   RESTARTS   AGE
 nginx-deployment-7dbcbc677f-2f2dd   1/1     Running   0        5s
 nginx-deployment-7dbcbc677f-8hw96   1/1     Running   0        5s
 nginx-deployment-7dbcbc677f-lvlqr   1/1     Running   0        5s
 nginx-deployment-7dbcbc677f-ntjqh   1/1     Running   0        5s
 nginx-deployment-7dbcbc677f-qfgn6   1/1     Running   0        5s
 nginx-deployment-7dbcbc677f-zqbpz   1/1     Running   0        5s

10、Kubernetes的几种更新方式

10.1修改deployment文件进行更新

 [root@yygh-de rollback]# sed -i 's#1.13.0-alpine#1.10.0-alpine#g' abcdocker-test.yaml
 [root@yygh-de rollback]# kubectl apply -f abcdocker-test.yaml --record
 deployment.apps/nginx-deployment configured
 # --record的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。

10.2直接修改deployment进行更新镜像

deployment文件支持动态更新，我们使用edit参数可以直接更新deployment文件

 ^C[root@yygh-de rollback]# kubectl get deployment
 NAME               READY   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   6/6     6           6          6m42s
 [root@yygh-de rollback]# kubectl edit deployments nginx-deployment

不太推荐使用edit进行编辑，退出即保存，同时也会在我们的rollout里面产生一个版本号

10.3接下来是使用kubectl set命令进行替换镜像

 [root@yygh-de rollback]# kubectl set image deploy nginx-deployment nginx=nginx.13.0-alpine

11、使用rollout进行升级几种操作方式

11.2查看状态

 [root@yygh-de rollback]# kubectl rollout status deployment/nginx-deployment
 deployment "nginx-deployment"successfully rolled out

11.2暂停升级

 [root@yygh-de rollback]# kubectl rollout pause deployment deployment/nginx-deployment

11.3继续升级

 [root@yygh-de rollback]# kubectl rollout resume deployment deployment/nginx-deployment

11.4升级结束后，继续查看rs的状态

 [root@yygh-de rollback]# kubectl get rs
 # 根据AGE我们可以看到离我们最近的当前状态是：3，和我们的yaml文件是一致的，证明升级成功了。用describe命令可以查看升级的全部信息.

12、回滚Deployment

我们已经能够滚动平滑的升级我们的Deployment了，但是如果升级后的POD出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment就为我们提供了回滚机制

12.1查看Deployment的升级历史

 [root@yygh-de rollback]# kubectl rollout history deployment nginx-deployment
 deployment.apps/nginx-deployment 
 REVISION CHANGE-CAUSE
 2        kubectl apply --filename=abcdocker-test.yaml --record=true
 4        kubectl apply --filename=abcdocker-test.yaml --record=true
 5        kubectl apply --filename=abcdocker-test.yaml --record=true

12.2从上面的结果可以看出在执行Deployment升级的时候最好带上record参数，便于我们查看历史版本信息。同样我们可以使用下面的命令查看单个REVISION的信息

 [root@yygh-de rollback]# kubectl rollout history deployment nginx-deployment --revision=4
 deployment.apps/nginx-deployment with revision #4
 Pod Template:
 Labels:app=nginx
 pod-template-hash=678746dbb4
 Annotations:kubernetes.io/change-cause: kubectl apply --filename=abcdocker-test.yaml --record=true
 Containers:
   nginx:
   Image:nginx:1.10.0-alpine
   Port:80/TCP
   Host Port:0/TCP
   Environment:<none>
   Mounts:<none>
 Volumes:<none>

12.3假如现在要直接回退到当前版本的前一个版本

 [root@yygh-de rollback]# kubectl rollout undo deployment nginx-deployment

12.4当然也可以用revision回退到指定的版本

 [root@yygh-de rollback]# kubectl rollout undo deployment nginx-deployment --to-revision=5

如果文章有任何错误欢迎不吝赐教，其次大家有任何关于运维的疑难杂问，也欢迎和大家一起交流讨论。关于运维学习、分享、交流，笔者开通了微信公众号【运维猫】，感兴趣的朋友可以关注下，欢迎加入，建立属于我们自己的小圈子，一起学运维知识。群主还经营一家Orchis饰品店，喜欢的小伙伴欢迎????前来下单。

扫描二维码

获取更多精彩

运维猫公众号

有需要技术交流的小伙伴可以加我微信，期待与大家共同成长，本人微信：

扫描二维码

添加私人微信

运维猫博主

扫码加微信

最近有一些星友咨询我知识星球的事，我也想继续在星球上发布更优质的内容供大家学习和探讨。运维猫公众号平台致力于为大家提供免费的学习资源，知识星球主要致力于即将入坑或者已经入坑的运维行业的小伙伴。

点击阅读原文  查看更多精彩内容！！！