Istio的扩展和定制

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节点进行相应的处理。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。