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

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、または両方の値が含まれます。
特定のアーキテクチャー向けにすべてのノードを 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=arm64 taint が指定されたノードでも許可できます。

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.9.2. マルチアーキテクチャーコンピューティングマシンのイメージストリームにマニフェストリストをインポートする

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