GKE Enterprise 参考架构:Google Distributed Cloud Virtual for Bare Metal

Last reviewed 2023-08-15 UTC

本指南介绍了用于部署 GDCV for Bare Metal 的参考架构。本指南适用于想要在高可用性的地理位置冗余配置中,在裸金属平台上部署 GKE Enterprise 的平台管理员。为了更好地了解本指南,您应该熟悉 GKE Enterprise 技术概览中所述的基本 GKE Enterprise 概念。您还应该对 Kubernetes 概念和 Google Kubernetes Engine (GKE) 有基本的了解,如了解 Kubernetes 基础知识GKE 文档中所述。

本指南有一个 GitHub 源代码库,其中包含可用于部署所述架构的脚本。本指南还介绍了附带用于创建这些组件的脚本和模块的架构组件。我们建议您使用这些文件作为模板,以创建使用组织的最佳实践和政策的模块。

GDCV for Bare Metal 架构模型

《GKE Enterprise 架构基础指南》按层介绍平台架构。每个层的资源提供了一组特定的功能。这些资源由一个或多个角色拥有和管理。如下图所示,适用于裸金属的 GKE Enterprise 平台架构包含以下各层和资源:

展示了文档中讨论的各层的 GDCV for Bare Metal 模型。

  1. 基础架构:此层包括使用本地结构处理的存储、计算和网络操作。
  2. 数据管理:在本指南中,数据管理层需要一个 SQL 数据库,该数据库在部署的 Kubernetes 集群外部进行管理。
  3. 容器管理层:此层使用 GKE 集群
  4. 服务管理层:此层使用 Anthos Service Mesh
  5. 政策管理层:此层使用 Config SyncPolicy Controller
  6. 应用管理层:此层使用 Cloud BuildCloud Source Repositories
  7. 可观测性层:此层使用 Google Cloud ObservabilityAnthos Service Mesh 信息中心。

针对不同的生命周期环境(例如开发环境、预演环境和生产环境)在堆栈中重复上述每个层。

以下各部分仅包含特定于 GDCV for Bare Metal 的其他信息。它们根据《GKE Enterprise 架构基础指南》中各自的部分构建。建议您在阅读本文时查看该指南。

网络

如需详细了解网络要求,请参阅网络要求

GDCV for Bare Metal 负载均衡器有两个可用选项:捆绑式和手动。

在捆绑模式下,系统会在创建集群期间部署 L4 负载均衡软件。负载均衡器进程可以在工作器节点的专用池中运行,也可以在与控制平面相同的节点上运行。如需通告虚拟 IP 地址 (VIP),此负载均衡器有两个选项:

在手动模式下,您可以为控制平面和数据平面流量配置自己的负载均衡解决方案。有许多硬件和软件选项可用于外部负载均衡器。您必须先为控制平面设置外部负载均衡器,然后才能创建 Bare Metal 集群。外部控制平面负载均衡器也可用于数据平面流量,您也可以为数据平面设置单独的负载均衡器。如需确定可用性,负载均衡器必须能够根据可配置的就绪性检查将流量分配到节点池。

如需详细了解 GDCV for Bare Metal 的负载均衡器,请参阅负载均衡器概览

集群架构

GDCV for Bare Metal 支持多种部署模型,以满足不同的可用性、隔离和资源配额需求。选择部署模型中讨论了这些部署模型。

身份管理

GDCV for Bare Metal 使用 GKE Identity Service 与身份提供方集成。它支持 OpenID Connect (OIDC)轻量级目录访问协议 (LDAP)。对于应用和服务,Anthos Service Mesh 可用于各种身份解决方案。

如需详细了解身份管理,请参阅在 GDCV for Bare Metal 中使用 OIDC 进行身份管理使用 OIDC 进行身份验证使用 LDAP 设置 Anthos Identity Service

安全和政策管理

对于 GDCV for Bare Metal 安全和政策管理,我们建议您使用 Config Sync 和 Policy Controller。Policy Controller 让您可以在集群中创建和强制执行政策。Config Sync 会评估变更并将其应用于所有集群,以达到适当的状态。

