本文包含有关[使用 Azure 机器学习配置 Kubernetes]的参考信息。

关注TechLead，分享AI全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验，同济本复旦硕，复旦机器人智能实验室成员，阿里云认证的资深架构师，项目管理专业人士，上亿营收AI产品研发负责人。

受支持的 Kubernetes 版本和区域

• 安装 Azure 机器学习扩展的 Kubernetes 群集的版本支持窗口为“N-2”，这与 Azure Kubernetes 服务 (AKS) 版本支持策略一致，其中“N”是 Azure Kubernetes 的最新 GA 次要版本服务。

  • 例如，如果 AKS 今天发布了 1.20.a，则 1.20.a、1.20.b、1.19.c、1.19.d、1.18.e 和 1.18.f 均受支持。

  • 如果客户在运行不受支持的 Kubernetes 版本，则在请求群集支持时，系统会要求他们升级。 运行不受支持的 Kubernetes 版本的群集未涵盖在 Azure 机器学习扩展支持策略中。

• Azure 机器学习扩展区域可用性：

  • Azure 机器学习扩展可以部署到已启用 Azure Arc 的 Kubernetes 区域支持中列出的受支持区域中的 AKS 或已启用 Azure Arc 的 Kubernetes。

建议的资源计划

部署 Azure 机器学习扩展时，某些相关服务将部署到适用于 Azure 机器学习的 Kubernetes 群集。 群集中“相关服务及其资源使用情况”如下表所示：

部署/Daemonset	副本 #	培训	推理	CPU 请求(m)	CPU 限制(m)	内存请求(Mi)	内存限制(Mi)
metrics-controller-manager	1	✓	✓	10	100	20	300
prometheus-operator	1	✓	✓	100	400	128	512
prometheus	1	✓	✓	100	1000	512	4096
kube-state-metrics	1	✓	✓	10	100	32	256
gateway	1	✓	✓	50	500	256	2048
fluent-bit	每个节点 1 个	✓	✓	10	200	100	300
inference-operator-controller-manager	1	✓	空值	100	1000	128	1024
amlarc-identity-controller	1	✓	空值	200	1000	200	1024
amlarc-identity-proxy	1	✓	空值	200	1000	200	1024
azureml-ingress-nginx-controller	1	✓	空值	100	1000	64	512
azureml-fe-v2	1（出于测试目的）

3（用于生产目的） | ✓ | 空值 | 900 | 2000 | 800 | 1200 |
| online-deployment | 每个部署 1 个 | User-created | 空值 | | | | |
| online-deployment/identity-sidecar | 每个部署 1 个 | ✓ | 空值 | 10 | 50 | 100 | 100 |
| aml-operator | 1 | 不适用 | ✓ | 20 | 1020 | 124 | 2168 |
| volcano-admission | 1 | 不适用 | ✓ | 10 | 100 | 64 | 256 |
| volcano-controller | 1 | 不适用 | ✓ | 50 | 500 | 128 | 512 |
| volcano-schedular | 1 | 不适用 | ✓ | 50 | 500 | 128 | 512 |

除你自己的部署/Pod 外，“总最低系统资源要求”如下：

场景	已启用推理	已启用训练	CPU 请求(m)	CPU 限制(m)	内存请求(Mi)	内存限制(Mi)	节点计数	推荐的最低 VM 大小	相应的 AKS VM SKU
测试	✓	空值	1780	8300	2440	12296	1 个节点	2 个 vCPU、7 GiB 内存、6400 IOPS 和 1500Mbps BW	DS2v2
测试	空值	✓	410	4420	1492	10960	1 个节点	2 个 vCPU、7 GiB 内存、6400 IOPS 和 1500Mbps BW	DS2v2
测试	✓	✓	1910	10420	2884	15744	1 个节点	4 个 vCPU、14 GiB 内存、12800 IOPS 和 1500Mbps BW	DS3v2
生产	✓	空值	3600	12700	4240	15296	3 个节点	4 个 vCPU、14 GiB 内存、12800 IOPS 和 1500Mbps BW	DS3v2
生产	空值	✓	410	4420	1492	10960	1 个节点	8 个 vCPU、28GiB 内存、25600 IOP、6000Mbps BW	DS4v2
生产	✓	✓	3730	14820	4684	18744	3 个节点	4 个 vCPU、14 GiB 内存、12800 IOPS 和 1500Mbps BW	DS4v2

ARO 或 OCP 群集的先决条件

禁用安全增强型 Linux (SELinux)

