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

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

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

本文档的目标受众是希望在 Google Cloud 上实现联邦学习用例的云架构师以及 AI 和机器学习工程师。它还适用于正在评估是否要在 Google Cloud 上实现联邦学习的决策者。

架构

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

跨孤岛架构

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

上图展示了一个跨 silo 架构的简单示例。在该图中，所有资源都位于 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，用于允许出站流量流向互联网。

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

• 服务账号，如下所示：

  • 租户节点池中节点的专用服务账号。
  • 一个专用服务账号，供租户应用与 Workload Identity Federation 搭配使用。

• 支持使用 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 集群，有助于保护使用中的数据

跨设备架构使用开源 Federated Compute Platform (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 优化器更新模型参数的算法。 典型用例如下：
    • 推荐系统：公司可以使用联邦 Adam 训练模型，以便根据用户的购买记录向用户推荐商品。
    • 排名：公司可以使用联邦 Adam 训练用于对搜索结果进行排名的模型。
    • 点击率预测：公司可以使用联邦 Adam 训练一个模型，以预测用户点击广告的可能性。

使用场景

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

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

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

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

根据用例，使用联邦学习训练模型还可以带来其他好处：

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

联邦学习有不同种类，其特征是数据的来源位置以及本地计算发生的位置。本文档中的架构重点介绍了两种类型的联邦学习：跨孤岛和跨设备。本文档不涵盖其他类型的联邦学习。

联邦学习还可按数据集的分区方式进行进一步分类，具体分类如下：

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

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

参与计划的成员可能无法将对方的各项工作负载视为可信实体。例如，参与计划的成员可能无法访问他们从第三方（例如协调者）收到的训练工作负载的源代码。由于无法访问此源代码，参与计划的成员无法确保工作负载是否完全可信。

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

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

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

跨 silo 联邦学习的示例用例如下：

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

跨设备联邦学习是一种联邦计算，其中参与的成员是最终用户设备，例如手机、车辆或 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 仓库中的配置保持同步。Git 代码库充当您的集群配置和政策的单一数据源。Config Sync 以声明式方法运作。它会持续检查集群状态，并应用配置文件中声明的状态来强制实施政策，这有助于防止配置偏移。

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

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

Policy Controller

Google Kubernetes Engine (GKE) 企业版 Policy Controller 是 Kubernetes 动态准入控制器，它会强制执行基于 CustomResourceDefinition（基于 CRD）的政策，这些政策由 Open Policy Agent (OPA) 执行。

准入控制器是 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 资源

GKE Compliance 信息中心

GKE Compliance 信息中心提供富有实用价值的分析洞见来强化安全状况，并帮助您自动生成行业基准和标准的合规性报告。您可以注册 GKE 集群，以启用自动合规性报告。

如需了解详情，请参阅 GKE“合规性”信息中心简介。

联邦学习安全注意事项

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

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

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

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

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

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

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

可靠性

本部分介绍使用本文档中的任一参考架构在 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 和机器学习工作负载的原则和建议，请参阅架构框架中的AI 和机器学习视角。
• 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。

贡献者

作者：

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

其他贡献者：

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