Google Cloud 上的跨孤岛和跨设备联邦学习

本文档介绍了两种参考架构，可帮助您在 Google Cloud 上使用 Google Kubernetes Engine (GKE) 创建联邦学习平台。本文档中介绍的参考架构和相关资源支持以下功能：

• 跨孤岛联邦学习
• 基于跨孤岛架构的跨设备联邦学习

本文档的目标受众群体是希望在Google Cloud上实现联邦学习应用场景的云架构师以及 AI 和机器学习工程师。本文档还面向评估是否在 Google Cloud上实现联邦学习的决策者。

架构

本部分中的图表展示了用于联邦学习的跨孤岛架构和跨设备架构。如需了解这些架构的不同应用，请参阅使用场景。

跨孤岛架构

下图展示了支持跨孤岛联邦学习的架构：

上图展示了一个简单的跨孤岛架构示例。 在该图中，所有资源都位于 Google Cloud组织中的同一项目内。这些资源包括本地客户端模型、全局客户端模型及其关联的联邦学习工作负载。

您可以修改此参考架构，以支持多种数据孤岛配置。联盟成员可以通过以下方式托管其数据孤岛：

• 在 Google Cloud上，位于同一 Google Cloud 组织和同一 Google Cloud项目中。
• 在 Google Cloud上，位于同一 Google Cloud 组织的不同Google Cloud 项目中。
• 在 Google Cloud上，位于不同 Google Cloud 组织中。
• 在私有的本地环境中或其他公有云中。

为使参与成员进行协作，他们需要在其环境之间建立安全通信通道。如需详细了解联邦学习中的参与成员的角色、他们如何进行协作以及他们彼此共享的内容，请参阅使用场景。

该架构包括以下组件：

• Virtual Private Cloud (VPC) 网络和子网。
• 专用 GKE 集群，可帮助您执行以下操作：
  • 将集群节点与互联网隔离。
  • 通过创建具有授权网络的专用 GKE 集群，限制集群节点和控制平面对互联网的公开。
  • 使用安全强化型集群节点，该节点使用安全加固的操作系统映像。
  • 启用 Dataplane V2 以优化 Kubernetes 网络。
• 专用 GKE 节点池：您可以创建专用节点池以专门托管租户应用和资源。节点具有污点，以确保只有租户工作负载调度到租户节点上。其他集群资源托管在主节点池中。

• 数据加密（默认处于启用状态）：

  • 静态数据。
  • 传输中的数据。
  • 应用层的集群 Secret。

• 使用中的数据加密，通过视需要启用机密 Google Kubernetes Engine 节点。

• 应用以下各项的 VPC 防火墙规则：

  • 适用于集群中所有节点的基准规则。
  • 仅适用于租户节点池中的节点的其他规则。这些防火墙规则限制了租户节点的入站流量和出站流量。

• Cloud NAT，用于允许出站流量流向互联网。

• Cloud DNS 记录，用于启用专用 Google 访问通道，以便集群中的应用无需通过互联网即可访问 Google API。

• 服务账号，如下所示：

  • 租户节点池中节点的专用服务账号。
  • 供租户应用与工作负载身份联合搭配使用的专用服务账号。

• 支持使用 Google 群组进行基于 Kubernetes 角色的访问控制 (RBAC)。

• 用于存储配置描述符的 Git 仓库。

• 用于存储容器映像的 Artifact Registry 仓库。

• 用于部署配置和政策的 Config Sync 和 Policy Controller。

• 用于选择性地允许集群入站和出站流量的 Cloud Service Mesh 网关。

• 用于存储全局和本地模型权重的 Cloud Storage 存储桶。

• 有权访问其他 Google 和 Google Cloud API。例如，训练工作负载可能需要访问存储在 Cloud Storage、BigQuery 或 Cloud SQL 中的训练数据。

跨设备架构

下图展示了支持跨设备联邦学习的架构：

上述跨设备架构基于跨孤岛架构构建，并添加了以下组件：

• 模拟设备连接到服务器的 Cloud Run 服务
• 用于为服务器和客户端创建私有证书以供运行的 Certificate Authority Service
• 用于直观呈现训练结果的 Vertex AI TensorBoard
• 用于存储合并模型的 Cloud Storage 存储桶
• 使用机密节点作为其主要池以帮助保护使用中的数据的专用 GKE 集群

跨设备架构使用来自开源联邦计算平台 (FCP) 项目的组件。此项目包含以下内容：

• 用于与服务器通信并在设备上执行任务的客户端代码
• 用于客户端-服务器通信的协议
• 与 TensorFlow Federated 的连接点，可让您更轻松地定义联邦计算

上图所示的 FCP 组件可以部署为一组微服务。这些组件执行以下操作：

