我正在GKE上运行一个集群，有时我会进入挂起状态。现在我只使用两个节点并允许群集自动缩放。其中一个节点具有NotReady状态，只是停留在其中。因此，由于CPU不足，我的一半pod正在等待。
我部署了一个从启动时起就拥有相当高CPU使用率的pod。当我将其缩放到2时，我注意到CPU使用率为1.0;在我将部署扩展到3个副本的那一刻，我希望第三个处于Pending状态，直到集群添加另一个节点，然后在那里安排它。
相反，节点切换到NotReady状态，其上的所有pod现在都处于Pending状态。
但是，节点没有重启或任何东西 - 它只是不被Kubernetes使用。然后GKE认为有足够的资源，因为VM有0 CPU使用率，并且不会扩展到3。
我无法从控制台手动SSH到实例 - 它卡在加载循环中。
我可以手动删除该实例，然后它开始工作 - 但我不认为这是完全管理的想法。
我注意到的一件事 - 不确定是否相关：在GCE控制台中，当我查看VM实例时，实例组和负载均衡器（即服务）正在使用Ready节点围绕nginx入口点），但NotReady节点仅由实例组使用 - 而不是负载均衡器。
此外，在kubectl get events中，有一行：
Warning CreatingLoadBalancerFailed {service-controller } Error creating load balancer (will retry): Failed to create load balancer for service default/proxy-service: failed to ensure static IP 104.199.xx.xx: error creating gce static IP address: googleapi: Error 400: Invalid value for field 'resource.address': '104.199.xx.xx'. Specified IP address is already reserved., invalid
我在代理服务的定义中指定了loadBalancerIP: 104.199.xx.xx，以确保每次重启时服务都获得相同（保留）的静态IP。
有关如何防止这种情况发生的任何想法？因此，如果一个节点陷入NotReady状态，它至少会重新启动 - 但理想情况下不会进入这种状态开始？
感谢。
答案 0 :(得分：6)
我要做的第一件事是为这些pod定义资源和限制。
资源告诉集群您认为该pod将使用多少内存和CPU。这样做是为了帮助调度程序找到运行这些pod的最佳位置。
限制在这里至关重要：它们设置为防止您的pod损坏节点的稳定性。由于资源匮乏，最好让一个OOM被一个OOM杀死而不是一个使节点停机的pod。
例如，在这种情况下，你说要为你的pod要200m CPU（20％），但是如果它有机会超过300（30％），你希望调度程序杀掉它并启动一个新的之一。
bin您可以在此处阅读更多内容：http://kubernetes.io/docs/admin/limitrange/
答案 1 :(得分：0)
我可以告诉AWS。 由于内存不足或CPU不足，它进入了NotReady状态。您可以创建一个自定义内存指标，以收集群集中所有工作节点的内存指标，并将其推送到cloudwatch。 您可以遵循此文档-https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html CPU指标已经存在，因此无需创建它。因此，将为您的群集创建一个内存指标。现在，当警报超过特定阈值时，您可以为其创建警报。现在，您必须通过AWS控制台转到Auto Scaling组。现在，您必须为自动伸缩组添加一个伸缩策略，选择创建的警报并相应地添加实例数。