Istio入门学习笔记
起源
设计目标
作为一款 Service Mesh 模式的实现，Istio 最根本的设计目标就是实现 Service Mesh 的设计构想：
- 将“应用程序”与“网络”解藕: 将服务之间、服务与集群外部的网络通讯和安全机制从微服务的业务逻辑中解藕，并作为一个与平台无关的、独立运行的程序，以减少开发和运维人员的工作量。
- 保障网络环节: 应用程序的目标是“将某些东西从A传送到B”，而 Service Mesh 所要做的就是实现这个目标，并处理传送过程中可能出现的任何故障。
- 提供应用层面的可见性和可控性: 通过每个微服务中的 Sidecar ，Service Mesh 得以将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一个独立部分——它不再是单纯的基础设施，更可以被监控、托管和控制。
除此之外，Istio 还有着其他更加关键的设计目标，这些目标对于使系统能够应对大规模流量和高性能地服务处理至关重要。
- 最大化透明度( 与“解藕”类似，但具体到基于 Pod 实现 ): Istio 使用 Sidecar 代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。注入 sidecar 代理到 pod 中并且修改路由规则后，Istio 就能够调解所有流量。
- 增量扩容策略: 扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。
- 可移植性: Istio 必须能够以最少的代价运行在任何云或预置环境中。将基于 Istio 的服务移植到新环境应该是轻而易举的，而使用 Istio 将一个服务同时部署到多个环境中也是可行的（例如，在多个云上进行冗余部署）。
- 策略一致性: 在服务间的 API 调用中，策略的应用使得可以对网格间行为进行全面的控制，但对于无需在 API 级别表达的资源来说，对资源应用策略也同样重要。策略系统作为独特的服务来维护，具有自己的 API，而不是将其放到代理或 Sidecar 中，这容许服务根据需要直接与其集成。
核心功能
istio的核心功能有以下五点
- 流量管理：Istio通过Pilot所提供的API动态配置所有的Pod中的Sidecar的路由规则，进而控制服务间的流量和API调用。Istio简化了断路器、超时重试等服务级别的属性和配置，并且可以轻松设置A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。
- 安全：Istio提供给开发人员应用程序级别的安全性。Istio底层安全通信通道，病大规模管理服务通信的认证、授权和加密。使用Istio，服务通信在默认情况下是安全的，它允许跨多种协议和运行时一致地实施策略-所有这些很少或根本不需要应用程序更改。将Istio、与Kubernetes的网络结合使用，优势会更大，包括在网络和应用层保护Pod间或服务间的通信能力。
- 可观察性：Istio的Mixer组件负责控制和遥测手机。通过Istio的监控功能，可以了解服务性能如何影响上下游的功能；其中第一仪表盘可以提供对所有服务性能的优化，从而了解性能如何影响其他进程。
- 平台独立：Istio 是独立于平台的，旨在运行在各种环境中，包括跨云、内部部署、Kubernetes、Mesos 等。您可以在 Kubernetes 上部署 Istio 或具有 Consul 的 Nomad 上部署。
- 集成和定制: 策略执行组件可以扩展和定制，以便与现有的 ACL、日志、监控、配额、审计等方案集成。
实现原理
架构
Istio的架构在逻辑上分为控制面和数据面。
数据面：由一组sidecar构成。这些sidecar可以调节控制微服务即Mixer之间所有网络通信。
控制面：负责管理和配置代理路由流量。此外，控制面通过Mixer来实施策略和收集各个Sidecar的遥测数据。
每个部分作用
sidecar
在Istio中默认的Sidecar是Envoy。
Envoy是C++开发的Sidecar ( 在 Istio 中，默认的 Sidecar 是 Envoy )
Envoy 是使用 C++ 开发的高性能代理，用于调解服务网格中所有服务的入站和出站流量。在 Istio 中，Envoy 被用于 Sidecar ，和对应的应用服务部署在同一个 Kubernetes 的 Pod 中。
Envoy 调解所有出入应用服务的流量。所有经过 Envoy 的流量行为都会调用 Mixer，为Mixer 提供一组描述请求和请求周围环境的 Attribute 。根据 Envoy 的配置和 Attribute，Mixer 会调用各种后台的基础设施资源。而这些 Attribute 又可以在 Mixer 中用于决策使用何种策略，并发送给监控系统，以提供整个网格行为的信息。
Envoy sidecar逻辑上在每次请求前调用Mixer以执行先决条件检查，在每次请求后调用Mixer以报告遥测数据。sidecar具有本地缓存，因此可以从缓存执行很大比例的先决条件检查，此外，sidecar缓冲出站遥测数据，因此它也只是低频率地调用Mixer
Pilot
Polit为sidecar提供服务发现功能，并管理高级路由（如A/B测试和金丝雀部署）和故障处理（超时、重试、熔断器等）的流量。Pilot讲这些高级的流量行为转换为详尽的Sidecar即Envoy配置项，并在运行时将它们配置到Sidecar中。
Pilot将服务发现机制提炼为供数据面使用的API，即任何Sidecar都可以使用标准的格式。这种松耦合的设计模式使Istio能在多种环境（Kubernetes、Consul和Nomad）下运行，同时保持用于流量管理操作的相同。
Mixer
Mixer是一个独立于平台的组件，通过Sidecar和一些其他服务处收集数据，进而在整个Service Mesh上控制访问和执行策略。Sidecar请求级别的Attribute被发送到Mixer进行评估。
Mixer中还包括一个灵活的插件，使其能介入各种主机环境和基础设施的后段，并得到Sidecar代理和Istio所管理的服务。
Mixer的设计还有以下夜店
- 无状态：Mixer 本身是无状态的，它没有持久化存储的管理功能。
- 高可用：Mixer 被设计成高度可用的组件，任何单独的 Mixer 实例实现 > 99.999% 的正常运行时间
- 缓存和缓冲：Mixer 能够积累大量短暂的瞬间状态
- Citadel
Citadel 通过内置身份和凭证管理提供“服务间”和“最终用户”身份验证。Citadel 可用于升级服务网格中未加密的流量，并能够为运维人员提供基于服务标识( 如 Kubernetes 中 Pod 的标签或版本号 )而不是网络层的强制执行策略
Mixer是负责提供遥控和遥测统计的Istio组件，具体实现如下几个功能。
- 调用前置检查：Envoy将请求透传给下游服务前，会通过调用Mixer判断该请求是否满足一定的前置条件，具体比如黑名单检查，访问权限校验等。
- 配额检查：配额检查调用时机和前置检查类似，由Envoy调用下游服务前调用Mixer进行检查，不同的是配额检查聚焦资源的管理，以实现对资源的有效管理，具体比如限流、连接数检查等。
- 统计观测信息上报：服务处理完请求后，Envoy将请求相关的统计信息上报到Mixer，Mixer及其Mixer相关的基础设施，会基于上报数据进行监控、性能分析等，也可以基于对数据的精细化分析，产生相应的策略对链路进行管控，具体的上报信息包含Log、Metric和Trace等。
与Envoy的关系
Istio与容器平台的关系（以k8s为例）
从设计上来说，Istio是平台无关的，它可以再许多容器管理平台上部署。但是当Istio与K8s共同使用时，它的能力将得到最大化应用。
比如，Istio 可以通过 yaml ( Istio 有提供 yaml )的形式快速在 K8s 上部署；其服务注册机制由 K8s 提供，而服务发现由 Istio 中的 Pilot 负责。
综上所述，在 Kubernetes 上使用 Istio 是非常合适的，具体四种 Service Mesh 的各种功能特性对比见 下文。
部分功能的工作流程
流量管理及请求路由
将流量从应用程序中解耦，使得Istio能提供各种流量管理的功能，例如：动态路由（负载均衡，A/B测试，金丝雀部署）、故障处理（超时，重试，熔断，故障恢复）以及故障注入（测试服务之间的故障恢复策略的兼容性）。这些都是通过Pilot与Sidecar共同协作完成的。
(上图：Pilot的构成及其与Sidecar协同工作的原理)
由上图可以看出，一个Pilot主要由平台适配器、抽象模型、用于配置和调用Envoy的Envoy API和用于用户指定流量管理的Rules API所组成。
Sidecar的服务发现及传输机制，主要遵循以下流程：
- 平台适配器（Platform Adapter）从Kubernetes API server中获取Pod的注册信息。（注意Istio本身并不具备服务注册的功能，它需要通过平台适配器和特定平台结合才能具有完整的服务发现的功能。）
- 用户通过Pilot的Rules API对所有被发现的服务的Sidecar进行各种高级特性（包括路由规则、HTTP层的流量管理）的配置
- 用户配置的这些规则被抽象模型翻译成低级配置。
- SidecarAPI及EnvoyAPI讲这些翻译好的低级配置通过discovery API分发到每个微服务上的Sidecar（即Envoy）实例中
服务间通讯
运维人员可以用Pilot指定路由规则，而Envoy根据这些规划动态地确定其服务版本的实际选择。Envoy拦截并转发客户端和服务器之间的所有请求和响应。路由规则让Envoy能够根据诸如header、source、destination或分配给每个版本的权重标准来进行版本选择。
Service A访问不同版本的Service B的工作流如下：
- 运维人员通过Polit的Rules API根据destination的相关标签配置分配流规则
- Service A运行时，其Envoy的配置规则更新
- Service A根据新配置的规则访问带有不同标签的Service B的版本
集群出入站规则
Istio默认进入和离开网络的所有流量都会通过Envoy进行传输。通过Envoy将流量路由到外部Web服务（例如访问MapsAPI或视频服务API）的方式，运维人员可以为这些服务添加超时控制、重试、熔断器等功能；还能从服务连接中获得各种细节指标。
流程如下
- 通过K8s的准入控制，外部流量进入Istio
- 流量与Serve A和Service B的Envoy交互，并有Envoy获取服务具体相应内容
- 流量通过Egress getway或直接流出的方式流出Istio
服务发现和负载均衡
Istio 的服务注册功能是基于平台来实现的。Istio 默认存在用于跟踪 Pod 的服务注册表，而且还默认新的服务自动注册，不健康的服务被自动删除。目前，Kubernetes、Mesos 等平台已经为基于容器的应用程序提供了这样的功能。
Pilot使用服务注册的信息，并提供平台无关的discovery API。网格中的Envoy提供服务发现功能，并相应更新负载均衡池。
运行过程：
- 每个微服务的Pod通过K8s提供的服务注册机制进行注册
- 已注册的Service A的Envoy通过Pilot中汇总的Envoy信息发现要访问的Service B
- serviceA的Envoy根据设置好的负载均衡或流量管理策略，对Service B的Envoy发起请求
- Service B的Envoy根据设置好的规则确认是否接受serviceA发出的请求
Attribute与服务监控
Attribute是Istio策略与遥控功能中的基本概念。Attribute是一小段数据，用于描述服务请求的一系列属性（例如特定请求的大小、相应操作码、请求来自IP）；通过Attribute，我们就可以熟悉服务的方方面面。
Mixer是Istio中用于实现策略和遥测功能的组件，其本质上是一个Attribute处理机。每个经过Sidecar的请求都会调用Mixer为Mixer提供有一组请求及其周围环境的Attribute。基于Envoy的配置和响应的Attribute，Mixer会调用各种基础设施后端。
遥测功能的信息汇总流程如下
- Envoy通过调用将Attribute 传递给Mixer
- Mixer得到Envoy的Attribute ，并根据Attribute 调用各种后端资源
- 同时Mixer可以汇总所有的Envoy的Attribute ，用于集群范围的监控以及运维人员提供客观测性
位于网格中的每个服务实例旁边的Sidecar代理必须在内存方面消耗方面节约，折现值了本地缓存的可能数量。然而Mixer独立运行，可以使用相当的大的缓存和输出缓冲区。因此，Mixer可作用Sidecar的高度扩展且高度可用的二级存储。
Istio安全
安全基础
认证和授权
在展开讨论Istio安全之前，先看一下通信安全方面两个最基本的概念：认证（authenti-cation）与授权。认证解决的是身份确认的问题，认证过程类似于身份证验证的过程；授权解决的是权限管理的问题，只有拥有相应的权限才能进行权限对应的操作。
以一个典型的知识论坛为例，使用论坛进行各种操作前都必须进行登录，登录就是一个身份确认的过程。用户在注册时，论坛会给每个用户分配一个唯一的标识，用于标识该用户的身份，用户后续在论坛上的所有操作均需要带着这个标识。登录完成后，不同的身份对应不同的权限，比如普通用户有发帖的权限，管理员用户有删帖的权限，因此登录操作是一个认证的过程，在发帖或删帖时确认是否有权限是一个授权的过程，其中认证是授权的基础，授权建立在身份标识的基础上进行。
身份
身份（identity）是通信安全的基础，安全认证和授权过程中需要用到。Kubernetes、GCE和AWS等平台上均已经有自己的身份体系，Istio身份模型架构层面非常开放，直接复用这些业界主流云平台的账号体系，也支持用户自定义服务账户。
SPIFFE
SPIFFE（Secure Production Identity Framework For Everyone，通用安全身份框架）是
一套用于服务之间进行身份识别的标准，主要包含以下内容。
1）SPIFFE ID标准：SPIFFE ID是服务的唯一标识，实现为URI。
2）SVID（SPIFFE Verifiable Identity Document）标准：将SPIFFE ID编码到一个加密
的可验证文档中。
3）SVID API：颁发/撤销SVID的一套API标准。
SPIFFE SVID目前支持的实现方式是X.509数字证书，在X.509 SVID中，采用X.509数
字证书的SAN（Subject Alternative Name）扩展字段来保存SPIFFE ID。
当前Istio已支持SPIFFE标准，可以为Istio网络中的服务颁发符合SPIFFE SVID标准的
证书，基于这些证书进行身份认证、RBAC授权等相关工作。
Istio的认证类型
Istio支持基于用户维度和服务维度俩种认证方式，基于用户的认证是对请求中断用户进行验证，具体可以通过JWT（Json Web Token）Google Auth和自定义身份认证等方式进行；基于服务维度的认证采用双向TLS的方式，为每个服务提供强大的身份认证能力，通过用户和服务层面的认证，全面保证用户到服务、服务到服务之间通信的安全性。
认证架构
Istio数据平面代理节点之间通过加密机制进行安全通信，为了保障安全通信的有效进行，通信双方需要通过认证机制来确认相互的身份信息，因此需要一套完善的认证架构来保证认证的可靠、高效运行，具体包括证书管理、证书验证、证书传递等，
Istio当前针对每个K8s节点部署一个Node Agentdialing服务用于代理本节点上的Envoy和证书服务器之间的证书获取，定期进行证书和密钥的获取和轮换。完整的证书获取流程大体如下。
1）Citadel创建一个gRPC服务来接受CSR请求。
2）Envoy通过Envoy secret发现服务（SDS）API发送证书和密钥请求。
3）Node Agent代理服务收到SDS请求后，节点代理会创建私钥和CSR，并将CSR及其凭据发送给Citadel进行签名。
4）Citadel验证CSR中携带的凭证，并签署CSR以生成证书。
5）节点代理通过Envoy SDS API将从Citadel接收的证书和私钥发送给Envoy。
Istio配置处理框架
为了减少Istio内部各个组件配置处理方面的重复工作，提高配置管理方面的效率，Istio抽象出来一个独立的子项目Galley，专门负责配置管理方面的工作，定位是将其他组件从配置管理的复杂性中解放出来.
Istio1.1版本之前，Galley进负责配置验证工作，Istio1.1版本之后，Grally省纪委istio整个控制平面的配置中心，不仅负责配置资源的验证，还负责配置的获取、处理和分发。
从图中可以看出，Galley充当了一个代理的角色，对配置变更订阅者屏蔽不同平台、不同环境下配置源的差异和使用细节，通过统一的MCP协议和配置变更订阅方进行交互，订阅者只需要指定当前关系的配置源和响应配置，配置源的配置发生变更时，Galley会接管配置处理的细节，将最新配置通过MCP协议同步给订阅方。
配置验证
Galley配置验证的目的是验证Istio核心配置的有效性。基于Kubernetes的ValidatingAdmision Webhook机制，Galley向Kubernetes注册Validating Admision Webhook插件，具体包括关注的资源信息以及Galley的地址，Galley启动后会创建HTTP服务器，然后等待Kubernetes API Server发过来的配置验证请求
配置变更处理和分发
网格配置协议（Mesh Configuration Protocol，MCP）是一个基于订阅的配置分发协议，参考XDS协议的思想构建而成，用于Galley配置订阅方和配置提供方之间的配置交互。
MCP定义了一套完整的配置分发协议，具体包括配置提供方Source、配置订阅方Sink和配置资源本身，当配置提供方和订阅方建立订阅关系后，Galley负责检测配置资源变化，然后按照MCP协议的语义将变更后的配置发送给订阅方
主流service mesh对比
优势：
- 使用 Sidecar 模式开发，便于流量控制和监测及安全机制
- 与 K8s 完美兼容
- 使用高性能的 Go 语言开发
- 支持多种高级快速的网络协议
- Sidecar 默认 Envoy 并自动注入
- 容错机制完善
- 集成了用于监测的可视化界面
- Jaeger 作为跟踪机制集成
- 具备权限认证功能
- Sidecar 代理具有缓存功能
- 完全免费
- 文档和技术博客数量远多于其他 3 种 Service Mesh
劣势：
- 复杂度高，技术门槛和学习成本高
- 目前 Istio 不支持集群内外通信的安全连接
Istio与K8s的相互关系
Kubernetes当前通过Kube Proxy只能提供基本的通信能力，对于精细粒度的集群管理、流量调度、服务发现、负载均衡等，还需要业务服务自己解决。
Kubernetes的定位是服务调度和服务生命周期管理，微服务通信本身不属于Kubernetes的重点支持范畴。为了减少微服务上云的复杂度，同时为了实现Kubernetes上微服务的标准化，需要有一套完善的基础设施，系统地解决微服务的通信问题，Istio正是解决Kubernetes集群的通信标准化问题，提供业务透明的通信解决方案。
Kubernetes提供的强大的基础设施，为Istio的运维提供了很大的帮助，Service Mesh之前很长时间内没有流行起来，其根本原因是运维复杂度偏高，导致Service Mesh使用起来难度很大。基于Kubernetes提供的云化基础设施，有力地推动了Service Mesh的快速发展和落地。
istio还支持Kubernetes、Mesos、Cloud Foundry等众多云平台