K8s node 断开连接后，在该 node 中运行的 Pod 会如何？
由于各种原因，工作节点与主节点断开连接的情况会经常发生。在这种情况下，其实有很多问题，例如，主节点是否删除了在无法连接的节点上运行的 Pod？Kubernetes 控制器的行为如何？Pod 是否在工作节点上继续运行？简而言之，我们想知道当节点变得不可访问时，Kubernetes 系统行为是什么样子的？
定义：在 Kubernetes 中，无法连接的节点称为隔离节点（partitioned node）。
为了具体了解，让我们创建一个隔离节点案例并了解其行为。
示例集群
示例集群具有一个主节点（master node）和 3 个工作节点（worker node）。这里创建了具有 2 个副本的 Nginx Deployment。这些副本在不同的节点上运行：kind-worker2 和 kind-worker3。图 1 展示了示例集群的状态：
图1：示例集群的状态
创建一个隔离节点
创建一个隔离节点的简单方法是删除节点的 IP 地址，即 kind-worker2。（或者直接将该 node 虚拟机关机也可以模拟 node 断网的情况）图 2 展示了必要的步骤：
图2：创建一个隔离节点
![]()
Kubernetes 系统的表现如何？
Kubernetes 系统的表现如何？工作节点（kind-worker2）被设置为 NotReady 状态，但 Pod 仍在继续运行，这是因为负责节点的 kube-controller-manager 的 node-controller 部分在等待 pod-eviction-timeout，这是确保在 Pod 删除之前该节点是无法访问的。
pod-eviction-timeout 默认设置为 5 分钟，可以在 kube-controller-manager 启动过程中对这个参数进行修改。kube-controller-manager 所有启动参数可以在这里找到。
在 pod-eviction-timeout（示例中为 5 分钟）之后，node-controller 将在隔离节点上运行的 pod 调度为 Terminating 状态。kube-controller-manager 的 Deployment Controller 部分开始在不同的节点上创建新的副本和调度。在示例中，我们在 kind-worker 节点上创建了一个 Nginx 副本。图 3 展示了 Kubernetes 系统上的所有状态更改：
图 3：主节点上的情况
隔离工作节点上运行的 Pod 会如何？
进入隔离工作节点，让我们看看发生了什么。从图 4 中，我们可以观察到 Pod 还在继续运行，这是因为 API server 无法与隔离节点的 Kubelet 通信来删除 Pod。同样，Kubelet 也无法控制运行哪些 Pod。
图 4：Pod 继续在隔离工作节点上运行
一旦隔离节点重新加入集群，处于“Terminating”状态的 Pod （也就是之前隔离节点中的 pod） 就会被自动删除。（也称为 Pod 被驱逐）
总结
当节点断开连接后，很多事情都在背后发生，以下是简单的总结：
- 当节点变得不可访问时，主节点会将节点设置为“NotReady”状态。
- 主节点在执行任何操作之前会等待 pod-eviction-timeout。作为 kube-controller-manager 引导过程的一部分，默认情况下，pod-eviction-timeout 参数设置为 5 分钟。
- 在 pod-eviction-timeout 时间之后，主节点的隔离节点 Pod 处于“Terminating”状态，并且 deployment 会在其他节点上创建 Pod 新实例（假设这个 pod 原来就是 deployment 创建的）。
- 这些 Pod 会继续在隔离节点上运行。但是一旦隔离节点重新加入集群，这些处于“Terminating”状态的 Pod 就会被自动删除。
更多与 pod 驱逐有关的内容，建议阅读 nodeLifecycleController 相关的内容。同时建议阅读官网这篇文章：Nodes | Kubernetes。
