Kubernetes 常見錯誤

Pod 異常

1. OOMKilled: Pod 的內存使用超出了 resources.limits 中的限制，被強制殺死。
2. CrashLoopBackoff: Pod 進入 崩潰-重啟循環，重啟間隔時間從 10 20 40 80 一直翻倍到上限 300 秒，然后以 300 秒為間隔無限重啟。
3. Pod 一直 Pending: 這說明沒有任何節點能滿足 Pod 的要求，容器無法被調度。比如端口被別的容器用 hostPort 占用，節點有污點等。
4. FailedCreateSandBox: Failed create pod sandbox: rpc error: code = DeadlineExceeded desc = context deadline exceeded：很可能是 CNI 網絡插件的問題（比如 ip 地址溢出），
5. SandboxChanged: Pod sandbox changed, it will be killed and re-created: 很可能是由於內存限制導致容器被 OOMKilled，或者其他資源不足
6. FailedSync: error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded: 常和前兩個錯誤先后出現，很可能是 CNI 網絡插件的問題。
7. 開發集群，一次性部署所有服務時，各 Pod 互相爭搶資源，導致 Pod 生存探針失敗，不斷重啟，重啟進一步加重資源使用。惡性循環。
   • 需要給每個 Pod 加上 resources.requests，這樣資源不足時，后續 Pod 會停止調度，直到資源恢復正常。
8. Pod 出現大量的 Failed 記錄，Deployment 一直重復建立 Pod: 通過 kubectl describe/edit pod <pod-name> 查看 pod Events 和 Status，一般會看到失敗信息，如節點異常導致 Pod 被驅逐。

• Kubernetes 問題排查：Pod 狀態一直 Terminating

節點異常

1. DiskPressure：節點的可用空間不足。（通過df -h 查看，保證可用空間不小於 15%）
2. The node was low on resource: ephemeral-storage: 同上，節點的存儲空間不夠了。

網絡異常

1. Ingress/Istio Gateway 返回值

1. 404：不存在該 Service/Istio Gateway
2. 503：Service 對應的 Pods NotReady
3. 504：主要有兩種可能
   1. 考慮是不是 Ingress Controller 的 IP 表未更新，將請求代理到了不存在的 Pod ip，導致得不到響應。
   2. Pod 響應太慢，代碼問題。

Ingress 相關網絡問題的排查流程：

1. Which ingress controller?
2. Timeout between client and ingress controller, or between ingress controller and backend service/pod?
3. HTTP/504 generated by the ingress controller, proven by logs from the ingress controller?
4. If you port-forward to skip the internet between client and ingress controller, does the timeout still happen?

kubectl/istioctl 等客戶端工具異常

1. socat not found: kubectl 使用 socat 進行端口轉發，集群的所有節點，以及本機都必須安裝有 socat 工具。

參考

• Kubernetes管理經驗
• 504 Gateway Timeout when accessing workload via ingress