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.go1 - 1
GOARCHフィールドをamd64から$TARGETARCHに変更します。
Operator プロジェクトの makefile は、
PLATFORMS環境変数を定義します。Operator のイメージがデフォルトで設定されているプラットフォームの一部をサポートしていない場合は、変数を編集してサポートされているプラットフォームを指定します。次の例では、サポートされるプラットフォームをlinux/arm64およびlinux/amd64として定義します。例 makefile
# ... PLATFORMS ?= linux/arm64,linux/amd641 .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/arch4 operator: In values: - amd64 - arm64 - ppc64le - s390x - key: kubernetes.io/os5 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/arch3 operator: In4 values: - amd64 - arm64 weight: 905 - 1
- preferred (優先) ルールを定義します。
- 2
nodeSelectorTermsに関連付けられた複数のmatchExpressionsを指定する場合、すべてのmatchExpressionsが満たされている場合にのみ Pod をノードにスケジュールすることができます。- 3
- マニフェストリストで定義されているアーキテクチャーを指定します。
- 4
Operatorを指定します。演算子はIn、NotIn、Exists、またはDoesNotExistにすることができます。たとえば、ノード内にラベルが存在することを要求するには、Inの値を使用します。- 5
- ノードの重みを指定します。有効な値は
1-100です。最も高い重みを持つノードが優先されます。