Operator

手順

1. この手順を実行するために OpenShift Container Platform Web コンソールで新規プロジェクトを作成します。この例では、my-etcd というプロジェクトを使用します。

2. Operators → Installed Operators ページに移動します。クラスター管理者によってクラスターにインストールされ、使用可能にされた Operator がクラスターサービスバージョン (CSV) の一覧としてここに表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。

   ヒント

   以下を使用して、CLI でこの一覧を取得できます。

   $ oc get csv

3. Installed Operators ページで、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。

   Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (EtcdCluster リソース) のタイプが含まれます。これらのオブジェクトは、Deployment または ReplicaSet などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。

4. 新規 etcd クラスターを作成します。

   1. etcd Cluster API ボックスで、Create instance をクリックします。
   2. 次の画面では、クラスターのサイズなど EtcdCluster オブジェクトのテンプレートを起動する最小条件への変更を加えることができます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。

5. example etcd クラスターをクリックしてから Resources タブをクリックして、プロジェクトに Operator によって自動的に作成され、設定された数多くのリソースが含まれることを確認します。

   Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。

6. 所定プロジェクトで edit ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。

   $ oc policy add-role-to-user edit <user> -n <target_project>

手順

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 ページで以下を行います。

   1. Operator をインストールする特定の単一 namespace を選択します。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
   2. Update Channel を選択します (複数を選択できる場合)。
   3. 前述のように、自動 (Automatic) または 手動 (Manual) の承認ストラテジーを選択します。

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

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

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

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

7. サブスクリプションのアップグレードステータスが Up to date になった後に、Operators → Installed Operators を選択し、インストールされた Operator のクラスターサービスバージョン (CSV) が表示されることを確認します。その Status は最終的に関連する namespace で InstallSucceeded に解決するはずです。

   注記

   All namespaces…​ インストールモードの場合、ステータスは openshift-operators namespace で InstallSucceeded になりますが、他の namespace でチェックする場合、ステータスは Copied になります。

   上記通りにならない場合、以下を実行します。

   1. さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、openshift-operators プロジェクト (または A specific namespace…​ インストールモードが選択されている場合は他の関連の namespace) の Pod のログを確認します。

手順

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

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

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

3. OperatorGroup で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。

   Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (AllNamespaces または SingleNamespace モードのいずれか)。インストールする Operator が AllNamespaces を使用する場合、 openshift-operators namespace には適切な Operator グループがすでに配置されます。

   ただし、Operator が SingleNamespace モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。

   注記

   この手順の Web コンソールバージョンでは、SingleNamespace モードを選択する際に、OperatorGroup および Subscription オブジェクトの作成を背後で自動的に処理します。

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

      OperatorGroup オブジェクトのサンプル

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

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

      $ oc apply -f operatorgroup.yaml

4. 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 を指定します。それ以外の場合は、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 の容認の一覧を定義します。

   11

   resources パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。

   12

   nodeSelector パラメーターは、OLM によって作成される Pod の ノードセレクター を定義します。

5. Subscription オブジェクトを作成します。

   $ oc apply -f sub.yaml

   この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

手順

1. startingCSV フィールドを設定し、特定バージョンの Operator に namespace をサブスクライブする Subscription オブジェクト YAML ファイルを作成します。installPlanApproval フィールドを Manual に設定し、Operator の新しいバージョンがカタログに存在する場合に Operator が自動的にアップグレードされないようにします。

   たとえば、以下の sub.yaml ファイルを使用して、バージョン 3.4.0 に固有の Red Hat Quay Operator をインストールすることができます。

   最初にインストールする特定の Operator バージョンのあるサブスクリプション

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

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

   2

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

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

   $ oc apply -f sub.yaml

3. 保留中のインストール計画を手動で承認し、Operator のインストールを完了します。

手順

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 ページで以下を行います。

   1. 以下のいずれかを選択します。

      • All namespaces on the cluster (default) は、デフォルトの openshift-operators namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。このオプションは常に選択可能です。
      • A specific namespace on the cluster では、Operator をインストールする特定の単一 namespace を選択できます。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
   2. Operator をインストールする特定の単一 namespace を選択します。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
   3. Update Channel を選択します (複数を選択できる場合)。
   4. 前述のように、自動 (Automatic) または 手動 (Manual) の承認ストラテジーを選択します。

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

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

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

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

7. サブスクリプションのアップグレードステータスが Up to date になった後に、Operators → Installed Operators を選択し、インストールされた Operator のクラスターサービスバージョン (CSV) が表示されることを確認します。その Status は最終的に関連する namespace で InstallSucceeded に解決するはずです。

   注記

   All namespaces…​ インストールモードの場合、ステータスは openshift-operators namespace で InstallSucceeded になりますが、他の namespace でチェックする場合、ステータスは Copied になります。

   上記通りにならない場合、以下を実行します。

   1. さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、openshift-operators プロジェクト (または A specific namespace…​ インストールモードが選択されている場合は他の関連の namespace) の Pod のログを確認します。

手順

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

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

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

3. OperatorGroup で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。

   Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (AllNamespaces または SingleNamespace モードのいずれか)。インストールする Operator が AllNamespaces を使用する場合、 openshift-operators namespace には適切な Operator グループがすでに配置されます。

   ただし、Operator が SingleNamespace モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。

   注記

   この手順の Web コンソールバージョンでは、SingleNamespace モードを選択する際に、OperatorGroup および Subscription オブジェクトの作成を背後で自動的に処理します。

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

      OperatorGroup オブジェクトのサンプル

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

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

      $ oc apply -f operatorgroup.yaml

4. 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 を指定します。それ以外の場合は、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 の容認の一覧を定義します。

   11

   resources パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。

   12

   nodeSelector パラメーターは、OLM によって作成される Pod の ノードセレクター を定義します。

5. Subscription オブジェクトを作成します。

   $ oc apply -f sub.yaml

   この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

手順

1. startingCSV フィールドを設定し、特定バージョンの Operator に namespace をサブスクライブする Subscription オブジェクト YAML ファイルを作成します。installPlanApproval フィールドを Manual に設定し、Operator の新しいバージョンがカタログに存在する場合に Operator が自動的にアップグレードされないようにします。

   たとえば、以下の sub.yaml ファイルを使用して、バージョン 3.4.0 に固有の Red Hat Quay Operator をインストールすることができます。

   最初にインストールする特定の Operator バージョンのあるサブスクリプション

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

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

   2

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

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

   $ oc apply -f sub.yaml

3. 保留中のインストール計画を手動で承認し、Operator のインストールを完了します。

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

手順

1. Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
2. 更新チャネルを変更する Operator の名前をクリックします。
3. Subscription タブをクリックします。
4. Channel の下にある更新チャネルの名前をクリックします。
5. 変更する新しい更新チャネルをクリックし、Save をクリックします。

6. Automatic 承認ストラテジーのあるサブスクリプションの場合、更新は自動的に開始します。Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。

   Manual 承認ストラテジーのあるサブスクリプションの場合、Subscription タブから更新を手動で承認できます。

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
2. 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
3. Subscription タブをクリックします。承認が必要な更新は、アップグレードステータス の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
5. 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
6. Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。

手順

1. Operators → Installed Operators ページからスクロールするか、または Filter by name にキーワードを入力して必要な Operator を見つけます。次に、それをクリックします。

2. Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。

   Uninstall Operator? ダイアログボックスが表示され、以下が通知されます。

   Operator を削除しても、そのカスタムリソース定義や管理リソースは削除されません。Operator がクラスターにアプリケーションをデプロイしているか、またはクラスター外のリソースを設定している場合、それらは引き続き実行され、手動でクリーンアップする必要があります。

   このアクションにより、Operator および Operator のデプロイメントおよび Pod が削除されます (ある場合)。CRD および CR を含む Operator によって管理される Operand およびリソースは削除されません。Web コンソールは、一部の Operator のダッシュボードおよびナビゲーションアイテムを有効にします。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

3. Uninstall を選択します。この Operator は実行を停止し、更新を受信しなくなります。

手順

1. サブスクライブされた Operator (例: jaeger) の現行バージョンを currentCSV フィールドで確認します。

   $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

   出力例

     currentCSV: jaeger-operator.v1.8.2

2. サブスクリプション (例: jaeger) を削除します。

   $ oc delete subscription jaeger -n openshift-operators

   出力例

   subscription.operators.coreos.com "jaeger" deleted

3. 直前の手順で currentCSV 値を使用し、ターゲット namespace の Operator の CSV を削除します。

   $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

   出力例

   clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

手順

1. Operator がインストールされている namespace から Subscription および ClusterServiceVersion オブジェクトの名前を取得します。

   $ oc get sub,csv -n <namespace>

   出力例

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. サブスクリプションを削除します。

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

3. クラスターサービスバージョンを削除します。

   $ oc delete csv <csv_name> -n <namespace>

