5.16. マルチプラットフォームをサポートするための Operator プロジェクトの設定
複数のアーキテクチャーとオペレーティングシステム (プラットフォーム) をサポートする Operator プロジェクトは、単一のプラットフォームのみをサポートする Operator プロジェクトよりも多くの Kubernetes および OpenShift Container Platform クラスターで実行できます。アーキテクチャーの例には、amd64
、arm64
、ppc64le
、s390x
があります。オペレーティングシステムの例には、Linux や Windows などがあります。
Operator プロジェクトが複数の OpenShift Container Platform プラットフォームで実行できるようにするには、以下のアクションを実行します。
- Operator がサポートするプラットフォームを指定するマニフェストリストを作成します。
- マルチアーキテクチャーのコンピュートマシンをサポートするように Operator のノードアフィニティーを設定します。
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 がインストールされている
手順
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 }, ...
前のコマンドでプラットフォーム情報が出力されない場合、指定されたベースイメージはイメージマニフェストではなく単一イメージである可能性があります。次のコマンドを実行すると、イメージがサポートするアーキテクチャーを確認できます。
$ docker inspect <image>
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
に変更します。
Operator プロジェクトの makefile は、
PLATFORMS
環境変数を定義します。Operator のイメージがデフォルトで設定されているプラットフォームの一部をサポートしていない場合は、変数を編集してサポートされているプラットフォームを指定します。次の例では、サポートされるプラットフォームをlinux/arm64
およびlinux/amd64
として定義します。例 makefile
# ... PLATFORMS ?= linux/arm64,linux/amd64 1 .PHONY: docker-buildx # ...
- 1
- デフォルトでは、次の
PLATFORMS
値が設定されています (linux/arm64
、linux/amd64
、linux/s390x
、およびlinux/ppc64le
)。
make docker buildx
コマンドを実行してマニフェストリストを生成すると、Operator SDK はPLATFORMS
変数で指定されたプラットフォームごとにイメージマニフェストを作成します。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 がサポートするプラットフォームを定義するマニフェストリスト。
手順
Operator プロジェクトで、Pod 仕様および Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストを検索します。
重要オブジェクト型名は YAML ファイルで宣言されていないため、Kubernetes マニフェストで必須の
containers
フィールドを探してください。Pod 仕様オブジェクトと Pod テンプレート仕様オブジェクトの両方を指定する場合は、containers
フィールドが必要です。Pod
、Deployment
、DaemonSet
、StatefulSet
などのオブジェクトを含む、Pod 仕様または Pod テンプレート仕様を定義するすべての Kubernetes マニフェストにノードアフィニティールールを設定する必要があります。Kubernetes マニフェストの例
apiVersion: v1 kind: Pod metadata: name: s1 spec: containers: - name: <container_name> image: docker.io/<org>/<image_name>
次の例のように、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
- マニフェストリストで定義されているオペレーティングシステムを指定します。
動的に作成されたワークロードを使用する 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 プロジェクトには、必要なノードアフィニティールールが設定されています。
手順
Operator プロジェクトで、Pod 仕様および Pod テンプレート仕様オブジェクトを定義する Kubernetes マニフェストを検索します。
Kubernetes マニフェストの例
apiVersion: v1 kind: Pod metadata: name: s1 spec: containers: - name: <container_name> image: docker.io/<org>/<image_name>
次の例のように、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
を指定します。演算子はIn
、NotIn
、Exists
、またはDoesNotExist
にすることができます。たとえば、ノード内にラベルが存在することを要求するには、In
の値を使用します。- 5
- ノードの重みを指定します。有効な値は
1
-100
です。最も高い重みを持つノードが優先されます。