云原生 on 方糖猫Blog

CI/CD 端到端落地实录：从 Git Push 到 K8s 发布的完整流水线

Wed, 02 Sep 2026 10:00:00 +0800

CI/CD 端到端落地实录：从 Git Push 到 K8s 发布的完整流水线

目标读者：会写 Jenkinsfile、会用 kubectl，但还没在生产环境把「提交代码 → 自动发布 → 失败回滚」整条链路跑通的同学。文中例子取自我主导的真实项目 videocloud（视频云转码服务，Spring Boot + Nacos + K8s），与站内《Kubernetes 学习总结与避坑指南》（kubernetes-authoritative-guide-notes.md）互为补充。

CI/CD 的 Demo 半小时能搭出来，生产可用要踩半年坑。kubectl apply 返回 0 不代表发布成功，Pod Ready 不代表配置生效。本文按真实落地顺序拆解五个阶段，每个阶段给出可抄的配置和踩过的坑。

一、全景：一条流水线要干多少事

graph LR
    Dev[git push / merge] --> WH[Webhook 触发 Jenkins]

    subgraph S1["阶段一：拉取与编译"]
        A1[检出 commit] --> A2[恢复依赖缓存]
        A2 --> A3[单测 + 打包]
    end

    subgraph S2["阶段二：推送产物"]
        B1[构建镜像] --> B2[推 ACR<br/>tag = git commit]
        B3[渲染部署模板<br/>快照留档]
    end

    subgraph S3["阶段三：执行变更单"]
        C1[DB changelog<br/>Liquibase] --> C2[Nacos changelog<br/>OpenAPI 发布]
    end

    subgraph S4["阶段四：部署与验证"]
        D1[更新 ConfigMap<br/>+ 滚动更新] --> D2[rollout status 阻塞]
        D2 --> D3[冒烟测试]
        D3 -->|成功| OK[发布完成]
        D3 -->|失败| RB[rollout undo<br/>自动回滚 + 告警]
    end

    WH --> S1 --> S2 --> S3 --> S4

阶段顺序有一条铁律：先备好「环境」，再动「代码」——数据库先于应用升级（新代码依赖新表结构），配置先于 Pod 重启（新 Pod 不能拿旧配置）。顺序反了，就是半夜被叫醒的那种故障。

二、阶段一：Jenkins 拉取与编译

2.1 触发：Webhook，不是轮询

