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

Posted 2021-02-16

本文整理自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