k8s集群排錯指南

排查集群狀態異常問題通常從 node 和 kubernetes 服務的狀態出發，常見的有

etcd 集群異常會導致

kube-controller-manager/kube-scheduler 異常會導致

node 本身宕機或者 kubelet 無法啟動會導致

網路分割槽會導致 kubelet 等與控制平面通訊異常以及 pod 之間通訊異常

一般來說，可以首先檢視 node 的狀態，確認 node 本身是不是 ready 狀態

kubectl get nodes

kubectl describe node

如果是 notready 狀態，則可以執行kubectl describe node命令來檢視當前 node 的事件。這些事件通常都會有助於排查 node 發生的問題。

在排查 kubernetes 問題時，通常需要 ssh 登入到具體的 node 上面檢視 kubelet、docker、iptables 等的狀態和日誌。在使用雲平台時，可以給相應的 vm 繫結乙個公網 ip；而在物理機部署時，可以通過路由器上的埠對映來訪問。但更簡單的方法是使用 ssh pod （不要忘記替換成你自己的 nodename）：

# cat ssh.yaml

apiversion: v1

kind: service

metadata:

name: ssh

spec:

selector:

type: loadbalancer

ports:

- protocol: tcp

port: 22

targetport: 22

---apiversion: extensions/v1beta1

kind: deployment

metadata:

name: ssh

labels:

spec:

replicas: 1

selector:

matchlabels:

template:

metadata:

labels:

spec:

containers:

- name: alpine

image: alpine

ports:

- containerport: 22

stdin: true

tty: true

hostnetwork: true

nodename:

$ kubectl create -f ssh.yaml

$ kubectl get svc ssh

name type cluster-ip external-ip port(s) age

ssh loadbalancer 10.0.99.149 52.52.52.52 22:32008/tcp 5m

接著，就可以通過 ssh 服務的外網 ip 來登入 node，如ssh [email protected]。

在使用完後，不要忘記刪除 ssh 服務kubectl delete -f ssh.yaml。

一般來說，kubernetes 的主要元件有兩種部署方法

使用 systemd 等管理控制節點服務時，檢視日誌必須要首先 ssh 登入到機器上，然後檢視具體的日誌檔案。如

journalctl -l -u kube-apiserver

journalctl -l -u kube-controller-manager

journalctl -l -u kube-scheduler

journalctl -l -u kubelet

journalctl -l -u kube-proxy

或者直接檢視日誌檔案

而對於使用 static pod 部署集群控制平面服務的場景，可以參考下面這些檢視日誌的方法。

podname=$(kubectl -n kube-system get pod -l component=kube-apiserver -o jsonpath='')
kubectl -n kube-system logs $podname --tail 100

podname=$(kubectl -n kube-system get pod -l component=kube-controller-manager -o jsonpath='')
kubectl -n kube-system logs $podname --tail 100

podname=$(kubectl -n kube-system get pod -l component=kube-scheduler -o jsonpath='')
kubectl -n kube-system logs $podname --tail 100

kubectl -n kube-system logs $podname -c kubedns

檢視 kubelet 日誌需要首先 ssh 登入到 node 上。

journalctl -l -u kubelet

kube-proxy 通常以 daemonset 的方式部署

$ kubectl -n kube-system get pod -l component=kube-proxy

name ready status restarts age

kube-proxy-42zpn 1/1 running 0 1d

kube-proxy-7gd4p 1/1 running 0 3d

kube-proxy-87dbs 1/1 running 0 4d

$ kubectl -n kube-system logs kube-proxy-42zpn

由於 dashboard 依賴於 kube-dns，所以這個問題一般是由於 kube-dns 無法正常啟動導致的。檢視 kube-dns 的日誌

可以發現如下的錯誤日誌

waiting for services and endpoints to be initialized from apiserver...

skydns: failure to forward request "read udp 10.240.0.18:47848->168.63.129.16:53: i/o timeout"

timeout waiting for initialization

這說明 kube-dns pod 無法** dns 請求到上游 dns 伺服器。解決方法為

如果錯誤日誌中不是** dns 請求超時，而是訪問 kube-apiserver 超時，比如

e0122 06:56:04.774977 1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: failed to list *v1.endpoints: get dial tcp 10.0.0.1:443: i/o timeout

i0122 06:56:04.775358 1 dns.go:174] waiting for services and endpoints to be initialized from apiserver...

e0122 06:56:04.775574 1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: failed to list *v1.service: get dial tcp 10.0.0.1:443: i/o timeout

i0122 06:56:05.275295 1 dns.go:174] waiting for services and endpoints to be initialized from apiserver...

i0122 06:56:05.775182 1 dns.go:174] waiting for services and endpoints to be initialized from apiserver...

i0122 06:56:06.275288 1 dns.go:174] waiting for services and endpoints to be initialized from apiserver...

這說明 pod 網路（一般是多主機之間）訪問異常，包括 pod->node、node->pod 以及 node-node 等之間的往來通訊異常。可能的原因比較多，具體的排錯方法可以參考

node 處於 notready 狀態，大部分是由於 pleg（pod lifecycle event generator）問題導致的。社群 issue #45419

目前還處於未解決狀態。

notready 的原因比較多，在排查時最重要的就是執行kubectl describe node並檢視 kubelet 日誌中的錯誤資訊。常見的問題及修復方法為：

k8s集群排錯指南

k8s 集群概念

K8S 集群安裝

K8S集群安裝

k8s集群排錯指南

k8s 集群概念

K8S 集群安裝

K8S集群安裝

相關推薦