Istio
https://zhuanlan.zhihu.com/p/54123996
Istio 的设计目标
从设计上来说，Istio 是平台无关的，它可以在许多容器管理平台上部署。但是当 Istio 与 Kubernetes 共同使用时，它的能力将得到最大化应用。
Istio 可以通过 yaml ( Istio 有提供 yaml )的形式快速在 K8s 上部署；其服务注册机制由 K8s 提供，而服务发现由 Istio 中的 Pilot 负责。
作为一款 Service Mesh 模式的实现，Istio 最根本的设计目标就是实现 Service Mesh 的设计构想：
- 将“应用程序”与“网络”解藕: 将服务之间、服务与集群外部的网络通讯和安全机制从微服务的业务逻辑中解藕，并作为一个与平台无关的、独立运行的程序，以减少开发和运维人员的工作量。
- 保障网络环节: 应用程序的目标是“将某些东西从A传送到B”，而 Service Mesh 所要做的就是实现这个目标，并处理传送过程中可能出现的任何故障。
- 提供应用层面的可见性和可控性: 通过每个微服务中的 Sidecar ，Service Mesh 得以将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一个独立部分——它不再是单纯的基础设施，更可以被监控、托管和控制。
- 最大化透明度( 与“解藕”类似，但具体到基于 Pod 实现 ): Istio 使用 Sidecar 代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。注入 sidecar 代理到 pod 中并且修改路由规则后，Istio 就能够调解所有流量。
- 增量扩容策略: 扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。
- 可移植性: Istio 必须能够以最少的代价运行在任何云或预置环境中。将基于 Istio 的服务移植到新环境应该是轻而易举的，而使用 Istio 将一个服务同时部署到多个环境中也是可行的（例如，在多个云上进行冗余部署）。
- 策略一致性: 在服务间的 API 调用中，策略的应用使得可以对网格间行为进行全面的控制，但对于无需在 API 级别表达的资源来说，对资源应用策略也同样重要。策略系统作为独特的服务来维护，具有自己的 API，而不是将其放到代理或 Sidecar 中，这容许服务根据需要直接与其集成。
Istio 的核心功能
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 的架构
- Istio 的架构在逻辑上分为“控制面”和“数据面”。
“数据面“：由一组 Sidecar 构成。这些 Sidecar 可以调节和控制微服务及 Mixer 之间所有的网络通信。
“控制面“：负责管理和配置代理路由流量。此外，控制面通过 Mixer 来实施策略和收集各个 Sidecar 的遥测数据。
Istio 架构中每个部分的作用
- Sidecar ( 在 Istio 中，默认的 Sidecar 是 Envoy )
Envoy 是使用 C++ 开发的高性能代理，用于调解服务网格中所有服务的入站和出站流量。在 Istio 中，Envoy 被用于 Sidecar ，和对应的应用服务部署在同一个 Kubernetes 的 Pod 中。
Envoy 调解所有出入应用服务的流量。所有经过 Envoy 的流量行为都会调用 Mixer，为Mixer 提供一组描述请求和请求周围环境的 Attribute 。根据 Envoy 的配置和 Attribute，Mixer 会调用各种后台的基础设施资源。而这些 Attribute 又可以在 Mixer 中用于决策使用何种策略，并发送给监控系统，以提供整个网格行为的信息。 - Pilot
Pilot 为 Sidecar 提供“服务发现”功能，并管理高级路由( 如 A/B 测试和金丝雀部署 )和故障处理( 超时、重试、熔断器等 )的流量。Pilot 将这些“高级”的流量行为转换为详尽的 Sidecar (即 Envoy) 配置项，并在运行时将它们配置到 Sidecar 中。
Pilot 将服务发现机制提炼为供数据面使用的 API ，即任何 Sidecar 都可以使用的标准格式。这种松耦合的设计模式使 Istio 能在多种环境( Kubernetes、Consul 和 Nomad )下运行，同时保持用于流量管理操作的相同。 - Mixer
Mixer 是一个独立于平台的组件，通过从 Sidecar 和一些其他服务处收集数据，进而在整个 Service Mesh 上控制访问和执行策略。Sidecar 请求级别的 Attribute 被发送到 Mixer 进行评估。( 关于 Attribute 的定西，详见下文 )
Mixer 中还包括一个灵活的插件，使其能接入各种主机环境和基础设施的后段，并得到 Sidecar 代理和 Istio 所管理的服务。
Mixer 的设计还具有以下特点：
- 无状态：Mixer 本身是无状态的，它没有持久化存储的管理功能。
- 高可用：Mixer 被设计成高度可用的组件，任何单独的 Mixer 实例实现 > 99.999% 的正常运行时间
- 缓存和缓冲：Mixer 能够积累大量短暂的瞬间状态
( 其能够作为 Envoy 的二级缓存，见 Attribute 与服务监控 )
- Citadel
Citadel 通过内置身份和凭证管理提供“服务间”和“最终用户”身份验证。Citadel 可用于升级服务网格中未加密的流量，并能够为运维人员提供基于服务标识( 如 Kubernetes 中 Pod 的标签或版本号 )而不是网络层的强制执行策略。