k8s集群排错指南
排查集群状态异常问题通常从 Node 和 Kubernetes 服务 的状态出发,常见的有
-
kube-apiserver 无法启动会导致
-
集群不可访问
-
已有的 Pod 和服务正常运行(依赖于 Kubernetes API 的除外)
-
-
etcd 集群异常会导致
-
kube-apiserver 无法正常读写集群状态,进而导致 Kubernetes API 访问出错
-
kubelet 无法周期性更新状态
-
-
kube-controller-manager/kube-scheduler 异常会导致
-
复制控制器、节点控制器、云服务控制器等无法工作,从而导致 Deployment、Service 等无法工作,也无法注册新的 Node 到集群中来
-
新创建的 Pod 无法调度(总是 Pending 状态)
-
-
Node 本身宕机或者 Kubelet 无法启动会导致
-
Node 上面的 Pod 无法正常运行
-
已在运行的 Pod 无法正常终止
-
-
网络分区会导致 Kubelet 等与控制平面通信异常以及 Pod 之间通信异常
查看 Node 状态
一般来说,可以首先查看 Node 的状态,确认 Node 本身是不是 Ready 状态
kubectl get nodes kubectl describe node <node-name>
如果是 NotReady 状态,则可以执行 kubectl describe node <node-name>
命令来查看当前 Node 的事件。这些事件通常都会有助于排查 Node 发生的问题。
SSH 登录 Node
在排查 Kubernetes 问题时,通常需要 SSH 登录到具体的 Node 上面查看 kubelet、docker、iptables 等的状态和日志。在使用云平台时,可以给相应的 VM 绑定一个公网 IP;而在物理机部署时,可以通过路由器上的端口映射来访问。但更简单的方法是使用 SSH Pod (不要忘记替换成你自己的 nodeName):
# cat ssh.yaml apiVersion: v1 kind: Service metadata: name: ssh spec: selector: app: ssh type: LoadBalancer ports: - protocol: TCP port: 22 targetPort: 22 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ssh labels: app: ssh spec: replicas: 1 selector: matchLabels: app: ssh template: metadata: labels: app: ssh spec: containers: - name: alpine image: alpine ports: - containerPort: 22 stdin: true tty: true hostNetwork: true nodeName: <node-name>
$ 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 user@52.52.52.52
。
在使用完后, 不要忘记删除 SSH 服务 kubectl delete -f ssh.yaml
。
查看日志
一般来说,Kubernetes 的主要组件有两种部署方法
-
直接使用 systemd 等启动控制节点的各个服务
-
使用 Static Pod 来管理和启动控制节点的各个服务
使用 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
或者直接查看日志文件
-
/var/log/kube-apiserver.log
-
/var/log/kube-scheduler.log
-
/var/log/kube-controller-manager.log
-
/var/log/kubelet.log
-
/var/log/kube-proxy.log
而对于使用 Static Pod 部署集群控制平面服务的场景,可以参考下面这些查看日志的方法。
kube-apiserver 日志
PODNAME=$(kubectl -n kube-system get pod -l component=kube-apiserver -o jsonpath='{.items[0].metadata.name}') kubectl -n kube-system logs $PODNAME --tail 100
kube-controller-manager 日志
PODNAME=$(kubectl -n kube-system get pod -l component=kube-controller-manager -o jsonpath='{.items[0].metadata.name}') kubectl -n kube-system logs $PODNAME --tail 100
kube-scheduler 日志
PODNAME=$(kubectl -n kube-system get pod -l component=kube-scheduler -o jsonpath='{.items[0].metadata.name}') kubectl -n kube-system logs $PODNAME --tail 100
kube-dns 日志
PODNAME=$(kubectl -n kube-system get pod -l k8s-app=kube-dns -o jsonpath='{.items[0].metadata.name}') kubectl -n kube-system logs $PODNAME -c kubedns
Kubelet 日志
查看 Kubelet 日志需要首先 SSH 登录到 Node 上。
journalctl -l -u kubelet
Kube-proxy 日志
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
Kube-dns/Dashboard CrashLoopBackOff
由于 Dashboard 依赖于 kube-dns,所以这个问题一般是由于 kube-dns 无法正常启动导致的。查看 kube-dns 的日志
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns $ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq $ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
可以发现如下的错误日志
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 服务器。解决方法为
-
如果使用的 Docker 版本大于 1.12,则在每个 Node 上面运行
iptables -P FORWARD ACCEPT
开启 Docker 容器的 IP 转发 -
等待一段时间,如果还未恢复,则检查 Node 网络是否正确配置,比如是否可以正常请求上游DNS服务器、是否开启了 IP 转发(包括 Node 内部和公有云上虚拟网卡等)、是否有安全组禁止了 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 https://10.0.0.1:443/api/v1/endpoints?resourceVersion=0: 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 https://10.0.0.1:443/api/v1/services?resourceVersion=0: 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
Node 处于 NotReady 状态,大部分是由于 PLEG(Pod Lifecycle Event Generator)问题导致的。社区 issue #45419 目前还处于未解决状态。
NotReady 的原因比较多,在排查时最重要的就是执行 kubectl describe node <node name>
并查看 Kubelet 日志中的错误信息。常见的问题及修复方法为:
-
Kubelet 未启动或者异常挂起:重新启动 Kubelet。
-
CNI 网络插件未部署:部署 CNI 插件。
-
Docker 僵死(API 不响应):重启 Docker。
-
磁盘空间不足:清理磁盘空间,比如镜像、临时文件等。