• 聚合器：此作业可读取设备梯度并使用差分隐私计算聚合结果。
• 收集器：此作业定期运行，用于查询活跃任务和加密梯度。此信息用于确定何时开始汇总。
• 模型上传者：此作业会监听事件并发布结果，以便设备可以下载更新后的模型。
• 任务分配：此前端服务将训练任务分配给设备。
• 任务管理：此作业管理任务。
• 任务调度器：此作业定期运行或由特定事件触发。

使用的产品

两个联邦学习应用场景的参考架构都使用以下 Google Cloud 组件：

• Google Cloud Kubernetes Engine (GKE)：GKE 为联邦学习提供基础平台。
• TensorFlow Federated (TFF)：TFF 提供了一个开源框架，用于对分散式数据进行机器学习和其他计算。

GKE 还为您的联邦学习平台提供以下功能：

• 托管联邦学习协调者：联邦学习协调者负责管理联邦学习流程。 此管理包括将全局模型分发给参与者、汇总参与者的更新以及更新全局模型等任务。GKE 可用于以高可用性和可扩缩的方式托管联邦学习协调者。
• 托管联邦学习参与者：联邦学习参与者负责使用本地数据训练全局模型。GKE 可用于以安全且隔离的方式托管联邦学习参与者。这种方法有助于确保参与者的数据保留在本地。
• 提供安全且可扩缩的通信通道：联邦学习参与者需要能够以安全且可扩缩的方式与联邦学习协调者通信。GKE 可用于在参与者和协调者之间提供安全且可扩缩的通信通道。
• 管理联邦学习部署的生命周期：GKE 可用于管理联邦学习部署的生命周期。此管理包括预配资源、部署联邦学习平台和监控联邦学习平台性能等任务。

除了上述优势之外，GKE 还提供许多可用于联邦学习部署的功能，例如：

• 区域级集群：GKE 可让您创建区域级集群，通过缩短参与者和协调者之间的延迟时间来帮助提高联邦学习部署的性能。
• 网络政策：GKE 可让您创建网络政策，通过控制参与者和协调者之间的流量来帮助提高联邦学习部署的安全性。
• 负载均衡：GKE 提供了许多负载均衡选项，通过在参与者和协调者之间分配流量来帮助提高联邦学习部署的可伸缩性。

TFF 提供以下功能，以便于实现联邦学习应用场景：

• 能够以声明方式表明联邦计算，即在一台服务器和一组客户端上运行的一组处理步骤。这些计算可以部署到不同的运行时环境中。
• 可以使用 TFF 开放源代码构建自定义聚合器。
• 支持多种联邦学习算法，包括以下算法：
  • 联邦平均：一种对参与客户端的模型参数进行平均的算法。它特别适合数据相对同构且模型不太复杂的应用场景。典型应用场景如下：
    • 个性化推荐：公司可以使用联邦平均来训练模型，以便根据用户的购买历史记录向用户推荐产品。
    • 欺诈检测：银行联盟可以使用联合平均来训练检测欺诈性交易的模型。
    • 医疗诊断：一组医院可以使用联合平均来训练一个诊断癌症的模型。
  • 联邦随机梯度下降法 (FedSGD)：一种使用随机梯度下降法更新模型参数的算法。它非常适合数据异构且模型复杂的应用场景。典型应用场景如下：
    • 自然语言处理：公司可以使用 FedSGD 训练模型，以提高语音识别的准确率。
    • 图片识别：公司可以使用 FedSGD 训练模型，以识别图片中对象。
    • 预测性维护：公司可以使用 FedSGD 训练模型，以预测机器可能发生故障的时间。
  • 联邦 Adam：一种使用 Adam 优化器更新模型参数的算法。 典型应用场景如下：
    • Recommender 系统：公司可以使用联邦 Adam 训练模型，以根据用户购买历史记录向用户推荐产品。
    • 排名：公司可以使用联邦 Adam 训练模型，以对搜索结果进行排名。
    • 点击率预测：公司可以使用联邦 Adam 训练模型，以预测用户点击广告的可能性。

使用场景

本部分介绍了适合为联邦学习平台选择跨孤岛和跨设备架构的应用场景。

联邦学习是一种机器学习设置，其中许多客户端通过协作来训练模型。此流程由中央协调者主导，训练数据保持分散式。

在联邦学习范式中，客户端下载全局模型，并通过在本地使用数据进行训练来改进模型。然后，每个客户端都会将计算出的模型更新发送回中央服务器，在该服务器上，模型更新会汇总，并生成新全局模型迭代。在这些参考架构中，模型训练工作负载在 GKE 上运行。

联邦学习通过以下方式遵循数据最小化的隐私原则：限制在每个计算阶段收集哪些数据、限制对数据的访问以及处理并尽早舍弃数据。此外，联邦学习的问题设置还可与额外的隐私保护技术兼容，例如使用差分隐私 (DP) 来改进模型匿名化，以确保最终模型不会记住单个用户的数据。

根据应用场景的不同，使用联邦学习训练模型可带来以下额外优势：

