作者：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）以进行进一步的分析和指标的机器学习。