本部分介绍开发者平台中使用的控制机制。
平台身份、角色和群组
访问 Google Cloud 服务需要 Google Cloud 身份。此蓝图使用舰队 Workload Identity 将用作 pod 身份的 Kubernetes 服务账号映射到控制 Google Cloud 服务访问权限的 Google Cloud 服务账号。为了帮助防范跨环境升级，每个环境都对其 Workload Identity 账号设置了一个单独的身份池（称为一组受信任的身份提供方）。
平台角色
部署蓝图时，您需要创建三种类型的用户组：开发者平台团队、应用团队（每个应用一个团队）和安全运营团队。
开发者平台团队负责开发和管理开发者平台。该团队的成员包括：
- 开发者平台开发者：这些团队成员负责扩展蓝图并将其集成到现有系统中。该团队还会创建新的应用模板。
- 开发者平台管理员：此团队负责以下任务：
- 批准创建新租户团队。
- 执行会影响多个租户的计划任务和计划外任务，包括：
- 批准将应用提升到非生产环境和生产环境。
- 协调基础设施更新。
- 制定平台级容量计划。
开发者平台的租户是一个软件开发团队和那些负责运行该软件的人员。租户团队由两个群组组成：应用开发者和应用运维人员。租户团队的两个群组的职责如下：
- 应用开发者：该团队负责编写和调试应用代码。他们有时也称为“软件工程师”或“全栈开发者”。他们的职责如下：
- 将应用组件部署到开发环境时，对其执行测试和质量保证。
- 在开发环境中管理应用拥有的云资源（例如数据库和存储桶）。
- 设计数据库或存储架构以供应用使用。
- 应用运维人员或站点可靠性工程师 (SRE)：此团队负责管理生产环境中运行的应用的可靠性，以及将应用开发者所做的更改安全推进到生产环境中。他们有时称为服务运维人员、系统工程师或系统管理员。他们的职责如下：
- 规划应用级容量需求。
- 为服务创建提醒政策并设置服务等级目标 (SLO)。
- 使用特定于该应用的日志和指标诊断服务问题。
- 对提醒和页面进行响应，例如当服务未达到其 SLO 时。
- 与一组或多组应用开发者合作。
- 批准将新版本部署到生产环境。
- 在非生产环境和生产环境中管理应用拥有的云资源（例如备份和架构更新）。
平台组织结构
企业应用蓝图使用企业基础蓝图提供的组织结构。下图展示了企业应用蓝图项目在基础蓝图结构中的位置。
平台项目
下表介绍了应用蓝图部署资源、配置和应用时除了基础蓝图提供的项目之外还需要其他哪些项目。
| 文件夹 | 项目 | 说明 |
|---|---|---|
|
|
包含用于部署租户基础设施的多租户基础设施流水线。 |
|
包含应用工厂 ，用于创建单租户应用架构以及持续集成和持续部署 (CI/CD) 流水线。此项目还包含用于 GKE 集群配置的 Config Sync。 |
|
|
包含应用 CI/CD 流水线，这些流水线位于独立项目中，实现了开发团队之间的分离。每个应用都有一个流水线。 |
|
|
|
包含开发者平台的 GKE 集群以及用于注册集群以进行舰队管理的逻辑。 |
( |
包含任何单租户应用服务，例如数据库或应用团队使用的其他托管式服务。 |
平台集群架构
此蓝图在三种环境中部署应用：开发、非生产和生产。每个环境都与一个舰队相关联。在此蓝图中，舰队是包含一个或多个集群的项目。但是，舰队还可以对多个项目进行分组。舰队会提供逻辑安全边界以实现管理控制。舰队提供了一种对 Kubernetes 集群进行逻辑分组和标准化的方法，并简化了基础设施的管理。
下图显示了在每个环境中创建的、用于部署应用的两个 GKE 集群。这两个集群在两个不同的区域中充当相同的 GKE 集群，以提供多区域弹性。为了利用舰队功能，蓝图在各个命名空间对象、服务和身份之间使用相同性概念。
企业应用蓝图使用此类 GKE 集群：它们通过控制平面的 Private Service Connect 访问和专用节点池启用了专用空间，可消除互联网中潜在攻击面。集群节点和控制平面都没有公共端点。集群节点运行 Container-Optimized OS 来限制其攻击面，而集群节点使用安全强化型 GKE 节点来限制攻击者模拟节点。
通过 Connect 网关启用 GKE 集群的管理员权限。在蓝图部署过程中，每个环境使用一个 Cloud NAT 实例为 pod 和 Config Sync 提供一种互联网资源（例如 GitHub）访问机制。GKE 集群的访问权限由基于 Google GKE 群组的 Kubernetes RBAC 授权控制。借助群组，您可以使用由身份管理员控制的中央身份管理系统来控制身份。
平台 GKE Enterprise 组件
开发者平台使用 GKE Enterprise 组件来构建、交付和管理应用的生命周期。蓝图部署中使用的 GKE Enterprise 组件如下：
- GKE，用于容器管理
- Policy Controller，用于政策管理和强制执行
- Anthos Service Mesh，用于服务管理
- Binary Authorization，用于容器映像证明
- GKE Gateway Controller，适用于 GKE 集群的多集群网关控制器
平台舰队管理
舰队使您能够以统一的方式管理多个 GKE 集群。舰队团队管理使平台管理员能够更轻松地为开发者平台租户预配和管理基础设施资源。租户可以对自己命名空间中的资源（包括其应用、日志和指标）进行范围控制。
如需按团队预配舰队资源子集，管理员可以使用团队范围。借助团队范围，您可以为每个团队定义舰队资源子集，并且每个团队范围与一个或多个舰队成员集群相关联。
借助舰队命名空间，您可以控制谁可以访问舰队中的特定命名空间。应用使用两个 GKE 集群，它们部署在一个舰队上，具有三个团队范围，每个范围都有一个舰队命名空间。
下图显示了由蓝图实现的环境中与示例集群对应的舰队和范围资源。
平台网络
对于网络，GKE 集群部署在共享 VPC 中，此 VPC 是作为企业基础蓝图的一部分创建的。GKE 集群要求在开发、非生产和生产环境中分配多个 IP 地址范围。此蓝图使用的每个 GKE 集群都需要为节点、pod、服务和控制平面分配单独的 IP 地址范围。AlloyDB for PostgreSQL 实例还需要单独的 IP 地址范围。
下表介绍了不同环境中用于部署蓝图集群的 VPC 子网和 IP 地址范围。对于应用 GKE 集群区域 2 中的开发环境，蓝图仅部署一个 IP 地址空间，即使为两个开发 GKE 集群分配了 IP 地址空间也是如此。
| 资源 | IP 地址范围类型 | 开发 | 非生产 | 生产 |
|---|---|---|---|---|
应用 GKE 集群区域 1 |
主要 IP 地址范围 |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Pod IP 地址范围 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
服务 IP 地址范围 |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
GKE 控制平面 IP 地址范围 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
应用 GKE 集群区域 2 |
主要 IP 地址范围 |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Pod IP 地址范围 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
服务 IP 地址范围 |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
GKE 控制平面 IP 地址范围 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB for PostgreSQL |
数据库 IP 地址范围 |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
如果您需要设计自己的 IP 地址分配方案，请参阅 GKE 中的 IP 地址管理和 GKE IPv4 地址规划。
平台 DNS
此蓝图使用 Cloud DNS for GKE 为 pod 和 Kubernetes 服务提供 DNS 解析。Cloud DNS for GKE 是一个托管式 DNS，不需要托管集群的 DNS 提供商。
在该蓝图中，Cloud DNS 配置了 VPC 范围。VPC 范围允许一个项目中的所有 GKE 集群中的服务共用一个 DNS 区域。单个 DNS 区域允许跨集群解析服务，而集群外部的虚拟机或 pod 可以解析集群中的服务。
平台防火墙
GKE 会在创建 GKE 集群、GKE 服务、GKE Gateway 防火墙和 GKE Ingress 防火墙时自动创建允许集群在您环境中运行的防火墙规则。所有自动创建的防火墙规则的优先级均为 1000。由于企业基础蓝图具有阻止共享 VPC 中的流量的默认规则，因此需要这些规则。
平台对 Google Cloud 服务的访问
由于蓝图应用使用专用集群，因此专用 Google 访问通道提供 Google Cloud 服务的访问权限。
平台高可用性
此蓝图旨在应对可用区和区域服务中断。使应用保持运行所需的资源分布在两个区域。您可以选择要在其中部署蓝图的区域。对于不在传送和响应负载的关键路径中的资源，它们只部署在一个区域，或部署在全球。下表介绍了各种资源及其部署位置。
位置 |
区域 1 |
区域 2 |
全球 |
|---|---|---|---|
其资源位于此位置的环境 |
|
|
|
其资源位于此位置的项目 |
|
|
|
此位置的资源类型 |
|
|
|
下表总结了不同的组件如何响应区域服务中断或可用区服务中断，以及如何缓解这些影响。
故障范围 |
外部服务影响 |
数据库效果 | 构建和部署效果 | Terraform 流水线效果 |
|---|---|---|---|---|
区域 1 的可用区 |
可用。 |
可用。 备用实例变为活跃状态，RPO 为零。 |
可用，可能需要手动更改。 您可能需要重启任何正在进行但在服务中断期间完成的 |
可用，可能需要手动更改。 您可能需要重启任何正在进行但在服务中断期间完成的 |
区域 2 的可用区 |
可用。 |
可用。 |
可用。 |
可用，可能需要手动更改。 您可能需要重启任何正在进行但在服务中断期间完成的 |
区域 1 |
可用。 |
需要手动更改。 操作员必须手动升级次要集群。 |
不可用。 |
不可用。 |
区域 2 |
可用。 |
可用。 |
可用，可能需要手动更改 构建仍然可用。您可能需要手动部署新构建。现有构建可能无法成功完成。 |
可用。 |
云服务提供商服务中断只是产生停机时间的一个因素。高可用性也取决于有助于减少错误的流程和操作。下表介绍了蓝图中与高可用性相关的所有决策以及这些决策的原因。
| 蓝图决策 | 可用性影响 |
|---|---|
变更管理 |
|
使用 GitOps 和 IaC。 |
支持对更改进行代码互审，支持快速还原到先前的配置。 |
将更改逐步提升到各个环境中。 |
降低软件和配置错误造成的影响。 |
使非生产环境和生产环境保持相似。 |
确保差异不会导致错误被延迟发现。这两种环境都是双区域环境。 |
在环境中一次更改一个区域中的复制资源。 |
确保逐步升级中未发现的问题仅影响一半的运行时基础设施。 |
在环境中一次更改一个区域中的服务。 |
确保逐步升级中未发现的问题仅影响一半的服务副本。 |
复制计算基础设施 |
|
使用区域级集群控制平面。 |
区域控制平面在升级和调整大小期间可用。 |
创建一个多可用区节点池。 |
集群节点池至少有三个节点，分布在三个可用区中。 |
配置共享 VPC 网络。 |
共享 VPC 网络覆盖两个区域。区域级故障只会影响进出故障区域中的资源的网络流量。 |
复制映像注册表。 |
映像存储在 Artifact Registry 中，该映像配置为复制到多个区域，这样在云区域发生服务中断时，便不会阻止在继续有效的区域中对应用进行纵向扩容。 |
复制服务 |
|
将服务副本部署到两个区域。 |
如果某个区域发生服务中断，Kubernetes 服务在生产和非生产环境中仍然可用。 |
对区域内的服务更改使用滚动更新。 |
您可以使用滚动更新部署模式更新 Kubernetes 服务，以降低风险并缩短停机时间。 |
在一个区域中为每个服务配置三个副本。 |
Kubernetes 服务至少具有三个副本 (pod)，用于支持生产环境和非生产环境中的滚动更新。 |
将部署的 pod 分布在多个可用区中。 |
Kubernetes 服务使用反亲和性节分布在不同可用区的虚拟机中。可以承受单节点中断或全可用区服务中断，而不会在依赖服务之间产生额外的跨区域流量。 |
复制存储 |
|
部署多可用区数据库实例。 |
AlloyDB for PostgreSQL 在一个区域中提供高可用性。其主实例的冗余节点位于该区域的两个不同可用区中。如果活跃可用区遇到问题，则主实例会通过触发自动故障切换到备用可用区的操作来保持区域级可用性。区域存储有助于在丢失一个可用区时，提供数据耐用性。 |
跨区域复制数据库。 |
AlloyDB for PostgreSQL 使用跨区域复制来提供灾难恢复功能。数据库会将主集群的数据异步复制到位于不同 Google Cloud 区域的次要集群。 |
运维 |
|
将应用预配为预期负载的两倍。 |
如果一个集群发生故障（例如，由于区域级服务中断），则在其余集群中运行的那部分服务就完全能够承受负载。 |
自动修复节点。 |
集群已配置节点自动修复。如果某个节点的连续健康检查在较长时间内反复失败，则 GKE 会为该节点启动修复流程。 |
确保节点池升级是应用感知的。 |
Deployment 使用 |
自动重启死锁服务。 |
支持服务的部署定义了活跃性探测，用于标识并重启死锁进程。 |
自动检查副本是否已准备就绪。 |
支持服务的部署定义了就绪性探测，用于标识应用在启动后何时可以提供服务。利用就绪性探测，无需在滚动更新和节点池升级期间进行手动检查或定时等待。 |
参考架构专为具有可用区和区域高可用性要求的应用而设计。若要保证高可用性，的确会产生一些费用（例如，备用费用或跨区域复制费用）。替代方案部分介绍了一些降低这些费用的方法。
平台配额、性能限制和扩缩限制
您可以控制开发者平台资源的配额、性能和扩缩。以下列表介绍了一些需要考虑的事项：
- 基础设施需要大量项目，而其他每个租户需要四个项目。在部署之前以及添加更多租户之前，您可能需要申请额外的项目配额。
- 每个项目最多只能有 100 个 MultiClusterGateway 资源。开发者平台上每个面向互联网的 Kubernetes 服务都需要一个 MultiClusterGateway。
- 项目中的 Cloud Logging 最多只能包含 100 个存储桶。此蓝图中的每租户日志访问权限依赖于每个租户的存储桶。
- 如需创建超过 20 个租户，您可以申请增加项目的“范围”和“范围命名空间”资源的配额。如需了解如何查看配额，请参阅查看和管理配额。使用过滤条件查找
gkehub.googleapis.com/global-per-project-scopes和gkehub.googleapis.com/global-per-project-scope-namespaces配额类型。
后续步骤
- 了解服务架构（本系列的下一个文档）。