2. Kubernetes 核心概念回顾：Pod、Deployment、Service、HPA、Namespace、资源模型（Requests & Limits）

在深入 Go 服务性能调优与资源配额实战之前，必须对 Kubernetes 的核心抽象层建立精确的认知。本章将聚焦于与资源管理、服务部署和弹性伸缩直接相关的六个核心概念，并重点剖析资源模型（Requests & Limits）的底层机制与配置策略。

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

Pod 是 Kubernetes 中可创建和部署的最小计算单元，也是资源配额（Requests & Limits）生效的原子单位。一个 Pod 可以包含一个或多个容器，这些容器共享网络栈、存储卷以及资源约束。

• 共享网络命名空间：Pod 内的所有容器共享同一个 IP 地址和端口空间，通过 localhost 互相通信。
• 资源约束绑定：资源配额（Requests & Limits）定义在 Pod 级别的容器规范中，调度器根据 Pod 的总请求量选择节点。
• 生命周期短暂：Pod 本身不提供自愈能力，通常由上层控制器（如 Deployment）管理。

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

Deployment 为 Pod 和 ReplicaSet 提供声明式更新能力。它定义了期望状态（Desired State），控制器会持续协调当前状态与期望状态一致。

2.3 Service：稳定的网络访问抽象

Service 为一组动态变化的 Pod 提供稳定的网络端点。Pod 的 IP 会随重建变化，而 Service 通过标签选择器（Label Selector）和 Endpoint 机制保持访问入口不变。

• ClusterIP：集群内部虚拟 IP，默认类型，用于内部服务间通信。
• NodePort：在每个节点上开放静态端口，外部流量可通过节点 IP + 端口访问。
• LoadBalancer：集成云厂商负载均衡器，将外部流量分发到 Service。
• Headless Service：不分配 ClusterIP，直接返回 Pod IP 列表，适用于有状态服务或需要客户端负载均衡的场景。

2.4 HPA（Horizontal Pod Autoscaler）：弹性伸缩的核心

HPA 根据观测到的 CPU、内存使用率或自定义指标（Custom Metrics）自动调整 Deployment 的副本数。它是 Go 服务应对流量波动的关键机制。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: go-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: go-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

• 指标采集周期：默认 15 秒，可通过 --horizontal-pod-autoscaler-sync-period 调整。
• 冷却窗口：默认扩容 3 分钟，缩容 5 分钟，避免频繁抖动。
• 自定义指标：支持 Prometheus Adapter 等外部指标源，实现基于 QPS、延迟等业务指标的弹性伸缩。

2.5 Namespace：多租户资源隔离

Namespace 将集群内的资源划分为逻辑隔离的虚拟集群。每个 Namespace 拥有独立的资源配额（ResourceQuota）、网络策略（NetworkPolicy）和访问控制（RBAC）。

2.6 资源模型：Requests & Limits 深度解析

资源模型是 Kubernetes 调度和资源管理的基石。每个容器可以指定两类资源约束：Requests（请求量）和 Limits（上限）。

2.6.1 核心定义

• Requests：容器保证获得的最小资源量。调度器根据所有容器的 Requests 总和选择节点，确保节点资源足够。
• Limits：容器可以使用的资源上限。当容器尝试使用超过 Limits 的资源时，会被限制（CPU 节流）或杀死（OOM Kill）。

2.6.2 CPU 资源特性

CPU 是可压缩资源（Compressible）。当容器超过 CPU Limits 时，内核会进行节流（Throttling），容器不会被杀掉，但性能会显著下降。

resources:
  requests:
    cpu: "500m"      # 保证 0.5 个 CPU 核心
    memory: "256Mi"
  limits:
    cpu: "1000m"     # 最多使用 1 个 CPU 核心
    memory: "512Mi"

2.6.3 内存资源特性

内存是不可压缩资源（Incompressible）。当容器超过内存 Limits 时，内核会触发 OOM Killer，直接终止容器进程。Go 服务的内存泄漏问题在 Kubernetes 环境下会直接导致 Pod 频繁重启。

2.6.4 服务质量（QoS）等级

Requests 和 Limits 的组合决定了 Pod 的 QoS 等级，直接影响调度优先级和驱逐顺序。

2.7 核心概念关系图

下图展示了 Pod、Deployment、Service、HPA 和 Namespace 之间的协作关系，以及资源模型如何贯穿其中。

2.8 资源配额配置实战建议

基于上述概念，以下是针对 Go 服务的资源配额配置建议：

1. CPU 配置：Requests 设置为服务稳定运行所需的最小 CPU，Limits 设置为突发流量时的上限。建议 Requests/Limits 比例在 1:2 到 1:4 之间。
2. 内存配置：Requests 设置为 Go 服务启动后的常驻内存（RSS），Limits 设置为 RSS + GC 峰值 + 安全余量。建议 Limits 比 Requests 高 20%-50%。
3. QoS 选择：延迟敏感型服务使用 Guaranteed（Requests == Limits）；吞吐优先型服务使用 Burstable（Requests < Limits）。
4. HPA 联动：HPA 的 targetUtilization 应低于 Limits 的 80%，避免节流导致指标失真。