検索

5.16. マルチプラットフォームをサポートするための Operator プロジェクトの設定

download PDF

複数のアーキテクチャーとオペレーティングシステム (プラットフォーム) をサポートする Operator プロジェクトは、単一のプラットフォームのみをサポートする Operator プロジェクトよりも多くの Kubernetes および OpenShift Container Platform クラスターで実行できます。アーキテクチャーの例には、amd64arm64ppc64les390x があります。オペレーティングシステムの例には、Linux や Windows などがあります。

Operator プロジェクトが複数の OpenShift Container Platform プラットフォームで実行できるようにするには、以下のアクションを実行します。

  • Operator がサポートするプラットフォームを指定するマニフェストリストを作成します。
  • マルチアーキテクチャーのコンピュートマシンをサポートするように Operator のノードアフィニティーを設定します。
重要

Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、OpenShift Container Platform の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、OpenShift Container Platform リリースから削除されます。

新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、OpenShift Container Platform 4.16 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、OpenShift Container Platform の新しいバージョンを対象とする Operator リリースを作成できます。

Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。

  • Ansible ベースの Operator プロジェクトのベースイメージ
  • Helm ベースの Operator プロジェクトのベースイメージ

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。

5.16.1. Operator がサポートするプラットフォームのマニフェストリストの作成

make docker-buildx コマンドを使用すると、Operator とオペランドによってサポートされるプラットフォームのマニフェストリストを作成できます。マニフェストリストは、1 つ以上のアーキテクチャーの特定のイメージマニフェストを参照します。イメージマニフェストは、イメージがサポートするプラットフォームを指定します。

詳細は、OpenContainers Image Index Spec または Image Manifest v2, Schema 2 を参照してください。

重要

Operator プロジェクトがアプリケーションまたはその他のワークロードリソースをデプロイする場合、次の手順では、アプリケーションのリリースプロセス中にアプリケーションのマルチプラットフォームイメージが構築されることを前提としています。

前提条件

  • Operator SDK バージョン 1.31.0 以降を使用して構築された Operator プロジェクト
  • Docker がインストールされている

