什么是Istio?

在企业普遍都做云平台的时代背景下，云平台架构带来的诸多好处，但是，不可否认的是，采用云技术架构会对DevOps团队造成很大的压力。 开发人员也必须使用微服务来构建可移植性，同时各大运营商正在管理超大型混合和多云部署。而Istio使得您可以连接，安全，控制和监控这些服务。

从更高的维度来看，Istio有助于降低部署的复杂性，减轻开发团队的负担。Istio是一个完全开源的服务网格（service mesh），可以透明地分层到现有的分布式应用程序上。同时，它也是一个平台，通过其提供的API，可将其集成到任何日志平台，telemetry或策略系统中。

Istio的多样化功能集使您能够高效地运行分布式微服务架构，并提供统一的方式来保护，连接和监视微服务。

什么是服务网格（serivce mesh）？

当整体应用程序向分布式微服务架构过渡时，Istio解决了开发人员和运营商面临的挑战。

服务网格术语用于描述组成此类应用程序的微服务网络及其之间的交互。随着服务网格的大小和复杂性的增长，它变得越来越难以理解和管理。它的要求可以包括发现，负载平衡，故障恢复，指标和监控。服务网格通常还具有更复杂的操作要求，例如A/B测试，金丝雀，网速限制，访问控制和端到端的身份验证。

Istio提供了整个服务网格上的行为洞察力和操作控制，从而提供了完整的解决方案来满足微服务应用程序的各种需求。

为什么使用Istio？

Istio可以轻松在已部署服务网络上创建带有负载平衡，服务到服务的身份验证，监控等功能，并且服务代码中的代码无需变动（或变动很少）。通过在整个环境中部署一个特殊的sidecar代理来拦截微服务之间的所有网络通信，然后使用其平台控制功能配置和管理Istio，包括：

• 自动为HTTP，gRPC，WebSocket和TCP流量负载平衡。
• 通过丰富的路由规则，重试，故障转移和故障注入对流量行为进行细粒度控制。
• 可插拔的策略层和配置API，支持访问控制，速率限制和配额。
• 集群内所有流量的自动度量，日志和跟踪，包括集群的入口和出口。
• 通过强大的基于身份的身份验证和授权，在集群中进行安全的服务之间通信。

Istio专为可扩展性而设计，可满足多种部署需求。

核心功能

Istio在服务网络中统一提供了许多关键功能：

流量管理

Istio规则配置和流量路由使您可以很容易的控制服务之间的流量和API调用的流量。Istio简化了诸如断路器，超时和重试之类的服务级别属性的配置，并使其轻而易举地设置重要任务，如A/B测试，金丝雀部署和基于百分比的流量拆分。

借助对流量的更好可见性和开箱即用的故障恢复功能，无论遇到什么情况，您都可以在问题引起故障之前及时发现问题，使得调用更加可靠，网络也更加强大。

安全

Istio的安全功能使开发人员可以将精力集中在应用程序级别。Istio提供基础安全通信通道，并大规模管理服务通信的身份验证，授权和加密。 借助Istio，默认情况下可以保护服务通信的安全，从而使您能够在各种协议和运行时之间一致地执行策略 - 所有这些操作几乎不需要更改应用程序。

虽然Istio是独立于平台的，但将其与Kubernetes（或基础架构）网络策略配合使用，则好处更大，包括能够在网络和应用程序层保护Pod到Pod或服务到服务的通信的能力。

可观察性(Observability)

Istio强大的跟踪，监控和日志记录功能使您可以深入了解服务网格部署。借助Istio的监视功能，您可以真正了解服务性能如何影响上游和下游事物，而其自定义dashboards（仪表盘）则可以提供对所有服务性能的可视性，并让您了解该性能如何影响您的其他的程序的。

Istio的Mixer组件负责策略控制和遥测(telemetry)采集。它提供了后端抽象和中介，使Istio的其余部分与各个基础架构后端的实现细节隔离开来，并为操作员提供了对网格和基础架构后端之间所有交互的精细控制。

所有这些功能使您可以更有效地设置，监控和执行服务上的SLO。当然，最重要的是您可以快速有效地检测和修复故障。

平台支持

Istio是独立于平台的，旨在在多种环境中运行，包括跨Cloud，本地，Kubernetes，Mesos等的环境。您可以在Kubernetes或Consul的Nomad上部署Istio。Istio当前支持：

• Kubernetes上部署Service
• 向Consul注册Services
• 在单个虚拟机上运行Services

集成和自定义

Istio的策略执行组件可以扩展和自定义，以与现有的ACL，日志记录，监视，配额，审核等集成。

