2. Kubernetes 核心概念回顾:Pod、Service、Deployment、StatefulSet、ConfigMap、Secret 的核心作用与关系

在深入分布式事务鉴权拦截与自动伸缩策略之前,必须重新梳理 Kubernetes 最核心的六个抽象对象。它们构成了应用部署、网络暴露、状态管理、配置注入与敏感信息存储的完整骨架。理解这些对象的作用与关系,是后续设计鉴权拦截器和伸缩策略的基础。

2.1 核心对象一览

下表从作用域、生命周期、典型场景三个维度对比了六个核心对象:

对象 API 组 / 版本 作用域 生命周期 典型场景
Pod v1 命名空间 临时(可被重建) 运行一个或多个容器,共享网络与存储
Service v1 命名空间 持久(直到删除) 提供稳定的网络入口,负载均衡到一组 Pod
Deployment apps/v1 命名空间 声明式管理 无状态应用的滚动更新、扩缩容、回滚
StatefulSet apps/v1 命名空间 有序、持久标识 有状态应用(数据库、消息队列、ZooKeeper)
ConfigMap v1 命名空间 持久(直到删除) 注入非敏感配置(环境变量、配置文件)
Secret v1 命名空间 持久(直到删除) 注入敏感数据(密码、Token、证书)
关键认知: Pod 是 Kubernetes 的最小调度单元,但用户几乎从不直接创建 Pod。Deployment 和 StatefulSet 才是真正的“应用管理者”,它们负责 Pod 的创建、更新、自愈和扩缩容。

2.2 对象关系与分层架构

下图展示了六个核心对象之间的依赖与协作关系。注意 ConfigMap 和 Secret 作为“数据平面”被 Pod 引用,而 Service 作为“网络平面”将流量分发到 Pod。

Kubernetes 核心对象关系图 Kubernetes 核心对象关系图 控制面(Controller Manager) Deployment / StatefulSet 控制器通过 ReplicaSet 管理 Pod 的期望状态 Deployment 无状态 · 滚动更新 StatefulSet 有状态 · 有序标识 Pod A 容器组 · 共享网络 Pod B 容器组 · 共享网络 Pod C 容器组 · 共享网络 Service ClusterIP / NodePort / LoadBalancer ConfigMap 非敏感配置(键值对) Secret 敏感数据(Base64 编码) Pod 通过 volumeMount 或 envFrom 引用 ConfigMap/Secret

2.3 各对象核心作用详解

2.3.1 Pod —— 最小调度单元

  • 定义:一组(一个或多个)容器的集合,共享网络命名空间、存储卷和 IP 地址。
  • 关键特性:Pod 内的容器通过 localhost 通信;Pod 是短暂的,可能因节点故障、资源不足或更新被重建。
  • 与鉴权拦截的关系:Sidecar 模式的鉴权代理(如 OAuth2 Proxy、Envoy 扩展)通常以独立容器运行在同一个 Pod 内,拦截进出主容器的流量。
# 一个包含鉴权 Sidecar 的 Pod 示例
apiVersion: v1
kind: Pod
metadata:
  name: auth-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: main-app
    image: my-app:1.0
    ports:
    - containerPort: 8080
  - name: auth-sidecar
    image: oauth2-proxy:latest
    args: ["--upstream=http://127.0.0.1:8080"]
    ports:
    - containerPort: 4180

2.3.2 Service —— 稳定的网络抽象层

  • 作用:为一组动态变化的 Pod 提供固定的虚拟 IP(ClusterIP)和 DNS 名称,实现负载均衡和服务发现。
  • 类型:ClusterIP(集群内访问)、NodePort(节点端口映射)、LoadBalancer(云负载均衡器)、ExternalName(DNS 别名)。
  • 与鉴权拦截的关系:Service 通常作为鉴权代理的前端入口,所有外部流量先经过 Service,再转发到包含鉴权 Sidecar 的 Pod。