• 合规性：在某些情况下，法规可能会限制数据的使用或共享方式。联合学习可用于遵守这些法规。
• 通信效率：在某些情况下，使用分布式数据训练模型比集中处理数据更高效。例如，模型需要训练的数据集过大，无法集中移动。
• 实现数据可访问性：借助联邦学习，组织可以将训练数据分散在每个用户或每个组织的数据孤岛中。
• 更高的模型准确率：通过使用真实用户数据（同时确保隐私权）而非合成数据（有时称为代理数据）进行训练，通常可以提高模型准确率。

联邦学习有不同种类，其特征是数据的来源位置以及本地计算发生的位置。本文档中的架构侧重于两种类型的联邦学习：跨孤岛和跨设备。其他类型的联邦学习不在本文档的讨论范围内。

联邦学习还可以根据数据集的分区方式进一步分类，如下所示：

• 横向联邦学习 (HFL)：具有相同特征（列）但样本（行）不同的数据集。例如，多家医院的患者记录可能具有相同的医疗参数，但患者群体不同。
• 纵向联邦学习 (VFL)：具有相同样本（行）但特征（列）不同的数据集。例如，银行和电子商务公司的客户数据可能包含重叠的个人信息，但财务和购买信息不同。
• 联邦迁移学习 (FTL)：数据集之间的样本和特征存在部分重叠。例如，两家医院的患者记录可能包含一些重叠的个人信息和一些共享的医疗参数，但每个数据集也包含唯一的特征。

跨孤岛联邦计算是指参与成员为组织或公司。在实践中，成员数量通常较少（例如，不超过 100 个成员）。跨孤岛计算通常用于以下场景：参与组织拥有不同的数据集，但希望训练共享模型或分析汇总结果，而无需相互共享原始数据。例如，参与成员的环境可以位于不同的 Google Cloud 组织中（例如，当他们代表不同的法律实体时），也可以位于同一Google Cloud 组织中（例如，当他们代表同一法律实体的不同部门时）。

参与的成员可能无法将彼此的工作负载视为受信任实体。例如，参与成员可能无法访问从第三方（例如协调者）收到的训练工作负载的源代码。由于参与成员无法访问此源代码，因此无法确保工作负载完全受信任。

为帮助您防止不受信任的工作负载在未经授权的情况下访问您的数据或资源，我们建议您执行以下操作：

• 在隔离的环境中部署不受信任的工作负载。
• 仅向不受信任的工作负载授予完成分配给该工作负载的训练轮次必需的访问权限和许可。

为了帮助您隔离可能不受信任的工作负载，这些参考架构会实施安全控制措施，例如配置隔离的 Kubernetes 命名空间，其中每个命名空间都有一个专用的 GKE 节点池。默认情况下，系统会禁止跨命名空间通信以及集群入站和出站流量，除非您明确覆盖此设置。

以下是跨孤岛联邦学习的一些应用场景示例：

• 欺诈检测：联邦学习可用于根据分布在多个组织中的数据训练欺诈检测模型。例如，银行联盟可以使用联邦学习来训练检测欺诈性交易的模型。
• 医疗诊断：联邦学习可用于根据分布在多家医院的数据训练医疗诊断模型。例如，一组医院可以使用联邦学习来训练一个诊断癌症的模型。

跨设备联邦学习是一种联邦计算，参与成员是最终用户设备，例如手机、车辆或 IoT 设备。成员人数可达数百万甚至数千万。

跨设备联邦学习的流程与跨孤岛联邦学习的流程类似。不过，您还需要调整参考架构，以适应在处理数千到数百万台设备时必须考虑的一些额外因素。您必须部署管理工作负载，以处理跨设备联邦学习应用场景中遇到的情况。例如，需要协调将在训练轮次中使用的部分客户端。借助跨设备架构，您可以通过部署 FCP 服务来实现此功能。这些服务具有与 TFF 存在连接点的工作负载。TFF 用于编写管理此协调的代码。

以下是跨设备联邦学习的一些应用场景示例：

• 个性化推荐：您可以使用跨设备联邦学习，根据分布在多个设备中的数据训练个性化推荐模型。例如，公司可以使用联邦学习来训练模型，以根据用户的购买历史记录向用户推荐产品。
• 自然语言处理：联邦学习可用于根据分布在多个设备中的数据来训练自然语言处理模型。例如，公司可以使用联邦学习来训练模型，以提高语音识别的准确率。
• 预测车辆维护需求：联邦学习可用于训练模型，以预测车辆可能需要维护的时间。 此模型可以根据从多辆车收集的数据进行训练。这种方法使模型能够从所有车辆的体验中学习，同时不会影响任一车辆的隐私。

下表总结了跨孤岛架构和跨设备架构的特征，并展示了如何对适用于您的应用场景的联邦学习方案类型进行分类。

