[IstioCon 2021：Istio 社区第一届全球峰会]：Istio is a long wild river- how to navigate it safely Raphael Fraysse

Istio 使用经验总结

Mercari 使用 Istio 概述

Mercari 是一个 C2C 二手物品交易平台，拥有 200 多个微服务，高峰期 API 网关处理 10 万 RPS，使用 Google Kubernetes Engine (GKE) 集群。Mercari 于 2019 年 9 月开始 Istio 试点，2021 年 2 月首次在生产环境发布，截至 2020 年底，约 25% 的生产服务和 50% 的开发服务迁移至 Istio，最终 100% 服务迁移至 Istio。目前使用的 Istio 功能包括 HTTP/2 负载均衡、流量转移和 mTLS，正在调查重试和断路器功能。

Istio 稳定化挑战与解决方案

Istio sidecar 代理规范

所有入站流量必须首先通过 pod 中的 sidecar 代理，所有出站流量必须在离开 pod 前通过 sidecar 代理。

Kubernetes sidecar 容器缺点

容器生命周期控制：Kubernetes 缺乏良好的控制 API 来自定义 pod 中容器的生命周期，无法确保 sidecar 代理在应用容器之前启动或之后停止。
- 解决方案：使用 postStart 和 preStop 生命周期钩子。
  - postStart 钩子在 istio-proxy 容器中启动 Envoy。
  - preStop 钩子在应用容器中停止 Envoy，并等待连接 draining 完成。
  - 调整 terminationGracePeriodSeconds 以确保连接 draining 完成。
多容器 pod 自动扩展：Kubernetes 的 HorizontalPodAutoscaler (HPA) 在扩展多容器 pod 时表现不佳。
- 解决方案：将 Istio sidecar 资源纳入 HPA 计算范围。
  - 使用 ContainerResource 资源定义来固定 HPA 目标。
  - 调整 HPA 阈值以匹配原始 CPU 绝对目标。

处理 Istio 的准备情况

成功采用 Istio 需要专用资源、内部网络知识、耐心以及提高 Istio 可靠性的机制。

选择合适的战斗，从小处着手

从简单的功能（如注入 sidecar 和 HTTP/2 负载均衡）开始，逐步建立信心和理解，然后逐步推广。

全 mesh 是乌托邦，只知所需

全 mesh 观察性和可达性虽然理想，但在大规模部署时会导致控制平面过载、代理 OOM 和 CPU 频繁被限流。

解决方案：使用 Sidecar CRD 限制每个代理的资源暴露。
- Sidecar CRD 允许基于命名空间或标签控制 mesh 配置的暴露范围。
- 主要缺点是服务必须知道其依赖关系，并更新文档。

Istio 的安全措施

使用 linters (conftest) 在 CI 级别捕获问题。
使用 admission webhooks (OPA Gatekeeper) 保护资源和检查无法在 linter 级别检查的内容。

Istio 采用挑战与策略

采用挑战

将 HTTP/2 负载均衡从客户端移至 Envoy：Mercari 使用 gRPC 严重依赖客户端负载均衡库和 Headless Services，但 Istio 的 HTTP/2 负载均衡导致 headless services 问题，因此迁移至 ClusterIP services。
标签选择器更新：Istio 需要应用和版本标签，但 Kubernetes 标签不可变，需要创建新的 Deployment 并更新 Service。
Istio 默认重试策略：所有 HTTP 请求默认重试两次，无法禁用或更改，Mercari 通过 fork Istio 临时解决。
Istio 代理性能和容量：sidecar 代理增加延迟和计算资源，需要根据工作负载进行资源调整和性能测试。
抽象 Istio 功能：为用户提供自动化和管理的抽象层，提高开发体验和运维可维护性。