Istio 正在调整主分支上的 CI 集成测试范围：从 Istio 1.32 开始，项目将不再持续测试已经 EOL 或即将 EOL 的旧 Kubernetes 版本，只保留当前官方支持范围内的版本。这不是改变 Istio 对 Kubernetes 的支持声明，而是让 CI 资源集中验证社区实际使用、且仍在上游支持周期内的版本。
CI 测试范围发生了什么变化
过去，Istio 通常会测试最新 Kubernetes 版本之前约 N-3 或 N-4 个小版本，同时保留更老版本的集成任务。当前测试矩阵覆盖 Kubernetes 1.23 到 1.36；随着 test-infra PR 6048 合并，主分支会移除其中已经不再支持的旧版本任务，只测试受支持的 Kubernetes 范围。
这项变更落在 master 分支，因此会影响 Istio 1.32 及之后的版本。具体版本范围会随 Kubernetes 发布节奏变化，不能把某个固定版本号当作长期不变的兼容性承诺。使用 Istio 时，应以对应 release 的 support status table 为准。
为什么要淘汰旧版本任务
Kubernetes 的小版本支持周期大约为 14 个月。旧版本一旦进入 EOL，继续为它们维护节点镜像、Kind 配置和 CI 任务，就会带来几类实际成本：
- 占用 CI 集群、节点镜像和测试执行时间；
- 增加测试基础设施修复和版本兼容维护的负担；
- 稀释对当前受支持 Kubernetes 版本的测试资源；
- 让失败结果更难区分是 Istio 回归，还是旧平台本身已经脱离支持周期。
因此，这次调整的重点不是删除本地验证能力，而是停止在主 CI 队列中长期维护过时平台。仍然运行旧 Kubernetes 的团队，需要把这部分验证转移到自己的环境或按需运行的本地测试中。
仍需验证旧版本？复用 CI 的 Kind 入口
如果项目必须兼容某个旧 Kubernetes 版本，可以在 Istio 源码树中使用与 CI 相同的 prow/integ-suite-kind.sh 入口运行集成测试。下面是一个可改造的命令示例：
# 在 Istio 源码根目录执行。
# 将 node image 和 kind 配置替换为目标 Kubernetes 版本过去在 CI 使用的值。
prow/integ-suite-kind.sh \
--node-image kindest/node:<target-kubernetes-version> \
--kind-config prow/config/mixedlb-service.yaml \
test.integration.kube
例如，若要验证某个历史版本，命令形态可以是：
prow/integ-suite-kind.sh \
--node-image kindest/node:v1.XX.Y \
--kind-config prow/config/mixedlb-service.yaml \
test.integration.kube
这里的 v1.XX.Y 只是占位符，不应直接照抄。应从 test-infra 的提交历史中查找目标 Kubernetes 版本此前使用的确切节点镜像和 Kind 配置，然后替换 --node-image 与 --kind-config 的值。这样做可以尽量复现过去 CI 的测试环境，而不是随意选择一个相近版本。
运行前还应确认本机已经安装并可用 Docker、Kind，以及项目测试所需的其他依赖。旧版本测试可能因为镜像不可用、宿主机架构差异或依赖下载失败而报错；这些问题需要与 Istio 本身的回归分开判断。
对维护者和升级计划的影响
使用仍受支持 Kubernetes 的团队
日常升级流程基本不需要改变，但应定期检查 Istio release 对应的支持状态表，并把 Kubernetes 升级纳入平台生命周期计划。不要仅因为旧版本仍能启动 Istio，就把它视为持续获得 CI 覆盖。
必须保留旧集群的团队
建议在自己的 CI 中固定以下信息：
- Kubernetes 节点镜像的完整版本；
- Kind 配置文件版本；
- Istio 分支或 release 版本；
- 测试失败时使用的宿主机和容器运行时版本。
这样既能保留遗留平台的回归能力，也能避免依赖已经从 Istio 主 CI 中移除的隐式配置。
一份实用检查清单
- 确认当前 Kubernetes 版本是否仍在目标 Istio release 的支持范围内；
- 不要把 master 分支的测试矩阵当作所有历史版本的永久兼容性证明；
- 对旧版本测试，从 test-infra 历史中恢复准确的节点镜像和 Kind 配置；
- 使用
prow/integ-suite-kind.sh在本地或自有 CI 中运行集成套件； - 将旧 Kubernetes 版本的测试失败与 Istio 代码回归、镜像失效和基础设施问题分别归类；
- 如需确认当前策略，可联系 Istio Test and Release Working Group。
这次退休的是过时版本的 CI 集成任务，而不是对所有遗留环境的即时强制中断。对大多数团队而言，最稳妥的做法是跟随 Kubernetes 上游支持周期升级；对仍有历史兼容性要求的团队，则应把旧版本验证明确地放入自己的可控测试流水线中。