2.3.3 Deployment —— 无状态应用的声明式管理

  • 核心能力:声明期望的副本数、支持滚动更新(RollingUpdate)、回滚(Rollback)、自动扩缩容(HPA)。
  • 适用场景:无状态微服务、Web 应用、API 网关。Pod 可以被随意替换,不依赖本地存储。
  • 与自动伸缩的关系:Deployment 是 HorizontalPodAutoscaler(HPA)的直接管理对象,HPA 根据 CPU/内存或自定义指标调整 Deployment 的副本数。

2.3.4 StatefulSet —— 有状态应用的稳定标识

  • 与 Deployment 的关键区别:
    1. 每个 Pod 拥有稳定的网络标识(pod-name-0、pod-name-1...)。
    2. Pod 的启动、停止、扩缩容遵循严格顺序。
    3. 每个 Pod 可以绑定独立的持久卷(PersistentVolumeClaim)。
  • 适用场景:数据库(MySQL、PostgreSQL)、消息队列(Kafka)、分布式协调(ZooKeeper、etcd)。
  • 与鉴权拦截的关系:有状态服务同样需要鉴权,但 StatefulSet 的 Pod 标识稳定,适合使用基于 Pod 名称的细粒度鉴权策略。

2.3.5 ConfigMap —— 非敏感配置注入

  • 存储内容:环境变量、命令行参数、配置文件(如 application.yml、nginx.conf)。
  • 注入方式:
    • 环境变量:envFrom 或 valueFrom.configMapKeyRef
    • 文件挂载:volumes[].configMap 挂载到 Pod 文件系统
  • 与鉴权拦截的关系:鉴权规则、OIDC 配置、白名单等非敏感参数可以存放在 ConfigMap 中,动态更新后通过 Sidecar 重新加载。

2.3.6 Secret —— 敏感数据安全存储

  • 存储内容:密码、API Token、TLS 证书、SSH 密钥。
  • 安全机制:数据以 Base64 编码存储(非加密,需配合 etcd 加密或外部密钥管理服务);支持 kubernetes.io/tls 和 kubernetes.io/dockerconfigjson 等类型。
  • 与鉴权拦截的关系:JWT 签名密钥、OAuth2 Client Secret、数据库密码等必须通过 Secret 注入,避免明文出现在 YAML 或镜像中。
⚠️ 常见误区:不要将 Secret 视为“安全保险箱”。默认情况下,Secret 以明文存储在 etcd 中。生产环境必须启用 etcd 加密(--encryption-provider-config)或使用外部密钥管理服务(如 HashiCorp Vault、AWS KMS)。

2.4 对象协作流程示例

下图展示了一个典型的无状态应用从配置注入到网络暴露的完整协作流程:

对象协作流程示例 无状态应用对象协作流程 ConfigMap 应用配置 Secret 数据库密码 Deployment 声明副本数 = 3 Pod 1 Pod 2 Pod 3 Service (ClusterIP) selector: app=my-app Ingress / LB 外部流量入口 流程:ConfigMap/Secret 注入 → Deployment 管理 Pod → Service 暴露 → Ingress 对外服务

2.5 核心关系总结

  • Pod 是基础:所有工作负载最终都以 Pod 形式运行。Deployment 和 StatefulSet 是 Pod 的“工厂”。
  • Service 是桥梁:将动态变化的 Pod IP 抽象为稳定的虚拟 IP,实现服务发现与负载均衡。
  • ConfigMap/Secret 是数据源:将配置与镜像解耦,实现环境无关的部署。Secret 额外提供敏感数据保护。
  • Deployment vs StatefulSet:无状态选 Deployment,有状态选 StatefulSet。鉴权拦截器本身通常是无状态的,适合 Deployment 管理。
  • 自动伸缩的依赖链:HPA → Deployment/StatefulSet → ReplicaSet → Pod。鉴权拦截器的伸缩策略同样遵循这条链路。
📌 本章要点:在后续章节中,鉴权拦截器将作为 Sidecar 容器部署在 Pod 内,通过 Service 暴露,由 Deployment 管理副本数,并通过 HPA 实现自动伸缩。ConfigMap 存放鉴权规则,Secret 存放签名密钥。这六个对象的协作关系是整套课程的技术基石。