istio介绍和资料整理

一、istio是什么？Service Mesh又是什么？

Istio是⼀个Service Mesh形态的⽤于服务治理的开放平台。（治理的是服务间的访问）

istio介绍和资料整理

连接：Istio 通过集中配置的流量规则控制服务间的流量和调⽤，实现负载均衡、熔断、故障注⼊、重试、重定向等服务治理功能。

保护：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能⼒，可增强服务访问的安全性。

控制：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能⼒。

观测：动态获取服务运⾏数据和输出，提供强⼤的调⽤链、监控和调⽤⽇志收集输出的能⼒。配合可视化⼯具，可⽅便运维⼈员了解服务的运⾏状况，发现并解决问题。

Service Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。

在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。

主要有控制面和数据面组成，数据面截获不同服务之间的调用并对其进行“处理”；控制面协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。

istio介绍和资料整理

二、istio架构和主要功能

istio1.1架构图

istio介绍和资料整理

控制⾯主要包括Pilot、Mixer、Citadel等服务组件。

数据⾯由伴随每个应⽤程序部署的代理程序Envoy组成，执⾏针对应⽤程序的治理逻辑。

Pilot是为我们提供配置智能路由（如A/B测试、金丝雀发布等）、弹性（超时、重发、熔断等）等功能的管理系统，它提供了一系列rules api，允许运维人员指定一系列高级的流量管理规则。Pilot负责将我们的配置转换并写入到每个sidecar（Enovy）。

Mixer混合了各种策略以及后端数据采集或遥测系统的适配器，从而实现了前端Proxy与后端系统的隔离与汇合。Mixer是一个灵活的插件模型，它一端连着Envoy，同时我们可以将日志、监控、遥测等各种系统“插入”到Mixer的另一端中，从而得到我们想要的数据或结果。

Citadel管理着集群的**和证书，是集群的安全部门。

类别	功能	说明
流量管理	请求路由	A/B测试、金丝雀发布等，包括对集群出入口、及集群内部的流量的控制。比如某应用新版本发布，可以配置为5%的流量流向新版本，95%的给旧版本
	流量转移	与上一条请求路由类似，可以平滑的将流量从旧版本转移到新版本上
	负载均衡	目前支持3种方式，轮询、随机和带权重的最少请求
	服务发现	带心跳的健康检查，失败率超标的Pod移出负载均衡池
	故障处理	超时、重发、熔断、上游并发请求或下游连接数限制等
	微调	支持用特殊的请求头参数，覆盖默认的超时、重发值
	故障注入	由Enovy在正常的集群中人为注入故障，比如TCP包损坏或延迟、HTTP错误码等，支持按百分比注入，比如给10%的流向服务A的请求包增加5秒延迟
	多重匹配	上述规则的配置，支持按多种条件匹配，且支持and或or的方式匹配多条规则
	Gateway	接管集群入口的流量，替代了Ingress，从而对入口流量执行其他规则
	Service Entry	接管集群内部访问外部服务的流量，从而对出口流量执行一些规则
	镜像	支持将特定的流量镜像到服务路径之外，而不影响主服务路径的正常执行
安全	命名空间访问控制	支持配置某命名空间的所有或个别服务可以被其他命名空间访问
	服务级别访问控制	允许或禁止访问某个服务
	双向TLS	HTTPS加密传输
	其他安全策略
策略	速率限制	比如限制每秒的请求次数
	黑白名单	支持基于IP或属性的黑名单、白名单
遥测	日志收集	支持将Prometheus、Jaeger等系统插入Mixer，从而完成数据的采集
	指标采集
	分布式追踪

istio1.5的架构图

Istio 1.5.1 性能总结

Istio 负载测试网格包含了 1000 个服务和 2000 个 sidecar，全网格范围内，QPS 为 70,000。在使用 Istio 1.5.1 运行测试后，我们得到了如下结果：

通过代理的 QPS 有 1000 时，Envoy 使用了 0.5 vCPU 和 50 MB 内存。
网格总的 QPS 为 1000 时，istio-telemetry 服务使用了 0.6 vCPU。
Pilot 使用了 1 vCPU 和 1.5 GB 内存。
90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟。

三、Istio与Kubernetes

Kubernetes 的本质是应用的生命周期管理，具体来说就是部署和管理（扩缩容、自动恢复、发布）。
Kubernetes 为微服务提供了可扩展、高弹性的部署和管理平台。
Service Mesh 的基础是透明代理，通过 sidecar proxy 拦截到微服务间流量后再通过控制平面配置管理微服务的行为。
Service Mesh 将流量管理从 Kubernetes 中解耦，Service Mesh 内部的流量无需 kube-proxy 组件的支持，通过为更接近微服务应用层的抽象，管理服务间的流量、安全性和可观察性。
xDS 定义了 Service Mesh 配置的协议标准。
Service Mesh 是对 Kubernetes 中的 service 更上层的抽象，它的下一步是 serverless。

Istio复⽤了Kubernetes Service的定义，在实现上进⾏了更细粒度的控制。

Istio的服务发现就是从 Kube-apiserver中获取 Service和Endpoint，然后将其转换成 Istio服务模型的 Service 和ServiceInstance，但是其数据⾯组件不再是 Kube-proxy，⽽是在每个Pod ⾥部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理。

istio介绍和资料整理