k8s内部的pod高可用

最新推荐文章于 2025-12-05 15:13:01 发布

原创最新推荐文章于 2025-12-05 15:13:01 发布 · 827 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #java #容器

容器技术专栏收录该内容

56 篇文章

订阅专栏

强烈建议将 Pod 副本强制调度到不同节点上，以避免单节点故障导致服务完全中断。这是 Kubernetes 高可用设计的核心原则之一。

⚠️ 为什么必须强制跨节点部署？

单点故障风险
若两个 Pod 在同一节点运行，该节点宕机会导致服务100%中断，直到新 Pod 在其他节点重建（通常需 30 秒至数分钟）。
资源隔离需求
节点级故障（如硬件损坏、网络故障、内核崩溃）无法通过 Pod 副本自愈机制避免，必须依赖跨节点冗余。
服务连续性保障
跨节点部署确保单节点故障时，至少有一个 Pod 可继续处理请求，实现 “零中断切换”。

⚙️ 实现跨节点部署的两种核心方案

方案一：Pod 反亲和性（Pod Anti-Affinity）

通过 requiredDuringSchedulingIgnoredDuringExecution 强制调度器遵守规则：

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 2
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values: [your-app-name]
              topologyKey: kubernetes.io/hostname  # 按节点主机名隔离

关键参数
- topologyKey: kubernetes.io/hostname：以节点为隔离域（每个节点视为独立故障域）。
- labelSelector：匹配当前 Deployment 的 Pod 标签，确保同应用 Pod 互斥。
效果：若集群有 2 个以上节点，两个 Pod 必定部署在不同节点；若仅 1 个节点可用，则第二个 Pod 会处于 Pending 状态（需告警）。

✅ 适用场景：对可用性要求极高的关键服务（如支付网关、认证服务）。

方案二：拓扑分布约束（Topology Spread Constraints）

通过 maxSkew 控制 Pod 分布的均衡性：

spec:
  topologySpreadConstraints:
    - maxSkew: 1  # 允许的最大偏差值
      topologyKey: kubernetes.io/hostname
      whenUnsatisfiable: DoNotSchedule  # 不满足条件则不调度
      labelSelector:
        matchLabels:
          app: your-app-name

关键参数
- maxSkew: 1：所有节点间运行的 Pod 数量差 ≤1（例如：节点 A 有 1 个 Pod，节点 B 必须有 0 或 1 个）。
- whenUnsatisfiable: DoNotSchedule：严格模式，确保分布均衡。
效果：在双副本场景下等效于反亲和性，但更灵活支持多副本的均匀分布（如 3 副本跨 3 节点）。

✅ 适用场景：需精细控制 Pod 分布策略（如同时约束节点+可用区）。

⚡️ 生产环境注意事项

节点资源池规模
- 至少部署 3 个以上工作节点，避免单个节点维护时触发 Pod Pending。
- 使用多可用区（Availability Zone）节点，进一步防范机房级故障。
资源配额预留
每个节点需预留足够资源（CPU/内存），确保故障转移时新 Pod 可快速调度。
调度冲突处理
- 若集群资源不足，结合 priorityClass 为关键服务赋予更高调度优先级。
- 避免与 nodeAffinity 等规则冲突（例如强制节点标签导致无可用节点）。
大规模集群性能
反亲和性在超 100 节点集群可能降低调度性能，建议用拓扑约束替代。

🔒 增强可用性的补充措施

Pod 干扰预算（PDB）：
设置 minAvailable: 1，防止节点维护时同时删除所有副本。
健康检查：
配置 livenessProbe 和 readinessProbe，确保故障 Pod 自动重启或隔离。
多集群部署：
对全局高可用服务，跨集群部署副本（如使用 Karmada 或 Cluster API）。

💎 总结

必须强制两个 Pod 副本部署在不同节点，否则无法抵御节点级故障。
首选方案：
- 简单场景 → Pod 反亲和性（配置简单，强制隔离）。
- 复杂场景 → 拓扑分布约束（支持多维度均衡调度）。
验证方法：
```
kubectl get pods -o wide | grep your-app-name  # 查看 Pod 所在节点
```
若输出显示两个 Pod 的 NODE 列不同，则跨节点部署成功。