本页面介绍了使用 Google Kubernetes Engine (GKE) 构建和优化批处理平台的最佳实践，包括以下最佳实践：
- 架构
- 作业管理
- 多租户
- 安全
- 排队
- 存储
- 性能
- 成本效益
- monitoring
GKE 提供了一个强大的框架，可用于编排批处理工作负载（例如数据处理、训练机器学习模型、运行科学模拟），以及其他高性能计算工作负载。
这些最佳实践适用于想要在 GKE 中部署批处理工作负载的平台管理员、云架构师和运维专业人员。 GKE 上的批处理平台的参考架构展示了本指南中讨论的许多最佳实践，并且可部署在您自己的 Google Cloud 项目中。
批处理工作负载的工作原理
批处理工作负载是一组无需用户干预即可完成运行的任务。如需定义任务，请使用 Kubernetes Job 资源。批处理平台会接收 Job，并按照接收的顺序将其排入队列。批处理平台中的队列会应用处理逻辑，例如优先级、配额和可分配资源。通过对批处理参数进行排队和自定义，Kubernetes 可让您优化可用资源的使用，最大限度地减少预定 Job 的空闲时间，并最大限度地节省费用。下图展示了可作为批处理平台一部分的 GKE 组件。
批处理平台管理
过去，批处理平台有两个主要用户角色：开发者和平台管理员：
- 开发者负责提交 Job，并指定程序、要处理的数据以及 Job 要求。然后，开发者会收到 Job 提交和唯一标识符的确认。作业完成后，开发者会收到通知，以及作业的所有输出或结果。
- 平台管理员负责管理高效且可靠的批处理平台并交付给开发者。
批处理平台必须满足以下要求：
- 平台资源已正确预配，以确保 Job 几乎不需要用户干预即可运行。
- 平台资源已根据组织的安全性和可观测性最佳实践进行配置。
- 平台资源尽可能高效地使用。如果出现资源争用，则先完成最重要的工作。
在 GKE 中准备批处理平台架构
GKE 环境由节点组成，节点是 Compute Engine 虚拟机 (VM)，它们组合在一起构成集群。
下表列出了在规划和设计批处理平台架构时的重要建议：
| 建议 | 资源 | |
|---|---|---|
| 选择 GKE 操作模式 |
GKE 提供以下操作模式：
|
|
| 为您的节点选择机器类型 |
GKE 支持以下 Compute Engine 虚拟机系列：
每个机器系列都与一个或多个 CPU 平台（例如来自 Intel 和 AMD 的 Arm 处理器和 x86 处理器）相关联。 了解目前可用于工作负载的选项。 |
|
| 为节点使用硬件加速器 |
您还可以在 GKE 中使用硬件加速器，例如图形处理器 (GPU) 和张量处理单元 (TPU)。 请考虑使用 GPU 分时策略，它允许多个容器在同一物理 GPU 上分时。此方法对于请求数量较少的爆发性同构 GPU 工作负载非常有用。用于对 GPU 进行分区的多实例 GPU，以同时在多个容器之间共享一个 GPU 资源。 |
|
| 在 Standard 集群上启用集群自动扩缩器 | GKE 会根据工作负载的需求自动调整给定节点池中的节点数量。您不需要手动添加或移除节点，也不需要过度预配节点池。您只需指定节点池的大小下限和上限。 我们建议您设置采用以下配置的集群自动扩缩器：
借助 Autopilot 集群，您无需担心预配节点或管理节点池，因为节点池会通过节点自动预配功能进行自动预配，并且会自动扩缩以满足工作负载的要求。 |
|
| 在发布渠道中注册集群 | GKE 可以自动管理集群版本和升级。根据您的版本采用模式，您可以在 GKE 可用渠道中注册集群。
如需了解详情，请参阅如何为集群选择最佳发布渠道 | |
| 定义要为集群排除的维护范围 | 定义升级范围排除期后，GKE 遵循长时间运行的批处理工作负载在完成之前不会因维护而中断。
如需了解详情，请参阅要排除的维护范围。 |
管理 Job 生命周期
在 Kubernetes 中，您可以在一组 Pod 中运行工作负载。Pod 是具有共享存储和网络资源的单个或多个容器组。Pod 由 Kubernetes 规范定义。
Job 会创建一个或多个 Pod，并继续重试执行这些 Pod，直到指定数量的 Pod 成功终止。Pod 完成后，Job 会跟踪成功的完成。当达到指定的成功完成次数时，Job 即告完成。
下表列出了在设计和管理 Job 时的重要建议：
| 建议 | 资源 |
|---|---|
| 选择 Job 完成模式 | 将完成模式指定为 Indexed。根据 Pod 的索引分配要处理的数据分区时，此配置非常有用。Job 的 Pod 会获得关联的完成索引。删除 Job 会清理它创建的 Pod。暂停作业会删除其活跃 Pod，直到作业再次恢复。
|
| 为定期计划的操作设置 CronJob | 使用 CronJob for GKE 执行定期计划的操作，例如备份、报告生成或计划为机器学习模型进行训练。 |
| 管理 Job 中的失败 | 定义 Kubernetes Pod 失败政策和 Pod 退避失败限制，以处理 Job 中可重试和不可重试的失败。此定义可避免因 Pod 中断而导致的不必要的 Pod 重试和Job 失败，从而降低集群资源消耗。例如，您可以配置抢占、API 发起的逐出或基于污点的逐出，这样不能容忍 |
| 将多个 Job 作为一个单元管理 | 使用 JobSet API 将多个 Job 作为一个单元进行管理来处理工作负载模式，例如一个驱动程序（或协调器）和多个工作器（例如 MPIJob），同时根据您的应用场景设置与常见模式一致的 Job 默认值。例如，您可以默认创建编入索引的 Job，为 Pod 的可预测完全限定域名 (FQDN) 创建无头服务，并设置关联的 Pod 失败政策。 |
| 延长不能容忍重启的 Pod 的运行时间 | 在 Pod 规范中将 Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict 注解设置为 false。集群自动扩缩器会遵循对 Pod 设置的逐出规则。如果节点包含具有 cluster-autoscaler.kubernetes.io/safe-to-evict 注解的 Pod，则这些限制可防止该节点被自动扩缩器删除。
如需了解详情，请参阅考虑 Pod 调度和中断。 |
管理多租户
GKE 集群多租户是在单个组织中按不同的用户或工作负载（称为租户）管理 GKE 资源的替代方案。管理 GKE 资源时，可能会遵循租户隔离、配额和限制范围或费用分配等条件。
下表列出了管理多租户时的重要建议：
| 建议 | 资源 |
|---|---|
| 使用命名空间管理租户隔离 | 您可以将每个租户及其 Kubernetes 资源分隔到各自的命名空间中。 |
| 使用政策强制执行租户隔离 | 定义政策来限制 API 访问权限、设置配额、限制资源用量以及限制允许容器执行的操作。这些政策的范围由命名空间确定。 |
| 设置 GKE 费用分配 | 使用 GKE 费用分配来获取命名空间中每个租户的集群资源请求的数据分析。 |
控制对批处理平台的访问权限
GKE 支持您微调集群上运行的工作负载的访问权限。
下表列出了管理访问权限和安全性时的重要建议
| 建议 | 资源 |
|---|---|
| 设置 Workload Identity Federation for GKE | GKE 可让 GKE 集群中的工作负载模拟 Identity and Access Management (IAM) 服务账号来访问 Google Cloud 服务。凭借适用于 GKE 的工作负载身份联合，工作负载可以安全地访问存储在 GKE 外部的 Secret。
如需了解详情，请参阅适用于 GKE 的工作负载身份联合和存储的访问 Secret。 |
| 设置集群网络隔离 | 使用其中的控制平面端点和工作器节点都可以具有内部 IP 地址的专用集群。您还可以更改使用 Private Service Connect 的现有公共集群的集群隔离。 |
| 使用安全强化型 GKE 节点 | 配置安全强化型 GKE 节点，提供强大、可验证的节点身份和完整性，以提高 GKE 节点的安全性。 |
| 物理隔离 | 出于安全考虑，工作负载可能需要更强的隔离。使用节点污点控制调度，以使用节点污点和工作负载容忍设置通过物理方式隔离节点池中的租户。这样可确保仅将适当的工作负载调度到这些节点池上。 |
排队和公平共享
如需控制资源消耗，您可以为每个租户分配资源配额限制、将传入 Job 排入队列，并按照接收顺序处理 Job。
下表列出了在管理批处理工作负载中的排队和公平共享时的重要建议：
| 建议 | 资源 |
|---|---|
| 使用 Kueue | Kueue 是一个 kubernetes 原生 Job 队列系统，用于 Kubernetes 集群中的批处理、高性能计算、机器学习和类似应用。为帮助在租户之间公平共享集群资源，Kueue 会管理配额以及 Job 使用配额的方式。Kueue 会做出以下决策：
如需了解如何实现 Job 排队系统，请参阅在 GKE 上通过命名空间之间的配额共享实现 Job 排队系统。 如需详细了解 Kueue，请参阅 Kueue 概念。 |
存储、性能和成本效益
高效使用 GKE 计算和存储资源可以降低费用。一种策略是合理调整计算实例并对其进行配置，以满足批处理需求，同时不会影响性能。
下表列出了在设计和管理存储并优化性能时的重要建议：
| 建议 | 资源 |
|---|---|
| 使用 Compute Engine Persistent Disk | 我们建议您使用以下 Compute Engine Persistent Disk 配置：
|
| 使用网络附加存储 | 将以下网络附加存储与 Persistent Disk 结合使用，以实现最佳存储性能：
|
| 定义 Pub/Sub | 您的批量工作负载还可以读取和写入数据。例如，您可以使用 Pub/Sub 并将结果写入在其中更新报告和数据中心的数据仓库（例如 BigQuery）。 我们建议您使用以下存储解决方案：
|
| 为工作负载指定调节参数 | 我们建议您使用以下配置：
|
| 优化工作负载网络和延迟时间 | GKE 支持为节点池使用紧凑布置政策，指定这些节点（以及在这些节点上运行的工作负载）应放置在一个可用区内彼此更靠近的物理位置。 这特别适合用于紧密耦合的高性能工作负载，其中构成工作负载的不同进程之间的低延迟是主要考虑因素。如需了解详情，请参阅紧凑布置。 |
| 使用 Spot 虚拟机 | Spot 虚拟机是一种价格低于标准 Compute Engine 虚拟机但不保证可用性的 Compute Engine 虚拟机 (VM) 实例。 我们建议您使用以下解决方案：
|
| 使用映像流式传输 | 使用映像流式传输拉取容器映像。GKE 会从符合条件的映像中流式传输数据。这样一来，您的工作负载便可以初始化，而无需等待整个映像下载完毕，从而显著缩短初始化时间并提升成本效益。 |
监控
GKE 集成了可观测性和日志记录工具，可帮助您监控集群的可靠性和效率。下表列出了启用和使用 GKE 可观测性工具时的重要建议：
| 建议 | 资源 |
|---|---|
| 使用 Prometheus | GKE 与 Google Cloud Observability 集成。自定义您希望 GKE 发送到 Cloud Logging 和 Cloud Monitoring 的指标 默认情况下，系统会为 GKE 集群启用 Google Cloud Managed Service for Prometheus。我们建议您使用代管式收集，以消除设置和维护 Prometheus 服务器的复杂性。 如需了解更多信息，请参阅 Managed Service for Prometheus。 |
| 使用 Cloud Monitoring 信息中心 | 使用适用于 GKE 的 Monitoring 信息中心简要了解集群和资源利用率，并深入分析和过滤各种指标和维度。 如需了解更多信息，请参阅观察 GKE 集群。 |