4. 网关资源模型设计：CPU/内存请求与限制、HPA配置、PodDisruptionBudget

云原生网关作为集群流量的入口，其资源模型的合理性直接决定网关的稳定性与弹性伸缩能力。本章围绕三个核心维度展开：静态资源配额（Requests & Limits）、动态弹性策略（HPA）以及可用性保障（PodDisruptionBudget）。三者共同构成网关资源模型的完整闭环。

4.1 资源请求与限制：静态配额设计原则

Kubernetes 中每个容器都可以声明 requests（调度保证）和 limits（资源上限）。对于网关这类延迟敏感型组件，推荐采用 Guaranteed QoS 模式，即 requests == limits，避免因 CPU 压缩或内存回收导致请求抖动。

资源类型 推荐配置（单副本） 说明
CPU requests 500m – 1000m 根据 TLS 卸载、路由规则复杂度调整
CPU limits 与 requests 一致 避免 CPU 节流导致延迟毛刺
Memory requests 512Mi – 1Gi 包含连接池、缓存、TLS 会话
Memory limits 与 requests 一致 防止 OOM 时被 Kill，但需预留 headroom
实践建议：生产环境至少预留 20% 的节点资源余量，用于应对突发流量和 DaemonSet 等系统组件开销。网关副本数建议从 2 起步，避免单点故障。

4.2 HPA 配置：基于自定义指标的弹性伸缩

水平 Pod 自动伸缩（HPA）是网关应对流量波动的核心手段。除了基础的 CPU/内存指标，网关场景更推荐使用 每秒请求数（RPS） 或 连接数 作为伸缩依据，这需要配合 Prometheus Adapter 或 KEDA 实现。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cloud-gateway
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: gateway_requests_per_second
        target:
          type: AverageValue
          averageValue: 5000
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
关键参数解读：
• stabilizationWindowSeconds: 300：缩容冷却窗口，防止流量抖动导致频繁伸缩。
• scaleDown 策略限制每次最多缩容 10%，避免批量驱逐造成容量不足。
• 建议同时配置 CPU 和 RPS 双指标，CPU 作为兜底，RPS 作为业务驱动。

4.3 PodDisruptionBudget：优雅中断与可用性保障

PodDisruptionBudget（PDB）用于约束自愿中断（如节点维护、集群升级）期间可同时不可用的 Pod 数量。对于网关，PDB 应设置为 至少保留 50% 的副本 或 最小可用数 = 1，确保集群升级时流量不中断。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: gateway-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: cloud-gateway
注意：PDB 仅保护自愿中断，不应对非自愿中断（如节点宕机、OOM）。当副本数小于等于 minAvailable 时，PDB 会阻止所有自愿驱逐操作，可能导致集群升级卡住。建议结合 maxUnavailable 使用，例如 maxUnavailable: 25%。

4.4 资源模型关系图

下图展示了网关资源模型中静态配额、HPA 与 PDB 之间的协作关系：

网关资源模型协作关系 网关 Deployment 静态资源配额 Requests / Limits HPA 弹性伸缩 CPU + RPS 双指标 PodDisruptionBudget minAvailable: 1 设计要点 • 静态配额保证调度与 QoS，避免资源争抢 • HPA 动态扩缩容，应对流量波动 • PDB 保障自愿中断期间的最小可用副本数

4.5 常见故障模式与排查思路

故障现象 可能原因 排查方向
网关频繁 OOMKill Memory limits 设置过低，或存在内存泄漏 检查 container_memory_working_set_bytes 指标，对比 limits
HPA 无法扩容 指标未上报、metrics-server 未部署、自定义指标适配器异常 kubectl describe hpa 查看事件，检查 kubectl get --raw /apis/custom.metrics.k8s.io/
节点维护时网关 Pod 被驱逐导致服务中断 PDB 未配置或配置过松 检查 PDB 状态：kubectl get pdb gateway-pdb -o yaml
CPU 节流导致延迟升高 CPU limits 小于 requests，或 limits 过低 查看 container_cpu_cfs_throttled_seconds_total 指标
故障排查黄金命令：
kubectl describe pod <gateway-pod> — 查看资源状态与事件
kubectl top pod -l app=cloud-gateway — 实时资源使用
kubectl describe hpa gateway-hpa — 伸缩事件与指标状态
kubectl get pdb gateway-pdb -o wide — PDB 允许/禁止驱逐数

4.6 资源模型设计检查清单

  • QoS 等级：网关容器是否设置为 Guaranteed（requests == limits）？
  • CPU 预留：requests 是否覆盖了 TLS 握手、路由匹配等计算开销？
  • 内存边界：limits 是否留有 20-30% 的 headroom 应对突发连接？
  • HPA 双指标：是否同时配置了 CPU 和业务指标（RPS/连接数）？
  • 缩容冷却：是否设置了 stabilizationWindowSeconds ≥ 300 秒？
  • PDB 策略：minAvailable 是否 ≥ 1 或 maxUnavailable ≤ 25%？
  • 副本下限：HPA minReplicas 是否 ≥ 2？
← 上一章 📖 返回目录 下一章 →