下图显示了由蓝图为单个环境部署的概要架构。您可以在三种不同的环境中部署此架构：生产、非生产和开发。
该图包含以下部分：
- Cloud Load Balancing 将各区域的应用流量分布到各个 Kubernetes 服务对象。每项服务的背后是相关 Pod 的逻辑分组。
- Anthos Service Mesh 可让 Kubernetes 服务相互通信。
- Kubernetes 服务划分到多个租户，表示为 Kubernetes 命名空间。租户是一个抽象概念，表示在集群中运行的多个用户和工作负载，它们使用单独的 RBAC 进行访问权限控制。每个租户还有其自己的项目，用于特定于租户的云资源，例如数据库、存储桶和 Pub/Sub 订阅。
- 具有各自身份的命名空间，用于访问对等服务和云资源。由于舰队 Workload Identity，身份在不同集群的同一命名空间中保持一致。每个环境都有一个单独的工作负载身份池，目的是缓解环境之间的提权。
- 每项服务都有专用的流水线，用于构建和部署该服务。该流水线用于将服务部署到开发环境，再将服务部署到非生产环境，最后将服务部署到生产环境。
开发者平台的关键架构决策
下表介绍了蓝图实现的架构决策。
| 决策区域 | 决策 | 原因 |
|---|---|---|
跨多个区域部署。 |
使应用在区域服务中断期间保持可用。 |
|
在企业基础蓝图的基础上部署。 |
使用企业基础蓝图提供的组织结构和安全控制机制。 |
|
使用企业基础蓝图中设置的三个环境文件夹： |
为具有不同访问权限控制的环境提供隔离。 |
|
将应用封装并部署为容器。 |
支持职责分离、高效运营和应用可移植性。 |
|
在 GKE 集群上运行应用。 |
使用推出容器的公司构建的代管式容器服务。 |
|
在主动/主动配置中复制并运行应用容器。 |
实现更高的可用性和更快速的渐进式发布，从而加快开发速度。 |
|
在两个不同的区域中使用两个 GKE 集群预配生产环境。 |
实现比单个云区域更高的可用性。 |
|
在两个不同的区域中使用两个 GKE 集群预配非生产环境。 |
在部署到生产环境之前，暂存对跨区域设置（例如负载均衡器）的更改。 |
|
使用单个 GKE 集群实例预配开发环境。 |
有助于降低费用。 |
|
为每个 GKE 集群配置高可用性控制平面。 |
确保集群控制平面在升级和调整大小期间可用。 |
|
对每个 GKE 集群内的命名空间、服务和身份使用相同性概念。 |
确保不同集群中的同名 Kubernetes 对象被视为同一对象。这种标准化做法有助于更轻松地管理舰队资源。 |
|
通过控制平面的 Private Service Connect 访问和专用节点池为 GKE 集群启用专用 IP 地址空间。 |
帮助保护 Kubernetes 集群 API 免遭扫描攻击。 |
|
通过 Connect 网关启用对 GKE 集群的管理员权限。 |
使用一条命令提取用于访问多个集群的凭据。使用群组和第三方身份提供方管理集群访问权限。 |
|
改善集群的整体安全状况，因为 pod 未直接公开给互联网，但仍可以访问面向互联网的资源。 |
||
配置节点以使用 Container-Optimized OS 和 安全强化型 GKE 节点。 |
限制节点的攻击面。 |
|
将每个环境与 GKE 舰队相关联。 |
允许将各组 GKE 集群作为一个整体进行管理。 |
|
提供受控、可审核且可重复的应用基础设施部署机制。 |
||
使用 GKE Enterprise 配置和政策管理功能配置 GKE 集群。 |
提供一个允许将 GKE 集群的配置视为代码的服务。 |
|
使用应用工厂部署蓝图中使用的应用 CI/CD 流水线。 |
提供可重复的模式，以便更轻松地部署应用流水线。 |
|
使用应用 CI/CD 流水线构建和部署蓝图应用组件。 |
提供受控、可审核且可重复的应用部署机制。 |
|
配置应用 CI/CD 流水线以使用 Cloud Build、Cloud Deploy 和 Artifact Registry。 |
使用托管式构建和部署服务，在安全性、规模和简洁性方面进行优化。 |
|
跨环境使用不可变的容器，并使用 Binary Authorization 为容器签名。 |
提供明确的代码出处，并确保代码已在各种环境中进行测试。 |
|
使用 Google Cloud Observability，其中包括 Cloud Logging 和 Cloud Monitoring。 |
使用 Google Cloud 的集成托管式服务来简化运营。 |
|
启用 Container Threat Detection（Security Command Center 中的一项服务）以监控容器的完整性。 |
使用通过持续监控容器来增强安全性的托管式服务。 |
|
通过 Kubernetes 基于角色的访问控制 (RBAC)（它基于 Google GKE 群组）控制对 GKE 集群的访问权限。 |
通过将访问权限控制关联到 Google Cloud 身份来增强安全性。 |
|
为每个 Kubernetes 服务使用唯一的 Kubernetes 服务账号。此账号通过使用 Workload Identity 充当 IAM 服务账号。 |
最大限度地减少需要提供给每项服务的权限，从而提高安全性。 |
|
通过 GKE Gateway API 公开服务。 |
通过提供基于声明式和基于资源的方法来管理入站规则和负载均衡配置，从而简化配置管理。 |
|
通过将 Anthos Service Mesh 与 Certificate Authority Service 搭配使用，将服务作为分布式服务运行。 |
通过在服务之间强制执行身份验证来增强安全性，还可以将流量重定向到运行状况不佳的服务，以提供自动容错能力。 |
|
对 AlloyDB for PostgreSQL 使用跨区域复制。 |
在数据库层提供高可用性。 |
|
在每个环境中配置共享 VPC 实例，并在服务项目中创建 GKE 集群。 |
共享 VPC 提供集中式网络配置管理，同时使环境保持分离。 |
|
提供单个任播 IP 地址来访问区域化 GKE 集群，以实现高可用性和低延迟服务。 |
||
使用 HTTPS 连接让客户端访问服务。将任何客户端 HTTP 请求重定向到 HTTPS。 |
帮助保护传输中的敏感数据，并防止中间人攻击。 |
|
使用 Certificate Manager 管理公共证书。 |
以统一的方式管理证书。 |
|
使用 Google Cloud Armor 保护网页界面。 |
通过防范常见的 Web 应用漏洞和卷攻击，增强安全性。 |
您的决定可能与蓝图有所不同。如需了解替代方案，请参阅默认建议的替代方案。
后续步骤
- 了解开发者平台控制（本系列的下一个文档）。