Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

異なるアーキテクチャーを使用するコンピュートノードを含むクラスターにワークロードをデプロイする場合は、基盤となるノードのアーキテクチャーに 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
Copy to Clipboard Toggle word wrap
1
サポートされるアーキテクチャーを指定します。有効な値には、amd64、arm64、または両方の値が含まれます。
特定のアーキテクチャーの各ノードに 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
Copy to Clipboard Toggle word wrap

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

$ oc adm taint nodes <node-name> multiarch.openshift.io/arch=arm64:NoSchedule
Copy to Clipboard Toggle word wrap
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"}]'
Copy to Clipboard Toggle word wrap
ワークロードでアーキテクチャーの 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"
Copy to Clipboard Toggle word wrap

このサンプルのデプロイメントは、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"
Copy to Clipboard Toggle word wrap

関連情報

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>
    Copy to Clipboard Toggle word wrap

    コマンドの例

    $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  3. コンピュートノード上にマシン設定を作成し、64k-pages パラメーターを使用して 64k-pages を有効にします。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    出力例

    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
    Copy to Clipboard Toggle word wrap

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

検証

  • イメージストリームタグを調べて、マニフェストリストが正しくインポートされたことを確認できます。次のコマンドは、特定のタグの個々のアーキテクチャーマニフェストを一覧表示します。 

    $ oc get istag cli-artifacts:latest -n openshift -oyaml
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat