【Istio 控制面】Sidecar、Telemetry、EnvoyFilter：三种「改配置」机制与各自的合并脚枪
内容提要
本文介绍Istio中Sidecar、Telemetry、EnvoyFilter三种资源在配置生成流水线中的作用：Sidecar在生成前裁剪可见输入，Telemetry在生成中注入可观测配置，EnvoyFilter在生成后直接打补丁。三者各有合并规则，不能简单套用“更具体覆盖更宽泛”的直觉。重点强调Sidecar裁剪不等于流量阻断、Telemetry禁用继承不对称、EnvoyFilter按创建时间排序而非修改时间等易错点。
延伸解读
Sidecar 裁剪 ≠ 流量阻断
Sidecar 的 egress 裁剪只影响控制面可见性，不阻断数据面流量。未显式导入的 host 会落入 passthrough 兜底集群，多数默认配置下流量仍可放行。因此，将窄 egress 配置视为流量隔离手段是常见误解，真正的流量控制需依赖 Egress Gateway 或网络策略。
Telemetry 禁用继承不对称
Telemetry 的字段覆盖是整体替换，但禁用继承不对称：父级显式禁用后，子级必须显式设置 disabled: false 才能重新启用，仅省略该字段不会覆盖。这避免了中间层意外重新打开被上层关闭的 provider，但要求子级配置时明确写出禁用状态。
EnvoyFilter 排序：创建时间而非修改时间
EnvoyFilter 的合并顺序由 root 命名空间优先，再按 priority、创建时间、资源名升序决定。创建时间戳在 kubectl apply 更新时不变，因此修改内容不会改变排序位置；只有删除重建或换名才能排到更靠后。这打破了“最后 apply 生效”的直觉。
相对操作缺 priority 的警告
EnvoyFilter 使用相对操作（如 MERGE、REMOVE）时若未设置 priority，istioctl analyze 会给出 IST0151/IST0155 警告。IST0151 提示排序不确定可能导致补丁失败，IST0155 则叠加 proxyVersion 匹配条件，升级后排序可能变化。建议改用绝对操作或显式设置 priority。
Q&A
Istio中Sidecar、Telemetry、EnvoyFilter三种资源在配置生成流水线中分别作用于哪个阶段？
Sidecar作用于生成前，裁剪代理可见的输入；Telemetry作用于生成中，注入可观测配置；EnvoyFilter作用于生成后，直接对生成的配置打补丁。
Istio Sidecar的egress配置能阻断流量吗？
不能。Sidecar的egress裁剪只影响控制面可见性，即CDS/RDS中是否包含该Cluster/路由，但不影响数据面转发。未显式导入的host会落入passthrough兜底集群，流量仍可能被放行。要实现流量阻断需使用Egress Gateway或网络策略。
Istio Telemetry中，父级显式禁用某个字段后，子级如何重新启用？
子级必须显式设置disabled: false才能重新启用。仅不写disabled字段不会重新启用，因为未显式设置时默认继承父级的显式禁用。
Istio EnvoyFilter的合并顺序是什么？
EnvoyFilter的合并顺序为：先处理root命名空间（通常istio-system）的所有EnvoyFilter，再处理workload命名空间的；同一范围内按priority升序，priority相同时按创建时间升序，创建时间也相同时按完整资源名字典序。
EnvoyFilter的排序键是创建时间还是修改时间？
排序键是创建时间，不是修改时间。对已存在的EnvoyFilter进行kubectl apply更新内容不会改变creationTimestamp，因此不会改变其在合并顺序中的位置。只有删除重建或更换资源名才会改变顺序。
EnvoyFilter使用相对操作但未设置priority时，istioctl analyze会给出什么警告？
会给出IST0151警告，提示可能因排序不确定导致补丁应用失败，建议改用绝对操作或显式设置priority。若同时匹配proxyVersion条件，还会给出IST0155警告。
Istio中“更具体的配置覆盖更宽泛的配置”这一直觉是否总是成立？
不成立。合并/覆盖规则因资源类型而异，例如Telemetry的禁用继承不对称、EnvoyFilter按创建时间排序等，都不能简单套用该直觉。具体规则需查阅官方文档。
