在云原生架构的日常运维与版本升级工作中,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方可启动升级。