叢集故障排除
除錯常見的叢集問題。
本文件介紹叢集故障排除；我們假設你已排除應用程式是導致你所遇到問題的根本原因。有關應用程式除錯的提示，請參閱應用程式故障排除指南。你也可以訪問故障排除概述文件以獲取更多資訊。
有關 kubectl 的故障排除，請參閱kubectl 故障排除。
列出你的叢集
除錯叢集的第一件事是檢查你的節點是否都已正確註冊。
執行以下命令：
kubectl get nodes
並驗證你期望看到的所有節點都已存在並且它們都處於 Ready 狀態。
要獲取有關叢集整體執行狀況的詳細資訊，你可以執行
kubectl cluster-info dump
示例：除錯宕機/無法訪問的節點
有時，在除錯時檢視節點狀態可能很有用——例如，因為你注意到在該節點上執行的 Pod 有異常行為，或者要找出 Pod 無法排程到該節點的原因。與 Pod 一樣，你可以使用 kubectl describe node 和 kubectl get node -o yaml 來檢索有關節點的詳細資訊。例如，如果節點宕機（網路斷開，或者 kubelet 死亡且無法重新啟動等），你將看到以下內容。請注意顯示節點為 NotReady 的事件，還要注意 Pod 不再執行（在 NotReady 狀態持續五分鐘後它們被驅逐）。
kubectl get nodes
NAME STATUS ROLES AGE VERSION
kube-worker-1 NotReady <none> 1h v1.23.3
kubernetes-node-bols Ready <none> 1h v1.23.3
kubernetes-node-st6x Ready <none> 1h v1.23.3
kubernetes-node-unaj Ready <none> 1h v1.23.3
kubectl describe node kube-worker-1
Name: kube-worker-1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=kube-worker-1
kubernetes.io/os=linux
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 17 Feb 2022 16:46:30 -0500
Taints: node.kubernetes.io/unreachable:NoExecute
node.kubernetes.io/unreachable:NoSchedule
Unschedulable: false
Lease:
HolderIdentity: kube-worker-1
AcquireTime: <unset>
RenewTime: Thu, 17 Feb 2022 17:13:09 -0500
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
NetworkUnavailable False Thu, 17 Feb 2022 17:09:13 -0500 Thu, 17 Feb 2022 17:09:13 -0500 WeaveIsUp Weave pod has set this
MemoryPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
DiskPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
PIDPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
Ready Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status.
Addresses:
InternalIP: 192.168.0.113
Hostname: kube-worker-1
Capacity:
cpu: 2
ephemeral-storage: 15372232Ki
hugepages-2Mi: 0
memory: 2025188Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 14167048988
hugepages-2Mi: 0
memory: 1922788Ki
pods: 110
System Info:
Machine ID: 9384e2927f544209b5d7b67474bbf92b
System UUID: aa829ca9-73d7-064d-9019-df07404ad448
Boot ID: 5a295a03-aaca-4340-af20-1327fa5dab5c
Kernel Version: 5.13.0-28-generic
OS Image: Ubuntu 21.10
Operating System: linux
Architecture: amd64
Container Runtime Version: containerd://1.5.9
Kubelet Version: v1.23.3
Kube-Proxy Version: v1.23.3
Non-terminated Pods: (4 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
default nginx-deployment-67d4bdd6f5-cx2nz 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m
default nginx-deployment-67d4bdd6f5-w6kd7 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m
kube-system kube-proxy-dnxbz 0 (0%) 0 (0%) 0 (0%) 0 (0%) 28m
kube-system weave-net-gjxxp 100m (5%) 0 (0%) 200Mi (10%) 0 (0%) 28m
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1100m (55%) 1 (50%)
memory 456Mi (24%) 256Mi (13%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events:
...
kubectl get node kube-worker-1 -o yaml
apiVersion: v1
kind: Node
metadata:
annotations:
node.alpha.kubernetes.io/ttl: "0"
volumes.kubernetes.io/controller-managed-attach-detach: "true"
creationTimestamp: "2022-02-17T21:46:30Z"
labels:
beta.kubernetes.io/arch: amd64
beta.kubernetes.io/os: linux
kubernetes.io/arch: amd64
kubernetes.io/hostname: kube-worker-1
kubernetes.io/os: linux
name: kube-worker-1
resourceVersion: "4026"
uid: 98efe7cb-2978-4a0b-842a-1a7bf12c05f8
spec: {}
status:
addresses:
- address: 192.168.0.113
type: InternalIP
- address: kube-worker-1
type: Hostname
allocatable:
cpu: "2"
ephemeral-storage: "14167048988"
hugepages-2Mi: "0"
memory: 1922788Ki
pods: "110"
capacity:
cpu: "2"
ephemeral-storage: 15372232Ki
hugepages-2Mi: "0"
memory: 2025188Ki
pods: "110"
conditions:
- lastHeartbeatTime: "2022-02-17T22:20:32Z"
lastTransitionTime: "2022-02-17T22:20:32Z"
message: Weave pod has set this
reason: WeaveIsUp
status: "False"
type: NetworkUnavailable
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
lastTransitionTime: "2022-02-17T22:13:25Z"
message: kubelet has sufficient memory available
reason: KubeletHasSufficientMemory
status: "False"
type: MemoryPressure
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
lastTransitionTime: "2022-02-17T22:13:25Z"
message: kubelet has no disk pressure
reason: KubeletHasNoDiskPressure
status: "False"
type: DiskPressure
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
lastTransitionTime: "2022-02-17T22:13:25Z"
message: kubelet has sufficient PID available
reason: KubeletHasSufficientPID
status: "False"
type: PIDPressure
- lastHeartbeatTime: "2022-02-17T22:20:15Z"
lastTransitionTime: "2022-02-17T22:15:15Z"
message: kubelet is posting ready status
reason: KubeletReady
status: "True"
type: Ready
daemonEndpoints:
kubeletEndpoint:
Port: 10250
nodeInfo:
architecture: amd64
bootID: 22333234-7a6b-44d4-9ce1-67e31dc7e369
containerRuntimeVersion: containerd://1.5.9
kernelVersion: 5.13.0-28-generic
kubeProxyVersion: v1.23.3
kubeletVersion: v1.23.3
machineID: 9384e2927f544209b5d7b67474bbf92b
operatingSystem: linux
osImage: Ubuntu 21.10
systemUUID: aa829ca9-73d7-064d-9019-df07404ad448
檢視日誌
目前，深入研究叢集需要登入到相關機器。以下是相關日誌檔案的位置。在基於 systemd 的系統上，你可能需要使用 journalctl 而不是檢查日誌檔案。
控制平面節點
/var/log/kube-apiserver.log- API 伺服器，負責提供 API/var/log/kube-scheduler.log- 排程器，負責制定排程決策/var/log/kube-controller-manager.log- 執行大多數 Kubernetes 內建控制器的元件，排程（kube-scheduler 處理排程）是其顯著例外。
工作節點
/var/log/kubelet.log- kubelet 的日誌，負責在節點上執行容器/var/log/kube-proxy.log-kube-proxy的日誌，負責將流量導向服務端點
叢集故障模式
這是一份不完整的可能出錯的事情列表，以及如何調整叢集設定以緩解這些問題。
促成因素
- 虛擬機器（VM）關閉
- 叢集內部或叢集與使用者之間的網路分割槽
- Kubernetes 軟體崩潰
- 持久化儲存的資料丟失或不可用（例如 GCE PD 或 AWS EBS 卷）
- 操作員錯誤，例如，Kubernetes 軟體或應用程式軟體配置錯誤
特定場景
- API 伺服器 VM 關閉或 apiserver 崩潰
- 結果
- 無法停止、更新或啟動新的 Pod、Service、Replication Controller
- 現有的 Pod 和 Service 應繼續正常工作，除非它們依賴於 Kubernetes API
- 結果
- API 伺服器後端儲存丟失
- 結果
- kube-apiserver 元件無法成功啟動並變得健康
- kubelet 將無法訪問它，但將繼續執行相同的 Pod 並提供相同的服務代理
- 在 apiserver 重新啟動之前需要手動恢復或重新建立 apiserver 狀態
- 結果
- 支援服務（節點控制器、複製控制器管理器、排程器等）VM 關閉或崩潰
- 目前這些服務與 apiserver 共存，它們的不可用性與 apiserver 類似
- 將來，這些也將被複制，並且可能不會共存
- 它們沒有自己的持久狀態
- 單個節點（VM 或物理機）關閉
- 結果
- 該節點上的 Pod 停止執行
- 結果
- 網路分割槽
- 結果
- 分割槽 A 認為分割槽 B 中的節點已宕機；分割槽 B 認為 apiserver 已宕機。（假設主節點 VM 最終在分割槽 A 中。）
- 結果
- Kubelet 軟體故障
- 結果
- 崩潰的 kubelet 無法在節點上啟動新的 Pod
- kubelet 可能會或可能不會刪除 Pod
- 節點被標記為不健康
- Replication Controller 在其他地方啟動新的 Pod
- 結果
- 叢集操作員錯誤
- 結果
- Pod、Service 等丟失
- apiserver 後端儲存丟失
- 使用者無法讀取 API
- 等等。
- 結果
緩解措施
行動：對於 IaaS 虛擬機器，使用 IaaS 提供商的自動虛擬機器重啟功能
- 緩解：Apiserver VM 關閉或 apiserver 崩潰
- 緩解：支援服務 VM 關閉或崩潰
行動：對於帶有 apiserver+etcd 的 VM，使用 IaaS 提供商的可靠儲存（例如 GCE PD 或 AWS EBS 卷）
- 緩解：API 伺服器後端儲存丟失
行動：使用高可用性配置
- 緩解：控制平面節點關閉或控制平面元件（排程器、API 伺服器、控制器管理器）崩潰
- 將容忍一個或多個同時發生的節點或元件故障
- 緩解：API 伺服器後端儲存（即 etcd 的資料目錄）丟失
- 假設採用高可用性（HA）etcd 配置
- 緩解：控制平面節點關閉或控制平面元件（排程器、API 伺服器、控制器管理器）崩潰
行動：定期快照 apiserver PD/EBS 卷
- 緩解：API 伺服器後端儲存丟失
- 緩解：某些操作員錯誤情況
- 緩解：某些 Kubernetes 軟體故障情況
行動：在 Pod 之前使用 Replication Controller 和 Service
- 緩解：節點關閉
- 緩解：Kubelet 軟體故障
行動：設計應用程式（容器）以容忍意外重啟
- 緩解：節點關閉
- 緩解：Kubelet 軟體故障
下一步
- 瞭解資源指標管道中可用的指標
- 發現用於監控資源使用情況的其他工具
- 使用 Node Problem Detector 監控節點健康狀況
- 使用
kubectl debug node除錯 Kubernetes 節點 - 使用
crictl除錯 Kubernetes 節點 - 獲取有關Kubernetes 審計的更多資訊
- 使用
telepresence在本地開發和除錯服務
最後修改時間：2025 年 7 月 4 日太平洋標準時間晚上 11:28：新增 NodeLocalCRISocket 升級到 Beta 版的文件 (0135b1b08b)