我们将考虑以下故障场景：
- 工作负载集群
- 边缘控制平面
- 从管理到工作负载的连接丢失
- 中央控制平面
- 管理平面
- 管理集群
并评估故障对以下操作的影响：
- 运行生产负载 - 生产负载的可用性、安全性和正确运行
- 本地集群操作 - 包括直接修改集群配置（如 kubectl 操作）和间接修改（即由本地边缘控制平面进行的更改以应用 TSB 策略或更新服务发现终端点）
- 指标收集 - 来自远程工作负载集群的指标的集中收集和存储
- 管理操作 - 由 GitOps、API 或管理 UI 执行的 TSB 配置更改
我们将研究典型的恢复情况，当失败组件恢复或被恢复时。
架构和术语
在本指南中，我们将使用以下架构描述：
- 工作负载集群：工作负载集群是托管生产工作负载的 Kubernetes 集群。
- 生产工作负载：生产工作负载是在工作负载集群中运行的应用程序或服务。为了避免疑虑，‘生产工作负载’ 还包括非生产工作负载。
- 数据平面：数据平面是部署在工作负载集群中的本地 Istio 实例。
- 边缘控制平面：边缘控制平面是部署在工作负载集群中的 Tetrate 软件组件（位于 istio-system 和其他命名空间中，如 cert-manager、xcp-multicluster）。它配置本地 Istio 数据平面，并向中央控制平面报告状态。
- 管理集群：管理集群是托管 Tetrate 管理平面组件（管理平面、中央控制平面）的 Kubernetes 集群。
- 中央控制平面：中央控制平面是 Tetrate 软件组件，它接受来自管理平面的配置以及来自边缘控制平面的状态信息。它评估整个配置，然后将必要的配置更新分发给每个边缘控制平面。
- 管理平面：管理平面是 Tetrate 软件组件，实体（GitOps、API 客户端、UI 客户端）与之交互。它提供 RBAC 访问控制，以控制哪些实体可以对哪些配置进行 CRUD 操作。配置存储在本地，并同步到中央控制平面。
有关更多信息，请参阅 Tetrate 架构文档。
术语
- 故障（Failure）意味着相关组件不可用
- 恢复（Recovery）意味着重新获得相关组件的可用性，通常使用过时的配置或状态
- 修复（Restoration）意味着重新安装失败的组件，无法恢复组件
- ✅ 组件或服务不受影响
- ⚠️ 发生了有限的服务中断。
- ❌ 发生了受影响组件的完全服务中断
工作负载集群故障
场景：单个工作负载集群发生灾难性故障。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 本地工作负载不可用。 其他集群上的工作负载不受影响。工作负载 HA（Tier1 和 EW 网关）确保不中断服务。 |
⚠️ |
| 本地集群操作 | 无法进行本地集群更改。 其他集群不受影响。 |
⚠️ |
| 指标收集 | 无法从本地集群收集指标。 其他集群的指标收集不受影响。 |
⚠️ |
| 管理操作 | 针对受影响的工作负载集群的更改将排队，并在集群恢复时应用。 所有其他管理操作不受影响。 |
✅ |
恢复
如果本地集群恢复，配置将迅速更新，并且指标收集将恢复。
修复
如果需要，可以重新安装 Tetrate 边缘控制平面。当集群重新引入管理平面时，它将同步到正确的配置。
边缘控制平面故障
场景：单个工作负载集群中的边缘控制平面发生灾难性故障。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 本地或远程集群中的运行工作负载不受影响。 | ✅ |
| 本地集群操作 | 本地集群更改（kubectl）不受影响。您可以继续向集群推送更新。 根据故障的性质：
|
⚠️ |
| 指标收集 | 指标在本地进行收集，然后转发到管理平面的 ElasticSearch。如果收集器服务不可用，可能无法收集指标。 | ⚠️ |
| 管理操作 | 针对受影响的工作负载集群的更改将排队，并在边缘控制平面恢复时应用。 所有其他管理操作不受影响。 |
✅ |
恢复
如果本地集群恢复，配置将迅速更新，并且指标收集将恢复。
修复
如果需要，可以重新安装 Tetrate 边缘控制平面。当集群重新引入管理平面时，它将同步到正确的配置。
连接丢失 - 工作负载到管理集群
场景：工作负载集群与中央管理集群之间的连接丢失。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 运行本地或远程集群中的工作负载不受影响。 | ✅ |
| 本地集群操作 | 本地集群更改（kubectl）不受影响。 新工作负载可能部分配置运行，直到恢复连接。它们可能获取已存在于集群中但缺少命名空间定向和细粒度策略的全局集群策略。 远程服务的本地服务发现终端点不会更新。 GitOps 操作可能会中断。 |
⚠️ |
| 指标收集 | 指标在受影响的工作负载集群中进行收集并排队。长时间失去连接将导致一些指标丢失。 | ⚠️ |
| 管理操作 | 针对受影响的工作负载集群的更改将排队，并在恢复连接时应用。 所有其他管理操作不受影响。 |
✅ |
恢复
恢复连接后，配置将迅速更新，并且指标收集将恢复。
中央控制平面故障
场景：中央控制平面组件发生故障。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 运行本地或远程集群中的工作负载不受影响。 | ✅ |
| 本地集群操作 | 本地集群更改（kubectl）不受影响。 新工作负载可能部分配置运行，直到中央控制平面恢复。它们可能获取已存在于集群中但缺少命名空间定向和细粒度策略的全局集群策略。 远程服务的本地服务发现终端点不会更新。 |
⚠️ |
| 指标收集 | 指标收集不受影响。 | ✅ |
| 管理操作 | 配置读取、仪表板（指标）不受影响。 配置更新排队。 |
✅ |
恢复
当中央控制平面恢复时，其本地配置缓存会自动恢复，通常在 1-2 分钟内完成。然后会更新远程集群配置。不会丢失任何配置更改或数据。
修复
如果需要，可以在Tetrate 技术支持的帮助下重新安装中央控制平面组件。不需要备份。
管理平面故障
场景：管理平面组件故障。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 本地或远程集群中运行的工作负载不受影响。 | ✅ |
| 本地集群操作 | 本地集群更改（kubectl）不受影响。 新的工作负载可能会部分配置，直到管理平面恢复。它们可能会获取全局集群策略，但会缺少针对命名空间和细粒度策略的配置。 中央和本地控制平面维护服务发现端点。 |
✅ |
| 指标收集 | 如果 ElasticSearch 数据库对工作负载集群不可用，将影响指标收集。 | ⚠️ |
| 管理操作 | 无法进行 TSB 配置更改。UI、API 和 GitOps 操作不可用。 | ❌ |
TSB 配置存储在客户提供的 PostgreSQL 数据库中，还存储在一些辅助服务中 - 用于 PKI 管理的 cert-manager，tsb 命名空间中的其他密钥。
恢复
如果管理平面在不丢失数据的情况下恢复，操作将如之前一样继续进行，不应发生配置丢失。
恢复
可以从 PostgreSQL 数据库的备份和 iam-signing-key 重新构建管理控制平面组件，需要Tetrate 技术支持的协助。有关该过程的概述，请参阅管理平面灾难恢复文档。
管理集群故障
场景：Kubernetes 管理集群故障。
影响
| 操作 | 影响 | |
|---|---|---|
| 运行工作负载 | 本地或远程集群中运行的工作负载不受影响。 | ✅ |
| 本地集群操作 | 本地集群更改（kubectl）不受影响。中央 TSB 策略（例如新命名空间的默认设置）适用于新配置。 远程服务的本地服务发现端点不会更新。 |
⚠️ |
| 指标收集 | 无法从任何工作负载集群中收集指标。 | ❌ |
| 管理操作 | 无法进行 TSB 配置更改。UI、API 和 GitOps 操作不可用。 | ❌ |
恢复
如果管理平面在不丢失数据的情况下恢复，操作将如之前一样继续进行，不应发生配置丢失。
修复
可以从 PostgreSQL 数据库的备份和 iam-signing-key 重新构建管理控制平面组件，需要Tetrate 技术支持的协助。有关该过程的概述，请参阅管理平面灾难恢复文档。
建议
为了应对管理组件的意外故障，我们建议考虑以下建议：
- 要么在可靠的冗余集群中维护 Postgres 数据库，要么（在 TSE 的情况下）利用定期的 Postgres 备份。
- 保留 iam-signing-key 的备份
- 如果保留指标很重要，请在可靠的冗余集群中维护 ElasticSearch 数据库，或定期备份，以便在必要时进行恢复。
有关恢复故障管理平面组件的过程概述，请参阅管理平面灾难恢复文档。