k8s 当节点notready后，网关pod并不会被驱逐的原因有哪些

1. Pod 中断预算 (PodDisruptionBudget - PDB)

这是最常见和最主要的原因。

• 目的：PDB 用于在主动驱逐（如节点排水、集群升级）时，保证应用的高可用性。它定义了同时中断的 Pod 副本数量的上限（maxUnavailable）或下限（minAvailable）。

• 网关场景：网关通常被部署为高可用模式，例如有 2 个副本。它的 PDB 可能会设置为 maxUnavailable: 1，这意味着任何时候最多只允许 1 个网关 Pod 不可用。

• 问题所在：当节点意外 NotReady 时，该节点上的网关 Pod 虽然实际已失效，但在 Kubernetes 看来，它仍然“存在”，只是状态不是 Ready。如果集群中只剩下一个健康的网关 Pod，此时控制面（特别是 kube-controller-manager 中的 disruption controller）会进行计算：如果驱逐故障节点上的 Pod，就会导致不可用的 Pod 数量超过 PDB 的限制（例如，2 个 Pod 中将有 1 个被标记为删除，而另一个可能已经是唯一的健康副本，这违背了 PDB）。因此，为了不违反 PDB 规则，驱逐操作会被自动阻止。

2. 节点状态更新与驱逐的延迟

Kubernetes 的节点状态监测和 Pod 驱逐不是瞬时完成的。

• 节点心跳：kubelet 会定期向 API Server 发送心跳。如果连续丢失多次（由 --node-monitor-grace-period 参数控制，默认 40 秒），节点才会被标记为 NotReady。

• 驱逐延迟：节点标记为 NotReady 后，并不会立即驱逐 Pod。kube-controller-manager 的 node-lifecycle-controller 会等待一个固定的时间（由 --pod-eviction-timeout 参数控制，但在较新版本中已被弃用，演变为基于节点状态的逐出机制），之后才开始驱逐。

• 网络分区：在复杂的网络问题下，API Server 可能无法准确判断节点的真实状态，导致驱逐决策被延迟。

3. Pod 容忍度 (Tolerations)

网关 Pod 通常会被配置容忍节点的 NotReady 和 Unreachable 污点。

• 机制：当节点出现问题时，控制面会自动给节点打上 node.kubernetes.io/not-ready 或 node.kubernetes.io/unreachable 污点。Pod 如果没有对应的容忍度，会被立即调度走。

• 网关场景：为了保证网络流量处理的极致高可用，网关 Pod 的部署清单中通常会显式地配置长时间容忍这些污点。例如：

  yaml

  tolerations:
  - key: "node.kubernetes.io/not-ready"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 300  # 可以容忍 5 分钟
  - key: "node.kubernetes.io/unreachable"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 300  # 可以容忍 5 分钟

  • tolerationSeconds 定义了 Pod 在被驱逐前可以容忍污点的时长。如果这个值设置得非常大（例如 300），或者根本没有设置（意味着无限期容忍），那么 Pod 就会一直“粘”在故障节点上。

4. 使用 DaemonSet 部署网关