Kubernetes 1.32高可用集群部署收尾：10项必查清单与一键检查脚本

1. 六篇之后为什么我还要单独写一篇“部署”收尾先说个背景。这个系列走到第六篇前面五篇分别覆盖了节点规划、基础组件安装、负载均衡层搭建、控制平面组件部署、工作节点接入每一步我都是按“能跑起来就算数”和“能扛住故障才算完”两个标准来做的。到了第六篇按理说集群已经能用了但我还是决定把部署这件事单独收个尾原因很简单很多人在前面五步都顺利走完结果在“最后看一眼集群状态”的时候翻车。翻车不是指集群起不来而是指——看起来起来了实际上某个核心组件处于半死不活的状态。比如我见过不止一次某开发者的集群里kube-scheduler一直在 CrashLoopBackOff但因为他没看kubectl get pods -A的细节只顾着看节点 Ready就这么带着隐患跑了好几天。后来一排查发现是静态 Pod 的 manifests 文件权限写错了导致 kubelet 反复拉起失败。所以这一篇我不打算再讲一遍安装命令而是要讲清楚Kubernetes 1.32 高可用集群部署到收尾阶段时哪些检查必须做、哪些参数必须核对、哪些坑我实际踩过以及怎么把这些检查固化成一键脚本让下次部署不再靠记忆力。这篇文章既适合刚把集群搭起来、正在做验证的人也适合准备把部署流程交给团队其他人维护的人。2. 部署完成的定义不是节点 Ready而是控制面自愈2.1 一个容易混淆的概念集群就绪 vs 集群健康很多人判断集群部署完成只看两个东西kubectl get nodes是不是全部 Readykubectl get cs是不是都 healthy。实际上kubectl get cs这个命令在 1.32 里已经基本废掉了因为它返回的是组件健康状态的旧接口很多新部署方式下根本不准。真正能反映控制面健康的是看每个控制平面组件是否以预期方式运行以及它们是否具备故障转移能力。我之前在某公司的模拟项目X里遇到过一种情况三个控制平面节点都 Readykube-apiserver也都能访问但其中一个节点的kube-controller-manager因为 etcd 证书路径配错一直在重启。表面上看集群是好的因为另外两个节点把工作扛住了。但这种状态非常危险——如果恰好那台健康节点要维护整个集群的控制面会直接退化到不可用。所以我给“Kubernetes 1.32 高可用集群部署完成”下的定义是三条缺一不可所有节点控制平面 工作节点的 kubelet 状态正常且节点版本一致或兼容。三个控制平面组件apiserver、controller-manager、scheduler以静态 Pod 或系统服务方式运行且不依赖单点资源。etcd 集群健康并且所有控制平面节点都能访问同一个 etcd 集群而不是各连各的。这里尤其要注意第三点。高可用集群最常见的部署错误就是每个控制平面节点上的 apiserver 配置了不同的 etcd 地址。你可能觉得“反正我们有三个 etcd 节点谁连谁都一样”但实际操作中如果某个 apiserver 只连着其中一个 etcd 实例而那个实例一旦重启这台 apiserver 就会进入只读或不可用状态。表面上不影响其他节点实际上已经把高可用拆成了单点。2.2 版本一致性1.32 的特殊之处Kubernetes 1.32 对版本一致性的要求比之前更严格。过去小版本之间差个把月问题不大但 1.32 开始部分控制器对 API 资源的版本协商逻辑有调整如果你混用了 1.31 和 1.32 的组件某些 CRD 的 list-watch 可能会出现行为差异。我的建议是控制面组件严格统一到同一个小版本工作节点的 kubelet 可以放宽到±1 个小版本但尽量不要差异超过两个版本。有人会问那 etcd 呢etcd 的版本和 Kubernetes 版本没有严格绑定但有一个实际经验——etcd 3.5.x 配合 Kubernetes 1.32 是当前最稳的组合。如果你还在用 etcd 3.4.x建议在部署收尾阶段顺手升级不然后续做 etcd 备份恢复时会遇到一些细节兼容问题。3. 收尾阶段的第一道闸门证书有效期与集群启动时序3.1 证书问题是最隐蔽的“定时炸弹”Kubernetes 集群里的证书多到你数不清但真正需要在收尾阶段核对的只有三类apiserver 对外服务的证书通常由 kubeadm 或自建 PKI 签发。kubelet 客户端证书kubelet 访问 apiserver 用的。etcd 节点间通信证书peer 证书。很多人以为“证书没过期就行”其实不对。在 1.32 里apiserver 对 kubelet 证书轮换的默认行为是允许自动轮换的但前提是你在初始化集群时设置了--rotate-kubelet-server-certificatestrue。如果没有设置kubelet 的 server 证书到期后不会自动续期而 client 证书可能已经轮换成功了两者之间会出现错配导致kubectl logs时偶发证书错误。我在部署收尾时通常这样检查证书kubeadm certs check-expiration这个命令会列出 apiserver、controller-manager、scheduler、front-proxy、etcd 等所有证书的到期时间。如果输出里出现某个证书剩余时间不足 30 天我基本不会继续往下走而是先手动 renew。为什么因为很多团队把集群部署完后就直接丢给运维没人记得三个月后回来续期。与其依赖自动轮换不如在部署收尾时就把证书有效期拉满或者直接建立证书到期提醒。我自己习惯是把kubeadm certs renew all写进部署脚本末尾只在证书剩余时间小于 90 天时执行这样既能避免频繁续期带来的风险又能确保集群长期稳定。3.2 启动时序先 etcd再 apiserver最后 controller-manager 和 scheduler不管你用 kubeadm 还是二进制方式部署组件启动顺序都应该是固定的先 etcd再 apiserver最后 controller-manager 和 scheduler。这个顺序不是玄学而是依赖关系决定的。etcd 是数据面apiserver 启动时要连 etcd 做资源发现如果 etcd 没起来apiserver 会直接启动失败或反复重试。controller-manager 启动时要通过 apiserver 获取集群状态如果 apiserver 没就绪controller-manager 会报连接拒绝。scheduler 同理。但这里有个容易忽略的点高可用集群里三个控制平面节点不是同时启动的。比如你按顺序启动了节点A的 etcd、apiserver接着启动节点B的 etcd、apiserver这时候节点A的 controller-manager 可能已经抢到了 leader 锁节点B的 controller-manager 会处于 standby 状态。这都是正常的。怕的是你在所有组件还没完全就绪时就去初始化工作节点这会导致 kubelet 第一次注册时拿到不完整的集群状态后续排障反而更麻烦。我的建议是每个控制平面节点上的组件启动完成后等 30 秒左右确认kubectl get --raw/healthz返回 ok再继续下一个节点。4. 实战核对这 10 个关键项我每次部署后必查这一节我不会讲“运行 kubectl get pods 看看有没有 CrashLoopBackOff”这种废话而是讲真正能暴露问题、且大部分人容易漏掉的检查项。我把它们分成三组每组都是我在真实环境里踩过坑之后固化的检查动作。4.1 etcd 健康与数据一致性etcd 是 Kubernetes 的大脑但很多人部署完集群后根本不看 etcd 状态。我见过一个案例某开发者的集群里三个 etcd 节点都显示 healthy但其中一个节点的数据落后其他节点几十秒。原因很简单——etcd 的 leader 选举和心跳正常不代表数据同步没有延迟。你这个落后节点在某个时间窗口内读到的数据是旧的如果恰好这时候有控制器要创建资源就会出现资源冲突。检查方法不只是etcdctl endpoint health还要看endpoint status的 Raft index。ETCDCTL_API3 etcdctl --cacert/etc/etcd/ca.pem --cert/etc/etcd/healthcheck-client.pem --key/etc/etcd/healthcheck-client-key.pem --endpointshttps://192.168.1.11:2379,https://192.168.1.12:2379,https://192.168.1.13:2379 endpoint status --write-outtable输出里会有一个RAFT INDEX列。正常情况三个节点的 RAFT INDEX 应该非常接近差距在两位数以内。如果某个节点落后几千甚至几万说明它的同步有问题要么是网络带宽不足要么是磁盘性能太差。我用的是fio做过一轮压测确认三台 etcd 节点的磁盘 IOPS 基本一致后才放心让它们组成集群。如果你发现某台节点磁盘性能明显差一截建议直接替换不要在 etcd 集群里混用不同性能档位的磁盘。4.2 控制面组件的静态 Pod 配置一致性使用 kubeadm 部署时apiserver、controller-manager、scheduler 都是以静态 Pod 方式运行的。所谓静态 Pod就是由 kubelet 直接读取/etc/kubernetes/manifests目录下的 YAML 文件来创建不走 apiserver 调度。这带来一个好处控制面组件不依赖 apiserver 就能起来。但同时也有一个坑三个控制面节点上的 manifests 文件必须保持一致否则就会出现“节点A的 apiserver 带了这个参数节点B的没带”这种诡异差异。我见过最典型的案例某同事在节点A上给 apiserver 加了--enable-admission-pluginsNodeRestriction但节点B、节点C没加。结果就是通过节点A创建的 Pod 正常通过节点B创建的 Pod 能绕过部分限制。这种问题极难排查因为表面看集群完全正常。所以我每次部署完都会做一次 manifests 文件比对diff /etc/kubernetes/manifests/kube-apiserver.yaml (ssh node2 cat /etc/kubernetes/manifests/kube-apiserver.yaml)如果三个节点的文件中出现不一致我会逐个字段核对而不是直接覆盖。因为有时候不一致是有意的比如不同节点监听了不同的--advertise-address参数这种就不能强行统一。但像--service-cluster-ip-range、--service-node-port-range、--cluster-cidr这几个参数必须完全一致否则集群行为会分裂。4.3 kubelet 注册与 Node 标签工作节点加入集群后第一件事不是跑业务 Pod而是确认 Node 对象正确注册并且带有期望的标签。很多部署指南只讲kubeadm join不讲标签。但在高可用集群里标签意味着业务负载的调度位置没打标签的节点很容易被调度器塞满非预期工作负载。我这里说的检查不是手动kubectl label而是在部署收尾阶段用 yaml 文件统一管理标签。比如我先写好一个node-labels.yamlapiVersion: v1 kind: Node metadata: name: node-1 labels: node-role.kubernetes.io/control-plane: true role: ops storage: fast然后用kubectl apply -f node-labels.yaml逐节点打标签。这样做的好处是标签变更可以被 Git 追踪而不是靠某个人记在脑子里。另外一定要检查 kubelet 注册时的providerID。在 1.32 里如果你在云环境部署providerID 缺失会影响很多与云厂商联动的功能。但如果是裸机或虚拟化环境自建providerID 不是必须项可以跳过。我自己的环境是自建虚拟机所以这个点我只做确认不做强制要求。4.4 kube-proxy 模式与 Service 连通性控制面正常只代表集群骨架正常Service 和 Pod 之间的网络打通才是真正能让业务跑起来的关键。kube-proxy 在 1.32 里默认使用 iptables 模式如果你的集群规模不大、Service 数量在几百以内iptables 完全够用。但如果你的 Service 数量会涨到几千建议在部署阶段就启用 IPVS 模式。怎么在部署收尾时验证 kube-proxy 工作正常最直接的办法是创建一个测试 Service然后从其他节点访问 ClusterIP。kubectl create deployment test-net --imagenginx:1.27 kubectl expose deployment test-net --port80 --target-port80 kubectl get svc test-net然后从另一台节点执行curl -I http://ClusterIP:80如果你 curl 不通先不要怀疑网络插件先检查 kube-proxy 的日志和 iptables 规则。我遇到过多次“curl 不通”的问题最后发现是 kube-proxy 所在的 DaemonSet Pod 因为镜像拉取失败没起来跟 CNI 一点关系都没有。如果你启用了 IPVS 模式检查方法会略有不同。IPVS 模式下你需要额外确认ip_vs内核模块已经加载否则 kube-proxy 会退回到 iptables 模式而且不会报错只是性能特征变了。加载内核模块可以在部署脚本里这样写modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh然后在/etc/modules-load.d/kube-proxy.conf里写入这几个模块名确保重启后自动加载。4.5 CNI 网络插件的版本兼容性网络插件在 1.32 生态里选择很多但我在高可用场景下只推荐两个Calico 和 Cilium。原因不复杂它们对 Kubernetes 1.32 的支持都相当完善且社区更新频率高。但我见过最多的问题不是选哪个而是版本匹配。很多人的习惯是“我装了最新版 Calico”然后跑起来没问题就完事了。但 Kubernetes 升级到 1.32 后如果 CNI 插件版本过旧可能会出现 Pod 网络通但 DNS 解析间歇性失败的问题这类问题极难定位因为所有组件都显示 Running。我建议在部署收尾阶段做一次版本校验打开 CNI 插件官方兼容性文档确认它支持的 Kubernetes 版本范围包含 1.32。以 Calico 为例v3.28 才能完整支持 1.32 引入的一些 API 变更。如果是 Cilium则要注意它的kube-proxy replacement功能是否与你的 kube-proxy 模式冲突。4.6 CoreDNS 与集群 DNS 解析我几乎每次部署完都会遇到 CoreDNS 的配置问题不是因为它复杂而是因为很多人安装完就忘了检查它能不能真正解析 Service 名称。你在控制平面节点上随便kubectl exec进一个 Pod跑nslookup kubernetes.default.svc.cluster.local如果解析失败集群的 DNS 链路就有问题。常见的坑有三个CoreDNS 的 Pod 数量不足。我见过有人只部署了 1 个副本控制面高可用了DNS 却是单点。CoreDNS 的forward配置指向了错误的上游 DNS导致集群外部域名解析慢或失败。节点上的/etc/resolv.conf被系统管理工具改写导致 CoreDNS 的 Pod 启动时读到宿主机配置影响解析。部署收尾时我通常会把 CoreDNS 的副本数调到至少 2并配置反亲和性让副本分散到不同节点。同时检查kubectl get configmap -n kube-system coredns -o yaml确认forward . /etc/resolv.conf里的配置符合预期。4.7 Ingress Controller 与负载均衡层连通如果你部署集群只是为了跑内部任务Ingress 可以后面再说。但如果你想对外提供服务收尾阶段必须把 Ingress 链路打通。这里我分开讲两种情况。第一种是你前面已经用 Nginx 或 HAProxy 搭了 TCP 负载均衡层那么 Ingress Controller 只需要作为 NodePort 或 HostPort 暴露在集群内然后由外部 LB 把流量转到 Ingress Controller 所在的节点。这种情况下重点检查外部 LB 的健康检查路径是否指向了 Ingress Controller 的healthz接口。第二种是你没有外部 LB直接用云厂商的 LoadBalancer Service。这种情况在 1.32 里比较省事但要注意 Service 的externalTrafficPolicy设置。如果设置为Cluster每次请求都可能被转发到非本节点的 Pod造成额外跳数和源地址丢失排查问题时特别烦。我实际建议设置为Local同时把 Ingress Controller 的副本数凑到每个节点都有避免单点。4.8 控制平面节点的 etcd 客户端证书认证默认情况下etcd 只监听 HTTPS并且要求客户端提供证书。apiserver 访问 etcd 时需要配置--etcd-cafile、--etcd-certfile、--etcd-keyfile。如果这三个参数配错apiserver 会无法连接 etcd集群直接不可用。但有一个比较隐蔽的问题etcdctl命令在部署收尾时如果没配好证书你查不到 etcd 健康状态然后会误判为 etcd 挂了。我遇到过几次这种误判最后发现是etcdctl的客户端证书路径写错了。所以我在部署脚本里一般这样封装检查命令alias etcd-healthETCDCTL_API3 etcdctl --cacert/etc/etcd/ca.pem --cert/etc/etcd/healthcheck-client.pem --key/etc/etcd/healthcheck-client-key.pem --endpointshttps://node-ip:2379 endpoint health再把这个 alias 写进/root/.bashrc方便后续运维直接使用。4.9 存储类与 PVC 的默认行为业务 Pod 不一定都需要持久化存储但如果没有默认 StorageClass很多需要 PVC 的工作负载会创建失败。Kubernetes 1.32 对 CSI 的依赖已经非常普遍如果你用的是自建存储务必确认 CSI Driver 是否注册成功。最简单的验证方式是kubectl get storageclass如果有默认 StorageClasskubectl get sc时它的 NAME 会带(default)后缀。没有的话你需要手动设置kubectl patch storageclass your-storageclass -p {metadata: {annotations:{storageclass.kubernetes.io/is-default-class:true}}}这里有个细节如果集群里同时存在多个 StorageClass但没有一个被标记为默认那么 PVC 不显式指定 StorageClass 时会直接报错而不是自动帮你选。很多人在部署完集群跑第一个有状态应用时才发现这个问题白白浪费不少时间。4.10 监控与日志的最小化采集最后一项检查容易被人忽略监控和日志要不要在部署收尾阶段就接入。我的建议是至少要接一个轻量级的采集端哪怕只是把kubelet的 metrics 暴露出来也行。原因很现实——三天后你发现某个节点磁盘快满了你总不能靠每台机器 SSH 上去df -h来排查。如果你不想在收尾阶段引入全家桶可以用 Prometheus kube-state-metrics 的最低配置。只需要在部署脚本里加一个小任务定时把集群核心指标抓一遍即可。我用的方式是在管理节点上跑一个简单的 curl 采集脚本把所有节点的/metrics接口拉一遍存储成文本后续要用时再导入分析。5. 从手动到自动我把收尾检查写成了一个 bash 脚本5.1 脚本设计思路上面那 10 项检查如果每部署一次都要手动敲一遍命令既浪费时间又容易漏项。尤其当你维护多套集群时“上次我明明检查过”这种话根本靠不住。所以我建议把这些检查固化成脚本至少涵盖以下功能检查节点状态和版本。检查 etcd 健康和 Raft Index。检查控制面组件静态 Pod 的存活状态。检查 CoreDNS 解析。检查 kube-proxy 规则是否正常加载。检查证书有效期。检查默认 StorageClass。输出汇总报告方便归档。这个脚本的价值不在于它多复杂而在于它能在每次部署后给出一份统一的“集群体检报告”让维护人员有据可查。5.2 一个可直接参考的核心版本下面这段脚本我简化掉了部分环境变量保留了最核心的检查逻辑。你可以根据自己的集群环境修改路径和端口。#!/bin/bash # 集群部署收尾检查脚本 # 用法: ./check.sh kubeconfig路径 set -e KUBECONFIG${1:-/root/.kube/config} export KUBECONFIG echo 1. 节点状态 kubectl get nodes -o wide echo echo 2. 证书有效期 kubeadm certs check-expiration 2/dev/null || true echo echo 3. etcd 健康状态 # 注意: 以下路径需根据实际部署环境调整 ETCD_CERT_DIR/etc/kubernetes/pki/etcd for ep in https://192.168.1.11:2379 https://192.168.1.12:2379 https://192.168.1.13:2379; do ETCDCTL_API3 etcdctl \ --cacert${ETCD_CERT_DIR}/ca.crt \ --cert${ETCD_CERT_DIR}/healthcheck-client.crt \ --key${ETCD_CERT_DIR}/healthcheck-client.key \ --endpoints${ep} endpoint health done echo echo 4. 控制面组件 Pod 状态 kubectl get pods -n kube-system -o wide | grep -E kube-apiserver|kube-controller-manager|kube-scheduler|etcd echo echo 5. CoreDNS 解析测试 kubectl run dns-test --imagebusybox:1.36 --restartNever --command -- /bin/sh -c nslookup kubernetes.default.svc.cluster.local # 等待一段时间后检查日志 kubectl wait --forconditionReady pod/dns-test --timeout30s || true kubectl logs dns-test || true kubectl delete pod dns-test --ignore-not-found echo echo 6. 默认 StorageClass kubectl get storageclass echo echo 7. kube-proxy 模式确认 kubectl get configmap -n kube-system kube-proxy -o jsonpath{.data.config\.conf} | grep -i mode || true echo echo 完成 这个脚本会在终端里输出所有关键检查项的结果。你不需要让它一次跑完就万事大吉而是要把输出结果保留下来作为这一版集群的初始健康基线。后面如果有性能波动或行为异常对照基线来排查会高效很多。5.3 扩展成准入校验的一部分如果你所在团队已经用了 GitOps 或 CI/CD 流程完全可以把这段检查逻辑扩展成一个“部署后自动验证”的步骤。比如在集群安装完成后CI 自动执行脚本如果检查项里有任何一项失败就阻止后续配置步骤继续。这样可以避免“集群没真正健康就进入配置管理流程”的问题。我实际遇到过的情况是某同学在 CI 里把集群安装和 Prometheus 部署写在一个流水线里集群还没完全就绪Prometheus 安装任务已经开始了结果 Prometheus 的 CRD 反复报错排查了半天才发现根本原因是集群的 apiserver 还没稳定。如果在流水线入口处加入这个健康检查脚本这些问题从一开始就能避免。6. 高可用集群的“可用”边界哪些情况我接受哪些情况必须重来6.1 单节点故障模拟必须做很多同行部署完高可用集群后从不做故障演练理由是“生产环境不敢动”。但我的经验恰恰相反在部署收尾阶段也就是业务流量还没进入的时候是最适合做故障演练的窗口。这时候出了问题不会影响真实用户而一旦跳过这一步后面你想做都没机会。我通常做的演练很简单并不会真的去拔电源而是依次执行# 停掉一个控制平面节点上的 kubelet systemctl stop kubelet然后观察两分钟确认集群仍然可以正常响应kubectl get nodes。接着把 kubelet 启动回来再做下一台。等三个控制平面节点都轮流停过一次之后再挑一台工作节点做同样的操作确认上面的 Pod 能重新调度到其他节点。这个过程能暴露很多在静态检查里看不出的问题比如某个 kubelet 停掉后它的静态 Pod 是否会正确迁移到其他节点还是因为端口冲突等原因一直 Pending。控制面组件失去 leader 后是否能在另一节点上快速接管。卷挂载相关的 Pod 在节点故障时能否正常做故障转移。6.2 已知但不强制的“小毛病”有一种状态我不会重来但会记录在案某个工作节点的磁盘 IO 延迟明显高于其他节点但它还没达到影响 etcd 的程度。这种情况下我选择继续使用但会把它标记为“低优节点”后续调度时尽量避免调度高 IO 业务到这台节点上。还有一种情况我同样接受但记录某个控制平面节点的 apiserver 参数与其他节点有轻微差异比如--request-timeout设置不同但功能不受影响。这种我会做一次标准化操作把它统一而不需要重新部署整个集群。真正让我决定“必须重来”的标准只有一个etcd 数据不一致并且无法通过常规手段修复。因为 etcd 是整个集群的基石它出了问题后面所有工作都是建立在错误数据之上的。这时候重来比强行修补更有效率。6.3 我踩过的那个“坑”一个标点符号引发的串联故障最后分享一个我实际踩过的坑。有一次我给三台控制面节点编写kube-apiserver.yaml参数时不小心在--etcd-servers的地址之间少写了一个逗号。这个错误导致 apiserver 只能访问第一个 etcd 地址另外两个地址被解析成了一个非法字符串。部署完了之后kubectl get nodes 看起来正常但集群的 HA 能力实际已经退化了——如果第一台 etcd 挂掉apiserver 连不到其他 etcd 节点整个集群会立即不可用。这个坑的特点是它不在表面报错而是在故障发生时才会暴露。正因为如此我才把“静态 Pod 配置一致性检查”列入了 10 项必查清单。很多人觉得部署很顺利其实只是运气好关键问题还没到爆发时间。7. 后续还能怎么扩展从部署收尾到长期运维这一篇虽然是系列收尾但部署收尾不等于运维结束。我一般会在部署完成后的第一周里把下面几件事顺手做了能省掉后面不少维护成本。建立证书到期提醒提前 60 天预警。定期备份 etcd 快照并演练恢复流程。备份文件一定要放到集群外部否则集群整体故障时备份也没了。记录集群版本和关键组件版本建立一份简单的环境文档。把检查脚本的输出结果和上一版做对比观察是否有劣化趋势。关于备份这一点多说一句。很多人在部署收尾时很兴奋觉得终于跑通了结果完全没做备份。等到一个月后不小心删了一个 namespace才发现没有任何恢复手段。我不建议在部署收尾当天就做完整的恢复演练但至少要把 etcd 快照的定时任务先建起来哪怕只是每天凌晨自动打一个快照心里也会踏实很多。根据我这几年做 Kubernetes 相关工作的习惯我会在每次集群部署完成后留出半天时间专门做本篇文章提到的这些检查和演练而不是急着把业务迁上去。集群可以后续再调优但初始健康状态如果没确认好后面所有问题都会叠加上来排查成本会翻好几倍。希望你这次部署的集群不只是看起来高可用而是真的能在某个节点宕掉时依然稳稳地跑住业务。