容器集群升级前，先做哪些确认

容器集群升级前先做哪些确认# 升级前的操作示例执行 drain 节点时遭遇 PodDisruptionBudget 阻断 kubectl drain node-worker-04 --ignore-daemonsets --delete-emptydir-data error: unable to drain node node-worker-04, aborting command... eviction request: cannot evict pod coredns-674b8bbf45-z9x2p due to PodDisruptionBudget coredns-pdb示例场景在基准压测下对生产环境 Kubernetes 集群执行kubeadm upgrade或节点版本轮换时若在kubectl drain步骤阻塞可能影响升级流程。若控制面 API 组件升级完成而工作节点因 CNI 插件版本不匹配或 API 版本废弃API Deprecation导致容器无法正常创建集群运行将面临稳定性风险。Kubernetes 跨版本升级需要严格的操作流程。在触发升级流程前必须建立一套覆盖 API 兼容性、etcd 全量快照、PodDisruptionBudget 驱逐预算以及 CNI/CSI 插件版本映射的确认清单。1. 第一项确认检查 API 废弃与移除清单避免应用 Helm Chart 兼容性故障随着 Kubernetes 版本的演进部分 Beta 版的 API 资源会在新版本中被弃用或移除例如autoscaling/v2beta2升级为autoscaling/v2或者ingress从networking.k8s.io/v1beta1迁移至v1。若应用清单或 Helm Release 中依然使用旧版 API 声明一旦集群 API Server 升级完成后续的kubectl apply或 CI 流水线更新会抛出unrecognized API version错误。# 借助 kubent (Kube No Trouble) 工具在线扫描集群中已被废弃的 API 依赖 kubent # 典型输出结果 # Deprecated API: networking.k8s.io/v1beta1 Ingress # Found in: Helm release ingress-nginx in namespace infra # Replaced by: networking.k8s.io/v1 Ingress工程要求在升级前通过自动化脚本扫描并重构所有现存的 YAML 与 Helm 模板# 废弃的旧版本 Ingress 格式 (1.22 移除) # apiVersion: networking.k8s.io/v1beta1 # 升级前需确认并更新为标准的 v1 正式格式 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-ingress namespace: production spec: ingressClassName: nginx rules: - host: api.yourcompany.com http: paths: - path: / pathType: Prefix backend: service: name: api-service port: number: 802. 第二项确认etcd 状态健康度检查与一致性 Snapshot 备份集群控制面升级包含 etcd 数据结构的迁移过程。若 etcd 节点本身存在隐患如 Disk Latency 过高、DB Size 接近 8GB 上限、或者三节点集群中存在节点同步延迟升级过程可能引发数据冲突或节点选主波动。升级之前需要通过etcdctl对集群健康度做全面断言并生成带有 Hash 校验的 Snapshot# 1. 检查 etcd 集群节点健康状态与 Leader 稳定度 ETCDCTL_API3 etcdctl \ --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ endpoint health --write-outtable # 2. 检查 DB 空间占用与碎片率 ETCDCTL_API3 etcdctl \ --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ endpoint status --write-outtable # 3. 强制执行快照保存 ETCDCTL_API3 etcdctl \ --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ snapshot save /tmp/etcd-backup-pre-upgrade-$(date %Y%m%d%H%M).db # 4. 验证快照文件的完整性 ETCDCTL_API3 etcdctl --write-outtable snapshot status /tmp/etcd-backup-pre-upgrade-*.db升级前应检查存储告警、磁盘延迟、备份恢复和碎片情况。是否执行整理以及操作窗口要按照集群版本、存储状态和官方运维建议决定并先在非生产环境演练。3. 第三项确认CNI 网络插件与内核 eBPF/iptables 驱动映射升级流程中需要核对集群控制面版本与节点运行的 CNI 网络插件如 Calico 或 Cilium版本的兼容性。新版 Kubernetes 的 Kubelet 对部分 Container Runtime Interface (CRI) 逻辑进行了优化若 CNI 插件无法识别新版 Kubelet 传递的 NetworkNamespace 句柄升级后 Node 虽然显示Ready但新建 Pod 可能滞留在ContainerCreating状态提示Failed to create pod sandbox: rpc error。升级 Kubelet 前需要核对 CNI 厂商的官方 Version Matrix。以 Calico 为例升级节点前应先升级 CNI DaemonSet# 校验当前 CNI DaemonSet 镜像版本 kubectl get daemonset -n kube-system -l k8s-appcalico-node -o jsonpath{.items[*].spec.template.spec.containers[*].image} # 检查节点 Kubelet 与 CNI 组件通信日志是否存在废弃接口调用 kubectl logs -n kube-system -l k8s-appcalico-node --tail50 | grep -i deprecated规范的升级顺序先升级 CNI 与 CSI 控制器版本 - 再升级 Control Plane (kube-apiserver/controller-manager) - 最后逐个轮换升级 Node 的 Kubelet 与 Containerd。4. 第四项确认检查 PodDisruptionBudget (PDB) 与单节点独占 Pod 驱逐规则在对 Node 执行kubectl drain准备升级节点 OS 或 Kubelet 时过苛限制的 PDB 参数可能导致drain命令长时间被阻塞。示例场景某服务仅部署了 2 个副本但配置了minAvailable: 2的 PDB意味着系统在任何时刻均不允许销毁副本。当drain命令尝试驱逐 Pod 时API Server 会拒绝 Eviction 请求使自动化升级流程暂停。升级前排查 PDB 配置的调试指令# 列出集群中所有的 PDB 配置并审查 Current Healthy 与 Allowed Disruptions kubectl get pdb --all-namespaces # 预演排空节点操作 (Dry-run)观察是否存在死锁 Pod kubectl drain node-worker-04 \ --ignore-daemonsets \ --delete-emptydir-data \ --dry-runserver对于无状态服务若配置了不合理的 PDB如maxUnavailable: 0需调整为合理的百分比参数apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: web-app-pdb namespace: production spec: minAvailable: 50% # 使用百分比替代硬编码固定数字适应动态扩缩容与平滑驱逐 selector: matchLabels: app: web-appAPI 兼容性、etcd 备份、CNI 依赖和 PDB 只是升级前的关键检查项。是否进入下一阶段还应结合目标版本支持范围、节点池演练和回退方案判断。