如何重新启动库伯氏节点？

节点的状态报告为 unknown

"conditions": [
{
"type": "Ready",
"status": "Unknown",
"lastHeartbeatTime": "2015-11-12T06:03:19Z",
"lastTransitionTime": "2015-11-12T06:04:03Z",
"reason": "Kubelet stopped posting node status."
}

当 kubectl get nodes返回 NOTReady 状态时，这意味着什么? 如何解决这个问题？

247449 次浏览
小开

您可以通过发出以下命令从主节点中删除该节点:

kubectl delete node hostname.company.net

NOTReady 状态可能意味着主服务器无法访问 kublet 服务。检查客户端是否一切正常。

小开

取出结节

kubectl get nodes

结果:

NAME            STATUS     AGE
192.168.1.157   NotReady   42d
192.168.1.158   Ready      42d
192.168.1.159   Ready      42d

描述节点

这是 192.168.1.157节点上的 还没准备好。然后调试这个不准备的节点，就可以读取官方文档 -应用程序自检和调试。

kubectl describe node 192.168.1.157

部分结果:

Conditions:
Type          Status          LastHeartbeatTime                       LastTransitionTime                      Reason                  Message
----          ------          -----------------                       ------------------                      ------                  -------
OutOfDisk     Unknown         Sat, 28 Dec 2016 12:56:01 +0000         Sat, 28 Dec 2016 12:56:41 +0000         NodeStatusUnknown       Kubelet stopped posting node status.
Ready         Unknown         Sat, 28 Dec 2016 12:56:01 +0000         Sat, 28 Dec 2016 12:56:41 +0000         NodeStatusUnknown       Kubelet stopped posting node status.

在我的节点上有一个 OutOfDisk，然后 < strong > 忽必烈停止发布节点状态。 因此，我必须释放一些磁盘空间，在我的 Ubuntu14.04上使用 df的命令我可以检查内存的细节，而在 su的作用下使用 docker rmi image_id/image_name的命令我可以删除无用的图像。

登入节点

使用 嘘(如 ssh administrator@192.168.1.157)登入 192.168.1.157，然后通过 sudo su切换到‘ su’;

重新开始

/etc/init.d/kubelet restart

结果:

stop: Unknown instance:
kubelet start/running, process 59261

再次得到结节

关于主人:

kubectl get nodes

结果:

NAME            STATUS    AGE
192.168.1.157   Ready     42d
192.168.1.158   Ready     42d
192.168.1.159   Ready     42d

好的，那个节点运行正常。

这里有一个参考: 库伯内特

小开

我也有这个问题，但它看起来像它取决于库伯内特提供和如何安装一切。在 Azure 中，如果您正在使用 acs-engine 安装，您可以找到正在运行的 shell 脚本，以便在以下位置提供该脚本:

/opt/azure/containers/provision.sh

要获得更细粒度的理解，只需通读它并运行它指定的命令。对我来说，我必须以 root 用户的身份运行:

systemctl enable kubectl
systemctl restart kubectl

我不知道是否启用是必要的，我不能说这些是否会工作与您的特定安装，但它肯定为我工作。

小开

如果一个节点非常不健康，以至于主节点无法从它获得状态—— Kubernetes也许不能重新启动该节点。如果健康检查不起作用，您还有什么希望通过 SSH 访问节点？

在这种情况下，您可能必须使用 重启——或者，如果您的硬件位于云中，则让您的提供商来完成。

例如，AWS EC2仪表板允许您右键单击一个实例以拉出“ Instance State”菜单——从该菜单可以重新启动/终止无响应的节点。

在这样做之前，您可以选择 kubectl cordon node来进行更好的测量。您可能会发现 kubectl delete node是恢复正常过程的重要组成部分——如果节点在重新启动后没有自动重新加入集群的话。

为什么节点会失去反应？可能某些资源已经耗尽，以致主机操作系统无法及时处理新的请求。这可能是磁盘或网络，但更隐蔽的情况是内存不足(OOM) ，即 Linux 处理得很差。

为了帮助 Kubernetes 安全地管理节点内存，最好执行以下两种操作:

这里的想法是为了避免与 内存过度使用相关的并发症，因为内存是 无法压缩，而 都有 Linux 和 Kubernetes 的 OOM 杀手可能不会在节点已经变得不健康和无法访问之前触发。

小开

我有一个在场的 HA 安装，一个主人和一个工人停止工作返回 NOTReady 状态。 检查节点上的 Kubelet 日志，我发现了这个问题:

failed to run Kubelet: Running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false

禁用节点上的交换

swapoff -a

然后重新开始

systemctl restart kubelet

完成了任务。

小开

在我的例子中，我使用 Hyper-V 在 VM 中运行3个节点。通过使用以下步骤，我能够在重新启动所有 VM 之后“重新启动”集群。

  1. (可选)交换

    $ swapoff -a

  2. 必须重新启动所有 Docker 容器

    $ docker restart $(docker ps -a -q)

  3. 在所有节点上执行步骤1和步骤2之后检查节点状态(状态为 还没准备好)

    $ kubectl get nodes

  4. 重启节点

    $ systemctl restart kubelet

  5. 再次检查状态(现在应该处于 准备好了状态)

注意: 我不知道它是否确实测量了节点重新启动的顺序，但是我选择从 k8s 主节点开始，然后从小黄人开始。此外，将节点状态从 NotReady 更改为 Ready 还需要一点时间

小开

在我的情况下，我使用 EKS。只需要重新启动它从控制台。


提交答案