要解决和了解节点状态为何会发生异常需要先了解k8s体系组件的基本知识与原理
在k8s容器集群运行过程，时长遇到节点运行状态异常的问题和因为组件异常、系统内核死锁、资源不足等原因引起节点状态不可知。
该问题可能的原因有：

1.节点停机
2.节点组件kubelet异常
3.节点docker异常
4.节点的systemd的版本过低触发pleg的bug (低版本的systemd (67版本之前)，dbus的cookie溢出，导致docker、kubelet组件无法正常运行，包括runc 夯死等
5.网络有拦截
6.节点pid满导致

通用思路：

1.查看kubectl describe node 信息（注意是完整的describe信息）
2.查看节点docker、kubelet状态，查看系统docker命令行是否卡
3.查看节点系统的messge日志的异常信息
4.查看节点的资源使用情况，和整体负载情况，是否有资源不足
5.查看pid使用情况，ps -eTf |wc -l 和节点pid配置

开源集群情况：
开源集群排查集群状态异常问题通常从 Node 和 Kubernetes 服务 的状态出发，定位出具体的异常服务，再进而寻找解决方法。集群状态异常可能的原因比较多，常见的有

虚拟机或物理机宕机
网络分区
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 之间通信异常
为了维持集群的健康状态，推荐在部署集群时就考虑以下

在云平台上开启 VM 的自动重启功能
为 Etcd 配置多节点高可用集群，使用持久化存储（如 AWS EBS 等），定期备份数据
为控制平面配置高可用，比如多 kube-apiserver 负载均衡以及多节点运行 kube-controller-manager、kube-scheduler 以及 kube-dns 等
尽量使用复制控制器和 Service，而不是直接管理 Pod
跨地域的多 Kubernetes 集群
查看日志
一般来说，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
等待一段时间，如果还未恢复，则检查 Node 网络是否正确配置，比如是否可以正常请求上游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 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 等之间的往来通信异常。可能的原因比较多，具体的排错方法可以参考网络异常排错指南。

Kubelet: failed to initialize top level QOS containers
重启 kubelet 时报错 Failed to start ContainerManager failed to initialise top level QOS containers（参考 #43856），临时解决方法是：

在 docker.service 配置中增加 --exec-opt native.cgroupdriver=systemd 选项。
重启主机

案例参考：

集群状态异常logs出现cgroup驱动问题参考：
https://github.com/kubernetes/kubernetes/issues/76531

Flannel / iptables: resource temporarily unavailable
资源临时不可用，参考:https://github.com/kubernetes/kubernetes/issues/88148

pid上限问题参考：https://blog.csdn.net/weixin_30382087/article/details/116616893
注意系统和pod的pid都需要查

具有大量文件的应用程序可能会导致 K8s 节点 DoS,例如在接待您出现问题时出现如下类似日志提示：

... code = ResourceExhausted desc = grpc: trying to send message larger than max (21922673 vs. 16777216)

参考：https://github.com/paketo-buildpacks/spring-boot/issues/80