K8S- Deployment 的滚动更新 Rolling Update

在这里插入图片描述

滚动更新

这里的更新指的不是更新deployment 本身的属性(label/ replicas)等, 而是更新POD 的container 的版本

更新方法通常有两种

  1. 是直接update deployment配置, 注意只有update了template中的内容(与container相关) 才会触发更新
  2. 用kubectl set image 命令




构造新版本的service

为了更好地测试,
我们构造1个新的版本的spring boot的service

更新很简单
直接更新pom里面的version就好, 由1.1.1 to 1.1.2

    <groupId>com.home</groupId>
    <artifactId>bq_api</artifactId>
    <version>1.1.2</version>
    <name>bq-api-service</name>

里面已经利用springboot actuator 构造了1个接口/actuator/info 可以获得当前版本

[gateman@manjaro-x13 ~]$ curl 127.0.0.1:8080/actuator/info
{
   
   "app":"Sales API","version":"1.1.2","description":"This is a simple Spring Boot application to demonstrate the use of BigQuery in GCP."}

当把docker image 推送到GAR后
可以用下面命令确认

[gateman@manjaro-x13 ~]$ gcloud artifacts docker images list europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo --include-tags
Listing items under project jason-hsbc, location europe-west2, repository my-docker-repo.

IMAGE                                                                 DIGEST                                                                   TAGS            CREATE_TIME          UPDATE_TIME          SIZE
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:30fb2cebd2bf82863608037ce41048114c061acbf1182261a748dadefff2372f                  2024-03-18T02:45:02  2024-03-18T02:45:02  366980350
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:55737b9c2efc7115d878c8b8b036dd0fe8ae5e66b2154fe05ba015b28a31c7aa  1.0.0           2024-03-18T01:40:34  2024-03-18T01:40:34  366980348
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:569397b5d13264988800ad5af15359b4ab085eaca209484e6d859fc2a9e6b6ab  1.1.1           2024-03-31T12:03:57  2024-03-31T12:03:57  366981699
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:648920b7aba0b5cdeeca9e1237d9eeb62ee29188801a95adf7619bcee94e9eb1                  2024-03-15T02:29:55  2024-03-15T02:29:55  367470655
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:6c4129c5a6938004b14cc555518b52a18e8177ce6940b52db7c514783ef9325b  1.1.2           2024-04-04T21:08:09  2024-04-04T21:08:09  366981681
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:7db14476085376db27a2814f8348fdbe002516c576d396c02030094c859f279c                  2024-03-15T20:51:58  2024-03-15T20:51:58  367470658
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:88c7f68df0dd0508b551d53ad22cf4395fea233b5e77be016f13ce9c8c4401fa                  2024-03-30T00:12:15  2024-03-30T00:12:15  366981231
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:a42cd0cd3a3483599b17d94022d1ccd234003491db217b4055f64997478149e1                  2024-03-15T00:03:21  2024-03-15T00:03:21  367470619
europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service  sha256:f1e5a8064b134aedd1a5840c16af85633e98a9649c830b6a3f6788a8b00bf16f                  2024-03-25T00:35:48  2024-03-25T00:35:48  366980337

可以看见到1.1.2 的image 已经在GAR了




update deployment配置 测试

先看当前的状态

