基于 Kubernetes 集群预检的经验总结

在云原生架构的日常运维与版本升级工作中，Kubernetes 集群的状态预检是保障操作顺利推进的核心环节。做好集群各组件与资源的状态检查，能够有效规避升级过程中出现的服务中断、资源异常等问题。

1、 节点状态检查

节点是 Kubernetes 集群的基础运行载体，节点状态异常会直接影响后续所有操作。在执行升级操作前，必须确保所有节点均处于Ready状态。

检查命令

kubectl get nodes |grep -i notready

处理原则一旦发现NotReady状态的节点，必须第一时间修复。节点异常的常见原因包括节点网络故障、kubelet 服务未启动、资源耗尽等。需要逐一排查并解决问题，确保所有节点恢复正常后，再进行后续步骤。

2、 Pod 状态检查

Pod 作为 Kubernetes 中最小的部署单元，其状态直接反映服务的运行情况。升级前需分层次对不同命名空间下的 Pod 进行检查，确保核心服务稳定、业务应用可控。

系统级命名空间 Pod 检查

kube-system 命名空间：该命名空间包含 kube-apiserver、kube-controller-manager 等集群核心组件的 Pod。执行以下命令排查非Running或Completed状态的 Pod。这类 Pod 异常会直接导致集群功能瘫痪，必须修复。

kubectl get pod -n kube-system |grep -v Run |grep -v Com

ark-system 命名空间：该命名空间承载着特定的平台服务，是集群运行的重要支撑。执行以下命令进行检查，发现NotReady状态的 Pod 需立即处理。

kubectl get pod -n ark-system |grep -v Run |grep -v Com

产品业务 Pod 检查对于除 kube-system 和 ark-system 外的其他产品基础服务 Pod，执行以下命令筛选异常 Pod。

kubectl get pod -A |grep -v kube-system |grep -v ark-system |grep -v Run |grep -v Com

这类 Pod 异常虽不直接影响集群基础功能，但可能会对业务造成影响。需要联系对应产品的研发同学，评估异常影响范围。在默认情况下，需确保所有业务 Pod 均处于Ready状态，再启动升级流程。

3、 特殊资源状态检查

除节点和 Pod 外，集群中的部分特殊资源状态也直接决定升级能否顺利进行，必须逐一确认状态正常。

AppSet 资源检查执行以下命令，查看 ark-system 命名空间下 AppSet 资源的状态。需确保其各项状态指标均符合运行要求，避免因配置异常引发升级问题。

kubectl get appset -n ark-system

Machine 与 MachineGroup 资源检查Machine 和 MachineGroup 资源与集群的节点管理密切相关。分别执行以下命令，检查这两类资源是否全部处于Ready状态。只要存在非Ready的资源，就无法进行升级操作，必须先完成修复。

# 检查Machine资源
kubectl get machine -n ark-system
# 检查MachineGroup资源
kubectl get machinegroup -n ark-system

SEED 状态检查SEED 状态是集群配置初始化的关键标识，其状态必须为success才能启动升级。执行以下命令，查看 SEED 的状态信息。若状态非success，需排查配置初始化过程中的问题，确保状态符合要求。

kubectl get cm -n ark-system ark.cmdb.seed.status -o yaml |grep status |grep -v seed

Kubernetes 集群升级前的预检工作，是一项需要严谨细致的系统性任务。从节点、Pod 到特殊资源，每个环节的状态都关乎升级成败。在实际工作中，要建立标准化的预检流程，严格按照步骤执行检查。遇到异常状态时，需分类处理：集群核心组件异常必须立即修复，业务应用异常需联动业务方评估影响。只有确保集群所有资源均处于健康状态，才能最大程度降低升级风险，保障集群和业务的稳定运行。

1、集群升级预检需优先保障节点、kube-system/ark-system 命名空间核心 Pod 的Ready状态，异常必须修复；

2、Machine、MachineGroup 资源需全部Ready、SEED 状态需为success，是升级的硬性前提；

3、业务 Pod 异常需联动研发评估影响，默认需全部Ready方可启动升级。