如何重启kubernetes节点？

Question

节点的状态报告为 unknown

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

whle kubectl get nodes返回NOTReady状态.这意味着什么以及如何解决这个问题？

Answer 1

获取节点

kubectl get nodes

结果:

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

描述节点

这是节点上的NotReady192.168.1.157.然后调试这个notready节点,你可以阅读官方文档 - 应用程序内省和调试.

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,然后Kubelet停止发布节点状态. 所以,我必须释放一些磁盘空间,使用df我的Ubuntu14.04上的命令我可以检查内存的细节,并使用命令docker rmi image_id/image_name下的角色su我可以删除无用的图像.

登录节点

登录在192.168.1.157通过使用ssh的一样ssh administrator@192.168.1.157,并切换到"素"通过sudo su;

重新启动kubelet

/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

好的,该节点工作正常.

这是一个参考:Kubernetes

Answer 2

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

kubectl delete node hostname.company.net

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

Answer 3

如果节点非常不健康，以至于主节点无法从中获取状态——Kubernetes可能无法重新启动节点。如果健康检查不起作用，您希望通过 SSH 访问节点吗？

在这种情况下，您可能需要硬重启——或者，如果您的硬件在云中，让您的提供商来做。

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

在执行此操作之前，您可能会选择kubectl cordon node进行测量。您可能会发现kubectl delete node这是让事情恢复正常的过程的重要组成部分——如果节点在重新启动后没有自动重新加入集群。

为什么节点会变得无响应？可能某些资源已以某种方式耗尽，从而阻止主机操作系统及时处理新请求。这可能是磁盘或网络——但更阴险的情况是内存不足(OOM)，Linux 处理得不好。

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

• 为系统预留一些内存。
• 对 pod 的（避免）机会性内存规范要非常小心。换句话说，不允许内存的requests和limits不同的值。

这里的想法是，以避免与相关的并发症内存过量使用，因为内存是不可压缩的，而这两个Linux和Kubernetes' OOM杀手可以在节点之前未触发已成为不健康和不可达。

Answer 4

我有一个本地 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

并重新启动 kubelet

systemctl restart kubelet

做了工作。

Answer 5

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

1. （可选）换掉

   $ swapoff -a

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

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

3. 在所有节点上执行步骤 1 和 2 后检查节点状态（状态为NotReady）

   $ kubectl get nodes

4. 重启节点

   $ systemctl restart kubelet

5. 再次检查状态（现在应该处于就绪状态）

注意：我不知道它是否符合节点重新启动的顺序，但我选择从 k8s 主节点开始，然后是从属节点。将节点状态从 NotReady 更改为 Ready 也需要一点时间