如何重启 Kubernetes 节点？答案

【问题标题】：How to restart kubernetes nodes?如何重启 Kubernetes 节点？
【发布时间】：2016-02-13 18:39:58
【问题描述】：

节点状态上报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 状态。这意味着什么以及如何解决这个问题？

【问题讨论】：

这里有完全相同的问题 :( 我能够在 VirtualBox 中删除节点，然后 kube-up.sh 将创建一个新节点。它对我的情况并没有真正的帮助，但也许会对你有所帮助
有删除节点的api吗？我不确定集群是如何设置的
哦，我什至没有问你有什么样的设置，虽然它是基于 virtualbox 的本地流浪者
这是一个物理的 linux 虚拟机，有关于如何创建新节点或重启现有节点的信息吗？
唯一的答案是如何删除节点。遇到这个问题的每个人都会寻找如何重新启动一个。我们能得到答案吗？

标签： nodes kubernetes

【解决方案1】：

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

kubectl delete node hostname.company.net

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

【讨论】：

您可能必须使用以下命令从集群中优雅地删除节点。 kubectl drain <node-name> --ignore-daemonsets --delete-local-data 然后kubectl delete node <node-name>

【解决方案2】：

获取节点

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的命令可以查看内存的详细信息，在@987654330的角色下使用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

【讨论】：

【解决方案3】：

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

/opt/azure/containers/provision.sh

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

systemctl enable kubectl
systemctl restart kubectl

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

【讨论】：

请帮助我了解删除/安装用于管理 Kubernetes 内资源的服务如何导致节点重启。这对我造成了严重破坏。

【解决方案4】：

如果节点非常不健康以至于主节点无法从中获取状态——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 杀手可能不会在节点已经变得不健康之前触发，并且无法访问。

【讨论】：

感谢您的详细解释。简而言之，如果您使用的是 aws ec2 节点，请转到控制台并重新启动它们，如果您已经解决了导致的问题，您的节点状态可能会从 NotReady 更改为 Ready。为我工作。

【解决方案5】：

我有一个本地 HA 安装，一个 master 和一个 worker 停止工作，返回 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

完成了工作。

【讨论】：

【解决方案6】：

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

（可选）关闭

$ swapoff -a
你必须重启所有 Docker 容器

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

$ kubectl get nodes
重启节点

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

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

【讨论】：

【解决方案7】：

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

【讨论】：