手順

  1. Operator とオペランドのイメージマニフェストを調べて、Operator プロジェクトがサポートできるプラットフォームを見つけます。次のコマンドを実行して、イメージマニフェストを検査します。

    $ docker manifest inspect <image_manifest> 1
    1
    redhat/ubi9:latest などのイメージマニフェストを指定します。

    Operator とオペランドが相互にサポートするプラットフォームによって、Operator プロジェクトのプラットフォーム互換性が決まります。

    出力例

    {
        "manifests": [
            {
                "digest": "sha256:c0669ef34cdc14332c0f1ab0c2c01acb91d96014b172f1a76f3a39e63d1f0bda",
                "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
                "platform": {
                    "architecture": "amd64",
                    "os": "linux"
                },
                "size": 528
            },
    ...
            {
                "digest": "sha256:30e6d35703c578ee703230b9dc87ada2ba958c1928615ac8a674fcbbcbb0f281",
                "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
                "platform": {
                    "architecture": "arm64",
                    "os": "linux",
                    "variant": "v8"
                },
                "size": 528
            },
    ...

  2. 前のコマンドでプラットフォーム情報が出力されない場合、指定されたベースイメージはイメージマニフェストではなく単一イメージである可能性があります。次のコマンドを実行すると、イメージがサポートするアーキテクチャーを確認できます。

    $ docker inspect <image>
  3. Go ベースの Operator プロジェクトの場合、Operator SDK はプロジェクトの Dockerfile で amd64 アーキテクチャーを明示的に参照します。Dockerfile に次の変更を加えて、環境変数をプラットフォームフラグで指定された値に設定します。

    Dockerfile の例

    FROM golang:1.19 as builder
    ARG TARGETOS
    ARG TARGETARCH
    ...
    RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o manager main.go 1

    1
    GOARCH フィールドを amd64 から $TARGETARCH に変更します。
  4. Operator プロジェクトの makefile は、PLATFORMS 環境変数を定義します。Operator のイメージがデフォルトで設定されているプラットフォームの一部をサポートしていない場合は、変数を編集してサポートされているプラットフォームを指定します。次の例では、サポートされるプラットフォームを linux/arm64 および linux/amd64 として定義します。

    例 makefile

    # ...
    PLATFORMS ?= linux/arm64,linux/amd64 1
    .PHONY: docker-buildx
    # ...

    1
    デフォルトでは、次の PLATFORMS 値が設定されています (linux/arm64linux/amd64linux/s390x、および linux/ppc64le)。

    make docker buildx コマンドを実行してマニフェストリストを生成すると、Operator SDK は PLATFORMS 変数で指定されたプラットフォームごとにイメージマニフェストを作成します。

  5. Operator プロジェクトディレクトリーから次のコマンドを実行して、マネージャーイメージを構築します。コマンドを実行すると、マルチプラットフォームをサポートするマネージャーイメージが構築され、マニフェストリストがレジストリーにプッシュされます。

    $ make docker-buildx \
      IMG=<image_registry>/<organization_name>/<repository_name>:<version_or_sha>

5.16.2. マルチアーキテクチャーのコンピュートマシンと Operator ワークロードのノードアフィニティールールについて

Operator ワークロードがマルチアーキテクチャーのコンピュートマシン上で実行できるようにするには、ノードアフィニティールールを設定する必要があります。ノードアフィニティーは、Pod の配置を定義するためにスケジューラーによって使用される一連のルールです。ノードアフィニティールールを設定すると、互換性のあるアーキテクチャーでマシンを計算するように Operator のワークロードがスケジュールされるようになります。

Operator が特定のアーキテクチャーでパフォーマンスが向上する場合は、優先ノードアフィニティールールを設定して、指定されたアーキテクチャーを持つマシンに Pod をスケジュールできます。

詳細は、「マルチアーキテクチャーのコンピュートマシンを使用したクラスターについて」および「ノードアフィニティールールを使用したノード上の Pod 配置の制御」を参照してください。

5.16.2.1. Operator プロジェクトのマルチアーキテクチャーコンピュートマシンをサポートするために必要なノードアフィニティールールを使用する

Operator でマルチアーキテクチャーのコンピュートマシンをサポートする場合は、Operator に必要なノードアフィニティールールを定義する必要があります。

前提条件

  • Operator SDK 1.31.0 で作成または保守されている Operator プロジェクト。
  • Operator がサポートするプラットフォームを定義するマニフェストリスト。

手順

  1. Operator プロジェクトで、Pod 仕様および Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストを検索します。

    重要

    オブジェクト型名は YAML ファイルで宣言されていないため、Kubernetes マニフェストで必須の containers フィールドを探してください。Pod 仕様オブジェクトと Pod テンプレート仕様オブジェクトの両方を指定する場合は、containers フィールドが必要です。

    PodDeploymentDaemonSetStatefulSet などのオブジェクトを含む、Pod 仕様または Pod テンプレート仕様を定義するすべての Kubernetes マニフェストにノードアフィニティールールを設定する必要があります。

    Kubernetes マニフェストの例

    apiVersion: v1
    kind: Pod
    metadata:
      name: s1
    spec:
      containers:
        - name: <container_name>
          image: docker.io/<org>/<image_name>

  2. 次の例のように、Pod 仕様オブジェクトと Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストに必要なノードアフィニティールールを設定します。

    Kubernetes マニフェストの例

    apiVersion: v1
    kind: Pod
    metadata:
      name: s1
    spec:
      containers:
        - name: <container_name>
          image: docker.io/<org>/<image_name>
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 1
            nodeSelectorTerms: 2
            - matchExpressions: 3
              - key: kubernetes.io/arch 4
                operator: In
                values:
                - amd64
                - arm64
                - ppc64le
                - s390x
              - key: kubernetes.io/os 5
                operator: In
                values:
                    - linux

    1
    required (必須) ルールを定義します。
    2
    nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。
    3
    nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。
    4
    マニフェストリストで定義されているアーキテクチャーを指定します。
    5
    マニフェストリストで定義されているオペレーティングシステムを指定します。
  3. 動的に作成されたワークロードを使用する Go ベースの Operator プロジェクトでは、Operator のロジックに Pod 仕様および Pod テンプレート仕様オブジェクトが埋め込まれる場合があります。

    プロジェクトで Operator のロジックに Pod 仕様または Pod テンプレート仕様オブジェクトが埋め込まれている場合は、次の例のように Operator のロジックを編集します。次の例は、Go API を使用して PodSpec オブジェクトを更新する方法を示しています。

    Template: corev1.PodTemplateSpec{
        ...
        Spec: corev1.PodSpec{
            Affinity: &corev1.Affinity{
                NodeAffinity: &corev1.NodeAffinity{
                    RequiredDuringSchedulingIgnoredDuringExecution: &corev1.NodeSelector{
                        NodeSelectorTerms: []corev1.NodeSelectorTerm{
                            {
                                MatchExpressions: []corev1.NodeSelectorRequirement{
                                    {
                                        Key:      "kubernetes.io/arch",
                                        Operator: "In",
                                        Values:   []string{"amd64","arm64","ppc64le","s390x"},
                                    },
                                    {
                                        Key:      "kubernetes.io/os",
                                        Operator: "In",
                                        Values:   []string{"linux"},
                                    },
                                },
                            },
                        },
                    },
                },
            },
            SecurityContext: &corev1.PodSecurityContext{
                ...
            },
            Containers: []corev1.Container{{
                ...
            }},
        },

    ここでは、以下のようになります。

    RequiredDuringSchedulingIgnoredDuringExecution
    required (必須) ルールを定義します。
    NodeSelectorTerms
    nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。
    MatchExpressions
    nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。
    kubernetes.io/arch
    マニフェストリストで定義されているアーキテクチャーを指定します。
    kubernetes.io/os
    マニフェストリストで定義されているオペレーティングシステムを指定します。
警告

ノードアフィニティールールを設定せず、互換性のないアーキテクチャーを持つコンピュートマシンにコンテナーがスケジュールされている場合は、Pod が失敗し、次のいずれかのイベントがトリガーされます。

CrashLoopBackOff
イメージマニフェストのエントリーポイントの実行が失敗し、exec format error メッセージがログに出力されると発生します。
ImagePullBackOff
Pod がスケジュールされているアーキテクチャーのマニフェストがマニフェストリストに含まれていない場合、またはノードアフィニティー条件が間違った値に設定されている場合に発生します。

5.16.2.2. 優先ノードアフィニティールールを使用して Operator プロジェクトのマルチアーキテクチャーコンピュートマシンのサポートを設定する

Operator のパフォーマンスが特定のアーキテクチャーで向上する場合は、優先ノードアフィニティールールを設定して、指定されたアーキテクチャーのノードに Pod をスケジュールできます。

前提条件

  • Operator SDK 1.31.0 で作成または保守されている Operator プロジェクト。
  • Operator がサポートするプラットフォームを定義するマニフェストリスト。
  • Operator プロジェクトには、必要なノードアフィニティールールが設定されています。

手順

  1. Operator プロジェクトで、Pod 仕様および Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストを検索します。

    Kubernetes マニフェストの例

    apiVersion: v1
    kind: Pod
    metadata:
      name: s1
    spec:
      containers:
        - name: <container_name>
          image: docker.io/<org>/<image_name>

  2. 次の例のように、Pod 仕様および Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストで、Operator の優先ノードアフィニティールールを設定します。

    Kubernetes マニフェストの例

    apiVersion: v1
    kind: Pod
    metadata:
      name: s1
    spec:
      containers:
        - name: <container_name>
          image: docker.io/<org>/<image_name>
      affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution: 1
              - preference:
                matchExpressions: 2
                  - key: kubernetes.io/arch 3
                    operator: In 4
                    values:
                    - amd64
                    - arm64
                weight: 90 5

    1
    preferred (優先) ルールを定義します。
    2
    nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。
    3
    マニフェストリストで定義されているアーキテクチャーを指定します。
    4
    Operator を指定します。演算子は InNotInExists、または DoesNotExist にすることができます。たとえば、ノード内にラベルが存在することを要求するには、In の値を使用します。
    5
    ノードの重みを指定します。有効な値は 1 - 100 です。最も高い重みを持つノードが優先されます。

5.16.3. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.