4.10. マルチアーキテクチャーコンピュートマシンを含むクラスターの管理
4.10.1. マルチアーキテクチャーのコンピュートマシンを含むクラスターでワークロードをスケジュールする
さまざまなアーキテクチャーのコンピュートノードを含むクラスターにワークロードをデプロイするには、クラスターの注意と監視が必要です。クラスターのノードに Pod を正常に配置するには、さらにアクションが必要な場合があります。
Multiarch Tuning Operator を使用すると、マルチアーキテクチャーコンピュートマシンを含むクラスターで、アーキテクチャーを考慮したワークロードのスケジューリングを有効にできます。Multiarch Tuning Operator は、Pod が作成時にサポートできるアーキテクチャーに基づいて、Pod 仕様に追加のスケジューラー述語を実装します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。
ノードアフィニティー、スケジューリング、taint、toleration の詳細は、次のドキュメントを参照してください。
4.10.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、または両方の値が含まれます。
- 特定のアーキテクチャー向けにすべてのノードを taint する
ノードを taint して、そのノード上でそのアーキテクチャーと互換性のないワークロードがスケジュールされるのを回避できます。クラスターが
MachineSetオブジェクトを使用している場合は、サポートされていないアーキテクチャーのノードでワークロードがスケジュールされるのを回避するために、パラメーターを.spec.template.spec.taintsフィールドに追加できます。ノードを taint する前に、
MachineSetオブジェクトをスケールダウンするか、使用可能なマシンを削除する必要があります。次のコマンドのいずれかを使用して、マシンセットをスケールダウンできます。$ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
または、以下を実行します。
$ oc edit machineset <machineset> -n openshift-machine-api
マシンセットのスケーリングの詳細は、「コンピュートマシンセットの変更」を参照してください。
taint セットを含む
MachineSetの例apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: # ... spec: # ... template: # ... spec: # ... taints: - effect: NoSchedule key: multi-arch.openshift.io/arch value: arm64次のコマンドを実行して、特定のノードに taint を設定することもできます。
$ oc adm taint nodes <node-name> multi-arch.openshift.io/arch=arm64:NoSchedule
- デフォルト許容範囲の作成
次のコマンドを実行して、namespace にアノテーションを付けて、すべてのワークロードが同じデフォルトの許容範囲を取得できるようにすることができます。
$ oc annotate namespace my-namespace \ 'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multi-arch.openshift.io/arch"}]'- ワークロードにおけるアーキテクチャーの taint を許容する
taint が定義されたノードでは、そのノード上でワークロードはスケジュールされません。ただし、Pod の仕様で toleration を設定することで、スケジュールを許可できます。
許容を備えた導入例
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=arm64taint が指定されたノードでも許可できます。- taint および許容でのノードアフィニティーの使用
スケジューラーが Pod をスケジュールするためにノードのセットを計算する場合は、ノードアフィニティーによってセットが制限される一方で、許容によってセットが拡大する可能性があります。特定のアーキテクチャーのノードに taint を設定する場合、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.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) がインストールされている。 - サポート対象のいずれかのプラットフォームで、異なるアーキテクチャーのコンピュートノードを含むクラスターを作成している。
手順
64k ページサイズのカーネルを実行するノードにラベルを付けます。
$ oc label node <node_name> <label>
コマンドの例
$ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=
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コンピュートノード上にマシン設定を作成し、
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注記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.10.3. マルチアーキテクチャーコンピュートマシンのイメージストリームにマニフェストリストをインポートする
マルチアーキテクチャーコンピュートマシンを持つ OpenShift Container Platform 4.16 クラスターでは、クラスター内のイメージストリームはマニフェストリストを自動的にインポートしません。マニフェストリストをインポートするには、デフォルトの importMode オプションを PreserveOriginal オプションに手動で変更する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc) をインストールしている。
手順
次のコマンド例は、
ImageStreamcli-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
