English日本語
Istio 1.0版本只支持在单个网络，即Mesh中的服务只能衔接在一个网络上。固然在架构设计上是盛开的，但从目前的代码来看，Istio的内部实现还是和Kubernetes高度集成的。由于Kubernetes集群中Pod缺省只支持一个网络接口，因而Istio也存在该限度并不让人意表。
随着Kubernetes在NFV领域中的逐步利用，已经出现多个Kubernetes的多网络平面解决规划，Istio也必要思考支持多网络平面，以为5G的微服务化架构提供服务通讯和管控的基础设施。
多网络平面是一个电信行业的常用术语，即将一个电信设备或者系统同时衔接到多个网络上。简而言之，就是一个主机上有多个物理或者虚构的网络接口，这些接口别离衔接到分歧的网络，这些网络之间通常是相互独立的。由于电信系统对靠得住性的要求极度高，因而系统会通过配置多网络平面来预防分歧网络流量的相互影响，提高系统的壮实性。
在电信的NFV（网络职能虚构化）领域中，已经有多个针对Kubernetes的多网络平面解决规划。其中一个Kubernetes推荐的规划是中兴通讯提供的Knitter开源实现。下图展示了Knitter是若何实现Kubernetes的多网络平面支持的。
要支持多网络平面，Istio必要批改Pilot天生Outbound Listener的代码实现
服务注册：
1) Envoy地点节点存在两个网络接口，别离衔接到10.75.8.0/24和192.168.10.0/24两个网络上。
2) Service A被注册到Service Registry中，使用的是第二个网络接口的IP，即10.75.8.101。
Envoy初始化（增长多网络平面处置逻辑）：
1) Envoy通过xDS接口向Pilot获取配相信息。
2) Envoy在xDS要求中携带地点节点上的所有网络接口的IP，在本例中即192.168.10.63和10.75.8.101。
3) Pilot从xDS要求中解析出Envoy地点节点的所有IP，在本例中即192.168.10.63和10.75.8.101。
4) Pilot用Envoy节点IP来和Service Registry中所有Service Instance的IP进行对比。
5) 由于Service A的注册IP 10.75.8.101和节点的两个IP之逐一样，Pilot判断该节点上存在Service A的Instance，为Service A创建了一个Inbound Listener。
服务要求：
1) 节点的网络接口10.75.8.101上收到一个来自downstream的要求，被沉定向到Envoy。
2) Envoy在15001端口上收到该要求，要求接见Service A。
3) Envoy凭据Pilot下发的配置将该要求交由在Service A端口的Inbound Listener，该Listener将要求分发到Service A的Inbound Cluster上，对应IP地址为127.0.0。1。
4) Envoy将要求发送到127.0.0.1的Service A过程的服务端口上进行处置。
该批改规划已实现并提交PR合入到Istio 代码中，在1月份颁布的Istio 1.1 Release中将会正式支持。
Copyright ? 沙巴 版权所有 京ICP备05032414号 
京公网安备11010802024551号
