ShowDocs
搜索文章Ctrl K

外观

← 返回Kubernetes列表
知识专题

Kubernetes 升级与维护 ​

升级原则 ​

  • 只升级到上游和发行版/云厂商共同支持的版本。
  • 次要版本逐级升级，不能跳过；先把当前分支升到最新补丁，再升目标分支最新补丁。
  • 控制面先于 kubelet；组件偏差必须符合官方版本偏差策略。
  • 集群升级不等于只升级核心：CNI、CSI、Ingress/Gateway、DNS、Metrics、Operator、CRD 和客户端都有兼容矩阵。
  • 先演练、备份和验证恢复，再变更；明确停止条件和回退/前滚策略。

截至 2026-08-12，上游维护 1.36、1.35、1.34，最新稳定补丁为 v1.36.3。执行时重新核对 Releases、stable.txt 和供应商公告。

升级前清单 ​

  1. 阅读目标次要版发布公告、完整 Changelog、Urgent Upgrade Notes、弃用/移除和已知问题。
  2. 盘点 API 使用：清单、Helm Chart、CRD、Webhook、Operator、客户端库。
  3. 核对所有插件和云服务兼容矩阵，升级必要的前置组件。
  4. 当前集群健康：API/etcd、节点、系统 Pod、存储、网络和备份无未解决告警。
  5. 容量足够逐节点 drain、Deployment surge 和故障域冗余；PDB 不会无解阻塞。
  6. 保存配置和资源清单；对 etcd/持久数据执行可恢复备份，并在隔离环境验证。
  7. 在接近生产的预发环境运行安装、升级、回滚/前滚、冒烟和性能测试。
  8. 通知业务、值班和供应商，设置变更窗口、观察期、负责人和停止条件。
bash
kubectl version
kubectl get nodes -o wide
kubectl get pods -A --field-selector='status.phase!=Running'
kubectl get apiservices
kubectl get --raw='/readyz?verbose'
kubectl get pdb -A

API 弃用扫描可使用组织批准的工具和 API Server 审计/指标；不要仅搜索 Git，因为运行中的 CR、Webhook 和外部客户端也可能调用旧 API。

上游支持的组件顺序 ​

从 1.35 升 1.36 的通用顺序：

  1. 所有 API Server 升到目标版本（HA 逐实例，混合期最多差一版）。
  2. controller-manager、scheduler、cloud-controller-manager 升级。
  3. kubelet 逐节点 drain 后升级；次要版 kubelet 不支持不驱逐 Pod 的原地升级。
  4. kube-proxy 升级。

kubectl 和客户端需保持在 API Server 前后一个次要版本内。这是组件兼容顺序，不是发行版命令；具体流程以厂商文档为准。

节点维护：cordon、drain、uncordon ​

先确认节点上的 Pod、PDB 和本地数据：

bash
node='worker-01'
kubectl get node "$node"
kubectl get pods -A --field-selector="spec.nodeName=$node" -o wide
kubectl get pdb -A
kubectl cordon "$node"
kubectl drain "$node" --ignore-daemonsets --delete-emptydir-data --timeout=20m
# 完成维护并验证节点健康后
kubectl uncordon "$node"

drain 参数

--delete-emptydir-data 会删除该节点被驱逐 Pod 的 emptyDir 数据；应用必须把它视为临时数据。不要默认加 --disable-eviction，它绕过 PDB。带非控制器 Pod、Local PV 或特殊系统 Pod 的节点要用专用 Runbook。

逐节点操作，每步等待业务副本 Ready、错误率/延迟恢复后再继续。故障域内不要同时 drain 过多节点。

kubeadm 集群 ​

kubeadm 通常先在第一个控制面节点升级 kubeadm 并运行 kubeadm upgrade plan/apply，再处理其余控制面和逐节点 drain 后的 kubelet。包 hold/unhold、配置 API 和准确命令必须使用目标版本的 kubeadm 升级指南，不得照抄旧教程；外部 etcd 与 stacked etcd 的流程也不同。

托管集群 ​

  • 核对控制面与节点池可选版本、强制升级日期和 EOL。
  • 阅读供应商变更：OS 镜像、运行时、CNI/CSI、LB、身份、自动修复。
  • 先升控制面，再滚动新节点池；高风险升级可新建节点池迁移工作负载。
  • 回退控制面通常不被支持，要以修复/前滚为主要方案。

etcd 备份与恢复 ​

etcd 快照必须来自一致、受支持的端点，包含正确证书，并加密保存到独立故障域。备份成功日志不代表可恢复：

  • 记录 Kubernetes/etcd 版本、集群 ID、证书和加密配置依赖。
  • 定期在隔离环境恢复，验证 API 对象和关键控制器。
  • 恢复是集群级灾难操作，所有 API Server/etcd 成员必须按一致流程处理。
  • 恢复旧快照会回退 Kubernetes API 状态，但不会自动回退外部云资源和业务数据库。

不要在通用文档中复制带生产证书路径的 etcdctl 命令；按集群拓扑的灾备 Runbook 执行。

升级中观察 ​

bash
kubectl get nodes --watch
kubectl get pods -A -o wide
kubectl get --raw='/readyz?verbose'
kubectl get apiservices
kubectl get events -A --field-selector=type=Warning

同时监控用户成功率/延迟、API Server、etcd、调度、DNS、CNI/CSI、Ingress、Webhook、Pending、重启和 PDB。停止条件应是可量化阈值，而非“感觉异常”。

升级后验证 ​

  • 所有节点和控制面版本、运行时版本符合计划，无长期偏差。
  • 系统组件、扩展 API、Webhook、CRD Controller 和插件 Ready。
  • 创建/更新/删除测试工作负载，验证调度、DNS、Service、Ingress/Gateway、NetworkPolicy 和存储挂载。
  • 执行应用冒烟、Job、HPA、日志/指标/告警和备份测试。
  • 检查废弃 API 调用、新 Warning、审计和资源使用变化。
  • 保留观察期，完成变更记录和新基线快照。

回退边界 ​

工作负载镜像通常可回滚，但 Kubernetes 控制面/etcd 降级一般不受支持；API 存储转换、组件状态和外部控制器可能已经前进。升级计划必须优先设计安全前滚。若达到停止条件，暂停后续节点、隔离问题、保留证据，并调用发行版支持流程，不擅自降级二进制或恢复旧 etcd。

继续阅读