四级渐进学习法 · 部署与排障 · 第 9/9 篇

依赖决定顺序,清单决定成败。

这套系统十几个组件、两套命名空间、40+ 个 topic——部署不是点点按钮,是按依赖排的一次行军。本页把部署手册压成可操作的骨架:六步部署、七项验证、六个坑、一套日常运维,再给一个亲手排障的挑战场。

ns: audit-release / middleware-release 镜像 Secret: ctct-mssp 40+ topic 预建 cert-manager → helm flink
THE FRAMEWORK

先看地图,再出发THE FRAMEWORK — 把整条链路拉起来的人

前面八页讲了链路每一跳(Agent → envoy → gateway → Kafka → Flink → std topic → StarRocks)与两张防护网;本页讲怎么把它们一次拉起来:顺序为什么是这样、怎么验证成功、哪里最容易翻车。

L1

受控语言

三十一句确定性短句,分四组:部署六步、验证清单、六大坑、日常运维。

例:「helm -n 与 watchNamespaces 必须一致。」
L2

结构图

三张图:六步依赖 DAG(可点击)、端口速查表、排障决策树。

例:DAG 里 Envoy 依赖 gateway,gateway 依赖中间件。
L3

交互网页

排障挑战:六张症状卡,每张先选诊断命令、再选修复动作,两轮全对才算治好;六卡全通点亮「部署老中医」。加六题自测。

例:ImagePullBackOff,先查什么?
L4

定制视频

六镜头「行军」:读图、行军六步、验证关卡、六坑警示、日常养护、收尾。成片已交付 · 01:35。

例:一支片子讲完「按序拉起」。

本页名片(一分钟版)

主角:部署手册(六步 + 清单 + 坑)
一句话:依赖决定顺序,清单决定成败。
三个数字:6 步 · 7 项验证 · 6 个坑。
铁律:中间件先行、topic 预建、证书带着 SAN 一起签。

ctct-msspcert-manager 前置rollout undo

一句话主线(背下来,全页都在展开它)

ns+Secret → 中间件就绪 → agent+gateway → envoy(证书) → ETL 平台(ipdb→S3) → cert-manager+flink operator+作业 → 七项验证全过 → 上线

L1 CONTROLLED LANGUAGE

受控语言:三十一句讲清部署简短、确定、一词一义——不靠形容词,只靠事实

以下每句话都来自交接材料(部署手册)。读不懂的句子,去 L2 找对应的结构图。

部署六步

§ 1 · 12 句

验证清单

§ 2 · 7 句

六大坑

§ 3 · 6 句

日常运维

§ 4 · 6 句
L2 DIAGRAMS

结构图:行军的真实路线图 1 可点击六步 · 图 2 是天天要查的端口表

三张图:先看六步之间的依赖箭头(谁等谁),再备一张端口速查表,最后一张决策树把「症状 → 诊断 → 修复」走通。

① 命名空间 + 镜像 Secret ns ×2 · Secret: ctct-mssp ② 依赖中间件就绪 Nacos·MySQL·Redis·Kafka·MinIO ③ agent + gateway apply 三件套 · 注册 Nacos ④ Envoy 网关 证书五连 · 依赖 ③ ⑤ ETL 平台 30012 / 31212 · ipdb → S3 ⑥ Flink Operator → 作业 cert-manager → helm → 作业 依赖链:②中间件 ← ①地基 ;③业务 ← ② ;④网关 ← ③ ;⑤平台 ← ② ;⑥Flink ← ①⑤ 验证七项全过(Pod Running · Nacos 注册 · endpoints ×3 · 3 healthy · 0 (ok) · PASS · 入口可达)才算部署完成
图 1 · 部署六步依赖 DAG(点击步骤查看明细与坑点)
点击图中的六步,这里显示它的顺序、依赖与坑点。
入口NodePort容器端口 / 协议说明
Nacos 控制台30002— / HTTP服务注册与配置中心
Flink Dashboard300048081 / HTTPETL 作业观测(内部 REST flink-etl-rest:8081)
dbeaver30005— / HTTP数据库管理
MinIO Console30008— / HTTPS3 控制台(bucket audit-etl)
kafka-ui30009— / HTTPKafka 管理(看 40+ topic)
data-platform 后端3001280 / HTTPETL 平台 API
ETL 控制台30013— / HTTPETL 平台入口
envoy(正式入口)300158285 / gRPC+mTLSAgent 上报唯一正式通道
envoy(调试)300168286 / gRPC 明文无需证书,仅调试
envoy(HTTP)300178080 / HTTP+mTLSHTTP 接口
audit-agent3001880 / HTTP采集/接收前端
data-platform-fe3121280 / HTTPETL 前端(Nginx 反代后端)
图 2 · 端口速查表(照抄部署手册,天天要查)
症状(看到什么) 诊断(查什么命令) 修复(做什么动作) 例:envoy 上游 0 个 healthy(Endpoints 空) 查:kubectl get endpoints audit-gateway-headless+ envoy Admin :9901/clusters 修:上游改 headless :8285(multi 是坑)+ 核对 selector 与 Pod 标签 顺序错了越修越乱: 先确认症状,再跑命令, 最后才动手修。
图 3 · 排障三段式:症状 → 诊断命令 → 修复动作
L3 INTERACTIVE

