大规模运行 Istio 以实现安全和合规的 Cloud - Lucas Copi 和 Rafael Polanco

Istio 在 IBM Cloud Kubernetes 服务中的大规模应用实践

IBM Cloud Kubernetes 服务概况

• 服务核心为 Kubernetes 和 Openshift 产品
• 全球 10 个地理区域，每个服务集群平均 250 rps
• 高峰负载和突发率极高，混合小批量和大批量负载
• 每天约 150-200 个集群创建事件

引入 Istio 的必要性

• Istio 提供 500 多项安全和合规控制措施，基于 NIST 800-53 标准
• 满足 75 家机构和 24 个国家的监管要求
• 最初为金融服务支持（18 个月前），提升 CISO 级别的安全合规性并超越服务水平目标 (SLO)

IKS 系统架构与迁移过程

• 迁移前托管入口架构：手动配置，效率低下
• 迁移后架构：
  • 采用 Istio 实现精细交通管制、可观测性和弹性
  • 开箱即用的自动 TLS 和严格 mTLS 连接
  • 控制出站流量安全性（所有出站流量需已知并记录）
  • 帮助团队实施安全和监管控制（如网络策略、mTLS 身份验证）
• 初始迁移：
  • 1.4 版本开始实验双向 TLS 和明文流量
  • 1.8.x 版本上线生产环境，手动灰度部署
• 当前 Istio 管道：
  • 使用开源工具 Razee 自动化部署
  • 结合 Jenkins 实现操作流程，全球部署时间从一周缩短至不到半天

迁移中的经验教训

• 分布式系统故障：
  • 故障可能因非硬件原因（配置错误、软件 bug）持续存在
  • 高突发负载增加延迟和错误级联，导致系统停机
• 稳定性优化措施：
  • Kubernetes HA 微服务指南：Pod 优先级和抢占
  • 配置管理容器资源，优化部署策略（RollingUpdate、maxUnavailable、maxSurge）
  • 解决雷鸣般的羊群问题与重新启动

迁移中的挑战与解决方案

• 意外结果：
  • 高敏感于超长延迟操作（如绕过 Istio 直接访问数据库）
  • 出口流量远高于入口流量（10 倍）
  • 解决方案：
    • 设置专用出口网关
    • 跨区域传播 SNI 代理
• 严格的 mTLS 挑战：
  • 普罗米修斯抓取问题：
    • Prometheus 通过 Istio Gateway 抓取入口网关度量端点时，流量被拦截
    • 解决方案：
      • 使用 traffic.sidecar.istio.io/includeInboundPorts 注释重定向流量到 Envoy
      • 配置 iptables 规则允许 Prometheus 抓取
  • Sidecar 与工作负载竞争：
    • holdApplicationUntilProxyStarts 钩子延迟应用启动
    • 解决方案：
      • 优化钩子逻辑，确保 Sidecar 和工作负载协同工作

下一步计划

• 利用分布式跟踪
• 实施速率限制
• 对 API 网关进行 A/B 测试
• 从 Istio 操作员迁移到 Razee 托管部署
• 优化性能