Istio学习笔记
术语服务网格（Service Mesh）用于描述微服务之间的网络，以及通过此网络进行的服务之间的交互。随着服务数量和复杂度的增加，服务网格将变的难以理解和管理。
对服务网格的需求包括：服务发现、负载均衡、故障恢复、指标和监控，以及A/B测试、金丝雀发布、限速、访问控制、端对端身份验证等。
使用云平台为DevOps团队带来了额外的约束，为了Portability开发人员通常需要使用微服务架构，运维人员则需要管理非常多数量的服务。Istio能够连接、保护、控制、观察这些微服务。
Istio是运行于分布式应用程序之上的透明（无代码入侵）服务网格，它同时也是一个平台，提供集成到其它日志、监控、策略系统的接口。
Istio的实现原理是，为每个微服务部署一个Sidecar，代理微服务之间的所有网络通信。在此基础上你可以通过Istio的控制平面实现：
- 针对HTTP、gRPC、WebSocket、TCP流量的负载均衡
- 细粒度的流量控制行为，包括路由、重试、故障转移、故障注入（fault injection）
- 可拔插的策略层+配置API，实现访问控制、限速、配额
- 自动收集指标、日志，跟踪集群内所有流量，包括Ingress/Egress
- 基于强身份认证和授权来保护服务之间的通信
使用Istio你可以很容易的通过配置，对流量和API调用进行控制。服务级别的可配置属性包括断路器（circuit breakers）、超时、重试。
Istio支持基于流量百分比切分的A/B测试、金丝雀滚动发布、分阶段滚动发布。
可以提供安全信道，管理身份验证和授权，加密通信流量。
联用K8S的网络策略可以获得更多益处，例如保护Pod-to-Pod之间的通信。
Istio强壮的跟踪、监控、日志能力，让服务网格内部结构更容易观察 —— 一个服务的性能对上下游的影响可以直观的展现在仪表盘上。
Istio的Mixer组件——通用的策略和监控（Telemetry）Hub负责策略控制、指标收集。Mixer提供基础设施后端的隔离层，Istio的其它部分不需要关注后端细节。
Istio当前支持：
- Kubernetes上的Service
- 通过Consul注册的服务
- 在独立虚拟机上运行的服务
从整体上看，Istio的服务网格由数据平面、控制平面两部分组成：
- 数据平面由一系列作为Sidecar部署的智能代理（Envoy）构成。这些代理联合Mixer，中介、控制所有微服务之间的网络通信
- 控制平面负责管理、配置智能代理，实现流量路由，配置Mixers来应用策略、收集指标
架构图：
Istio使用一个扩展过的Envoy版本。Envoy是基于C++开发的高性能代理，Istio使用它的以下特性：
- 动态服务发现
- 负载均衡
- TLS termination
- HTTP/2和gRPC代理
- 断路器
- 健康检查
- 分阶段（基于流量百分比）发布
- 故障注入
- 丰富的监控指标
Envoy在目标服务的相同Pod中，以Sidecar形式部署。
一个平台无关的组件：
- 为服务网格应用访问控制和访问策略
- 从Envoy和其它服务中收集指标
- Envoy收集的请求级别的属性，被发送到Mixer进行分析
Mixer提供了一个灵活的插件模型，让Istio能够灵活的和多种宿主机环境、基础设施后端进行对接。
- 为Envoy提供服务发现
- 为智能路由（AB测试、金丝雀部署……）提供流量管理能力
- 提供弹性（resiliency）——超时、重试、断路器等
Pilot将高级别的路由规则转换为Envoy理解的配置信息，并在运行时将这些配置传播到Sidecars。
Pilot将平台相关的服务发现机制抽象为标准的（Envoy data plane API）格式，这让Istio可以在K8S、Consul、Nomad等多种环境下运行。
提供服务-服务、终端用户的身份验证功能，可以加密服务网格中的流量。
Istio的流量管理模型，从根本上将流量（traffic flow）和基础设施扩容进行了解耦。通过Pilot，你可以通过更细致的规则来说明流量如何流动，而不是简单的指定哪个VM/Pod来接收流量。例如，你可以指定某个服务的5%的流量发往金丝雀版本（不管金丝雀的实例数量），或者指定根据请求内容来选择特定版本的服务：
将流量（traffic flow）和基础设施扩容解耦后，Istio可以在应用程序代码外部提供大量的流量管理特性，包括AB测试的请求路由、逐步发布、金丝雀发布，基于超时、重试、断路器的故障恢复，以及为了测试故障恢复策略而进行的故障注入（fault injection）。
流量管理的核心组件是Pilot，它管理、配置所有部署在服务网格中的Envoy代理实例，对Envoy的完整生命周期负责。Pilot除了可以配置路由规则、配置故障恢复特性之外，还维护网格中所有服务的规范（canonical）模型。Envoy就是基于此模型，通过自己的发现服务，找到网格中其它Envoy。
每个Envoy实例都基于从Pilot得到的信息、以及针对负载均衡池中的实例进行周期性的健康检查，来维护负载均衡信息。根据此负载均衡信息，Envoy能够在遵守路由规则的同时，智能的在目的实例之间分发请求。
规范模型是独立于底层平台的，和底层平台的对接由Pilot中的适配器负责，适配器调用底层平台的API（例如K8S适配器实现了必要的控制器来Watch API Server，获取Pod、Ingress等资源的变动），并产生适当的规范模型。
Envoy特定的配置文件根据规范模型生成。
如上文所述，网格中服务的规范模型由Pilot维护。Istio还引入了服务版本的概念，用于对服务实例进行细粒度区分。服务版本既可以指服务API的版本（v1,v2），也可以指服务运行环境（stg,pdt）或任何其它属性。
在上图中，服务的客户端对服务的不同版本毫无感知。客户端仍然使用服务的IP或主机名来访问，只是Envoy在客户端-服务器之间拦截并转发了请求和响应。
Envoy根据你通过Pilot指定的路由规则，决定实际使用的服务版本。这让应用程序代码和被依赖服务之间实现解耦，可分别独立演化。在路由规则中，你可以指定让Envoy依据源/目标的消息头、Tag来判定服务版本。
Istio假设服务网格的所有出入流量都经由Envoy代理转发。通过这种前置代理可以实现面向用户的服务，包括AB测试、金丝雀部署。在访问外部服务时，Envoy可以实现必要的故障恢复特性，包括超时、重试，并获取外部服务的性能指标。
Istio能够在网格中服务实例之间进行负载均衡。
Leave a Reply