早上好，我是 Istio 1.1

1性能加强

 

虽然Istio1.0的目标是生产可用，但从去年7月份发布以来，在性能和稳定性上并不能让用户满意。社区的Performance and Scalability工做组在Istio v1.1中作了大量的努力以提升控制面和数据面的性能，其中最明显的性能加强包括：

• Sidecar API，减小发给proxy的配置数量以及pilot负载。

• 网络配置规则（Destinationrule,Virtualservie, ServiceEntry）中增长的 exportTo字段限制配置的可见范围。

• Envoy默认收集的统计数据大量减小。

• 给mixer增长load-shedding功能，防止overload。

• 提高envoy和mixer之间的交互协议。

• 可配置并发线程数，提升吞吐量。

• 可配置filter来约束mixer遥测数据。

从对Istio 1.1的测试数据来看，这部分工做取得了显著的效果。

 

1.1控制面性能表现

Pilot的CPU和内存使用受网格内的配置和系统状态的影响，例如负载变化速率，配置变化速率，链接到Pilot的proxy的数量等。能够经过增长Pilot的实例数来减小配置分发处理的时间，提升性能。

在网格内有1000个服务，2000 个sidecars，每秒1000请求下的表现：

• 单Pilot 实例使用 1 vCPU 和1.5 GB 的内存。

• istio-telemetry服务使用0.6 vCPU。

 

1.2数据面性能表现

CPU：proxy在每秒1000个请求下大约消耗0.6 vCPU 。

内存：proxy的内存消耗主要取决于它须要处理的配置数量，大量的listeners, clusters, and routes配置会增长内存使用。proxy每秒1000个请求下大约消耗50MB的内存。

时延：数据在传输时会经过客户端和服务端的sidecar，传输路径上的这两个proxy在1000 rps状况下，99%的请求时延是10 ms（TP99），单独server端的proxy增长6ms的时延。若是启用策略会进一步增长时延。

 

2多集群方案

 

在1.0中只提供了一种基于扁平网络的多集群方案：Istio控制面部署在一个Kubernetes集群中。这种方案要求各集群的 Pod 地址不能重叠，且全部的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多个Kubernetes并到一个Istio控制面下，在Istio看来是同一个网格。这种方案的网络要求苛刻，实际应用并很少。

在新发布的1.1版本上，多集群上作了很是多的加强，除了保留1.0扁平网络做为一种单控制面的方案外，还提出了另外两种方案供用户根据实际环境和需求灵活选择，这两种方案都不要求是扁平网络：

• 多控制面方案：在每一个集群中安装完整的Istio控制面，能够当作是一种松散的联邦，集群间服务在Gateway处联通便可。经过一个全局的DNS将跨集群的请求路由到另一个集群里去。这种集群的访问是基于Istio的ServiceEntry和Gateway来实现的，配置较多且复杂，需用户本身维护。

• 一种集群感知（Split Horizon EDS）的单控制面方案：Istio控制面板只在一个Kubernetes集群中安装，Istio控制面仍然须要链接全部Kubernetes集群的Kube API Server。每一个集群都有集群标识和网络标识。在服务间访问时，若是目标是本集群的负载，则相似单集群的方式直接转发；若是是其余集群的实例，则将流量转发到集群的入口网关上，再通过网关转发给实际对端。

 

3安全

 

3.1HTTP Readiness Liveness Probe自动重写

mTLS模式下，进入Envoy的HTTP请求会在TLS握手阶段被拒绝。1.1新增长了HTTP Probe的自动重写，经过将HTTP Probe请求发送到pilot-agent由其转发HTTP探测到应用，进而绕开Envoy的TLS认证。默认自动重写是关闭状态，用户须要根据实际须要打开。

3.2集群级别的RBAC设置ClusterRbacConfig

RbacConfig被标记为废弃，用户升级1.1后，必须迁移到使用ClusterRbacConfig。由于RbacConfig有bug，在一些状况下，其做用范围会被缩小到命名空间。

3.3SDS

SDS（SecretDiscovery Service）经过节点密钥生成提供更强的安全性以及动态的证书回滚。能够取代目前使用secret卷挂载的方式提供证书。1.1中目前为alpha，不建议生产环境使用，可是随着Istio发展值得期待。

3.4受权

新增对TCP类型服务的RBAC受权以及基于用户组的受权。

3.5Vault集成

容许用户集成开源Vault，使用Vault CA签发证书。

 

