使用 Azure Kubernetes Fleet Manager 自动部署来驱动多群集资源放置（预览版）

Azure Kubernetes Fleet Manager 自动部署可用于生成应用程序，并将应用程序从代码存储库部署到机群中的一个或多个 AKS 群集。 自动化部署简化了设置 GitHub Action 工作流以生成和部署代码的过程。 连接后，你所做的每个新提交都会运行管道。

自动化部署基于 draft.sh 构建。创建新的部署工作流时，可以使用现有的 Dockerfile、生成新的 Dockerfile、使用现有的 Kubernetes 清单或生成新的 Kubernetes 清单。 生成的清单是考虑到安全性和复原能力最佳做法创建的。

• 一个 GitHub 帐户，其中包含要部署的应用程序。
• 如果没有 Azure 试用版订阅，请在开始前创建一个。
• 阅读自动部署和资源传播的概念概述，了解本文中使用的概念和术语。
• 用于管理中心集群和成员集群的 Kubernetes Fleet 管理器。 如果没有，请参阅使用 Azure CLI 创建 Azure Kubernetes 舰队管理器资源并加入成员群集。
• 完成配置的用户有权访问 Fleet Manager 中心群集 Kubernetes API。 有关详细信息，请参阅 访问 Kubernetes API 。
• 已在舰队管理器中心群集上部署的 Kubernetes 命名空间。
• 向 成员 AKS 群集授予 AcrPull 权限的 Azure 容器注册表（ACR）。

找到 Azure Kubernetes Fleet Manager 并启动自动部署配置。

1. 在 Azure 门户中，在顶部搜索栏中搜索 Kubernetes Fleet Manager 。
2. 在搜索结果中选择 Kubernetes 机群管理器 。
3. 从资源列表中选择 Azure Kubernetes Fleet Manager。
4. 在 “机群管理器服务”菜单中的“舰队资源”下，选择 “自动部署”。
5. 在顶部菜单中选择 “+ 创建 ”。 如果此部署是第一个部署，还可以在部署列表区域中选择“ 创建 ”。

创建工作流并授权它连接到所需的源代码存储库和分支。 在 “存储库 ”选项卡上完成以下详细信息。

1. 在 “工作流名称 ”字段中输入工作流的有意义的名称。
2. 接下来，选择“ 授权访问权限 ”以授权用户针对 GitHub 获取存储库列表。
3. 对于 存储库源 ，请选择以下任一项：
   1. “我的存储库”，适用于当前授权的 GitHub 用户拥有的存储库；
   2. “所有存储库”，适用于当前授权的 GitHub 用户可以访问的存储库。 需要选择拥有存储库的组织。
4. 选择 存储库 和 分支。
5. 选择“下一步”按钮。

若要准备要在 Kubernetes 上运行的应用程序，需要将其构建到容器注册表中存储的容器映像中。 Dockerfile 提供有关如何生成容器映像的说明。 如果源代码存储库还没有 Dockerfile，则自动部署可以为你生成一个。

Kubernetes 上运行的应用程序包含许多 Kubernetes 基元组件。 这些组件描述了要使用的容器映像、要运行的副本数、如果公开应用程序需要公共 IP，等等。有关详细信息，请参阅官方 Kubernetes 文档。 如果源代码存储库还没有 Kubernetes 清单，则自动部署可以为你生成它们。 此外，也可以选择现有 Helm chart。

查看存储库、映像和部署配置的配置。

选择 “下一步 ”以启动执行以下作的进程：

1. 创建联合凭据以允许 GitHub Action：
   1. 将生成的容器映像推送到 Azure 容器注册表。
   2. 将 Kubernetes 清单配置到 Fleet Manager 集群中心的所选命名空间中。
2. 在代码存储库上创建包含生成文件和工作流的拉取请求。

设置需要几分钟时间，因此在此期间不要切换离开“部署”页面。

部署阶段完成后，选择“ 批准拉取请求 ”按钮以打开代码存储库上生成的拉取请求。

1. 查看 文件更改 下的更改，并进行任何所需的编辑。
2. 选择 “合并拉取请求 ”，将更改合并到代码存储库中。

合并更改将运行 GitHub Actions 工作流，该工作流将应用程序生成到容器映像中，并将其存储在所选的 Azure 容器注册表中。

管道完成后，可以通过查找配置的 Azure 容器注册表实例并打开映像存储库，在 Azure 门户中查看创建的容器映像。

还可以查看 Fleet Manager 自动部署配置。 选择 workflow 名称会在 GitHub Action 上打开 GitHub。

最后，您可以确认预期的 Kubernetes 资源已经在 Fleet Manager 的中心群集上暂存。

az fleet get-credentials \
    --resource-group ${GROUP} \
    --name ${FLEET}

kubectl describe deployments virtual-worker --namespace=contoso-store

输出如下所示。 由于工作负荷未安排在舰队管理器中心群集上，因此副本数量预计为 0。 确保属性 Image 指向 Azure 容器注册表中的内置映像。

Name:                   virtual-worker
Namespace:              contoso-store
CreationTimestamp:      Thu, 24 Apr 2025 01:56:49 +0000
Labels:                 workflow=actions.github.com-k8s-deploy
                        workflowFriendlyName=contoso-store-deploy
Annotations:            <none>
Selector:               app=virtual-worker
Replicas:               1 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=virtual-worker
  Containers:
   virtual-worker:
    Image:      contoso03.azurecr.io/virtual-worker:latest
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:     2m
      memory:  20Mi
    Requests:
      cpu:     1m
      memory:  1Mi
    Environment:
      MAKELINE_SERVICE_URL:  http://makeline-service:3001
      ORDERS_PER_HOUR:       100
    Mounts:                  <none>
  Volumes:                   <none>
  Node-Selectors:            kubernetes.io/os=linux
  Tolerations:               <none>
Events:                      <none>

在预览期间，若要将已准备的工作负荷配置到成员群集上，您可以按照以下步骤进行操作。

1. 在应用程序的源代码存储库中，在名为 fleet 的存储库根目录中创建一个文件夹。

2. 在deploy-contoso-ns-two-regions.yaml文件夹中创建新文件，并添加显示的内容。 此示例跨 contoso-store 两个群集部署命名空间，这些群集必须位于两个不同的 Azure 区域中。

   apiVersion: placement.kubernetes-fleet.io/v1
   kind: ClusterResourcePlacement
   metadata:
     name: distribute-virtual-worker-two-regions
   spec:
     resourceSelectors:
       - group: ""
         kind: Namespace
         version: v1          
         name: contoso-store
     policy:
       placementType: PickN
       numberOfClusters: 2
       topologySpreadConstraints:
       - maxSkew: 1
         topologyKey: region
         whenUnsatisfiable: DoNotSchedule
   

3. 修改 GitHub Action 工作流文件，添加对 CRP 文件的引用。

   DEPLOYMENT_MANIFEST_PATH: |
     ./virtual-worker.yaml
     ./fleet/deploy-contoso-ns-two-regions.yaml
   

4. 提交新的 CRP 清单并更新了 GitHub Action 工作流文件。

5. 检查是否已按照 CRP 定义中定义的策略放置工作负荷。 可以使用 Azure 门户或在 kubectl 命令行中检查。

• 利用资源放置功能在多个群集上部署工作负荷。
• 基于成员群集属性的智能跨群集 Kubernetes 资源放置。
• 自动部署常见问题解答。