支持控制台（Console）开发人员开始试用联系人

4.9. 使用多架构计算机器管理集群

4.9.1. 使用多架构计算机器在集群中调度工作负载

使用不同架构的计算节点在集群中部署工作负载需要注意和监控集群。您可能需要进行进一步的操作，才能成功将 pod 放置到集群的节点中。

如需有关节点关联性、调度、污点和容限和容忍的更多信息，请参阅以下文档：

4.9.1.1. 多架构节点工作负载部署示例

在使用不同架构的计算节点将工作负载调度到具有不同架构的计算节点上之前，请考虑以下用例：

使用节点关联性在节点上调度工作负载

您可以只允许将工作负载调度到其镜像支持的一组节点上，您可以在 pod 模板规格中设置 spec.affinity.nodeAffinity 字段。

将 nodeAffinity 设置为特定架构的部署示例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
   # ...
  template:
     # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values: 1
                - amd64
                - arm64

1
指定支持的构架。有效值包括 amd64,arm64, 或这两个值。
为特定架构污点每个节点

您可以污点节点，以避免与其架构不兼容的工作负载调度到该节点上。如果集群正在使用 MachineSet 对象，您可以在 .spec.template.spec.taints 字段中添加参数，以避免在带有不支持的架构的节点上调度工作负载。

  • 在污点节点前，您必须缩减 MachineSet 对象或删除可用的机器。您可以使用以下命令之一缩减机器集： 

    $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

    或者： 

    $ oc edit machineset <machineset> -n openshift-machine-api

    有关扩展机器集的更多信息，请参阅"修改计算机器集"。

带有污点集的 MachineSet 示例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      taints:
      - effect: NoSchedule
        key: multi-arch.openshift.io/arch
        value: arm64

您还可以运行以下命令来在特定节点上设置污点： 

$ oc adm taint nodes <node-name> multi-arch.openshift.io/arch=arm64:NoSchedule
创建默认容限

您可以运行以下命令来注解命名空间，以便所有工作负载都获得相同的默认容限： 

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multi-arch.openshift.io/arch"}]'
在工作负载中容忍架构污点

在具有定义污点的节点上，工作负载不会调度到该节点上。但是，您可以通过在 pod 的规格中设置容限来允许调度它们。

具有容限的部署示例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"

本例部署也可以在指定了 multi-arch.openshift.io/arch=arm64 污点的节点上允许。

使用带有污点和容限的节点关联性

当调度程序计算一组要调度 pod 的节点时，容限可能会扩大集合，而节点关联性会限制集合。如果将污点设置为特定架构的节点，则需要以下示例容限才能调度 pod。

使用节点关联性和容限集的部署示例。

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
                - arm64
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"

其他资源

4.9.2. 在 Red Hat Enterprise Linux CoreOS (RHCOS) 内核中启用 64k 页

您可以在集群中的 64 位 ARM 计算机器上启用 Red Hat Enterprise Linux CoreOS (RHCOS) 内核中的 64k 内存页。64k 页大小内核规格可用于大型 GPU 或高内存工作负载。这使用 Machine Config Operator (MCO) 完成，它使用机器配置池来更新内核。要启用 64k 页面大小，您必须为 ARM64 指定一个机器配置池，以便在内核中启用。

重要

使用 64k 页专用于 64 位 ARM 架构计算节点或在 64 位 ARM 机器上安装的集群。如果您使用 64 位 x86 机器在机器配置池中配置 64k 页内核，机器配置池和 MCO 将降级。

先决条件

  • 已安装 OpenShift CLI（oc）。
  • 您在其中一个支持的平台中使用不同架构的计算节点创建集群。

流程

  1. 标记您要运行 64k 页大小内核的节点： 

    $ oc label node <node_name> <label>

    示例命令

    $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=

  2. 创建包含使用 ARM64 架构和 worker-64k-pages 角色的 worker 角色的机器配置池： 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-64k-pages
spec:
  machineConfigSelector:
    matchExpressions:
      - key: machineconfiguration.openshift.io/role
        operator: In
        values:
        - worker
        - worker-64k-pages
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-64k-pages: ""
      kubernetes.io/arch: arm64

  3. 在计算节点上创建机器配置，以使用 64k-pages 参数启用 64k-pages。 

    $ oc create -f <filename>.yaml

    MachineConfig 示例

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: "worker-64k-pages" 1
  name: 99-worker-64kpages
spec:
  kernelType: 64k-pages 2

    1
    在自定义机器配置池中指定 machineconfiguration.openshift.io/role 标签的值。MachineConfig 示例使用 worker-64k-pages 标签在 worker-64k-pages 池中启用 64k 页面。
    2
    指定所需的内核类型。有效值为 64k-pages 和 default
    注意

    64k-pages 类型仅支持基于 64 位 ARM 架构。realtime 类型仅支持基于 64 位 x86 架构。

验证

  • 要查看您的新 worker-64k-pages 机器配置池，请运行以下命令： 

    $ oc get mcp

    输出示例

    NAME     CONFIG                                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-9d55ac9a91127c36314e1efe7d77fbf8                      True      False      False      3              3                   3                     0                      361d
worker   rendered-worker-e7b61751c4a5b7ff995d64b967c421ff                      True      False      False      7              7                   7                     0                      361d
worker-64k-pages  rendered-worker-64k-pages-e7b61751c4a5b7ff995d64b967c421ff   True      False      False      2              2                   2                     0                      35m

4.9.3. 在多架构计算机器上的镜像流中导入清单列表

在带有多架构计算机器的 OpenShift Container Platform 4.15 集群中，集群中的镜像流不会自动导入清单列表。您必须手动将默认的 importMode 选项改为 PreserveOriginal 选项，才能导入清单列表。

先决条件

  • 已安装 OpenShift Container Platform CLI (oc)。

流程

  • 以下示例命令演示了如何对 ImageStream cli-artifacts 进行补丁，以便 cli-artifacts:latest 镜像流标签作为清单列表导入。 

    $ oc patch is/cli-artifacts -n openshift -p '{"spec":{"tags":[{"name":"latest","importPolicy":{"importMode":"PreserveOriginal"}}]}}'

验证

  • 您可以通过检查镜像流标签来检查是否正确导入的清单列表。以下命令将列出特定标签的各个架构清单。 

    $ oc get istag cli-artifacts:latest -n openshift -oyaml

    如果存在 dockerImageManifests 对象，则清单列表导入成功。

    dockerImageManifests 对象的输出示例

    dockerImageManifests:
  - architecture: amd64
    digest: sha256:16d4c96c52923a9968fbfa69425ec703aff711f1db822e4e9788bf5d2bee5d77
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: arm64
    digest: sha256:6ec8ad0d897bcdf727531f7d0b716931728999492709d19d8b09f0d90d57f626
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: ppc64le
    digest: sha256:65949e3a80349cdc42acd8c5b34cde6ebc3241eae8daaeea458498fedb359a6a
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: s390x
    digest: sha256:75f4fa21224b5d5d511bea8f92dfa8e1c00231e5c81ab95e83c3013d245d1719
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.