Day 19 / 共 20 天 · 第 4 周 遥测/扩展/安装

Operator 与安装

istioctl install 怎么把 Istio 装进集群？今天看安装机制：新版纯 render 模型（客户端渲染 Helm + server-side apply）、IstioOperator 配置、组件依赖图。前 18 天讲的都是"Istio 跑起来之后怎么工作"，今天回到最开头——它当初是怎么被装进集群的。

📍 你在整门课的位置 · 第 4 周「遥测 / 扩展 / 安装」（W1-3 全部 ✓）
D16 遥测→ D17 EnvoyFilter→ D18 istioctl→ D19 安装→ D20 收官
L01

新版 render 模型

🤔 痛点：装个 Istio 要手调几百个参数？ Istio 有 istiod、网关、CNI、一堆 CRD 和 RBAC，参数成百上千。如果让你手写全部 K8s YAML 再 apply，既容易漏、又难保证组件按正确顺序装上、还难升级。怎么把"装一个合理的 Istio"变成可复制的一步操作？
💡 本质：像宜家家具——给你图纸+套餐，按序组装 安装 Istio 好比装宜家家具：profile 是"预选套餐"（简约款/豪华款/毛坯款），Helm chart 是"图纸"，istioctl install 是那个照图纸把零件拼起来的人。新版是"自己照图纸装"（客户端 render 模型）——不再像旧版"请个常驻管家(controller)住你家帮你装"。而且组装讲顺序：先打地基(Base/CRD)、再立柱子(istiod)、最后挂门窗(网关)。今天就看这套组装逻辑。
重要：新版 operator 已无集群内 controller：本版本是纯 render 模型——istioctl install 在客户端渲染 Helm chart 并 server-side apply，不再有集群内 operator controller、不再有 IstioOperator CRD。（老教程/博客可能还讲"装个 operator 监听 CRD"，那是旧模型。）
"render 模型" vs 旧"controller 模型" 旧模型：集群里跑一个 operator controller，watch IstioOperator CRD，据此在集群内 reconcile 出 Istio 组件。新模型更简单：istioctl install 直接在你的电脑上（客户端）把 Helm chart 渲染成 K8s 清单，然后 apply 到集群——没有常驻 controller。好处：更简单、更可预测、少一个要维护的组件。operator/ 目录是纯上游 Istio（无 Higress 定制）——Higress 的定制在 pilot/proxy 层。
L02

IstioOperator

// operator/pkg/apis/types.go:65 IstioOperatorSpec
//   Profile / Hub / Tag / Namespace / Revision / MeshConfig / Components / Values
// :217 BoolValue（三态）：GetValueOrTrue（:241 默认启用语义）
读法：IstioOperator 是安装配置（虽然不再是集群内 CRD，仍是配置格式）：选哪个 profile、镜像仓库（Hub/Tag）、启用哪些组件、MeshConfig 覆盖。三态 BoolValue（true/false/未设）让"未设"能表达"用默认"（GetValueOrTrue）。
L03

组件表

// operator/pkg/component/component.go:142 AllComponents：
//   Base（base chart，CRD+集群资源）
//   Pilot（istio-control/istio-discovery，产出 istiod Deployment）
//   IngressGateways / EgressGateways（默认关）
//   Cni（默认关）/ Ztunnel（ambient）
读法：Istio 由这几个组件组成，每个对应一个 Helm chart。Base（CRD 等基础）+ Pilot（istiod，核心）是必装；网关、CNI、ztunnel 按需。安装就是渲染这些组件的 chart。
L04

GenerateManifest

// operator/pkg/render/manifest.go:44 GenerateManifest
//   MergeInputs（合并配置）→ 校验 → 遍历 AllComponents 逐个 helm.Render → postProcess
// operator/cmd/mesh/install.go:141 Install → GenerateManifest（:161）→ InstallManifests（:192）
读法：安装核心：GenerateManifest 把 IstioOperator 配置 + --set 合并，逐组件用 Helm 渲染成 K8s YAML，后处理（应用 k8s.* patch）。InstallManifests 再 server-side apply 到集群。istioctl manifest generate 只渲染不 apply（供审查）。
L05

输入优先级

