Kubernetes 生产级故障排查：从 Pod 崩溃到 etcd 性能调优的实战指南导读：在生产环境中，Kubernetes 集群的稳定性直接关系到业务的连续性。本文基于多年一线运维经验，系统梳理 Pod、Service、Node、存储、镜像、集群性能、etcd 等核心组件的故障排查思路，强调"先看状态 → 再看事件 → 最后定位根因"的工程化方法，助你从容应对 K8s 面试与生产故障。一、故障排查方法论：三层递进式诊断1.1 核心思路┌─────────────────────────────────────────────────────────────┐ │ Kubernetes 故障排查三层模型 │ ├─────────────────────────────────────────────────────────────┤ │ 第一层：状态层 (Status) → kubectl get 快速定位异常资源 │ │ 第二层：事件层 (Events) → kubectl describe 查看资源事件流 │ │ 第三层：根因层 (Root Cause) → logs/exec/debug 深入诊断 │ └─────────────────────────────────────────────────────────────┘1.2 排障黄金命令清单# 状态层 - 快速扫描 kubectl get pods -A --field-selector status.phase!=Running kubectl get events --sort-by='.lastTimestamp' kubectl top nodes kubectl top pods -A # 事件层 - 深度查看 kubectl describe pod pod-name -n namespace kubectl get events --field-selector involvedObject.name=pod-name # 根因层 - 精准定位 kubectl logs pod-name -c container-name --previous kubectl exec -it pod-name -- /bin/sh kubectl debug -it pod-name --image=nicolaka/netshoot二、Pod 故障排查：从 Pending 到 CrashLoopBackOff2.1 Pod 常见状态及含义状态含义排查方向PendingPod 已创建但未调度资源不足、PVC 未绑定、节点选择器ContainerCreating容器创建中镜像拉取、网络插件、存储挂载Running容器运行中应用健康检查、业务逻辑CrashLoopBackOff容器反复崩溃应用错误、配置问题、资源限制OOMKilled内存溢出被杀内存限制、内存泄漏Evicted被驱逐节点资源压力、Pod 优先级2.2 实战案例：CrashLoopBackOff 排查场景：某微服务 Pod 持续重启，状态为CrashLoopBackOff# Step 1: 查看 Pod 状态 $ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod NAME READY STATUS RESTARTS AGE payment-service-7d8f9c6b5-x2k4m 0/1 CrashLoopBackOff 15 45m # Step 2: 查看 Pod 详情和事件 $ kubectl describe pod payment-service-7d8f9c6b5-x2k4m -n prod Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 45m default-scheduler Successfully assigned prod/payment-service-7d8f9c6b5-x2k4m to node-01 Normal Pulled 45m kubelet Container image "registry.example.com/payment:v1.2.3" already present on machine Normal Created 45m kubelet Created container payment Normal Started 45m kubelet Started container payment Warning BackOff 2m (x187 over 44m) kubelet Back-off restarting failed container # Step 3: 查看容器日志（关键！） $ kubectl logs payment-service-7d8f9c6b5-x2k4m -n prod --previous Exception in thread "main" java.lang.IllegalStateException: Could not find a valid Docker environment. at com.payment.config.DockerClient.init(DockerClient.java:45) ... # Step 4: 检查资源配置 $ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod -o yaml | grep -A 10 resources resources: limits: memory: 256Mi # ⚠️ 内存限制过小 cpu: 200m requests: memory: 128Mi cpu: 100m根因分析：应用尝试初始化 Docker 客户端，但容器内无 Docker 守护进程内存限制 256Mi 可能导致 OOM解决方案：# 修复 1: 移除 Docker-in-Docker 依赖，改用 Kubernetes 原生 API apiVersion: apps/v1 kind: Deployment metadata: name: payment-service spec: template: spec: containers: - name: payment image: registry.example.com/payment:v1.2.4 # 修复版本 resources: limits: memory: 512Mi # 提升内存限制 cpu: 500m requests: memory: 256Mi cpu: 200m env: - name: KUBERNETES_SERVICE_HOST valueFrom: fieldRef: fieldPath: status.hostIP2.3 OOMKilled 专项排查# 检查 Pod 是否因 OOM 被杀 $ kubectl get pod pod-name -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}' OOMKilled # 查看历史内存使用 $ kubectl top pod pod-name --containers # 检查节点内存压力 $ kubectl describe node node-name | grep -A 5 "Allocated resources"内存限制计算公式：推荐 limit = P95 内存使用量 × 1.5 推荐 request = P50 内存使用量 × 1.2三、Service 故障排查：从 DNS 解析到负载均衡3.1 Service 连通性检查清单# 1. 检查 Service 是否存在且配置正确 kubectl get svc svc-name -n namespace -o wide # 2. 检查 Endpoints 是否有后端 Pod kubectl get endpoints svc-name -n namespace # 3. 检查 Service 标签选择器是否匹配 Pod kubectl get pods --show-labels -n namespace kubectl get svc svc-name -n namespaceg
Kubernetes 生产级故障排查：从 Pod 崩溃到 etcd 性能调优的实战指南
Kubernetes 生产级故障排查：从 Pod 崩溃到 etcd 性能调优的实战指南导读：在生产环境中，Kubernetes 集群的稳定性直接关系到业务的连续性。本文基于多年一线运维经验，系统梳理 Pod、Service、Node、存储、镜像、集群性能、etcd 等核心组件的故障排查思路，强调"先看状态 → 再看事件 → 最后定位根因"的工程化方法，助你从容应对 K8s 面试与生产故障。一、故障排查方法论：三层递进式诊断1.1 核心思路┌─────────────────────────────────────────────────────────────┐ │ Kubernetes 故障排查三层模型 │ ├─────────────────────────────────────────────────────────────┤ │ 第一层：状态层 (Status) → kubectl get 快速定位异常资源 │ │ 第二层：事件层 (Events) → kubectl describe 查看资源事件流 │ │ 第三层：根因层 (Root Cause) → logs/exec/debug 深入诊断 │ └─────────────────────────────────────────────────────────────┘1.2 排障黄金命令清单# 状态层 - 快速扫描 kubectl get pods -A --field-selector status.phase!=Running kubectl get events --sort-by='.lastTimestamp' kubectl top nodes kubectl top pods -A # 事件层 - 深度查看 kubectl describe pod pod-name -n namespace kubectl get events --field-selector involvedObject.name=pod-name # 根因层 - 精准定位 kubectl logs pod-name -c container-name --previous kubectl exec -it pod-name -- /bin/sh kubectl debug -it pod-name --image=nicolaka/netshoot二、Pod 故障排查：从 Pending 到 CrashLoopBackOff2.1 Pod 常见状态及含义状态含义排查方向PendingPod 已创建但未调度资源不足、PVC 未绑定、节点选择器ContainerCreating容器创建中镜像拉取、网络插件、存储挂载Running容器运行中应用健康检查、业务逻辑CrashLoopBackOff容器反复崩溃应用错误、配置问题、资源限制OOMKilled内存溢出被杀内存限制、内存泄漏Evicted被驱逐节点资源压力、Pod 优先级2.2 实战案例：CrashLoopBackOff 排查场景：某微服务 Pod 持续重启，状态为CrashLoopBackOff# Step 1: 查看 Pod 状态 $ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod NAME READY STATUS RESTARTS AGE payment-service-7d8f9c6b5-x2k4m 0/1 CrashLoopBackOff 15 45m # Step 2: 查看 Pod 详情和事件 $ kubectl describe pod payment-service-7d8f9c6b5-x2k4m -n prod Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 45m default-scheduler Successfully assigned prod/payment-service-7d8f9c6b5-x2k4m to node-01 Normal Pulled 45m kubelet Container image "registry.example.com/payment:v1.2.3" already present on machine Normal Created 45m kubelet Created container payment Normal Started 45m kubelet Started container payment Warning BackOff 2m (x187 over 44m) kubelet Back-off restarting failed container # Step 3: 查看容器日志（关键！） $ kubectl logs payment-service-7d8f9c6b5-x2k4m -n prod --previous Exception in thread "main" java.lang.IllegalStateException: Could not find a valid Docker environment. at com.payment.config.DockerClient.init(DockerClient.java:45) ... # Step 4: 检查资源配置 $ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod -o yaml | grep -A 10 resources resources: limits: memory: 256Mi # ⚠️ 内存限制过小 cpu: 200m requests: memory: 128Mi cpu: 100m根因分析：应用尝试初始化 Docker 客户端，但容器内无 Docker 守护进程内存限制 256Mi 可能导致 OOM解决方案：# 修复 1: 移除 Docker-in-Docker 依赖，改用 Kubernetes 原生 API apiVersion: apps/v1 kind: Deployment metadata: name: payment-service spec: template: spec: containers: - name: payment image: registry.example.com/payment:v1.2.4 # 修复版本 resources: limits: memory: 512Mi # 提升内存限制 cpu: 500m requests: memory: 256Mi cpu: 200m env: - name: KUBERNETES_SERVICE_HOST valueFrom: fieldRef: fieldPath: status.hostIP2.3 OOMKilled 专项排查# 检查 Pod 是否因 OOM 被杀 $ kubectl get pod pod-name -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}' OOMKilled # 查看历史内存使用 $ kubectl top pod pod-name --containers # 检查节点内存压力 $ kubectl describe node node-name | grep -A 5 "Allocated resources"内存限制计算公式：推荐 limit = P95 内存使用量 × 1.5 推荐 request = P50 内存使用量 × 1.2三、Service 故障排查：从 DNS 解析到负载均衡3.1 Service 连通性检查清单# 1. 检查 Service 是否存在且配置正确 kubectl get svc svc-name -n namespace -o wide # 2. 检查 Endpoints 是否有后端 Pod kubectl get endpoints svc-name -n namespace # 3. 检查 Service 标签选择器是否匹配 Pod kubectl get pods --show-labels -n namespace kubectl get svc svc-name -n namespaceg
