Istio 升级问题及解决方案
核心观点与背景
Istio 作为服务网格（Service Mesh）解决方案，其安全性是其主要应用动机之一，但 88% 的 Istio 安装运行在已知 CVE 状态。用户不升级的主要原因包括：对自身脆弱状态 unaware、升级困难、频繁的小版本升级、以及人类不擅长重复性任务。
用户不升级的原因分析
2020 年至 2022 年第一季度，用户不升级的原因经历了变化：
- 2020 年 Q2：用户 unaware 自己处于脆弱状态
- 2020 年 Q3：升级太困难
- 2021 年 Q2：需要频繁进行小版本升级
- 2022 年 Q1：人类不擅长重复任务
此外，用户知道自身不在日期但无时间 fix，缺乏信息，以及频繁的小版本升级被认为是危险和困难的。
Istio 升级路线图改进
Istio 在 2021 年和 2022 年的路线图中重点解决升级问题，并成立了专门工作组。通过降低升级节奏，允许用户跳过次要版本，并扩展支持窗口，Istio 支持用户每年升级 2-4 次。
解决方案：IstioD 作为托管服务
Google 提出将 Istio 作为托管服务（IstioD），管理 ASM 数据平面和 CDConfig，使用户无需关心组件管理，只需关注业务。
GitOps for IstioD
构建 OSS Config-as-Code 系统，将服务网格的所有状态定义在源代码控制中，实现自动化升级和简单回滚。GitHub Actions 检查新的 Istio 版本并自动创建拉取请求。
控制平面升级
- 优点：控制平面保持在 semver 范围内最新状态，超出范围的更新触发 GitHub Actions 拉取请求，全栈在 kind e2e 测试中进行全面测试，每次变更时运行 Istioctl Analyze
- 缺点：代理升级仍然不受控制，需要更新 Helm，基于修订的升级
数据平面升级
- 优点：代理保持在 semver 范围内更新，自动回滚 Canary
- 缺点：在 Git 中定义代理会大大增加 workload.yml 中的噪声，不尊重修订版本，向多个集群部署时必须手动协调
未来工作方向
计划通过自动化升级解决 Istio 升级问题，用户可以选择向供应商付款升级，或使用自动化工具。
相关资源与活动