4. openshift-marketplace namespace の失敗したジョブおよび関連する設定マップの名前を取得します。

   $ oc get job,configmap -n openshift-marketplace

   出力例

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. ジョブを削除します。

   $ oc delete job <job_name> -n openshift-marketplace

   これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。

6. 設定マップを削除します。

   $ oc delete configmap <configmap_name> -n openshift-marketplace

7. Web コンソールの OperatorHub を使用した Operator の再インストール

手順

1. Web コンソールで、Operators → OperatorHub ページに移動します。
2. Operator を選択し、Install をクリックします。

3. Install Operator ページで、Subscription オブジェクトを変更して以下の 1 つ以上の環境変数を spec セクションに組み込みます。

   • HTTP_PROXY
   • HTTPS_PROXY
   • NO_PROXY

   以下に例を示します。

   プロキシー設定の上書きのある Subscription オブジェクト

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd-config-test
     namespace: openshift-operators
   spec:
     config:
       env:
       - name: HTTP_PROXY
         value: test_http
       - name: HTTPS_PROXY
         value: test_https
       - name: NO_PROXY
         value: test
     channel: clusterwide-alpha
     installPlanApproval: Automatic
     name: etcd
     source: community-operators
     sourceNamespace: openshift-marketplace
     startingCSV: etcdoperator.v0.9.4-clusterwide

   注記

   これらの環境変数については、以前に設定されたクラスター全体またはカスタムプロキシーの設定を削除するために空の値を使用してそれらの設定を解除することもできます。

   OLM はこれらの環境変数を単位として処理します。それらの環境変数が 1 つ以上設定されている場合、それらはすべて上書きされているものと見なされ、クラスター全体のデフォルト値はサブスクライブされた Operator のデプロイメントには使用されません。

4. Install をクリックし、Operator を選択された namespace で利用可能にします。

5. Operator の CSV が関連する namespace に表示されると、カスタムプロキシーの環境変数がデプロイメントに設定されていることを確認できます。たとえば、CLI を使用します。

   $ oc get deployment -n openshift-operators \
       etcd-operator -o yaml \
       | grep -i "PROXY" -A 2

   出力例

           - name: HTTP_PROXY
             value: test_http
           - name: HTTPS_PROXY
             value: test_https
           - name: NO_PROXY
             value: test
           image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c
   ...

手順

1. Operator のサブスクリプションがある namespace に空の設定マップを作成し、以下のラベルを組み込みます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: trusted-ca 1
     labels:
       config.openshift.io/inject-trusted-cabundle: "true" 2

   1

   設定マップの名前。

   2

   Cluster Network Operator に対してマージされたバンドルを挿入するように要求します。

   この設定マップの作成後すぐに、設定マップにはマージされたバンドルの証明書の内容が設定されます。

2. Subscription オブジェクトを更新し、trusted-ca 設定マップをカスタム CA を必要とする Pod 内の各コンテナーにボリュームとしてマウントする spec.config セクションを追加します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: my-operator
   spec:
     package: etcd
     channel: alpha
     config: 1
       selector:
         matchLabels:
           <labels_for_pods> 2
       volumes: 3
       - name: trusted-ca
         configMap:
           name: trusted-ca
           items:
             - key: ca-bundle.crt 4
               path: tls-ca-bundle.pem 5
       volumeMounts: 6
       - name: trusted-ca
         mountPath: /etc/pki/ca-trust/extracted/pem
         readOnly: true

   1

   config セクションがない場合に、これを追加します。

   2

   Operator が所有する Pod に一致するラベルを指定します。

   3

   trusted-ca ボリュームを作成します。

   4

   ca-bundle.crt は設定マップキーとして必要になります。

   5

   tls-ca-bundle.pem は設定マップパスとして必要になります。

   6

   trusted-ca ボリュームマウントを作成します。

手順

1. Operator サブスクリプションを一覧表示します。

   $ oc get subs -n <operator_namespace>

2. oc describe コマンドを使用して、Subscription リソースを検査します。

   $ oc describe sub <subscription_name> -n <operator_namespace>

3. コマンド出力で、Conditions セクションで Operator サブスクリプションの状態タイプのステータスを確認します。以下の例では、利用可能なすべてのカタログソースが正常であるため、CatalogSourcesUnhealthy 状態タイプのステータスは false になります。

   出力例

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

手順

1. namespace のカタログソースを一覧表示します。例えば、クラスター全体のカタログソースに使用されている openshift-marketplacenamespace を確認することができます。

   $ oc get catalogsources -n openshift-marketplace

   出力例

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

2. カタログソースの詳細やステータスを確認するには、oc describe コマンドを使用します。

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   出力例

   Name:         example-catalog
   Namespace:    openshift-marketplace
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   前述の出力例では、最後に観測された状態が TRANSIENT_FAILURE となっています。この状態は、カタログソースの接続確立に問題があることを示しています。

3. カタログソースが作成された namespace の Pod をリストアップします。

   $ oc get pods -n openshift-marketplace

   出力例

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

   namespace にカタログソースを作成すると、その namespace にカタログソース用の Pod が作成されます。前述の出力例では、example-catalog-bwt8z Pod のステータスが ImagePullBackOff になっています。このステータスは、カタログソースのインデックスイメージのプルに問題があることを示しています。

4. oc describe コマンドを使用して、より詳細な情報を得るために Pod を検査します。

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   出力例

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   前述の出力例では、エラーメッセージは、カタログソースのインデックスイメージが承認問題のために正常にプルできないことを示しています。例えば、インデックスイメージがログイン認証情報を必要とするレジストリーに保存されている場合があります。

手順

1. Operator のOperatorConditionオブジェクトを編集します。

   $ oc edit operatorcondition <name>

2. Spec.Overrides 配列をオブジェクトに追加します。

   Operator 条件の上書きの例

   apiVersion: operators.coreos.com/v1
   kind: OperatorCondition
   metadata:
     name: my-operator
     namespace: operators
   spec:
     overrides:
     - type: Upgradeable 1
       status: "True"
       reason: "upgradeIsSafe"
       message: "This is a known issue with the Operator where it always reports that it cannot be upgraded."
     conditions:
     - type: Upgradeable
       status: "False"
       reason: "migration"
       message: "The operator is performing a migration."
       lastTransitionTime: "2020-08-24T23:15:55Z"

   1

   クラスター管理者は、アップグレードの準備状態を True に変更できます。

手順

1. 新規の namespace を作成します。

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: scoped
   EOF

2. Operator を制限する必要のあるパーミッションを割り当てます。これには、新規サービスアカウント、関連するロール、およびロールバインディングの作成が必要になります。

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: scoped
     namespace: scoped
   EOF

   以下の例では、単純化するために、サービスアカウントに対し、指定される namespace ですべてのことを実行できるパーミッションを付与します。実稼働環境では、より粒度の細かいパーミッションセットを作成する必要があります。

   $ cat <<EOF | oc create -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: scoped
     namespace: scoped
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: scoped-bindings
     namespace: scoped
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: scoped
   subjects:
   - kind: ServiceAccount
     name: scoped
     namespace: scoped
   EOF

3. 指定された namespace に OperatorGroup オブジェクトを作成します。この Operator グループは指定された namespace をターゲットにし、そのテナンシーがこれに制限されるようにします。

   さらに、Operator グループはユーザーがサービスアカウントを指定できるようにします。直前の手順で作成したサービスアカウントを指定します。

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: scoped
     namespace: scoped
   spec:
     serviceAccountName: scoped
     targetNamespaces:
     - scoped
   EOF

   指定された namespace にインストールされる Operator はこの Operator グループに関連付けられ、指定されるサービスアカウントに関連付けられます。

4. 指定された namespace で Subscription オブジェクトを作成し、Operator をインストールします。

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   spec:
     channel: singlenamespace-alpha
     name: etcd
     source: <catalog_source_name> 1
     sourceNamespace: <catalog_source_namespace> 2
   EOF

   1

   指定された namespace にすでにあるカタログソース、またはグローバルカタログ namespace にあるものを指定します。

   2

   カタログソースが作成された namespace を指定します。

   この Operator グループに関連付けられる Operator は、指定されたサービスアカウントに付与されるパーミッションに制限されます。Operator がサービスアカウントの範囲外のパーミッションを要求する場合、インストールは関連するエラーを出して失敗します。

1. デフォルトのグローバルカタログをすべて無効にします。
2. 関連する Operator グループがプリインストールされているのと同じ namespace で、キュレートされたカスタムカタログを有効にします。

手順

1. Subscription オブジェクトを確認します。このステータスには、Operator の必要な [Cluster]Role[Binding] オブジェクトの作成を試行した InstallPlan オブジェクトをポイントするオブジェクト参照 installPlanRef があります。

   apiVersion: operators.coreos.com/v1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   status:
     installPlanRef:
       apiVersion: operators.coreos.com/v1
       kind: InstallPlan
       name: install-4plp8
       namespace: scoped
       resourceVersion: "117359"
       uid: 2c1df80e-afea-11e9-bce3-5254009c9c23

