Azure Red Hat OpenShift：让生产级 AI 与平台现代化真正落地

预计阅读时间：10 分钟

Red Hat Summit 2026 上，Microsoft 与 Red Hat 联合展示了一条不少企业正在走的路——用 Azure Red Hat OpenShift（ARO）同时推进平台现代化和生产级 AI 部署。这不是两个独立项目拼在一起，而是同一套平台解决两个核心痛点：老旧基础设施拖慢业务迭代，AI 实验难以跨过"从 demo 到生产"的鸿沟。

ARO 解决的到底是什么问题

很多企业的现状是：开发团队已经在用容器和 Kubernetes，但运维侧还停留在虚拟机手动管理；AI 团队训练了模型，却找不到一个合规、可审计的生产环境来部署推理服务。ARO 的定位很明确——它是托管在 Azure 上的 OpenShift，由 Microsoft 和 Red Hat 共同运维，企业拿到的是一个已经配置好安全策略、监控、日志、CI/CD 集成的生产就绪平台。

关键区别在于"托管"二字：控制平面由两家厂商联合维护，节点升级、补丁、证书轮换都由平台侧完成，企业团队不需要自己扛 OpenShift 的运维负担，但保留了完整的集群管理权限。

平台现代化的实际路径

从传统虚拟机架构迁移到 ARO，不是简单的"搬容器"。Red Hat 在 Summit 上强调的路径是：

先标准化运行环境——用 OpenShift 的 BuildConfig 和 ImageStream 统一镜像构建流程，消除各团队自行拼装镜像的混乱。
再逐步迁移工作负载——通过 OpenShift Virtualization 在同一集群内运行虚拟机工作负载，不需要一刀切全部容器化。
最后统一治理——RBAC、NetworkPolicy、Quota 全部在集群级别配置，不同团队共享同一套策略框架。

这意味着迁移可以分阶段进行，而不是赌一次大规模重构。

生产级 AI 需要什么，ARO 提供了什么

AI 从实验走向生产，最大的障碍不是模型本身，而是运行环境。训练时可以随便开一台 GPU 虚拟机，推理时却要面对：谁来保证服务可用性？谁来做模型版本管理？谁能审计每一次推理请求的数据流向？

ARO 在 AI 场景下提供的支撑包括：

GPU 节点池管理：在 Azure 上直接挂载 ND/NC 系列 GPU 虚拟机作为 Worker Node，OpenShift 的 MachineSet 机制自动处理节点扩缩容。
模型服务部署：通过 OpenShift AI（原 OpenShift Data Science）提供 Jupyter Notebook 开发环境、模型注册、推理服务部署的完整流水线。
企业级安全边界：NetworkPolicy 限制推理服务只接受指定来源的请求，SecurityContextConstraint 控制 GPU 容器的权限范围，审计日志自动汇入 Azure Monitor。

实战：在 ARO 上部署一个 GPU 推理服务

下面是一个可以直接改造使用的示例，展示如何在 ARO 集群上创建 GPU 节点池并部署推理服务。

1. 创建 ARO 集群并添加 GPU 节点池

# 前置条件：已安装 az CLI 并登录，ARO RP 已在订阅中注册

# 创建集群（简化参数，实际生产需配置 VNet、私有链接等）
az aro create \
  --resource-group my-aro-rg \
  --name my-aro-cluster \
  --location eastus \
  --worker-vm-size Standard_D4s_v3 \
  --worker-count 3

# 获取集群登录信息
az aro list-credentials \
  --resource-group my-aro-rg \
  --name my-aro-cluster

# 获取 API Server 地址
az aro show \
  --resource-group my-aro-rg \
  --name my-aro-cluster \
  --query apiserverProfile.url -o tsv

# 登录 OpenShift CLI
oc login https://<api-server-url> \
  --username <admin-user> \
  --password <admin-password>

# 添加 GPU 节点池（NC6s_v3 = 1x V100 GPU）
oc create -f - <<EOF
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: gpu-worker-eastus1
  namespace: openshift-machine-api
  labels:
    machine.openshift.io/cluster-api-cluster: my-aro-cluster
    machine.openshift.io/cluster-api-machine-role: worker
    machine.openshift.io/cluster-api-machine-type: gpu-worker
