第22章 故障排除 集群
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
当Kubernetes集群 遭遇基础设施级故障时,其影响可能灾难性。Pod拒绝调度、应用程序无法访问、整节点从集群消失,可能同时影响数百个工作负载。与仅影响单一服务的应用程序特定问题不同,集群组件和节点的问题直击Kubernetes环境根基,因此快速诊断与解决对维持系统可用性至关重要。
本章将传授您排查此类基础设施级问题的技能。您将学会解读节点状态、探究节点转入NotReady状态的原因、解决资源压力状况,并追溯Pod调度失败的根本原因。
检查集群节点状态
诸多因素可能导致Kubernetes集群在组件层面出现 故障。建议列出集群中可用节点以识别潜在问题:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION control-plane-node Ready control-plane 2m45s v1.33.2 worker-node-1 Ready <none> 2m36s v1.33.2 worker-node-2 Ready <none> 2m29s v1.33.2 worker-node-3 Ready <none> 2m22s v1.33.2
输出结果将呈现整体概况。通过ROLES列可轻松识别各节点职责,同时掌握其使用的 Kubernetes 版本及当前健康状态。
在高层次排查问题时需关注以下要点:
-
该节点的健康状态是否为非
就绪状态? -
节点版本是否与其他节点存在差异?
后续章节将分别详述控制平面节点与工作节点的故障排查方法。
检查集群组件状态
在 中,控制平面节点上可用的组件包括:
- kube-apiserver
-
暴露用于管理对象的Kubernetes API( ),供
kubectl等客户端使用 - etcd
-
用于存储集群数据的键值存储库
- kube-调度器
-
为已调度但未创建的Pod选择节点( )
- 核心DNS
-
充当集群的DNS服务器 ,自动创建DNS记录使Pod和Service能通过名称而非IP地址相互发现,同时处理工作负载的外部DNS解析
- kube-controller-manager
-
运行控制器进程 (例如负责执行Job对象的作业控制器)
- 云控制器管理器(可选)
-
将Cloud服务商专属API( )与Kubernetes集群对接。此控制器不适用于本地部署的Kubernetes集群
除控制平面节点专属组件外,所有节点(控制平面与工作节点)均可能包含以下组件:
- kubelet
-
确保所有Pod( )及其容器正常运行
- kube-proxy(可选)
-
维护节点上的网络规则 以实现服务
- 容器运行时
-
负责运行容器的软件组件
要发现这些组件及其状态,请列出kube-system命名空间中的可用Pod。请注意某些组件不以Pod形式运行,例如kubelet或容器运行时。组件列表如下:
$ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE etcd 1/1 Running 1 (11d ago) 29d kube-apiserver 1/1 Running 1 (11d ago) 29d kube-controller-manager 1/1 Running ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access