2. InstallPlan オブジェクトのステータスでエラーの有無を確認します。

   apiVersion: operators.coreos.com/v1
   kind: InstallPlan
   status:
     conditions:
     - lastTransitionTime: "2019-07-26T21:13:10Z"
       lastUpdateTime: "2019-07-26T21:13:10Z"
       message: 'error creating clusterrole etcdoperator.v0.9.4-clusterwide-dsfx4: clusterroles.rbac.authorization.k8s.io
         is forbidden: User "system:serviceaccount:scoped:scoped" cannot create resource
         "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope'
       reason: InstallComponentFailed
       status: "False"
       type: Installed
     phase: Failed

   エラーメッセージは、以下を示しています。

   • リソースの API グループを含む、作成に失敗したリソースのタイプ。この場合、これは rbac.authorization.k8s.io グループの clusterroles です。
   • リソースの名前。
   • エラーのタイプ: is forbidden は、ユーザーに操作を実行するための十分なパーミッションがないことを示します。
   • リソースの作成または更新を試みたユーザーの名前。この場合、これは Operator グループで指定されたサービスアカウントを参照します。

   • 操作の範囲が cluster scope かどうか。

     ユーザーは、不足しているパーミッションをサービスアカウントに追加してから、繰り返すことができます。

     注記

     現時点で、Operator Lifecycle Manager (OLM) は最初の試行でエラーの詳細の一覧を提供しません。

手順

1. 新しいインデックスを開始します。

   $ opm index add \
       --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1
       --tag <registry>/<namespace>/<index_image_name>:<tag> \2
       [--binary-image <registry_base_image>] 3

   1

   インデックスに追加するバンドルイメージのコンマ区切りの一覧。

   2

   インデックスイメージで使用するイメージタグ。

   3

   オプション: カタログを提供するために使用する代替レジストリーベースイメージ。

2. インデックスイメージをレジストリーにプッシュします。

   1. 必要な場合は、ターゲットレジストリーで認証します。

      $ podman login <registry>

   2. インデックスイメージをプッシュします。

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

手順

1. インデックスイメージを参照する CatalogSource オブジェクトを作成します。

   1. 仕様を以下のように変更し、これを catalogSource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace 1
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.8 2
        displayName: My Operator Catalog
        publisher: <publisher_name> 3
        updateStrategy:
          registryPoll: 4
            interval: 30m

      1

      カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、openshift-marketplace namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。

      2

      インデックスイメージを指定します。

      3

      カタログを公開する名前または組織名を指定します。

      4

      カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。

   2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc apply -f catalogSource.yaml

2. 以下のリソースが正常に作成されていることを確認します。

   1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

手順

1. バンドルイメージを追加して、既存のインデックスを更新します。

   $ opm index add \
       --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
       --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
       --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
       --pull-tool podman 4

   1

   --bundlesフラグは、インデックスに追加する他のバンドルイメージのコンマ区切りリストを指定します。

   2

   --from-indexフラグは、以前にプッシュされたインデックスを指定します。

   3

   --tagフラグは、更新されたインデックスイメージに適用するイメージタグを指定します。

   4

   --pull-toolフラグは、コンテナーイメージのプルに使用されるツールを指定します。

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

   <registry>

   quay.ioやmirror.example.comなどのレジストリーのホスト名を指定します。

   <namespace>

   ocs-devやabcなど、レジストリーの namespace を指定します。

   <new_bundle_image>

   ocs-operatorなど、レジストリーに追加する新しいバンドルイメージを指定します。

   <digest>

   c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。

   <existing_index_image>

   abc-redhat-operator-indexなど、以前にプッシュされたイメージを指定します。

   <existing_tag>

   4.8 など、以前にプッシュされたイメージタグを指定します。

   <updated_tag>

   4.8.1 など、更新されたインデックスイメージに適用するイメージタグを指定します。

   コマンドの例

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.8 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.8.1 \
       --pull-tool podman

2. 更新されたインデックスイメージをプッシュします。

   $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

3. Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。

   $ oc get packagemanifests -n openshift-marketplace

手順

1. ターゲットレジストリーで認証します。

   $ podman login <target_registry>

2. プルーニングされたインデックスに追加するパッケージの一覧を判別します。

   1. コンテナーでプルーニングするソースインデックスイメージを実行します。以下に例を示します。

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.8

      出力例

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.8...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 別のターミナルセッションで、grpcurl コマンドを使用して、インデックスが提供するパッケージの一覧を取得します。

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. packages.out ファイルを検査し、プルーニングされたインデックスに保持したいパッケージ名をこの一覧から特定します。以下に例を示します。

      パッケージ一覧のスニペットの例

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. podman run コマンドを実行したターミナルセッションで、Ctrl と C を押してコンテナープロセスを停止します。

3. 以下のコマンドを実行して、指定したパッケージ以外のすべてのパッケージのソースインデックスをプルーニングします。

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.8 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.8] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8 4

   1

   プルーニングするインデックス。

   2

   保持するパッケージのコンマ区切りリスト。

   3

   IBM Power Systems および IBM Z イメージのみに必要です: ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用する Operator レジストリーのベースイメージです。

   4

   ビルドされる新規インデックスイメージのカスタムタグ。

4. 以下のコマンドを実行して、新規インデックスイメージをターゲットレジストリーにプッシュします。

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8

   ここで、<namespace> はレジストリー上の既存の namespace になります。

手順

1. 必要な各プライベートレジストリーのシークレットを作成します。

   1. プライベートレジストリーにログインして、レジストリー認証情報ファイルを作成または更新します。

      $ podman login <registry>:<port>

      注記

      レジストリー認証情報のファイルパスは、レジストリーへのログインに使用されるコンテナーツールによって異なります。podman CLI の場合、デフォルトの場所は ${XDG_RUNTIME_DIR}/containers/auth.json です。docker CLI の場合、デフォルトの場所は /root/.docker/config.json です。

   2. シークレットごとに 1 つのレジストリーに対してのみ認証情報を追加し、別のシークレットで複数のレジストリーの認証情報を管理することが推奨されます。これ以降の手順で、複数のシークレットを CatalogSource オブジェクトに含めることができ、OpenShift Container Platform はイメージのプル時に使用する単一の仮想認証情報ファイルにシークレットをマージします。

      レジストリー認証情報ファイルは、デフォルトで複数のレジストリーの詳細を保存することができます。ファイルの現在の内容を確認します。以下に例を示します。

      2 つのレジストリーの認証情報を保存するファイル

      {
              "auths": {
                      "registry.redhat.io": {
                              "auth": "FrNHNydQXdzclNqdg=="
                      },
                      "quay.io": {
                              "auth": "Xd2lhdsbnRib21iMQ=="
                      }
              }
      }

      これ以降の手順で、シークレットの作成にこのファイルが使用されるため、保存できる詳細は 1 つのファイルにつき 1 つのレジストリーのみであることを確認してください。これには、以下の方法の 1 つを使用します。

      • podman logout <registry> コマンドを使用して、必要な 1 つのレジストリーのみになるまで、追加のレジストリーの認証情報を削除します。

      • レジストリー認証情報ファイルを編集し、レジストリーの詳細を分離して、複数のファイルに保存します。以下に例を示します。

        1 つのレジストリーの認証情報を保存するファイル

        {
                "auths": {
                        "registry.redhat.io": {
                                "auth": "FrNHNydQXdzclNqdg=="
                        }
                }
        }

        別のレジストリーの認証情報を保存するファイル

        {
                "auths": {
                        "quay.io": {
                                "auth": "Xd2lhdsbnRib21iMQ=="
                        }
                }
        }

   3. プライベートレジストリーの認証情報が含まれるシークレットを openshift-marketplace namespace に作成します。

      $ oc create secret generic <secret_name> \
          -n openshift-marketplace \
          --from-file=.dockerconfigjson=<path/to/registry/credentials> \
          --type=kubernetes.io/dockerconfigjson

      この手順を繰り返して、他の必要なプライベートレジストリーの追加シークレットを作成し、--from-file フラグを更新して別のレジストリー認証情報ファイルのパスを指定します。

2. 1 つ以上のシークレットを参照するように既存の CatalogSource オブジェクトを作成または更新します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: my-operator-catalog
     namespace: openshift-marketplace
   spec:
     sourceType: grpc
     secrets: 1
     - "<secret_name_1>"
     - "<secret_name_2>"
     image: <registry>:<port>/<namespace>/<image>:<tag>
     displayName: My Operator Catalog
     publisher: <publisher_name>
     updateStrategy:
       registryPoll:
         interval: 30m

   1

   spec.secrets セクションを追加し、必要なシークレットを指定します。

