K8s 节点 NotReady 后 Pod的变化

NotReady 后 Pod的变化

当Kubernetes（K8s）节点进入NotReady状态时，该节点将无法接收新的Pod调度，这可能会影响服务的可用性。以下是节点变为NotReady后，其上Pod状态可能发生的一些情况和细节：

1. Pod状态变为Pending：如果节点不健康，新的Pod将无法在该节点上启动，它们的状态会保持在Pending，等待节点恢复健康或被调度到其他健康的节点上。

2. 现有Pod可能被终止：如果节点上的Pod没有设置适当的容忍（Tolerations）或亲和性（Affinities），它们可能会因为节点的NotReady状态而被终止。这是因为调度器可能会将这些Pod重新调度到其他节点上。

3. Pod的重调度：对于没有在NotReady节点上运行的关键Pod，如DaemonSet或StatefulSets，它们可能会被调度到其他节点上。这取决于Pod的配置和集群的调度策略。

4. Pod的驱逐：如果节点因为某些原因（如资源不足、网络问题等）变得不健康，节点上运行的Pod可能会被标记为驱逐（Eviction）。这意味着它们将被终止，并在其他节点上重新调度。

5. 节点状态监控：Kubernetes会定期检查节点的健康状态。如果节点在一定时间内（由node-monitor-grace-period参数定义）没有向控制平面报告其状态，它将被标记为NotReady。这个状态会持续，直到节点恢复健康或被手动干预。

6. 节点维护：如果节点需要维护或更新，它可能会被标记为不可调度（通过cordon命令）。在这种情况下，节点上的现有Pod将继续运行，但不会有新的Pod被调度到该节点上。

7. 节点恢复：一旦节点问题得到解决，它需要重新变得健康（Ready状态），以便能够接收新的Pod调度。这可能涉及到重启kubelet服务、解决网络问题、增加资源等措施。

了解这些细节有助于在节点变为NotReady时，采取适当的措施来维护集群的稳定性和应用的可用性。

kube-controller-manager 日志

https://blog.csdn.net/hezuijiudexiaobai/article/details/141223614

从您提供的日志片段来看，这些日志条目涉及到 Kubernetes 中的 Taint（污点）和 Pod 的删除过程。以下是对日志的分析：

1. TaintManager：这是 Kubernetes 中的一个组件，负责管理节点上的污点。污点是一种标记，用于防止某些 Pod 被调度到特定的节点上。

2. NoExecuteTaintManager：这是一个特定的污点管理器，它处理 NoExecute 污点。NoExecute 污点会导致节点上的现有 Pod 被驱逐（删除），并且新的 Pod 不会被调度到该节点上。

3. is deleting pod：这表明 TaintManager 正在删除一个或多个 Pod。这通常是因为节点被标记了 NoExecute 污点，导致所有未被容忍（Tolerations）的 Pod 需要被删除。

4. Event occurred：日志的最后一行显示了一个事件已经被记录。这个事件是关于 Pod 被标记为删除的。

5. reason=“TaintManagerEviction”：这表明 Pod 被删除的原因是 TaintManager 触发的驱逐。

6. message=“Marking for deletion Pod”：这是事件的消息，表明 Pod 正在被标记为删除。

7. Pod 名称：日志中列出了多个 Pod 的名称，这些 Pod 正在被删除。例如，qfusion-admin/mysql-935a51a501-0。

8. 时间戳：所有日志条目都有一个时间戳，显示了这些事件发生的具体时间。

这些日志条目表明，由于节点上的 NoExecute 污点，TaintManager 正在删除所有没有相应容忍的 Pod。这可能是由于节点状态变化（如维护、升级或资源不足）导致的，也可能是为了响应集群策略的变化。

解决这个问题通常需要：

• 确认节点为何被标记了 NoExecute 污点。
• 确保所有关键 Pod 都有适当的容忍，以便它们不会被驱逐。
• 如果节点需要维护或更新，考虑使用 cordon 命令来防止新的 Pod 被调度到该节点上，而不是使用 NoExecute 污点。
• 一旦节点恢复健康，它将需要被解除 NoExecute 污点，以便新的 Pod 可以被调度到该节点上。这可以通过 kubectl taint nodes <node-name> <taint-key>- 命令来实现。

Terminating

在Kubernetes中，Pod显示为Terminating状态通常意味着Pod正在被删除的过程之中。这种情况可能由以下几个原因引起：

1. 节点状态变化：当节点变为NotReady，例如因为维护、资源不足或其他原因，节点上的Pod可能会被标记为Terminating，以便它们可以被重新调度到其他健康的节点上。

2. 资源不足：如果节点资源不足，如CPU、内存或存储空间不足，可能会导致Pod被终止。

3. Kubelet服务问题：如果Kubelet服务出现故障，可能会导致Pod被标记为Terminating。

4. 网络问题：网络连接问题可能导致节点与控制平面通信中断，进而使Pod被终止。

5. Pod配置问题：Pod的配置错误，如资源请求和限制设置不当，也可能导致Pod被终止。

6. 控制器管理：如果Pod是由控制器（如Deployment、StatefulSet等）管理的，控制器可能会因为策略或更新而终止Pod。

7. 手动干预：管理员可能手动删除了Pod，或者使用了kubectl delete命令来删除Pod。

8. 污点和容忍：如果节点被添加了污点，而Pod没有相应的容忍，Pod会被终止并尝试在其他节点上重新调度。

在处理Terminating状态的Pod时，您应该首先检查导致Pod终止的原因。您可以使用kubectl describe pod <pod-name>命令来获取更多关于Pod状态的信息，包括事件和警告，这将帮助您诊断问题所在。一旦确定了原因，您可以采取相应的措施来解决它，例如修复节点问题、调整Pod配置或更新控制器的设置。