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命令我可以查看内存的详细信息，并使用docker rmi image_id/image_name下的命令su的作用我可以删除无用的图像。

登录节点

使用 ssh 登录192.168.1.157，例如ssh administrator@192.168.1.157，然后切换到＆＃39; su＆＃39; 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

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

var edge = {
  s: sourceVertex,
  d: destinationVertex,
  tag: "n"   // the tag will define the type of relation
  // again you can use strings: 'n' - `needs` and 'p' - `prohibits`
  // or whatever type you like       
};

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

Answer 3

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

（可选）交换

$ swapoff -a
您必须重新启动所有Docker容器

$ docker restart $(docker ps -a -q)
在所有节点上执行步骤1和2之后检查节点状态（状态为未就绪）

$ kubectl get nodes
重新启动节点

$ systemctl restart kubelet
再次检查状态（现在应该处于 Ready 状态）

注意：：我不知道它是否确实满足了节点重启的顺序，但是我选择从k8s主节点开始，然后从奴才开始。另外，将节点状态从NotReady更改为Ready

Answer 4

我也有这个问题，但看起来它取决于Kubernetes产品以及所有产品的安装方式。在Azure中，如果您使用的是acs-engine安装，则可以找到实际运行的shell脚本，以便在以下位置进行配置：

/opt/azure/containers/provision.sh

要获得更细粒度的理解，只需仔细阅读并运行它指定的命令即可。对我来说，我必须以root身份运行：

systemctl enable kubectl
systemctl restart kubectl

我不知道启用是否必要，我不能说这些是否适用于您的特定安装，但它确实对我有用。

Answer 5

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

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

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

在执行此操作之前，您可以选择kubectl cordon node以取得良好的效果。而且，您可能会发现kubectl delete node是使事情恢复正常的过程的重要组成部分-如果节点在重启后没有自动重新加入群集。

为什么节点将变得无响应？某些资源可能已用尽，无法阻止主机操作系统及时处理新请求。这可能是磁盘，也可能是网络，但是更阴险的是内存不足（OOM），Linux handles poorly。

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

Reserve为系统保留一些内存。
请特别小心（避免）用于Pod的机会内存规范。换句话说，请勿将requests and limits的其他值用于存储。

这里的想法是避免与memory overcommit相关的复杂性，因为内存为incompressible，并且两者 Linux和Kubernetes的OOM杀手可能不会在节点拥有之前触发已经变得不健康和无法到达。

Answer 6

GET all Nodes

kubectl get nodes

状态为not ready的检查节点

您只需删除该节点并创建新节点并将其加入群集

Kubectl delete node <node name>

如果您使用的是AWS EKS之类的管理服务，它将附带新的节点您也可以从AWS控制台重新启动节点（ec2）重新启动。

Answer 7

运行以下命令以关闭节点上的交换。它对我有用。

 swapoff -a

Answer 8

就我而言，我使用的是 EKS。只需要从 aws 控制台重新启动它。

Answer 9

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

完成工作了。

如何重启kubernetes节点？

9 个答案:

获取节点

描述节点

登录节点

重新启动kubelet

再次获取节点