启用了 SELinux 的计算机不支持 Azure 机器学习数据集（用于 Azure 机器学习训练作业的 SDK v1 功能）。 因此，需要对所有辅助角色禁用 selinux 才能使用 Azure 机器学习数据集。

ARO 和 OCP 的特权设置

对于 ARO 或 OCP 群集上的 Azure 机器学习扩展部署，授予对 Azure 机器学习服务帐户的特权访问，运行 oc edit scc privileged 命令，并在“users:”下添加以下服务帐户：

• system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
• system:serviceaccount:azureml:{EXTENSION-NAME}-kube-state-metrics
• system:serviceaccount:azureml:prom-admission
• system:serviceaccount:azureml:default
• system:serviceaccount:azureml:prom-operator
• system:serviceaccount:azureml:load-amlarc-selinux-policy-sa
• system:serviceaccount:azureml:azureml-fe-v2
• system:serviceaccount:azureml:prom-prometheus
• system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default
• system:serviceaccount:azureml:azureml-ingress-nginx
• system:serviceaccount:azureml:azureml-ingress-nginx-admission

备注

• {EXTENSION-NAME}：它是由 az k8s-extension create --name CLI 命令指定的扩展名。
• {KUBERNETES-COMPUTE-NAMESPACE}：它是将计算附加到 Azure 机器学习工作区时指定的 Kubernetes 计算的命名空间。 如果 KUBERNETES-COMPUTE-NAMESPACE 为 default，则跳过配置 system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default。

收集的日志详细信息

关于群集中 Azure 机器学习工作负载的某些日志将通过扩展组件（例如状态、指标、生命周期等）收集。以下列表显示了收集的所有日志详细信息，包括收集的日志类型以及它们发送到或存储的位置。

Pod	资源说明	详细日志信息
amlarc-identity-controller	通过托管标识请求和续订 Azure Blob/Azure 容器注册表令牌。	仅在安装扩展时设置了 enableInference=true 时使用。 它包含有关获取终结点标识以使用 Azure 机器学习服务进行身份验证的状态的跟踪日志。
amlarc-identity-proxy	通过托管标识请求和续订 Azure Blob/Azure 容器注册表令牌。	仅在安装扩展时设置了 enableInference=true 时使用。 它包含有关获取群集标识以使用 Azure 机器学习服务进行身份验证的状态的跟踪日志。
aml-operator	管理训练作业的生命周期。	日志包含群集中的 Azure 机器学习训练作业 Pod 状态。
azureml-fe-v2	用于将传入推理请求路由到已部署服务的前端组件。	请求级别的访问日志，包括请求 ID、开始时间、响应代码、错误详细信息和请求延迟的持续时间。 用于服务元数据更改、服务运行状态等的跟踪日志，用于调试目的。
gateway	网关用于来回通信和发送数据。	有关从 Azure 机器学习服务到群集的请求的跟踪日志。
运行状况检查	–	日志包含 azureml 命名空间资源（Azure 机器学习扩展）状态，以诊断导致扩展无法运行的原因。
inference-operator-controller-manager	管理推理终结点的生命周期。	日志包含群集中的 Azure 机器学习推理终结点和部署 Pod 状态。
metrics-controller-manager	管理 Prometheus 的配置。	有关上传训练作业状态的跟踪日志，以及有关 CPU 利用率和内存利用率的推理部署指标。
中继服务器	中继服务器仅在连接 Arc 的群集中是必需的，并且不会安装在 AKS 群集中。	中继服务器与 Azure 中继配合使用，以便与云服务通信。 日志包含来自 Azure 中继的请求级别信息。

Azure 机器学习作业与自定义数据存储连接

永久性卷 (PV) 和永久性卷声明 (PVC) 是 Kubernetes 概念，允许用户提供和使用各种存储资源。

1. 创建 PV，以 NFS 为例，

apiVersion: v1
kind: PersistentVolume
metadata:name: nfs-pv 
spec:capacity:storage: 1Gi accessModes:- ReadWriteMany persistentVolumeReclaimPolicy: RetainstorageClassName: ""nfs: path: /share/nfsserver: 20.98.110.84 readOnly: false

2. 使用 ML 工作负载在同一 Kubernetes 命名空间中创建 PVC。 在 metadata 中，必须添加标签 ml.azure.com/pvc: "true" 以供 Azure 机器学习识别，并添加注释 ml.azure.com/mountpath: <mount path> 以设置装载路径。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs-pvc  namespace: defaultlabels:ml.azure.com/pvc: "true"annotations:ml.azure.com/mountpath: "/mnt/nfs"
spec:storageClassName: ""accessModes:- ReadWriteMany      resources:requests:storage: 1Gi