3. サブスクライブされた Operator によって参照される Operator イメージまたはオペランドイメージにプライベートレジストリーへのアクセスが必要な場合は、クラスター内のすべての namespace または個々のターゲットテナント namespace のいずれかにアクセスを提供できます。

   • クラスター内のすべての namespace へアクセスを提供するには、認証情報を openshift-config namespace のグローバルクラスタープルシークレットに追加します。

     警告

     クラスターリソースは新規のグローバルプルシークレットに合わせて調整する必要がありますが、これにより、クラスターのユーザービリティーが一時的に制限される可能性があります。

     1. グローバルプルシークレットから .dockerconfigjson ファイルを展開します。

        $ oc extract secret/pull-secret -n openshift-config --confirm

     2. .dockerconfigjson ファイルを、必要なプライベートレジストリーまたはレジストリーの認証情報で更新し、これを新規ファイルとして保存します。

        $ cat .dockerconfigjson | \
            jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1
            > new_dockerconfigjson

        1

        <registry>:<port>/<namespace> をプライベートレジストリーの詳細に置き換え、<token> を認証情報に置き換えます。

     3. 新規ファイルでグローバルプルシークレットを更新します。

        $ oc set data secret/pull-secret -n openshift-config \
            --from-file=.dockerconfigjson=new_dockerconfigjson

   • 個別の namespace を更新するには、ターゲットテナント namespace でアクセスが必要な Operator のサービスアカウントにプルシークレットを追加します。

     1. テナント namespace で openshift-marketplace 用に作成したシークレットを再作成します。

        $ oc create secret generic <secret_name> \
            -n <tenant_namespace> \
            --from-file=.dockerconfigjson=<path/to/registry/credentials> \
            --type=kubernetes.io/dockerconfigjson

     2. テナント namespace を検索して、Operator のサービスアカウントの名前を確認します。

        $ oc get sa -n <tenant_namespace> 1

        1

        Operator が個別の namespace にインストールされていた場合、その namespace を検索します。Operator がすべての namespace にインストールされていた場合、openshift-operators namespace を検索します。

        出力例

        NAME            SECRETS   AGE
        builder         2         6m1s
        default         2         6m1s
        deployer        2         6m1s
        etcd-operator   2         5m18s 1

        1

        インストールされた etcd Operator のサービスアカウント。

     3. シークレットを Operator のサービスアカウントにリンクします。

        $ oc secrets link <operator_sa> \
            -n <tenant_namespace> \
             <secret_name> \
            --for=pull

手順

1. Web コンソールの Administrator パースペクティブで、Administration → Cluster Settings に移動します。
2. Global Configuration タブをクリックしてから、OperatorHub をクリックします。
3. Sources タブをクリックします。
4. 削除するカタログの Options メニュー を選択し、Delete CatalogSource をクリックします。

手順

1. registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. ターゲットレジストリーで認証します。

   $ podman login <target_registry>

3. プルーニングされたインデックスに追加するパッケージの一覧を判別します。

   1. コンテナーでプルーニングするソースインデックスイメージを実行します。以下に例を示します。

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.8

      出力例

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.8...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 別のターミナルセッションで、grpcurl コマンドを使用して、インデックスが提供するパッケージの一覧を取得します。

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. packages.out ファイルを検査し、プルーニングされたインデックスに保持したいパッケージ名をこの一覧から特定します。以下に例を示します。

      パッケージ一覧のスニペットの例

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. podman run コマンドを実行したターミナルセッションで、Ctrl と C を押してコンテナープロセスを停止します。

4. 以下のコマンドを実行して、指定したパッケージ以外のすべてのパッケージのソースインデックスをプルーニングします。

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.8 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.8] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8 4

   1

   プルーニングするインデックス。

   2

   保持するパッケージのコンマ区切りリスト。

   3

   IBM Power Systems および IBM Z イメージのみに必要です: ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用する Operator レジストリーのベースイメージです。

   4

   ビルドされる新規インデックスイメージのカスタムタグ。

5. 以下のコマンドを実行して、新規インデックスイメージをターゲットレジストリーにプッシュします。

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8

   ここで、<namespace> はレジストリー上の既存の namespace になります。たとえば、olm-mirror namespace を作成し、ミラーリングされたすべてのコンテンツをプッシュすることができます。

手順

1. Red Hat が提供するカタログをミラーリングする場合は、ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. oc adm catalog mirror コマンドは、インデックスイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。コマンドのデフォルト動作で、マニフェストを生成し、インデックスイメージからのすべてのイメージコンテンツを、インデックスイメージと同様にミラーレジストリーに対して自動的にミラーリングします。または、ミラーレジストリーが完全に非接続または エアギャップ環境のホスト上にある場合、最初にコンテンツをリムーバブルメディアにミラーリングし、メディアを非接続環境に移行してから、メディアからレジストリーにコンテンツをレジストリーに対してミラーリングできます。

   • オプション A: ミラーレジストリーがネットワークアクセスが無制限のワークステーションと同じネットワーク上にある 場合、ワークステーションで以下のアクションを実行します。

     1. ミラーレジストリーに認証が必要な場合は、以下のコマンドを実行してレジストリーにログインします。

        $ podman login <mirror_registry>

     2. 以下のコマンドを実行してコンテンツをミラーリングします。

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6

        1

        ミラーリングするカタログのインデックスイメージを指定します。たとえば、これは以前に作成したプルーニングされたインデックスイメージ、または registry.redhat.io/redhat/redhat-operator-index:v4.8 などのデフォルトカタログのソースインデックスイメージのいずれかである可能性があります。

        2

        Operator コンテンツをミラーリングするターゲットレジストリーおよび namespace の完全修飾ドメイン名 (FQDN) を指定します。ここで、<namespace> はレジストリーの既存の namespace です。たとえば、olm-mirror namespace を作成し、ミラーリングされたすべてのコンテンツをプッシュすることができます。

        3

        オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。registry.redhat.io には、{REG_CREDS} が必要です。

        4

        オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。

        5

        オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは '<platform>/<arch>[/<variant>]' として渡されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64、linux/ppc64le、linux/s390x および .* です。

        6

        オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。このオプションは、ミラーリングする内容を確認するのに役立ちます。また、パッケージのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、mapping.txt ファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。このフラグは、カタログからのコンテンツの高度で選択可能なミラーリングにのみ使用することが意図されています。opm index prune をインデックスイメージをプルーニングするために以前にしている場合、これはほとんどのカタログ管理のユースケースに適しています。

        出力例

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1

        コマンドで生成された一時的な index.db データベースのディレクトリー。

        2

        生成される manifests ディレクトリー名を記録します。このディレクトリー名は、後の手順で使用されます。

        注記

        Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、oc adm catalog mirror コマンドを実行すると、401 unauthorized エラーで失敗します。回避策として、oc adm catalog mirror コマンドを実行するときに --max-components = 2 オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は、Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューション記事を参照してください。

   • オプション B: ミラーレジストリーが非接続ホストにある場合 は、以下のアクションを実行します。

     1. ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、コンテンツをローカルファイルにミラーリングします。

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure] \
            [--index-filter-by-os='<platform>/<arch>']

        1

        ミラーリングするカタログのインデックスイメージを指定します。たとえば、これは以前に作成したプルーニングされたインデックスイメージ、または registry.redhat.io/redhat/redhat-operator-index:v4.8 などのデフォルトカタログのソースインデックスイメージのいずれかである可能性があります。

        2

        現在のディレクトリーのローカルファイルにコンテンツをミラーリングします。

        出力例

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1

        生成される manifests ディレクトリー名を記録します。このディレクトリー名は、後の手順で使用されます。

        2

        提供されたインデックスイメージをベースとする、拡張された file:// パスを記録します。このパスは、後のステップで使用されます。

     2. 現在のディレクトリーに生成される v2/ ディレクトリーをリムーバブルメディアにコピーします。
     3. メディアを物理的に削除して、これをミラーレジストリーにアクセスできる非接続環境のホストに割り当てます。

     4. ミラーレジストリーに認証が必要な場合は、非接続環境のホストで以下のコマンドを実行し、レジストリーにログインします。

        $ podman login <mirror_registry>

     5. v2/ ディレクトリーを含む親ディレクトリーから以下のコマンドを実行し、ローカルファイルからミラーレジストリーにイメージをアップロードします。

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure] \
            [--index-filter-by-os='<platform>/<arch>']

        1

        直前のコマンド出力の file:// パスを指定します。

        2

        Operator コンテンツをミラーリングするターゲットレジストリーおよび namespace の完全修飾ドメイン名 (FQDN) を指定します。ここで、<namespace> はレジストリーの既存の namespace です。たとえば、olm-mirror namespace を作成し、ミラーリングされたすべてのコンテンツをプッシュすることができます。

        注記

        Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、oc adm catalog mirror コマンドを実行すると、401 unauthorized エラーで失敗します。回避策として、oc adm catalog mirror コマンドを実行するときに --max-components = 2 オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は、Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューション記事を参照してください。

     6. oc adm catalogmirror コマンドを再度実行します。新しくミラーリングされたインデックスイメージをソースとして使用し、前の手順で使用したのと同じミラーレジストリーの namespace をターゲットとして使用します。

        $ oc adm catalog mirror \
            <mirror_registry>:<port>/<index_image> \
            <mirror_registry>:<port>/<namespace> \
            --manifests-only \1
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        コマンドがミラーリングされたすべてのコンテンツを再度コピーしないように、このステップには --manifests-only フラグが必要です。

        重要

        前のステップで生成された imageContentSourcePolicy.yaml ファイルのイメージマッピングをローカルパスから有効なミラー位置に更新する必要があるため、このステップが必要です。そうしないと、後のステップで imageContentSourcePolicy オブジェクトを作成するときにエラーが発生します。

