Azure Kubernetes Fleet Manager 自动部署可用于生成应用程序,并将应用程序从代码存储库部署到机群中的一个或多个 AKS 群集。 自动化部署简化了设置 GitHub Action 工作流以生成和部署代码的过程。 连接后,你所做的每个新提交都会运行管道。
自动化部署基于 draft.sh 构建。创建新的部署工作流时,可以使用现有的 Dockerfile、生成新的 Dockerfile、使用现有的 Kubernetes 清单或生成新的 Kubernetes 清单。 生成的清单是考虑到安全性和复原能力最佳做法创建的。
重要
Azure Kubernetes 舰队管理器预览功能可以通过自助服务方式选择性启用。 预览版按“现状”和“视供应情况”提供,它们不包括在服务级别协议和有限保证范围内。 客户支持部门会尽力为 Azure Kubernetes 舰队管理器预览功能提供部分支持。 因此,这些功能并不适合用于生产。
- 一个 GitHub 帐户,其中包含要部署的应用程序。
- 如果没有 Azure 试用版订阅,请在开始前创建一个。
- 阅读自动部署和资源传播的概念概述,了解本文中使用的概念和术语。
- 用于管理中心集群和成员集群的 Kubernetes Fleet 管理器。 如果没有,请参阅使用 Azure CLI 创建 Azure Kubernetes 舰队管理器资源并加入成员群集。
- 完成配置的用户有权访问 Fleet Manager 中心群集 Kubernetes API。 有关详细信息,请参阅 访问 Kubernetes API 。
- 已在舰队管理器中心群集上部署的 Kubernetes 命名空间。
- 向 成员 AKS 群集授予 AcrPull 权限的 Azure 容器注册表(ACR)。
找到 Azure Kubernetes Fleet Manager 并启动自动部署配置。
- 在 Azure 门户中,在顶部搜索栏中搜索 Kubernetes Fleet Manager 。
- 在搜索结果中选择 Kubernetes 机群管理器 。
- 从资源列表中选择 Azure Kubernetes Fleet Manager。
- 在 “机群管理器服务”菜单中的“舰队资源”下,选择 “自动部署”。
- 在顶部菜单中选择 “+ 创建 ”。 如果此部署是第一个部署,还可以在部署列表区域中选择“ 创建 ”。
创建工作流并授权它连接到所需的源代码存储库和分支。 在 “存储库 ”选项卡上完成以下详细信息。
- 在 “工作流名称 ”字段中输入工作流的有意义的名称。
- 接下来,选择“ 授权访问权限 ”以授权用户针对 GitHub 获取存储库列表。
- 对于 存储库源 ,请选择以下任一项:
- “我的存储库”,适用于当前授权的 GitHub 用户拥有的存储库;
- “所有存储库”,适用于当前授权的 GitHub 用户可以访问的存储库。 需要选择拥有存储库的组织。
- 选择 存储库 和 分支。
- 选择“下一步”按钮。
若要准备要在 Kubernetes 上运行的应用程序,需要将其构建到容器注册表中存储的容器映像中。 Dockerfile 提供有关如何生成容器映像的说明。 如果源代码存储库还没有 Dockerfile,则自动部署可以为你生成一个。
如果代码存储库已有 Dockerfile,则可以使用它来生成应用程序映像。
- 选择“现有 Dockerfile”作为“容器配置”。
- 从存储库中选择 Dockerfile 。
- 输入 Dockerfile 生成上下文 ,将文件和目录集传递给生成过程(通常与 Dockerfile 的文件夹相同)。 这些文件用于生成映像,并且它们包含在最终映像中,除非它们通过包含在
.dockerignore
文件中被忽略。 - 选择现有的 Azure 容器注册表。 此注册表用于存储生成的应用程序映像。 任何能够接收应用程序的 AKS 群集都必须被授予
AcrPull
注册表的权限。 - 设置 Azure 容器注册表映像 名称。 必须在 Kubernetes 部署配置文件中使用此镜像名称。
Kubernetes 上运行的应用程序包含许多 Kubernetes 基元组件。 这些组件描述了要使用的容器映像、要运行的副本数、如果公开应用程序需要公共 IP,等等。有关详细信息,请参阅官方 Kubernetes 文档。 如果源代码存储库还没有 Kubernetes 清单,则自动部署可以为你生成它们。 此外,也可以选择现有 Helm chart。
警告
请勿选择 fleet-system
命名空间或任何 fleet-member
命名空间,因为这些命名空间是 Fleet Manager 使用的内部命名空间,不能用于放置应用程序。
如果您的代码存储库中已经有 Kubernetes 配置文件,您可以选择它来控制通过集群资源分配部署和配置的工作负载。
- 为部署选项选择 “使用现有 Kubernetes 清单部署文件 ”。
- 从存储库中选择 Kubernetes 清单文件或文件夹 。
- 选择用于暂存工作负荷的现有舰队管理器“命名空间”。
- 选择“下一步”按钮。
查看存储库、映像和部署配置的配置。
选择 “下一步 ”以启动执行以下作的进程:
- 创建联合凭据以允许 GitHub Action:
- 将生成的容器映像推送到 Azure 容器注册表。
- 将 Kubernetes 清单配置到 Fleet Manager 集群中心的所选命名空间中。
- 在代码存储库上创建包含生成文件和工作流的拉取请求。
设置需要几分钟时间,因此在此期间不要切换离开“部署”页面。
部署阶段完成后,选择“ 批准拉取请求 ”按钮以打开代码存储库上生成的拉取请求。
备注
生成的拉取请求的命名存在一个已知问题,指示正在部署到 AKS。 尽管名字不正确,但生成的工作流确实在您选择的命名空间中的 Fleet Manager 枢纽集群上暂存工作负载。
- 查看 文件更改 下的更改,并进行任何所需的编辑。
- 选择 “合并拉取请求 ”,将更改合并到代码存储库中。
合并更改将运行 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>
在预览期间,若要将已准备的工作负荷配置到成员群集上,您可以按照以下步骤进行操作。
在应用程序的源代码存储库中,在名为 fleet 的存储库根目录中创建一个文件夹。
在
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
修改 GitHub Action 工作流文件,添加对 CRP 文件的引用。
DEPLOYMENT_MANIFEST_PATH: | ./virtual-worker.yaml ./fleet/deploy-contoso-ns-two-regions.yaml
提交新的 CRP 清单并更新了 GitHub Action 工作流文件。
检查是否已按照 CRP 定义中定义的策略放置工作负荷。 可以使用 Azure 门户或在
kubectl
命令行中检查。