Istio 模块化 Helm Charts 深度解析manifests/charts 源码结构、a-la-carte 设计理念与安装机制【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio这篇技术指南聚焦 manifests/charts 目录——Istio 官方 Helm chart 的源码仓库。文章将讲清该目录与安装 Istio的关系与边界、模块化a-la-carte安装器的设计目标渐进升级、多环境灵活性与安全隔离、各组件 Chart 的实际结构以及修改与发布这些 Chart 时必须遵守的开发规范。读完你可以明确要用 Istio 该去哪里拿 Chart要改 Istio 的 Chart 与 values 应该动哪些文件、走哪些步骤并理解当前base / istiod / ztunnel / gateway / istio-cni等 Chart 家族是如何组织协作的。一、先认清目录定位这是 Chart 源码仓库不是安装脚本原文档在开头就给出了一条醒目的警示manifests/charts/README.md 首段不要使用此目录中的文件来安装 Istio。这句话初看反直觉但恰恰点明了该目录的本质manifests/charts下存放的是Helm chart 的源文件_sources它们会随每次 Istio 发布被版本化、构建并推送到公开的 Helm 仓库。官方发布链路由独立的istio/release-builder负责会把这些 Chart 以两种形式对外分发HTTP Chart 仓库形式承载官方发布版本OCI Registry 形式oci://同时承载官方发布版本与 dev 构建版本。因此普通用户若要通过 Helm 安装 Istio应当使用上述仓库中已发布、带版本号的 Chart即各子 Chart README 中展示的helm install istio-base istio/base之类用法而不是直接apply本目录里的模板文件。而对于想要修改 Istio Helm Chart 的开发者这个目录正是正确的工作场所。文档特别强调凡是改动本目录下的 Chart 或values.yaml必须先阅读 UPDATING-CHARTS.md它规定了可接受的 PR 类型、修改步骤与 value 弃用策略详见本文第八节。二、模块化安装器从单体模板到 a-la-carte 的重构该目录下的 Chart 体系源自 Istio 早期 Helm 模板的一个 fork其重构目标被概括为三点manifests/charts/README.md设计目标含义与收益改善升级体验支持组件渐进式滚动升级新版本部署时可保留稳定版本在位应用逐步迁移到新版本从而具备对 Istio 组件的 canary金丝雀部署能力更灵活允许存在多个“环境environment”应用可以选择不同的控制平面设置与组件组合。整个网格仍遵守同一套 Istio API 与配置但不同应用可指向包含不同实例与变体的“环境”更安全各 Istio 组件被隔离到不同命名空间便于不同团队或角色分别管理 Istio 的不同部分。例如安全团队只维护根 CA 与策略可观测性团队只接触 Prometheus而控制平面组件安全敏感度最高由专门团队维护也就是说这套安装器强调组件化、显式声明它拆分的步骤比传统单体安装更多但每一步更小、更聚焦于单一功能且可以由不同团队在各自的时间点独立执行manifests/charts/README.md。该文档把目标用户明确描述为在生产环境运行 Istio、希望对每个被部署的二进制进行选择、调优与深入理解并决定组合方式的用户。原文档同时提醒了几条历史约束阅读时需结合其编写背景各新组件可与运行在istio-system中的早期 Istio文档中具体指 1.0/1.1安装并行存在新旧组件互不干扰且可互操作从而支持从旧版本向新“环境”以及跨“环境”如 canary → prod渐进迁移文档承认当时仍存在少量 ClusterRole 权限归属待收敛的问题并预期集群级权限最终会迁移到 security 组件中。三、“环境Environment”抽象与注入选择机制围绕“多环境”思想早期文档定义了一套环境选择机制manifests/charts/README.md通过istioctl kube-inject或自动 Sidecar 注入器来选择环境在自动注入场景下命名空间标签使用istio-env: NAME_OF_ENV而非传统的istio-injected: true环境名称被定义为对应控制平面组件config、discovery、auto-injection所运行的命名空间例如istio-control也可通过 Pod 注解选择不同的“环境”。需要说明的是这一节描述的是该文档所对应早期模块化安装器以iop命令与istio-env标签为特征的环境编排方式。从当前仓库的实际 Chart 源码看这套“多套并存、可金丝雀升级”的需求已演进为以revision修订版本为核心实现例如 istio-control/istio-discovery 的模板中可以看到revision-tags-mwc.yamlrevision tag 的 MutatingWebhookConfiguration、revision-tags-svc.yaml等资源而 istiod Chart 的 README 明确说明控制平面 revision 允许在同一集群中部署多个版本的控制平面以实现安全的 canary 升级配置方式为在 values 中设置revision: my-revision-name。也就是说当前 Chart 家族通过 revision/revision-tag 完成了文档中“多环境并行 渐进迁移”的设计意图这一点在阅读时值得对照理解。四、Chart 家族全景从 CRD 到 ztunnelmanifests/charts当前包含七类 Chart 源码另有 install-OpenShift.md 与 UPDATING-CHARTS.md 两份说明文档Chart 目录组件性质核心资源templates 佐证base所有 revision 共享的集群资源CRDscrd-all.gen.yaml→templates/crds.yaml、defaultRevision 校验 Webhook、reader ServiceAccount 与 RBACistio-control/istio-discoveryistiodPilot/discovery控制平面Deployment、Service、autoscale、PDB、网络策略、注入模板injection-template.yaml、gateway-injection-template.yaml、Mutating/Validating Webhook、revision-tag 相关资源、远端 istiod EndpointSlice/Servicegateways/istio-ingress 与 gateways/istio-egress南北向入口/出口网关Deployment含injected-deployment.yaml注入形态、Service、autoscale、PDB、RBAC、网络策略gateway新一代网关 Chart含values.schema.json支持值的 JSON Schema 校验Deployment、Service 等模板istio-cniIstio CNI 插件DaemonSet 形态、单例、安全敏感CNI 配置安装逻辑与配套 RBACztunnelambient mesh 数据平面组件 ztunneltemplates/daemonset.yaml、rbac.yaml、networkpolicy.yaml、resourcequota.yaml、serviceaccount.yamldefault默认注入/校验 Webhook 配置mutatingwebhook.yaml、validatingwebhook.yamlbase一切 revision 的公共底座base/README.md 将该 Chart 描述为“安装所有 Istio revision 共享资源的 Chart包括 Istio CRDs”。官方安装方式为在配置好官方 chart 仓库后kubectl create namespace istio-system helm install istio-base istio/base -n istio-system值得注意的 CRD 管理设计Helm v3 本身不支持升级 CRD因为它无法保证全场景安全升级而 Istio 项目自己承诺了向后兼容保证因此 base 默认把 CRD 作为普通 Kubernetes 资源自管enableCRDTemplates: true从而能在后续安装中安全地升级 CRDbase/values.yaml。同时支持按需排除某些 CRDbase: # 需要将 enableCRDTemplates 置为 true 才能生效 excludedCRDs: [envoyfilters.networking.istio.io] enableCRDTemplates: true # istioctl 安装且关闭配置类 CRD 时使用 enableIstioConfigCRDs: truevalues 中还透出global.istioNamespace默认istio-system用于定位 istiod、resourceScopeall/cluster/namespace用于集群管理员与网格管理员分权以及enableReaderRBAC仅为多集群 remote-secret 工作流创建 reader ServiceAccount等关键项base/values.yaml。istiod控制平面istio-discovery 的 README 给出的安装前提是“集群中必须先由 istio/base 安装好 CRDs”kubectl create namespace istio-system helm install istiod istio/istiod --namespace istio-system该 README 还示范了通过 values 直接透传任意 MeshConfig 选项例如开启访问日志meshConfig: accessLogFile: /dev/stdout以及通过 revision 支持 canary 升级见第三节。卸载只需helm delete istiod --namespace istio-system。istio-cni可选但安全敏感原文档强调 CNI必须运行在专用命名空间、是单例singleton且极度安全敏感对该命名空间的访问必须严格受限manifests/charts/README.md。当前 istio-cni/values.yaml 中的平台相关参数提供了更细的控制面hub: tag: image: install-cni # CNI 与平台相关的路径默认值不同平台如 GKE需按 manifests/helm-profiles/ 下的 # platform-*.yaml 覆盖调整 cniBinDir: /opt/cni/bin # GKE 上通常需要 /home/kubernetes/bin cniConfDir: /etc/cni/net.d cniConfFileName: # 默认取 cni-conf-dir 下第一个发现的 conflist istioOwnedCNIConfig: false # 置 true 时默认管理 02-istio-cni.conflist # 默认排除的命名空间 excludeNamespaces: - kube-system原文档中针对 GKE 的安装片段当时以iop命令演示即为给cniBinDir注入 GKE 专用路径ISTIO_CNI_ARGS if [[ ${ISTIO_CLUSTER_ISGKE} true ]]; then ISTIO_CNI_ARGS--set cni.cniBinDir/home/kubernetes/bin fi这解释了为什么如今manifests/helm-profiles/例如 platform-gke.yaml会集中维护各平台对这些路径值的覆盖。网关、ztunnel 与 ambientGateways一个集群可以运行多个网关各自拥有不同的负载均衡 IP、域名与证书由于域名证书存放在网关命名空间文档建议每个网关使用独立命名空间并限制访问。对于大规模网关还可选在网关命名空间部署专用 istiodmanifests/charts/README.md。ztunnelztunnel/README.md 提供了最简安装helm install ztunnel istio/ztunnel其模板围绕 DaemonSet 组织ztunnel/templates 下的daemonset.yaml、resourcequota.yaml等。default承载注入/校验 Webhook 的默认配置与 base 配合使用。五、Everything is Optional按需组装与渐进迁移哲学文档用专门一节阐述了“一切皆可选”的设计原则manifests/charts/README.md新安装器中的每个组件都是可选的你可以安装本安装器定义的组件也可以使用官方安装器配置在istio-system中的等价组件甚至替换为不同版本或完全不同的实现例如使用自建的 Prometheus/Grafana、专用的证书签发工具或使用集中管理、运行在其它集群中的组件作为极端目标作者期望在不向某集群安装任何 Istio 组件的情况下也能运行 Istio workload——文档指出当时的最低要求是安全提供方node agent 或 citadel即后续演进为 istiod 内置的 CA 与安全组件。这意味着这套架构把“替换与组合的自由度”视为一等公民用户可以根据组织边界哪些团队管 CA、哪些团队管遥测、哪些团队管控制平面自由裁剪安装面。六、安装实战原文档命令与当前 Chart 用法的对应原文档给出了一份“小而专”的分步安装序列manifests/charts/README.md其顺序与依赖关系在今天依然成立第 1 步安装 CRDs最优先文档强调不得删除或编辑任何 CRD——当前配置要求所有 CRD 必须齐备每次升级都建议重新应用清单以确保获得全部 CRD。CRD 在 base 中按 release 与组件类型组织见 base/files/crd-all.gen.yaml。由于 Istio 与 cert-manager 集成较深部分运维者希望保留既有 cert-manager CRD 不被 Istio 改动此时就需按需单独应用个别 CRD 文件。原文档给出的两条等价命令kubectl apply -k …/base或直接kubectl apply -f base/files对应到今天即helm install istio-base istio/base -n istio-systembase Chart 已把 CRD 作为常规资源管理见 base/values.yaml 的enableCRDTemplates。第 2 步可选安装 istio-cniCNI 单例、安全敏感、须专用命名空间且可后续再安装并渐进迁移存量应用。第 3 步安装控制平面网格至少应有一个集群运行 Pilot或等价 XDS Server多集群场景下建议每个 region、多个可用区都运行 Pilot。原文档演示了“一稳定版 一 master 版并存”的多环境部署iop istio-control istio-discovery $IBASE/istio-control/istio-discovery \ --set global.istioNamespaceistio-system # 第二个 istio-discovery使用 master 版 istio TAGlatest HUBregistry.istio.io/testing iop istio-master istio-discovery-master $IBASE/istio-control/istio-discovery \ --set policy.enablefalse \ --set global.istioNamespaceistio-master说明示例中的iop是该 README 编写时期对应旧式安装器IstioOperator v1alpha1的命令入口。在当前仓库中同一套 istiod Chart 的官方安装入口已收敛为helm install istiod istio/istiod参见 istiod README多版本并存则交由revision实现。$IBASE指代 charts 源目录根此处代码块仅用于复现原文档语义、便于读者对照 Chart 目录路径理解安装对象。第 4 步按需网关按域名/证书/负载均衡 IP 拆分多个网关独立命名空间、限制访问大规模网关可配专用 istiod。第 5 步附加测试模板一批通用的 Helm test 资源可用于任何集群以验证 Istio 工作正常、并针对特定安装做冒烟测试。七、Profile 机制与 values 组织结构源码佐证每个 Chart 的files/目录下都沉淀了一套名为profile-*.yaml的预设文件例如 base/files 中的profile-demo.yaml、profile-preview.yaml、profile-ambient.yaml、profile-platform-gke.yaml、profile-compatibility-version-*.yaml等istio-control/istio-discovery/files 与 ztunnel/files、gateways 亦然模板目录下还有汇总用的zzz_profile.yaml。各 Chart README 对 profile 的使用规则描述一致见 base/README.mdprofile 是可批量套用的 value 预设通过--set profileprofile选择例如demoprofile 面向测试环境开启更多特性并降低资源要求为保持一致同一组 profile 在所有 Chart 上通用即使某个 profile 不影响某个 Chart优先级显式设置的值 profile 设置 Chart 默认值实现细节上Chart 的默认值整体嵌套在defaults之下但用户配置时不要写defaults.前缀——即应写--set some.fieldtrue而非--set defaults.some.fieldtrue。对应地Chart 级默认值文件如 base/values.yaml顶部存在一个_internal_defaults_do_not_set“内部默认值请勿设置”的 workaround 键它正是上述defaults嵌套的实现载体——用户应直接设置其内部字段而不要把该前缀写进--set。base中同时还维护着defaultRevision、experimental.stableValidationPolicy等面向安装行为的默认项base/values.yaml。八、如何正确地修改 ChartUPDATING-CHARTS 规范精读由于values.yaml本质上是“面向用户的复杂 API”UPDATING-CHARTS.md 为所有变更设置了严格门槛其核心立场是尽量克制对values.yamlAPI 的扩张——若所有 Kubernetes 字段都暴露到 values最终会得到一个比直接用 Kubernetes API 还难用、且无比庞大的 API。可接受改动PR 准则Helm 只负责安装期配置若属运行时动态配置应进入 MeshConfig API对应仓库外的istio/api的mesh/v1alpha1/config.proto避免重装或重启一般不鼓励新增global值仅在跨至少 2 个 Chart 被频繁且一致消费如镜像 tag、公共标签这类严格逐案评估下才可能被接受若改动的是 Kubernetes 字段也不代表 PR 必然被接受——values.yaml保持“最小核心配置集”定制化场景应走 Helm Chart Customization 等进阶机制倾向暴露整体字段而非单个子键例如与其逐个暴露 affinity 的复杂子字段不如提供一个整体affinity字段原样透传给 Kubernetes 资源以最小 API 面获得最大灵活性所有 value 的增删都面向用户必须附带 release note避免在多个 Chart 间重复同样的模板逻辑或复杂条件应抽公共 Helm 模板保持一致。修改的标准五步流程先在manifests目录下改 Chart 与values.yaml并在values.yaml中提供充分文档与示例若 Chart 带values.schema.json如 gateway 即有此文件需同步更新除gatewayChart 外其余 Chart 都会被istioctl用于生成安装 manifest因此需同步更新 manifests/profiles/default.yaml更新 istioctl 的类型检查 schemaoperator/pkg/apis/values_types.proto然后执行make operator-proto重新生成校验用 Go 结构体执行make copy-templates update-golden重新生成 golden manifestsistioctl 测试依赖它们来保证二进制内 Chart 版本正确基于上述步骤产物提交 PR。Value 弃用规则被标记为 deprecated 的 value最短 2 个 release 之后才允许移除标记弃用的 PR 必须附 release note 说明被弃用值及替代方案移除已弃用值的 PR其 release note 必须同时填写releaseNote与upgradeNote两个字段release note 相关约定见 releasenotes/README.md。九、安全与多租户部署建议综合文档与 Chart 结构生产环境按模块化方式部署时可遵循以下准则命名空间与服务账号隔离强烈建议各组件使用不同命名空间、不同 ServiceAccount尤其对安全关键的生产组件根 CA、策略、控制平面的访问必须锁死、最小授权manifests/charts/README.md角色分权借助多实例部署让测试/预发环境的新配置与新版本由不同于生产环境的角色去验证实现“生产只读、变更可控”CNI 与网关单独管控CNI 使用独立高危命名空间、网关按证书域拆分并限制命名空间访问多可用区冗余多集群/多区域部署时让 Pilot 在每个 region 的多个可用区运行提升控制面可用性manifests/charts/README.md。十、小结manifests/charts是 Istio 官方 Helm Chart 的单一事实来源base提供 CRD 与公共集群资源istio-control/istio-discoveryistiod提供控制平面gateways/gateway提供南北向流量入口ztunnel提供 ambient 数据平面istio-cni与default分别承担 CNI 与 Webhook 配置。理解该目录需要同时把握三点其一普通安装应使用已发布的 Helm Chart 而非直接取用源码其二目录背后的 a-la-carte 理念追求组件化、多环境并行、可渐进升级与跨团队职责隔离其三任何对 Chart/values 的修改都受 UPDATING-CHARTS.md 的强约束——克制 API 扩张、保持最小核心配置、配套 schema 与 release note并通过 golden 测试保证istioctl与 Chart 源码的一致性。把握住这三点无论是作为 Istio 的生产运维者挑选组件还是作为开发者向 Istio 贡献 Chart 改动都能快速定位到正确的文件与流程。【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考