root@k8s-master:~# kubectl get deploy -o wide --show-labels
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS                 IMAGES                                                                       SELECTOR             LABELS
bq-api-service-deploy-sample   10/10   10           10          3h27m   bq-api-service-container   europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service:1.1.1   app=bq-api-service   app=bq-api-service
root@k8s-master:~# kubectl get rs -o wide --show-labels
NAME                                     DESIRED   CURRENT   READY   AGE     CONTAINERS                 IMAGES                                                                       SELECTOR                                         LABELS
bq-api-service-deploy-sample-9f8d9c988   10        10        10      3h27m   bq-api-service-container   europe-west2-docker.pkg.dev/jason-hsbc/my-docker-repo/bq-api-service:1.1.1   app=bq-api-service,pod-template-hash=9f8d9c988   app=bq-api-service,pod-template-hash=9f8d9c988
root@k8s-master:~# kubectl get pods -o wide --show-labels
NAME                                           READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES   LABELS
bq-api-service-deploy-sample-9f8d9c988-25tqr   1/1     Running   0          3h27m   10.244.1.20   k8s-node1   <none>           <none>            app=bq-api-service,pod-template-hash=9f8d9c988
bq-api-service-deploy-sample-9f8d9c988-67psf   1/1     Running   0          3h27m   10.244.3.30   k8s-node3   <none>           <none>            app=bq-api-service,pod-template-hash=9f8d9c988
bq-api-service-deploy-sample-9f8d9c988-cvm4z   1/1     Running   0          3h27m   10.244.3.32   k8s-node3   <none>           <none>            app=bq-api-service,pod-template-hash=9f8d9c988
bq-api-service-deploy-sample-9f8d9c988-f77tx   1/1     Running   0          3h27m   10.244.1.23   k8s-node1   <none>           <none>            app=bq-api-service,pod-template-hash=9f8d9c988
bq-api-service-deploy-sample-9f8d9c988-f98s6   1/1     Running   0          3h27m   10.244.2.82   k8s-node0   <none>           <none>            
<think>好的,我现在需要帮助用户了解KubernetesDeployment滚动更新策略的配置和工作原理。用户之前询问了Pod的生命周期,现在转向Deployment滚动更新,这可能是因为他们正在学习Kubernetes的不同控制器和部署策略。根据用户提供的引用内容,特别是引用[1]和引用[2],里面提到了Deployment的工作原理、滚动更新策略以及回滚方法,这些内容需要整合到回答中。 首先,我需要明确用户的需求:他们想知道如何配置滚动更新策略以及其工作原理。因此,回答需要分两部分:配置方法和原理。同时,用户提供的引用中提到了一些关键点,比如maxSurge和maxUnavailable参数,以及回滚命令kubectl rollout undo,这些都需要包含在回答中。 接下来,我需要考虑用户可能的背景。他们可能已经了解Deployment的基本概念,但需要更深入的配置细节。因此,回答中需要详细解释每个参数的作用,例如maxSurge控制同时新增的Pod数量,maxUnavailable控制不可用Pod的最大数量。同时,可能需要提供一个YAML示例,让用户能够直观地看到如何配置这些参数。 关于工作原理部分,需要解释滚动更新的过程,包括如何逐步替换旧Pod,保持应用可用性。结合用户之前的问题中提到的Pod生命周期,可以联系到Pod的状态变化,比如新Pod启动时的健康检查(就绪探针)如何影响更新过程。此外,用户提到的引用[3]中关于Service和Endpoint的内容,说明Service如何关联Pod,因此在更新过程中,Endpoint会自动更新指向新的Pod,确保流量正确路由,这一点也需要在原理部分提到。 用户可能还关心如何验证和监控滚动更新的状态,因此需要介绍kubectl rollout status和kubectl get rs命令,这些帮助用户查看更新进度和副本集状态。此外,回滚是一个重要的故障恢复机制,用户提供的引用[2]中提到了kubectl rollout undo,需要详细说明如何使用该命令回滚到之前的版本,并查看历史记录。 另外,用户之前的回答中提到了健康检查机制(如就绪探针),在滚动更新过程中,这些探针的作用至关重要,因为新Pod必须通过就绪检查才能被纳入Service的Endpoint,否则更新会被阻塞。这需要在原理部分强调,确保用户理解健康检查与滚动更新的关联。 最后,需要考虑用户可能的应用场景,比如生产环境中的蓝绿部署或金丝雀发布,但用户当前的问题是滚动更新,因此可能需要简要提及这些策略的不同,但主要聚焦在滚动更新。不过用户提供的引用[1]中提到了蓝绿和金丝雀发布,可能用户后续会问到这些问题,所以相关问题部分可以包含这些内容,引导用户进一步探索。 总结回答结构:先概述滚动更新的作用,然后分配置方法和工作原理两部分详细说明,包括参数解释、YAML示例、更新流程步骤,最后介绍监控和回滚操作,以及相关问题的延伸。</think>### Kubernetes Deployment滚动更新策略详解 #### 一、滚动更新核心机制 滚动更新Rolling Update)是Deployment控制器默认的更新策略,通过**渐进式替换Pod**实现零停机(Zero Downtime)的版本迭代。其核心目标是在保证服务可用性的前提下完成应用升级,具体通过以下两个参数控制更新节奏: - `maxSurge`:允许超出期望副本数的最大Pod数量(例如30%或固定值) - `maxUnavailable`:更新过程中允许不可用Pod的最大比例(例如25%或0)[^1][^2] --- #### 二、配置滚动更新策略 ##### 1. **参数定义示例(YAML)** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: strategy: type: RollingUpdate # 滚动更新策略(默认) rollingUpdate: maxSurge: 25% # 允许同时新增25%的Pod(如总副本4,最多同时启动5个) maxUnavailable: 0 # 更新期间必须保证所有旧Pod可用(严格零停机) replicas: 4 template: spec: containers: - name: nginx image: nginx:1.25 ``` ##### 2. **关键参数解析** | 参数 | 作用场景 | 典型值 | |--------------------|------------------------------------------------------------------------|-------------------| | `maxSurge` | 控制新Pod的创建速度,避免瞬间资源压力 | 25%、1(绝对值) | | `maxUnavailable` | 限制旧Pod的删除速度,确保服务最小可用容量 | 0(高可用场景) | --- #### 三、滚动更新工作原理 ##### 1. **更新流程** 1. **创建新ReplicaSet**:当镜像版本或配置变更时,Deployment生成新ReplicaSet(RS)[^1]。 2. **按策略扩容/缩容**: - 根据`maxSurge`逐步启动新Pod(如总副本4,`maxSurge=25%`时,新RS先启动1个Pod)。 - 根据`maxUnavailable`逐步终止旧Pod(若`maxUnavailable=0`,每启动1个新Pod后才会终止1个旧Pod)。 3. **健康检查**:新Pod必须通过`readinessProbe`才会被加入Service的Endpoint列表[^3]。 4. **完成替换**:旧RS缩容至0,新RS接管所有流量。 ##### 2. **流量切换逻辑** - Kubernetes的Service通过Label Selector动态关联Pod,更新过程中Endpoint列表会实时更新新Pod的IP[^3]。 - 旧Pod在终止前会完成**优雅关闭**(处理完现有请求再退出)。 --- #### 四、操作实践 ##### 1. **触发更新** ```bash kubectl set image deployment/nginx-deployment nginx=nginx:1.25 ``` ##### 2. **监控更新状态** ```bash kubectl rollout status deployment/nginx-deployment # 实时查看进度 kubectl get rs # 观察新旧ReplicaSet的副本分布 ``` ##### 3. **回滚操作** 若更新后出现异常,可快速回滚到上一版本: ```bash kubectl rollout undo deployment/nginx-deployment # 回滚到最近一次版本[^2] kubectl rollout history deployment/nginx-deployment # 查看历史版本记录 ``` --- #### 五、生产环境注意事项 - **严格定义就绪探针**:避免新Pod未完全初始化就被接入流量。 - **灰度验证**:结合金丝雀发布逐步验证新版本(先更新少量Pod)。 - **资源预留**:`maxSurge`需根据节点资源余量设置,防止资源争抢导致更新卡顿[^1]。 --- ### 相关问题 1. **如何通过`kubectl`命令直接修改滚动更新参数而不编辑YAML文件?** 2. **如果滚动更新过程中出现Pod启动失败,Deployment会如何处理?** 3. **蓝绿部署与滚动更新在流量切换机制上有何本质区别?**[^1] [^1]: Deployment控制器通过ReplicaSet管理Pod版本迭代,滚动更新是其默认策略 [^2]: 使用`kubectl rollout undo`可快速回滚到上一个稳定版本 [^3]: Service通过Endpoint动态关联健康Pod,确保流量无缝切换
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

nvd11

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值