架构

Istio服务网格在逻辑上分为数据平面和控制平面。

• 数据plane由部署为sidecar的一组智能代理（Envoy）组成。这些代理中介和控制微服务与Mixer、通用策略和遥测集线器之间的所有网络通信。

• 控制平面管理并将代理配置为路由流量。另外，控制平面配置Mixers来执行策略和采集遥测数据。

下图显示了组成每个平面的不同组件:

Envoy

Istio使用Envoy代理的扩展版本。Envoy是使用C++开发的高性能代理，可为服务网格中的所有服务调解所有入站和出站流量。Istio利用Envoy的许多内置功能，如：

• 动态服务发现
• 负载均衡
• TLS termination
• HTTP/2和gRPC代理
• 熔断（Circuit breakers）
• 健康检查
• 分阶段推出，按百分比分配流量
• 故障注入
• 丰富的指标

Sidecar代理模型还允许你将Istio功能添加到现有部署中，而无需重新构造或重写代码。你可以阅读更多关于为什么我们在设计目标中选择这种方法的信息。

Mixer

Mixer是一个与平台无关的组件。Mixer跨服务网格实施访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。 代理提取请求级别属性，并将其发送到Mixer进行评估。您可以在我们的“Mixer配置”文档中找到有关此属性提取和策略评估的更多信息。

Mixer包含一个灵活的插件模型。该模型使Istio可以与各种主机环境和基础架构后端交互。因此，Istio从这些细节中抽象了Envoy代理和Istio管理的服务。

Pilot

Pilot提供了Envoy sidecar的服务发现，智能路由的流量管理功能（例如 A/B测试，金丝雀等）和弹性（超时，重试，断路器等）。

Pilot将控制流量行为的高级路由规则转换为Envoy特定的配置，并在运行时将其传送到sidecar。Pilot提取了特定于平台的服务发现机制，并将它们合成为标准格式，任何符合Envoy数据平面API的Sidecar都可以使用。这种松散的耦合使得Istio可以在Kubernetes，Consul或Nomad等多种环境中运行，同时为流量管理保留相同的操作员界面。

Citadel

Citadel通过内置的身份和凭据管理实现了强大的服务到服务和终端用户的身份验证。可以使用Citadel来升级服务网格中的未加密流量。使用Citadel，运营商可以基于服务身份而不是相对不稳定的3层或4层网络识别码来实施策略。从版本0.5开始，您可以使用Istio的授权功能来控制谁可以访问您的服务。

Galley

Galley是Istio的配置验证，提取，处理和分发组件。它负责将其余Istio组件与从底层平台（例如Kubernetes）获取用户配置的细节隔离开来。

• 最大化透明度：要采用Istio，要求操作员或开发人员进行尽可能少的工作，以从系统中获得真正的价值。为此，Istio可以自动将其自身插入服务之间的所有网络路径中。Istio使用Sidecar代理来捕获流量，并在可能的情况下自动对网络层进行编程，以通过这些代理路由流量，而无需更改已部署的应用程序代码。 在Kubernetes中，代理被注入到Pod中，并通过对iptables规则进行编程来捕获流量。 一旦注入了sidecar代理并且对流量路由进行了编程，Istio就可以调解所有流量。此原则也适用于性能。将Istio应用于部署时，运营商会发现所提供功能的资源成本增加最小。组件和API必须在设计时充分考虑性能和规模。

• 可扩展性：随着运营商和开发人员越来越依赖Istio提供的功能，系统也必须随着他们的需求而增长。在我们继续添加新功能的同时，最大的需求是扩展策略系统，与其他策略和控制源集成以及将有关网格行为的信号传送到的其他系统以进行分析。策略运行时支持插入其他服务的标准扩展机制。此外，它还允许扩展其词汇表，从而可以根据网格生成的新信号来实施策略。

• 可移植性：使用Istio的生态系统在许多方面都不同。Istio必须能在任何云端或本地环境中运行，只需最少的努力。将基于Istio的服务移植到新环境的任务必须很简单。使用Istio，您可以操作部署到多个环境中的单个服务。例如，可以在多个云上部署以实现冗余。

• 策略统一性：将策略应用于服务之间的API调用提供了对网格行为的大量控制。但是，将策略应用于不一定在API级别表达的资源也同样重要。例如，对ML训练任务消耗的CPU数量应用quota比对启动wrok的调用应用quota更有用。为此，Istio将策略系统作为具有其自己的API的独特服务来维护，而不是将策略系统烘焙到代理Sidecar中，从而使得服务根据需要直接与其集成。

社区