📚 课程目录第2章 Kubernetes基础回顾

2. Kubernetes 基础回顾：Pod 生命周期、Service 与网络模型、ConfigMap 与 Secret 管理、资源限制（Requests/Limits）

在深入连接池水位调优之前，必须夯实 Kubernetes 核心基础。本章将围绕 Pod 生命周期、Service 与网络模型、配置管理以及资源限制四个维度展开，这些概念直接决定了连接池的创建时机、网络可达性、配置注入方式以及资源争抢行为。

2.1 Pod 生命周期与连接池的创建时机

Pod 是 Kubernetes 中最小的调度单元，也是连接池实例化与销毁的直接载体。理解 Pod 的完整生命周期，有助于在调优时精准定位连接池初始化、预热、保活与回收的时机。

  关键认知： 连接池的初始化应放在 PostStart 或 ReadinessProbe 首次成功之后，而非容器启动命令中，以避免在 Pod 尚未就绪时建立无效连接。

Pod 生命周期阶段

阶段	状态说明	连接池行为关联
Pending	Pod 已被调度，但容器尚未完全启动	连接池未创建，避免提前建立连接
Running	至少一个容器正在运行	连接池在此阶段初始化，建议配合 ReadinessProbe
Succeeded / Failed	Pod 终止，不再重启	连接池应优雅关闭，释放数据库/中间件连接
Unknown	节点失联，状态不可知	连接池可能泄漏，需设置超时回收机制

Pod 生命周期与连接池状态机

下图展示了 Pod 从创建到销毁过程中，连接池的对应状态转换：

2.2 Service 与网络模型：连接池的网络边界

Kubernetes 网络模型要求每个 Pod 拥有独立的 IP，Pod 之间可以直接通信，但 Pod IP 是动态变化的。Service 作为稳定的网络入口，是连接池配置中 目标地址 的核心抽象。

Service 类型与连接池选型

Service 类型	网络行为	连接池配置建议
ClusterIP	集群内虚拟 IP，iptables/IPVS 转发	连接池指向 Service DNS，利用 kube-proxy 负载均衡
NodePort	节点端口映射，外部流量进入	连接池指向节点 IP + NodePort，注意跨节点延迟
LoadBalancer	云厂商 LB 分发流量	连接池指向 LB 地址，避免直接连接 Pod IP
Headless Service	返回所有 Pod IP，无负载均衡	连接池需自行实现端点发现，适用于 StatefulSet

Service 网络模型与连接池通信路径

下图展示了支付订单系统中，应用 Pod 通过 Service 访问数据库中间件的网络路径：

cachePrepStmts 和 useServerPrepStmts 减少网络往返。 3. 设置 socketTimeout 防止连接池线程被网络故障阻塞。 4. 使用 Headless Service 时，连接池需配合 loadBalance 策略。

2.3 ConfigMap 与 Secret 管理：连接池配置的注入方式

连接池的配置参数（如最大连接数、超时时间、用户名密码）不应硬编码在镜像中。Kubernetes 通过 ConfigMap 和 Secret 实现配置与镜像的解耦，这是连接池水位调优中配置动态调整的基础。

ConfigMap 与 Secret 对比

特性	ConfigMap	Secret
存储内容	非敏感配置（连接池大小、超时时间）	敏感信息（数据库密码、TLS 证书）
编码方式	明文	Base64 编码，支持加密
注入方式	环境变量 / 挂载文件	环境变量 / 挂载文件
更新生效	挂载文件方式自动更新（需应用监听）	挂载文件方式自动更新
典型用途	`spring.datasource.hikari.maximum-pool-size`	`spring.datasource.password`

连接池配置注入示例

以下是一个典型的 ConfigMap 和 Secret 定义，以及如何在 Deployment 中引用：

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-datasource-config
data:
  application.properties: |
    spring.datasource.hikari.maximum-pool-size=20
    spring.datasource.hikari.minimum-idle=5
    spring.datasource.hikari.connection-timeout=30000
    spring.datasource.hikari.idle-timeout=600000
---
# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: payment-db-secret
type: Opaque
data:
  db-password: cGFzc3dvcmQxMjM=  # base64 编码
---
# deployment.yaml (片段)
spec:
  template:
    spec:
      containers:
      - name: payment-app
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: payment-db-secret
              key: db-password
        volumeMounts:
        - name: config
          mountPath: /app/config
      volumes:
      - name: config
        configMap:
          name: payment-datasource-config

调优实践： 将连接池参数放在 ConfigMap 中，可以在不重建 Pod 的情况下通过挂载文件热更新（需应用支持 spring.config.import 或监听文件变化）。密码等敏感信息务必使用 Secret，并启用 encryption at rest。

2.4 资源限制（Requests/Limits）：连接池水位的资源约束

连接池的水位不仅受业务流量影响，更受 Pod 资源限制的硬约束。如果 Pod 的 CPU 或内存被限流，连接池线程可能因资源竞争而阻塞，导致连接池水位异常升高。

Requests 与 Limits 的核心区别

属性	含义	调度依据	对连接池的影响
Requests	容器保证能获得的最小资源	调度器根据 Requests 选择节点	连接池线程数应 ≤ CPU Requests 可支撑的并发数
Limits	容器允许使用的最大资源上限	超过 Limits 会被限流或 OOMKill	连接池内存占用必须 ≤ Limits 的 60%~70%

资源限制与连接池参数映射关系

在支付订单系统中，我们通常按照以下经验公式进行初始配置：

# 经验公式（以 4C8G 的 Pod 为例）
CPU Requests = 2 核
CPU Limits  = 4 核
Memory Requests = 4 Gi
Memory Limits  = 8 Gi

# 连接池参数推导
maximum-pool-size = CPU Requests * 10 = 20
# 每个连接约占用 1~2 MB 内存
# 连接池总内存 ≈ 20 * 2 MB = 40 MB
# 预留 60% 内存给 JVM 堆 + 连接池 + 其他开销
JVM Heap = Memory Requests * 0.6 = 2.4 Gi

避坑指南： 不要将 maximum-pool-size 设置得过大，否则当 Pod 被 Limit 限流时，大量连接池线程会进入阻塞等待，反而降低吞吐量。建议结合压测结果，将连接池大小控制在 CPU Requests 的 8~12 倍之间。

资源限制与连接池水位的联动关系

下图展示了资源限制如何影响连接池的可用连接数：

资源限制调优检查清单

CPU 限流检查： 使用 kubectl top pod 观察 CPU 使用率是否接近 Limits，若持续限流则需降低连接池大小或增加 CPU Requests。
内存 OOM 检查： 监控 Pod 的 container_memory_working_set_bytes，确保连接池内存 + JVM 堆 + 其他开销 ≤ Memory Limits 的 85%。
连接池线程与 CPU 比例： 连接池线程数不应超过 CPU Requests 的 10 倍，避免上下文切换开销过大。
垂直扩缩容策略： 当连接池水位持续高位时，优先考虑增加 Pod 的 CPU/Memory Requests，而非盲目增大连接池大小。