功能	跨孤岛联邦计算	跨设备联邦计算
群体规模	通常较小（例如，不超过 100 台设备）	可扩缩到数千、数百万或数亿台设备
参与的成员	组织或公司	移动设备、边缘设备、车辆
最常见的数据分区	HFL、VFL、FTL	HFL
数据敏感度	参与者不希望以原始格式相互共享的敏感数据	过于敏感而无法与中央服务器共享的数据
数据可用性	参与者几乎总是处于有空状态	任何时候只有一部分参与者有空
实际使用示例	欺诈检测、医疗诊断、财务预测	健身追踪、语音识别、图片分类

设计考虑事项

本部分提供的指导可帮助您使用此参考架构开发一个或多个架构，以满足您在安全性、可靠性、运营效率、费用和性能方面的特定要求。

跨孤岛架构设计注意事项

如需在Google Cloud中实现跨孤岛联邦学习架构，您必须满足以下最低前提条件，详情请参阅以下各部分：

1. 建立联邦学习联盟。
2. 确定联邦学习联盟要实现的协作模型。
3. 确定参与者组织的责任。

除了这些前提条件之外，联盟所有者还必须执行其他不在本文档讨论范围内的操作，例如：

• 管理联邦学习联盟。
• 设计和实现协作模型。
• 准备、管理和操作模型训练数据以及联盟所有者打算训练的模型。
• 创建、容器化和编排联邦学习工作流。
• 部署和管理联邦学习工作负载。
• 为参与者组织设置通信通道，以便安全地转移数据。

建立联邦学习联盟

联邦学习联盟是指参与跨孤岛联邦学习工作的组织群组。联盟中的组织仅共享机器学习模型的参数，并且您可以加密这些参数以提高隐私性。如果联邦学习联盟允许这一做法，则组织还可以汇总不包含个人身份信息 (PII) 的数据。

确定联邦学习联盟的协作模型

联邦学习联盟可以实现不同的协作模型，例如：

• 由称为联盟所有者或编排者的单个协调组织以及一组参与者组织或数据所有者组成的集中式模型。
• 由作为一个群组进行协调的组织组成的分散式模型。
• 由各种参与组织的联盟组成的异构模型，所有这些组织为联盟提供不同的资源。

本文档假设协作模型是集中式模型。

确定参与者组织的责任

为联邦学习联盟选择协作模型后，联盟所有者必须确定参与者组织的责任。

在开始组建联邦学习联盟时，联盟所有者还必须执行以下操作：

• 协调联邦学习工作。
• 设计和实现全局机器学习模型以及与参与者组织共享的机器学习模型。
• 定义联邦学习轮次（即机器学习训练过程的迭代方法）。
• 选择为任何给定联邦学习轮次作贡献的参与者组织。此选择结果称为同类群组。
• 为参与者组织设计和实现联盟成员资格验证流程。
• 更新全局机器学习模型以及与参与者组织共享的机器学习模型。
• 为参与者组织提供工具，以验证联邦学习联盟符合其隐私权、安全和监管要求。
• 为参与者组织提供安全且加密的通信通道。
• 为参与者组织提供完成每轮联邦学习所需的所有必要的非机密汇总数据。

参与者组织承担以下责任：

• 提供并维护安全、隔离环境（孤岛）。孤岛是指参与者组织存储自己的数据以及实现机器学习模型训练的位置。 参与者组织不会与其他组织共享自己的数据。
• 使用自己的计算基础架构和自己的本地数据训练联盟所有者提供的模型。
• 移除任何个人身份信息后，以汇总数据的形式与联盟所有者共享模型训练结果。

联邦所有者和参与者组织可以使用 Cloud Storage 来共享更新后的模型和训练结果。

联盟所有者和参与者组织会优化机器学习模型训练，直到模型满足其要求。

在 Google Cloud上实现联邦学习

建立联邦学习联盟并确定其协作方式后，我们建议参与者组织执行以下操作：

1. 为联邦学习联盟预配和配置必要的基础设施。
2. 实现协作模型。
3. 开始联邦学习。

为联邦学习联盟预配和配置基础架构

在为联邦学习联盟预配和配置基础架构时，联盟所有者负责创建用于训练联邦机器学习模型的工作负载并将其分发到参与者组织。由于第三方（联盟所有者）创建并提供了工作负载，因此参与者组织在运行时环境中部署这些工作负载时必须采取预防措施。

参与者组织必须根据各自的安全最佳实践配置其环境，并应用控制措施来限制授予每个工作负载的范围和权限。除了遵循各自的安全最佳实践之外，我们还建议联盟所有者和参与者组织考虑特定于联邦学习的威胁矢量。

实现协作模型

联邦学习联盟基础架构准备就绪后，联盟所有者会设计并实现使参与者组织能够彼此交互的机制。该方法遵循联盟所有者为联邦学习联盟选择的协作模型。

开始联邦学习

实现协作模型后，联盟所有者会实现要训练的全局机器学习模型，以及与参与者组织共享的机器学习模型。这些机器学习模型准备就绪后，联盟所有者会开始第一轮联邦学习。

在每轮联邦学习中，联盟所有者会执行以下操作：