重要

• 只有命令作业/组件、hyperdrive 作业/组件和批处理部署支持来自 PVC 的自定义数据存储。 > * 实时联机终结点、AutoML 作业和 PRS 作业不支持来自 PVC 的自定义数据存储。
• 此外，只有与 PVC 位于同一 Kubernetes 命名空间中的 Pod 才会装载到卷上。 数据科学家能够访问作业中 PVC 批注中指定的 mount path。 AutoML 作业和 Prs 作业将无法访问 PVC。

支持的 Azure 机器学习排斥和容许

污点和容忍是 Kubernetes 中的概念，它们协同工作，以确保不会将 Pod 安排到不适当的节点。

与 Azure 机器学习（包括 AKS 和 Arc Kubernetes 群集）集成的 Kubernetes 群集现在支持特定的 Azure 机器学习排斥和容许，允许用户在 Azure 机器学习专用节点上添加特定的 Azure 机器学习排斥，以防止非 Azure 机器学习工作负载安排到这些专用节点上。

我们仅支持在节点上放置 amlarc 特定的排斥，定义如下：

排斥	密钥	值	效果	说明
amlarc 整体	ml.azure.com/amlarc	true	NoSchedule、NoExecute 或 PreferNoSchedule	所有 Azure 机器学习工作负载（包括扩展系统服务 Pod 和机器学习工作负载 Pod）都会容忍此 amlarc overall 污点。
amlarc 系统	ml.azure.com/amlarc-system	true	NoSchedule、NoExecute 或 PreferNoSchedule	只有 Azure 机器学习扩展系统服务 Pod 才会容忍此 amlarc system 污点。
amlarc 工作负载	ml.azure.com/amlarc-workload	true	NoSchedule、NoExecute 或 PreferNoSchedule	只有机器学习工作负载 Pod 才容许此 amlarc workload 排斥。
amlarc 资源组	ml.azure.com/resource-group	<资源组名称>	NoSchedule、NoExecute 或 PreferNoSchedule	只有从特定资源组创建的机器学习工作负载 Pod 才容许此 amlarc resource group 排斥。
amlarc 工作区	ml.azure.com/workspace	<工作区名称>	NoSchedule、NoExecute 或 PreferNoSchedule	只有从特定工作区创建的机器学习工作负载 Pod 才容许此 amlarc workspace 排斥。
amlarc 计算	ml.azure.com/compute	<计算名称>	NoSchedule、NoExecute 或 PreferNoSchedule	只有使用特定计算目标创建的机器学习工作负载 Pod 才容许此 amlarc compute 排斥。

提示

1. 对于Azure Kubernetes 服务 (AKS)，可以遵循有关 Azure Kubernetes 服务 (AKS) 中的高级计划程序功能的最佳做法中的示例，将污点应用到节点池。
2. 对于 Arc Kubernetes 群集（例如本地 Kubernetes 群集），可以使用 kubectl taint 命令向节点添加污点。 有关更多示例，请参阅 Kubernetes 文档。

最佳实践

根据 Azure 机器学习专用节点的计划要求，可以添加“多个特定于 amlarc 的污点”，以限制 Azure 机器学习工作负载可在节点上运行的内容。 我们列出了有关使用 amlarc 排斥的最佳做法：

• 若要防止非 Azure 机器学习工作负载在 Azure 机器学习专用节点/节点池上运行，只需向这些节点添加 aml overall 污点即可。
• 要防止非系统 Pod 在 Azure 机器学习专用节点/节点池上运行，必须添加以下污点：
  • amlarc overall 排斥
  • amlarc system 排斥
• 要防止非 ml 工作负载在 Azure 机器学习专用节点/节点池上运行，必须添加以下污点：
  • amlarc overall 排斥
  • amlarc workloads 排斥
• 要防止不是从工作区 X 创建的工作负载在 Azure 机器学习专用节点/节点池上运行，必须添加以下污点：
  • amlarc overall 排斥
  • amlarc resource group (has this <workspace X>) 排斥
  • amlarc <workspace X> 排斥
• 要防止不是由计算目标 X 创建的工作负载在 Azure 机器学习专用节点/节点池上运行，必须添加以下污点：
  • amlarc overall 排斥
  • amlarc resource group (has this <workspace X>) 排斥
  • amlarc workspace (has this <compute X>) 排斥
  • amlarc <compute X> 排斥

通过 HTTP 或 HTTPS 将其他入口控制器与 Azure 机器学习扩展集成

