如何在GKE上调试节点健康错误？

Question

我运行了一个小型GKE集群，其中有几个节点池(每个节点中有2-8个节点，有些是可抢占的)。我开始发现节点本身存在很多健康问题，需要很长时间才能完成结荚操作(30+ mins)。这包括终止荚，开始荚，启动initContainers在荚，启动主容器在荚，等等。下面的例子。这个集群运行一些NodeJS、PHP容器，以及一个Elastic和NFS。此外，一些基于PHP的CronJobs。他们一起组成了一个位于CDN后面的网站。

• 我的问题是:如何在GKE上调试它，原因是什么？

我试图将SSH放入支持节点的VM实例中，以检查日志，但我的SSH连接总是超时，不确定这是否正常。

Ready 症状：和之间的节点拍动。

$ kubectl get nodes
NAME                                    STATUS     ROLES    AGE     VERSION
gke-cluster-default-pool-4fa127c-l3xt   Ready      <none>   62d     v1.13.6-gke.13
gke-cluster-default-pool-791e6c2-7b01   NotReady   <none>   45d     v1.13.6-gke.13
gke-cluster-preemptible-0f81875-cc5q    Ready      <none>   3h40m   v1.13.6-gke.13
gke-cluster-preemptible-0f81875-krqk    NotReady   <none>   22h     v1.13.6-gke.13
gke-cluster-preemptible-0f81875-mb05    Ready      <none>   5h42m   v1.13.6-gke.13
gke-cluster-preemptible-2453785-1c4v    Ready      <none>   22h     v1.13.6-gke.13
gke-cluster-preemptible-2453785-nv9q    Ready      <none>   134m    v1.13.6-gke.13
gke-cluster-preemptible-2453785-s7r2    NotReady   <none>   22h     v1.13.6-gke.13

症状:节点有时被重新引导：

2019-08-09 14:23:54.000 CEST
Node gke-cluster-preemptible-0f81875-mb05 has been rebooted, boot id: e601f182-2eab-46b0-a953-7787f95d438

症状:集群不健康：

2019-08-09T11:29:03Z Cluster is unhealthy 
2019-08-09T11:33:25Z Cluster is unhealthy 
2019-08-09T11:41:08Z Cluster is unhealthy 
2019-08-09T11:45:10Z Cluster is unhealthy 
2019-08-09T11:49:11Z Cluster is unhealthy 
2019-08-09T11:53:23Z Cluster is unhealthy 

症状: Node 中的各种并发健康错误(这种类型的条目很多，很多)：

12:53:10.573176 1315163 kubelet.go:1854] skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m26.30454685s ago; threshold is 3m0s] 
12:53:18.126428 1036 setters.go:520] Node became not ready: {Type:Ready Status:False LastHeartbeatTime:2019-08-09 12:53:18.126363615 +0000 UTC m=+3924434.187952856 LastTransitionTime:2019-08-09 12:53:18.126363615 +0000 UTC m=+3924434.187952856 Reason:KubeletNotReady Message:PLEG is not healthy: pleg was last seen active 3m5.837134315s ago; threshold is 3m0s}
12:53:38.627284 1036 kubelet.go:1854] skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m26.338024015s ago; threshold is 3m0s]

症状:豆荚发出‘网络未准备’错误：

2019-08-09T12:42:45Z network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized] 
2019-08-09T12:42:47Z network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized] 
2019-08-09T12:42:49Z network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized] 

症状:豆荚抱怨“超过了上下文截止日期”：

2019-08-09T08:04:07Z error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded 
2019-08-09T08:04:15Z error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded 
2019-08-09T08:04:20Z error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded 
2019-08-09T08:04:26Z error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded 

显然有一些特别奇怪的事情正在进行，但是对于相当微不足道的IOPS、入口请求、cpu/内存饱和。我希望有一些症状可以指向我可以进一步调试的方向。但这些错误似乎到处都是。

Answer 1

考虑到GKE是一个受管理的解决方案，而且在它的操作中涉及到许多系统，我认为最好是与GCP支助小组联系。

他们有特定的工具来定位节点上的问题(如果有的话)，并且可以深入到日志记录中，以确定产生这种问题的根本原因。

到目前为止，您显示的日志可能指向显然与Docker有关的这个老问题，以及CNI尚未准备好的问题，从而阻止节点向主节点报告，后者认为它们还没有准备好。

请考虑这仅仅是猜测，因为支持小组将能够挖掘更深，并提供更准确的建议。