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
- サポートされるアーキテクチャーを指定します。有効な値には、
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
次のコマンドを実行して、特定のノードに 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
) がインストールされている。 - サポート対象のいずれかのプラットフォームで、異なるアーキテクチャーのコンピュートノードを含むクラスターを作成している。
手順
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
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