除了默认的 Azure 机器学习推理负载均衡器 azureml-fe 外，还可以通过 HTTP 或 HTTPS 将其他负载均衡器与 Azure 机器学习扩展集成。

本教程介绍如何集成 Nginx 入口控制器或 Azure 应用程序网关。

先决条件

• 使用 inferenceRouterServiceType=ClusterIP 和 allowInsecureConnections=True部署 Azure 机器学习扩展，以便 Nginx 入口控制器可以自行处理 TLS 终止，而不是当通过 HTTPS 公开服务时将其移交给 azureml-fe。
• 若要与 Nginx 入口控制器集成，需要使用 Nginx 入口控制器设置 Kubernetes 群集。
  • 创建基本控制器：如果是从头开始，请参阅这些说明。
• 若要与 Azure 应用程序网关集成，需要使用 Azure 应用程序网关入口控制器设置 Kubernetes 群集。
  • 绿地部署：如果是从头开始，请参阅这些说明。
  • 棕地部署：如果有现有的 AKS 群集和应用程序网关，请参阅这些说明。
• 若要在此应用程序上使用 HTTPS，则需 x509 证书及其私钥。

通过 HTTP 公开服务

为了公开 azureml-fe，我们将使用以下入口资源：

# Nginx Ingress Controller example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: azureml-fenamespace: azureml
spec:ingressClassName: nginxrules:- http:paths:- path: /backend:service:name: azureml-feport:number: 80pathType: Prefix

此入口会将 azureml-fe 服务和所选部署作为 Nginx 入口控制器的默认后端公开。

# Azure Application Gateway example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: azureml-fenamespace: azureml
spec:ingressClassName: azure-application-gatewayrules:- http:paths:- path: /backend:service:name: azureml-feport:number: 80pathType: Prefix

此入口会将 azureml-fe 服务和所选部署作为应用程序网关的默认后端公开。

请将以上入口资源另存为 ing-azureml-fe.yaml。

1. 通过运行以下命令部署 ing-azureml-fe.yaml：

   kubectl apply -f ing-azureml-fe.yaml
   

2. 检查入口控制器的日志以了解部署状态。

3. azureml-fe 应用程序现在应该可用。 可以通过访问以下位置进行检查：

   • Nginx 入口控制器：Nginx 入口控制器的公共 LoadBalancer 地址
   • Azure 应用程序网关：应用程序网关的公共地址。

4. 创建推理作业并调用。

   备注

   调用前，将 scoring_uri 中的 IP 替换为 Nginx 入口控制器的公共 LoadBalancer 地址。

通过 HTTPS 公开服务

1. 在部署入口之前，需创建 Kubernetes 机密来托管证书和私钥。 可通过运行以下命令来创建 Kubernetes 机密

   kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>
   

2. 定义以下入口。 在入口的 secretName 节中指定机密的名称。

   # Nginx Ingress Controller example
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:name: azureml-fenamespace: azureml
   spec:ingressClassName: nginxtls:- hosts:- <domain>secretName: <ingress-secret-name>rules:- host: <domain>http:paths:- path: /backend:service:name: azureml-feport:number: 80pathType: Prefix
   

   # Azure Application Gateway example
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:name: azureml-fenamespace: azureml
   spec:ingressClassName: azure-application-gatewaytls:- hosts:- <domain>secretName: <ingress-secret-name>rules:- host: <domain>http:paths:- path: /backend:service:name: azureml-feport:number: 80pathType: Prefix
   

   备注

   将上述入口资源中的 <domain> 和 <ingress-secret-name> 替换为指向 Nginx 入口控制器/应用程序网关的 LoadBalancer 的域和你的机密名称。 将以上入口资源存储在名为 ing-azureml-fe-tls.yaml 的文件中。

3. 通过运行部署 ing-azureml-fe-tls.yaml

   kubectl apply -f ing-azureml-fe-tls.yaml
   

4. 检查入口控制器的日志以了解部署状态。

5. 现在，azureml-fe 应用程序在 HTTPS 上可用。 可以通过访问 Nginx 入口控制器的公共 LoadBalancer 地址来检查这一点。

6. 创建推理作业并调用。

   备注

   调用前，将 scoring_uri 中的协议和 IP 替换为指向 Nginx 入口控制器或应用程序网关的 LoadBalancer 的 https 和域。

使用 ARM 模板部署扩展

可以使用 ARM 模板部署托管群集上的扩展。 可从 deployextension.json 中找到示例模板，其中包含演示参数文件 deployextension.parameters.json

若要使用示例部署模板，请使用正确的值编辑参数文件，然后运行以下命令：

