第4章 管理者タスク
4.1. Operator のクラスターへの追加
Operator Lifecycle Manager (OLM) を使用して、クラスター管理者は OLM ベースの Operator を OpenShift Container Platform クラスターにインストールできます。
OLM が同一 namespace に配置されたインストール済み Operator の更新を処理する方法や、カスタムグローバル Operator グループで Operator をインストールする別の方法は、マルチテナント対応と Operator のコロケーション を参照してください。
4.1.1. OperatorHub を使用した Operator のインストールについて
OperatorHub は Operator を検出するためのユーザーインターフェイスです。これは Operator Lifecycle Manager (OLM) と連携し、クラスター上で Operator をインストールし、管理します。
適切なパーミッションを持つユーザーとして、OpenShift Container Platform Web コンソールまたは CLI を使用して OperatorHub から Operator をインストールできます。
インストール時に、Operator の以下の初期設定を判別する必要があります。
- インストールモード
- Operator をインストールする特定の namespace を選択します。
- 更新チャネル
- Operator が複数のチャネルで利用可能な場合、サブスクライブするチャネルを選択できます。たとえば、(利用可能な場合に) stable チャネルからデプロイするには、これをリストから選択します。
- 承認ストラテジー
自動 (Automatic) または手動 (Manual) のいずれかの更新を選択します。
インストールされた Operator について自動更新を選択する場合、Operator の新規バージョンが選択されたチャネルで利用可能になると、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
手動更新を選択する場合、Operator の新規バージョンが利用可能になると、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
関連情報
4.1.2. Web コンソールを使用した OperatorHub からのインストール
OpenShift Container Platform Web コンソールを使用して OperatorHub から Operator をインストールし、これをサブスクライブできます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
-
Web コンソールで、Operators
OperatorHub ページに移動します。 スクロールするか、キーワードを Filter by keyword ボックスに入力し、必要な Operator を見つけます。たとえば、Advanced Cluster Management for Kubernetes Operator を検索するには
advanced
を入力します。また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
Operator を選択して、追加情報を表示します。
注記コミュニティー Operator を選択すると、Red Hat がコミュニティー Operator を認定していないことを警告します。続行する前に警告を確認する必要があります。
- Operator に関する情報を確認してから、Install をクリックします。
Install Operator ページで以下を行います。
以下のいずれかを選択します。
-
All namespaces on the cluster (default) は、デフォルトの
openshift-operators
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。このオプションは常に選択可能です。 - A specific namespace on the cluster では、Operator をインストールする特定の単一 namespace を選択できます。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
-
All namespaces on the cluster (default) は、デフォルトの
- Operator をインストールする特定の単一 namespace を選択します。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
- Update channel を選択します (複数を選択できる場合)。
- 前述のように、Automatic または Manual 承認ストラテジーを選択します。
Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、そのインストール計画を確認し、承認するまで Upgrading のままになります。
Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
- 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。
サブスクリプションのアップグレードステータスが Up to date になった後に、Operators
Installed Operators を選択し、インストールされた Operator のクラスターサービスバージョン (CSV) が表示されることを確認します。その Status は最終的に関連する namespace で InstallSucceeded に解決するはずです。 注記All namespaces… インストールモードの場合、ステータスは
openshift-operators
namespace で InstallSucceeded になりますが、他の namespace でチェックする場合、ステータスは Copied になります。上記通りにならない場合、以下を実行します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads
Pods ページで、 openshift-operators
プロジェクト (または A specific namespace… インストールモードが選択されている場合は他の関連の namespace) の Pod のログを確認します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads
4.1.3. CLI を使用した OperatorHub からのインストール
OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。oc
コマンドを使用して、Subscription
オブジェクトを作成または更新します。
前提条件
- Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
OperatorHub からクラスターで利用できる Operator のリストを表示します。
$ oc get packagemanifests -n openshift-marketplace
出力例
NAME CATALOG AGE 3scale-operator Red Hat Operators 91m advanced-cluster-management Red Hat Operators 91m amq7-cert-manager Red Hat Operators 91m ... couchbase-enterprise-certified Certified Operators 91m crunchy-postgres-operator Certified Operators 91m mongodb-enterprise Certified Operators 91m ... etcd Community Operators 91m jaeger Community Operators 91m kubefed Community Operators 91m ...
必要な Operator のカタログをメモします。
必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。
$ oc describe packagemanifests <operator_name> -n openshift-marketplace
OperatorGroup
で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (
AllNamespaces
またはSingleNamespace
モードのいずれか)。インストールする Operator がAllNamespaces
モードを使用する場合、openshift-operators
namespace には適切なglobal-operators
Operator グループがすでに配置されています。ただし、Operator が
SingleNamespace
モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。注記-
この手順の Web コンソールバージョンでは、
SingleNamespace
モードを選択する際に、OperatorGroup
およびSubscription
オブジェクトの作成を背後で自動的に処理します。 - namespace ごとに Operator グループを 1 つだけ持つことができます。詳細は、「Operator グループ」を参照してください。
OperatorGroup
オブジェクト YAML ファイルを作成します (例:operatorgroup.yaml
)。OperatorGroup
オブジェクトのサンプルapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <namespace> spec: targetNamespaces: - <namespace>
警告Operator Lifecycle Manager (OLM) は、各 Operator グループに対して次のクラスターロールを作成します。
-
<operatorgroup_name>-admin
-
<operatorgroup_name>-edit
-
<operatorgroup_name>-view
Operator グループを手動で作成する場合は、既存のクラスターロールまたはクラスター上の他のOperator グループと競合しない一意の名前を指定する必要があります。
-
OperatorGroup
オブジェクトを作成します。$ oc apply -f operatorgroup.yaml
-
この手順の Web コンソールバージョンでは、
Subscription
オブジェクトの YAML ファイルを作成し、namespace を Operator にサブスクライブします (例:sub.yaml
)。Subscription
オブジェクトの例apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: <subscription_name> namespace: openshift-operators 1 spec: channel: <channel_name> 2 name: <operator_name> 3 source: redhat-operators 4 sourceNamespace: openshift-marketplace 5 config: env: 6 - name: ARGS value: "-v=10" envFrom: 7 - secretRef: name: license-secret volumes: 8 - name: <volume_name> configMap: name: <configmap_name> volumeMounts: 9 - mountPath: <directory_name> name: <volume_name> tolerations: 10 - operator: "Exists" resources: 11 requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" nodeSelector: 12 foo: bar
- 1
- デフォルトの
AllNamespaces
インストールモードの使用については、openshift-operators
namespace を指定します。カスタムグローバル namespace を作成している場合はこれを指定できます。それ以外の場合は、SingleNamespace
インストールモードの使用について関連する単一の namespace を指定します。 - 2
- サブスクライブするチャネルの名前。
- 3
- サブスクライブする Operator の名前。
- 4
- Operator を提供するカタログソースの名前。
- 5
- カタログソースの namespace。デフォルトの OperatorHub カタログソースには
openshift-marketplace
を使用します。 - 6
env
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要がある環境変数の一覧を定義します。- 7
envFrom
パラメーターは、コンテナーの環境変数に反映するためのソースの一覧を定義します。- 8
volumes
パラメーターは、OLM によって作成される Pod に存在する必要があるボリュームの一覧を定義します。- 9
volumeMounts
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要があるボリュームマウントの一覧を定義します。volumeMount
が存在しないボリューム
を参照する場合、OLM は Operator のデプロイに失敗します。- 10
tolerations
パラメーターは、OLM によって作成される Pod の toleration の一覧を定義します。- 11
resources
パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。- 12
nodeSelector
パラメーターは、OLM によって作成される Pod のノードセレクター
を定義します。
Subscription
オブジェクトを作成します。$ oc apply -f sub.yaml
この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
関連情報
4.1.4. Operator の特定バージョンのインストール
Subscription
オブジェクトにクラスターサービスバージョン (CSV) を設定して Operator の特定バージョンをインストールできます。
前提条件
- Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、インストールする Operator の利用可能なバージョンとチャネルを検索します。
コマンド構文
$ oc describe packagemanifests <operator_name> -n <catalog_namespace>
たとえば、次のコマンドは、OperatorHub から Red Hat Quay Operator の利用可能なチャネルとバージョンを出力します。
コマンドの例
$ oc describe packagemanifests quay-operator -n openshift-marketplace
例4.1 出力例
Name: quay-operator Namespace: operator-marketplace Labels: catalog=redhat-operators catalog-namespace=openshift-marketplace hypershift.openshift.io/managed=true operatorframework.io/arch.amd64=supported operatorframework.io/os.linux=supported provider=Red Hat provider-url= Annotations: <none> API Version: packages.operators.coreos.com/v1 Kind: PackageManifest ... Current CSV: quay-operator.v3.7.11 ... Entries: Name: quay-operator.v3.7.11 Version: 3.7.11 Name: quay-operator.v3.7.10 Version: 3.7.10 Name: quay-operator.v3.7.9 Version: 3.7.9 Name: quay-operator.v3.7.8 Version: 3.7.8 Name: quay-operator.v3.7.7 Version: 3.7.7 Name: quay-operator.v3.7.6 Version: 3.7.6 Name: quay-operator.v3.7.5 Version: 3.7.5 Name: quay-operator.v3.7.4 Version: 3.7.4 Name: quay-operator.v3.7.3 Version: 3.7.3 Name: quay-operator.v3.7.2 Version: 3.7.2 Name: quay-operator.v3.7.1 Version: 3.7.1 Name: quay-operator.v3.7.0 Version: 3.7.0 Name: stable-3.7 ... Current CSV: quay-operator.v3.8.5 ... Entries: Name: quay-operator.v3.8.5 Version: 3.8.5 Name: quay-operator.v3.8.4 Version: 3.8.4 Name: quay-operator.v3.8.3 Version: 3.8.3 Name: quay-operator.v3.8.2 Version: 3.8.2 Name: quay-operator.v3.8.1 Version: 3.8.1 Name: quay-operator.v3.8.0 Version: 3.8.0 Name: stable-3.8 Default Channel: stable-3.8 Package Name: quay-operator
ヒント次のコマンドを実行すると、Operator のバージョンとチャネル情報を YAML 形式で出力できます。
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
namespace に複数のカタログがインストールされている場合は、次のコマンドを実行して、特定のカタログから Operator の使用可能なバージョンとチャネルを検索します。
$ oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
重要Operator のカタログを指定しない場合、
oc get packagemanifest
およびoc describe packagemanifest
コマンドを実行すると、次の条件が満たされると予期しないカタログからパッケージが返される可能性があります。- 複数のカタログが同じ namespace にインストールされます。
- カタログには、同じ Operator、または同じ名前の Operator が含まれています。
OperatorGroup
オブジェクトによって定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要なロールベースのアクセス制御 (RBAC) アクセスを生成するターゲットの namespace を選択します。Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (
AllNamespaces
またはSingleNamespace
モードのいずれか)。インストールしようとしている Operator がAllNamespaces
モードを使用する場合、openshift-operators
namespace にはすでに適切な Operator グループが存在します。ただし、Operator が
SingleNamespace
モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。OperatorGroup
オブジェクト YAML ファイルを作成します (例:operatorgroup.yaml
)。OperatorGroup
オブジェクトのサンプルapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <namespace> spec: targetNamespaces: - <namespace>
警告Operator Lifecycle Manager (OLM) は、各 Operator グループに対して次のクラスターロールを作成します。
-
<operatorgroup_name>-admin
-
<operatorgroup_name>-edit
-
<operatorgroup_name>-view
Operator グループを手動で作成する場合は、既存のクラスターロールまたはクラスター上の他のOperator グループと競合しない一意の名前を指定する必要があります。
-
OperatorGroup
オブジェクトを作成します。$ oc apply -f operatorgroup.yaml
startingCSV
フィールドを設定し、特定バージョンの Operator に namespace をサブスクライブするSubscription
オブジェクト YAML ファイルを作成します。installPlanApproval
フィールドをManual
に設定し、Operator の新しいバージョンがカタログに存在する場合に Operator が自動的にアップグレードされないようにします。たとえば、以下の
sub.yaml
ファイルを使用して、バージョン 3.7.10 に固有の Red Hat Quay Operator をインストールすることができます。最初にインストールする特定の Operator バージョンのあるサブスクリプション
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay spec: channel: stable-3.7 installPlanApproval: Manual 1 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: quay-operator.v3.7.10 2
Subscription
オブジェクトを作成します。$ oc apply -f sub.yaml
- 保留中のインストール計画を手動で承認し、Operator のインストールを完了します。
4.1.5. マルチテナントクラスター用の Operator の複数インスタンスの準備
クラスター管理者は、マルチテナントクラスターで使用する Operator の複数のインスタンスを追加できます。これは、最小特権の原則に違反していると見なされる標準の All namespaces インストールモード、または広く採用されていない Multinamespace モードのいずれかを使用する代替ソリューションです。詳細は、「マルチテナントクラスター内の Operator」を参照してください。
次の手順では、テナント は、デプロイされた一連のワークロードに対する共通のアクセス権と特権を共有するユーザーまたはユーザーのグループです。テナント Operator は、そのテナントのみによる使用を意図した Operator のインスタンスです。
前提条件
インストールする Operator のすべてのインスタンスは、特定のクラスター全体で同じバージョンである必要があります。
重要この制限およびその他の制限の詳細は、「マルチテナントクラスター内の Operator」を参照してください。
手順
Operator をインストールする前に、テナントの namespace とは別のテナント Operator の namespace を作成します。たとえば、テナントの namespace が
team1
の場合、team1-operator
namespace を作成できます。Namespace
リソースを定義し、YAML ファイル (例:team1-operator.yaml)
を保存します。apiVersion: v1 kind: Namespace metadata: name: team1-operator
以下のコマンドを実行して namespace を作成します。
$ oc create -f team1-operator.yaml
spec.targetNamespaces
リストにその 1 つの namespace エントリーのみを使用して、テナントの namespace をスコープとするテナント Operator の Operator グループを作成します。OperatorGroup
リソースを定義し、YAML ファイル (例:team1-operatorgroup.yaml)
を保存します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: team1-operatorgroup namespace: team1-operator spec: targetNamespaces: - team1 1
- 1
spec.targetNamespaces
リストでテナントの namespace のみを定義します。
以下のコマンドを実行して Operator グループを作成します。
$ oc create -f team1-operatorgroup.yaml
次のステップ
テナント Operator namespace に Operator をインストールします。このタスクは、CLI の代わりに Web コンソールで OperatorHub を使用することにより、より簡単に実行できます。詳細な手順は、Web コンソールを使用した OperatorHub からのインストール を参照してください。
注記Operator のインストールが完了すると、Operator はテナントの Operator namespace に存在し、テナントの namespace を監視しますが、Operator の Pod もそのサービスアカウントも、テナントによって表示または使用されません。
4.1.6. カスタム namespace にグローバル Operator をインストールする
OpenShift Container Platform Web コンソールを使用して Operator をインストールする場合、デフォルトの動作により、All namespaces インストールモードをサポートする Operator がデフォルトの openshift-operators
グローバル namespace にインストールされます。これにより、namespace 内のすべての Operator 間で共有インストールプランと更新ポリシーに関連する問題が発生する可能性があります。これらの制限の詳細は、「マルチテナント対応と Operator のコロケーション」を参照してください。
クラスター管理者は、カスタムグローバル namespace を作成し、その namespace を使用して、個々のまたは範囲指定された一連の Operator とその依存関係をインストールすることにより、このデフォルトの動作を手動でバイパスできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
Operator をインストールする前に、目的の Operator をインストールするための namespace を作成します。このインストール namespace は、カスタムグローバル namespace になります。
Namespace
リソースを定義し、YAML ファイル (例:global-operators.yaml
) を保存します。apiVersion: v1 kind: Namespace metadata: name: global-operators
以下のコマンドを実行して namespace を作成します。
$ oc create -f global-operators.yaml
すべての namespace を監視する Operator グループである、カスタム global Operator group を作成します。
OperatorGroup
リソースを定義し、global-operatorgroup.yaml
などの YAML ファイルを保存します。spec.selector
フィールドとspec.targetNamespaces
フィールドの両方を省略して、すべての namespace を選択する global Operator group にします。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
注記作成されたグローバル Operator グループの
status.namespaces
には、空の文字列 (""
) が含まれています。これは、すべての namespace を監視する必要があることを消費する Operator に通知します。以下のコマンドを実行して Operator グループを作成します。
$ oc create -f global-operatorgroup.yaml
次のステップ
必要な Operator をカスタムグローバル namespace にインストールします。Web コンソールは、Operator のインストール時にカスタムグローバル namespace で Installed Namespace メニューを設定しないため、このタスクは OpenShift CLI (
oc
) でのみ実行できます。詳細な手順は、CLI を使用した OperatorHub からのインストール を参照してください。注記Operator のインストールを開始すると、Operator に依存関係がある場合、その依存関係もカスタムグローバル namespace に自動的にインストールされます。その結果、依存関係 Operator が同じ更新ポリシーと共有インストールプランを持つことが有効になります。
4.1.7. Operator ワークロードの Pod の配置
デフォルトで、Operator Lifecycle Manager (OLM) は、Operator のインストールまたはオペランドのワークロードのデプロイ時に Pod を任意のワーカーノードに配置します。管理者は、ノードセレクター、taint、および toleration の組み合わせを持つプロジェクトを使用して、Operator およびオペランドの特定のノードへの配置を制御できます。
Operator およびオペランドワークロードの Pod 配置の制御には以下の前提条件があります。
-
要件に応じて Pod のターゲットとするノードまたはノードのセットを判別します。利用可能な場合は、単数または複数のノードを特定する
node-role.kubernetes.io/app
などの既存ラベルをメモします。それ以外の場合は、コンピュートマシンセットを使用するか、ノードを直接編集して、myoperator
などのラベルを追加します。このラベルは、後のステップでプロジェクトのノードセレクターとして使用します。 -
関連しないワークロードを他のノードに向けつつ、特定のラベルの付いた Pod のみがノードで実行されるようにする必要がある場合、コンピュートマシンセットを使用するか、ノードを直接編集して taint をノードに追加します。taint に一致しない新規 Pod がノードにスケジュールされないようにする effect を使用します。たとえば、
myoperator:NoSchedule
taint は、taint に一致しない新規 Pod がノードにスケジュールされないようにしますが、ノードの既存 Pod はそのまま残ります。 - デフォルトのノードセレクターで設定され、taint を追加している場合に一致する toleration を持つプロジェクトを作成します。
この時点で、作成したプロジェクトでは、以下のシナリオの場合に指定されたノードに Pod を導くことができます。
- Operator Pod の場合
-
管理者は、次のセクションで説明するように、プロジェクトに
Subscription
オブジェクトを作成できます。その結果、Operator Pod は指定されたノードに配置されます。 - オペランド Pod の場合
- インストールされた Operator を使用して、ユーザーはプロジェクトにアプリケーションを作成できます。これにより、Operator が所有するカスタムリソース (CR) がプロジェクトに置かれます。その結果、Operator が他の namespace にクラスター全体のオブジェクトまたはリソースをデプロイしない限り、オペランド Pod は指定されたノードに配置されます。この場合、このカスタマイズされた Pod の配置は適用されません。
関連情報
- ノードに手動で、または コンピュートマシンセットを使用 して taint と toleration を追加する
- プロジェクトスコープのノードセレクターの作成
- ノードセレクターおよび toleration を使用したプロジェクトの作成
4.1.8. Operator のインストール場所の制御
デフォルトでは、Operator をインストールすると、OpenShift Container Platform は Operator Pod をワーカーノードの 1 つにランダムにインストールします。ただし、特定のノードまたはノードのセットでその Pod をスケジュールする必要がある場合があります。
以下の例では、Operator Pod を特定のノードまたはノードのセットにスケジュールする状況を説明します。
-
Operator が
amd64
やarm64
などの特定のプラットフォームを必要とする場合 - オペレータが Linux や Windows などの特定のオペレーティングシステムを必要とする場合
- 同じホストまたは同じラックに配置されたホストでスケジュールされた一緒に動作する Operator が必要な場合
- ネットワークまたはハードウェアの問題によるダウンタイムを回避するために、Operator をインフラストラクチャー全体に分散させたい場合
Operator の Subscription
オブジェクトにノードアフィニティー、Pod アフィニティー、または Pod 非アフィニティー制約を追加することで、Operator Pod がインストールされる場所を制御できます。ノードアフィニティーは、Pod の配置場所を判別するためにスケジューラーによって使用されるルールのセットです。Pod アフィニティーを使用すると、関連する Pod が同じノードにスケジュールされていることを確認できます。Pod 非アフィニティーを使用すると、ノードで Pod がスケジュールされないようにすることができます。
次の例は、ノードアフィニティーまたは Pod 非アフィニティーを使用して、Custom Metrics Autoscaler Operator のインスタンスをクラスター内の特定のノードにインストールする方法を示しています。
Operator Pod を特定のノードに配置するノードアフィニティーの例
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
nodeAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- ip-10-0-163-94.us-west-2.compute.internal
#...
- 1
- Operator の Pod を
ip-10-0-163-94.us-west-2.compute.internal
という名前のノードでスケジュールする必要があるノードアフィニティー。
Operator Pod を特定のプラットフォームのノードに配置するノードアフィニティーの例
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
nodeAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
- key: kubernetes.io/os
operator: In
values:
- linux
#...
- 1
- Operator の Pod を
kubernetes.io/arch=arm64
およびkubernetes.io/os=linux
ラベルを持つノードでスケジュールする必要があるノードアフィニティー。
Operator Pod を 1 つ以上の特定のノードに配置する Pod アフィニティーの例
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
podAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- test
topologyKey: kubernetes.io/hostname
#...
- 1
app=test
ラベルを持つ Pod を持つノードに Operator の Pod を配置する Pod アフィニティー。
Operator Pod が 1 つ以上の特定のノードからアクセスできないようにする Pod 非アフィニティーの例
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: openshift-custom-metrics-autoscaler-operator
namespace: openshift-keda
spec:
name: my-package
source: my-operators
sourceNamespace: operator-registries
config:
affinity:
podAntiAffinity: 1
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: cpu
operator: In
values:
- high
topologyKey: kubernetes.io/hostname
#...
- 1
- Operator の Pod が
cpu=high
ラベルの Pod を持つノードでスケジュールされないようにする Pod 非アフィニティー。
手順
Operator Pod の配置を制御するには、次の手順を実行します。
- 通常どおり Operator をインストールします。
- 必要に応じて、ノードがアフィニティーに適切に応答するようにラベル付けされていることを確認してください。
Operator
Subscription
オブジェクトを編集してアフィニティーを追加します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-custom-metrics-autoscaler-operator namespace: openshift-keda spec: name: my-package source: my-operators sourceNamespace: operator-registries config: affinity: 1 nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-185-229.ec2.internal #...
- 1
nodeAffinity
、podAffinity
、またはpodAntiAffinity
を追加します。アフィニティーの作成については、以下のその他のリソースセクションを参照してください。
検証
Pod が特定のノードにデプロイされていることを確認するには、次のコマンドを実行します。
$ oc get pods -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>