Debian上K8S部署的更新策略
一 核心策略与适用场景
- RollingUpdate（滚动更新）：默认策略，逐步替换旧 Pod，保持服务可用。通过参数控制节奏与可用性，适合大多数有状态或无状态服务。
- Recreate（重建）：先删除全部旧 Pod，再创建新 Pod，升级窗口内存在短暂不可用，适合允许停机的场景或资源紧张环境。
- 蓝绿部署（Blue-Green）：同时维护两套完全一致的环境，通过 Service selector 或 Ingress 原子切换流量，支持快速回滚，适合对稳定性要求极高的业务。
- 金丝雀发布（Canary）：先引入少量新版本流量进行验证，再逐步放大，适合需要灰度验证与风险控制的发布。
- 集群组件升级策略：控制平面与工作节点遵循“先控制平面、后工作节点、逐个节点腾空升级”的顺序，确保整体稳定性。
二 Deployment滚动更新关键参数与推荐配置
- 关键字段与作用：
- spec.strategy.type= RollingUpdate（默认）；
- maxSurge：更新期间可超出期望副本数的最大数量（整数或百分比），默认 25%；
- maxUnavailable：更新期间允许不可用的最大数量（整数或百分比），默认 25%；
- minReadySeconds：新 Pod 被判定“就绪”后需稳定运行的最短时间，建议根据应用启动时长设置；
- readinessProbe/livenessProbe：决定流量接入与健康重启，是滚动更新成功的前提；
- revisionHistoryLimit：保留的历史版本数（默认 10），影响可回滚范围；
- progressDeadlineSeconds：升级卡住超时（默认 600s），超时将标记升级失败。
- 典型安全配置示例（零宕机为目标）：
- 当 replicas=3 时，设置 maxSurge: 1、maxUnavailable: 0，可确保更新期间始终至少有 3 个可用实例；
- 当 replicas=1 时，避免同时设置 maxSurge=0 且 maxUnavailable=0（会导致无法滚动），实际会按“先增新后减旧”进行。
- 常用操作：
- 查看状态：kubectl rollout status deployment/；
- 回滚：kubectl rollout undo deployment/（可指定 revision）。
三 蓝绿与金丝雀发布落地方式
- 蓝绿部署：
- 使用两个 Deployment（如 blue/green）与同一 Service，通过修改 Service 的 selector 或 Ingress 规则切换全部流量；
- 优势是切换与回滚迅速（秒级）、版本强隔离；代价是需要双倍资源与数据/会话兼容性保障。
- 金丝雀发布：
- 通过两套 Deployment 或 ReplicaSet 按比例分流（如 5%→20%→50%→100%），结合 readiness 与监控指标逐步推进；
- 可借助 Argo Rollouts 实现自动化推进/回滚、可视化与指标驱动（如 Prometheus）。
四 在Debian上的集群升级顺序与注意事项
- 升级顺序与节点操作：
- 备份关键数据（如 /etc/kubernetes/、/var/lib/etcd/，必要时用 etcdctl 备份）；
- 升级控制平面：执行 kubeadm upgrade plan 查看可升级版本，执行 kubeadm upgrade apply ；
- 逐节点升级工作节点：对每个节点执行 kubectl drain --ignore-daemonsets，升级 kubelet/kubectl，重启 kubelet，再 kubectl uncordon ；
- 升级前后保持集群健康与监控告警可用。
- 运行环境与兼容性：
- 建议运行在 Debian 稳定版，并关闭 Swap（如 swapoff -a 并注释 fstab 条目）；
- 容器运行时优先 containerd（自 v1.24 起 Docker 被逐步弃用）；
- 选择兼容的 CNI 网络插件（如 Calico/Flannel/Weave），并在升级前确认其对目标 K8s 版本的兼容性；
- 升级期间关注网络插件、存储插件与控制器的版本匹配。