az deployment group create --name <ARM deployment name> --resource-group <resource group name> --template-file deployextension.json --parameters deployextension.parameters.json

有关如何使用 ARM 模板的详细信息，请参阅 ARM 模板文档

AzuremML 扩展发行说明

Date	版本	版本说明
2023 年 10 月 11 日	1.1.35	修复易受攻击的映像。 bug 修复。
2023 年 8 月 25 日	1.1.34	修复易受攻击的映像。 返回更详细的标识错误。 bug 修复。
2023 年 7 月 18 日	1.1.29	添加新标识运算符错误。 bug 修复。
2023 年 6 月 4 日	1.1.28	改进自动缩放程序以处理多个节点池。 bug 修复。
2023 年 4 月 18 日	1.1.26	Bug 修复和漏洞修复。
2023 年 3 月 27 日	1.1.25	添加 Azure 机器学习作业限制。 SSH 设置失败时，训练作业会快速失败。 将 Prometheus 抓取间隔缩短到 30 秒。 改进用于推理的错误消息。 修复易受攻击的映像。
2023 年 3 月 7 日	1.1.23	更改默认实例类型以使用 2Gi 内存。 更新 scoring-fe 的指标配置，其中添加 15 秒的 scrape_interval。 为 mdc 挎斗添加资源规范。 修复易受攻击的映像。 bug 修复。
2023 年 2 月 14 日	1.1.21	Bug 修复。
2023 年 2 月 7 日	1.1.19	改进用于推理的错误返回消息。 更新默认实例类型以使用 2Gi 内存限制。 对 Pod 运行状况、资源配额、Kubernetes 版本和扩展版本执行群集运行状况检查。 Bug 修复
2022 年 12 月 27 日	1.1.17	将 Fluent-bit 从 DaemonSet 移至挎斗。 添加 MDC 支持。 优化错误消息。 支持群集模式（windows、linux）作业。 Bug 修复
2022 年 11 月 29 日	1.1.16	通过新的 CRD 添加实例类型验证。 支持容错。 缩短 SVC 名称。 工作负载核心小时数。 多个 bug 修复和改进。
2022 年 9 月 13 日	1.1.10	Bug 修复。
2022 年 8 月 29 日	1.1.9	改进了运行状况检查逻辑。 Bug 修复。
2022 年 6 月 23 日	1.1.6	Bug 修复。
2022 年 6 月 15 日	1.1.5	更新了训练，以使用新的公共运行时运行作业。 删除了 AKS 扩展的 Azure 中继使用情况。 从扩展中删除了服务总线使用情况。 更新了安全上下文使用情况。 已将推理 azureml-fe 更新为 v2。 已更新为使用 Volcano 作为训练作业计划程序。 Bug 修复。
2021 年 10 月 14 日	1.0.37	在 AMLArc 训练作业中支持 PV/PVC 卷装载。
2021 年 9 月 16 日	1.0.29	新区域可用：美国西部、美国中部、美国中北部、韩国中部。 作业队列可扩展性。 请参阅“Azure 机器学习工作区工作室”中的作业队列详细信息。 自动终止策略。 支持 ScriptRunConfig 中的 max_run_duration_seconds。 如果运行时间超过设置值，系统会尝试自动取消运行。 群集自动缩放支持的性能改进。 从本地容器注册表部署 Arc 代理和 ML 扩展。
2021 年 8 月 24 日	1.0.28	作业 YAML 支持计算实例类型。 将托管标识分配给 AMLArc 计算。
2021 年 8 月 10 日	1.0.20	新的 Kubernetes 分发支持，K3S - 轻型 Kubernetes。 将 Azure 机器学习扩展部署到 AKS 群集，而无需通过 Azure Arc 进行连接。自动化机器学习 (AutoML) 需要通过 Python SDK。 使用 2.0 CLI 将 Kubernetes 群集附加到 Azure 机器学习工作区。 优化 Azure 机器学习扩展组件 CPU/内存资源利用率。
2021 年 7 月 2 日	1.0.13	新的 Kubernetes 分发支持、OpenShift Kubernetes 和 GKE（Google Kubernetes 引擎）。 自动缩放支持。 如果用户管理的 Kubernetes 群集启用了自动缩放，则群集将根据活动运行和部署的量自动横向扩展或缩减。 作业启动器的性能改进，大大缩短了作业执行时间。

---

关注TechLead，分享AI全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验，同济本复旦硕，复旦机器人智能实验室成员，阿里云认证的资深架构师，项目管理专业人士，上亿营收AI产品研发负责人。