3. コンテンツをレジストリーにミラーリングした後に、現在のディレクトリーに生成される manifests ディレクトリーを検査します。

   注記

   manifests ディレクトリー名は後の手順で使用されます。

   直前の手順で同じネットワークのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下の形式になります。

   manifests-<index_image_name>-<random_number>

   直前の手順で非接続ホストのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下の形式になります。

   manifests-index/<namespace>/<index_image_name>-<random_number>

   manifests ディレクトリーには以下のファイルが含まれており、これらの一部にはさらに変更が必要になる場合があります。

   • catalogSource.yaml ファイルは、インデックスイメージタグおよび他の関連するメタデータで事前に設定される CatalogSource オブジェクトの基本的な定義です。このファイルは、カタログソースをクラスターに追加するためにそのまま使用したり、変更したりできます。

     重要

     ローカルファイルにコンテンツをミラーリングする場合は、catalogSource.yaml ファイルを変更して metadata.name フィールドからバックスラッシュ (/) 文字を削除する必要があります。または、オブジェクトの作成を試みると、invalid resource name (無効なリソース名) を示すエラーを出して失敗します。

   • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。

     注記

     クラスターが ImageContentSourcePolicy オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。

   • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。

     重要

     ミラーリングのプロセスで --manifests-only フラグを使用しており、ミラーリングするパッケージのサブセットをさらにトリミングするには、mapping.txt ファイルの変更および oc image mirror コマンドでのファイルの使用について、OpenShift Container Platform 4.7 ドキュメントの Package Manifest Format カタログイメージのミラーリング の手順を参照してください。これらの追加のアクションを実行した後に、この手順を続行できます。

4. 非接続クラスターへのアクセスのあるホストで、以下のコマンドを実行して manifests ディレクトリーで imageContentSourcePolicy.yaml ファイルを指定し、ImageContentSourcePolicy (ICSP) オブジェクトを作成します。

   $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

   ここで、<path/to/manifests/dir> は、ミラーリングされたコンテンツについての manifests ディレクトリーへのパスです。

   ミラーリングされたインデックスイメージおよび Operator コンテンツを参照する CatalogSource を作成できるようになりました。

手順

1. インデックスイメージを参照する CatalogSource オブジェクトを作成します。oc adm catalog mirror コマンドを使用してカタログをターゲットレジストリーにミラーリングする場合、開始点として生成される catalogSource.yaml ファイルをそのまま使用することができます。

   1. 仕様を以下のように変更し、これを catalogSource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog 1
        namespace: openshift-marketplace 2
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.8 3
        displayName: My Operator Catalog
        publisher: <publisher_name> 4
        updateStrategy:
          registryPoll: 5
            interval: 30m

      1

      レジストリーにアップロードする前にローカルファイルにコンテンツをミラーリングする場合は、metadata.name フィールドからバックスラッシュ (/) 文字を削除し、オブジェクトの作成時に invalid resource name エラーを回避します。

      2

      カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、openshift-marketplace namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。

      3

      インデックスイメージを指定します。

      4

      カタログを公開する名前または組織名を指定します。

      5

      カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。

   2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc apply -f catalogSource.yaml

2. 以下のリソースが正常に作成されていることを確認します。

   1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

手順

1. バンドルイメージを追加して、既存のインデックスを更新します。

   $ opm index add \
       --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
       --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
       --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
       --pull-tool podman 4

   1

   --bundlesフラグは、インデックスに追加する他のバンドルイメージのコンマ区切りリストを指定します。

   2

   --from-indexフラグは、以前にプッシュされたインデックスを指定します。

   3

   --tagフラグは、更新されたインデックスイメージに適用するイメージタグを指定します。

   4

   --pull-toolフラグは、コンテナーイメージのプルに使用されるツールを指定します。

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

   <registry>

   quay.ioやmirror.example.comなどのレジストリーのホスト名を指定します。

   <namespace>

   ocs-devやabcなど、レジストリーの namespace を指定します。

   <new_bundle_image>

   ocs-operatorなど、レジストリーに追加する新しいバンドルイメージを指定します。

   <digest>

   c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。

   <existing_index_image>

   abc-redhat-operator-indexなど、以前にプッシュされたイメージを指定します。

   <existing_tag>

   4.8 など、以前にプッシュされたイメージタグを指定します。

   <updated_tag>

   4.8.1 など、更新されたインデックスイメージに適用するイメージタグを指定します。

   コマンドの例

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.8 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.8.1 \
       --pull-tool podman

2. 更新されたインデックスイメージをプッシュします。

   $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

3. Operator カタログのミラーリングの手順にあるステップを再度実行し、更新されたコンテンツをミラーリングします。ただし、ImageContentSourcePolicy (ICSP) オブジェクトの作成手順を参照する場合、 oc create コマンドの代わりに oc replace コマンドを使用します。以下に例を示します。

   $ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml

   この変更は、オブジェクトがすでに存在し、更新する必要があるために必要になります。

   注記

   通常、oc apply コマンドを使用して、oc apply を使用して以前に作成された既存のオブジェクトを更新できます。ただし、ICSP オブジェクトの metadata.annotations フィールドのサイズに関する既知の問題により、現時点では oc replace コマンドをこの手順で使用する必要があります。

4. Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。

   $ oc get packagemanifests -n openshift-marketplace

1. Operator SDK コマンドラインインターフェイス (CLI) を使用した Operator プロジェクトの作成。
2. カスタムリソース定義 (CRD) を追加することによる新規リソース API の定義。
3. Operator SDK API を使用した監視対象リソースの指定。
4. 指定されたハンドラーでの Operator 調整 (reconciliation) ロジックの定義、およびリソースと対話するための Operator SDK API の使用。
5. Operator Deployment マニフェストをビルドし、生成するための Operator SDK CLI の使用。

手順

1. OpenShift ミラーサイト に移動します。
2. 4.8.4 ディレクトリーから、Linux 用の最新バージョンの tarball をダウンロードします。

3. アーカイブを展開します。

   $ tar xvf operator-sdk-v1.8.0-ocp-linux-x86_64.tar.gz

4. ファイルを実行可能にします。

   $ chmod +x operator-sdk

5. 展開された operator-sdk バイナリーを PATH にあるディレクトリーに移動します。

   ヒント

   PATH を確認するには、以下を実行します。

   $ echo $PATH

   $ sudo mv ./operator-sdk /usr/local/bin/operator-sdk

手順

1. PROJECT ファイルに対して以下の変更を実行します。

   1. PROJECT ファイルの plugins オブジェクトを、manifests と scorecard を使用するように更新します。

      Operator Lifecycle Manager (OLM) およびスコアカードマニフェストを作成する manifests および scorecard プラグインには、関連ファイルを作成する create サブコマンドを実行するためのプラグインプラグインが含まれるようになりました。

      • Go ベースの Operator プロジェクトでは、既存の Go ベースのプラグイン設定オブジェクトがすでに存在します。以前の設定は引き続きサポートされますが、設定オプションがそれぞれのプラグインに追加されるため、これらの新しいオブジェクトは今後役に立ちます。

        以前の設定

        version: 3-alpha
        ...
        plugins:
          go.sdk.operatorframework.io/v2-alpha: {}

        新規設定

        version: 3-alpha
        ...
        plugins:
          manifests.sdk.operatorframework.io/v2: {}
          scorecard.sdk.operatorframework.io/v2: {}

      • オプション: Ansible および Helm ベースの Operator プロジェクトの場合に、プラグイン設定オブジェクトは存在しませんでした。プラグイン設定オブジェクトを追加する必要はありませんが、設定オプションがそれぞれのプラグインに追加されるため、これらの新しいオブジェクトは今後役に立ちます。

        version: 3-alpha
        ...
        plugins:
          manifests.sdk.operatorframework.io/v2: {}
          scorecard.sdk.operatorframework.io/v2: {}

   2. PROJECT 設定バージョン 3-alpha は 3 にアップグレードする必要があります。PROJECT ファイルの version キーは、PROJECT の設定バージョンを表します。

      以前の PROJECT ファイル

      version: 3-alpha
      resources:
      - crdVersion: v1
      ...

      バージョン 3alpha は バージョン 3 として安定しており、プロジェクトの完全記述に十分な設定フィールドが含まれています。この変更は、仕様がアルファバージョンであるため、技術的には重大ではありませんが、デフォルトで operator-sdk コマンドで使用されていたので、Breaking とマークして、便利なアップグレードパスを設定する必要があります。

      1. alpha config-3alpha-to-3 コマンドを実行して、PROJECT ファイルの多くをバージョン 3-alpha から 3 に変換します。

         $ operator-sdk alpha config-3alpha-to-3

         出力例

         Your PROJECT config file has been converted from version 3-alpha to 3. Please make sure all config data is correct.

         このコマンドは、自動変換が不可能な方向を示すコメントも出力します。

      2. 変更内容を確認します。

         新規の PROJECT ファイル

         version: "3"
         resources:
         - api:
           crdVersion: v1
         ...