spec:
  replicas: 2
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: my-aro-cluster
      machine.openshift.io/cluster-api-machineset: gpu-worker-eastus1
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: my-aro-cluster
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: gpu-worker
    spec:
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          kind: AzureMachineProviderSpec
          location: eastus
          vmSize: Standard_NC6s_v3
          image:
            offer: aro4
            publisher: azure-openshift
            resourceID: ""
            sku: aro414
            version: latest
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
          networkResourceGroup: my-aro-rg
          vnet: my-aro-vnet
          subnet: worker-subnet
EOF

# 等待 GPU 节点就绪
oc get nodes -l machine.openshift.io/cluster-api-machine-type=gpu-worker -w

2. 部署推理服务

# inference-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-inference
  namespace: ai-serving
spec:
  replicas: 2
  selector:
    matchLabels:
      app: model-inference
  template:
    metadata:
      labels:
        app: model-inference
    spec:
      # 限制只调度到 GPU 节点
      nodeSelector:
        machine.openshift.io/cluster-api-machine-type: gpu-worker
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: inference-server
          image: quay.io/modh/tritonserver:24.01-py3
          resources:
            limits:
              nvidia.com/gpu: 1
            requests:
              nvidia.com/gpu: 1
          ports:
            - containerPort: 8000
              name: http
            - containerPort: 8001
              name: grpc
          env:
            - name: MODEL_REPOSITORY
              value: /models
          volumeMounts:
            - name: model-store
              mountPath: /models
      volumes:
        - name: model-store
          persistentVolumeClaim:
            claimName: model-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: inference-service
  namespace: ai-serving
spec:
  selector:
    app: model-inference
  ports:
    - port: 8000
      targetPort: 8000
      name: http
  type: ClusterIP
---
# 限制只有指定命名空间可以访问推理服务
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: inference-access-policy
  namespace: ai-serving
spec:
  podSelector:
    matchLabels:
      app: model-inference
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              env: production-app
      ports:
        - port: 8000
          protocol: TCP

# 创建命名空间并添加标签
oc new-project ai-serving
oc label namespace ai-serving env=ai-serving

# 部署推理服务
oc apply -f inference-deployment.yaml

# 验证 GPU 已分配到 Pod
oc exec -it deployment/model-inference -- nvidia-smi --query-gpu=name,memory.used --format=csv

运行前需要确认的事项： - Azure 订阅中 NC6s_v3 的配额是否充足，不足时需提前申请提升。 - 模型文件需预先上传到 PVC 指向的存储（Azure Disk 或 Azure File）。 - 生产环境应配置私有链接，避免 API Server 暴露在公网。

治理不是事后补的，是平台内置的

Summit 上反复提到的一个观点：治理不是限制创新，而是让创新可控。ARO 的治理能力不是额外购买的插件，而是 OpenShift 平台的一部分：

RBAC 统一管理：AI 团队可以在自己的命名空间内自由部署，但无法触碰其他团队的资源，也无法修改集群级策略。
Quota 限制资源争夺：每个命名空间设置 CPU/GPU/内存上限，防止 AI 训练任务吃掉整个集群资源。
审计链路完整：所有 API 调用记录在 OpenShift审计日志中，并可通过 Azure Monitor 导出到企业 SIEM 系统。

落地前的几项决策

如果你正在评估 ARO 作为现代化和 AI 的统一平台，以下清单值得逐条确认：

决策项	需要确认的内容
网络架构	集群是否需要完全私有（Private Link + Private Endpoint），还是允许 API Server 公网访问
GPU 配额	Azure 订阅中目标 GPU SKU 的 vCPU 配额是否已提前申请
团队边界	AI 团队、应用团队、平台团队各自的 RBAC 范围是否已规划
存储策略	模型文件、训练数据使用 Azure Disk、Azure File 还是外部存储（如 ADLS Gen2）
监控集成	OpenShift 日志和指标是否需要汇入已有的 Azure Monitor / Grafana 体系
迁移节奏	是否有虚拟机工作负载需要先通过 OpenShift Virtualization 共存运行

ARO 不是万能钥匙，但它确实把"平台现代化"和"AI 生产化"这两件事放在了同一个技术栈上。对于已经在用 Azure 且需要企业级 Kubernetes 治理的团队来说，这条路的起步成本比自建 OpenShift 或拼装裸 Kubernetes 要低得多。关键在于：不要试图一次性迁移所有工作负载，先选一个 AI 推理场景或一个中等复杂度的应用服务做试点，验证治理策略和 GPU 调度是否符合预期，再逐步扩大范围。