2. Kubernetes 核心概念回顾：Pod、Service、Deployment、Namespace、ConfigMap、Secret
在深入蓝绿发布与 Secrets 动态注入之前，必须牢固掌握 Kubernetes 的六大核心原语。这些原语构成了所有工作负载与配置管理的基础。本章将逐一拆解其定义、职责与协作关系，并重点突出与后续课程紧密相关的特性。
2.1 核心概念总览
下表从作用层级、生命周期和与蓝绿发布的相关性三个维度，快速建立全局认知：
| 概念 | 作用层级 | 生命周期 | 与蓝绿发布 / Secrets 注入的关联 |
|---|---|---|---|
| Pod | 工作负载（最小单元） | 临时性（可被重建） | 承载容器；Secrets 以 Volume 或环境变量形式注入到 Pod 中 |
| Service | 网络抽象 | 持久（稳定 IP/DNS） | 蓝绿切换的核心流量入口；通过 Selector 指向不同版本的 Pod |
| Deployment | 工作负载管理 | 声明式更新 | 管理 ReplicaSet；蓝绿发布中用于创建/销毁版本实例 |
| Namespace | 集群资源隔离 | 持久 | 隔离蓝/绿环境或测试/生产环境 |
| ConfigMap | 配置管理 | 独立于 Pod | 存储非敏感配置；动态更新需配合重启或 Sidecar 重载 |
| Secret | 敏感信息管理 | 独立于 Pod | 存储凭证、TLS 证书；动态注入是本章课程的核心主题 |
2.2 Pod —— 最小部署单元
Pod 是 Kubernetes 中可创建和管理的最小计算单元。一个 Pod 包含一个或多个共享网络栈和存储卷的容器。
- 共享网络：Pod 内的所有容器共享同一个 IP 地址和端口空间，通过 localhost 互相通信。
- 共享存储：Pod 级别的 Volume 可以被内部所有容器挂载。
- 生命周期：Pod 是短暂的，不会自愈；如果节点故障，Pod 会被调度器重新创建。
- 与 Secrets 的关系：Secret 数据通过
volumes或env字段挂载到 Pod 中，Pod 运行时读取。
关键点：Pod 是蓝绿发布中版本替换的基本单位。蓝版本和绿版本分别由不同的 Pod 集合承载，Service 通过 Label Selector 决定流量指向哪个集合。
2.3 Service —— 稳定的网络入口
Service 为一组功能相同的 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，并实现负载均衡。其核心机制是 Label Selector。
- ClusterIP：默认类型，集群内部可访问。
- NodePort：在每个节点上开放一个静态端口，外部流量可访问。
- LoadBalancer：云厂商提供的外部负载均衡器。
- 蓝绿发布中的角色：Service 的 Selector 指向
version: blue或version: green标签。切换时只需更新 Service 的 Selector，流量瞬间切换。
# 示例：Service 通过标签选择 Pod
apiVersion: v1
kind: Service
metadata:
name: my-app-svc
spec:
selector:
app: my-app
version: blue # 切换时改为 green
ports:
- protocol: TCP
port: 80
targetPort: 80802.4 Deployment —— 声明式应用管理
Deployment 管理 ReplicaSet，并提供声明式更新、回滚和扩缩容能力。它不直接管理 Pod，而是通过 ReplicaSet 控制 Pod 副本数。
- 滚动更新：默认策略，逐步替换旧版本 Pod。
- 回滚：通过
kubectl rollout undo快速回到上一个版本。 - 蓝绿发布中的角色：通常创建两个独立的 Deployment（blue 和 green），各自维护自己的 ReplicaSet。发布时先部署新版本 Deployment，验证无误后切换 Service。
最佳实践：在蓝绿发布中，不要修改已有 Deployment 的 Pod 模板，而是创建全新的 Deployment。这样可以保留旧版本作为快速回退的“绿洲”。
2.5 Namespace —— 虚拟集群边界
Namespace 将物理集群划分为多个虚拟集群，用于实现资源隔离和访问控制。每个 Namespace 内的资源名称必须唯一，但跨 Namespace 可以重名。
- 默认 Namespace：
default、kube-system、kube-public。 - 资源配额：可以为每个 Namespace 设置 CPU、内存、存储等配额。
- 网络策略：结合 NetworkPolicy 实现 Namespace 级别的网络隔离。
- 与蓝绿发布的关系：可以将蓝/绿版本部署到不同的 Namespace（如
prod-blue和prod-green），通过 Service 跨 Namespace 访问或使用全局 DNS。
2.6 ConfigMap —— 非敏感配置管理
ConfigMap 用于将非机密性的配置数据（如配置文件、命令行参数、环境变量）与 Pod 解耦。数据以键值对形式存储。
- 注入方式：环境变量、命令行参数、Volume 挂载。
- 更新行为：通过 Volume 挂载的 ConfigMap 更新后，Pod 内文件会同步（有延迟）；通过环境变量注入的 ConfigMap 更新后，需要重启 Pod 才能生效。
- 限制：ConfigMap 大小限制为 1MB（etcd 限制）。
# 创建 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
app.properties: |
log.level=INFO
max.connections=1002.7 Secret —— 敏感信息管理
Secret 与 ConfigMap 类似，但专门用于存储敏感数据（密码、OAuth 令牌、SSH 密钥、TLS 证书）。数据以 Base64 编码存储，但请注意 Base64 不是加密。
- 类型：
Opaque（通用）、kubernetes.io/tls（TLS 证书）、kubernetes.io/dockerconfigjson（镜像仓库凭证）。 - 注入方式：环境变量、Volume 挂载。
- 安全机制：etcd 加密（需开启）、RBAC 访问控制、静态加密。
- 动态注入挑战：默认情况下，Secret 更新后，已运行的 Pod 不会自动获取新值。本课程后续将讲解如何通过 Reloader、Sidecar 或 CSI 驱动实现动态注入。
安全警告：不要将 Secret 提交到 Git 仓库。使用外部 Secret 管理工具（如 HashiCorp Vault、AWS Secrets Manager）并通过 CSI 或 Operator 同步到集群。
2.8 六大原语协作关系图
下图展示了在典型应用中，这些核心概念如何协同工作：
2.9 概念对比速查表
以下表格从数据持久性、更新方式和安全等级三个关键维度，对比 ConfigMap 与 Secret：
| 特性 | ConfigMap | Secret |
|---|---|---|
| 数据内容 | 明文配置（非敏感） | Base64 编码（敏感） |
| 存储大小限制 | 1MB（etcd 限制） | 1MB（etcd 限制） |
| 静态加密 | 默认不加密 | 可开启 etcd 加密 |
| Pod 内更新方式 | Volume 挂载：自动同步（有延迟） 环境变量：需重启 Pod |
Volume 挂载：自动同步（有延迟） 环境变量：需重启 Pod |
| 典型用途 | 配置文件、环境变量、命令行参数 | 数据库密码、、TLS 证书 |
| 审计与 RBAC | 标准 RBAC | 标准 RBAC + 建议开启审计日志 |
2.10 本章小结
六大核心原语构成了 Kubernetes 的骨架：
- Pod 是运行容器的最小单元，承载应用进程。
- Service 提供稳定的网络入口，是蓝绿流量切换的枢纽。
- Deployment 管理 Pod 的生命周期，支持声明式更新和回滚。
- Namespace 实现多租户隔离，为蓝绿环境提供逻辑边界。
- ConfigMap 和 Secret 将配置与镜像解耦，其中 Secret 的动态注入是后续章节的核心挑战。