如何重启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

描述节点

这是192.168.1.157节点上的NotReady。然后调试这个notready节点，你就可以阅读官方文档了- Application Introspection and Debugging。

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

登录节点

使用ssh登录192.168.1.157，就像ssh administrator@192.168.1.157一样，并使用sudo su切换到'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

您可以通过执行以下命令从master中删除该节点：

kubectl delete node hostname.company.net

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

Answer 3

如果一个节点非常不健康，以至于主机无法从它获取状态-- Kubernetes可能无法重新启动该节点。如果运行状况检查不起作用，那么通过SSH访问节点又有什么希望呢？

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

例如，亚马逊网络服务EC2仪表板允许你右击一个实例来弹出一个“实例状态”菜单--你可以在这个菜单中重启/终止一个没有响应的节点。

在执行此操作之前，您可能会选择kubectl cordon node。您可能会发现kubectl delete node是恢复正常的过程中的重要部分--如果节点在重新引导后不能自动重新加入集群。

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

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

为系统

• Reserve一些内存。
• 对于pods的机会主义内存规格要非常小心(避免)。换句话说，不允许内存使用不同的requests and limits值。

这里的想法是为了避免与memory overcommit相关的复杂情况，因为内存是面向对象的( incompressible )，并且在节点已经变得不健康和不可访问之前，Linux和Kubernetes的面向对象模型杀手可能不会触发。