Istio 的扩展和定制

1、Istio 和 Kubernetes 的去耦合

对于非 Kubernetes 环境下，并且相当长一段时间内也没有迁移到 Kubernetes 的计划时，没有必要使用基于 Istio 的 Service Mesh 方案。但如果是多平台支持的场景，比如客户中既有 Kubernetes 环境用户，也有非 Kubernetes 环境用户，这种情况下，可以对 Istio 进行定制修改，去掉对 Kubernetes 的强耦合，并且增加对其他平台的支持。

Istio 对 Kubernetes 的耦合主要有如下几个方面，因此需要有针对性地进行适配修改。

• API 资源管理层面对 Kubernetes API Server 的依赖

资源管理是 Istio 对 Kubernetes 依赖最大的地方。Istio 对核心资源的管理，是以 Kubernetes CRD 为基础的，并且使用 kubectl 作为命令行操作入口，kubectl 会调用 API Server，将资源存放在 etcd 中，并通过 Kubernetes CRD 机制触发资源变更事件通知，通知关心 Istio 资源变更事件的模块进行相应的处理。

Kubernetes 通过 kubectl、API Server、etcd 和 Kubernetes CRD 组件，提供一套完善的 API 资源管理机制，包括资源的增删查改和资源的变更通知，如果需要解除 Istio 对 Kubernetes 的绑定，就需要自行实现这一套 API 管理方式，并且做到平台无关。

• 通信访问层面对 kube DNS 的依赖

通信层面，在客户端发送请求前，先通过 DNS 获取服务的虚拟 IP 地址，Istio 的 DNS 实现沿用 Kubernetes DNS 方案（Kubernetes DNS 是 Kubernetes 网络管理中的关键一环），基于 DNS，通过服务名就可以直接访问服务。因此通信层面，需要在 DNS 方案层面解除和 Kubernetes 的耦合，并使用平台无关的 DNS 解决方案。

2、平台无关的 Istio 支持方案

Istio 作为控制平面，主要是对数据平面 Envoy 的服务信息和配置信息进行管理，因此平台无关的 Istio 支持方案，主要需要提供平台无关的配置管理中心和服务注册中心。

Consul 是管理分布式系统的配置和服务发现的开源项目，和 ZooKeeper、etcd 等其他分布式服务发现方案相比，Consul 提供了一站式解决方案，内置了服务发现、健康检查、key/value 存储、多数据中心方案、REST API 接口等众多特性。推荐使用 Consul 作为平台无关的配置中心和服务发现解决方案，Istio 当前也提供了对 Consul 的基本支持，但还不太成熟，所以无法直接应用到生产环境中。

3、RPC 协议扩展支持

Envoy 当前重点提供对 HTTP1 和 HTTP2 的支持，而对 RPC 协议的支持还很弱。RPC 协议方面，当前虽已提供对 Thrift 协议和 Dubbo 协议的支持，但支持的程度都很弱，也不支持常见的链路治理特性，因此它们均不具备在生产环境下使用的条件。

如果需要对 Envoy 增加相应的 RPC 协议扩展，可以参考 Envoy 下 Thrift 协议的具体实现，首先要定义 RPC 协议对应的 Network Filter 插件，并通过 RegisterFactory 进行静态注册。

在插件必须实现的入口函数 createFilterFactoryFromProtoTyped 中，可以实现插件对应配置的解析，比如路由相关的配置，同时要通过 addFilter 向 filter manager 注册插件协议处理函数。

在插件的 OnData 函数中实现具体的协议解析逻辑，解析出路由需要的参数，从而可以通过配置的路由策略选取相应的 Upstream 节点，进而调用 Upstream 节点进行相应的处理。