作者: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/1pc5C3jQGUEb-LydA5NTBA