4网络

 

4.1新的sidecar API资源

在1.1中引入Sidecar这资源对象能够更精细的控制Envoy转发和接收的端口、协议。在指定命名空间中使用sidecar资源时，支持定义可访问的服务范围。这样能够下降发给proxy的配置的数量。在大规模的集群中，咱们推荐给每一个namespace增长sidecar的对象。 这个功能主要是为了提高性能，减轻pilot计算的负担。对proxy的影响是：1. 内存占用少，2. 下降网络带宽占用。  

4.2exportTo

在Istio1.1版本中添加了一个重要字段exportTo。用于控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可见性。这样就能够控制一个Namespace下定义的资源对象是否能够被其余Namespace下的Envoy执行了。若是未赋值，则默认全局可见。当前版本中只支持“.”和“*”两种配置。

•  “.”表示仅应用到当前Namespace。

• “*”表示应用到全部Namespace。

4.3Locality based loadbalancer

Istio 1.1 引入了负载均衡新特性：基于位置的负载均衡。这也是华为主导的新特性。目前是alpha特性，只支持服务网格全局的位置感知的负载均衡设置：

1. 基于位置权重的负载均衡设置（Locality-weighted load balancing）：

   Locality-weighted load balancing容许管理员基于流量来源及终止的位置信息控制流量的分发。例如能够设置从源位置{region}/{zone}/{sub-zone}的工做负载发出的流量转发到目的位置的endpoints负载均衡权重：用户能够为相同区域的工做负载访问设置较高的权重，为不一样区域的工做负载设置较小的权重，减小网络延迟。

2. 基于位置的故障转移设置：

   相似于Envoy的“Zone aware routing”负载均衡策略，基于位置的故障转移特性，经过为不一样的位置的endpoints设置不一样的优先级，控制流量的转发策略。默认设置以下，同一位置{region}/{zone}/{sub-zone}的endpoints优先级最高，同一{region}/{zone}的endpoints优先级次之，同一region的endpoints第三，最后故障转移设置区域以及其余区域的endpoints依次。endpoints所有健康的状况下，流量只会在同一{region}/{zone}/{sub-zone}转发。当endpoint变得不健康时，会进行相应的降级处理，选择低优先级的endpoints转发。

4.4pilot配置资源发现

Istio1.1将galley做为默认的 配置规则发现中心，pilot经过MCP协议与galley进行配置订阅，取代1.0之前直接从Kubernetes以CR的方式watch配置资源。

 

5策略和遥测

 

1. 默认关闭策略检查功能 为了提升多数客户场景下的性能，安装时默认关闭策略检查， 后期可按需开启此功能。

2. 弃用ServiceGraph，推荐使用 Kiali：提供了更丰富的可视化体验。

3. 多方面下降开销 ，提高性能和可扩展性：

   o 减小Envoy生成的统计数据的默认收集

   o Mixer的工做负载增长load-shedding功能

   o 改进Envoy和Mixer的通讯协议

4. 控制请求头和路由 增长选项使适配器能够修改请求头和路由

5. 进程外适配器 进程外适配器功能生产可用，下个release弃用进程内适配器。

6. 多方面加强Tracing的能力： 

   o Trace id支持128bit的范围

   o 支持向LightStep发送追踪数据

   o 增长选项彻底禁用Mixer支持的服务的追踪功能

   o 增长策略的decision-aware 追踪

7. 默认的TCP指标 为追踪TCP链接增长默认指标

8. 下降Addon对Load Balancer的依赖 再也不经过独立的load balancers对外暴露addons，而是经过Istio gateway来暴露插件服务。

9. 安全的Addon证书 改变插件的证书存储方式。Grafana, Kiali, and Jaeger的用户名和密码存放在kubernetes的secrets中以提升安全性和合规性。

10. 去除内置的statsd collector。Istio目前支持用户本身的statsd，以提升现有Kubernetes部署的灵活性。

另外，Istio运维管理的复杂度也不能被部分用户接受（好比：众多的crd资源），所以社区专门成立了User Experience工做组致力于提升Istio的易用性，进一步下降其使用门槛。

通过你们的共同努力，Istio1.1版本几经推迟终于发布了！咱们有理由对其充满期待和信心，共同催熟以Istio为表明的云原生服务网格技术，为咱们的用户提供高品质的云服务体验。

欢迎试用华为云应用服务网格Istio。

 

 

​相关服务请访问： https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019