Kubernetes 故障排除简单指南
介绍
毫无疑问，Kubernetes 在部署和管理容器化应用程序的方法上带来了标准转变。然而，无论系统设计得多么好，随着时间的推移，它们都会遇到问题。
本指南概述了 Kubernetes 部署期间最常见的故障源以及解决这些问题的方法组合。这包括资源分配调整、网络干扰、镜像拉取错误等问题，本指南将提供解决方案，以确保您的 Kubernetes 应用程序继续正常运行。
常见问题：
通过本指南，您将了解如何识别和解决 Pod、服务、Ingress 等问题。
1- 是否有待处理(pending)的 Pod？
命令：
## 获取 Pod 列表和状态
$ kubectl get pods -n namespace
可能的问题：
注意：Pod 处于
Pending状态，意味着它尚未被调度到节点上。
-
集群已满：待处理的 Pod 通常意味着集群中没有足够的资源。
-
资源配额限制：ResourceQuota 或 LimitRange 约束可能阻止调度。
-
PersistentVolumeClaims (PVCs) 问题：Pod 正在等待存储，但 PersistentVolumeClaim 未绑定到 PersistentVolume。
解决方案：
-
提供更大的集群：通过添加更多节点或调整现有节点的大小来扩展集群，以提供额外的 CPU 或内存。
-
放宽资源配额：使用新的 YAML 定义增加或调整配额。
apiVersion: v1
kind: ResourceQuota
$ kubectl edit resourcequota <quota-name>
-
修复 PersistentVolumeClaims：使用
kubectl describe pvc <PVC-Name>检查错误并确保存储类配置正确。
2. Pod 是否在运行？
命令：
kubectl describe pod <pod-name>
可能的问题：
-
节点问题：Pod 可能由于调度器或 Kubelet 问题而未分配到节点。
-
应用程序级错误：检查应用程序日志中的错误。
-
CrashLoopBackOff：由于配置错误导致的持续重启。
解决方案：
-
调度器或 Kubelet 问题：确保节点健康并检查调度器日志。同时检查 Kubelet 是否运行并具有足够的权限。
kubectl get nodes
-
应用程序错误：检查 Pod 日志
kubectl logs -f <pod-name>
-
CrashLoopBackOff：检查容器镜像或入口点问题。同时验证 Dockerfile 中的 CMD/入口点命令或检查健康检查。
3. Pod 是否准备就绪？
命令：
kubectl describe pod <pod-name>
可能的问题：
-
就绪探针失败：应用程序可能尚未准备好处理请求。
-
容器崩溃日志：如果容器终止过快，就绪探针可能会失败。
解决方案：
-
修复就绪探针：更新部署 YAML 中的就绪探针设置：
## 就绪探针文件示例
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
-
检查之前的日志：使用
kubectl logs <pod-name> --previous了解崩溃原因。
4. 应用程序是否可访问？
命令：
## 8080 是本地机器上的端口，<pod-port> 是 Pod 内的端口
kubectl port-forward <pod-name> 8080:<pod-port>
可能的问题：
-
应用程序配置错误：Pod 内的应用程序可能未配置为监听正确的端口。
-
网络问题：端口在 Kubernetes 集群或 Pod 内可能未正确暴露。
解决方案：
-
修复容器端口：确保 Pod 规范中的容器
containerPort与应用程序配置监听的端口匹配。 -
更新应用程序设置：验证应用程序是否监听
0.0.0.0而不是127.0.0.1，以允许外部连接。监听127.0.0.1意味着应用程序仅在 Pod 内部可访问，而监听0.0.0.0允许外部连接访问应用程序。
5. 服务是否运行正确？
命令：
kubectl describe service <service-name>
可能的问题：
-
端点缺失：服务选择器可能与 Pod 标签不匹配。这意味着服务无法将流量转发到正确的 Pod。
-
网络问题：服务可能没有分配 ClusterIP。没有 ClusterIP，服务在 Kubernetes 集群内没有内部 IP 地址。
解决方案：
-
修复服务选择器：确保服务 YAML 中的选择器与 Pod 标签匹配。这允许服务正确识别并路由流量到目标 Pod。
## 标签和选择器示例
selector:
app: my-app
-
调试端点：使用以下命令检查服务的端点并验证正确的 Pod 是否列出。
kubectl get endpoints
6. Ingress 是否运行正确？
命令：
## 获取指定 Ingress 资源的详细信息
$ kubectl describe ingress <ingress-name>
可能的问题：
-
服务配置错误：Ingress 可能未指向正确的服务，这意味着它无法将流量路由到正确的应用程序。
-
后端问题：Ingress 可能无法将流量路由到后端服务，这可能是由于配置错误或后端服务本身的问题。
解决方案：
-
修复 Ingress 设置：更新 Ingress YAML 中的
serviceName和servicePort以匹配目标服务。这确保流量正确路由到目标服务。
backend:
serviceName: my-service
servicePort: 8080
-
调试 Ingress 控制器：检查 Ingress 控制器的日志以识别任何错误或问题。不同的 Ingress 控制器（例如 NGINX）在集群中运行特定的 Pod 来管理 Ingress 资源。
kubectl logs <ingress-controller-pod>
7. 常见的镜像拉取问题
命令：
kubectl describe pod <pod-name>
可能的问题：
-
私有仓库访问：从私有仓库拉取镜像可能会失败，如果 Kubernetes 集群没有访问该仓库的权限。这是因为未提供必要的凭据。
-
错误的镜像标签：使用无效或不存在的镜像标签会导致问题。如果指定的标签在仓库中不存在，镜像拉取将失败。
解决方案：
-
配置 imagePullSecrets：如果您尝试从私有仓库拉取镜像，您需要在部署 YAML 中配置
imagePullSecrets。这为 Kubernetes 提供了访问私有仓库所需的凭据。
imagePullSecrets:
- name: my-registry-secret
-
验证镜像可用性：检查镜像是否存在于仓库中并确保使用正确的标签。
8. PersistentVolumeClaim 问题
命令：
kubectl describe pvc <pvc-name>
可能的问题：
-
存储类配置错误：请求的存储类可能不存在或指定错误。如果存储类未正确定义，PVC 将无法绑定到 PersistentVolume。
-
存储不足：集群可能没有足够的可用存储来满足 PVC 请求。如果没有任何 PV 具有足够的容量或命名空间的存储配额已耗尽，可能会发生这种情况。
解决方案：
-
修复存储类：确保 PVC 中指定的存储类正确且存在于您的集群中。需要在 PVC yaml 中检查存储类名称并确保其与现有存储类匹配。
storageClassName: storage-class-
提供更多存储：如果存储不足，需要向集群添加更多存储容量或调整现有声明。这可能涉及创建具有所需容量的新 PV 或调整现有卷的大小（如果存储提供商支持）。
9. 查看集群事件
-
排除 Kubernetes 集群故障的第一步是检查集群内发生的事件。
-
以下命令提供所有命名空间的所有事件，允许您发现与 Pod、节点和其他资源相关的错误、警告和问题。
$ kubectl get events --all-namespaces
10. 检查节点状态
-
节点是 Kubernetes 集群的骨干。要确保一切运行顺利，请执行以下命令查看所有节点的状态。
## 列出集群中的所有节点及其当前状态
$ kubectl get nodes
-
Ready：表示节点健康并准备好接受和运行容器。
-
NotReady：节点存在问题，无法运行容器，例如资源限制或网络问题。
-
SchedulingDisabled：节点被标记为不可调度，适用于维护或故障排除。
-
Unknown：由于与 Kubernetes 控制平面的通信问题，节点状态未知。
11. 资源指标
-
资源使用指标对于识别性能问题至关重要。
-
它们提供 CPU 和内存使用的实时洞察。
## 监控节点的 CPU 和内存使用情况：
$ kubectl top nodes
## 查看特定命名空间中 Pod 的资源使用指标
$ kubectl top pods -n my-namespace