Deployment 介绍-更新-回滚-扩缩容HPA

介绍

用于部署无状态的服务,如Web服务、API服务等。它提供了应用程序的副本管理、自动扩展、滚动升级等功能。具体来说,Deployment通过ReplicaSet实现副本管理,确保指定数量的Pod副本正在运行,并处理Pod的创建、删除和更新。此外,Deployment还可以实现无缝迁移、自动扩容缩容、自动灾难恢复以及一键回滚等功能

Deployment 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  progressDeadlineSeconds: 600 # 用于定义Deployment升级过程中的最大时间。具体来说,如果Deployment的升级过程超过了这个时间还没有完成,那么Kubernetes会判断该Deployment进程已经卡住,并可能会进行回滚或其他相应的操作
  revisionHistoryLimit: 10 # 默认保留RS旧的revision的个数
  strategy:
    rollingUpdate:
      maxSurge: 25% # 可以超过期望值的最大Pod数,可选字段,默认为25%,可以设置成数字或百分比,如果该值为0,那么maxUnavailable不能为0
      maxUnavailable: 25% # 指定在回滚或更新时最大不可用的Pod的数量,可选字段,默认25%,可以设置成数字或百分比,如果该值为0,那么maxSurge就不能为0
    type: RollingUpdate # 更新deployment的方式,默认是RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

yaml 关键字解释

  • revisionHistoryLimit: 10 # 默认保留RS旧的revision的个数
  • progressDeadlineSeconds: 600 # 用于定义Deployment升级过程中的最大时间。具体来说,如果Deployment的升级过程超过了这个时间还没有完成,那么Kubernetes会判断该Deployment进程已经卡住,并可能会进行回滚或其他相应的操作。
  • maxSurge: 25% # 可以超过期望值的最大Pod数,可选字段,默认为25%,可以设置成数字或百分比,如果该值为0,那么ma
