关于Istio 1.1，你所不知道的细节

本文整理自Istio社区成员Star在

Cloud Native Days China 2019 北京站的现场分享

 

第1则

主角 Istio

Istio做为service mesh领域的明星项目，从2016年发布到如今热度不断攀升。

Istio & Envoy Github Star Growth

官网中Istio1.1的架构图除了数据面的Envoy和控制面的Pilot，Mixer，Citadel三大组件外，引入了Galley组件验证Istio API 的配置。

Istio能带来什么收益呢？

开发和运维过程当中咱们常常会碰到下面的问题：如何作到新版本的上线不影响现网业务的运行？若是访问系统的请求忽然增多，咱们的系统处理不了怎么办？若是系统出现问题，到底是哪一个服务的问题，服务之间的调用关系如何？业务程序员一般缺少安全相关的知识，能不能作到直接对没有加密的流量自动加密？针对这些问题，Istio都有相应的方案解决，对应于它的各个功能组件。

第2则

Istio 1.1大不一样

Istio 1.0的主题是生产可用，而1.1版本则是企业可用，强调1.1在大规模集群（不少服务和负载）下的性能和可靠性可以得以保障。

下表是Istio1.1和1.0在流量管理的特性状态的对比：

Istio 1.1版本的性能提高方面成果显著。

在应用性能上：

• 应用的平均时延降低 30%

• 在大规模集群中，服务启动速度提升 40%

在管理面组件资源占用率上：

• 大规模集群中，Pilot CPU使用降低 90%

• 大规模集群中，Pilot 内存使用降低 50%

Istio 1.1版本为提升性能贡献的重点优化项以下：

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

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

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

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

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

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

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

升级到Istio 1.1也很方便

1. 控制面板升级

• Kubernetes rolling update

• Helm 升级

2. 数据面升级

• 经过对全部的pods触发rolling update从新注入sidecar （例如：patching the grace termination period）

Istio1.1的多集群网格管理

新引入了多控制面方案和集群感知（Split Horizon EDS）的单控制面方案：

多控制平面方案

单控制平面（Split Horizon EDS）方案

关于服务可见性，刚才说到的大集群规模性能的提高很大一部分归功于服务可见性。主要由两部分结合起来使用：

• ExportTo字段

  服务端的Service/ServiceEntry/Virtualservice/Destinationrule 配置exportTo字段，申明此网络资源的可见范围。

• 新增sidecar资源对象

  请求端所在的namespace配置sidecar对象，能够精确控制sidecar转发到指定的namespace或service。

安全特性方面比较关心的一项是SDS（Secret Discovery Service）：

• 提供更强的安全性：

  经过节点密钥生成，私钥仅存在于 Citadel 和 Envoy Sidecar 的内存中。

• 不依赖 Kubernetes Secret

  不须要挂载Secret 卷。

• 证书替换不须要重启 Envoy

  Sidecar 可以利用 SDS API 动态刷新密钥和证书。

Istio 1.1的命令行工具Istioctl增长了离线校验命令和验证安装命令，Istioctl弃用create、replace、get 和 delete使用 kubectl 代替，同时支持kubectl操做Istio网络资源时使用缩写。

Istio社区成立了用户体验工做组，专门致力于提升Istio的易用性，进一步下降使用门槛。

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