常见的 Kubernetes 集群问题及解决方法
Kubernetes 虽然功能强大，但有时也会遇到需要仔细排查的挑战。了解常见的集群级问题及其解决方案对于维护健康可靠的编排环境至关重要。本指南将深入探讨影响 Kubernetes 控制平面、etcd 和工作节点（worker nodes）的常见问题，并提供诊断和修复它们的实用步骤。
有效的 Kubernetes 集群管理依赖于主动监控和系统化的解决问题的方法。通过熟悉这些常见问题，您可以显著减少停机时间，并确保您的应用程序保持可用。
控制平面问题
Kubernetes 控制平面是您集群的大脑，负责管理集群状态和协调操作。这里出现的问题可能会产生深远的影响。
API 服务器不可用
API 服务器是所有集群通信的中心枢纽。如果它宕机或无响应，您将无法使用 kubectl 或其他工具与集群进行交互。
症状：
* kubectl 命令超时或出现连接被拒绝错误。
* 控制器和其他集群组件无法通信。
原因和修复：
* 资源耗尽： API 服务器 Pod 可能耗尽了 CPU 或内存。使用 kubectl top pods -n kube-system 检查资源利用率，并在必要时扩展 API 服务器部署或节点。
bash
kubectl get pods -n kube-system -l component=kube-apiserver -o wide
kubectl top pods -n kube-system -l component=kube-apiserver
* 网络问题： 确保网络策略或防火墙没有阻止到 API 服务器端口（通常是 6443）的流量。
* 控制平面节点健康状况： 如果 API 服务器运行在特定节点上，请检查该节点的健康状况。它是否过载、处于 NotReady 状态，或出现内核恐慌（kernel panics）？
bash
kubectl get nodes
kubectl describe node <node-name>
* 证书过期： API 服务器依赖 TLS 证书。如果证书过期，通信将失败。监控证书过期日期并主动续订。
控制器管理器或调度器故障
控制器管理器（Controller Manager）和调度器（Scheduler）是负责管理集群期望状态并将 Pod 调度到节点上的关键组件。
症状：
* 新 Pod 未被创建或调度。
* 部署（Deployments）、有状态集（StatefulSets）或其他控制器未在进展。
* Pod 卡在 Pending 状态。
原因和修复：
* Pod 故障： 检查 kube-system 命名空间中 kube-controller-manager 和 kube-scheduler Pod 的日志。
bash
kubectl logs <controller-manager-pod-name> -n kube-system
kubectl logs <scheduler-pod-name> -n kube-system
* 领导者选举问题： 这些组件使用领导者选举来确保只有一个实例处于活动状态。网络分区或领导者选举锁问题可能导致它们变得不可用。
* RBAC 权限： 确保这些组件使用的服务账户具有与 API 服务器交互的必要权限。
Etcd 问题
Etcd 是分布式键值存储，作为 Kubernetes 所有集群数据的后端存储。它的健康状况至关重要。
Etcd 性能下降
缓慢的 etcd 操作可能导致控制平面响应迟缓或无响应。
症状：
* kubectl 操作缓慢。
* API 服务器延迟。
* 控制平面组件报告与 etcd 通信时超时。
原因和修复：
* 高磁盘 I/O： Etcd 对磁盘性能非常敏感。为 etcd 数据目录使用快速 SSD。
* 网络延迟： 确保 etcd 成员之间以及 etcd 与 API 服务器之间的延迟较低。
* 数据库大小过大： 随着时间的推移，etcd 可能会积累大量数据。定期压缩和碎片整理 etcd 数据库。
bash
ETCDCTL_API=3 etcdctl compact $(etcdctl --endpoints=<etcd-endpoints> --cacert=<ca.crt> --cert=<client.crt> --key=<client.key> alarm list | grep -o '[0-9]*')
ETCDCTL_API=3 etcdctl defrag --endpoints=<etcd-endpoints> --cacert=<ca.crt> --cert=<client.crt> --key=<client.key>
* 资源不足： 确保 etcd Pod 或专用节点具有足够的 CPU 和内存。
Etcd 集群不可用
如果 etcd 无法维持仲裁（quorum），整个集群将停止运行。
症状：
* 集群完全无响应。
* API 服务器无法连接到 etcd。
原因和修复：
* 网络分区： 确保所有 etcd 成员都能相互通信。检查防火墙和网络配置。
* 成员故障： 如果过多的 etcd 成员发生故障（对于 N 个成员的集群，超过 (N-1)/2 个），则会丢失仲裁。调查故障成员，尝试重启它们，或考虑从备份恢复。
* 磁盘损坏： 检查 etcd 日志中是否有与磁盘相关的错误。如果数据损坏，您可能需要从备份恢复。
提示： 务必定期进行经过测试的 etcd 备份。这是您最终的安全网。
节点健康问题
工作节点是运行您的应用程序 Pod 的地方。节点问题会直接影响应用程序的可用性。
节点处于 NotReady 状态
当节点上的 kubelet 停止向 API 服务器报告其状态时，节点将变为 NotReady。
症状：
* kubectl get nodes 显示节点处于 NotReady 状态。
* 调度在该节点上的 Pod 可能变得不可调度或被重新调度到其他地方。
原因和修复：
* Kubelet 未运行： Kubelet 进程可能已崩溃或未能启动。检查节点上的 kubelet 日志。
bash
sudo journalctl -u kubelet -f
* 资源饥饿： 节点可能缺少 CPU、内存或磁盘空间，导致 kubelet 无法正常运行。
bash
kubectl describe node <node-name>
# 在节点本身上：
top
df -h
* 网络连接： 节点可能已与控制平面失去网络连接。
* Docker/Containerd 问题： 节点上的容器运行时（例如 Docker、containerd）可能存在故障。
Pod 驱逐（Eviction）
Pod 可能因资源限制或其他策略驱动的事件而被从节点驱逐。
症状：
* Pod 处于 Evicted 状态。
* kubectl describe pod <pod-name> 显示 Reason: Evicted 并附有指示原因的消息（例如，the node has insufficient memory）。
原因和修复：
* 资源限制： 超过其定义的资源限制（CPU/内存）的 Pod 是被驱逐的候选者，尤其是在内存压力下。
* 节点压力： 节点可能遇到关键资源短缺（内存、磁盘、PID）。Kubernetes 的 kubelet 驱逐管理器 会积极监控这一点。
* 服务质量（QoS）类别： 较低 QoS 类别（BestEffort、Burstable）的 Pod 比 Guaranteed QoS Pod 更容易被驱逐。
预防：
* 设置资源请求和限制： 为所有容器准确定义 CPU 和内存的请求（requests）和限制（limits）。
yaml
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
* 使用节点污点（Taints）和容忍（Tolerations）： 防止不需要的 Pod 被调度到具有特定特性或资源限制的节点上。
* 监控节点资源： 实施强大的监控，以在节点资源利用率高时发出警报。
网络问题
网络是 Kubernetes 中复杂性和问题的一个常见来源。
Pod 到 Pod 通信失败
即使 Pod 在同一个节点上，它们也可能无法相互通信。
原因和修复：
* CNI 插件问题： 容器网络接口（CNI）插件（例如 Calico、Flannel、Cilium）负责 Pod 网络。检查您的 CNI Pod 的状态和日志。
bash
kubectl get pods -n kube-system -l <cni-label-selector>
kubectl logs <cni-pod-name> -n kube-system
* 网络策略（Network Policies）： 配置错误的 NetworkPolicy 资源可能会阻止合法的流量。
bash
kubectl get networkpolicy --all-namespaces
* 防火墙/安全组： 确保节点之间以及集群内部的网络安全规则允许 CNI 所需的流量。
* IP 地址管理（IPAM）： IP 地址分配问题可能导致 Pod 无法获取有效的 IP 地址或路由。
服务发现故障（DNS）
如果 Pod 无法解析服务名称，它们就无法与其他服务通信。
原因和修复：
* CoreDNS/Kube-DNS 问题： 集群的 DNS 服务（通常是 CoreDNS）可能不健康或配置错误。检查其日志和资源利用率。
bash
kubectl logs <coredns-pod-name> -n kube-system
* kubelet DNS 配置： 确保每个节点上的 kubelet 已正确配置为使用集群的 DNS 服务。这通常通过 --cluster-dns 标志设置。
* 到 DNS 的网络连接： Pod 必须能够访问 DNS 服务 IP 地址。
结论
排查 Kubernetes 集群需要有条不紊的方法，首先要识别症状，然后系统地调查相关组件。通过了解控制平面、etcd、节点和网络中的常见故障点，您可以有效地诊断和解决问题，确保 Kubernetes 环境的稳定性和性能。
关键要点：
* 监控一切： 为所有集群组件实施全面的监控。
* 检查日志： Pod 和系统日志对于查明根本原因非常有价值。
* 理解依赖关系： 认识到 etcd、API 服务器和 kubelet 等组件如何相互作用。
* 定期备份： 特别是对于 etcd，定期备份对于灾难恢复至关重要。
* 测试解决方案： 在生产环境中应用更改之前，请先在暂存环境中进行测试。