Istio 1.28 的支持已经正式结束。这意味着从现在开始，1.28 分支不会再收到安全问题和关键缺陷的回溯修复。对于运行在生产环境里的服务网格来说，这不是一个“版本号过旧”的小问题，而是安全边界、故障恢复和合规审计都会关心的风险点。
当前官方建议升级到最新版本 Istio 1.30.2。如果你的集群还停留在 1.28，现在应该把升级从“待办事项”提升为一次明确排期的运维变更。
支持结束到底影响什么
Istio 的生命周期结束，最直接的影响是：即使后续发现了影响 1.28 的安全漏洞或严重 bug，也不会再把修复补丁回移到 1.28 分支。
这会带来几个实际后果：
- 安全修复不再覆盖当前版本，漏洞窗口会持续扩大。
- 严重 bug 即使在新版本中修复，1.28 用户也需要自行承担风险。
- 平台团队在排障时更难获得社区和上游版本的支持。
- 合规场景下，继续运行 EOL 版本可能需要额外风险说明。
服务网格通常处在请求路径的核心位置，Envoy sidecar、入口网关、证书轮换、策略控制都可能受版本影响。升级不只是“跟上版本”，更是减少未来不可控故障面的动作。
升级前先确认你在哪里
在升级前，先把当前控制面、数据面和命名空间注入情况查清楚。下面这些命令可以直接复制运行。
# 查看 istioctl 客户端、控制面和数据面版本
istioctl version
# 查看 istiod Pod 镜像版本
kubectl -n istio-system get pods -l app=istiod -o wide
kubectl -n istio-system get deploy istiod -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
# 查看网关注入和镜像版本
kubectl -n istio-system get deploy -l istio=ingressgateway -o wide
# 找出开启自动注入的命名空间
kubectl get namespace -L istio-injection
# 如果使用 revision-based 安装，也检查 revision 标签
kubectl get namespace -L istio.io/rev
如果你看到控制面仍是 1.28.x，就应该规划升级。若集群使用多 revision 灰度升级，需要额外确认工作负载绑定的是哪个 revision，避免只升级了控制面，却留下大量旧 sidecar。
可以这样实践：用 revision 做一次更稳的升级
Istio 升级方式取决于你当前的安装方式。下面示例展示一种常见思路：安装 1.30.2 的新 revision，逐步把命名空间切过去，再重启工作负载让 sidecar 更新。请根据你的 profile、网关部署方式和生产变更流程调整。
# 1. 下载并切换到目标版本 istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.30.2 sh -
cd istio-1.30.2
export PATH="$PWD/bin:$PATH"
# 2. 安装一个新的 revision，避免直接覆盖旧控制面
istioctl install \
--set profile=default \
--set revision=1-30-2 \
-y
# 3. 将一个低风险命名空间切换到新 revision
kubectl label namespace demo istio-injection- --overwrite
kubectl label namespace demo istio.io/rev=1-30-2 --overwrite
# 4. 滚动重启工作负载，让新的 sidecar 注入生效
kubectl -n demo rollout restart deployment
kubectl -n demo rollout status deployment
# 5. 确认 proxy 状态
istioctl proxy-status
如果你希望先做一次配置兼容性检查，可以在升级前运行：
istioctl analyze --all-namespaces
这个命令不能替代完整测试，但能提前暴露一部分配置问题，例如无效的 Gateway、VirtualService 或目标服务引用。
升级时最容易踩的几个点
不要只升级 istiod，还要关注数据面。Istio 的控制面升级后，业务 Pod 中的 sidecar 仍可能停留在旧版本，直到工作负载重新注入。对长期不重启的服务尤其要留意。
网关也需要单独检查。很多集群把 ingress gateway 当作独立 Deployment 管理，升级控制面并不一定自动替换网关镜像。
另外，生产环境建议避免一次性切换所有命名空间。更稳妥的路径是：
- 先在测试集群验证 1.30.2。
- 再选择低流量或内部服务命名空间灰度。
- 观察指标、访问日志、mTLS、授权策略和入口流量。
- 最后扩大到核心业务命名空间。
收尾检查清单
升级完成后，不要只看 Pod 是否 Running。建议至少检查这些项目：
# 确认是否还有旧版本 proxy
istioctl proxy-status
# 检查 Istio 配置是否有明显错误
istioctl analyze --all-namespaces
# 查看控制面日志中是否有异常
kubectl -n istio-system logs deploy/istiod --tail=200
# 确认关键命名空间的 revision 标签
kubectl get namespace -L istio.io/rev -L istio-injection
如果检查后确认没有工作负载继续依赖 1.28 revision，再考虑清理旧 revision。清理前务必确认回滚策略，因为删除旧控制面后，回退路径会变窄。
建议的决策
如果你的 Istio 仍在 1.28，最合理的动作不是等待下一个故障或安全公告，而是尽快规划到 1.30.2 的升级窗口。对生产集群来说，使用 revision 灰度、逐步重启数据面、保留短期回滚路径，是比原地大版本覆盖更稳的做法。
EOL 版本最大的风险不是它今天一定会坏，而是当它明天真的遇到安全问题或关键 bug 时，你已经不在补丁覆盖范围内了。