Istio: Kubernetes Service Mesh

最近在写 L4/L7 ILB的design doc，load balancing在cloud和service mesh层面的矛盾在于它在架构层面极其重要（路由是微服务网关的基础），但从开发者的视角却几乎不存在（people expect it naturally happen）。

Istio是什么

首先Istio是什么

Google Cloud官方说法 Istio 就是是一种现代化的Service Mesh服务网格

service mesh是什么

其实从研发人员的角度来说，微服务可能还算有点，但是service mesh给人的感觉就是在炒概念：不就是加个sidecar么，怎么就mesh了？

Matt Klein（envoy的作者）在2017年的博客里画了一张图。

他认为在微服务的场景下，拆分后的服务是一个个独立的单元。每个服务实例都与一个sidecar proxy 处于一个单元。来自单个服务实例的所有网络流量（HTTP、REST、gRPC、Redis等）都通过其本地sidecar proxy 流向适当的目的地。因此，服务实例不知道整个网络，只知道其本地proxy。

Google认为应该将service mesh理解成管理服务的SDN（Software-defined networking for services）。这个理念其实非常激进，一般的看法认为service mesh是实现可靠微服务的基础架构层。Google的观点则一步到位，认为整个service mesh其实就是在做网络治理。（这样也好，省的大家拿着新概念炒作，再扯service mesh就是搞网络转发）

数据平面

SDN分两层：控制平面 & 数据平面，service mesh 也是同样。Matt Klein 认为数据平面的任务在于：

• Service discovery: 所有可用的上游/后端服务实例是什么？
• Health checking:由服务发现返回的上游服务实例是否健康并准备接受网络流量？这可能包括主动（例如，ping到/healthcheck端点）和被动（例如，使用连续3个5xx作为不健康状态的指标）健康检查。
• Routing: 考虑到来自本地服务实例的/foo的REST请求，该请求应该被发送到哪个上游服务集群？
• Load balancing: 一旦在路由过程中选择了一个上游服务集群，该请求应该被发送到哪个上游服务实例？使用什么超时？用什么样的断路设置？如果请求失败，应该重试吗？
• Authentication and authorization: 对于传入的请求，能否使用mTLS或其他机制对呼叫者进行加密证明？如果经过认证，调用者是否被允许调用所请求的端点，还是应该返回一个未经认证的响应？
• Observability: 对于每个请求，应该产生详细的统计数据、日志和分布式跟踪数据，以便操作人员能够了解分布式流量并在发生问题时进行调试。

这些都是data plane 的责任。并且 sidecar proxy就是data plane，比如Linkerd, NGINX, HAProxy, Envoy, Traefik...

换句话说，data plane负责转换、重定向和审查来往服务实例的每个网络数据包。

控制平面

data plane所提供的完整但复杂的网络抽象。接下来的问题是，proxy如何知道将/foo路由到服务B？proxy 是如何查询服务发现的？如何指定负载平衡、超时、断路等设置？如何使用蓝/绿或渐进式流量转移语义来完成部署？如何配置整个系统的认证和授权设置？

这些都是 control plane的任务：将一组独立的无状态的sidecar proxies，组成一个分布式系统。控制平面的目标是设置policy，最终由数据平面来执行。以前这些事都是人来控制，只不过现在变成软件了。

Istio

Istio 其实是四个部分：Pilot + Mixer + Istio Security + Envoy。前三个组成Istio control plane，envoy作为data plane。

但是这事儿没这么简单，你要是仔细看ppt下面那个注解的话。Istio control plane 的组件中，真正做配置和流量管理的只有Pilot。Mixer是留给用户做插件的，security做安全。

那用户要是想轻松点，只用pilot呢？或者进一步，用户连control plane都不想管理，Google Cloud作为云提供商不能直接给个简单方案么。所以Google 又发布了一个东西叫做 Traffic Director

Traffic Director

Traffic Director相当于一个由Google Cloud直接管理的Pilot，但实际上用户可以完全忽略掉Istio Envoy，直接关注于业务。

底层当然还是Envoy了，毕竟Matt本人都过来站台。仔细说的话，这东西其实还跟VNS有关系。VNS会在里面做endpoint awareness然后通知Backend Manager。

BackendManager根据VNS Spanner去做health check，如果发现某个service宕机了，就会通知Traffic Director去移除这个节点。

Traffic Director再去通知data plane绕开故障区域

当然在data plane上这些还是靠Envoy实现的

神奇的L7 ILB

那L7 ILB跟这些有什么关系？L7 ILB底层是靠Envoy实现的，google cloud使用了一个envoy的资源池，在逻辑层面上将Envoy作为middle proxy插入用户网络中，用户甚至可以无需注入新的改动，直接在L7层面启用负载均衡。

当然这些都是场面话，真正发生在cloud内部的事情，比这个更加复杂。所以我们要深入看看Envoy在Google Cloud中做了什么。下篇《Envoy: modern Cloud Load Balancing》

References：

1. Service mesh data plane vs. control plane by Matt Klein
2. Traffic Director & Envoy-Based L7 ILB for Production-Grade Service Mesh & Istio (Cloud Next '19)