如何调试 GKE 上的节点运行状况错误？

Question

我运行一个小型 GKE 集群，其中有几个节点池（每个节点池有 2-8 个节点，有些是可抢占的）。我开始发现节点本身存在很多健康问题，并且 Pod 操作需要很长时间（30 多分钟）。这包括终止 pod、启动 pod、启动 pod 中的 initContainer、启动 pod 中的主容器等。示例如下。 该集群运行一些 NodeJS、PHP 和 Nginx 容器，以及一个 Elastic、Redis 和 NFS Pod。另外，还有一些基于 PHP 的 CronJobs。它们一起组成了一个位于 CDN 后面的网站。

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

我尝试通过 SSH 进入支持节点的虚拟机实例来检查日志，但我的 SSH 连接总是超时，不确定这是否正常。

症状：节点在

Ready

和

NotReady

之间摆动：

$ 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 

症状：节点日志中出现各种 PLEG 运行状况错误（这种类型的条目有很多很多）：

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]

症状：Pod 发出“网络未就绪”错误：

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] 

症状：Pod 抱怨“超出上下文截止日期”：

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 未就绪的问题，阻止节点向主节点报告，主节点认为它们未就绪。

请将此视为纯粹的猜测，因为支持团队将能够更深入地挖掘并提供更准确的建议。

Answer 2

创建新节点时，由于 Pod 节点上的网络可用延迟，创建系统 Pod 可能会失败。

系统 DaemonSet 或 Pod 可以容忍集群中的所有污点，例如节点准备就绪之前设置的 NoSchedule 污点。这可能会导致以下情况：在 CNI 配置（通过 netd 或 Calico）完成之前无法在新节点上创建这些系统 Pod，但最终成功。 Pod 失败并出现“NetworkNotReady”错误。

警告 NetworkNotReady pod/XXXXX 网络未准备好：运行时网络未准备好：NetworkReady=false 原因：NetworkPluginNotReady 消息：docker：网络插件未准备好：cni config 未初始化

注意：上述 webhook 问题也可能会导致 NetworkNotReady 错误发生，因此请务必验证在这种情况下 NetworkNotReady 错误是否只会短暂出现。