第4章 管理者タスク

手順

1. Web コンソールで、Operators OperatorHub ページに移動します。

2. スクロールするか、キーワードを Filter by keyword ボックスに入力し、必要な Operator を見つけます。たとえば、Advanced Cluster Management for Kubernetes Operator を検索するには advanced を入力します。

   また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。

3. Operator を選択して、追加情報を表示します。

   注記

   コミュニティー Operator を選択すると、Red Hat がコミュニティー Operator を認定していないことを警告します。続行する前に警告を確認する必要があります。

4. Operator の情報を確認してから、Install をクリックします。

5. Install Operator ページで、Operator のインストールを設定します。

   1. 特定のバージョンの Operator をインストールする場合は、リストから Update channel と Version を選択します。Operator のすべてのチャネルから Operator のさまざまなバージョンを参照し、そのチャネルとバージョンのメタデータを表示して、インストールする正確なバージョンを選択できます。

      注記

      バージョン選択のデフォルトは、選択したチャネルの最新バージョンです。チャネルの最新バージョンが選択されている場合は、自動 承認戦略がデフォルトで有効になります。それ以外の場合、選択したチャネルの最新バージョンをインストールしない場合は、手動 による承認が必要です。

      手動 承認を使用して Operator をインストールすると、namespace 内にインストールされたすべての Operator が 手動 承認戦略で機能し、すべての Operator が一緒に更新されます。Operator を個別に更新する場合は、Operator を別の namespace にインストールします。

   2. Operator のインストールモードを確認します。

      • All namespaces on the cluster (default) は、デフォルトの openshift-operators namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。このオプションは常に選択可能です。
      • A specific namespace on the cluster では、Operator をインストールする特定の単一 namespace を選択できます。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。

   3. トークン認証が有効になっているクラウドプロバイダー上のクラスターの場合:

      • クラスターで AWS Security Token Service (Web コンソールの STS Mode) を使用する場合は、role ARN フィールドに、サービスアカウントの AWS IAM ロールの Amazon Resource Name (ARN) を入力します。ロールの ARN を作成するには、AWS アカウントの準備 で説明されている手順に従います。
      • クラスターで Microsoft Entra Workload ID (Web コンソールの Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、クライアント ID、テナント ID、サブスクリプション ID を追加します。
      • クラスターで Google Cloud Platform Workload Identity (Web コンソールの GCP Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、プロジェクト番号、プール ID、プロバイダー ID、サービスアカウントのメールアドレスを追加します。

   4. Update approval で、承認ストラテジー Automatic または Manual を選択します。

      重要

      Web コンソールに、クラスターが AWS STS、Microsoft Entra Workload ID、または GCP Workload Identity を使用していることが示されている場合は、Update approval を Manual に設定する必要があります。

      更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。

6. Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。

   1. 手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、そのインストール計画を確認し、承認するまで Upgrading のままになります。

      Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。

   2. 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。

手順

1. OperatorHub からクラスターで利用できる Operator のリストを表示します。

   $ oc get packagemanifests -n openshift-marketplace

   例4.1 出力例

   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 のカタログをメモします。

2. 必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。

   $ oc describe packagemanifests <operator_name> -n openshift-marketplace

   例4.2 出力例

   # ...
   Kind:         PackageManifest
   # ...
         Install Modes: 1
           Supported:  true
           Type:       OwnNamespace
           Supported:  true
           Type:       SingleNamespace
           Supported:  false
           Type:       MultiNamespace
           Supported:  true
           Type:       AllNamespaces
   # ...
       Entries:
         Name:       example-operator.v3.7.11
         Version:    3.7.11
         Name:       example-operator.v3.7.10
         Version:    3.7.10
       Name:         stable-3.7 2
   # ...
      Entries:
         Name:         example-operator.v3.8.5
         Version:      3.8.5
         Name:         example-operator.v3.8.4
         Version:      3.8.4
       Name:           stable-3.8 3
     Default Channel:  stable-3.8 4

   1 1

   サポートされているインストールモードを示します。

   2 2 3

   チャネル名の例。

   4

   指定されていない場合にデフォルトで選択されるチャネル。

   ヒント

   次のコマンドを実行すると、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 が含まれています。

3. インストールする Operator が AllNamespaces インストールモードをサポートしており、このモードを使用することを選択した場合は、openshift-operators namespace に global-operators と呼ばれる適切な Operator グループがデフォルトですでに配置されているため、この手順をスキップしてください。

   インストールする Operator が SingleNamespace インストールモードをサポートしており、このモードを使用することを選択した場合は、関連する namespace に適切な Operator グループが存在することを確認する必要があります。存在しない場合は、次の手順に従って作成できます。

   重要

   namespace ごとに Operator グループを 1 つだけ持つことができます。詳細は、「Operator グループ」を参照してください。

   1. SingleNamespace インストールモード用に、OperatorGroup オブジェクト YAML ファイル (例: operatorgroup.yaml) を作成します。

      SingleNamespace インストールモードの OperatorGroup オブジェクトの例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace> 1
      spec:
        targetNamespaces:
        - <namespace> 2

      1 2

      SingleNamespace インストールモードの場合は、metadata.namespace フィールドと spec.targetNamespaces フィールドの両方に同じ <namespace> 値を使用します。

   2. OperatorGroup オブジェクトを作成します。

      $ oc apply -f operatorgroup.yaml

4. namespace を Operator にサブスクライブするための Subscription オブジェクトを作成します。

   1. Subscription オブジェクトの YAML ファイル (例: subscription.yaml) を作成します。

      注記

      特定のバージョンの Operator をサブスクライブする場合は、startingCSV フィールドを目的のバージョンに設定し、installPlanApproval フィールドを Manual に設定して、カタログに新しいバージョンが存在する場合に Operator が自動的にアップグレードされないようにします。詳細は、次の「特定の開始 Operator バージョンを持つ Subscription オブジェクトの例」を参照してください。

      例4.3 Subscription オブジェクトの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: <subscription_name>
        namespace: <namespace_per_install_mode> 1
      spec:
        channel: <channel_name> 2
        name: <operator_name> 3
        source: <catalog_name> 4
        sourceNamespace: <catalog_source_namespace> 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 の NodeSelector を定義します。

      例4.4 特定の開始 Operator バージョンを持つ Subscription オブジェクトの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: example-operator
        namespace: example-operator
      spec:
        channel: stable-3.7
        installPlanApproval: Manual 1
        name: example-operator
        source: custom-operators
        sourceNamespace: openshift-marketplace
        startingCSV: example-operator.v3.7.10 2

      1

      指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。

      2

      Operator CSV の特定バージョンを設定します。

   2. Amazon Web Services (AWS) Security Token Service (STS)、Microsoft Entra Workload ID、Google Cloud Platform Workload Identity など、トークン認証が有効なクラウドプロバイダー上のクラスターの場合は、次の手順に従って Subscription オブジェクトを設定します。

      1. Subscription オブジェクトが手動更新承認に設定されていることを確認します。

         例4.5 更新の手動承認を使用した Subscription オブジェクトの例

         kind: Subscription
         # ...
         spec:
           installPlanApproval: Manual 1

         1

         更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。

      2. 関連するクラウドプロバイダー固有のフィールドを Subscription オブジェクトの config セクションに含めます。

         • クラスターが AWS STS モードの場合は、次のフィールドを含めます。

           例4.6 AWS STS の変数を使用した Subscription オブジェクトの例

           kind: Subscription
           # ...
           spec:
             config:
               env:
               - name: ROLEARN
                 value: "<role_arn>" 1

           1

           ロール ARN の詳細を含めます。

         • クラスターが Workload ID モードの場合は、次のフィールドを含めます。

           例4.7 Workload ID の変数を使用した Subscription オブジェクトの例

           kind: Subscription
           # ...
           spec:
            config:
              env:
              - name: CLIENTID
                value: "<client_id>" 1
              - name: TENANTID
                value: "<tenant_id>" 2
              - name: SUBSCRIPTIONID
                value: "<subscription_id>" 3

           1

           クライアント ID を含めます。

           2

           テナント ID を含めます。

           3

           サブスクリプション ID を含めます。

         • クラスターが GCP Workload Identity モードの場合は、次のフィールドを含めます。

           例4.8 GCP Workload Identity の変数を使用した Subscription オブジェクトの例

           kind: Subscription
           # ...
           spec:
            config:
              env:
              - name: AUDIENCE
                value: "<audience_url>" 1
              - name: SERVICE_ACCOUNT_EMAIL
                value: "<service_account_email>" 2

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

           <audience>

           AUDIENCE 値は、管理者が GCP Workload Identity を設定するときに GCP で作成し、次の形式で事前にフォーマットした URL である必要があります。

           //iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>

           <service_account_email>

           SERVICE_ACCOUNT_EMAIL 値は、Operator 操作中に権限を借用する GCP サービスアカウントのメールアドレスです。次に例を示します。

           <service_account_name>@<project_id>.iam.gserviceaccount.com

   3. 以下のコマンドを実行して Subscription オブジェクトを作成します。

      $ oc apply -f subscription.yaml

5. installPlanApproval フィールドを Manual に設定する場合は、保留中のインストールプランを手動で承認して Operator のインストールを完了します。詳細は、「保留中の Operator 更新の手動による承認」を参照してください。

検証

1. 次のコマンドを実行して、インストールされている Operator の Subscription オブジェクトのステータスを確認します。

   $ oc describe subscription <subscription_name> -n <namespace>

2. SingleNamespace インストールモードの Operator グループを作成した場合は、次のコマンドを実行して OperatorGroup オブジェクトのステータスを確認します。

   $ oc describe operatorgroup <operatorgroup_name> -n <namespace>

手順

1. Operator をインストールする前に、テナントの namespace とは別のテナント Operator の namespace を作成します。たとえば、テナントの namespace が team1 の場合、team1-operator namespace を作成できます。

   1. Namespace リソースを定義し、YAML ファイル (例: team1-operator.yaml) を保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: team1-operator

   2. 以下のコマンドを実行して namespace を作成します。

      $ oc create -f team1-operator.yaml

2. spec.targetNamespaces リストにその 1 つの namespace エントリーのみを使用して、テナントの namespace をスコープとするテナント Operator の Operator グループを作成します。

   1. OperatorGroup リソースを定義し、YAML ファイル (例: team1-operatorgroup.yaml) を保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: team1-operatorgroup
        namespace: team1-operator
      spec:
        targetNamespaces:
        - team1 1

      1 1

      spec.targetNamespaces リストでテナントの namespace のみを定義します。

   2. 以下のコマンドを実行して Operator グループを作成します。

      $ oc create -f team1-operatorgroup.yaml

手順

1. Operator をインストールする前に、目的の Operator をインストールするための namespace を作成します。このインストール namespace は、カスタムグローバル namespace になります。

   1. Namespace リソースを定義し、YAML ファイル (例: global-operators.yaml) を保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: global-operators

   2. 以下のコマンドを実行して namespace を作成します。

      $ oc create -f global-operators.yaml

2. すべての namespace を監視する Operator グループである、カスタム global Operator group を作成します。

   1. 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 に通知します。

   2. 以下のコマンドを実行して Operator グループを作成します。

      $ oc create -f global-operatorgroup.yaml

1. 要件に応じて Pod のターゲットとするノードまたはノードのセットを判別します。利用可能な場合は、単数または複数のノードを特定する node-role.kubernetes.io/app などの既存ラベルをメモします。それ以外の場合は、コンピュートマシンセットを使用するか、ノードを直接編集して、myoperator などのラベルを追加します。このラベルは、後のステップでプロジェクトのノードセレクターとして使用します。
2. 関連しないワークロードを他のノードに向けつつ、特定のラベルの付いた Pod のみがノードで実行されるようにする必要がある場合、コンピュートマシンセットを使用するか、ノードを直接編集して taint をノードに追加します。taint に一致しない新規 Pod がノードにスケジュールされないようにする effect を使用します。たとえば、myoperator:NoSchedule taint は、taint に一致しない新規 Pod がノードにスケジュールされないようにしますが、ノードの既存 Pod はそのまま残ります。
3. デフォルトのノードセレクターで設定され、taint を追加している場合に一致する toleration を持つプロジェクトを作成します。

1. 通常どおり Operator をインストールします。
2. 必要に応じて、ノードがアフィニティーに適切に応答するようにラベル付けされていることを確認してください。

3. 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 を追加します。アフィニティーの作成は、以下のその他のリソースセクションを参照してください。