1. 分发要与参与者组织共享的机器学习模型。
2. 等待参与者组织提供联盟所有者共享的机器学习模型的训练结果。
3. 收集并处理参与者组织生成的训练结果。
4. 在接收到参与组织的适当训练结果后，更新全局机器学习模型。
5. 更新要在适当情况下与其他联盟成员共享的机器学习模型。
6. 为下一轮联邦学习准备训练数据。
7. 开始下一轮联邦学习。

安全性、隐私权和合规性

本部分介绍使用此参考架构在Google Cloud上设计和构建联邦学习平台时应考虑的因素。本指导适用于本文档中所述的两种架构。

您在环境中部署的联邦学习工作负载可能会将您、数据、联邦学习模型和基础设施暴露在可能影响您的业务的威胁中。

为了帮助您提高联邦学习环境的安全性，这些参考架构会配置专注于环境基础架构的 GKE 安全控制措施。这些控制措施可能不足以保护您免受特定于联邦学习工作负载和使用场景的威胁。鉴于每种联邦学习工作负载和应用场景的特殊性，本文档不讨论旨在保护联邦学习实现的安全性控制措施。如需详细了解这些威胁并查看其示例，请参阅联邦学习安全注意事项。

GKE 安全控制措施

本部分讨论通过这些架构应用的可帮助您保护 GKE 集群的控制措施。

增强 GKE 集群的安全性

这些参考架构可帮助您创建实现以下安全设置的 GKE 集群：

• 通过创建具有授权网络的专用 GKE 集群，限制集群节点和控制平面对互联网的公开。
• 使用安全强化型节点，它将安全强化的节点映像与 containerd 运行时搭配使用。
• 使用 GKE Sandbox 提高了租户工作负载的隔离性。
• 默认对静态数据进行加密。
• 默认对传输中的数据进行加密。
• 在应用层对集群 Secret 加密。
• （可选）通过启用机密 Google Kubernetes Engine 节点来加密使用中的数据。

如需详细了解 GKE 安全设置，请参阅加固集群的安全性和安全状况信息中心简介。

VPC 防火墙规则

Virtual Private Cloud (VPC) 防火墙规则决定允许哪些流量进出 Compute Engine 虚拟机。这些规则让您可以根据第 4 层属性，在虚拟机粒度级别过滤流量。

您可以使用默认 GKE 集群防火墙规则创建 GKE 集群。这些防火墙规则支持集群节点与 GKE 控制平面之间的通信，以及集群中节点与 Pod 之间的通信。

您可以对租户节点池中的节点应用其他防火墙规则。这些防火墙规则限制来自租户节点的出站流量。此方法可以增强租户节点的隔离性。默认情况下，系统会拒绝来自租户节点的所有出站流量。必须明确配置任何必需的出站流量。例如，您可以创建防火墙规则，以允许从租户节点流向 GKE 控制平面的出站流量，以及使用专用 Google 访问通道流向 Google API 的出站流量。防火墙规则使用租户节点池的服务账号面向租户节点。

命名空间

借助命名空间，您可以为集群内的相关资源（例如 Pod、Service 和副本控制器）提供范围。通过使用命名空间，您可以将相关资源的管理责任作为一个单元进行委派。因此，命名空间是大多数安全模式不可或缺的一部分。

命名空间是控制平面隔离的一项重要功能。不过，它们不提供节点隔离、数据平面隔离和网络隔离。

一种常用的方法是为各个应用创建命名空间。例如，您可以为应用的界面组件创建命名空间 myapp-frontend。

这些参考架构可帮助您创建专用命名空间来托管第三方应用。命名空间及其资源被视为集群中的租户。您可将政策和控制措施应用于命名空间，以限制命名空间中的资源范围。

网络政策

网络政策使用 Pod 级防火墙规则强制控制第 4 层网络流量的流动。网络政策的范围限定为命名空间。

在本文档介绍的参考架构中，您将网络政策应用于托管第三方应用的租户命名空间。默认情况下，网络政策会拒绝进出命名空间中 pod 的所有流量。任何必需的流量都必须明确添加到许可清单中。例如，这些参考架构中的网络政策明确允许流量传输到所需的集群服务，例如集群内部 DNS 和 Cloud Service Mesh 控制平面。

Config Sync

Config Sync 使您的 GKE 集群与存储在可靠来源中的配置保持同步。Git 代码库充当您的集群配置和政策的单一数据源。Config Sync 以声明式方法运作。它会持续检查集群状态，并应用配置文件中声明的状态来强制实施政策，这有助于防止配置偏移。

将 Config Sync 安装到 GKE 集群中。您可以配置 Config Sync 以同步可靠来源中的集群配置和政策。同步的资源包括以下内容：

• 集群级 Cloud Service Mesh 配置
• 集群级安全政策
• 租户命名空间级配置和政策，包括网络政策、服务账号、RBAC 规则和 Cloud Service Mesh 配置

Policy Controller

