NotReady 后 Pod的变化
当Kubernetes（K8s）节点进入NotReady状态时，该节点将无法接收新的Pod调度，这可能会影响服务的可用性。以下是节点变为NotReady后，其上Pod状态可能发生的一些情况和细节：
-
Pod状态变为
Pending：如果节点不健康，新的Pod将无法在该节点上启动，它们的状态会保持在Pending，等待节点恢复健康或被调度到其他健康的节点上。 -
现有Pod可能被终止：如果节点上的Pod没有设置适当的容忍（Tolerations）或亲和性（Affinities），它们可能会因为节点的
NotReady状态而被终止。这是因为调度器可能会将这些Pod重新调度到其他节点上。 -
Pod的重调度：对于没有在
NotReady节点上运行的关键Pod，如DaemonSet或StatefulSets，它们可能会被调度到其他节点上。这取决于Pod的配置和集群的调度策略。 -
Pod的驱逐：如果节点因为某些原因（如资源不足、网络问题等）变得不健康，节点上运行的Pod可能会被标记为驱逐（Eviction）。这意味着它们将被终止，并在其他节点上重新调度。
-
节点状态监控：Kubernetes会定期检查节点的健康状态。如果节点在一定时间内（由
node-monitor-grace-period参数定义）没有向控制平面报告其状态，它将被标记为NotReady。这个状态会持续，直到节点恢复健康或被手动干预。 -
节点维护：如果节点需要维护或更新，它可能会被标记为不可调度（通过
cordon命令）。在这种情况下，节点上的现有Pod将继续运行，但不会有新的Pod被调度到该节点上。 -
节点恢复：一旦节点问题得到解决，它需要重新变得健康（
Ready状态），以便能够接收新的Pod调度。这可能涉及到重启kubelet服务、解决网络问题、增加资源等措施。
了解这些细节有助于在节点变为NotReady时，采取适当的措施来维护集群的稳定性和应用的可用性。
kube-controller-manager 日志
https://blog.csdn.net/hezuijiudexiaobai/article/details/141223614
从您提供的日志片段来看，这些日志条目涉及到 Kubernetes 中的 Taint（污点）和 Pod 的删除过程。以下是对日志的分析：
-
TaintManager：这是 Kubernetes 中的一个组件，负责管理节点上的污点。污点是一种标记，用于防止某些 Pod 被调度到特定的节点上。
-
NoExecuteTaintManager：这是一个特定的污点管理器，它处理
NoExecute污点。NoExecute污点会导致节点上的现有 Pod 被驱逐（删除），并且新的 Pod 不会被调度到该节点上。 -
is deleting pod：这表明 TaintManager 正在删除一个或多个 Pod。这通常是因为节点被标记了
NoExecute污点，导致所有未被容忍（Tolerations）的 Pod 需要被删除。 -
Event occurred：日志的最后一行显示了一个事件已经被记录。这个事件是关于 Pod 被标记为删除的。
-
reason=“TaintManagerEviction”：这表明 Pod 被删除的原因是 TaintManager 触发的驱逐。
-
message=“Marking for deletion Pod”：这是事件的消息，表明 Pod 正在被标记为删除。
-
Pod 名称：日志中列出了多个 Pod 的名称，这些 Pod 正在被删除。例如，
qfusion-admin/mysql-935a51a501-0。 -
时间戳：所有日志条目都有一个时间戳，显示了这些事件发生的具体时间。
这些日志条目表明，由于节点上的 NoExecute 污点，TaintManager 正在删除所有没有相应容忍的 Pod。这可能是由于节点状态变化（如维护、升级或资源不足）导致的，也可能是为了响应集群策略的变化。
解决这个问题通常需要：
- 确认节点为何被标记了
NoExecute污点。 - 确保所有关键 Pod 都有适当的容忍，以便它们不会被驱逐。
- 如果节点需要维护或更新，考虑使用
cordon命令来防止新的 Pod 被调度到该节点上，而不是使用NoExecute污点。 - 一旦节点恢复健康，它将需要被解除
NoExecute污点，以便新的 Pod 可以被调度到该节点上。这可以通过kubectl taint nodes <node-name> <taint-key>-命令来实现。
Terminating
在Kubernetes中，Pod显示为Terminating状态通常意味着Pod正在被删除的过程之中。这种情况可能由以下几个原因引起：
-
节点状态变化：当节点变为
NotReady，例如因为维护、资源不足或其他原因，节点上的Pod可能会被标记为Terminating，以便它们可以被重新调度到其他健康的节点上。 -
资源不足：如果节点资源不足，如CPU、内存或存储空间不足，可能会导致Pod被终止。
-
Kubelet服务问题：如果Kubelet服务出现故障，可能会导致Pod被标记为
Terminating。 -
网络问题：网络连接问题可能导致节点与控制平面通信中断，进而使Pod被终止。
-
Pod配置问题：Pod的配置错误，如资源请求和限制设置不当，也可能导致Pod被终止。
-
控制器管理：如果Pod是由控制器（如Deployment、StatefulSet等）管理的，控制器可能会因为策略或更新而终止Pod。
-
手动干预：管理员可能手动删除了Pod，或者使用了
kubectl delete命令来删除Pod。 -
污点和容忍：如果节点被添加了污点，而Pod没有相应的容忍，Pod会被终止并尝试在其他节点上重新调度。
在处理Terminating状态的Pod时，您应该首先检查导致Pod终止的原因。您可以使用kubectl describe pod <pod-name>命令来获取更多关于Pod状态的信息，包括事件和警告，这将帮助您诊断问题所在。一旦确定了原因，您可以采取相应的措施来解决它，例如修复节点问题、调整Pod配置或更新控制器的设置。
