即使节点上的所有Pod都“行为良好”,我的Kubernetes Engine集群仍会继续重新引导我的一个节点。我试图查看集群的Stackdriver日志,但找不到原因。一段时间后,连续重启通常会停止,直到几小时或几天后才会再次发生。
通常只影响一个节点,而其他节点都很好,但是删除该节点并在其位置创建一个新节点只是暂时的。
我已经禁用了节点自动修复功能,以查看是否有所作为(之前已打开),并且如果我没记错的话,这是在将群集升级到Kubernetes 1.13(特别是版本1.13.5-gke
)之后开始的。升级到1.13.6-gke.0
后,该问题仍然存在。甚至创建一个新的节点池并迁移到它都没有效果。
集群由四个节点组成,每个节点具有1个CPU和3 GB RAM。我知道这对于k8s集群来说很小,但这在过去一直很好。
我正在使用新的Stackdriver Kubernetes Monitoring以及GKE上的Istio。
任何有关可能是什么原因或我在哪里寻找可能原因的指针都将不胜感激。
Node事件列表的屏幕截图(乐于提供其他日志;在Stackdriver Logging中找不到有意义的东西)
答案 0 :(得分:0)
将此答案发布为社区Wiki,以提供一些故障排除提示/步骤,因为未发现根本问题。
随意扩展它。
执行以下步骤后,不再存在节点重新启动的问题:
GKE
)Istio
e2-medium
个实例作为节点。@aurelius用户指出:
我将从发布
kubectl describe node
开始,也许在您的Node重新启动且运行不正常之前发生了一些事情。您还会使用资源和限制吗?重新启动是否可能是由于某些突发工作负载导致的?您还尝试过在节点本身重新启动后检查系统日志吗?您可以发布结果吗? – aurelius 19年6月7日15:38
以上注释可能是解决群集问题的一个很好的起点。
对群集中注释的群集进行故障排除的选项:
$ kubectl describe node
专注于以下方面的输出:
Conditions
-KubeletReady
,KubeletHasSufficientMemory
,KubeletHasNoDiskPressure
等Allocated resources
-预定工作量的Requests
和Limits
GCP Cloud Console
(Web用户界面)-> Logging
-> Legacy Logs Viewer
/ Logs Explorer
-> VM Instance
/ GCE Instance
在以下位置检查CPU
/ RAM
的使用也可能是有益的:
GCP Cloud Console
(Web用户界面)-> Monitoring
-> Metrics Explorer
您还可以检查集群上是否有任何操作:
gcloud container operations list
加上以上几点:
在GKE上使用Istio创建集群
我们建议在使用此附加组件时,至少使用2个vCPU计算机类型创建一个 4个节点群集。您可以使用默认的GKE新群集设置来部署Istio本身,但这可能无法提供足够的资源来探索示例应用程序。
此外,Istio的官方文档也指出:
CPU和内存
由于sidecar代理在数据路径上执行其他工作,因此会占用CPU和内存。从Istio 1.7开始,代理每秒钟每1000个请求消耗 0.5个vCPU。
- Istio.io: Docs: Performance and scalability: CPU and memory
其他资源: