Istio与Envoy xDS的关系

• • Istio & Envoy -- 控制面与数据面
  • Envoy & xDs协议
  • • 概念
    • • Downstream
      • Upstream
      • Listener
      • Cluster
      • Route
      • Endpoint
    • 运行时配置

服务网格是通过sidebar模式实现的，网格中的每个点是微服务，而实际上每个点之间的通信都是通过自己的sidebar. 因此只要控制了所有sidebar,就控制了所有服务的通信。这是服务网格最根本的道理。

服务网格分成控制面和数据面：

• istio 作为网格的控制面(control plane),控制面获取服务注册信息，下发给控制面。

• envoy作为网格的数据面 (data plane)，数据面接受来自控制面服务注册信息，更新本地路由规则。
  

控制面与数据面数据交换，为了形成一个统一的规范。于是有了xDs协议。

为了便于扩展，任何兼容规范的实现者都可以接入，所以需要定义统一的规范。

Envoy会主动从管理服务器（istio pilot）中获取服务注册信息，因为istio pilot实现了xDs API。
XDs API是一系列资源对象集合。

参考： Envoy terminology

下游主机，下游主机连接Envoy,向它发送请求，接受响应。

下游主机从Envoy接受请求，并向Envoy发送响应。

比如Service A要访问Service B, Service A就是下游，Service B就是上游。

图中红色为请求路径，蓝色为响应路径。可以看到服务间通信都需要经过Envoy Proxy

A listener is a named network location (e.g., port, unix domain socket, etc.) that can be connected to by downstream clients. Envoy exposes one or more listeners that downstream hosts connect to.

Envoy作为一个进程在容器环境下和业务容器运行在同一个Pod。因为处于同一Pod的容器概念上属于同一主机的不同进程，业务容器通过本地localhost:${envoy_port} 与envoy进程通信。这个envoy进程的访问地址就是Listener。

通常情况下， envoy会有多个访问地址供下游连接，这意味着会有多个listener.

A cluster is a group of logically similar upstream hosts that Envoy connects to.

一组上游服务器（相同镜像的Pod实例）称为Cluster

路由是一组将虚拟主机(virtual hosts)与群集(cluster)匹配的规则。

将virtual hosts = 域名+ API访问路径(e.g. vip.com/getUser)路由到cluster user-service(user-service是一组Pod).

一个实例就是一个endpoint, cluster由多个endpoint组成。

将这些概念组织起来

1. 下游服务器要访问上游服务器
2. 需要连接Listener监听的端口（e.g. 80）发出请求。
3. listener通过查看请求的域名和路径，路由匹配到某个集群
4. 查看集群中的Endpoint/实例列表信息，将请求路由到其中一个EndPoint，（此处的Endpoint是上游服务代理的ip和端口）。

• 参考自：https://skyao.io/learning-envoy/architecture/concept/

通过Kuberenetes增删服务时，数据面Envoy的本地路由信息是要动态更新的, 且不需要重启即可配置生效。

Envoy会主动定期从服务器拉取路由信息，称为“订阅”。 Envoy可以通过监听文件，调用gRPC/RESTful HTTP API接口三种方式从管理服务器（实现xDS API的服务）订阅路由信息。

Envoy请求管理服务器的报文格式使用xDS规范。xDS规范定义了资源对象的增删改查接口(比如实现了增删改查Cluster的服务，叫做 Cluster Discovery Service)。