交互探索:排障挑战六张症状卡 · 两轮判定 · 全通点亮「部署老中医」

每张卡是一个真实坑的现场:先从三个命令里选出正确的诊断动作,再从三个修复里选出对症的动作——两轮全对才算治好。选错会告诉你为什么错。

3a · 排障挑战

6 症状 · 诊断 + 修复两轮

✦ 部署老中医:六坑全平 ✦

3b · 概念自测

6 题 · 单选

已答 0 / 6 · 正确 0 · 正确率 0%

1. 部署的第一步是?

地基先行:audit-release / middleware-release 两个 ns + 镜像拉取 Secret。部分 YAML 里写 ctyun-registry,要统一改名。

2. 镜像拉取失败的常见原因是?

坑 2:部分 YAML 写的是 ctyun-registry,统一改成 ctct-mssp;实在拉不到就去节点机 docker save/load 取现成镜像。

3. 验证 headless 上游的正确命令是?

endpoints 是 headless 的命脉:3 个 Pod IP:8285 一个不能少;再用 envoy Admin :9901/clusters 确认 3 个上游 healthy。

4. envoy 上游健康状态在哪里看?

健康检查是 envoy 做的,结果当然在 envoy 的 Admin 页看——部署验证清单里 3 个上游全 healthy 是硬性关卡。

5. 证书轮换后必须做的事?

坑 6:换服务端证书后 Agent 手里的 client 证书与新链路不配套就握手失败——两侧都要动:envoy 重启 + 全部 Agent 重启。

6. 关于 Kafka topic,部署时必须?

坑 4:topic 不自动建,漏一个链路数据就无处落——部署手册明确要求 40+ 全部提前创建。
L4 VIDEO

定制视频:行军六镜头 · 成片已交付 · 01:35· 分镜与解说骨架已备

六镜头讲完「按序拉起」:读图出发、六步行军、七道关卡、六坑警示、日常养护、收尾。画面里的命令与顺序与 L1–L3 同源。

成片 · topic-09-deploy.mp4 ✓ 已交付

00:00 开场 · 读图出发 00:15 六步 · 依赖定序 00:32 七灯 · 清单制验收 00:48 六坑 · 前车之鉴 01:04 养护 · 永远有退路 01:19 收尾 · 灯全绿

规格:1920×1080 · 30fps · 01:35 · H.264 + AAC · 中文配音(zh-CN-Yunxi 逐句合成,每句实测时长均落在自己的字幕窗口内)+ 画面内嵌字幕。底部常驻进度轨随镜头推进点亮。

分镜脚本

6 镜头 · 旁白即片中字幕

镜头 1 · 读图出发

画面:DAG 地图铺开,六面小旗依次标注,指挥官手指地基节点。
旁白:部署是一场行军。地图上画着谁等谁——看懂箭头的人,才配敲回车。

镜头 2 · 六步行军

画面:六支小队按序开拔:地基、中间件、业务、网关、平台、Flink。
旁白:地基先动,中间件先活,业务才能注册,网关才有得转发,规则才有得算。顺序不是习惯,是依赖。

镜头 3 · 七道关卡

画面:七盏验证灯逐个亮起:Pod Running、Nacos 注册、endpoints ×3、3 healthy、0 (ok)、PASS、入口可达。
旁白:行军终点不是 apply 完,是七盏灯全绿。少一盏,都叫没到。

镜头 4 · 六坑警示

画面:地图上闪过六个红色陷阱标记:multi、Secret 名、watchNamespaces、topic、ipdb、SAN。
旁白:这条路上埋着六个坑,每一个都真实炸过。手册把它们写下来,就是为了让你不踩第二遍。

镜头 5 · 日常养护

画面:set image、rollout status、rollout undo 三条命令如检修流程滚动;证书轮换四步走完。
旁白:上线只是开始。滚动升级看着走,出事一条命令退回去——运维的底气,是永远有退路。

镜头 6 · 收尾:灯全绿

画面:全链路七跳 + 防护网整幅亮起,七盏验证灯排成一排定格式收尾。
旁白:按序拉起、逐项验证、踩坑有册、回退有路。这,就是部署的全部修养。

解说骨架:六个设计决定

镜头 2–5 的旁白依据

① 依赖定序

谁等谁是 DAG 画好的,不靠记忆靠结构。

② 清单制验收

七盏灯全绿才算完成,标准不靠感觉。

③ 坑册传承

六个坑白纸黑字,新人不再交学费。

④ 中间件先行

Kafka topic、S3、Nacos 就位,业务才有处落。

⑤ 证书成套

SAN、Secret、重启、重发——证书轮换是链不是点。

⑥ 永远有退路

set image / status / undo 三件套,进退有序。