📚 课程目录第4章集群基础设施验收

4. 集群基础设施验收

基础设施验收是 OpenShift 集群交付中最容易被“看起来正常”所掩盖的环节。控制平面 Pod 处于 Running、节点 Ready、Web 控制台能打开，并不等于集群基础设施健康。真正需要确认的是：控制平面各组件是否在同一版本、同一证书信任链下协同工作；计算节点是否具备承载业务工作负载的完整条件；etcd 是否在可接受的延迟与配额内稳定运行；集群 DNS 是否能正确解析内部与外部名称；负载均衡是否把 API 与入口流量分发到健康的后端；证书是否在有效期内且被正确信任。本节围绕这六个对象，给出可执行的检查路径与判读依据。

控制平面：先看整体，再看组件

控制平面验收的第一步不是逐个 Pod 排查，而是确认集群版本与整体状态。使用 oc get clusterversion 查看 VERSION、AVAILABLE、PROGRESSING、SINCE 四列。AVAILABLE 应为 True，PROGRESSING 应为 False；若 PROGRESSING 长时间为 True，说明集群仍在滚动更新或某组件未收敛，此时不应继续后续验收。随后用 oc get clusteroperators 检查各 Operator 的 AVAILABLE、PROGRESSING、DEGRADED。DEGRADED 为 True 的 Operator 必须逐个定位，常见如 network、authentication、ingress 降级会直接影响后续 DNS 与负载均衡验收结论。

控制平面静态 Pod 位于 openshift-kube-apiserver、openshift-kube-controller-manager、openshift-kube-scheduler 命名空间。重点检查 kube-apiserver 的副本数是否与 master 节点数一致，以及 oc get pods -n openshift-kube-apiserver -o wide 中每个 Pod 是否分布在不同的 master 节点上。若三个 master 中有一个未运行 apiserver，说明该节点可能被排除在负载均衡后端之外，需要结合负载均衡检查确认。

计算节点：Ready 只是起点

节点验收要区分“Ready”与“可调度且资源充足”。执行 oc get nodes -o wide 确认所有节点 STATUS 为 Ready、ROLES 正确、INTERNAL-IP 与预期一致。接着用 oc describe node <node> 查看 Conditions：MemoryPressure、DiskPressure、PIDPressure 均应为 False；Allocatable 与 Capacity 的差值反映系统预留，若 Allocatable 明显偏低需检查 kubelet 预留配置。

更关键的是节点上的 MCP（MachineConfigPool）状态。执行 oc get mcp，UPDATED 与 UPDATING 应分别为 True 与 False，DEGRADED 为 False。若某节点处于 UPDATING，说明其配置尚未收敛，此时节点上的 kubelet、CRI-O、内核参数可能与其他节点不一致，不应通过验收。此外用 oc adm top nodes 观察 CPU、内存实际使用率，避免节点虽 Ready 但已接近资源上限。

etcd：延迟、配额与成员一致性

etcd 是集群的“事实来源”，其健康度直接决定控制平面能否稳定写入。验收时先确认成员数量：oc get pods -n openshift-etcd -o wide 应看到与 master 数量一致的 etcd Pod，且每个 Pod 运行在不同节点。随后进入任一 etcd Pod 执行健康检查：

oc rsh -n openshift-etcd etcd-master-0
etcdctl endpoint health --cluster
etcdctl endpoint status --cluster -w table
etcdctl member list -w table

判读要点：endpoint health 应全部返回 healthy；endpoint status 中 DB SIZE 应远小于 2GB 默认配额，若接近 2GB 需触发 defrag 或排查写入放大；RAFT TERM 与 RAFT INDEX 在各成员间应基本一致，若某成员 RAFT INDEX 明显落后，说明其同步滞后。磁盘 fsync 延迟是 etcd 最敏感的指标，生产环境建议 P99 低于 10ms，若持续高于 20ms 应检查底层存储是否为低延迟 SSD。此外 etcdctl alarm list 若返回 NOSPACE 告警，说明配额已触发，必须立即处理。

DNS：内部解析与外部转发

OpenShift 集群 DNS 由 openshift-dns 命名空间的 dns-default Pod 提供，通常以 DaemonSet 形式在每个节点运行。验收时先确认 oc get pods -n openshift-dns -o wide 中每个节点都有对应 Pod 且 Ready。随后用一次实际解析验证：

oc run dnstest --image=registry.access.redhat.com/ubi9/ubi --restart=Never -- sleep 3600
oc exec dnstest -- nslookup kubernetes.default.svc.cluster.local
oc exec dnstest -- nslookup api-int.cluster.example.com

第一条应解析到 Service 网段的 ClusterIP，第二条应解析到内部 API 负载均衡地址。若解析失败，检查 oc get dns.operator/default -o yaml 中 status 是否正常，以及 CoreDNS ConfigMap 中 forward 的上游 DNS 是否可达。外部域名解析（如 quay.io）也应验证，避免节点无法拉取镜像。

负载均衡：API 与入口两条链路

集群外部负载均衡通常分为两类：API 负载均衡（6443 端口）和入口负载均衡（80/443 端口）。验收 API 负载均衡时，从集群外执行 curl -k https://api.cluster.example.com:6443/healthz，应返回 ok；再对每个 master 节点 IP 单独执行同一请求，确认每个后端都健康。若某后端返回连接拒绝，说明该 master 的 apiserver 未监听或负载均衡健康检查未通过。

入口负载均衡则检查 oc get route -A 中已存在的路由，从外部访问其 Host 是否返回预期响应。同时确认负载均衡器后端池包含所有 infra 节点，且健康检查路径与端口正确。若使用 HAProxy，可查看其统计页确认各后端状态为 UP。

证书健康状态：有效期与信任链

OpenShift 证书分为集群证书与用户证书。集群证书可用 oc get secret -n openshift-kube-apiserver 与 oc adm certificate approve 相关流程检查，但更直接的方式是查看 oc get clusteroperators 中 certificate 相关 Operator 是否降级。对于 kube-apiserver 服务证书，可执行：

oc get secret -n openshift-kube-apiserver | grep serving
oc get secret -n openshift-ingress | grep router-certs

使用 openssl x509 -in cert.pem -noout -dates -subject -issuer 查看 Not Before、Not After、Subject、Issuer。重点确认：有效期剩余是否大于 30 天；Issuer 是否为集群内部 CA 或已信任的外部 CA；SAN 是否包含 api.cluster.example.com、api-int.cluster.example.com 及所有 master 节点 IP。若 SAN 缺失，客户端会报证书名称不匹配。对于 ingress 证书，还需确认是否被浏览器或调用方信任，自签名证书需在客户端导入 CA。

验收记录与判读

建议将上述六域检查结果记录为一份可追溯的验收表，至少包含：检查对象、命令或方法、期望值、实际值、结论、备注。例如 etcd 的 fsync P99 期望值可写“<10ms”，实际值记录实测结果；证书 Not After 期望值写“剩余 >30 天”，实际值记录具体日期。对于任何“实际值偏离期望值”的条目，必须给出根因或后续处理计划，不能以“观察中”结案。

注意：etcd 的 DB SIZE 接近 2GB 配额时，集群会进入只读保护状态，所有写入失败。验收阶段若发现 DB SIZE 超过 1.5GB，应优先安排 defrag 或排查异常写入，而不是继续其他检查。

最后需要强调，基础设施验收不是一次性动作。控制平面、etcd、证书等对象会随时间变化，建议在交付后 24 小时内做一次复验，确认没有出现新的降级或证书告警。只有六域全部通过且记录完整，才能认为集群基础设施具备进入业务工作负载验收的条件。