使用 Kubernetes 实现基础结构复原能力

  • 15 分钟

若要实现基于基础结构的复原，可使用服务网格。 除了无需更改代码的复原能力，服务网格还提供流量管理、策略、安全性、强标识和可观测性。 你的应用与移动到基础结构层的操作功能分离。 从结构上讲，服务网格由两个组件组成：一个控制平面和一个数据平面。

Diagram of a typical service mesh architecture.

控制平面组件具有多个支持管理服务网格的组件。 组件清单通常包括：

  • 管理界面，可以是 UI 或 API。
  • 定义服务网格应如何实现特定功能的规则和策略定义。
  • 对强标识和 mTLS 的证书等的安全管理。
  • 用于从应用收集和聚合指标及遥测数据的指标或可观测性。

数据平面组件由代理组成，代理以透明方式注入到每个服务旁边，这称为 Sidecar 模式。 每个代理都配置为控制进出包含你的服务的 Pod 的网络流量。 此配置允许将每个代理配置为：

  • 通过 mTLS 确保流量安全。
  • 动态路由流量。
  • 对流量应用策略。
  • 收集指标和跟踪信息。

Kubernetes 群集的一些常用服务网格选项包括 Linkerd、Istio 和 Consul。 本模块重点介绍 Linkerd。 下图显示了数据平面与控制平面内组件之间的交互：

Diagram of a Linkerd service mesh architecture.

与基于代码的方法的比较

Linkerd 的主要故障处理策略由重试和超时组成。 由于 Linkerd 具有整个群集的系统视图，它可以通过新颖的方式采用复原策略。 例如，以在目标服务上最多添加 20% 的额外负载的方式重试。 Linkerd 的基于指标的视图使它能够实时动态适应群集情况。 此方法会再添加一个维度来管理群集，但不会添加任何代码。

使用基于代码的方法（例如使用 Polly）时，你：

  • 需要猜测适合采用哪些重试和超时参数。
  • 应关注特定的 HTTP 请求。

没有合理的方法来响应应用代码中的基础结构故障。 考虑同时处理的数百个或数千个请求。 即使是指数回退（时间请求计数）的重试也可能会使服务不堪负重。

相比之下，基于基础结构的方法（如 Linkerd）不了解应用内部。 例如，复杂的数据库事务对于 Linkerd 是不可见的。 可以使用 Polly 防止此类事务发生故障。

在后续的单元中，你将使用 Polly 和 Linkerd 为优惠券服务实现复原。