2. Kubernetes 核心概念回顾：Pod、Deployment、Service、Namespace、ResourceQuota

在深入 HPA 弹性伸缩调优之前，必须牢固掌握 Kubernetes 的五个基础抽象。HPA 的每一次决策——从指标采集、目标副本计算到最终扩缩容——都直接与这些原语的交互方式相关。本节以“HPA 视角”重新梳理每个概念，而非泛泛介绍。

2.1 Pod：不可调度的最小单元与 HPA 的扩缩容对象

Pod 是 Kubernetes 中可创建和管理的最小部署单元。一个 Pod 包含一个或多个容器（通常为一个主容器加若干 sidecar），共享网络栈、存储卷和生命周期。

• HPA 直接操作的对象是 ReplicaSet / StatefulSet，而非 Pod 本身。HPA 通过调整 ReplicaSet 的 replicas 字段，间接控制 Pod 的创建与销毁。
• Pod 的 资源请求（requests）与限制（limits） 是 HPA 计算目标副本数的核心输入。如果 Pod 未设置 resources.requests.cpu 或 resources.requests.memory，基于指标的 HPA 将无法准确计算利用率。
• Pod 的 就绪探针（readinessProbe） 影响 HPA 的稳定性：新创建的 Pod 未通过就绪检查时，不会被计入“可用副本”，HPA 会持续扩容直到可用副本数达标。

2.2 Deployment：声明式更新与 HPA 的协作模式

Deployment 是管理 ReplicaSet 和 Pod 的声明式控制器，提供滚动更新、回滚、副本管理能力。HPA 与 Deployment 的协作遵循以下规则：

2.3 Service：流量入口与 HPA 的负载均衡前提

Service 为一组 Pod 提供稳定的网络端点（ClusterIP / NodePort / LoadBalancer），通过标签选择器（selector）动态关联 Pod。HPA 的扩缩容效果必须通过 Service 才能被客户端感知：

• Service 的 selector 必须与 Deployment 的 spec.selector.matchLabels 一致，否则新创建的 Pod 不会被纳入 Service 后端。
• HPA 扩容后，新 Pod 的 IP 自动加入 Service 的 EndpointSlice；缩容时，旧 Pod 的 IP 在 terminationGracePeriodSeconds 结束后被移除。
• 对于无状态服务，建议使用 ClusterIP + 轮询（iptables/IPVS） 模式，避免 Session Affinity 导致流量倾斜。

2.4 Namespace：多租户隔离与 HPA 的资源边界

Namespace 提供逻辑上的资源隔离，HPA 的生效范围严格限定在单个 Namespace 内。关键影响点：

• HPA 只能监控同一 Namespace 内的 Pod 指标。跨 Namespace 的指标聚合需要额外配置（如 Prometheus + custom metrics adapter）。
• ResourceQuota 作用于 Namespace 级别，当 HPA 扩容导致 Namespace 总资源请求超过 Quota 时，新 Pod 会因资源不足而 Pending，HPA 的扩容效果被阻断。
• 建议为每个业务环境（dev/staging/prod）使用独立 Namespace，并分别配置 HPA 的 minReplicas / maxReplicas。

2.5 ResourceQuota：硬边界与 HPA 的扩容天花板

ResourceQuota 限制 Namespace 内所有 Pod 的资源请求总和（CPU / 内存 / 存储 / 对象数量）。HPA 扩容时必须考虑 Quota 余量：

2.6 核心概念关系总结