事实来源
我们不建议在本文档中概述的部署架构：TSB 的单个实例设计为在所有环境（测试、QA、暂存和生产）中部署。最佳做法是在中心位置部署单个 TSB，并将所有环境指向该单个 TSB。Tetrate Service Bridge 内置的控制保持了你环境配置的隔离和安全性。
一些站点已经为每个环境部署了单独的 TSB 实例。本指南的存在是为了确保这些站点能够建立一个跨环境控制配置推广的流程，不依赖于 TSB 本身。
配置推广注意事项和建议
TSB 配置主要由许多 Kubernetes 对象 组成，例如 Tenant 是 api.tsb.tetrate.io/v2 中的一个对象。
因此，主要建议是将 TSB 配置视为任何其他 Kubernetes 资源定义，例如：
- 声明性地定义资源。
- 使用 GitOps 进行资源应用。
- 使用
kustomize或类似工具进行配置模板化和渲染。
在将一个 TSB 安装的资源应用到另一个 TSB 安装时的主要注意事项是在计算和评估 NGAC 访问规则、集群/服务参数等时 TSB 存储配置数据的方式。
Tetrate Service Bridge 使用持久存储（PostgreSQL）作为事实来源，并选择资源的完全限定名称作为其 主键。因此，在两个独立的 TSB 安装之间“推广”配置时，必须考虑配置资源命名，以避免 主键 冲突。
换句话说，要在独立的实例之间可靠地推广配置，应该：
- 在两个实例中将所有 TSB 资源的命名 完全相同，包括资源路径（即一个实例中具有相同名称的
Cluster必须属于另一个实例中相同的Tenant等等）。 - 避免使用命令式的配置更改（例如通过 UI/CLI 在一个环境中添加一个
Cluster而在另一个环境中没有），而是使用声明性的定义。 - 始终备份最近的持久存储数据，以便在数据模型冲突的情况下能够快速回滚。