2. config/manager/manager.yaml ファイルに以下の変更を加えます。

   1. Ansible および Helm ベースの Operator プロジェクトの場合は、liveness および readiness プローブを追加します。

      Operator SDK でビルドされた新規プロジェクトには、デフォルトでプローブが設定されます。指定のイメージベースで、エンドポイント /healthz および /readyz が利用可能になりました。Dockerfile を更新して最新のベースイメージを使用するように既存のプロジェクトを更新し、以下を config/manager/manager.yaml ファイルの manager コンテナーに追加できます。

      例5.1 Ansible ベースの Operator プロジェクトの設定

        livenessProbe:
          httpGet:
            path: /healthz
            port: 6789
          initialDelaySeconds: 15
          periodSeconds: 20
        readinessProbe:
          httpGet:
            path: /readyz
            port: 6789
          initialDelaySeconds: 5
          periodSeconds: 10

      例5.2 Helm ベースの Operator プロジェクトの設定

        livenessProbe:
          httpGet:
            path: /healthz
            port: 8081
          initialDelaySeconds: 15
          periodSeconds: 20
        readinessProbe:
          httpGet:
            path: /readyz
            port: 8081
          initialDelaySeconds: 5
          periodSeconds: 10

   2. Ansible および Helm ベースの Operator プロジェクトについては、セキュリティーコンテキストをマネージャーのデプロイメントに追加します。

      config/manager/manager.yaml ファイルに、以下のセキュリティーコンテキストを追加します。

      例5.3 config/manager/manager.yaml ファイル

      spec:
        ...
        template:
          ...
          spec:
            securityContext:
              runAsNonRoot: true
            containers:
            - name: manager
              securityContext:
                allowPrivilegeEscalation: false