服务

当您使用 GDCV for Bare Metal 的捆绑模式进行负载均衡时,可以创建 LoadBalancer 类型的服务。当您创建这些服务时,GDCV for Bare Metal 会将已配置的负载均衡器 IP 地址池中的 IP 地址分配给该服务。LoadBalancer 服务类型用于公开集群外部的南北流量的 Kubernetes 服务。使用 GDCV for Bare Metal 时,默认情况下还会在集群中创建 IngressGateway。您不能在手动模式中为 GDCV for Bare Metal 创建 LoadBalancer 类型的服务。但是,您可以创建一个使用 IngressGatewayIngress 对象,或创建 NodePort 类型的服务,并手动配置外部负载平衡器,以将 Kubernetes 服务用作后端。

对于服务管理(也称为东西流量),建议您使用 Anthos Service Mesh。Anthos Service Mesh 基于 Istio open API,可提供统一可观察性、身份验证、加密、精细的流量控制能力,以及其他特征与功能。如需详细了解服务管理,请参阅 Anthos Service Mesh

持久性和状态管理

GDCV for Bare Metal 主要依赖于现有的基础架构来实现临时存储、卷存储和 PersistentVolume 存储。临时数据使用安排了 Kubernetes Pod 的节点上的本地磁盘资源。对于永久性数据,GKE Enterprise 与容器存储接口 (CSI) 兼容,该接口是一种开放式标准 API,许多存储供应商都可支持。对于生产存储,我们建议安装 GKE Enterprise Ready 存储合作伙伴提供的 CSI 驱动程序。如需查看 GKE Enterprise Ready 存储合作伙伴的完整列表,请参阅 GKE Enterprise Ready 存储合作伙伴

如需详细了解存储,请参阅配置存储

数据库

GDCV for Bare Metal 只提供 GKE Enterprise 平台的标准功能,不提供其他特定于数据库的功能。大多数数据库都在外部数据管理系统上运行。GKE Enterprise 平台上的工作负载也可以配置为连接到任何可访问的外部数据库。

可观测性

Google Cloud Observability 按照与 GKE 集群的收集和监控政策类似的方式,收集有关 GDCV for Bare Metal 集群的日志和监控指标。默认情况下,集群日志和系统组件指标会发送到 Cloud Monitoring。如需让 Google Cloud Observability 收集应用日志和指标,请在集群配置 YAML 文件中启用 clusterOperations.enableApplication 选项。

如需详细了解可观测性,请参阅配置日志记录和监控

应用场景:Cymbal Bank 部署

在本指南中,我们使用 Cymbal Bank/Bank of Anthos 应用来模拟 GDCV for Bare Metal 的规划、平台部署和应用部署流程。

本文档的其余部分由三部分组成。规划部分概述了根据架构模型部分讨论的选项做出的决策。平台部署部分讨论了源代码库提供的用于部署 GKE Enterprise 平台的脚本和模块。最后在应用部署部分,在平台上部署 Cymbal Bank 应用。

本 GDCV for Bare Metal 指南可用于部署到自行管理的主机或 Compute Engine 实例上。通过使用 Google Cloud 资源,任何人都可以完成本指南,无需访问物理硬件。仅出于演示目的使用 Compute Engine 实例。请不要将这些实例用于生产工作负载。当可以访问物理硬件并且使用相同的 IP 地址范围时,您可以按原样使用提供的源代码库。如果环境与规划部分概述的环境不同,您可以修改脚本和模块以适应这些差异。关联源代码库包含物理硬件和 Compute Engine 实例场景的说明。

规划

下面的部分详细介绍了在规划和设计平台以在 GDCV for Bare Metal 上部署 Bank of GKE Enterprise 应用时作出的架构决策。这些部分重点介绍生产环境。如需构建开发或预演等级别更低的环境,您可以使用类似的步骤。

Google Cloud 项目

