Istio

前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。 蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？ 本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。 蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构

单控制平面拓扑下，多个 Kubernetes 集群共同使用在其中一个集群上运行的单个 Istio 控制平面。控制平面的 Pilot 管理本地和远程集群上的服务，并为所有集群配置 Envoy Sidecar 代理。 集群感知的服务路由 Istio 1.1 中引入了集群感知的服务路由能力，在单一控制平面拓扑配置下，使用 Istio 的 Split-horizon EDS（水平分割端点发现服务）功能可以通过其入口网关将服务请求路由到其他集群。基于请求源的位置，Istio 能够将请求路由到不同的端点。 在该配置中，从一个集群中的 Sidecar 代理到同一集群中的服务的请求仍然被转发到本地服务 IP。如果目标工作负载在其他集群中运行，则使用远程集群的网关 IP 来连接到该服务。 如图所示，主集群 cluster1 运行全套的 Istio 控制平面组件，同时集群 cluster2 仅运行 Istio Citadel、Sidecar Injector 和 Ingress 网关。不需要 VPN 连接，不同集群中的工作负载之间也不需要直接网络访问。 从共享的根 CA 为每个集群的 Citadel 生成中间 CA 证书，共享的根 CA 启用跨不同集群的双向 TLS 通信。为了便于说明，我们将 samples/certs 目录下 Istio 安装中提供的示例根 CA 证书用于两个集群。在实际部署中