Policy Controller是一个 Kubernetes 动态准入控制器，用于强制实施由 Open Policy Agent (OPA) 执行的基于 CustomResourceDefinition（基于 CRD）的政策。

准入控制器是 Kubernetes 插件，用于在对象持久保留之前，但在请求经过身份验证和授权之后拦截对 Kubernetes API 服务器的请求。您可以使用准入控制器来限制集群的使用方式。

您将 Policy Controller 安装到 GKE 集群中。这些参考架构包含有助于保护集群的示例政策。您可以使用 Config Sync 将政策自动应用到集群。您应用以下政策：

• 有助于强制执行 Pod 安全性的所选政策。例如，您应用的政策会阻止 Pod 运行特权容器，并且需要只读根文件系统。
• Policy Controller 模板库中的政策。例如，您应用禁止类型为 NodePort 的服务的政策。

Cloud Service Mesh

Cloud Service Mesh 是一种服务网格，可帮助您简化对跨服务安全通信的管理。这些参考架构配置了 Cloud Service Mesh，使其能够执行以下操作：

• 自动注入边车代理。
• 强制在网格中的服务之间执行 mTLS 通信。
• 将出站网格流量限制到已知主机上。
• 限制入站流量仅来自特定客户端。
• 可让您根据服务身份而不是网络上对等方的 IP 地址来配置网络安全政策。
• 限制网格中服务之间的授权通信。例如，租户命名空间中的应用只能与同一命名空间或一组已知外部主机中的应用通信。
• 通过网格网关路由所有入站和出站流量，您可以在该网关中应用进一步的流量控制。
• 支持集群之间的安全通信。

节点污点和亲和性

节点污点和节点亲和性是 Kubernetes 机制，可让您影响 pod 被安排到集群节点上的方式。

污点节点会逐出 pod。Kubernetes 不会将 pod 调度到污点节点上，除非 pod 对污点有容忍。您可以使用节点污点来保留节点，以便仅供某些工作负载或租户使用。多租户集群通常使用污点和容忍。如需了解详情，请参阅具有污点和容忍设置的专用节点文档。

通过节点亲和性，您可以将 pod 限制为具有特定标签的节点。如果 pod 具有节点亲和性要求，Kubernetes 不会将 pod 调度到节点上，除非该节点的标签与亲和性要求一致。您可以使用节点亲和性来确保将 pod 调度到适当的节点上。

您可以将节点污点和节点亲和性结合使用，以确保租户工作负载 pod 专门调度到为租户预留的节点上。

这些参考架构可帮助您通过以下方式控制租户应用的调度：

• 创建专用于租户的 GKE 节点池。池中的每个节点都有一个与租户名称相关的污点。
• 自动将适当的容忍和节点亲和性应用于以租户命名空间为目标的任何 pod。您可以使用 PolicyController 变更来应用容忍和亲和性。

最小权限

为您的Google Cloud 项目和资源（如 GKE 集群）采用最小权限原则是安全方面的一种最佳实践。通过使用此方法，在集群内运行的应用以及使用集群的开发者和运营商仅具有所需的一组最低权限。

这些参考架构可帮助您通过以下方式使用最小权限服务账号：

• 每个 GKE 节点池都会收到自己的服务账号。例如，租户节点池中的节点会使用专用于这些节点的服务账号。节点服务账号配置了所需的最低权限。
• 集群使用 Workload Identity Federation for GKE 将 Kubernetes 服务账号与 Google 服务账号相关联。这样，租户应用便可以获得对任何所需 Google API 的有限访问权限，而无需下载和存储服务账号密钥。例如，您可以向服务账号授予从 Cloud Storage 存储桶读取数据的权限。

这些参考架构可帮助您通过以下方式限制对集群资源的访问权限：

• 您可以创建具有有限权限来管理应用的示例 Kubernetes RBAC 角色。您可以向在租户命名空间中运行应用的用户和群组授予此角色。通过应用此有限的用户和群组角色，这些用户仅有权修改租户命名空间中的应用资源。他们无权修改集群级资源或敏感安全设置（例如 Cloud Service Mesh 政策）。

Binary Authorization

借助 Binary Authorization，您可以强制执行针对 GKE 环境中部署的容器映像所定义的政策。Binary Authorization 仅允许部署符合您定义的政策的容器映像。它不允许部署任何其他容器映像。

在此参考架构中，Binary Authorization 采用默认配置启用。如需检查 Binary Authorization 默认配置，请参阅导出 YAML 格式的政策文件。

如需详细了解如何配置政策，请参阅以下具体指导：

• Google Cloud CLI
• Google Cloud 控制台
• REST API
• google_binary_authorization_policy Terraform 资源

跨组织证明验证

您可以使用 Binary Authorization 来验证第三方签名者生成的证明。例如，在跨孤岛联邦学习使用场景中，您可以验证其他参与者组织创建的证明。

如需验证第三方创建的证明，请执行以下操作：