在 Google Cloud 中为 GDCV for Bare Metal 创建项目时,需要使用舰队宿主项目。建议为每个环境或业务功能使用其他项目。通过此项目配置,您可以根据与资源进行交互的角色来整理资源。

以下各部分介绍推荐的项目类型以及与之关联的角色。

Hub 项目

Hub 项目 hub-prod 适用于网络管理员角色。在此项目中,本地数据中心使用您选择的混合连接形式连接到 Google Cloud。如需详细了解混合连接选项,请参阅 Google Cloud 连接

队列宿主项目

舰队宿主项目 fleet-prod 适用于平台管理员角色。这是 GDCV for Bare Metal 注册的项目。与平台相关的 Google Cloud 资源也驻留在此项目中。这些资源包括 Google Cloud Observability、Cloud Source Repositories 等等。给定的 Google Cloud 项目只能关联单个舰队(或没有舰队)。此限制可强化使用 Google Cloud 项目在未受治理或未一起使用的资源之间实现更强的隔离。

应用或团队项目

应用或团队项目 app-banking-prod 适用于开发者角色。应用专用或团队专用的 Google Cloud 资源驻留在此项目中。该项目包含除 GKE 集群以外的所有组件。可能存在此项目类型的多个实例,具体取决于团队或应用的数量。通过为不同的团队创建单独的项目,您可以单独管理每个团队的 IAM、结算和配额。

网络

每个 GDCV for Bare Metal 集群都需要以下 IP 地址子网:

  1. 节点 IP 地址
  2. Kubernetes Pod IP 地址
  3. Kubernetes 服务/集群 IP 地址
  4. 负载平衡器 IP 地址(捆绑模式)

如需对每个集群中的 Kubernetes Pod 和服务子网使用相同的不可路由 IP 地址范围,请选择孤岛模式网络模型。在此配置中,Pod 可以直接在集群内相互通信,但无法直接从集群外部进行访问(使用 Pod IP 地址)。这种配置会在未连接到外部网络的网络内形成一个孤岛。集群在该孤岛内的各集群节点之间形成一个完整的节点到节点网格,从而让 Pod 能够直接访问该集群中的其他 Pod。

IP 地址分配

集群 节点 Pod 服务 负载均衡器
metal-admin-dc1-000-prod 10.185.0.0/24 192.168.0.0/16 10.96.0.0/12 不适用
metal-user-dc1a-000-prod 10.185.1.0/24 192.168.0.0/16 10.96.0.0/12 10.185.1.3-10.185.1.10
metal-user-dc1b-000-prod 10.185.2.0/24 192.168.0.0/16 10.96.0.0/12 10.185.2.3-10.185.2.10
metal-admin-dc2-000-prod 10.195.0.0/24 192.168.0.0/16 10.96.0.0/12 不适用
metal-user-dc2a-000-prod 10.195.1.0/24 192.168.0.0/16 10.96.0.0/12 10.195.1.3-10.195.1.10
metal-user-dc2b-000-prod 10.195.2.0/24 192.168.0.0/16 10.96.0.0/12 10.195.2.3-10.195.2.10

在孤岛模式下,请务必确保为 Kubernetes Pod 和服务选择的 IP 地址子网未被使用或者可从节点网络进行路由。

网络要求

如需为 GDCV for Bare Metal 提供无需配置的集成式负载均衡器,请在每个集群中使用捆绑式负载均衡器模式。当工作负载运行 LoadBalancer 服务时,系统会从负载平衡器池中分配一个 IP 地址。

如需详细了解捆绑式负载平衡器的要求和配置,请参阅负载平衡器概览配置捆绑式负载平衡

集群架构

对于生产环境,我们建议将管理员和用户集群部署模型与每个地理位置的一个管理员集群和两个用户集群结合使用,以实现 GDCV for Bare Metal 的最大冗余和容错能力。

我们建议每个生产环境至少使用四个用户集群。使用两个地理位置冗余的位置,每个位置包含两个容错集群。每个容错集群都有冗余硬件和冗余网络连接。减少集群数量会降低架构的冗余或容错能力。

