作者：Gaurav Agarwal
翻译：Bach（才云）
校对：星空下的文仔（才云）、bot（才云）
如果在 Kubernetes 上应用微服务，那么像 Istio 这样的服务网格将施展出巨大作用。这里咱们先讨论一下 Istio 的体系结构。
Istio 通过两个次要组件帮忙治理微服务：
- 数据立体（Data Plane）：这是 Istio 在微服务中的 Envoy sidecar，它们在服务之间进行理论路由，并收集遥测数据。
- 管制立体（Control Plane）：这是通知数据立体如何路由流量的组件，它存储、治理配置，帮忙管理员与 sidecar 代理进行交互并管制 Istio 服务网格。管制立体就像是 Istio 的大脑。
通过 Istio 的流量有两种类型：数据立体流量（与业务相干的流量）和管制立体流量（由音讯和 Istio 组件之间的交互组成）。
管制立体组件
在以后 Istio 版本（Istio v1.5 及更高版本）中，管制立体以单个二进制 Istiod 的模式提供，由三局部组成：Pilot、Citadel 和 Galley。
Istio 架构
Pilot
Pilot 是服务网格的地方控制器，负责应用 Envoy API 与 Envoy sidecar 进行通信。它会解析 Istio manifest 中定义的高级规定，并将其转换为 Envoy 配置。它有助于服务发现、流量治理和智能路由，使咱们能够进行 A/B 测试、蓝绿部署、金丝雀公布等。它能通过配置 sidecar 来提供超时、重试和断路性能，以在网格中提供足够的弹性。
另外，Pilot 还负责在 Istio 配置和 Istio 运行的根底根底构造之间提供涣散的耦合。因而，咱们能够在 Kubernetes、Nomad 或 Consul 上运行 Istio，这些与 Istio 交互的形式是类似的。Pilot 晓得本人在哪个平台上运行，能够确保流量治理是雷同的，和平台无关。它能够托管流量治理 API，该 API 可帮忙定义配置并提供更精密的服务网格中流量治理。
Citadel
服务之间的身份和拜访治理是 Istio 的外围性能，它容许 Kubernetes Pod 之间进行平安通信。这意味着，当开发人员设计了具备不平安 TCP 的组件时，Envoy proxy 要确保 Pod 之间的通信是加密的。
咱们能够通过为每个 Pod 配置一个证书来实现互相 TLS，但这十分麻烦，如果是大型微服务应用程序，那么最终将要治理数百个证书。对此，Istio 提供了一个名为 Citadel 的身份和拜访管理器以及证书存储库。Citadel 可帮忙治理与服务进行的通信以及它们是如何互相辨认和认证的。Citadel 也提供了用户身份验证、凭证治理、证书治理和流量加密。如果有任何 Pod 须要验证凭证，Citadel 就能够提供。
Galley
Galley 负责为服务网格提供配置验证、接管、解决和散发。它是 Istio 管制立体与之交互的根底 API 接口。例如，如果咱们利用了新策略，Galley 将对其进行验证、解决并推送到服务网格的正确组件。
数据立体组件
数据立体组件蕴含 Envoy proxy。这些是第 7 层代理，可依据收到的音讯的内容进行要害决策。与业务流量交互的惟一组件是 Envoy proxy，能帮忙提供：
- 动静服务发现。
- 负载平衡。
- TLS 终止。
- 分阶段推出基于百分比的指标。
- 故障注入。
- 健康检查。
- 断路。
- 收集遥测数据。
当所有流量流经 Envoy proxy 时，它们会收集无关业务流量的根本数据，这能够帮忙咱们收集信息，做好布局。
Istio 提供了开箱即用的 Prometheus 和 Grafana，用于监督和可视化此数据，还能够将数据作为 Elastic Logstash Kibana（ELK）堆栈发送到日志剖析工具，以理解趋势并依据这些指标进行机器学习。
因为 Istio 应用 sidecar，因而无需从新设计 Kubernetes 上运行的微服务应用程序，它是开发、平安和经营团队之间的绝佳分离器。开发人员能够像以前一样开发代码，而不用放心操作和安全性方面。平安和经营团队能够应用 Istio 在应用程序中应用 Sidecar，这有助于他们贯彻治理和安全策略。
Envoy proxy 可帮忙提供 Istio 的大多数性能，例如：
- 流量管制：这有助于管制流量通过服务网格，例如提供 HTTP、TCP、Websocket 和 gRPC 流量的路由规定。
- 安全性和身份验证：它对 Pod 施行身份和拜访治理，以便只有正确的 Pod 能力与另一个 Pod 交互。此外，还实现了双向 TLS 和流量加密，以避免中间人攻打。它们提供速率限度，从而避免老本失控和拒绝服务攻打。
- 网络弹性：它有助于提供网络弹性性能，例如重试、故障转移、断路和故障注入。
它还提供了一种应用 Web 程序集扩大模型插入自定义策略施行和遥测数据收集的办法。
组件如何交互？
Istio 所做的一切都是通过 Envoy proxy 进行的。让咱们看一下通过 Istio 的数据包采取的典型流程。
图源 Istio.io
咱们查看下面的图片，能够发现有 一个 Ingress，两个微服务和一个 Egress。服务 A 和服务 B 是在容器上运行的微服务，它们与 Envoy proxy 共享同一 Pod。部署它们后，Istio 会将 Envoy proxy 主动注入到 Pod 中。正如图片中那样，服务 A 是前端服务，服务 B 是后端服务。
流量数据包依照以下路线在服务网格中挪动：
Ingress
流量通过 Ingress 资源达到服务网格。Ingress 是由一个或多个 Envoy proxy 组成的库，这些代理在部署后由 Pilot 配置。Pilot 应用 Kubernetes 服务端点配置 Ingress 代理，并且 Ingress 代理晓得其后端，因而，Ingress 晓得接管到的数据包将发送到何处。它会进行健康检查和负载平衡，并依据已定义的度量规范（例如负载、数据包、配额和流量均衡）做出决定来发送音讯。
服务 A
一旦 Ingress 路由到第一个 Pod，它将命中 Service A Pod 的代理，而不是容器。因为 sidecar 与微服务容器造成同一 Pod 的一部分，因而它们共享雷同的网络命名空间，并位于同一节点中。两个容器具备雷同的 IP 地址，并共享雷同的 IP 表规定。这使得代理能够齐全管制 Pod，并解决通过 Pod 的所有流量。
Envoy proxy 与 Citadel 进行交互，以理解是否须要执行任何策略。它还查看是否须要加密通过链的流量并与后端容器建设 TLS。
服务 B
服务 A 将加密的数据包发送到服务 B，服务 B 遵循与服务 A 雷同的步骤。它会标记数据包的发送者，并与源代理进行 TLS 握手。在建设信赖后，它将承受该数据包并将其转发到 Service B 容器，而后这些将挪动到该 Egress 层。
Egress
所有从网状网络流出的流量都会应用 Egress 资源。该 Egress 层定义了哪些流量能够从网格中传出并应用 Pilot，其配置与该 Ingress 层类似。应用 Egress 资源，咱们能够编写策略以限度出站流量，并且仅容许所需的服务将数据包发送出网格。
遥测数据收集
在上述所有步骤中，当流量通过代理时，它能够收集遥测数据并将其发送到 Prometheus。数据能够在 Grafana 中可视化，或发送到内部工具（如 ELK）以进行进一步的剖析和指标的机器学习。
原文链接：https://mp.weixin.qq.com/s/1p…