1. 接收第三方用于创建您需要验证的证明的公钥。
2. 创建证明者以验证证明。
3. 将您从第三方收到的公钥添加到您创建的证明者中。

如需详细了解如何创建证明者，请参阅以下具体指导：

• Google Cloud CLI
• Google Cloud 控制台
• REST API
• google_binary_authorization_attestor Terraform 资源

联邦学习安全注意事项

尽管具有严格的数据共享模型，但联邦学习本身并不能防范所有定向攻击，因此在部署本文档中描述的任一架构时，您都应考虑这些风险。机器学习模型或模型训练数据也存在意外泄露信息的风险。例如，攻击者可能会有意危害全局机器学习模型或多轮联邦学习，或者可能会执行计时攻击（一种边信道攻击）来收集有关训练数据集大小的信息。

针对联邦学习实现的最常见威胁如下所示：

• 有意或无意的训练数据记忆。您的联邦学习实现或攻击者可能会有意或无意地以很难使用的方式存储数据。攻击者可能会通过对存储的数据进行逆向工程来收集有关全局机器学习模型或联邦学习过往轮次的信息。
• 从全局机器学习模型的更新中提取信息。在联邦学习期间，攻击者可能会对联盟所有者从参与者组织和设备收集的全局机器学习模型更新进行逆向工程。
• 联盟所有者可能会泄露轮次。受到攻击的联盟所有者可能会控制恶意孤岛或设备并开始一轮联邦学习。在这一轮结束时，受到攻击的联盟所有者也许能够将这些更新与恶意孤岛生成的更新进行比较，从而收集有关其从合法参与者组织和设备收集的更新的信息。
• 参与者组织和设备可能会破坏全局机器学习模型。在联邦学习期间，攻击者可能会尝试生成恶意或不合逻辑的更新，以恶意影响全局机器学习模型的性能、质量或完整性。

为了帮助缓解本部分所述威胁的影响，我们建议遵循以下最佳实践：

• 调优模型，将训练数据的记忆降至最低。
• 实现隐私权保护机制。
• 定期审核全局机器学习模型、您打算共享的机器学习模型、训练数据，以及您为达到联邦学习目标而实现的基础设施。
• 实现安全聚合算法，以处理参与者组织生成的训练结果。
• 使用公钥基础架构安全地生成和分发数据加密密钥。
• 将基础设施部署到机密计算平台。

联盟所有者还必须执行以下额外的步骤：

• 验证每个参与者组织的身份和每个孤岛的完整性（如果采用跨孤岛架构），以及每个设备的身份和完整性（如果采用跨设备架构）。
• 将更新的范围限制为参与者组织和设备可以生成的全局机器学习模型。

可靠性

本部分介绍使用本文档中的任一参考架构在 Google Cloud上设计和构建联邦学习平台时应考虑的设计因素。

在 Google Cloud上设计联邦学习架构时，我们建议您遵循本部分中的指导来提高工作负载的可用性和可伸缩性，并使架构能够应对服务中断和灾难。

GKE：GKE 支持多种不同的集群类型，您可以根据工作负载的可用性要求和预算来选择合适的集群类型。例如，您可以创建区域级集群以在一个区域内的多个可用区中分布控制平面和节点，也可以创建在单个可用区中具有控制平面和节点的可用区级集群。跨孤岛和跨设备参考架构都依赖于区域级 GKE 集群。如需详细了解创建 GKE 集群时需要考虑的方面，请参阅集群配置选项。

根据集群类型以及控制平面和集群节点在区域和可用区中的分布方式，GKE 提供不同的灾难恢复功能，以保护您的工作负载免受可用区级和区域级服务中断的影响。如需详细了解 GKE 的灾难恢复功能，请参阅针对云基础设施服务中断设计灾难恢复架构：Google Kubernetes Engine。

Google Cloud Load Balancing：GKE 支持多种将流量负载均衡到工作负载的方式。Kubernetes Gateway 和 Kubernetes Service API 的 GKE 实现可让您自动预配和配置 Cloud Load Balancing，以便安全可靠地公开 GKE 集群中运行的工作负载。

在这些参考架构中，所有入站和出站流量都通过 Cloud Service Mesh 网关。这些网关意味着您可以严格控制流量在 GKE 集群内外的流动方式。

跨设备联邦学习的可靠性挑战

跨设备联邦学习存在许多在跨孤岛场景中不会遇到的可靠性挑战。其中包括：

• 设备连接不可靠或断断续续
• 设备存储空间有限
• 计算资源和内存有限

不可靠的连接可能会导致以下问题：

