3.10. マルチアーキテクチャーコンピュートマシンを含むクラスターの管理


複数のアーキテクチャーを使用するノードを含むクラスターを管理するには、クラスターを監視してワークロードを管理するときに、ノードアーキテクチャーを考慮する必要があります。そのため、クラスターリソースの要件と動作を設定するとき、またはマルチアーキテクチャークラスターでワークロードをスケジュールするときには、追加事項を考慮する必要があります。

3.10.1. マルチアーキテクチャーのコンピュートマシンを含むクラスターでワークロードをスケジュールする

異なるアーキテクチャーを使用するコンピュートノードを含むクラスターにワークロードをデプロイする場合は、基盤となるノードのアーキテクチャーに Pod アーキテクチャーを合わせる必要があります。ワークロードによっては、基盤となるノードのアーキテクチャーに応じて、特定のリソースに対する追加の設定が必要になる場合もあります。

Multiarch Tuning Operator を使用すると、マルチアーキテクチャーコンピュートマシンを含むクラスターで、アーキテクチャーを考慮したワークロードのスケジューリングを有効にできます。Multiarch Tuning Operator は、Pod が作成時にサポートできるアーキテクチャーに基づいて、Pod 仕様に追加のスケジューラー述語を実装します。

3.10.1.1. マルチアーキテクチャーノードのワークロードデプロイメントのサンプル

アーキテクチャーに基づいて適切なノードにワークロードをスケジュールする方法は、他のノード特性に基づいてスケジュールする方法と同じです。ワークロードのスケジュール方法を決定するときは、次の選択肢を考慮してください。

nodeAffinity を使用して特定のアーキテクチャーのノードをスケジュールする

イメージによってサポートされるアーキテクチャーを持つ一連のノード上でのみワークロードをスケジュールできるようにすることができ、Pod のテンプレート仕様で spec.affinity.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
サポートされるアーキテクチャーを指定します。有効な値には、amd64arm64、または両方の値が含まれます。
特定のアーキテクチャーの各ノードに taint を付与する

ノードに taint を付与することで、そのアーキテクチャーと互換性のないワークロードがそのノードによってスケジュールされるのを回避できます。クラスターで MachineSet オブジェクトを使用している場合、.spec.template.spec.taints フィールドにパラメーターを追加すると、サポートされていないアーキテクチャーのノードでワークロードがスケジュールされるのを回避できます。

taint をノードに追加する前に、MachineSet オブジェクトをスケールダウンするか、既存の使用可能なマシンを削除する必要があります。詳細は、コンピュートマシンセットの変更 を参照してください。

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

次のコマンドを実行して、特定のノードに taint を設定することもできます。

$ oc adm taint nodes <node-name> multiarch.openshift.io/arch=arm64:NoSchedule
namespace にデフォルトの toleration を作成する

ノードまたはマシンセットに taint を付与すると、スケジュールできるワークロードが、その taint を許容するワークロードだけになります。次のコマンドを実行すると、namespace にアノテーションを付けて、すべてのワークロードに同じデフォルトの toleration を適用できます。

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multiarch.openshift.io/arch"}]'
ワークロードでアーキテクチャーの taint を許容する

ノードまたはマシンセットに taint を付与すると、スケジュールできるワークロードが、その taint を許容するワークロードだけになります。toleration を使用してワークロードを設定すると、特定のアーキテクチャー taint を持つノードでワークロードをスケジュールできます。

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

このサンプルのデプロイメントは、multiarch.openshift.io/arch=arm64 が指定されているノードおよびマシンセットでスケジュールできます。

ノードアフィニティーを taint と toleration とともに使用する

Pod をスケジュールするためのノードセットがスケジューラーによって計算されるとき、そのノードセットは toleration によって拡張される一方で、ノードアフィニティーによって制限されます。特定のアーキテクチャーを持つノードに taint を設定する場合は、そこにスケジュールするワークロードに toleration を追加する必要もあります。

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: "multiarch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"

3.10.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 ロールを含むマシン設定プールを作成します。

    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-pagesdefault です。
    注記

    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

3.10.3. マルチアーキテクチャーコンピュートマシンのイメージストリームにマニフェストリストをインポートする

マルチアーキテクチャーコンピュートマシンを持つ OpenShift Container Platform 4.17 クラスターでは、クラスター内のイメージストリームはマニフェストリストを自動的にインポートしません。マニフェストリストをインポートするには、デフォルトの 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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.