2. Kubernetes 核心概念回顾：Pod、Service、ConfigMap、Secret、Deployment、Ingress
在深入分布式事务鉴权拦截与配置热更新设计之前，必须牢固掌握 Kubernetes 的核心抽象层。本章将围绕六个关键资源——Pod、Service、ConfigMap、Secret、Deployment 和 Ingress——展开回顾，重点突出它们在鉴权拦截与配置热更新场景中的角色与交互关系。
2.1 核心资源概览与职责矩阵
下表从作用层级、生命周期、与鉴权拦截的关联、与配置热更新的关联四个维度，对这六个资源进行横向对比：
| 资源名称 | 作用层级 | 生命周期 | 鉴权拦截关联 | 配置热更新关联 |
|---|---|---|---|---|
| Pod | 工作负载（最小单元） | 临时性（可被重建） | 承载鉴权拦截 Sidecar 容器 | 通过环境变量或挂载卷感知配置变化 |
| Service | 网络抽象层 | 稳定（名称不变） | 作为鉴权拦截的流量入口 | 不直接参与，但为热更新提供稳定端点 |
| ConfigMap | 配置存储 | 独立于 Pod | 存储鉴权规则白名单/黑名单 | 热更新的核心数据源 |
| Secret | 敏感信息存储 | 独立于 Pod | 存储 JWT 密钥、Token、证书 | 支持自动轮换与热加载 |
| Deployment | 工作负载控制器 | 声明式管理 | 控制鉴权拦截组件的副本数与滚动更新 | 配合 ConfigMap/Secret 实现配置变更后的滚动重启 |
| Ingress | 南北向流量入口 | 稳定（规则可更新） | 在入口层执行统一鉴权拦截 | 通过 Ingress Controller 热加载路由规则 |
设计提示：在分布式事务鉴权拦截场景中，ConfigMap 和 Secret 是配置热更新的数据基座，Deployment 负责将配置变更传递到 Pod，而 Service 与 Ingress 则确保流量始终经过鉴权拦截层。
2.2 Pod：鉴权拦截的执行单元
Pod 是 Kubernetes 中最小的部署单元，也是鉴权拦截逻辑实际运行的地方。在分布式事务鉴权拦截设计中，Pod 通常采用 Sidecar 模式：
- 主容器：运行业务服务（如事务协调器、参与者服务）。
- Sidecar 容器：运行鉴权拦截代理（如 OPA、Envoy、自定义 Go 中间件），拦截进出主容器的所有请求。
Pod 通过以下方式感知配置变化：
- 环境变量：从 ConfigMap/Secret 注入，但需重启 Pod 才能生效。
- 卷挂载（Volume Mount）：将 ConfigMap/Secret 挂载为文件，支持 inotify 监听文件变化，实现热更新。
apiVersion: v1
kind: Pod
metadata:
name: transaction-auth-pod
spec:
containers:
- name: business-container
image: myapp:latest
env:
- name: AUTH_RULES_PATH
value: "/etc/auth/rules.yaml"
volumeMounts:
- name: auth-rules
mountPath: /etc/auth
- name: auth-sidecar
image: auth-proxy:latest
volumeMounts:
- name: auth-rules
mountPath: /etc/auth
volumes:
- name: auth-rules
configMap:
name: auth-rules-config
optional: false
2.3 Service：稳定的鉴权流量入口
Service 为 Pod 提供稳定的网络标识（Cluster IP 或 DNS 名称）。在鉴权拦截架构中，Service 承担以下职责：
- 流量抽象：无论 Pod 如何重建，Service 名称不变，鉴权拦截层无需感知后端 Pod 的变化。
- 负载均衡：将请求分发到多个鉴权拦截 Pod 副本，提升吞吐与可用性。
- 服务发现：Ingress 或内部客户端通过 Service 名称访问鉴权拦截层。
关键点：Service 本身不参与配置热更新，但它为热更新后的 Pod 提供了无缝的流量切换能力。当 Deployment 滚动更新 Pod 时，Service 自动将流量导向新 Pod。
2.4 ConfigMap 与 Secret：配置热更新的数据基座
ConfigMap 和 Secret 是 Kubernetes 中存储配置数据的标准资源，二者在鉴权拦截场景中的分工如下：
| 特性 | ConfigMap | Secret |
|---|---|---|
| 存储内容 | 非敏感配置（规则文件、白名单、超时时间） | 敏感信息（JWT 密钥、数据库密码、TLS 证书） |
| 编码方式 | 明文（YAML/JSON 键值对） | Base64 编码（etcd 中加密可选） |
| 热更新支持 | 挂载为文件后，Pod 内可监听文件变化 | 挂载为文件后，Pod 内可监听文件变化 |
| 更新触发方式 | kubectl apply / API 更新 | kubectl apply / API 更新 |
| 鉴权拦截典型用途 | 动态路由规则、IP 白名单、请求限流配置 | JWT 签名密钥、OAuth2 Client Secret、mTLS CA 证书 |
注意：ConfigMap 和 Secret 更新后，已挂载到 Pod 中的文件不会自动更新，除非使用 subPath 挂载或依赖 CSI 驱动。在热更新设计中，推荐使用 挂载整个卷（非 subPath），并配合 inotify 或 fsnotify 监听文件变更事件。
2.5 Deployment：配置变更的编排引擎
Deployment 负责管理 Pod 的声明式更新与回滚。在配置热更新场景中，Deployment 提供两种策略：
- 滚动更新（Rolling Update）：当 ConfigMap/Secret 变更后，通过修改 Deployment 的注解或环境变量触发滚动重启，新 Pod 加载最新配置。
- 原地更新（In-Place Update）：结合 Sidecar 容器的热加载能力，Deployment 仅更新 Pod 的挂载卷内容，无需重启 Pod。
apiVersion: apps/v1
kind: Deployment
metadata:
name: auth-proxy-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: auth-proxy
spec:
containers:
- name: auth-proxy
image: auth-proxy:2.1.0
volumeMounts:
- name: config-volume
mountPath: /etc/auth-config
volumes:
- name: config-volume
configMap:
name: auth-rules-config
optional: false
最佳实践：对于鉴权规则这种需要快速生效的配置，优先采用 原地更新 + 文件监听 方案，避免滚动重启带来的连接中断。对于 JWT 密钥等安全敏感配置，建议使用 滚动更新 确保所有 Pod 同步切换。
2.6 Ingress：南北向流量的统一鉴权拦截点
Ingress 是 Kubernetes 中管理外部访问的 API 对象，通常与 Ingress Controller（如 Nginx、Traefik、Istio）配合使用。在分布式事务鉴权拦截架构中，Ingress 扮演第一道防线的角色：
- 统一入口：所有外部请求首先到达 Ingress，在此处执行全局鉴权检查（如 Token 验证、IP 白名单）。
- 路由分发：根据请求路径、Host 头将流量转发到不同的 Service，实现鉴权后的精细化路由。
- 热更新支持：Ingress Controller 通常支持动态加载 Ingress 资源变更，无需重启即可生效。
架构价值：将鉴权拦截前置到 Ingress 层，可以大幅减少后端服务的鉴权压力，同时实现统一的鉴权策略管理。当配置热更新发生时，Ingress Controller 自动加载新的路由与鉴权规则，实现零停机切换。
2.7 核心资源交互关系图
下图展示了上述六个核心资源在分布式事务鉴权拦截与配置热更新场景中的交互关系：
2.8 本章小结
本章回顾了 Kubernetes 中六个核心资源的概念与职责，并重点分析了它们在分布式事务鉴权拦截与配置热更新场景中的角色：
- Pod 是鉴权逻辑的执行单元，通过 Sidecar 模式实现拦截。
- Service 提供稳定的流量入口，屏蔽后端 Pod 变化。
- ConfigMap 与 Secret 构成配置热更新的数据基座，分别管理非敏感与敏感配置。
- Deployment 负责配置变更的编排，支持滚动更新与原地更新两种策略。
- Ingress 作为南北向流量的统一鉴权点，实现第一道防线。