• 更新过时和模型差异：当设备连接断断续续时，其本地模型更新可能会过时，表示与全局模型的当前状态相比过时的信息。汇总过时的更新可能会导致模型偏差，即全局模型因训练过程中的不一致而偏离最佳解决方案。
• 贡献不平衡和模型有偏差：断断续续的通信可能导致参与设备的贡献分布不均匀。连接状况欠佳的设备可能会贡献较少的更新，从而导致底层数据分布的表示不平衡。这种不平衡可能会使全局模型偏向于来自连接更可靠的设备的数据。
• 增加了通信开销和能耗：断断续续的通信可能导致通信开销增加，因为设备可能需要重新发送丢失或损坏的更新。此问题还会增加设备的功耗，尤其是对于电池续航时间有限的设备，因为这类设备可能需要较长时间保持活跃连接，以确保成功传输更新。

为了帮助缓解由断断续续的通信导致的一些影响，本文档中的参考架构可与 FCP 搭配使用。

执行 FCP 协议的系统架构可以设计为满足以下要求：

• 处理长时间运行的轮次。
• 启用推测性执行（在预期很快会有更多客户端签到的情况下，即使尚未达到所需的客户端数量，也可以开始轮次）。
• 使设备能够选择要参与的任务。这种方法可以实现不放回抽样等功能，这是一种抽样策略，其中每个总体样本单位只有一次被选中的机会。这种方法有助于减少不平衡的贡献和有偏差的模型
• 可针对差分隐私 (DP) 和可信聚合 (TAG) 等匿名化技术进行扩展。

为了帮助缓解设备存储空间和计算能力有限的问题，以下技巧可能会有所帮助：

• 了解可用于运行联邦学习计算的容量上限
• 了解在任何特定时间可以保留的数据量
• 设计客户端联邦学习代码，以在客户端可用的计算资源和 RAM 中运行
• 了解存储空间用尽的影响，并实施相关的管理流程

费用优化

本部分提供了指导，以优化您使用此参考架构在 Google Cloud 上创建和运行联邦学习平台的费用。此指导适用于本文档中所述的两种架构。

在 GKE 上运行工作负载有助于您根据工作负载的资源要求来预配和配置集群，从而优化环境的费用。它还支持动态重新配置集群和集群节点的功能，例如自动扩缩集群节点和 Pod，以及合理调整集群大小。

如需详细了解如何优化 GKE 环境的费用，请参阅在 GKE 上运行费用经过优化的 Kubernetes 应用的最佳实践。

运营效率

本部分介绍使用此参考架构在 Google Cloud上创建和运行联邦学习平台时应考虑哪些因素来优化效率。此指导适用于本文档中所述的两种架构。

为了提高联邦学习架构的自动化和监控，我们建议您采用 MLOps 原则，这些原则是机器学习系统情境下的 DevOps 原则。实施 MLOps 意味着您将在机器学习系统构建流程的所有步骤（包括集成、测试、发布、部署和基础设施管理）中实现自动化和监控。如需详细了解 MLOps，请参阅 MLOps：机器学习中的持续交付和自动化流水线。

性能优化

本部分介绍在使用此参考架构在 Google Cloud上创建和运行联邦学习平台时应考虑哪些因素来优化工作负载的性能。此指导适用于本文档中所述的两种架构。

GKE 支持多项功能来自动和手动合理调整和扩缩 GKE 环境的规模，以满足工作负载的需求，并帮助您避免过度预配资源。例如，您可以使用 Recommender 生成分析洞见和建议，以优化 GKE 资源用量。

在考虑如何扩缩 GKE 环境时，我们建议您针对环境和工作负载的扩缩方式制定短期、中期和长期计划。例如，您打算在未来几周、几个月和几年内如何扩大 GKE 覆盖范围？准备好计划可帮助您充分利用 GKE 提供的可伸缩性功能，优化 GKE 环境并降低费用。如需详细了解如何规划集群和工作负载的可伸缩性，请参阅 GKE 可扩缩性简介。

要提高机器学习工作负载的性能，您可以采用 Cloud Tensor Processing Unit（云张量处理单元）(Cloud TPU)，这是 Google 设计的 AI 加速器（针对大型 AI 模型的训练和推理进行了优化）。

部署

如需部署本文档介绍的跨孤岛和跨设备参考架构，请参阅 Google Cloud上的联邦学习 GitHub 仓库。

后续步骤

• 探索如何在 TensorFlow Federated 平台上实现联邦学习算法。
• 了解联邦学习的推进和开放问题。
• 了解 Google AI 博客上的联邦学习。
• 观看 Google 使用联合学习和去识别化、聚合信息来改进机器学习模型，保证隐私安全。
• 阅读迈向大规模联邦学习。
• 了解如何实现 MLOps 流水线来管理机器学习模型的生命周期。
• 如需简要了解 Google Cloud中特定于 AI 和机器学习工作负载的架构原则和建议，请参阅 Well-Architected Framework 中的 AI 和机器学习视角。
• 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。

贡献者

作者：

• Grace Mollison | 解决方案负责人
• Marco Ferrari | 云解决方案架构师

其他贡献者：

• Chloé Kiddon | 资深软件工程师兼经理
• Laurent Grangeau | 解决方案架构师
• Lilian Felix | 云工程师
• Christiane Peters | 云安全架构师