为帮助确保高可用性,每个集群的控制层面使用 3 个节点。每个用户集群至少有三个工作器节点,您可以在这些节点之间分布工作负载,以降低节点离线时的影响。工作器节点的数量和大小在很大程度上取决于集群中运行的工作负载的类型和数量。如需查看每个节点的建议大小,请参阅为 GDCV for Bare Metal 配置硬件

下表介绍了此使用场景中推荐的 CPU 核心、内存和本地磁盘存储空间的节点容量。

节点容量
节点类型 CPU/vCPU 内存 存储
控制平面 8 核 32 GiB 256 GiB
工作器 8 核 64 GiB 512 GiB

如需详细了解机器前提条件和容量调整,请参阅集群节点机器前提条件

身份管理

对于身份管理,我们建议通过 GKE Identity Service 与 OIDC 集成。在源代码库中提供的示例中,本地身份验证用于简化要求。如果 OIDC 可用,您可以修改示例以使用它。如需了解详情,请参阅在 GDCV for Bare Metal 中使用 OIDC 进行身份管理

安全和政策管理

在 Cymbal Bank 应用场景中,Config Sync 和 Policy Controller 用于政策管理。系统会创建 Cloud Source Repositories 代码库来存储 Config Sync 使用的配置数据。用于安装和管理 Config Sync 和 Policy Controller 的 ConfigManagement Operator 需要具有对配置源代码库的只读权限。如需授予该访问权限,请使用可接受的身份验证形式。此示例使用 Google 服务账号。

服务

对于此使用场景中的服务管理,Anthos Service Mesh 用于提供分布式服务的构建基础。默认情况下,系统还会在处理标准 Kubernetes Ingress 对象的集群中创建 IngressGateway

持久性和状态管理

由于永久性存储很大程度上取决于现有基础架构,因此该用例不要求使用它。但是在其他情况下,我们建议您使用 GKE Enterprise Ready 存储合作伙伴的存储方案。如果有 CSI 存储选项,则可以按照供应商提供的说明在集群上安装该选项。对于概念验证和高级使用场景,您可以使用本地卷。但对于大多数应用场景,我们不建议在生产环境中使用本地卷。

数据库

GDCV for Bare Metal 上的许多有状态应用将数据库用作其永久性存储。有状态数据库应用需要访问数据库才能向客户端提供其业务逻辑。GDCV for Bare Metal 使用的 Datastore 类型没有任何限制。因此,数据存储决策应由开发者或关联的数据管理团队做出。由于不同的应用可能需要不同的数据存储区,因此这些数据存储区也可不受限制地使用。数据库可以在集群内、本地甚至云端进行管理。

Cymbal Bank 应用是一款可访问两个 PostgreSQL 数据库的有状态应用。数据库访问是通过环境变量配置的。即使从集群外部管理数据库,也需要能够从运行工作负载的节点访问 PostgreSQL 数据库。在此示例中,应用会访问现有的外部 PostgreSQL 数据库。当应用在平台上运行时,数据库是在外部管理的。因此,数据库不是 GKE Enterprise 平台的一部分。如果 PostgreSQL 数据库可用,请使用该数据库。否则,请为 Cymbal Bank 应用创建和使用 Cloud SQL 数据库。

可观测性

Cymbal Bank 应用场景中的每个集群都配置为让 Google Cloud Observability 收集系统组件和应用的日志及指标。您可以在 Monitoring 信息中心页面上查看由 Google Cloud Console 安装程序创建的多个 Cloud Monitoring 信息中心。如需详细了解可观测性,请参阅配置日志记录和监控以及适用于 GDCV for Bare Metal 的日志记录和监控的工作原理

平台部署

如需了解详情,请参阅 GitHub 源代码库中文档的部署平台部分。

应用部署

如需了解详情,请参阅 GitHub 源代码库中文档的部署应用部分。

后续步骤