K8S应用更新策略

艺帆风顺 发布于 2025-04-02 37 次阅读

一、简介

    Kubernetes（k8s）提供了多种更新策略，以适应不同场景下的应用程序更新需求。常见的Kubernetes更新策略有：1、滚动更新（Rolling Update）：这是最常见的更新策略。它允许逐步替换旧版本的Pod实例，确保应用程序在更新过程中保持可用。滚动更新适用于无状态应用，并且允许您指定更新速率和同时更新的Pod数量。2、蓝绿部署（Blue/Green Deployment）：蓝绿部署是一种在新旧版本之间进行切换的策略。在蓝绿部署中，您先部署一个全新的版本（绿色），然后在切换时将流量从旧版本（蓝色）切换到新版本。这种策略允许您在部署过程中立即回滚到旧版本，以应对意外问题。3、金丝雀发布（Canary Release）：金丝雀发布是一种渐进性更新策略。它允许您在生产环境中逐渐引入新版本的应用程序，只将少量流量路由到新版本，以评估其性能和稳定性。如果新版本稳定，可以逐渐增加流量份额，直至完全替换旧版本。4、滚动回滚（Rolling Rollback）：当滚动更新出现问题或新版本存在严重错误时，滚动回滚策略允许您回滚到之前的版本，以恢复到一个稳定的状态。5、逐一替换（Recreate）：逐一替换策略简单粗暴，它直接删除旧版本的Pod并创建新版本的Pod。这种策略会导致应用程序在更新过程中短暂的不可用，因为所有Pod都会同时停止和重新创建。

    二、实验测试

    1. 滚动更新

      简介：滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批 1 台，第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的

      实验：

        vim RollingUpdate.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: rollingupdate labels: name: rollingupdate annotations:  images.version.history: "v1:janakiramm/myapp:v1,v2:janakiramm/myapp:v2,v3:janakiramm/myapp:v3"spec: replicas: 3 selector: matchLabels: name: nginx strategy:    rollingUpdate: #滚动更新 maxSurge: 1 #最大增加一个pod      maxUnavailable: 0  #不允许减少pod，在生产中建议设置为0，防止剩余pod支撑不住过大流量 template: metadata: labels: name: nginx spec: containers: - name: nginx image: nginx:1.9.1 imagePullPolicy: IfNotPresent ports: - name: web containerPort: 80 protocol: TCP startupProbe: failureThreshold: 5 httpGet:  scheme: HTTP port: 80 path: / initialDelaySeconds: 20 timeoutSeconds: 20 periodSeconds: 5 livenessProbe: failureThreshold: 5 periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 20 httpGet: port: 80 scheme: HTTP path: / readinessProbe: failureThreshold: 5 periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 20 httpGet: port: 80 scheme: HTTP path: /测试：修改yaml中镜像重新更新资源菜单kubectl apply -f RollingUpdate.yaml查看更新动作(会发现会新创建成功一个删除一个)kubectl get pods -l name=nginx -owide -wNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESrollingupdate-56dc5f9cb8-2f5hh 1/1 Running 0 11m 10.247.66.129 lx120 none> none>rollingupdate-56dc5f9cb8-9n7zj 1/1 Running 0 11m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-mzhmt   1/1     Running   0          11m   10.247.66.135   lx120   none>           none>rollingupdate-9d84989b4-dp525 0/1 Pending 0 0s none> none> none> none>rollingupdate-9d84989b4-dp525 0/1 Pending 0 0s none> lx110 none> none>rollingupdate-9d84989b4-dp525 0/1 ContainerCreating 0 1s none> lx110 none> none>rollingupdate-7c9b8dfbb7-d85x8 0/1 Terminating 0 84s 10.247.66.148 lx120 none> none>rollingupdate-9d84989b4-dp525    0/1     ContainerCreating   0          1s    none>          lx110    none>           none>rollingupdate-9d84989b4-dp525 0/1 Running 0 2s 10.246.71.101 lx110 none> none>rollingupdate-9d84989b4-dp525 0/1 Running 0 21s 10.246.71.101 lx110 none> none>rollingupdate-9d84989b4-dp525 1/1 Running 0 21s 10.246.71.101 lx110 none> none>rollingupdate-56dc5f9cb8-2f5hh 1/1 Terminating 0 14m 10.247.66.129 lx120 none> none>rollingupdate-9d84989b4-s2ff8 0/1 Pending 0 0s none> none> none> none>rollingupdate-9d84989b4-s2ff8 0/1 Pending 0 0s none> lx120 none> none>rollingupdate-9d84989b4-s2ff8 0/1 ContainerCreating 0 0s none> lx120 none> none>rollingupdate-56dc5f9cb8-2f5hh 1/1 Terminating 0 14m 10.247.66.129 lx120 none> none>rollingupdate-9d84989b4-s2ff8 0/1 ContainerCreating 0 0s none> lx120 none> none>rollingupdate-56dc5f9cb8-2f5hh 0/1 Terminating 0 14m 10.247.66.129 lx120 none> none>rollingupdate-56dc5f9cb8-2f5hh 0/1 Terminating 0 14m 10.247.66.129 lx120 none> none>rollingupdate-56dc5f9cb8-2f5hh 0/1 Terminating 0 14m 10.247.66.129 lx120 none> none>rollingupdate-9d84989b4-s2ff8 0/1 Running 0 2s 10.247.66.147 lx120 none> none>rollingupdate-9d84989b4-s2ff8 0/1 Running 0 25s 10.247.66.147 lx120 none> none>rollingupdate-9d84989b4-s2ff8 1/1 Running 0 25s 10.247.66.147 lx120 none> none>rollingupdate-56dc5f9cb8-mzhmt 1/1 Terminating 0 15m 10.247.66.135 lx120 none> none>rollingupdate-9d84989b4-spwq9 0/1 Pending 0 0s none> none> none> none>rollingupdate-9d84989b4-spwq9 0/1 Pending 0 0s none> lx120 none> none>rollingupdate-9d84989b4-spwq9 0/1 ContainerCreating 0 0s none> lx120 none> none>rollingupdate-56dc5f9cb8-mzhmt 1/1 Terminating 0 15m 10.247.66.135 lx120 none> none>rollingupdate-9d84989b4-spwq9 0/1 ContainerCreating 0 1s none> lx120 none> none>rollingupdate-9d84989b4-spwq9 0/1 Running 0 2s 10.247.66.133 lx120 none> none>rollingupdate-56dc5f9cb8-mzhmt 0/1 Terminating 0 15m 10.247.66.135 lx120 none> none>rollingupdate-56dc5f9cb8-mzhmt 0/1 Terminating 0 15m 10.247.66.135 lx120 none> none>rollingupdate-56dc5f9cb8-mzhmt 0/1 Terminating 0 15m 10.247.66.135 lx120 none> none>rollingupdate-9d84989b4-spwq9 0/1 Running 0 21s 10.247.66.133 lx120 none> none>rollingupdate-9d84989b4-spwq9 1/1 Running 0 21s 10.247.66.133 lx120 none> none>rollingupdate-56dc5f9cb8-9n7zj 1/1 Terminating 0 15m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-9n7zj 0/1 Terminating 0 15m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-9n7zj 0/1 Terminating 0 17m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-9n7zj 0/1 Terminating 0 17m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-9n7zj 0/1 Terminating 0 17m 10.246.71.109 lx110 none> none>rollingupdate-56dc5f9cb8-9n7zj   0/1     Terminating         0          17m   10.246.71.109   lx110    none>           none>

        2.蓝绿部署

          简介蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。蓝色系统不对外提供服务，用来做什么呢？用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统蓝绿部署的优势和缺点优点：1、更新过程无需停机，风险较少2、回滚方便，只需要更改路由或者切换 DNS 服务器，效率较高缺点：1、成本较高，需要部署两套环境。如果新版本中基础服务出现问题，会瞬间影响全网用户。2、需要部署两套机器，费用开销大3、在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险4、负载均衡器/反向代理/路由/DNS 处理不当，将导致流量没有切换过来情况出现

          实验

            创建命名空间kubectl create ns lanlv创建绿色环境(原来的部署环境)vim lv.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: lv namespace: lanlvspec: replicas: 3 selector: matchLabels: app: lv template: metadata: labels: app: lv spec: containers: - name: lv image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80创建前端servicevim service_lanlv.yamlapiVersion: v1kind: Servicemetadata: name: myapp-lan-lv namespace: lanlv labels: app: myapp version: lanlvspec: type: NodePort ports: - port: 80 nodePort: 30062 name: http selector: name: myapp version: v1

            绿色界面：

              创建蓝色环境vim lan.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: lan namespace: lanlvspec: replicas: 3 selector: matchLabels: name: myapp version: v1 template: metadata: labels: name: myapp version: v1 spec: containers: - name: lan image: janakiramm/myapp:v1 imagePullPolicy: IfNotPresent ports: - containerPort: 80修改service_lanlv.yaml配置文件,让其匹配到蓝程序 selector: name: myapp version: v2将V1修改为V2

              打开新的无痕窗口进行测试

              3.金丝雀发布

                简介金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发 1 台，或者一个小比例，例如 2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。金丝雀发布的优缺点优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度(比如不同账号，不同参数)，出现问题不会影响全网用户缺点：没有覆盖到所有的用户导致出现问题不好排查

                实验

                  打开一个新标签监测更新过程kubectl get pods -l name=nginx -w新标签执行如下操作kubectl set image deployment rollingupdate nginx=janakiramm/myapp:v2 && kubectl rollout pause deployment rollingupdate解释：更新一个名字叫rollingupdate的Deployment对象中名叫nginx的容器的镜像版本，更新为janakiramm/myapp:v2kubectl set image deployment rollingupdate nginx=janakiramm/myapp:v2暂停更新名字叫rollingupdate的deploymentkubectl rollout pause deployment rollingupdate 

                  金丝雀pod运行成功

                    继续更新余下所有podkubectl rollout resume deployment rollingupdate