<think>嗯,用户询问Kubernetes的滚动更新回滚操作,这正好在我刚才看到的知识点里。用户提供的引用材料非常详细,完全覆盖了原理、操作示例,让我可以有针对性地回答。滚动更新的工作原理很清晰,就是通过Deployment控制Pod逐步替换,KubernetesService会自动将流量指向新版本Pod。这个过程中有个关键点需要注意,就是maxSurgemaxUnavailable这两个参数,它们控制着更新速度稳定性。用户可能会关心实际配置值,我准备用个20%的示例来说明。回滚操作其实更简单,主要依赖kubectlrollouthistoryundo命令。用户应该注意到每次变更都会产生Revision记录,回滚就是切换到这个历史版本。材料里提到的比例放很有意思,自动放时新旧版本Pod会按比例分配副本数,这个优化策略值得强调。配置示例部分,我考虑把健康检查一起写进去,因为实际业务中这个配置往往更新策略关联。LivenessReadiness探针的配置差异需要解释清楚,特别是timeoutSeconds这些调优参数,用户在生产环境可能会遇到相关问题。用户引用材料里有个小细节提到kubectlsetimage,这个命令可能比修改整个YAML更便捷,应该单独作为快速更新方案推荐。考虑到用户可能是运维人员,命令行操作要给出具体示例。最后突然想到,用户之前的问题历史显示对基础概念比较熟悉,所以回答可以适当深入些。比如比例放的实现机制,或者健康检查失败导致的更新阻塞问题,这些实战经验对用户应该很有价值。</think> 好的,在 Kubernetes 中实现**滚动更新(Rolling Update)****回滚(Rollback)**操作主要通过对 `Deployment` 资源进行配置管理来实现。以下是详细的实现方式配置示例: **核心概念:`Deployment`** `Deployment` 是 Kubernetes 中声明式管理 Pod ReplicaSet 的主要资源对象。它定义了应用程序应运行的 Pod 模板以及所需副本数,并提供了滚动更新回滚功能的核心机制。 **一、实现滚动更新 (Rolling Update)** 滚动更新是一种逐步用新版本 Pod 替换旧版本 Pod 的策略,旨在实现零停机或最小化服务中断的更新。 1. **配置策略 (`strategy`):** 在 `Deployment` 的 `.spec.strategy` 字段中明确指定 `type: RollingUpdate` 并配置其参数。 2. **控制参数:** * `.spec.strategy.rollingUpdate.maxSurge`: (可选,默认为 25%) 更新过程中最多可以创建的超出期望副本数的 Pod 数量(绝对值或百分比)。例如 `maxSurge: 2` 或 `maxSurge: 20%`。这允许在新 Pod 启动时保持服务能力。 * `.spec.strategy.rollingUpdate.maxUnavailable`: (可选,默认为 25%) 更新过程中最多允许多少 Pod 不可用(绝对值或百分比)。例如 `maxUnavailable: 1` 或 `maxUnavailable: 10%`。这控制着服务可能的最小量。 3. **触发更新:** * **修改 Pod 模板 (`spec.template`)**: 最常见的方式是更新容器镜像标签(如 `nginx:1.16.1` -> `nginx:1.17.0`)、修改环境变量、调整资源请求/限制等。任何对 `spec.template` 部分的修改都会触发滚动更新。 * **命令行直接修改镜像**: 使用 `kubectl set image` 命令快速更新指定容器镜像: ```bash kubectl set image deployment/<deployment-name> <container-name>=<new-image>:<tag> # 示例 kubectl set image deployment/nginx-deployment nginx=nginx:1.17.0 ``` * **编辑 Deployment YAML 并重新应用**: ```bash kubectl edit deployment <deployment-name> # 修改 `spec.template.spec.containers[].image` kubectl apply -f deployment.yaml # 若修改的是文件则用这个 ``` 4. **更新过程行为:** * 检测到 Pod 模板变化后,Deployment Controller 会创建一个包含新 Pod 模板的 **新 ReplicaSet**。 * 逐步增加新 ReplicaSet 的副本数 (`.spec.replicas + maxSurge` 约束),同时减少旧 ReplicaSet 的副本数 (`.spec.replicas - maxUnavailable` 约束)。 * 通过 `kubectl get pods -w` 或 `kubectl rollout status deployment/<deployment-name>` 观察实时更新状态。 * Kubernetes `Service` 基于 `selector` 标签路由流量。由于 `Service` 的 `selector` 通常与 `Deployment` 的 `podTemplate` 中的标签一致(旧新 Pod 都有这些标签),流量会自动从旧 Pod 引流到新 Pod。[^1] * 更新完成时,新 ReplicaSet 的副本数达到期望值,旧 ReplicaSet 的副本数变为 0(但仍保留历史记录用于回滚)。 **滚动更新示例 Deployment YAML** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 最多同时运行 4 个 Pod (3 desired + 1 surge) maxUnavailable: 0 # 确保至少 3 个 Pod 始终可用(或 1 允许少量降级) template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.16.1 # 触发更新时修改此镜像标签 ports: - containerPort: 80 # 健康检查建议配置 livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 15 periodSeconds: 10 readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5 ``` **二、实现回滚 (Rollback)** 如果滚动更新导致应用出现问题,可以快速回滚到之前的稳定版本。 1. **查看历史版本 (`rollout history`):** 列出 Deployment 的所有更新修订记录(Revision)。 ```bash kubectl rollout history deployment/<deployment-name> # 示例 kubectl rollout history deployment/nginx-deployment ``` 默认可能看不到修改原因。如果需要详细原因,在更新时加上 `--record=true` 标记(`kubectl apply/set image --record`)或者在 Deployment YAML 的注解中添加 `kubernetes.io/change-cause`。 2. **查看特定版本详情:** 查看某个 Revision 的具体更改信息。 ```bash kubectl rollout history deployment/<deployment-name> --revision=<revision-number> # 示例 kubectl rollout history deployment/nginx-deployment --revision=2 ``` 3. **执行回滚 (`rollout undo`):** 回滚到上一个版本或指定历史版本。 * **回滚到上一版本:** ```bash kubectl rollout undo deployment/<deployment-name> # 示例 kubectl rollout undo deployment/nginx-deployment ``` * **回滚到指定版本 (`--to-revision`):** ```bash kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number> # 示例(回滚到 Revision 1) kubectl rollout undo deployment/nginx-deployment --to-revision=1 ``` 4. **回滚过程行为:** 回滚操作本质上是一次新的滚动更新Deployment Controller 会找到目标 Revision 的 Pod 模板(相当于旧模板),然后逐步替换当前 ReplicaSet 的 Pod(可能处于问题状态)为目标 Revision 的 Pod 模板(稳定状态)。回滚过程中的行为同样遵循 `maxSurge` `maxUnavailable` 策略[^4]。 **重要注意事项** * **健康检查(Readiness/Liveness Probes)**: 强烈建议在 Pod 模板中配置 `readinessProbe` `livenessProbe`。`readinessProbe` 确保新 Pod *准备好接收流量前*不会加入 Service 端点列表,防止用户请求被发送到未初始化完成的 Pod。`livenessProbe` 在 Pod 进入非预期状态时重启它,辅助滚动更新的顺利进行。这是保证滚动更新期间服务稳定性的关键。[^1] * **比例放(Proportional Scaling)**: 如果在滚动更新过程中(或暂停期间)发生了水平 Pod 自动放(HPA),Kubernetes 会按比例分配副本到*活跃*的 ReplicaSet(旧的新的),而不是只针对旧版或只针对新版扩容。这有助于在并行处理更新放时维持服务的整体稳定性资源平衡[^4]。 * **暂停与恢复 (`rollout pause/resume`):** 可以在复杂的多步骤更新中使用 `kubectl rollout pause deployment/<name>` 暂停滚动更新,进行中间步骤的配置或检查。完成后,使用 `kubectl rollout resume deployment/<name>` 恢复更新过程。[^4] **总结** 在 Kubernetes 中实现滚动更新回滚的核心操作步骤如下: 1. **定义 Deployment:** 在 YAML 文件中配置应用及其滚动更新策略 (`RollingUpdate` 及其 `maxSurge`, `maxUnavailable`),**强烈建议配置健康检查**。 2. **触发滚动更新:** 修改 Deployment 的 Pod 模板 (如镜像) 并应用,或使用 `kubectl set image` 命令。Deployment Controller 会自动管理 Pod 的逐步替换。 3. **监控更新:** 使用 `kubectl get pods -w`, `kubectl describe deployment <name>`, `kubectl rollout status deployment/<name>` 观察状态。 4. **回滚(如需):** 使用 `kubectl rollout history` 查看版本,`kubectl rollout undo`(或 `--to-revision`)回滚到指定稳定版本。Deployment Controller 会执行一次到历史版本的滚动更新。 通过 `Deployment` 资源及其关联的命令(`set image`, `rollout`),Kubernetes 提供了强大且声明式的方式来管理应用的无中断更新安全回滚
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值