pod 升级与回滚

 pod 升级方式：

1、删掉旧pod,在部署新pod.

2、创建新pod,通过修改service选择器后删除旧pod

3、滚动式升级  rolling-update

4、使用deployment声明方式升级

前两者不在详述，都需要中断业务。

kubectl 滚动式升级：

实验：

      定义kubia-v1 YAML 文件创建POD 和service

apiVersion: v1

kind: ReplicationController

metadata:

  name: kubia-v1

spec:

  replicas: 3

  template:

    metadata:

      name: kubia

      lebels:

         app: kubia

    spec:

      containers:

      - images: luksa/kubia:v1

        name: nodejs

---

apiVersion: v1

kind: service

metadata:

  name: kubia-v1

spec:

  type: LoadBalancer

  selector:

     app: kubia

  ports:

  - port: 80 

    targetPort: 8080

使用 kubia-v2替换kubia-v1 

kubectl  rolling-update  kubia-v1 kubia-v2 --image=luksa/kubia:v2 #执行替换命令.一个新的rc会被创建，初始副本为0。

kubectl describe rc kubia-v2  #查看kubia-v2的RC

随着kubectl继续滚动升级，开始看到越来越多的请求被切换到v2 pod,v1的pod 不断的被删除。

rolling-update的方式升级需要执行 kubectl 命令，如果在升级过程中失去网络连接升级进程会将中断。 rolling-update是一种淘汰的升级方式。

deployment 声明式升级

    deployment用于部署应用程序并已声明的方式升级应用、而不是通过RC,RS进行部署。

    使用deployment时，实际上pod是由deployment的replicaset创建和管理的，不是由deployment直接创建和管理。

deployment也是由标签选择器、期望副本数和pod模本组成，此外还包含一个字段指定一个部署策略，该策略定义在修改deployment资源时应该如何执行更新。

创建一个deployment yaml 文件

apiVersion: apps/v1beta1   #deployment属于apps api组，版本为v1beta1

kind: Deployment         #kind 名称为Deployment

metadata: 

  name: kubia            #deployment名称中不在需要版本号

spec:

  replicas: 3

  template:

    metadata:

      name: kubia

      labels:

        app: kubia

    spec:

      contaoners:

      - image: luksa/kubia:v1

        name: nodejs

 

kubectl  create -f  kubia-deployment.yaml --record #创建deployment， --record 参数会记录历史版本号。

可以同过kubectl get deployment 和 kubectl describe deployment 查看详细信息。

kubectl rollout status deployment kubia  #查看 kubia的部署状态。

 

deployment 升级策略：

1、滚动式升级（rollingupdate）

2、recreate （逐渐删除旧pod,逐渐创建新pod)

           要触发升级，只需要修改deployment的yaml 文件即可。

            kubectl set image deployment kubia nodejs=lunksa/kubia:v2   #这条命名会将模板里的镜像修改为lunksa/kubia:v2 （新版本）修改完成后会开始滚动升级。

修改deployment或者其他资源的不同方式：

方法	作用
Kubectl  edit	使用默认编辑器打开资源配置，修改保存并退出编辑器 例： kubectl edit deployment  kubia
Kubectl  patch	修改单个资源属性 例：kubectl patch deployment kubia -p ‘{“spec”:{template”:{“spec”:{“containers”:[{“name”: “nodejs”,”image”:”luksa/kubia:v2}]}}}
Kubectl  apply	通过一个完整的yaml或json 文件，应用其中新的值来修改对象，如果yaml或json中指定的对象不存在，则会被创建。该文件需要包含资源的完整定义，（不能像 kubectl patch 那样只创建想要更新的字段） 例：kubectl apply -f kubia-deployment-v2.yaml
Kubectl replace	将原有对象替换为YAML、JSON文件中定义的新对象，与apply命令相反，运行这个命令要求对象必须存在，否则报错。 Kubectl replace -f  kubia-deployment-v2.yaml
Kubectl setimage	修改Pod、RS、RC、 Deployment 、DemonSet 、Job内的镜像 例：kubectl  set image  deploymen kubia nodejs=luksa/kubia:v2

回滚升级：

     Kubectl  rollout undo deployment kubia  #回滚到上一个版本

     Kubectl   rollout  history deployment kubia # 查看kubia 历史版本

     Kubectl rollout undo deployment kubia —to-revision=1 #回滚到指定版本

暂停滚动升级：

    如果想让新版和旧版pod混合运行、看看新版pod运行是否正常则在执行升级几秒后在执行暂停升级命令。

    kubectl rollout pause deployment kubia

恢复滚动升级：

     确认了刚才新版没有问题，可以继续升级替换所以旧版本pod，可以执行恢复升级命令。

     kubectl rollout resume deployment kubia 

取消出错滚动升级 :

    kubectl describe deploy kubia # 查看deployment的详细情况。

    如果出现ProgressDeadlineExceeded记录，则表示完成滚动升级时间太久。

    可通过设定Deployment  spec 中使用 progressDeadlineSeconds来指定时间。

    因为错误滚动升级不能在继续，所以执行下面命令取消升级。

    kubectl rollout undo deployment kubia