3. Makefile に以下の変更を加えます。

   1. Ansible および Helm ベースの Operator プロジェクトの場合には、Makefile で helm-operator および ansible-operator URL を更新します。

      • Ansible ベース Operator のプロジェクトの場合:

        https://github.com/operator-framework/operator-sdk/releases/download/v1.3.0/ansible-operator-v1.3.0-$(ARCHOPER)-$(OSOPER)

        以下のように変更します。

        https://github.com/operator-framework/operator-sdk/releases/download/v1.8.0/ansible-operator_$(OS)_$(ARCH)

      • Helm ベースの Operator プロジェクトの場合:

        https://github.com/operator-framework/operator-sdk/releases/download/v1.3.0/helm-operator-v1.3.0-$(ARCHOPER)-$(OSOPER)

        以下のように変更します。

        https://github.com/operator-framework/operator-sdk/releases/download/v1.8.0/helm-operator_$(OS)_$(ARCH)

   2. Ansible および Helm ベースの Operator プロジェクトの場合は、Makefile で helm-operator、ansible-operator および kustomize ルールを更新します。これらのルールはローカルのバイナリーをダウンロードしますが、グローバルバイナリーが存在する場合はローカルのバイナリーは使用されません。

      例5.4 Ansible ベースの Operator プロジェクトの Makefile の差分

       PATH  := $(PATH):$(PWD)/bin
       SHELL := env PATH=$(PATH) /bin/sh
      -OS := $(shell uname -s | tr '[:upper:]' '[:lower:]')
      -ARCH := $(shell uname -m | sed 's/x86_64/amd64/')
      +OS    = $(shell uname -s | tr '[:upper:]' '[:lower:]')
      +ARCH  = $(shell uname -m | sed 's/x86_64/amd64/')
      +OSOPER   = $(shell uname -s | tr '[:upper:]' '[:lower:]' | sed 's/darwin/apple-darwin/' | sed 's/linux/linux-gnu/')
      +ARCHOPER = $(shell uname -m )
      
      -# Download kustomize locally if necessary, preferring the $(pwd)/bin path over global if both exist.
      -.PHONY: kustomize
      -KUSTOMIZE = $(shell pwd)/bin/kustomize
       kustomize:
      -ifeq (,$(wildcard $(KUSTOMIZE)))
      -ifeq (,$(shell which kustomize 2>/dev/null))
      +ifeq (, $(shell which kustomize 2>/dev/null))
       	@{ \
       	set -e ;\
      -	mkdir -p $(dir $(KUSTOMIZE)) ;\
      -	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.5.4/kustomize_v3.5.4_$(OS)_$(ARCH).tar.gz | \
      -	tar xzf - -C bin/ ;\
      +	mkdir -p bin ;\
      +	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.5.4/kustomize_v3.5.4_$(OS)_$(ARCH).tar.gz | tar xzf - -C bin/ ;\
       	}
      +KUSTOMIZE=$(realpath ./bin/kustomize)
       else
      -KUSTOMIZE = $(shell which kustomize)
      -endif
      +KUSTOMIZE=$(shell which kustomize)
       endif
      
      -# Download ansible-operator locally if necessary, preferring the $(pwd)/bin path over global if both exist.
      -.PHONY: ansible-operator
      -ANSIBLE_OPERATOR = $(shell pwd)/bin/ansible-operator
       ansible-operator:
      -ifeq (,$(wildcard $(ANSIBLE_OPERATOR)))
      -ifeq (,$(shell which ansible-operator 2>/dev/null))
      +ifeq (, $(shell which ansible-operator 2>/dev/null))
       	@{ \
       	set -e ;\
      -	mkdir -p $(dir $(ANSIBLE_OPERATOR)) ;\
      -	curl -sSLo $(ANSIBLE_OPERATOR) https://github.com/operator-framework/operator-sdk/releases/download/v1.3.0/ansible-operator_$(OS)_$(ARCH) ;\
      -	chmod +x $(ANSIBLE_OPERATOR) ;\
      +	mkdir -p bin ;\
      +	curl -LO https://github.com/operator-framework/operator-sdk/releases/download/v1.8.0/ansible-operator-v1.8.0-$(ARCHOPER)-$(OSOPER) ;\
      +	mv ansible-operator-v1.8.0-$(ARCHOPER)-$(OSOPER) ./bin/ansible-operator ;\
      +	chmod +x ./bin/ansible-operator ;\
       	}
      +ANSIBLE_OPERATOR=$(realpath ./bin/ansible-operator)
       else
      -ANSIBLE_OPERATOR = $(shell which ansible-operator)
      -endif
      +ANSIBLE_OPERATOR=$(shell which ansible-operator)
       endif

      例5.5 Helm ベースの Operator プロジェクトの Makefile の差分

       PATH  := $(PATH):$(PWD)/bin
       SHELL := env PATH=$(PATH) /bin/sh
      -OS := $(shell uname -s | tr '[:upper:]' '[:lower:]')
      -ARCH := $(shell uname -m | sed 's/x86_64/amd64/')
      +OS    = $(shell uname -s | tr '[:upper:]' '[:lower:]')
      +ARCH  = $(shell uname -m | sed 's/x86_64/amd64/')
      +OSOPER   = $(shell uname -s | tr '[:upper:]' '[:lower:]' | sed 's/darwin/apple-darwin/' | sed 's/linux/linux-gnu/')
      +ARCHOPER = $(shell uname -m )
      
      -# Download kustomize locally if necessary, preferring the $(pwd)/bin path over global if both exist.
      -.PHONY: kustomize
      -KUSTOMIZE = $(shell pwd)/bin/kustomize
       kustomize:
      -ifeq (,$(wildcard $(KUSTOMIZE)))
      -ifeq (,$(shell which kustomize 2>/dev/null))
      +ifeq (, $(shell which kustomize 2>/dev/null))
       	@{ \
       	set -e ;\
      -	mkdir -p $(dir $(KUSTOMIZE)) ;\
      -	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.5.4/kustomize_v3.5.4_$(OS)_$(ARCH).tar.gz | \
      -	tar xzf - -C bin/ ;\
      +	mkdir -p bin ;\
      +	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.5.4/kustomize_v3.5.4_$(OS)_$(ARCH).tar.gz | tar xzf - -C bin/ ;\
       	}
      +KUSTOMIZE=$(realpath ./bin/kustomize)
       else
      -KUSTOMIZE = $(shell which kustomize)
      -endif
      +KUSTOMIZE=$(shell which kustomize)
       endif
      
      -# Download helm-operator locally if necessary, preferring the $(pwd)/bin path over global if both exist.
      -.PHONY: helm-operator
      -HELM_OPERATOR = $(shell pwd)/bin/helm-operator
       helm-operator:
      -ifeq (,$(wildcard $(HELM_OPERATOR)))
      -ifeq (,$(shell which helm-operator 2>/dev/null))
      +ifeq (, $(shell which helm-operator 2>/dev/null))
       	@{ \
       	set -e ;\
      -	mkdir -p $(dir $(HELM_OPERATOR)) ;\
      -	curl -sSLo $(HELM_OPERATOR) https://github.com/operator-framework/operator-sdk/releases/download/v1.3.0/helm-operator_$(OS)_$(ARCH) ;\
      -	chmod +x $(HELM_OPERATOR) ;\
      +	mkdir -p bin ;\
      +	curl -LO https://github.com/operator-framework/operator-sdk/releases/download/v1.8.0/helm-operator-v1.8.0-$(ARCHOPER)-$(OSOPER) ;\
      +	mv helm-operator-v1.8.0-$(ARCHOPER)-$(OSOPER) ./bin/helm-operator ;\
      +	chmod +x ./bin/helm-operator ;\
       	}
      +HELM_OPERATOR=$(realpath ./bin/helm-operator)
       else
      -HELM_OPERATOR = $(shell which helm-operator)
      -endif
      +HELM_OPERATOR=$(shell which helm-operator)
       endif

   3. docker-build の make ターゲットで、位置ディレクトリー引数 . を移動します。

      docker-build ターゲットのディレクトリー引数 . は、podman CLI が想定する内容に合わせて最後の位置引数に移動されるので、置換が整理されます。

      以前のターゲット

      docker-build:
        docker build . -t ${IMG}

      新規ターゲット

      docker-build:
        docker build -t ${IMG} .

      以下のコマンドを実行して変更を加えます。

      $ sed -i 's/docker build . -t ${IMG}/docker build -t ${IMG} ./' $(git grep -l 'docker.*build \. ')

   4. Ansible および Helm ベースの Operator プロジェクトの場合は、Makefile に ヘルプ ターゲットを追加します。

      Ansible および Helm ベースのプロジェクトでは、 --help フラグと同様に、デフォルトで Makefile で ヘルプ ターゲットを提供するようになりました。以下の行を使用して、このターゲットを Makefile に手動で追加できます。

      例5.6 help ターゲット

      ##@ General
      
      # The help target prints out all targets with their descriptions organized
      # beneath their categories. The categories are represented by '##@' and the
      # target descriptions by '##'. The awk commands is responsible for reading the
      # entire set of makefiles included in this invocation, looking for lines of the
      # file as xyz: ## something, and then pretty-format the target and help. Then,
      # if there's a line with ##@ something, that gets pretty-printed as a category.
      # More info on the usage of ANSI control characters for terminal formatting:
      # https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parameters
      # More info on the awk command:
      # http://linuxcommand.org/lc3_adv_awk.php
      
      help: ## Display this help.
      	@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n  make \033[36m<target>\033[0m\n"} /^[a-zA-Z_0-9-]+:.*?##/ { printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2 } /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) } ' $(MAKEFILE_LIST)

   5. opm と catalog-build ターゲットを追加します。これらのターゲットを使用して Operator の独自のカタログを作成するか、Operator バンドルを既存のカタログに追加できます。

      1. 以下の行を追加して、Makefile にターゲットを追加します。

         例5.7 opm および catalog-build ターゲット

         .PHONY: opm
         OPM = ./bin/opm
         opm:
         ifeq (,$(wildcard $(OPM)))
         ifeq (,$(shell which opm 2>/dev/null))
         	@{ \
         	set -e ;\
         	mkdir -p $(dir $(OPM)) ;\
         	curl -sSLo $(OPM) https://github.com/operator-framework/operator-registry/releases/download/v1.15.1/$(OS)-$(ARCH)-opm ;\
         	chmod +x $(OPM) ;\
         	}
         else
         OPM = $(shell which opm)
         endif
         endif
         BUNDLE_IMGS ?= $(BUNDLE_IMG)
         CATALOG_IMG ?= $(IMAGE_TAG_BASE)-catalog:v$(VERSION) ifneq ($(origin CATALOG_BASE_IMG), undefined) FROM_INDEX_OPT := --from-index $(CATALOG_BASE_IMG) endif
         .PHONY: catalog-build
         catalog-build: opm
         	$(OPM) index add --container-tool docker --mode semver --tag $(CATALOG_IMG) --bundles $(BUNDLE_IMGS) $(FROM_INDEX_OPT)
         
         .PHONY: catalog-push
         catalog-push: ## Push the catalog image.
         	$(MAKE) docker-push IMG=$(CATALOG_IMG)

      2. Go ベースの Operator プロジェクトを更新する場合は、以下の Makefile 変数も追加します。

         例5.8 Makefile 変数

         OS = $(shell go env GOOS)
         ARCH = $(shell go env GOARCH)

   6. Go ベースの Operator プロジェクトの場合は、Makefile の SHELL 変数をシステム bash バイナリーに設定します。

      setup-envtest.sh スクリプトをインポートするには bash が必要であるため、SHELL 変数をエラーオプションで bash に設定する必要があります。

      例5.9 Makefile の差分

      else GOBIN=$(shell go env GOBIN)
      endif
      +# Setting SHELL to bash allows bash commands to be executed by recipes.
      +# This is a requirement for 'setup-envtest.sh' in the test target.
      +# Options are set to exit when a recipe line exits non-zero or a piped command fails.
      +SHELL = /usr/bin/env bash -o pipefail
      +.SHELLFLAGS = -ec
      + all: build

4. Go ベースの Operator プロジェクトの場合は、go.mod ファイルの以下のエントリーを変更して controller-runtime を v0.8.3 に、Kubernetes の依存関係を v0.20.2 にアップグレードし、プロジェクトを再ビルドします。

   例5.10 go.mod ファイル

   ...
   	k8s.io/api v0.20.2
   	k8s.io/apimachinery v0.20.2
   	k8s.io/client-go v0.20.2
   	sigs.k8s.io/controller-runtime v0.8.3

5. system:controller-manager サービスアカウントをプロジェクトに追加します。デフォルト以外のサービスアカウント controller-manager が operator-sdk init コマンドで生成されるようになり、共有 namespace にインストールされている Operator のセキュリティーが改善されます。このサービスアカウントを既存プロジェクトに追加するには、以下の手順に従います。

   1. ファイルに ServiceAccount 定義を作成します。

      例5.11 config/rbac/service_account.yaml ファイル

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: controller-manager
        namespace: system

   2. サービスアカウントを RBAC リソースの一覧に追加します。

      $ echo "- service_account.yaml" >> config/rbac/kustomization.yaml

   3. Operator のサービスアカウントを参照する RoleBinding および ClusterRoleBinding オブジェクトをすべて更新します。

      $ find config/rbac -name *_binding.yaml -exec sed -i -E 's/  name: default/  name: controller-manager/g' {} \;

   4. サービスアカウント名をマネージャーデプロイメントの spec.template.spec.serviceAccountName フィールドに追加します。

      $ sed -i -E 's/([ ]+)(terminationGracePeriodSeconds:)/\1serviceAccountName: controller-manager\n\1\2/g' config/manager/manager.yaml

   5. 変更が以下の差分のようになっていることを確認します。

      例5.12 config/manager/manager.yaml ファイルの差分

      ...
                 requests:
                   cpu: 100m
                   memory: 20Mi
      +      serviceAccountName: controller-manager
             terminationGracePeriodSeconds: 10

      例5.13 config/rbac/auth_proxy_role_binding.yaml ファイルの差分

      ...
         name: proxy-role
       subjects:
       - kind: ServiceAccount
      -  name: default
      +  name: controller-manager
         namespace: system

      例5.14 config/rbac/kustomization.yaml ファイルの差分

       resources:
      +- service_account.yaml
       - role.yaml
       - role_binding.yaml
       - leader_election_role.yaml

      例5.15 config/rbac/leader_election_role_binding.yaml ファイルの差分

      ...
         name: leader-election-role
       subjects:
       - kind: ServiceAccount
      -  name: default
      +  name: controller-manager
         namespace: system

      例5.16 config/rbac/role_binding.yaml ファイルの差分

      ...
         name: manager-role
       subjects:
       - kind: ServiceAccount
      -  name: default
      +  name: controller-manager
         namespace: system

      例5.17 config/rbac/service_account.yaml ファイルの差分

      +apiVersion: v1
      +kind: ServiceAccount
      +metadata:
      +  name: controller-manager
      +  namespace: system

6. config/manifests/kustomization.yaml ファイルに以下の変更を加えます。

   1. Kustomize パッチを追加して、cert-manager ボリューム および volumeMount オブジェクトをクラスターサービスバージョン (CSV) から削除します。

      Operator Lifecycle Manager (OLM) ではまだ cert-manager がサポートされないため、OLM が Operator 用の証明書を作成して管理できるように、このボリュームを削除してマウントするように、JSON パッチが追加されました。

      config/manifests/kustomization.yaml ファイルに、以下の行を追加します。

      例5.18 config/manifests/kustomization.yaml ファイル

      patchesJson6902:
      - target:
          group: apps
          version: v1
          kind: Deployment
          name: controller-manager
          namespace: system
        patch: |-
          # Remove the manager container's "cert" volumeMount, since OLM will create and mount a set of certs.
          # Update the indices in this path if adding or removing containers/volumeMounts in the manager's Deployment.
          - op: remove
            path: /spec/template/spec/containers/1/volumeMounts/0
          # Remove the "cert" volume, since OLM will create and mount a set of certs.
          # Update the indices in this path if adding or removing volumes in the manager's Deployment.
          - op: remove
            path: /spec/template/spec/volumes/0

   2. オプション: Ansible および Helm ベースの Operator プロジェクトの場合は、コンポーネント設定で ansible-operator および helm-operator を設定します。このオプションを追加するには、以下の手順に従います。

      1. 以下のファイルを作成します。

         例5.19 config/default/manager_config_patch.yaml ファイル

         apiVersion: apps/v1
         kind: Deployment
         metadata:
           name: controller-manager
           namespace: system
         spec:
           template:
             spec:
               containers:
               - name: manager
                 args:
                 - "--config=controller_manager_config.yaml"
                 volumeMounts:
                 - name: manager-config
                   mountPath: /controller_manager_config.yaml
                   subPath: controller_manager_config.yaml
               volumes:
               - name: manager-config
                 configMap:
                   name: manager-config

      2. 以下のファイルを作成します。

         例5.20 config/manager/controller_manager_config.yaml ファイル

         apiVersion: controller-runtime.sigs.k8s.io/v1alpha1
         kind: ControllerManagerConfig
         health:
           healthProbeBindAddress: :6789
         metrics:
           bindAddress: 127.0.0.1:8080
         
         leaderElection:
           leaderElect: true
           resourceName: <resource_name>

      3. 以下の変更を resources に適用して、config/default/kustomization.yaml ファイルを更新します。

         例5.21 config/default/kustomization.yaml ファイル

           resources:
           ...
           - manager_config_patch.yaml

      4. 以下の変更を適用して、config/manager/kustomization.yaml ファイルを更新します。

         例5.22 config/manager/kustomization.yaml ファイル

           generatorOptions:
             disableNameSuffixHash: true
         
           configMapGenerator:
           - files:
             - controller_manager_config.yaml
             name: manager-config
           apiVersion: kustomize.config.k8s.io/v1beta1
           kind: Kustomization
           images:
           - name: controller
             newName: quay.io/example/memcached-operator
             newTag: v0.0.1

   3. オプション: config/default/kustomization.yaml ファイルにマネージャー設定パッチを追加します。

      config file のサポートが最初に追加されたタイミングで、生成された --config フラグが ansible-operator または helm-operator バイナリーのいずれかに追加されていなかったため、現在は機能しません。--config フラグは、ファイルによるバイナリーの設定をサポートします。この設定の方法は、Operator 全体としてではなく、基盤の コントローラーマネージャー にのみ適用されます。

      オプションで設定ファイルで Operator のデプロイメントを設定するには、以下の差分に示されるように config/default/kustomization.yaml ファイルに変更を加えます。

      例5.23 config/default/kustomization.yaml ファイルの差分

      # If you want your controller-manager to expose the /metrics # endpoint w/o any authn/z, please comment the following line.
      \- manager_auth_proxy_patch.yaml
      +# Mount the controller config file for loading manager configurations
      +# through a ComponentConfig type
      +- manager_config_patch.yaml

      フラグはそのまま使用したり、設定ファイルの値を上書きしたりできます。

7. Ansible および Helm ベースの Operator プロジェクトについては、config/rbac/leader_election_role.yaml ファイルに以下の変更を加え、リーダー選出のロールルールを追加します。

   例5.24 config/rbac/leader_election_role.yaml ファイル

   - apiGroups:
     - coordination.k8s.io
     resources:
     - leases
     verbs:
     - get
     - list
     - watch
     - create
     - update
     - patch
     - delete

8. Ansible ベースの Operator プロジェクトの場合は、Ansible コレクションを更新します。

   requirements.yml ファイルで community.kubernetes の バージョン フィールドを 1.2.1 に変更し、operator_sdk.util の バージョン フィールドを 0.2.0 に変更します。

9. config/default/manager_auth_proxy_patch.yaml ファイルに以下の変更を加えます。

   • Ansible ベースの Operator プロジェクトの場合は、--health-probe-bind-address=:6789 引数を config/default/manager_auth_proxy_patch.yaml ファイルに追加します。

     例5.25 config/default/manager_auth_proxy_patch.yaml ファイル

     spec:
       template:
         spec:
           containers:
           - name: manager
             args:
             - "--health-probe-bind-address=:6789"
             ...

   • Helm ベースの Operator のプロジェクト:

     1. --health-probe-bind-address=:8081 引数を config/default/manager_auth_proxy_patch.yaml ファイルに追加します。

        例5.26 config/default/manager_auth_proxy_patch.yaml ファイル

        spec:
          template:
            spec:
              containers:
              - name: manager
                args:
                - "--health-probe-bind-address=:8081"
                ...

     2. 非推奨のフラグ --enable-leader-election を --leader-elect に置き換え、非推奨のフラグ --metrics-addr を --metrics-bind-address に置き換えます。

10. config/prometheus/monitor.yaml ファイルに以下の変更を加えます。

    1. スキーム、トークン、および TLS 設定を Prometheus ServiceMonitor メトリクスエンドポイントに追加します。

       マネージャー Pod で https ポートを指定しているにも拘らず、tlsConfig が設定されていないので、/metrics エンドポインが HTTPS 経由でサービスを提供されるように実際には設定されていません。kube-rbac-proxy は、Pod にマウントされたサービスアカウントトークンを使用して、このエンドポイントのセキュリティーをマネージャーサイドカーコンテナーとして確保するので、デフォルトでこの問題が修正されます。

       以下の差分に示されるように、config/prometheus/monitor.yaml ファイルに変更を適用します。

       例5.27 config/prometheus/monitor.yaml ファイルの差分

       spec:
          endpoints:
            - path: /metrics
              port: https
       +      scheme: https
       +      bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
       +      tlsConfig:
       +        insecureSkipVerify: true
          selector:
            matchLabels:
              control-plane: controller-manager

       注記

       kube-rbac-proxy をプロジェクトから削除した場合には、適切な TLS 設定 を使用して /metrics エンドポイントのセキュリティーを確保するようにしてください。

11. 既存の依存リソースに所有者アノテーションがあることを確認します。

    Ansible ベースの Operator プロジェクトの場合には、クラスタースコープの依存リソースおよび他の namespace の依存関係リソースで 所有者の参照アノテーション が正しく適用されませんでした。これらのアノテーションを手動で追加することが回避策でしたが、このバグが修正されたため、これは必要なくなりました。

12. パッケージマニフェストのサポートを非推奨にします。

    Operator Framework では、今後のリリースで Operator パッケージマニフェスト形式のサポートが削除されます。非推奨のプロセスの一環として、operator-sdk generate packagemanifests および operator-sdk run packagemanifests コマンドが非推奨となりました。パッケージマニフェストをバンドルに移行するには、operator-sdk pkgman-to-bundle コマンドを使用できます。

    operator-sdk pkgman-to-bundle --help コマンドを実行して、パッケージマニフェストプロジェクトのバンドル形式への移行を参照してください。

13. Operator のファイナライザー名を更新します。

    Kubernetes ドキュメント が提案するファイナライザーの名前の形式は、以下のとおりです。

    <qualified_group>/<finalizer_name>

    以前の Operator SDK の記述形式は次のとおりです。

    <finalizer_name>.<qualified_group>

    Operator が、名前の形式が不適切なファイナライザーを使用する場合は、公式の形式に一致するようにこれらのファイナライザーを変更します。たとえば、finalizer.cache.example.com を cache.example.com/finalizer に変更する必要があります。