关于kubernetes:K8s-节点断开连接后本在运行的-Pod-会如何

45次阅读

共计 1361 个字符,预计需要花费 4 分钟才能阅读完成。

因为各种起因,工作节点与主节点断开连接的状况会常常产生。在这种状况下,其实有很多问题,例如,主节点是否删除了在无奈连贯的节点上运行的 Pod?Kubernetes 控制器的行为如何?Pod 是否在工作节点上持续运行?简而言之,咱们想晓得当节点变得不可拜访时,Kubernetes 零碎行为是什么样子的?

定义:在 Kubernetes 中,无奈连贯的节点称为隔离节点(partitioned node)。

为了具体理解,让咱们创立一个隔离节点案例并理解其行为。

K8sMeetup

示例集群

示例集群具备一个主节点(master node)和 3 个工作节点(worker node)。这里创立了具备 2 个正本的 Nginx Deployment。这些正本在不同的节点上运行:kind-worker2 和 kind-worker3。图 1 展现了示例集群的状态:

图 1:示例集群的状态

K8sMeetup

创立一个隔离节点

创立一个隔离节点的简略办法是删除节点的 IP 地址,即 kind-worker2。图 2 展现了必要的步骤:

图 2:创立一个隔离节点

K8sMeetup

Kubernetes 零碎的体现如何?

工作节点(kind-worker2)被设置为 NotReady 状态,但 Pod 仍在持续运行,这是因为负责节点的 kube-controller-manager 的 node-controller 局部在期待 pod-eviction-timeout,这是确保在 Pod 删除之前该节点是无法访问的。

pod-eviction-timeout 默认设置为 5 分钟,能够在 kube-controller-manager 启动过程中进行批改。

在 pod-eviction-timeout(示例中为 5 分钟)之后,node-controller 将在隔离节点上运行的 pod 调度为 Termination 状态。kube-controller-manager 的 Deployment Controller 局部开始在不同的节点上创立新的正本和调度。在示例中,咱们在 kind-worker 节点上创立了一个 Nginx 正本。图 3 展现了 Kubernetes 零碎上的所有状态更改:

图 3:主节点上的状况

K8sMeetup

隔离工作节点上运行的 Pod 会如何?

进入隔离工作节点,让咱们看看产生了什么。从图 4 中,咱们能够察看到 Pod 还在持续运行,这是因为 API server 无奈与隔离节点的 Kubelet 通信来删除 Pod。同样,Kubelet 也无法控制运行哪些 Pod。

图 4:Pod 持续在隔离工作节点上运行

一旦隔离节点退出集群,Pod 就能删除。

K8sMeetup

总结

当节点断开连接后,很多事件都在背地产生,以下是简略的总结:

  • 当节点变得不可拜访时,主节点会将节点设置为“NotReady”状态。
  • 主节点在执行任何操作之前会期待 pod-eviction-timeout。作为 kube-controller-manager 疏导过程的一部分,默认状况下,pod-eviction-timeout 参数设置为 5 分钟。
  • 在 pod-eviction-timeout 工夫之后,主节点的隔离节点 Pod 处于“Terminating”状态,并会在不同节点上创立 Pod 新实例。
  • 这些 Pod 会持续在隔离节点上运行。

原文链接:https://medium.com/tailwinds-…

正文完
 0