# manifest.go:249 MergeInputs 优先级（后者胜）：
内置默认 < profile < 集群探测 < -f 文件 < --set
# translateIstioOperatorToHelm：spec.hub→global.hub、spec.meshConfig→meshConfig …
又是"分层覆盖"（配置系统的通用模式） 安装配置来自多处：内置默认、选的 profile、集群探测结果、你的 -f 文件、命令行 --set。优先级从低到高——越"具体、越靠近命令行"的越优先。这和 Envoy 的模板路径优先级（Day 13）、OpenClaw 的 env 链、Istio 自己的 exportTo 层级都是同一个思想：提供合理默认，允许逐层覆盖。translateIstioOperatorToHelm 把 IstioOperator 字段翻译成 Helm values（因为底层是 Helm chart）。
📝 举个例子：同一个值被层层覆盖 副本数 pilot.replicaCount：内置默认 1 → 选了 demo profile 设成 1 → 你 -f myvalues.yaml 写 2 → 命令行又 --set pilot.replicaCount=3 → 最终生效 3。谁离命令行近谁赢：内置 < profile < 集群探测 < -f 文件 < --set。
L06

profile 三层

manifests/zzz_profile.yaml 用巧妙技巧实现"默认 < profile < 用户输入"三层合并：把内置默认藏在 .Values._internal_defaults_do_not_set，运行时读 files/profile-<name>.yaml，mustMergeOverwrite $defaults $profile，再 merge 用户 Values。

profile = "预设的安装套餐" Istio 有多个 profile（安装套餐）：default（生产）、demo（全功能演示）、minimal（最小）、ambient（无 sidecar 模式）等。profile 就是"一组预调好的配置默认值"——选 demo 就自动开启全套遥测/追踪，选 minimal 就只装核心。你在 profile 基础上再用 --set 微调。这让"装一个合理的 Istio"变成一行命令（istioctl install --set profile=demo），不用手调几百个参数。两套 profile 别混：operator 级（IstioOperator 形态）和 chart 级（纯 Helm values）。
L07

依赖图安装

// operator/pkg/install/install.go:106 install()：按依赖图并发 apply
//   componentDependencies（:293）：Base→Pilot；Pilot→{Cni,Ingress,Egress}；Cni→Ztunnel
//   serverSideApply（FieldManager:"istio-operator"）→ prune（按 owner label 清孤儿）
为什么安装要讲依赖顺序？ 组件之间有依赖：Base（含 CRD）必须先装——否则后面的组件引用的 CRD 还不存在；Pilot（istiod）要在网关之前——网关连 istiod 拿配置。所以按依赖图有序安装：Base → Pilot → 网关/CNI → Ztunnel。同层可并发。安装完还 prune——按 owner label 删除"上次装了但这次没有"的孤儿资源（比如你从 demo 切到 minimal，多余的组件被清理）。这保证集群状态和你的配置一致。
BaseCRD+基础(先) Pilot(istiod)核心 IngressGateway Cni EgressGateway Ztunnel 按依赖图有序 apply，同层可并发；装完 prune 清孤儿
组件依赖图：Base(地基)→Pilot(柱子)→网关/CNI(门窗)→Ztunnel。就像装家具，顺序错了后面装不上。
⚠️ 常见误解：网上老教程常说"先在集群里装个 Istio operator，它 watch IstioOperator CRD 自动 reconcile"。那是旧的 controller 模型，本版本已废弃——现在是纯客户端 render：istioctl install 本地渲染完直接 apply，集群里没有常驻 operator 进程。
L08

今日小结 + 动手

🧠 今天你应该能回答

  • 新版 render 模型 vs 旧 controller 模型的区别？
  • IstioOperator 配置什么？三态 BoolValue 的意义？
  • Istio 由哪几个组件组成？
  • GenerateManifest → Install 的流程？输入优先级？
  • profile 是什么？为什么安装要讲依赖顺序？

✋ 动手

cd /Users/bitmart/work/codes/github/higress-group/istio
grep -n 'func GenerateManifest\|func MergeInputs' operator/pkg/render/manifest.go
grep -n 'AllComponents\|componentDependencies' operator/pkg/component/component.go operator/pkg/install/install.go
ls manifests/profiles/
明天预告 · Day 20（结业）：收官串讲——Istio 全景回顾、控制面/数据面完整闭环，以及它和 Higress 的关系（xDS-over-MCP、pkg/ali 定制），承上启下引出下一站 Higress。
← Day 18 istioctl Day 20 · 收官串讲 →