2. Kubernetes 核心概念回顾：Pod、Deployment、Service、Ingress、ConfigMap、Secret、Namespace 等核心资源及其在发布流水线中的作用

在深入构建发布流水线之前，必须对 Kubernetes 的核心资源建立精确的认知。这些资源不仅是集群的“积木”，更是流水线中每个阶段（构建、部署、暴露、配置、隔离）的操作对象。下面逐一回顾其定义、关键属性以及在 CI/CD 流程中的具体角色。

2.1 资源概览与发布角色对照

下表总结了 7 种核心资源在发布流水线中的典型职责，后续小节将展开细节。

2.2 核心资源详解

2.2.1 Pod：最小的调度与发布单元

Pod 是 Kubernetes 中可创建和部署的最小计算单元，包含一个或多个共享网络和存储的容器。在发布流水线中，Pod 是“被管理”的对象，而非直接操作的目标。

• 关键属性： 容器镜像、端口、资源请求/限制、存活探针（livenessProbe）、就绪探针（readinessProbe）。
• 发布作用： 流水线通过更新 Deployment 的 Pod 模板（如镜像版本）来触发 Pod 的滚动替换。就绪探针决定 Pod 何时加入 Service 的负载均衡池，直接影响发布过程中的流量切换。
• 典型 YAML 片段：

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: app
    image: registry.example.com/my-app:v1.2.3
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

2.2.2 Deployment：声明式发布引擎

Deployment 是发布流水线的核心控制器。它负责维护一组 Pod 的期望状态，并支持声明式更新与回滚。

• 关键属性： replicas（副本数）、selector（标签选择器）、template（Pod 模板）、strategy（更新策略：RollingUpdate / Recreate）、revisionHistoryLimit（保留历史版本数）。
• 发布作用：
  • 滚动更新： 流水线执行 kubectl set image deployment/my-app app=registry.example.com/my-app:v1.3.0，Deployment 自动创建新 Pod，逐步替换旧 Pod。
  • 回滚： 若监控告警触发，流水线可执行 kubectl rollout undo deployment/my-app 快速恢复至上一版本。
  • 扩缩容： 结合 HPA（Horizontal Pod Autoscaler）实现弹性伸缩。

2.2.3 Service：稳定的网络抽象层

Service 为一组 Pod 提供固定的虚拟 IP（ClusterIP）和 DNS 名称，实现服务发现与负载均衡。Pod 的 IP 会随重启变化，而 Service 的端点保持不变。

• 类型：
  • ClusterIP（默认）： 仅在集群内部可访问。
  • NodePort： 在每个节点上开放一个静态端口（30000-32767），外部可通过 NodeIP:NodePort 访问。
  • LoadBalancer： 云厂商提供外部负载均衡器，自动分配公网 IP。
• 发布作用： 流水线在部署新版本后，Service 自动将流量导向新的就绪 Pod，无需手动更新网络配置。这是实现“零停机发布”的关键。

2.2.4 Ingress：七层流量入口

Ingress 管理集群外部到内部 Service 的 HTTP/HTTPS 路由，通常需要配合 Ingress Controller（如 Nginx Ingress、Traefik）使用。

• 关键属性： rules（主机名、路径与后端 Service 的映射）、tls（HTTPS 证书配置）。
• 发布作用： 流水线在应用上线或域名变更时，创建/更新 Ingress 资源，将新版本的 Service 绑定到指定域名和路径。例如：api.example.com/v2 路由到新版本 Service。
• 典型 YAML 片段：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 8080

2.2.5 ConfigMap 与 Secret：配置与密钥注入

这两个资源将配置数据与容器镜像解耦，使得同一镜像可以在不同环境（开发/测试/生产）中运行。

2.2.6 Namespace：多环境隔离基石

Namespace 将物理集群划分为多个虚拟集群，用于实现环境隔离、资源配额（ResourceQuota）和权限控制（RBAC）。

• 发布作用：
  • 环境隔离： 流水线根据分支或标签，将应用部署到对应的 Namespace（如 dev、staging、prod）。
  • 资源配额： 为每个 Namespace 设置 CPU/内存上限，防止某个环境耗尽集群资源。
  • 网络策略： 结合 NetworkPolicy 实现 Namespace 间的流量控制。

2.3 核心资源在发布流水线中的协作关系

下图展示了从代码提交到服务暴露的完整资源协作流程，帮助理解每个资源在流水线中的位置。

2.4 发布流水线中的资源操作清单

以下是一个典型发布流水线中，针对上述核心资源的操作步骤清单，供参考实现。

1. 配置准备阶段：
   • 从 Git 仓库读取环境配置，生成 ConfigMap 和 Secret 的 YAML 文件。
   • 使用 kubectl apply -f configmap.yaml -n <namespace> 和 kubectl apply -f secret.yaml -n <namespace> 更新配置。
2. 镜像构建与推送阶段：
   • 构建 Docker 镜像并推送至镜像仓库，标签使用 Git Commit SHA 或语义化版本。
3. 部署阶段：
   • 执行 kubectl set image deployment/<name> <container>=<new-image> -n <namespace> 触发滚动更新。
   • 或使用 kubectl apply -f deployment.yaml 更新整个 Deployment 定义。
4. 暴露与验证阶段：
   • 确保 Service 已存在，若为新服务则创建 Service。
   • 更新 Ingress 规则，将新域名或路径指向新 Service。
   • 执行健康检查（如 kubectl rollout status deployment/<name> -n <namespace>）确认发布成功。
5. 回滚阶段（异常时）：
   • 执行 kubectl rollout undo deployment/<name> -n <namespace> 回滚到上一版本。
   • 或指定版本：kubectl rollout undo deployment/<name> --to-revision=3 -n <namespace>。

2.5 多集群场景下的资源管理要点

当流水线需要管理多个 Kubernetes 集群（如生产集群、灾备集群、边缘集群）时，上述资源的管理方式需要额外注意：

• Namespace 一致性： 确保不同集群中相同环境的 Namespace 名称、标签和资源配额保持一致，便于流水线脚本复用。
• ConfigMap/Secret 差异化： 不同集群的数据库地址、证书等配置不同，流水线应根据目标集群名称或标签，从不同的配置源（如 Vault 路径、不同 Git 分支）获取数据。
• Ingress Controller 兼容性： 不同集群可能使用不同的 Ingress Controller（如 Nginx、Traefik、AWS ALB），Ingress 资源的注解（annotations）需要适配。
• Service 类型选择： 本地集群可能使用 NodePort，云上集群使用 LoadBalancer，流水线应通过参数化模板动态生成 Service 定义。