Git 平台配 Webhook，push/merge 时推给 Jenkins。不要用 SCM 轮询——几十个仓库每分钟扫一遍，Jenkins 自己先爆了。分支与环境对应：feature/* 只编译+单测，develop 自动部署到 dev，master/tag 走完整流水线 + 人工审批发 prod。

2.2 编译提速：缓存 + 并行

stage('拉取与编译') {
    steps {
        checkout scm
        sh '''
            mvn -q -T 1C test                      # 单测先跑，挂了直接终止
            mvn -q -T 1C -DskipTests package       # -T 1C 按核数并行
        '''
    }
}

依赖缓存是性价比最高的优化：~/.m2 挂共享 PVC，构建从 5 分钟压到 1 分钟。
单测只跑变更相关模块（mvn -pl -am），全量留给 nightly。门禁是拦问题的，不是表演严格的。

2.3 Jenkins 自身怎么部署才不拖后腿

流水线慢，一半原因在 Jenkins 自己的形态。我们的规范五条：

Controller 只调度不构建（executors 设为 0），否则构建打满 Controller，UI 卡死、webhook 丢失。
agent 用 Kubernetes 插件动态拉起：按语言预定义 Pod 模板（maven/node/go），构建完即销毁，并发上限就是集群容量：

# agent Pod 模板要点
spec:
  nodeSelector: { node-pool: ci-build }      # 调度到 CI 专用节点池
  containers:
    - name: maven
      image: registry.../ci/maven:3.9-jdk17  # 自维护构建镜像，工具一次装好
      resources:
        requests: { cpu: "4", memory: 8Gi }
      volumeMounts:
        - { name: m2-cache, mountPath: /root/.m2 }
  volumes:
    - name: m2-cache
      persistentVolumeClaim: { claimName: ci-m2-cache }

CI 独立节点池：SSD 磁盘（编译是 IO 密集型）、taint 防业务混部、闲时自动缩容。
构建镜像自己维护：JDK、Maven 私服配置、docker/kubectl/cosign 全打进去，agent 起来就能干活。
部署阶段并行化：无依赖的服务用 parallel 并发部署。我们 8 个服务的流水线从 25 分钟降到 9 分钟。

三、阶段二：推镜像、推配置

3.1 镜像 tag：回滚能力的地基

environment {
    IMAGE = "registry.cn-hangzhou.aliyuncs.com/mycompany/videomart-videocloud"
    TAG   = "${env.GIT_COMMIT.take(8)}"   // git commit 短哈希：唯一、可追溯、可回滚
}

三条规矩：

部署 tag 必须唯一可追溯，杜绝 latest——回滚时说不清「上一个 latest」是谁。
生产仓库开 tag 不可变，禁止覆盖推送，否则同 tag 不同代码，回滚失效。
推送后 cosign 签名，K8s 侧用 Kyverno 校验，未签名拒绝部署——镜像仓库凭证泄露时，这是最后一道闸。

3.2 部署配置：仓库里只存一份参数化模板

原则：代码仓库不按环境拆分配置（没有 prod/、dev/ 目录）。同一份配置写三遍，改一处忘两处是必然结局。videocloud 的做法——部署模板随应用仓库，全部 ${占位符}：

videocloud/
├── k8s_deploy/                                    # 部署模板：环境无关，只有一份
│   ├── k8s-deployment-videomart-videocloud.yaml   # 头部注释列出全部参数
│   ├── k8s-service-videomart-videocloud.yaml
│   └── k8s-persistentvolumeclaim-videomart-videocloud.yaml
├── changelog/          # 数据库/Nacos 变更单（第四章）
└── src/main/resources/bootstrap.properties   # 服务读 Nacos 的方式（第五章）

### 参数: APP_NAME, APP_PORT, NAMESPACE, VERSION
kind: Service
apiVersion: v1
metadata:
  name: videomart-videocloud
  namespace: ${NAMESPACE}      # 发布到哪个环境，由 CD 注入
spec:
  ports:
    - { name: http-0, port: 9577, targetPort: 9577 }

流水线在这一步把渲染结果（含镜像 tag、namespace、副本数的完整快照）提交到发布记录库留档。模板只有一份保证「写法一致」，快照留档保证「可审计、可回滚」，两件事分开解决。

四、阶段三：变更单驱动——数据库与 Nacos

发布事故的头号根源不是工具，而是变更没落盘：开发改了字段口头通知运维，配置加在 Nacos 控制台、测试环境忘了加。规范只有一条：一次迭代对「环境」的所有变更——表结构、Nacos 配置——必须作为 changelog 文件随代码提交、随代码评审。

videocloud/changelog/
├── database/    # Liquibase 格式
│   ├── videomart-videocloud-changelog-db-v6.0.4.0-01.yaml
│   └── ...-02.yaml ...
└── nacos/
    └── videomart-videocloud-changelog-nacos-v6.0.4.0-01.yaml

命名 {服务}-changelog-{db|nacos}-{版本}-{序号}.yaml，序号定执行顺序。CD 的职责是按序、幂等地执行：

graph LR
    A[扫描 changelog<br/>按版本+序号排序] --> B{changeSet id<br/>已执行?}
    B -->|是| C[跳过，幂等]
    B -->|否| D["渲染占位符<br/>${VAR} ← Jenkins 凭据"]
    D --> E[执行<br/>DB: liquibase update<br/>Nacos: OpenAPI]
    E --> F[记录 id<br/>失败即终止流水线]

4.1 数据库变更单（Liquibase）

# changelog/database/videomart-videocloud-changelog-db-v6.0.4.0-01.yaml（节选）
databaseChangeLog:
  - changeSet:
      id: videomart-videocloud-changelog-db-v6.0.3.0-05
      author: cline
      comment: Add stream task table for transcoding
      changes:
        - sql:
            sql: |-
              CREATE TABLE `GTT_VIDEOMART_VIDEOCLOUD_STREAM_TASK` ( ... );

CD 用官方镜像执行，已执行的 changeSet 记在 DATABASECHANGELOG 表里，天然幂等：

sh '''
    docker run --rm -v $WORKSPACE/changelog/database:/liquibase/changelog \
        liquibase/liquibase:4.29 \
        --url=jdbc:mysql://prod-mysql:3306/videomart \
        --username=$DBU --password=$DBP \
        --changelog-file=videomart-videocloud-changelog-db-${VERSION}.yaml \
        update
'''

纪律三条：

只增不改、向后兼容：滚动更新期间新旧 Pod 同时在线，新代码要的表结构先就位，旧代码不能被新结构弄挂。
破坏性变更拆两次发布：先发「代码不再读写该字段」，观察一周，再发「删字段」。代码能回滚，删掉的列回不来。
执行过的 changeSet 绝不许改（checksum 变了 Liquibase 直接拒绝），要改就写新变更单。

4.2 Nacos 变更单

自定义格式，与 DB 同一套约定（videocloud 真实文件）：

# changelog/nacos/videomart-videocloud-changelog-nacos-v6.0.4.0-01.yaml
nacosChangeLog:
  - changeSet:
      id: videomart-videocloud-changelog-nacos-v6.0.4.0-01
      comment: videocloud drm configuration
      changes:
        - namespace: ${NAMESPACE}
          group: videocloud
          dataId: gtt-videomart-videocloud.properties
          format: properties
          patchContent: |-
              gtt.videomart.videocloud.db.username = ${VIDEOMART_VIDEOCLOUD_DATABASE_USERNAME}
              gtt.videomart.videocloud.aws.s3.accessKeyId = ${FUSIONSTORAGE_ACCESS_KEY}
              gtt.videomart.videocloud.aws.s3.secretAccessKey = ${FUSIONSTORAGE_SECRET_KEY}

注意：变更单里没有一个真实密钥，全是 ${占位符}——「key 叫什么、引哪份凭据」可以进 Git，「值是什么」不可以。

patchContent 是增量。CD 脚本逻辑：GET 现有配置 → envsubst 渲染增量 → 合并（增量覆盖同名 key）→ 整体发布 → 读回校验 → 记录 id。发布用的是 Nacos OpenAPI（POST /nacos/v1/cs/configs），Nacos 客户端长轮询秒级生效，不需要重启 Pod。生产 Nacos 必须开鉴权。

五、凭证权限划分：密钥只有 CD 管理员可见

占位符背后的真实值在哪、谁能碰？分三层：

graph TB
    Dev[开发者] -->|只能看到| Git[Git 仓库<br/>changelog 占位符 / 模板]
    CD[CD 管理员] -->|独占维护| Cred[Jenkins 凭据<br/>DB 账号 / S3 密钥]
    CD -->|独占维护| Sec[K8s Secret<br/>videomart-videocloud-secret]
    Pipe[CD 流水线] -->|"withCredentials 临时注入"| Cred
    Pod[运行中的 Pod] -->|"envFrom / secretRef"| Sec

四条规矩：

1. Jenkins 分角色。 Role-Based Strategy 插件：开发者能触发构建、看日志；只有 CD 管理员能管凭据、改生产流水线。凭据按 Folder 隔离，prod 的 DB 账号对开发者连「存在」都不可见。流水线里 withCredentials 临时注入，用完即销毁。

2. 服务只引用配置，绝不内嵌。 videocloud 的 bootstrap.properties 节选：

spring.cloud.nacos.config.server-addr=${NACOS_SERVER_ENDPOINT:localhost:8848}
spring.cloud.nacos.config.namespace=${NACOS_NAMESPACE:videomart}
spring.cloud.nacos.config.group=videocloud
spring.cloud.nacos.config.username=${NACOS_USERNAME}
spring.cloud.nacos.config.password=${NACOS_PASSWORD}
spring.cloud.nacos.config.refresh-enabled=true
spring.config.import=optional:nacos:gtt-videomart-videocloud.properties

服务只声明「连哪个 Nacos、读哪个 dataId」，账号全占位，生产由 K8s Secret 注入。默认值只给本地开发用，宁可留空让缺参时启动直接报错，也不要把内网地址当真默认值写进仓库。

3. 注入靠 Secret 引用。 看 k8s_deploy 的 Deployment 模板：

envFrom:
  - configMapRef: { name: gtt-common-config }        # 公共非敏感配置
  - secretRef:    { name: videomart-videocloud-secret }  # 本服务的 Nacos/DB 账号
  - secretRef:    { name: gtt-common-secret }        # 公共敏感配置

Secret 由 CD 管理员提前建好，开发者不需要、也不应该知道里面的值。

4. 轮换只动一处。 换 DB 密码 = 更新 Jenkins 凭据 + K8s Secret + 触发一次流水线，代码和模板都不用动。这就是「引用配置」相对「携带配置」的收益。

六、阶段四：更新 ConfigMap

《Kubernetes 学习总结与避坑指南》第七章讲透了两个坑，这里给结论：

环境变量注入的 ConfigMap，改了不生效，必须重启 Pod；文件挂载方式 kubelet 分钟级同步，但应用要自己支持 reload。
subPath 挂载单文件的 ConfigMap 永远不自动更新。

流水线的稳妥做法：kubectl apply 更新 ConfigMap 后无脑跟一次滚动更新——反正接下来要换镜像，合成一次滚动零成本。「要不要重启」交给脚本做死，比交给值班同学半夜判断可靠。

七、阶段五：部署与验证

7.1 部署配置长什么样

发布完成后集群里的对象关系：

graph TB
    GW[Gateway<br/>order.example.com] --> RT[HTTPRoute<br/>/api/order/**]
    RT --> SVC[Service videomart-videocloud<br/>ClusterIP 9577]
    SVC --> P1[Pod ✅] & P2[Pod ✅] & P3[Pod ✅]
    DEP[Deployment<br/>replicas: 3<br/>RollingUpdate] -.管理.-> P1
    CM[ConfigMap] -.挂载.-> P1
    NC[(Nacos)] -.长轮询推送.-> P1
    NC -.长轮询推送.-> P2
    NC -.长轮询推送.-> P3
    P1 --> DB[(MySQL)]

videocloud 的 Deployment 模板里有几处直接抄的规范：podAntiAffinity 强制同服务 Pod 分散到不同节点、topologySpreadConstraints 跨可用区打散、revisionHistoryLimit: 10 留回滚版本、探针端口与容器启动端口写死一致。对外暴露用 Gateway API（已 GA，Ingress 停止演进），把「入口」（Gateway，运维管）和「路由」（HTTPRoute，开发管）拆开。

7.2 部署与验证：流水线里真正干活的命令

stage('部署与验证') {
    steps {
        sh '''
            # 1. 渲染模板并部署
            envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml \
                | kubectl --kubeconfig=$KUBECONFIG apply -f -

            # 2. 阻塞等待滚动更新完成，超时/失败非零退出
            kubectl --kubeconfig=$KUBECONFIG -n $NAMESPACE \
                rollout status deployment/videomart-videocloud --timeout=300s

            # 3. 冒烟测试：健康检查 + 核心业务接口
            curl -fsS --retry 5 http://videomart-videocloud:9577/healthz || exit 1
        '''
    }
    post {
        failure {
            sh "kubectl --kubeconfig=$KUBECONFIG -n $NAMESPACE \
                rollout undo deployment/videomart-videocloud || true"
            // + 钉钉/邮件告警
        }
    }
}

再强调一遍：apply 成功只代表 apiserver 收下了 YAML。rollout status 阻塞 → 冒烟测试 → 失败自动 undo 三件套缺了，你的流水线只是「自动提交 YAML 的机器」。

7.3 部署凭证：别把 admin kubeconfig 给 Jenkins

给 Jenkins 一个只能操作特定 namespace、只能 patch Deployment 的 ServiceAccount（Role 限定 verbs get/list/watch/patch/update，完整 RBAC 示例见笔记 12.3 节）。凭证泄露的爆炸半径锁死在一个 namespace，且随时可 delete rolebinding 吊销。prod 部署再叠一个 input 人工审批。

7.4 弹性伸缩：HPA 不是配上就完事

前提：requests 必须配准（按 P95 实际用量）——HPA 的利用率是 实际用量 / requests，requests 瞎填，扩缩时机全错。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: videomart-videocloud }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: videomart-videocloud }
  minReplicas: 3        # 生产最小副本 ≥ 2，单副本没资格谈弹性
  maxReplicas: 20       # 按下游容量倒推（DB 连接数 / 每 Pod 连接数）
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 60 } }
  behavior:             # 快扩慢缩
    scaleUp:
      stabilizationWindowSeconds: 0
      policies: [{ type: Percent, value: 100, periodSeconds: 60 }]   # 每分钟最多翻倍
    scaleDown:
      stabilizationWindowSeconds: 300                                # 缩容观察 5 分钟
      policies: [{ type: Pods, value: 1, periodSeconds: 120 }]

配套三条：HPA 必搭 PDB（防节点维护+缩容+发布叠加把服务缩没）；GitOps 场景 Deployment YAML 别写死 replicas（否则 ArgoCD 每次同步把 HPA 扩的副本压回去）；HPA 管 Pod、Cluster Autoscaler 管节点，两层都要配，流量可预期的业务用 KEDA 定时伸缩提前备容量。

7.5 灰度发布：现有流程加两个 stage 就能支持

前面几节的设计纪律已经埋好了灰度所需的前提：模板里 Deployment 命名带版本（videomart-videocloud-${VERSION}）、Pod 打 app + version 双标签，而 Service 的 selector 只选 app——新旧两个 Deployment 可以并行存在，Pod 同时挂在同一个 Service 下。在这个基础上，灰度有两级做法：

第一级：副本级灰度（零新组件）。 渲染同一份模板，只换 VERSION 和 REPLICAS，拉起 1 个新版本副本与旧版并存——流量比 ≈ 副本比（3 旧 + 1 新 ≈ 25% 流量进新版）：

VERSION=v6.0.5.0 REPLICAS=1 IMAGE=$IMAGE:$TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml \
    | kubectl --kubeconfig=$KUBECONFIG apply -f -

第二级：权重级灰度（精确比例）。 新旧版本各起一个 Service（selector 分别锁定各自 version），用 Gateway API 的 HTTPRoute backendRefs 配 weight: 95 / 5，或上 Istio VirtualService 按权重/请求头分流。要「只让内部员工进新版」这类按用户维度的灰度，只能走这一级。

流水线形态——在「变更单执行」和「全量部署」之间插入灰度段：

graph LR
    A[变更单执行] --> B[部署 canary<br/>1 副本或 5% 权重]
    B --> C[观察期<br/>指标对比 / 人工 input]
    C -->|正常| D[全量滚动更新<br/>删除 canary]
    C -->|异常| E[删除 canary<br/>流量即刻回稳]

要点四条：

灰度期新旧版本同时在线，DB/Nacos 变更必须向后兼容——changelog「只增不改」的纪律正是为此准备的；不兼容的变更没有资格灰度。
观察期看指标不看感觉：canary 的错误率、P99 延迟与 stable 对比，Prometheus 按 version 标签分组就能出数——这就是 Pod 要打 version 标签的另一个理由。观察期可以是定时（如 10 分钟）加 Jenkins input 人工确认。
回滚动作极轻：删掉 canary Deployment，Service selector 自动不再选中它，秒级完成，不用动旧版本一根毫毛。
Nacos 配置也能灰度：配置支持按 IP/标签灰度下发，配置类变更先推给 canary 实例验证，再全量。

7.6 实操：给新版本分 20% 流量的完整跑法

以「线上 v6.0.4.0 共 4 副本，给 v6.0.5.0 分 20% 流量」为例，两种做法选一。

做法 A：副本比例近似（4 旧 + 1 新 ≈ 20%）。改动最小，适合服务间（东西向）流量或没有网关层权重能力的场景：

# 1. 变更单已执行完毕（DB/Nacos，向后兼容）
# 2. 起 1 个新版本副本（与旧版并存，同一个 Service 下）
VERSION=v6.0.5.0 REPLICAS=1 IMAGE=$IMAGE:$NEW_TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml | kubectl apply -f -
kubectl rollout status deployment/videomart-videocloud-v6.0.5.0 --timeout=300s

# 3. 观察：Prometheus 按 version 分组对比错误率 / P99

# 4a. 正常 → 全量：新版本扩到满配，再删旧版本
VERSION=v6.0.5.0 REPLICAS=4 IMAGE=$IMAGE:$NEW_TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml | kubectl apply -f -
kubectl rollout status deployment/videomart-videocloud-v6.0.5.0 --timeout=300s
kubectl delete deployment videomart-videocloud-v6.0.4.0

# 4b. 异常 → 回滚：删掉 canary 即可，旧版全程没动过
kubectl delete deployment videomart-videocloud-v6.0.5.0

做法 B：HTTPRoute 权重精确 20%。适合入口（南北向）HTTP 流量。需要两个按 version 锁定 selector 的 Service：

# stable 和 canary 各一个 Service，selector 分别锁死版本
# videomart-videocloud-stable:  selector { app: videomart-videocloud, version: v6.0.4.0 }
# videomart-videocloud-canary:  selector { app: videomart-videocloud, version: v6.0.5.0 }
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: videocloud-route }
spec:
  parentRefs: [{ name: prod-gateway }]
  hostnames: ["videocloud.example.com"]
  rules:
    - backendRefs:
        - { name: videomart-videocloud-stable, port: 9577, weight: 80 }
        - { name: videomart-videocloud-canary, port: 9577, weight: 20 }

调比例就是改 weight（20% → 50% → 100%)，每次 kubectl apply 即时生效。全量后把 stable Service 指向新版本、删掉 canary，路由权重归位。

做法 B 有一个必踩的坑：原来那个 selector 只选 app 的 Service，灰度期间会同时选中新旧 Pod——HTTPRoute 里 20% 的权重之外，走老 Service 的内部调用方还在按副本比随机进新版，等于流量叠加失控。所以权重灰度前，必须把老 Service 的 selector 也加上 version 锁到旧版，或者干脆只保留 stable/canary 两个 Service。

对应的 Jenkinsfile 就是在「变更单执行」后加两个 stage：

stage('灰度 20%') {
    steps { sh 'deploy-canary.sh $NEW_TAG 20' }   // 上面做法 A/B 的脚本化
}
stage('灰度观察') {
    steps {
        sh 'check-canary-metrics.sh'              // 错误率/P99 对比，超阈值非零退出
        input message: '灰度指标正常，是否全量？'    // 人工确认，prod 必备
    }
}
stage('全量') { steps { sh 'promote-canary.sh $NEW_TAG' } }
post { failure { sh 'cleanup-canary.sh || true' } }  // 任何失败自动清理 canary

八、配置治理：文档化与三环境一致性

8.1 配置文档化：阈值不再是「口口相传」

症状：限流阈值为什么是 500 不是 1000，只有离职的那个人知道。解法：每个服务在仓库里维护 CONFIG.md，强制四列——配置项 / 含义 / 当前值 / 取值依据与影响面：

配置项	含义	当前值	取值依据与影响面
`upload.retryCount`	上传重试次数	5	对象存储偶发抖动 P99 在 3 次内恢复；超过 5 次基本是故障，应快速失败
`upload.chunkSize`	分片大小	5MB	内网带宽实测拐点；调大加剧内存压力

纪律三条：配置项三处一致（Git 里的值、CONFIG.md、代码注释，评审时卡点检查）；阈值必须写取值依据（拍脑袋的值两个版本后就成了没人敢动的屎山）；开关必须有退役计划（全量后一个迭代内删除）。进阶：用 JSON Schema 在推送 Nacos 前校验类型和取值范围，低级错误 CI 阶段拦住。

8.2 三环境一致性：写法一致，取值注入

「在测试环境是好的」的根源：各环境配置是各自维护的副本。解法前面已经埋下——仓库里只有一份参数化模板和变更单，差异压缩成发布时注入的参数：

差异项	注入方式	维护者
namespace、集群地址	CD 环境参数	CD 管理员
副本数、资源 requests/limits	CD 环境参数	CD 管理员
DB 账号、密钥、合作方地址	Jenkins 凭据 → envsubst	CD 管理员（开发者不可见）
业务阈值、特性开关	changelog 变更单，三环境执行同一份	开发者（评审把关）

「写法」必须三环境一致，「取值」本来就该不同。再加两道保险：发 prod 前用各环境参数分别渲染同一份模板并 diff（源头只有一份，diff 干干净净只有几行）；每周漂移检测，发现有人手工改过线上配置就告警（上 ArgoCD 后免费获得）。

九、行业动态：2025–2026 值得关注的变化

GitOps 成默认答案：Jenkins 只构建推镜像，集群内 ArgoCD 从 Git 同步部署——CI 不再需要生产集群凭证，安全性质变。
Gateway API 取代 Ingress：后者已停止演进，新项目别再用它起头。
供应链安全成必修：cosign 签名、SBOM、SLSA 框架已进入金融政企招标要求。
CI 引擎分化：Tekton、Dagger 各有拥趸，GitHub Actions 吞噬中小团队；Jenkins 份额缓降，但存量企业和内网仍是主力。
AI 进流水线：CI 失败日志自动归因、pipeline 脚本生成评审已经实用；「AI 自动决定发布」不建议——爆炸半径需要人负责。

十、思考与感悟

1. 流水线的本质是「把运气变成流程」。 手工发布的质量取决于值班同学当晚的状态。流水线的价值不是快，是把「老司机会记得检查、新人一定会漏」的 20 个检查点固化成代码——先消灭方差，其次才是耗时。

2. 最贵的知识是顺序和兼容。 DB 先于应用、配置先于重启、破坏性变更拆两次——背后是同一个认知：发布中系统处于新旧混合的中间态，所有设计都要保证中间态可用。蓝绿、金丝雀、滚动更新都只是它的具体实现。

3. 验证深度决定发布频次。 没有可靠自动验证 → 发布靠人肉兜底 → 怕 → 少发 → 单次变更量大 → 更怕，恶性循环。打破循环的入口就是把验证做深：rollout 阻塞、冒烟、自动回滚。验证越可信，发布越敢小而频。

4. 配置有权限边界。 「引用关系」进 Git，「真实值」进凭据系统，且只有 CD 管理员能碰。这条边界一开始不划，等密钥躺在几百人可见的仓库里再补救就晚了。

十一、避坑清单（速查）

Webhook 触发，不用轮询；Controller 不跑构建；agent 用一次性 Pod + 依赖缓存 PVC + CI 专用 SSD 节点池；无依赖的部署步骤并行。
镜像 tag = git commit 短哈希，杜绝 latest；仓库开 tag 不可变；cosign 签名。
DB 与 Nacos 变更一律走 changelog 变更单，随代码评审，CD 按序幂等执行；控制台手工改属违规。
数据库变更只增不改；破坏性变更拆两次发布；执行过的 changeSet 绝不许改。
变更单和模板只写 ${占位符}；真实密钥只在 Jenkins 凭据和 K8s Secret，只有 CD 管理员可见；服务一律 envFrom/secretRef 引用。
每个服务维护 CONFIG.md 四列（配置项/含义/当前值/取值依据）；开关有退役计划。
仓库只存一份环境无关模板，环境差异由 CD 注入；发 prod 前渲染结果 diff；每周漂移检测。
ConfigMap 更新后跟一次滚动更新（env 注入和 subPath 都不自动生效）。
Deployment 必配 readinessProbe + maxUnavailable: 0 + preStop 延迟；revisionHistoryLimit 别设 0。
验证三件套：rollout status → 冒烟 → 失败自动 undo + 告警。
HPA：requests 按 P95 配准；minReplicas ≥ 2、maxReplicas 按下游容量倒推；快扩慢缩 + PDB；GitOps 场景别写死 replicas。
灰度发布：Service selector 只选 app、Deployment 按版本并行，先副本级灰度，要精确比例再上 HTTPRoute 权重；观察期看 version 分组的指标；回滚 = 删 canary。
Jenkins 用最小权限 ServiceAccount，prod 加 input 审批；新系统对外暴露用 Gateway API；渲染快照进发布记录库，为 GitOps 铺路。

参考资料：

《Kubernetes 学习总结与避坑指南》（本站 kubernetes-authoritative-guide-notes.md）：ConfigMap 注入机制、RBAC 最小权限、rollout 验证的完整细节

Jenkins 官方文档 / Liquibase / Nacos OpenAPI

Kubernetes Gateway API / ArgoCD / SLSA

Netflix 如何用 Kueue 简化批计算：一次百万级任务的换心手术

Mon, 22 Jun 2026 10:00:00 +0800

Netflix 如何用 Kueue 简化批计算：一次百万级任务的换心手术

原文：How Netflix Simplified Batch Compute with Kueue 目标读者：维护过或正在维护自研任务调度/排队系统的工程师；以及所有纠结过「自研轮子 vs 换开源方案」的人。阅读目标：搞清楚 Netflix 为什么敢把百万级批任务的排队调度层整体换成 Kueue、怎么换的、换完拿到了什么。重点不在 Kueue 的用法，在这次迁移的姿势。

〇、先把背景摊开：CMB 和 Titus

Netflix 的容器平台叫 Titus，跑批任务用的是自建方案 CMB（Compute Managed Batch），2018 年建的。CMB 负责的事：用户提交跑到结束的批工作负载，按租户层级排队、按优先级有序执行、按租户管理容量；真正跑任务的活交给 Titus。

Titus 对 CMB 有两个关键能力：跨 cell 联邦（一个 cell 就是一个 K8s 集群）和联邦容量预留。所以 CMB 只需要对 Titus 的一个端点说话，不用关心底下集群的拓扑——这一层抽象是后面整次迁移能「无感」的地基。

租户层级与两种容量

CMB 的租户是一棵树，分两类：

内部租户（Internal Tenant）：只做组织，不接收任务，没有队列；子节点可以是内部或叶子租户。
叶子租户（Leaf Tenant）：能接收任务，挂队列，不能再有子节点。

容量也分两种：

预留容量（Reserved）：内部租户的预留在其子树内公平共享；叶子租户的预留则是独占切分，别的租户碰不了，保证吞吐。
共享容量（Shared）：Compute 团队维护一个全局池子，谁都可以 burst 进去。池子按租户公平共享——但注意，CMB 的公平只在准入（admission）那一刻生效：它没有抢占，任务一旦放行就跑到结束，哪怕公平份额已经变了。这个语义缺口后面会被 Kueue 填上。

一、为什么是 Kueue：自研轮子的折旧时刻

CMB 2018 年建的时候，开源界还没有像样的批计算方案。但 K8s 生态滚了几年之后，CMB 有的和想要的功能——公平共享、层级租户、容量管理、优先级队列——开源项目全都有了。反过来，CMB 想加新功能（比如抢占）越来越费劲，因为它离底层的 K8s 集群隔得太远。这就是自研系统的经典折旧曲线：当年它填补空白，现在它阻碍你吃到生态红利。

团队评估了怎么把批抽象现代化，最后选了 Kueue，理由五条，第一条最值得琢磨：

Kueue 不替换 kube-scheduler。 和 YuniKorn、Volcano 不同，Kueue 只管排队和准入，Pod 调度还是 kube-scheduler 干，所以能和 Titus 已有的调度画像（scheduling profiles）集成。换掉 Titus 的调度画像会让任务摆放（placement）碎片化，损害效率。这条的工程含义：选组件时，「它不管哪一段」和「它管哪一段」同样重要——Kueue 把调度和排队拆开，只拿走排队这一段，接入面就小得多。
社区采用势头和创新速度。
支持异构硬件上的多租户配额管理。
能操作 v1.Pod、batch/v1.Job 这类原生原语，也支持 RayJob / RayCluster 这类高层抽象，留好了扩展空间。
自带团队本来想在 CMB 里自己造的功能：抢占、all-or-nothing 调度、拓扑感知调度。

二、迁移：Netflix Batch 的三条军规

这次把 CMB 工作负载迁到 Kueue 的项目，内部叫 Netflix Batch。军规三条：

对 CMB 终端用户零负担、完全透明。
容器启动速率和整体最大吞吐不允许回退。
用 Kueue 替换 CMB 的排队与调度。

新旧提交流程的关键差别：排队和调度被下放给每个启用了 Kueue 的 Titus cell 里的 Kueue，Titus 联邦层通过一个自研 Kueue 路由器把任务路由到 Kueue cell。注意这里没说换成 K8s 的通用调度入口——联邦这层壳还在，换的是壳里面的引擎。

租户管理这边，对运维来说迁移简单到「在 UI 上给租户点一个按钮」，出问题也能一键回滚。按钮底下的映射关系是：

内部租户 → Cohort
叶子租户 → ClusterQueue + LocalQueue
租户上的容量配置 → resource flavor + 名义配额（nominal quota）

flowchart LR
    subgraph OLD["迁移前 CMB"]
        U1["用户与应用"] -->|"提交批任务"| CMBQ["CMB 自研排队与调度<br/>租户层级加公平共享"]
        CMBQ --> FED["Titus 联邦层"]
        FED --> CELL["Titus cell 各 K8s 集群"]
    end
    subgraph NEW["迁移后 Netflix Batch"]
        U2["用户与应用 同一 API"] -->|"提交批任务 无感"| ROUTER["自研 Kueue 路由器"]
        ROUTER --> KQ["各 cell 内的 Kueue<br/>ClusterQueue 排队与准入"]
        KQ --> KS["kube-scheduler 负责 Pod 摆放"]
    end
    OLD -.->|"只换排队调度引擎<br/>API 与联邦层不动"| NEW
    style KQ fill:#fff3cd

这张图是整篇文章的骨架：对上一寸不动，对下一寸不动，只把中间自研的那层换成开源组件。 用户侧的 API、Titus 的联邦与调度画像都是旧资产，全保留了。

三条经验教训（全文最有信息量的部分）

先保 API 平价，先换底层组件。 不给用户暴露新 API 面，而是把底下组件换掉作为第一步。原文的说法是 unstacking bets——把赌注拆开：不让「用户迁新 API」和「底层换引擎」两件事耦合成一次豪赌。项目风险降了，客户体验也没断。
别把最复杂的客户留到最后。 他们一上来就迁最大最复杂的那个客户。信心是先难后易建起来的，后面其他客户的迁移就顺了——结果整个生产迁移只花了 4 周。多数迁移的直觉是「先易后难、小步快跑」，Netflix 反着来：最难的客户先过，因为它把所有边角情况一次性暴露完，剩下的全是子集。这和「先打最硬的仗」是一个道理——前提是第 1 条保证了输得起。
Kueue 的默认参数顶不住 Netflix 的量。 必须把 QPS、Burst、groupKindConcurrency 调得比默认高很多才能满足吞吐。这个坑是提前在仿 Titus 的开发环境跑负载测试趟出来的，不是生产上撞出来的。

三、换完之后：抢占式公平共享补上了语义缺口

Kueue 已在生产全量铺开，管理着数百万级批工作负载。前面说的 CMB「公平只在准入时生效、无抢占」的语义缺口，现在用**基于抢占的公平共享（Preemption-based Fair Sharing）**补上了：

预留容量没人用的时候可以借给其他租户，主人回来再抢回来——预留语义保住，闲置不再浪费。
高优先级任务可以抢占低优先级任务——关键业务的周转时间变快，且不怕饿死。

原文给的 ClusterQueue 抢占配置示例：

apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "team-a-cq"
spec:
  preemption:
    reclaimWithinCohort: Any
    withinClusterQueue: LowerPriority

reclaimWithinCohort: Any 意思是：同 Cohort 里谁借了我的份额，我随时可以抢回来（不限优先级）；withinClusterQueue: LowerPriority 意思是：队列内部只抢优先级比我低的。两条规则分别对应「租户之间」和「租户之内」两个维度的公平。

效果：Compute 团队观察到平均资源利用率显著提升（原文没给具体数字，只有这个定性结论）。另外这套经验正在外溢到其他内部团队，包括搭 K8s 原生训练基础设施的团队——批计算和 ML 训练的调度问题，本质上是同一个。

flowchart TD
    subgraph COHORT["Cohort 对应内部租户 子树"]
        CQA["ClusterQueue 团队 A<br/>有预留配额"] 
        CQB["ClusterQueue 团队 B<br/>有预留配额"]
    end
    CQA -->|"配额闲置时<br/>借给同 Cohort 成员"| CQB
    CQB -->|"主人回来 reclaimWithinCohort Any<br/>抢占借出去的资源"| CQA
    CQA -->|"队列内部<br/>高优先级抢占低优先级"| PRE["withinClusterQueue LowerPriority"]
    PRE --> R["预留语义不丢<br/>闲置容量不浪费<br/>利用率上升"]
    style R fill:#e8f5e9

四、工程实践联想

迁移的黄金姿势：API 不动，引擎换心。 Netflix 把「用户迁新 API」和「底层换引擎」拆成两个独立的赌注，先只赌后者。回到我们自己的项目：存储换引擎、队列换实现、框架换内核，第一件事永远是把门面焊死。门面动了，你就同时在做两个项目。
先迁最难的客户，但要先有回滚按钮。 「最难的先来」之所以成立，是因为他们有 UI 一键切换加一键回滚托底。没有廉价回滚能力之前，先难后易是鲁莽，不是勇气。顺序是：先造回滚，再挑硬骨头。
调度与排队分层，是值得抄的架构决策。 Kueue 只做排队准入，Pod 摆放留给 kube-scheduler。这个切分让 Netflix 保住了 Titus 多年的调度调优积累。评估任何「大而全」的调度系统（YuniKorn、Volcano 都是全替换派）时，先问：它接管的那一层，我原有的积累值多少钱？
开源组件的默认参数是按「示例集群」调的，不是按你的量。 QPS、Burst、并发数这类旋钮，上生产前必须在仿真环境里压出来。Netflix 的负载测试环境「模仿 Titus」，这笔钱花在了迁移前，不是事故后。
自研系统要定期做折旧审计。 CMB 不是烂系统，是时代变了：它独有的功能被生态追平，它缺失的功能（抢占）自研成本却越来越高。每两年问一次「这轮子如果今天立项，我还会自己造吗」，答案变了就该动手了。顺带一提，做 AI 训练平台的可以直接抄作业：批任务的排队、配额、抢占、多租户公平，和 GPU 训练集群的调度问题是同构的，Kueue 支持 RayJob/RayCluster 就是 Netflix 明说的扩展点。

本篇小结

背景：CMB（2018 年自研托管批处理）跑在 Titus 上，租户分内部/叶子两级，容量分预留/共享两种；共享容量只在准入时公平，无抢占。
动机：K8s 生态追平了 CMB 的功能，而自研新功能（如抢占）成本越来越高；Kueue 不替换 kube-scheduler、支持异构配额和 Pod/Job/RayJob，且有抢占、all-or-nothing、拓扑感知调度等原生能力。
迁移（Netflix Batch）：用户零感知、吞吐不回退、排队调度换 Kueue；内部租户映射为 Cohort，叶子租户映射为 ClusterQueue + LocalQueue，容量配置映射为 resource flavor + nominal quota；UI 一键切换、可回滚。
经验：API 平价先行拆分赌注；最大最复杂的客户最先迁，生产迁移仅 4 周；Kueue 需调高 QPS/Burst/groupKindConcurrency，靠仿真环境负载测试提前摸底。
现状：生产全量、数百万批工作负载；基于抢占的公平共享（reclaimWithinCohort: Any + withinClusterQueue: LowerPriority）让预留容量可出借可回收，平均资源利用率显著提升。

一句话收束：这篇文章表面讲 Kueue，实际讲的是一个成熟组织怎么给自研系统办一场体面的退休——不办追悼会（大 rewrite），办的是工作交接（API 不变、逐层替换、最难的先交）。

参考资料

How Netflix Simplified Batch Compute with Kueue（原文，作者 Alvin Bao、Alex Petrov、Jennifer Lai、Aidan Sherr、Samartha Chandrashekar，2026-06-22）
Kueue 官方文档（K8s 原生的批任务排队系统，原文提到的 Cohort、ClusterQueue、LocalQueue、resource flavor、抢占语义的权威定义）
YuniKorn 与 Volcano（原文对比中提到的全替换派调度器）
Netflix Titus（Netflix 容器平台，CMB 与 Netflix Batch 的运行底座）

☸️ Kubernetes 学习总结与避坑指南

Wed, 12 Feb 2025 10:00:00 +0800

☸️ Kubernetes 学习总结与避坑指南

参考书籍：龚正等《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触》、Marko Lukša《Kubernetes in Action》目标读者：会一点 Docker、刚接触 K8s，或者「YAML 会抄但一出问题就懵」的同学。

Kubernetes（简称 K8s，因为 K 和 s 之间有 8 个字母）是 Google 开源的容器编排系统，解决了「成百上千个容器跑在成百上千台机器上，谁来调度、谁来扩容、挂了谁来拉起」的问题。它不是一门「背完概念就会」的技术——新人最常见的状态是：每个名词都听过，但它们之间怎么串起来的说不清楚，Pod 一挂就不知道该看哪里。

这篇文章帮你建立主干知识框架：

K8s 集群整体长什么样？Master 和 Node 各自干什么？
Pod、Node、Service、Ingress、ConfigMap 这些核心对象到底是什么关系？
Istio 服务网格在解决什么问题？
共享存储（PV/PVC/NAS）怎么用，有哪些坑？
排查 K8s 问题需要补哪些 Unix 网络编程基础知识？
生产环境如何做内外网访问隔离（私网端点 / 内网 LB / NetworkPolicy）？
在阿里云 ACK（以及 AWS EKS）上落地时要注意什么？
Jenkins 如何与 K8s 打通，实现自动化部署、验证与失败回滚？
遇到 CrashLoopBackOff、OOMKilled、502、DNS 慢这些经典问题，该按什么思路排查？

一、K8s 整体架构：一个「中心化大脑 + 一群干活的节点」

K8s 集群在逻辑上分为两大部分：

控制平面（Control Plane，俗称 Master）：集群的大脑，负责「决策」——调度、扩缩容、故障自愈。
工作节点（Node）：真正跑容器的机器，负责「执行」。

graph TB
    subgraph 控制平面["控制平面 Control Plane（阿里云 ACK 托管，用户不可见）"]
        APIServer[kube-apiserver<br/>集群唯一入口，所有操作都经过它]
        ETCD[(etcd<br/>分布式 KV 存储<br/>集群所有状态都在这里)]
        Scheduler[kube-scheduler<br/>决定 Pod 调度到哪个 Node]
        CM[kube-controller-manager<br/>各种控制器：副本数维持、节点监控等]
        CCM[cloud-controller-manager<br/>对接云厂商：SLB/EBS/路由]
    end

    subgraph 节点1["Worker Node 1"]
        K1[kubelet<br/>节点上的「包工头」]
        P1[kube-proxy<br/>维护 Service 网络规则]
        C1[容器运行时<br/>containerd]
        Pod1[Pod A] ~~~ Pod2[Pod B]
    end

    subgraph 节点2["Worker Node 2"]
        K2[kubelet]
        P2[kube-proxy]
        C2[containerd]
        Pod3[Pod C]
    end

    APIServer --> ETCD
    Scheduler --> APIServer
    CM --> APIServer
    CCM --> APIServer
    K1 --> APIServer
    K2 --> APIServer
    User[kubectl / CI/CD] --> APIServer

记住这条主线：所有组件只跟 apiserver 说话，apiserver 把状态写进 etcd。你敲的每一条 kubectl 命令、每一个控制器的决策，都是「读/写 apiserver」这个动作。理解了这一点，后面所有概念都好串了。

K8s 的核心设计思想是声明式 API + 控制器循环：

graph LR
    A[你提交 YAML<br/>期望状态：3 个副本] --> B[apiserver 存进 etcd]
    B --> C{控制器不断对比<br/>期望状态 vs 实际状态}
    C -->|实际只有 2 个| D[再创建 1 个 Pod]
    D --> C
    C -->|一致| E[什么都不做]

这就是「自愈」的本质：不是有人盯着修，而是控制器永远在循环纠偏。所以 K8s 里的对象是「期望状态」的描述，不是一条条命令。

二、Node：干活的机器

2.1 Node 上有什么

每个 Node 上必装三个组件：

kubelet：节点代理。接收 apiserver 下发的 Pod 定义（PodSpec），调用容器运行时把容器拉起来，并持续上报节点和 Pod 状态。Pod 挂了重启、探针检测，都是 kubelet 干的。
容器运行时：真正拉镜像、跑容器的软件。Docker 已在 K8s 1.24 后被移除，现在主流是 containerd。
kube-proxy：维护节点上的网络规则（iptables/IPVS），让 Service 的虚拟 IP 能转发到真实 Pod。

2.2 节点相关的避坑点

节点 NotReady：最常见的原因是 kubelet 挂了、节点磁盘满（DiskPressure）、内存不足（MemoryPressure）或网络不通。排查顺序：先 kubectl describe node <名字> 看 Conditions，再登节点看 systemctl status kubelet 和日志 journalctl -u kubelet。
磁盘压力：容器日志、镜像、emptyDir 都在吃节点磁盘。务必给应用日志配轮转（logrotate 或运行时自带的日志上限 containerLogMaxSize），否则磁盘写满会把节点上所有 Pod 驱逐（Evicted）。
不要随意登节点手工改东西：K8s 期望节点是「牛」不是「宠物」——可替换、不特殊。手工装的 Agent、改的 iptables 规则，节点一重建全没了。需要节点级能力请用 DaemonSet。

三、Pod：K8s 的最小调度单元

3.1 为什么不是直接调度容器

Pod 是一组共享网络和存储的容器集合。同一个 Pod 里的容器：

共享同一个 IP 和端口空间（通过 localhost 直接互通）
可以共享 Volume

graph TB
    subgraph Pod["Pod（10.0.1.15）"]
        direction LR
        C1[主容器<br/>app:8080]
        C2[边车容器<br/>日志采集]
        V[(共享 Volume<br/>日志目录)]
        C1 --> V
        C2 --> V
    end
    C1 -.->|localhost:8080| C2

这个设计的经典用途就是 Sidecar（边车）模式：日志采集、流量代理（Istio 的 Envoy）都以边车容器形式注入 Pod，主容器无感知。

新人直觉「一个 Pod 跑一个容器」，这对 90% 的场景是对的。只有容器之间必须同生共死、共享 localhost 或共享文件时，才放进同一个 Pod。

3.2 Pod 生命周期与探针

stateDiagram-v2
    [*] --> Pending: 创建，等调度/拉镜像
    Pending --> Running: 调度成功，容器启动
    Running --> Succeeded: 正常退出（Job 类）
    Running --> Failed: 异常退出
    Running --> Running: 探针失败→kubelet 重启容器

三个探针，新人人手必配：

探针	作用	配错的后果
`livenessProbe`	判断容器是否活着，失败则重启容器	太灵敏 → 无限重启循环
`readinessProbe`	判断是否能接流量，失败则从 Service 摘除	不配 → 启动期请求打到没 ready 的 Pod，报 502
`startupProbe`	启动探针，成功前禁用另外两个	慢启动应用（如老 Java 服务）不配 → 被 liveness 误杀

3.3 资源 requests/limits 与 QoS：最容易被忽视的重灾区

resources:
  requests:        # 调度依据：保证分到这么多
    cpu: "250m"    # 0.25 核
    memory: "512Mi"
  limits:          # 使用上限
    cpu: "500m"
    memory: "1Gi"

requests 是调度的唯一依据：节点剩余可分配资源 ≥ Pod 的 requests 总和，Pod 才调度得上去。不配 requests，调度就是瞎排，节点超载。
CPU 超 limit → 被限流（throttle），容器变慢但不死；内存超 limit → OOMKilled，直接杀。这是两种完全不同的失败模式，排查时先分清。
QoS 等级：requests=limits 为 Guaranteed（最后被驱逐）；都不配为 BestEffort（节点资源紧张时最先被杀）。生产核心服务至少配 Burstable。

四、工作负载：不要直接创建裸 Pod

实际工作中你几乎不会手写 Pod，而是使用「管理 Pod 的控制器」：

对象	适用场景	一句话
Deployment	无状态服务（Web/API）	副本数 + 滚动更新 + 回滚
StatefulSet	有状态服务（MySQL/Kafka）	稳定的名字和网络标识、按序启停
DaemonSet	节点级 Agent（日志/监控）	每个 Node 跑一个
Job / CronJob	一次性/定时任务	跑完即退

Deployment 滚动更新过程：

sequenceDiagram
    participant U as 用户
    participant D as Deployment
    participant RS1 as ReplicaSet v1
    participant RS2 as ReplicaSet v2

    U->>D: kubectl set image 更新镜像
    D->>RS2: 创建新 RS，先拉起 1 个新 Pod
    RS2-->>D: 新 Pod ready
    D->>RS1: 缩掉 1 个旧 Pod
    Note over D,RS2: 循环：新 +1 → 旧 -1
    D->>RS1: 缩到 0（旧 RS 保留，可回滚）
    U->>D: kubectl rollout undo（随时回滚）

避坑点：

maxSurge / maxUnavailable 控制滚动节奏。默认 25%/25%，意味着更新中可能瞬间少 25% 的可用副本——容量紧张的服务要调小 maxUnavailable。
回滚靠旧 ReplicaSet 保留的 Pod 模板，revisionHistoryLimit 默认 10，别设成 0 否则无法回滚。
镜像 tag 不要用 latest：无法回滚、无法审计，且 imagePullPolicy 行为反直觉。用 git commit 号或语义化版本。

五、K8s 网络模型与必备的 Unix 网络编程知识

K8s 的网络问题占了线上故障的一半以上。而很多「K8s 网络问题」本质上是 Unix 网络编程/TCP 协议问题，只是发生在容器环境里。这一节把两边打通。

5.1 K8s 网络的三条铁律

K8s 对网络模型只有三个基本要求（具体实现交给 CNI 插件，如 Flannel、Calico、阿里云 Terway）：

每个 Pod 有自己的独立 IP
任意两个 Pod 之间可以直接通信（不经过 NAT）
Node 和 Pod 之间可以直接通信

graph LR
    subgraph 节点A["Node A"]
        PA["Pod A<br/>10.244.1.5"]
    end
    subgraph 节点B["Node B"]
        PB["Pod B<br/>10.244.2.8"]
    end
    PA <-->|"Pod 网络（CNI：Terway/Flannel/Calico）<br/>直连，无 NAT"| PB

5.2 Service：一组 Pod 的稳定入口

Pod 会漂移（重建后 IP 就变了），所以不能在代码里写死 Pod IP。Service 提供一个固定虚拟 IP（ClusterIP）+ DNS 名字，负载均衡到后端 Pod。

graph LR
    Client[客户端 Pod] -->|"访问 my-svc:80<br/>DNS 解析为 10.96.0.10"| SVC["Service: my-svc<br/>ClusterIP 10.96.0.10"]
    SVC -->|kube-proxy 的 iptables/IPVS 规则转发| P1[Pod 1]
    SVC --> P2[Pod 2]
    SVC --> P3[Pod 3]

三种 Service 类型：

ClusterIP（默认）：仅集群内可达
NodePort：在每个节点开一个高端口（30000-32767），可从集群外访问
LoadBalancer：对接云厂商负载均衡器（阿里云 CLB/SLB、AWS NLB/ALB），对外暴露的标准姿势

5.3 为什么排查 K8s 网络要懂 Unix 网络编程

下面这几组知识，是在 K8s 环境里排查连接问题的「元技能」：

（1）TCP 连接状态与 TIME_WAIT

TCP 挥手后主动关闭方会进入 TIME_WAIT 状态，默认保持 2MSL（Linux 上约 60s）。在高并发短连接场景（比如服务间大量 HTTP/1.0 式短调用），客户端端口会被 TIME_WAIT 大量占用，最终 Cannot assign requested address。

stateDiagram-v2
    ESTABLISHED --> FIN_WAIT1: 主动方 close()
    FIN_WAIT1 --> FIN_WAIT2: 收到对端 ACK
    FIN_WAIT2 --> TIME_WAIT: 收到对端 FIN
    TIME_WAIT --> CLOSED: 2MSL 超时（约60s）
    ESTABLISHED --> CLOSE_WAIT: 对端先 close()
    CLOSE_WAIT --> LAST_ACK: 我方 close()
    LAST_ACK --> CLOSED

K8s 里的对应症状与解法：

症状：服务间调用偶发超时，ss -s 看到 timewait 几万。
正解：应用层用长连接 + 连接池（HTTP keep-alive、gRPC），别依赖 net.ipv4.tcp_tw_reuse 这类内核参数硬扛。
另一个常见坑是 CLOSE_WAIT 堆积：对端关了连接但你的代码没 close()（连接泄漏），ss -ant | grep CLOSE_WAIT 一查便知。

（2）socket、backlog 与「连接被 Reset」

服务端 listen(fd, backlog) 的 backlog 是「已完成三次握手但应用还没 accept」的队列长度。K8s 场景下突发流量打到刚重启的 Pod，如果应用 backlog 太小（或迟迟不 accept），内核会直接 RST，客户端看到的是 Connection reset by peer。这类问题在 Pod 扩容瞬间、探针刚通过时高发——readinessProbe 通过 ≠ 应用真的能扛流量。

（3）epoll 与 I/O 多路复用

一个进程通过 epoll 可以管理数万连接（C10K 问题的解法）。Nginx Ingress、Envoy 都是 epoll 模型。要懂的点：

进程能开的连接数受 文件描述符上限限制：ulimit -n。容器里同样生效，高并发服务记得确认 limit（cat /proc/<pid>/limits）。
每个 TCP 连接 = 一个四元组（源IP:源端口 → 目标IP:目标端口）。客户端对单一目标的并发连接数理论上受源端口数（约 2.8 万个可用）限制——这又回到「必须用连接池复用连接」。

（4）conntrack：K8s 特有的网络坑

kube-proxy 的 iptables 模式依赖内核 conntrack（连接跟踪表）。节点上连接数巨大时 conntrack 表被打满（默认 nf_conntrack_max 往往不够），表现为新建连接随机丢包、无日志，极难排查。解法：调大 net.netfilter.nf_conntrack_max，或干脆把 kube-proxy 切到 IPVS 模式。阿里云 ACK 的 Terway 模式在这方面压力小很多。

（5）DNS：K8s 里的「隐形依赖」

集群内所有服务名解析都靠 CoreDNS。两个经典坑：

glibc 的 DNS 解析是串行的，且默认 ndots:5 导致集群内短域名先查 5 次后缀。症状：应用偶发解析慢 5s（一次超时重传）。解法：FQDN 写法 my-svc.my-ns.svc.cluster.local.（结尾加点）或调整 Pod 的 dnsConfig。
Java 应用默认永久缓存 DNS 结果（networkaddress.cache.ttl=-1），Service 后端 IP 变了 JVM 不知道。容器里务必显式设置 DNS 缓存 TTL（如 30s）。

5.4 内外网访问隔离：哪些服务能暴露，哪些必须藏住

生产集群的基本安全原则：默认所有东西都不出集群，只开必要的口子。K8s 默认网络是「全通」的（任何 Pod 可以访问任何 Pod，LoadBalancer 一不小心就开到公网），隔离要靠自己显式配置。隔离分三个层面，从外到内：

graph TB
    Internet[公网用户] -->|只放行 443| WAF[WAF / 安全组<br/>云平台层]
    WAF --> PubLB[公网 ALB/CLB<br/>仅 Web 入口服务]
    PubLB --> PubIng[Ingress Controller<br/>公网命名空间]
    PubIng --> WebSvc[Web Service<br/>ClusterIP]

    Office[办公网/运维] -->|VPN/跳板机| IntLB[内网 LoadBalancer<br/>intranet 类型]
    IntLB --> AdminSvc[管理后台 / 监控<br/>Grafana / Jenkins]

    subgraph 集群内["集群内部（东西向流量）"]
        WebSvc -->|NetworkPolicy 允许| AppSvc[业务 Service]
        AppSvc -->|NetworkPolicy 允许| DBSvc[数据库 Proxy Service]
        AppSvc -.->|NetworkPolicy 拒绝| Other[其他 namespace]
    end

第一层：云网络边界（VPC / 安全组）

API Server 用私网端点：阿里云 ACK 创建集群时选择「专有网络（私网）」API Server 访问，或只绑定内网 EIP，运维通过 VPN/跳板机访问；公网端点即便有证书认证也是攻击面。AWS EKS 对应 endpoint private access。
节点安全组收紧入方向：只放行 NodePort 范围给内网、放行 LB 健康检查来源，其余一律拒绝。ACK 的节点安全组默认规则要审一遍。
数据库、Redis 这类云产品走 VPC 内网地址，安全组只对集群节点网段开放。

第二层：Service 暴露方式——内外网分流的关键

LoadBalancer 类型 Service 默认创建的是公网 LB，这是最常见的「误暴露」事故。面向内部的服务要用注解显式声明内网 LB：

# 阿里云：内网 CLB（VPC 内可达，公网不可达）
apiVersion: v1
kind: Service
metadata:
  name: internal-admin
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
spec:
  type: LoadBalancer
  ports:
    - port: 80

AWS EKS 对应注解：service.beta.kubernetes.io/aws-load-balancer-internal: "true"（NLB）或 aws-load-balancer-scheme: internal（ALB Controller）。

经验法则：

对外服务：公网 ALB/CLB + Ingress，前面最好再挂 WAF。
对内服务（管理后台、监控、Jenkins）：内网 LB 或纯 ClusterIP，配合 VPN/跳板机访问。
默认用 ClusterIP，需要出集群时再显式升级类型——把「暴露」当成一个需要评审的动作。
Ingress 上还可以用注解做来源 IP 白名单（如 nginx.ingress.kubernetes.io/whitelist-source-range: 10.0.0.0/8），给内部接口再加一道闸。

第三层：NetworkPolicy——集群内部的东西向隔离

即使流量不出集群，「测试 namespace 的 Pod 误连生产数据库」这类事故也常见。NetworkPolicy 是 Pod 级的防火墙（需要 CNI 支持，ACK 的 Terway、Calico 都支持，Flannel 不支持）：

# 第一步：namespace 默认全拒（白名单模式的起点）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: prod
spec:
  podSelector: {}          # 选中 namespace 内所有 Pod
  policyTypes: ["Ingress", "Egress"]
---
# 第二步：只放行需要的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-app
  namespace: prod
spec:
  podSelector:
    matchLabels: {app: order-svc}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: web-frontend}
      ports:
        - port: 8080

避坑点：

NetworkPolicy 是白名单累加模型：任何一条 policy 选中某 Pod，该 Pod 未被放行的方向就被默认拒绝。写漏了 DNS（Egress 到 kube-dns 的 53 端口）会导致全 namespace 解析失败——默认拒绝后记得显式放行 DNS。
策略只对选中后新建立的连接生效，且 Flannel 下写了也不生效（静默失效，最坑的一种）。
云安全组管的是「节点/LB 维度」，NetworkPolicy 管的是「Pod 维度」，两者互补不替代。
上了 Istio 的话，还可以用 AuthorizationPolicy 做带身份（mTLS 服务身份）的七层鉴权，比纯 IP/端口的 NetworkPolicy 更细。

六、Ingress：HTTP 流量的统一入口

Service 解决的是四层（TCP）负载均衡；Ingress 解决的是七层（HTTP/HTTPS）路由：按域名、按路径把外部流量分发到不同 Service。

graph TB
    User[外部用户] -->|HTTPS| LB[云负载均衡<br/>阿里云 ALB/CLB]
    LB --> IC[Ingress Controller<br/>Nginx / ALB Ingress]
    IC -->|"a.example.com/api/*"| S1[Service: api]
    IC -->|"a.example.com/web/*"| S2[Service: web]
    IC -->|"b.example.com/*"| S3[Service: admin]
    S1 --> P1[api Pod]
    S2 --> P2[web Pod]
    S3 --> P3[admin Pod]

注意分清两层：

Ingress 资源（YAML 对象）：只是路由规则的声明，本身不做任何事。
Ingress Controller（真正干活的组件）：如 ingress-nginx、阿里云 ALB Ingress Controller。它 watch Ingress 资源，把规则翻译成 Nginx 配置并热加载。

避坑点：

pathType: Prefix 和 Exact 的区别，/api 配 Prefix 会把 /apiserver 也匹配进去。
后端重写（rewrite-target）是最容易写错的注解，先想清楚「客户端路径 → 后端真实路径」的映射。
HTTPS 证书放在 Secret 里，过期忘续是经典事故——建议上 cert-manager 自动签发续期。
502 的第一排查动作：看 Ingress Controller 日志里 upstream 是「连接拒绝」（Pod 没 ready）还是「超时」（应用卡死）。

七、ConfigMap 与 Secret：配置和代码分离

十二要素应用的第一条就是「配置存环境」。K8s 里对应两个对象：

ConfigMap：普通配置（应用参数、配置文件、特性开关）
Secret：敏感配置（密码、密钥、证书），etcd 中 Base64 编码（注意：Base64 不是加密，生产环境要开 etcd 静态加密或对接 KMS）

两种注入方式：

# 方式一：环境变量
env:
  - name: DB_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: db_host

# 方式二：挂载为文件（推荐，支持热更新）
volumeMounts:
  - name: config
    mountPath: /etc/app
volumes:
  - name: config
    configMap:
      name: app-config

两个必踩的坑，提前告诉你：

环境变量注入的配置，改了 ConfigMap 不会生效，必须重启 Pod。文件挂载方式会自动更新（kubelet 定期同步，有分钟级延迟），但应用要支持 reload。
subPath 挂载的 ConfigMap 不会自动更新。这是用了 subPath 挂单个配置文件的同学必踩的坑——改完 ConfigMap 发现容器里还是旧的。解法：挂载整个目录，或接受重启 Pod 的事实。
ConfigMap 有 1MB 大小限制，别把大文件塞进去。

八、共享存储：PV / PVC / StorageClass

容器是临时的，数据要持久化就必须落到外部存储。K8s 的存储抽象分三层：

graph TB
    subgraph 管理员/云平台侧
        SC[StorageClass<br/>定义「用什么盘」<br/>如 alicloud-disk-essd / nas]
        PV[PersistentVolume<br/>一块真实的存储<br/>云盘/NAS 文件系统]
    end
    subgraph 应用侧
        PVC[PersistentVolumeClaim<br/>「我要 100Gi 存储」的申请单]
        Pod[Pod 挂载 PVC]
    end
    PVC -->|绑定| PV
    SC -->|动态供给：PVC 一创建<br/>自动开出对应 PV| PV
    Pod --> PVC

现代用法几乎全是动态供给：你只需要写 PVC 声明要多少空间，StorageClass 自动调用云厂商 API 创建云盘/NAS，不用手工建 PV。

三种访问模式（Access Modes）是高频考点：

模式	含义	典型存储
ReadWriteOnce (RWO)	只能挂到一个节点	云盘（阿里云 ESSD、AWS EBS）
ReadWriteMany (RWX)	多节点共享读写	文件存储（阿里云 NAS、AWS EFS）
ReadOnlyMany (ROX)	多节点只读	对象存储挂载、只读数据卷

共享存储的避坑清单：

云盘（RWO）不能跨可用区挂载。PV 创建在可用区 A，Pod 被调度到可用区 B 就永远 Pending。解法：用 WaitForFirstConsumer 模式的 StorageClass（等 Pod 定好节点再开盘），并用拓扑约束调度。
要多副本共享文件（如多个 Web Pod 共享上传目录），必须用 NAS/EFS 这类 RWX 存储，云盘做不到。
NAS 挂载注意权限问题：容器内进程 UID 和 NAS 目录属主不匹配会 Permission denied，用 securityContext.fsGroup 或挂载参数解决。
删除 PVC 会不会丢数据，取决于 PV 的 persistentVolumeReclaimPolicy（Retain 保留 / Delete 连盘一起删）。生产数据盘务必确认是 Retain。
StatefulSet 用 volumeClaimTemplates 给每个副本独立开盘，扩缩容时数据卷跟着 Pod 名字走，这是有状态服务的标准姿势。

九、Istio 服务网格：把「网络能力」从业务代码里剥出来

微服务多了之后，每个服务都要自己实现超时重试、熔断、灰度、流量监控——这些和业务无关。Istio 的思路：给每个 Pod 注入一个 Envoy 边车代理，接管所有进出流量，上述能力全部在代理层实现，业务代码零侵入。

graph TB
    subgraph 控制平面["Istio 控制平面（istiod）"]
        Pilot[配置下发<br/>流量规则]
        Citadel[证书管理<br/>mTLS]
    end
    subgraph 数据平面
        subgraph PodA["Pod A"]
            App1[业务容器] --- E1[Envoy 边车]
        end
        subgraph PodB["Pod B"]
            App2[业务容器] --- E2[Envoy 边车]
        end
    end
    Pilot -.->|xDS 配置下发| E1
    Pilot -.->|xDS 配置下发| E2
    E1 <-->|"mTLS 加密流量<br/>（应用无感知）"| E2

核心能力速览：

流量管理：VirtualService + DestinationRule 实现按权重灰度（v1 90% / v2 10%）、按 Header 路由、超时重试、熔断
安全：服务间自动 mTLS 加密 + 身份认证（AuthorizationPolicy）
可观测：不用改代码就拿到全链路指标、调用拓扑、访问日志
入口：Istio Gateway 替代/补充原生 Ingress，作为网格的南北向入口

避坑点（Istio 坑不少，挑最重要的）：

边车有成本：每个 Pod 多一份 Envoy 的 CPU/内存（默认 requests 约 100m/128Mi），上千 Pod 规模要算这笔账，必要时调小。
Sidecar 启动顺序：业务容器可能比 Envoy 先起来导致启动瞬间网络不通（现在 holdApplicationUntilProxyStarts 可解）；Job 类任务跑完 Envoy 不退导致 Job 永不结束，需要显式退出或关掉注入。
协议识别：Service 端口名要带协议前缀（name: http-xxx），否则 Istio 按 TCP 处理，七层能力全部失效。这是网格内路由不生效的第一嫌疑。
排障三板斧：istioctl analyze（静态检查配置）、istioctl proxy-config（看 Envoy 实际生效配置）、Envoy 的 :15000/stats 和 :15000/clusters。
新人别一上来就上全量 Istio。先在非核心 namespace 开注入练手，理解 VirtualService 再说。

十、云上落地：阿里云 ACK 为主，AWS EKS 对照

自己从零搭一套生产级 K8s（etcd 高可用、证书、网络插件）成本极高，生产环境几乎都用云厂商托管服务。

10.1 阿里云 ACK 关键点

graph TB
    subgraph 阿里云托管["ACK 托管层（免费/Pro）"]
        MA[控制平面：apiserver/etcd/scheduler<br/>阿里云托管，SLA 保障]
    end
    subgraph 你的账号["你的 VPC 内"]
        N1[ECS 节点池 1<br/>按量/抢占式]
        N2[ECS 节点池 2<br/>弹性伸缩 ESS]
    end
    MA --> N1
    MA --> N2
    N1 -.对接.-> CLB[CLB/ALB<br/>负载均衡]
    N1 -.对接.-> NAS[云盘 ESSD / NAS<br/>持久存储]
    N1 -.对接.-> SLS[SLS 日志 / ARMS 监控<br/>可观测]

实践经验：

网络插件选 Terway：Pod 直接用 VPC 弹性网卡 IP，无 overlay 开销、conntrack 压力小，还能配 NetworkPolicy；Flannel 适合小规模简单场景。Terway 模式下规划 VPC 网段要留够，每个 Pod 占一个真实 IP。
节点池 + 弹性伸缩：按业务波峰波谷自动扩缩节点；抢占式实例（Spot）跑无状态任务能省 70% 成本，但要容忍随时被回收。
Ingress 用 ALB Ingress Controller：比自建 Nginx Ingress 省心，ALB 本身按量弹性，且和 ACK 深度集成。
日志和监控开箱即用：日志服务 SLS（采集容器 stdout 和文件日志）、ARMS Prometheus 监控，别再自己搭 ELK 了。
镜像仓库 ACR：用 ACR EE（企业版）+ ACK 免密拉取插件，避免在 YAML 里配 imagePullSecret。
存储选 CNFS/云盘 ESSD（有状态单副本）+ NAS（共享文件）+ OSS（静态资源、备份） 的组合。

10.2 AWS EKS 速查对照

需求	阿里云 ACK	AWS EKS
网络插件	Terway（VPC 网卡直连）	aws-vpc-cni（同理）
七层入口	ALB Ingress	AWS Load Balancer Controller (ALB/NLB)
块存储	云盘 ESSD	EBS (gp3)
共享文件存储	NAS	EFS
日志	SLS	CloudWatch
监控	ARMS Prometheus	Managed Prometheus / Grafana
镜像仓库	ACR	ECR
无服务器节点	虚拟节点（ECI）	Fargate

概念完全互通，换云只是换 Controller 和注解。

十一、典型问题排查手册

11.1 通用排查流程

graph TD
    A[发现问题] --> B{Pod 状态？<br/>kubectl get pods}
    B -->|Pending| C[kubectl describe pod<br/>看 Events]
    C --> C1{原因}
    C1 -->|资源不足| C2[加节点/降 requests<br/>或开弹性伸缩]
    C1 -->|存储挂载失败| C3[检查 PVC 绑定/可用区]
    C1 -->|镜像拉取失败| C4[ImagePullBackOff：查镜像名/凭证/网络]
    B -->|CrashLoopBackOff| D[kubectl logs --previous<br/>看上一个容器的临终日志]
    D --> D1{原因}
    D1 -->|应用自身报错| D2[修代码/配置]
    D1 -->|Exit 137| D3[OOMKilled：调大 memory limit<br/>或查内存泄漏]
    D1 -->|Exit 143| D4[被优雅终止：查探针/滚动更新]
    B -->|Running 但访问异常| E[分层验证]
    E --> E1[1. 进 Pod 内 curl localhost 通吗？]
    E1 --> E2[2. curl Pod IP 通吗？]
    E2 --> E3[3. curl Service ClusterIP 通吗？<br/>查 Endpoints 是否有后端]
    E3 --> E4[4. Ingress 域名通吗？<br/>查 Controller 日志]

11.2 高频问题速查表

症状	最常见原因	第一动作
ImagePullBackOff	镜像名/tag 错、私有仓库无凭证、节点无公网	`describe pod` 看 Events 报错原文
CrashLoopBackOff	配置错、依赖没起来、探针误杀	`kubectl logs --previous`
OOMKilled (137)	内存 limit 太小或泄漏	看监控曲线，调 limit；Java 服务注意堆外内存
Pod 一直 Pending	资源不够、PVC 未绑定、污点/亲和性	`describe pod` 看调度失败原因
服务间偶发超时	conntrack 满、DNS 慢、TIME_WAIT 耗尽	`ss -s`、CoreDNS 日志、查连接池配置
滚动更新后 502	没配 readinessProbe / 没处理 SIGTERM 优雅退出	配探针 + preStop + 应用优雅关闭
ConfigMap 改了不生效	环境变量注入 / subPath 挂载	重启 Pod 或改为目录挂载
跨可用区挂载失败	云盘和节点不在同一 AZ	WaitForFirstConsumer + 拓扑约束

11.3 优雅退出：滚动更新不断流的完整姿势

Pod 被删除时的标准流程（很多人只知道一半）：

sequenceDiagram
    participant K as kubelet
    participant P as Pod
    participant EP as Endpoints

    K->>EP: 把 Pod 从 Service 摘除（不再接新流量）
    K->>P: 执行 preStop 钩子（如 sleep 5，等摘流量生效）
    K->>P: 发送 SIGTERM
    P->>P: 应用应：停止接新请求，处理完存量请求后退出
    Note over K,P: 超过 terminationGracePeriodSeconds（默认30s）
    K->>P: SIGKILL 强杀

三个缺一不可：readinessProbe 保证新 Pod ready 才切流量；preStop/优雅关闭保证老 Pod 处理完存量请求；terminationGracePeriodSeconds 给够时间。Java/Go 服务请确认框架注册了 SIGTERM 处理器（Spring Boot 的 server.shutdown=graceful、Go 的 signal.Notify）。

11.4 kubectl 排障速查

kubectl get pods -o wide -n <ns>          # 看状态和所在节点
kubectl describe pod <pod> -n <ns>        # 看 Events（排障第一步）
kubectl logs <pod> -c <container> --previous   # 崩溃前的日志
kubectl get endpoints <svc> -n <ns>       # Service 后面到底有没有 Pod
kubectl exec -it <pod> -- sh              # 进容器内验证网络
kubectl run debug --rm -it --image=busybox:1.36 -- sh   # 临时网络调试 Pod
kubectl top pod / kubectl top node        # 资源占用
kubectl get events --sort-by=.lastTimestamp -n <ns>     # 按时间看事件

十二、CI/CD：Jenkins 与 K8s 打通，实现自动化部署与验证

手工 kubectl apply 只适合学习。生产环境的标准做法是把「构建 → 推镜像 → 部署 → 验证 → 失败回滚」串成流水线，代码合并后自动完成发布。

12.1 整体流水线长什么样

graph LR
    Dev[开发者 git push] --> Hook[Webhook 触发 Jenkins]
    Hook --> Build[阶段1: 构建<br/>单测 + Docker 镜像]
    Build --> Push[阶段2: 推送镜像<br/>到 ACR/ECR<br/>tag = git commit]
    Push --> Deploy[阶段3: 部署<br/>kubectl set image<br/>更新 K8s]
    Deploy --> Verify[阶段4: 验证<br/>rollout status + 冒烟测试]
    Verify -->|成功| Done[发布完成<br/>钉钉/邮件通知]
    Verify -->|失败| RB[自动回滚<br/>rollout undo] --> Alarm[告警通知]

关键认知：K8s 侧不需要装任何 Jenkins 插件或 Agent 也能被部署——Jenkins 只要有目标集群的 kubeconfig（访问凭证），用 kubectl 就能驱动 apiserver 完成一切。打通的本质就两件事：凭证怎么管、流水线脚本怎么写。

12.2 Jenkins 的两种部署形态

形态	说明	适用
Jenkins 在集群外（独立服务器/另一集群）	通过 kubeconfig 远程操作业务集群	一套 Jenkins 管多个集群，最常见
Jenkins 跑在 K8s 集群内	配合 Kubernetes 插件，每次构建动态拉起一个 Pod 作为构建 agent，用完即销毁	构建任务多、想弹性利用集群资源

graph TB
    subgraph Jenkins侧["Jenkins（集群外或集群内）"]
        J[Jenkins Master]
        C1[凭据1: kubeconfig<br/>Secret file 类型]
        C2[凭据2: ACR 账号<br/>Username/Password 类型]
        J --> C1
        J --> C2
    end
    subgraph 阿里云["阿里云"]
        J -->|docker push| ACR[ACR 镜像仓库]
        J -->|"kubectl（走内网 API Server 端点）"| API[ACK apiserver]
        API --> Pod[滚动更新业务 Pod]
        Pod -->|免密拉取| ACR
    end

推荐做法：Jenkins 与 ACK 在同一 VPC 内，kubectl 直接走 API Server 的内网端点（安全且免公网流量）；镜像仓库用 ACR 企业版 + ACK 免密拉取，业务侧零凭证。

12.3 最小权限的部署凭证：别把 admin kubeconfig 给 Jenkins

这是 CI/CD 安全的第一课。给 Jenkins 一个只能操作特定 namespace、只能改 Deployment 的 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: prod
---
# Role 只在 prod namespace 内生效
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer
  namespace: prod
subjects:
  - kind: ServiceAccount
    name: jenkins-deployer
    namespace: prod
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

然后为这个 SA 生成 token，做成只含该 token 的 kubeconfig，存进 Jenkins 的 Secret file 凭据。好处：凭证泄露也只影响一个 namespace 的 Deployment，且可以随时 kubectl delete rolebinding 吊销。

12.4 完整 Jenkinsfile 示例

pipeline {
    agent any
    environment {
        IMAGE     = "registry.cn-hangzhou.aliyuncs.com/mycompany/order-svc"
        TAG       = "${env.GIT_COMMIT.take(8)}"   // 用 git commit 做 tag，可回滚可追溯
        KUBECONFIG = credentials('ack-prod-kubeconfig')   // Secret file 凭据
    }
    stages {
        stage('构建') {
            steps {
                sh 'mvn -q test'                       // 先跑单测，挂了直接终止
                sh "docker build -t ${IMAGE}:${TAG} ."
            }
        }
        stage('推送镜像') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'acr-account',
                    usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'echo $P | docker login registry.cn-hangzhou.aliyuncs.com -u $U --password-stdin'
                    sh "docker push ${IMAGE}:${TAG}"
                }
            }
        }
        stage('部署到 ACK') {
            steps {
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    set image deployment/order-svc order-svc=${IMAGE}:${TAG}"
            }
        }
        stage('验证') {
            steps {
                // 阻塞等待滚动更新完成；超时/失败会非零退出
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    rollout status deployment/order-svc --timeout=300s"
                // 冒烟测试：走内网 SLB 打健康检查和关键接口
                sh "curl -fsS --retry 5 --retry-delay 3 \
                    http://order-svc-internal.prod.svc.cluster.local/healthz || exit 1"
            }
        }
    }
    post {
        failure {
            // 部署验证失败自动回滚到上一个版本
            sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                rollout undo deployment/order-svc || true"
        }
    }
}

12.5 「验证」环节的正确姿势

很多流水线只做到 kubectl apply 就算「发布成功」，这是自欺欺人。apply 返回成功只代表 apiserver 收下了 YAML，Pod 起不起得来是另一回事。可靠的验证链：

rollout status 阻塞等待：确认所有新副本 ready（背后靠的就是 readinessProbe——再次体现探针的重要性）。
冒烟测试：对真实入口打 /healthz 和一两个核心业务接口，确认「能起来」且「能干活」。
失败自动回滚：rollout undo 依赖旧 ReplicaSet 还在（revisionHistoryLimit 别设 0）且镜像 tag 可追溯——这就是前面说「不要用 latest」的根本原因。
更严谨的做法是灰度验证：先用 Istio 把 5% 流量切到新版本观察指标，确认无误再全量（见第九章）。

12.6 CI/CD 避坑清单

镜像 tag 必须唯一可追溯：git commit 短哈希或构建号，杜绝 latest，否则回滚时根本不知道该回滚到哪个镜像。
凭据最小化 + 分环境：dev/staging/prod 用不同的 SA 和 Jenkins 凭据，prod 的部署动作加人工审批（Jenkins 的 input 步骤）。
声明式优先：服务变多后，把 kubectl set image 换成 Helm/Kustomize（YAML 也进 Git 仓库，可审计可 diff）；再进一步上 GitOps（ArgoCD/Flux）——Jenkins 只负责构建推镜像，部署由集群内的 ArgoCD 从 Git 仓库自动同步，Jenkins 不再需要生产集群的任何凭证，安全性大幅提升。
Jenkins 到集群的网络：kubectl 走内网 API Server 端点；如果 Jenkins 在另一个 VPC，用云企业网/对等连接打通，不要把 API Server 暴露公网给 Jenkins 用。
构建产物（镜像）与部署配置分离管理，避免「同一个 tag 被覆盖推送」导致回滚失效——ACR 里给 prod 仓库开镜像 tag 不可变（immutable）开关。

十三、学习路线建议

第一周：本地装 minikube 或 kind，把 Deployment/Service/ConfigMap 各玩一遍，亲手制造一次 CrashLoopBackOff 并修好它。
第二周：搞懂网络——Pod 网络、Service 转发（iptables）、Ingress、NetworkPolicy 内外网隔离，配合 tcpdump/ss 在容器里抓包看真实流量。
第三周：上云。开一套阿里云 ACK（按量付费，玩完就删），跑通「ACR 推镜像 → ACK 部署 → ALB Ingress 暴露 → NAS 挂共享盘 → SLS 看日志」全流程。
第四周：打通 CI/CD。用 Jenkins + 最小权限 SA 实现「推代码 → 自动构建 → 自动部署 → rollout 验证 → 失败回滚」完整流水线。
进阶：Helm 包管理、HPA 自动扩缩容、Istio 灰度发布、GitOps（ArgoCD）。

最后送一句《Kubernetes 权威指南》反复强调的心法：K8s 的一切都是声明式的——你描述「我要什么」，控制器负责「做到」。排查问题时永远先问：期望状态（YAML/Spec）是什么？实际状态（Status/Events）是什么？两者的差距就是答案所在。

参考资料：

《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）》龚正等

《Kubernetes in Action》Marko Lukša

《Unix 网络编程卷1》W. Richard Stevens（网络排障内功）

Kubernetes 官方文档

阿里云 ACK 文档