Istio 的版本维护策略很明确——每个小版本在 N+2 版本发布六周后停止支持。Istio 1.30 已于 2026 年 5 月 18 日发布，这意味着 1.28 的维护窗口将在 2026 年 6 月 28 日正式关闭。届时，安全漏洞和关键 bug 的修复不会再回溯到 1.28。如果你还在跑 1.28，现在就是规划升级的时间点，拖下去只会让未来的紧急升级变成一场没有退路的硬仗。
Istio 的版本生命周期规则
Istio 采用的是滚动式支持策略：当 1.30（1.28 的 N+2）发布后，1.28 进入最后的六周过渡期。过渡期结束，1.28 分支不再接受任何补丁，包括安全修复。这套规则的核心逻辑是让社区集中精力维护最近三个版本，而不是无限向后兼容。
换算一下时间线：
| 版本 | 发布时间 | 支持截止 |
|---|---|---|
| 1.28 | — | 2026-06-28 |
| 1.29 | — | 1.31 发布后 6 周 |
| 1.30 | 2026-05-18 | 1.32 发布后 6 周 |
落在 1.28 上的集群，6 月 28 日之后如果爆出高危 CVE，你只能选择就地升级到受支持版本，没有补丁可以打。这种被动升级的风险远大于主动规划。
先摸清现状：集群里跑的是哪个版本
升级之前，第一步是确认当前 Istio 的精确版本和组件分布。下面这条命令可以一次性拿到控制面和数据面的版本信息：
# 查看控制面版本
istioctl version
# 查看所有命名空间中 sidecar proxy 的版本分布
istioctl proxy-version
# 如果你没有 istioctl，也可以用 kubectl 直接查
kubectl -n istio-system get deploy istiod -o jsonpath='{.spec.template.image}'
输出示例：
client version: 1.28.3
control plane version: 1.28.3
data plane version: 1.28.3 (120 proxies)
如果你看到 data plane 里混杂了多个小版本（比如部分 proxy 还停留在 1.27），说明之前的升级没有做完整滚动，需要先统一数据面版本再继续。
升级实操：从 1.28 到 1.30
Istio 推荐的升级方式是 金丝雀升级（Canary Upgrade）——新旧控制面并行运行，逐步迁移数据面，全程业务不中断。下面是一个完整的升级流程示例：
1. 部署金丝雀控制面
# 安装 1.30 版本的 istioctl（假设你已经下载了 1.30 发行包）
export PATH=$PWD/istio-1.30.0/bin:$PATH
# 金丝雀升级：在 istio-system 中并行部署新的 istiod-canary
istioctl upgrade --canary --version 1.30.0
这条命令不会替换现有的 istiod，而是额外部署一个 istiod-canary Deployment。两个控制面共存，各自管理自己标签匹配的 proxy。
2. 验证金丝雀控制面状态
# 确认两个 istiod 都在运行
kubectl -n istio-system get deploy
# 期望看到：
# istiod 1/1 istio/pilot:1.28.3
# istiod-canary 1/1 istio/pilot:1.30.0
3. 逐步迁移数据面
给命名空间打上金丝雀 revision 标签，让该命名空间下的 pod 重启后接入新控制面：
# 标记 default 命名空间使用 canary revision
kubectl label namespace default istio.io/rev=canary --overwrite
# 重启 default 命名空间中的 pod，触发 sidecar 重新注入
kubectl rollout restart deployment -n default
# 等待滚动完成，检查 proxy 版本
istioctl proxy-version -n default
确认所有 proxy 都变成 1.30.x 后，再迁移下一个命名空间。不要一次性全切，逐个命名空间滚动是最稳的做法。
4. 收尾：移除旧控制面
当所有命名空间的数据面都迁移完毕，卸载旧版本控制面：
# 确认没有 proxy 还在指向旧 revision
istioctl proxy-version | grep 1.28
# 如果输出为空，安全卸载旧控制面
istioctl uninstall --canary-revision 1.28 -y
# 清理旧 revision 标签
kubectl label namespace default istio.io/rev- istio.io/rev=1.30.0 --overwrite
升级前的检查清单
升级本身不难，难的是升级前没排查隐患。跑一遍这个清单可以减少意外：
- CRD 兼容性：检查自定义的 EnvoyFilter、AuthorizationPolicy 是否使用了 1.28 中即将废弃的 API 字段。1.30 的变更日志里有明确的废弃列表，逐项对照。
- 第三方集成：如果你用了 Istio Gateway API 替代 Ingress，确认 Gateway API 的 CRD 版本与 1.30 兼容。
- 监控告警：升级期间新旧 proxy 混合运行，指标采集可能出现短暂不一致。提前在 Prometheus/ Grafana 里加一个按
istio.io/rev分组的过滤面板，方便观察切换进度。 - 回滚预案：金丝雀升级支持回退——只要旧 istiod 还在，把命名空间标签改回旧 revision 再重启 pod 即可。但一旦你卸载了旧控制面，回退就只能重装 1.28，成本陡增。所以确认全量迁移后再收尾。
别等到 CVE 来敲门
Istio 1.28 的支持截止日是硬性的，不会延期。6 月 28 日之后，任何安全修复只覆盖 1.29 及以上版本。留在 1.28 的集群等于在裸奔——不是"可能出问题"，而是"出了问题没有补丁可用"。
金丝雀升级的设计让整个过程可以零中断完成，但前提是你有足够的时间逐命名空间滚动。现在离截止日还有窗口，正是最从容的升级时机。