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

在深入 VPA 压测与成本优化之前，必须重新校准 Kubernetes 的五大核心抽象。这些概念不仅是集群的“积木”，更是后续容量基线、证书轮换策略和资源配额调整的直接操作对象。本节以 SRE 视角，从资源调度与网络可达性两个维度进行结构化回顾。

2.1 Pod：最小调度单元与资源边界

Pod 是 Kubernetes 中可创建和部署的最小计算单元，代表集群上运行的一个进程。一个 Pod 封装一个或多个容器（通常为一个主容器加若干 Sidecar），共享存储卷（Volume）和网络 IP。

SRE 要点：Pod 是资源请求（Requests）和限制（Limits）生效的边界。VPA 调整的是 Pod 级别的 CPU/Memory 值，而非单个容器。证书轮换 Sidecar 与主容器共享同一网络栈，可通过 localhost 通信。
属性 说明 压测关联
共享网络 同一 Pod 内所有容器共享 IP 和端口空间 证书轮换 Sidecar 监听本地端口，主容器通过 localhost 访问
共享存储 通过 Volume 挂载，容器间可读写同一数据卷 证书文件通过 EmptyDir 或 Secret Volume 在容器间同步
生命周期 Pod 是临时实体，重建后 IP 会变化 压测时需关注 Pod 重建对连接池的影响
资源边界 Requests 用于调度，Limits 用于压制 VPA 基于历史指标调整这两个值
Pod 内部结构：共享网络与存储 Pod 边界 主应用容器 CPU / Memory Requests 监听 :8080 证书轮换 Sidecar 监听 :9090 TLS 证书热更新 共享网络栈 (localhost) + 共享 Volume Pod 是 VPA 调整的最小粒度，也是证书轮换 Sidecar 的部署单元

2.2 Deployment：声明式更新与副本管理

Deployment 为 Pod 提供声明式更新能力，负责维护期望的副本数（Replicas）、滚动更新策略以及回滚机制。它是无状态工作负载的标准控制器。

  • ReplicaSet 管理：Deployment 控制 ReplicaSet，ReplicaSet 控制 Pod。每次更新都会创建新的 ReplicaSet。
  • 滚动更新：通过 maxSurge 和 maxUnavailable 控制更新速率，压测期间需调整这两个参数以避免容量抖动。
  • 版本回滚：保留历史版本（revisionHistoryLimit），证书轮换失败时可快速回退。
压测实践：VPA 与 Deployment 配合时，建议设置 updateStrategy.type: RollingUpdate，并确保 PodDisruptionBudget 已配置，防止 VPA 驱逐 Pod 造成服务中断。

2.3 Service：稳定的网络抽象层

Service 为一组动态变化的 Pod 提供稳定的网络端点（ClusterIP/NodePort/LoadBalancer）。它通过标签选择器（Selector）关联 Pod，并内置负载均衡。

Service 类型 访问范围 典型场景
ClusterIP 集群内部 微服务间 RPC 调用，证书轮换管理接口
NodePort 集群外部（节点端口） 压测流量注入入口
LoadBalancer 外部负载均衡器 生产环境公网入口
Headless 无 ClusterIP StatefulSet 有状态服务
证书轮换注意：Service 不感知 TLS 证书变更。如果证书绑定在 Service 层（如 Ingress），轮换后需要手动 reload 或等待证书自动发现。推荐将证书管理下沉到 Pod 级别，由 Sidecar 负责热更新。

2.4 Namespace：多租户隔离边界

Namespace 将物理集群划分为多个虚拟集群，用于环境隔离（开发/测试/生产）、团队隔离或成本核算。它是 Resource Quota 和 NetworkPolicy 的作用域。

  • 资源配额作用域：Resource Quota 和 LimitRange 绑定到特定 Namespace。
  • 网络隔离：配合 NetworkPolicy 实现 Namespace 间流量控制。
  • 成本归属：通过 Namespace 标签进行成本分摊，VPA 优化后的资源节省可精确到 Namespace 级别。
Namespace 与 Resource Quota 层级关系 Kubernetes 集群 Namespace: production Resource Quota: CPU=32, Mem=128Gi LimitRange: 默认 Requests/Limits NetworkPolicy: 隔离 dev Namespace: staging Resource Quota: CPU=16, Mem=64Gi LimitRange: 默认 Requests/Limits NetworkPolicy: 允许 production 每个 Namespace 独立配额，VPA 优化后释放的资源可被同 Namespace 其他工作负载复用

2.5 Resource Quota：硬性资源边界

Resource Quota 是 Namespace 级别的资源总量限制，防止单个 Namespace 耗尽集群资源。它覆盖 CPU、内存、存储卷数量、PVC 大小、对象数量（如 Pod、Service 数量）等。

成本优化关键：VPA 压测后，Pod 的资源请求会下降。此时需要同步调整 Resource Quota 的 requests.cpu 和 requests.memory 上限，否则释放的资源无法被其他 Namespace 使用。这是“容量基线校准”的核心操作。 
# Resource Quota 示例：限制 production Namespace 资源总量
apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "32"        # 所有 Pod CPU 请求总和上限
    requests.memory: "128Gi"  # 所有 Pod 内存请求总和上限
    limits.cpu: "64"          # 所有 Pod CPU 限制总和上限
    limits.memory: "256Gi"    # 所有 Pod 内存限制总和上限
    persistentvolumeclaims: "20"
    pods: "100"
    services: "50"

2.6 概念关联：从 Pod 到成本优化

这五个概念在 VPA 压测与成本优化流程中形成一条完整链路：

  1. Pod 是资源调整的最小单元，VPA 修改其 Requests/Limits。
  2. Deployment 控制 Pod 的副本数和更新策略，确保 VPA 调整不中断服务。
  3. Service 提供稳定访问入口，屏蔽 Pod IP 变化。
  4. Namespace 划定隔离边界，VPA 优化效果按 Namespace 统计。
  5. Resource Quota 是硬性上限，VPA 释放的资源需通过调整 Quota 才能被其他业务使用。
基线校准动作：压测完成后，执行 kubectl describe resourcequota -n <namespace> 查看当前使用量，然后根据 VPA 推荐值更新 Quota 的 hard 字段。这一步是“成本优化落地”的最后一公里。
← 上一章 📖 返回目录 下一章 →