1. テナントの namespace とは別のテナント Operator の namespace を作成します。これは、プロジェクトを作成することで実行できます。
2. テナントの namepsace のみを対象とするテナント Operator の Operator グループを作成します。
3. テナント Operator namespace に Operator をインストールします。

手順

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

2. Operators → Installed Operators ページに移動します。このページには、dedicated-admin によってクラスターにインストールされた使用可能な 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. 以下のいずれかを選択します。

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

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

      • クラスターが AWS STS モードの場合は、サービスアカウントの AWS IAM ロールの Amazon Resource Name (ARN) を role ARN フィールドに入力します。

        

        ロールの ARN を作成するには、AWS アカウントの準備 で説明されている手順に従います。

      • クラスターが Azure AD Workload Identity モードの場合は、クライアント ID、テナント ID、およびサブスクリプション ID を適切なフィールドに追加します。
   3. 複数の更新チャネルが利用可能な場合は、Update channel を選択します。

   4. 前述のように、Automatic または Manual 承認ストラテジーを選択します。

      重要

      Web コンソールにクラスターが AWS STS または Azure AD Workload Identity モードであることが示された場合は、Update approval を Manual に設定する必要があります。

      更新前に権限の変更が必要になる可能性があるため、自動更新承認のあるサブスクリプションは推奨できません。手動更新承認付きのサブスクリプションにより、管理者は新しいバージョンの権限を確認し、更新前に必要な手順を実行する機会が確保されます。

6. Install をクリックし、Operator をこの OpenShift Dedicated クラスターの選択した 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 を指定します。カスタムグローバル 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. トークン認証が有効になっているクラウドプロバイダー上のクラスターの場合:

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

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

      1

      更新前に権限の変更が必要になる可能性があるため、自動更新承認のあるサブスクリプションは推奨できません。手動更新承認付きのサブスクリプションにより、管理者は新しいバージョンの権限を確認し、更新前に必要な手順を実行する機会が確保されます。

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

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

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

        1

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

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

        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 を含めます。

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

   $ oc apply -f sub.yaml

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

手順

1. 次のコマンドを実行して、インストールする Operator の利用可能なバージョンとチャネルを検索します。

   コマンド構文

   $ oc describe packagemanifests <operator_name> -n <catalog_namespace>

   たとえば、次のコマンドは、OperatorHub から Red Hat Quay Operator の利用可能なチャネルとバージョンを出力します。

   コマンドの例

   $ oc describe packagemanifests quay-operator -n openshift-marketplace

   例4.1 出力例

   Name:         quay-operator
   Namespace:    operator-marketplace
   Labels:       catalog=redhat-operators
                 catalog-namespace=openshift-marketplace
                 hypershift.openshift.io/managed=true
                 operatorframework.io/arch.amd64=supported
                 operatorframework.io/os.linux=supported
                 provider=Red Hat
                 provider-url=
   Annotations:  <none>
   API Version:  packages.operators.coreos.com/v1
   Kind:         PackageManifest
   ...
       Current CSV:  quay-operator.v3.7.11
   ...
       Entries:
         Name:       quay-operator.v3.7.11
         Version:    3.7.11
         Name:       quay-operator.v3.7.10
         Version:    3.7.10
         Name:       quay-operator.v3.7.9
         Version:    3.7.9
         Name:       quay-operator.v3.7.8
         Version:    3.7.8
         Name:       quay-operator.v3.7.7
         Version:    3.7.7
         Name:       quay-operator.v3.7.6
         Version:    3.7.6
         Name:       quay-operator.v3.7.5
         Version:    3.7.5
         Name:       quay-operator.v3.7.4
         Version:    3.7.4
         Name:       quay-operator.v3.7.3
         Version:    3.7.3
         Name:       quay-operator.v3.7.2
         Version:    3.7.2
         Name:       quay-operator.v3.7.1
         Version:    3.7.1
         Name:       quay-operator.v3.7.0
         Version:    3.7.0
       Name:         stable-3.7
   ...
      Current CSV:  quay-operator.v3.8.5
   ...
      Entries:
         Name:         quay-operator.v3.8.5
         Version:      3.8.5
         Name:         quay-operator.v3.8.4
         Version:      3.8.4
         Name:         quay-operator.v3.8.3
         Version:      3.8.3
         Name:         quay-operator.v3.8.2
         Version:      3.8.2
         Name:         quay-operator.v3.8.1
         Version:      3.8.1
         Name:         quay-operator.v3.8.0
         Version:      3.8.0
       Name:           stable-3.8
     Default Channel:  stable-3.8
     Package Name:     quay-operator

   ヒント

   次のコマンドを実行すると、Operator のバージョンとチャネル情報を YAML 形式で出力できます。

   $ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml

   • namespace に複数のカタログがインストールされている場合は、次のコマンドを実行して、特定のカタログから Operator の使用可能なバージョンとチャネルを検索します。

     $ oc get packagemanifest \
        --selector=catalog=<catalogsource_name> \
        --field-selector metadata.name=<operator_name> \
        -n <catalog_namespace> -o yaml

     重要

     Operator のカタログを指定しない場合、oc get packagemanifest および oc description packagemanifest コマンドを実行すると、次の条件が満たされると予期しないカタログからパッケージが返される可能性があります。

     • 複数のカタログが同じ namespace にインストールされます。
     • カタログには、同じ Operator、または同じ名前の Operator が含まれています。

2. OperatorGroup オブジェクトによって定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要なロールベースのアクセス制御 (RBAC) アクセスを生成するターゲットの namespace を選択します。

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

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

   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

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

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

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

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

   1

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

   2

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

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

   $ oc apply -f sub.yaml

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

手順

1. Web コンソールで Operators → OperatorHub をクリックします。
2. インストールする Operator を選択します。

3. 選択した Operator から、リストから チャンネル と バージョン を選択できます。

   注記

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

   手動承認は、namespace にインストールされているすべての Operator に適用されます。

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

4. Install をクリックします。

手順

1. Operator をインストールする前に、テナントの namepsace とは別のテナント Operator の namespace を作成します。これは、プロジェクトを作成することで実行できます。たとえば、テナントの namespace が team1 の場合、team1-operator プロジェクトを作成します。

   $ oc new-project team1-operator

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

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

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

      $ oc create -f team1-operatorgroup.yaml

手順

1. Operator をインストールする前に、目的の Operator をインストールするための namespace を作成します。これは、プロジェクトを作成することで実行できます。このプロジェクトの namespace は、カスタムのグローバル namespace になります。

   $ oc new-project global-operators

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 のみがノードで実行されるようにする必要がある場合、コンピュートマシンセットを使用するか、ノードを直接編集してテイントをノードに追加します。テイントに一致しない新規 Pod がノードにスケジュールされないようにする effect を使用します。たとえば、myoperator:NoSchedule テイントは、テイントに一致しない新規 Pod がノードにスケジュールされないようにしますが、ノードの既存 Pod はそのまま残ります。
3. デフォルトのノードセレクターで設定され、テイントを追加している場合に一致する容認を持つプロジェクトを作成します。

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

手順

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

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

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

手順

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

手順

1. Operators → Installed Operators ページに移動します。
2. スクロールするか、キーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。

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

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

4. Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。

   注記

   このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

手順

1. サブスクライブした Operator の最新バージョン (serverless-operator など) が、currentCSV フィールドで識別されていることを確認します。

   $ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV

   出力例

     currentCSV: serverless-operator.v1.28.0

2. サブスクリプション (serverless-operator など) を削除します。

   $ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless

   出力例

   subscription.operators.coreos.com "serverless-operator" deleted

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

   $ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless

   出力例

   clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" 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 ボリュームマウントを作成します。

   注記

   Operator のデプロイメントは認証局の検証に失敗し、x509 certificate signed by unknown authority エラーが表示される可能性があります。このエラーは、Operator のサブスクリプションの使用時にカスタム CA を挿入した後でも発生する可能性があります。この場合、Operator のサブスクリプションを使用して、trusted-ca の mountPath を /etc/ssl/certs として設定できます。

手順

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 になります。

   出力例

   Name:         cluster-logging
   Namespace:    openshift-logging
   Labels:       operators.coreos.com/cluster-logging.openshift-logging=
   Annotations:  <none>
   API Version:  operators.coreos.com/v1alpha1
   Kind:         Subscription
   # ...
   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
   Labels:       <none>
   Annotations:  operatorframework.io/managed-by: marketplace-operator
                 target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
   API Version:  operators.coreos.com/v1alpha1
   Kind:         CatalogSource
   # ...
   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

   このように編集すると、dedicated-admin ユーザーはアップグレードの準備状況を True に変更できます。

手順

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

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace 1
        annotations:
          olm.catalogImageTemplate: 2
            "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
      spec:
        sourceType: grpc
        grpcPodConfig:
          securityContextConfig: <security_mode> 3
        image: <registry>/<namespace>/<index_image_name>:<tag> 4
        displayName: My Operator Catalog
        publisher: <publisher_name> 5
        updateStrategy:
          registryPoll: 6
            interval: 30m

      1

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

      2

      任意: olm.catalogImageTemplate アノテーションをカタログイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。

      3

      legacy または restricted の値を指定します。フィールドが設定されていない場合、デフォルト値は legacy です。今後の OpenShift Dedicated リリースでは、デフォルト値が restricted になる予定です。restricted 権限でカタログを実行できない場合は、このフィールドを手動で legacy に設定することを推奨します。

      4

      インデックスイメージを指定します。イメージ名の後にタグを指定すると (:v4 など)、カタログソース Pod が Always イメージプルポリシーを使用します。つまり、Pod がコンテナーを起動する前に常にイメージをプルするようになります。@sha256:<id> などのダイジェストを指定した場合、イメージプルポリシーは IfNotPresent になります。これは、イメージがノード上にまだ存在しない場合にのみ、Pod がイメージをプルすることを意味します。

      5

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

      6

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

   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. Web コンソールの Administrator パースペクティブで、Home → Search に移動します。
2. Project: リストからプロジェクトを選択します。
3. Resources リストから CatalogSource を選択します。
4. 削除するカタログの Options メニュー を選択し、Delete CatalogSource をクリックします。

手順

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 になります。

   出力例

   Name:         cluster-logging
   Namespace:    openshift-logging
   Labels:       operators.coreos.com/cluster-logging.openshift-logging=
   Annotations:  <none>
   API Version:  operators.coreos.com/v1alpha1
   Kind:         Subscription
   # ...
   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
   Labels:       <none>
   Annotations:  operatorframework.io/managed-by: marketplace-operator
                 target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
   API Version:  operators.coreos.com/v1alpha1
   Kind:         CatalogSource
   # ...
   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 をリスト表示します。出力には、Operator バージョン、可用性、およびアップタイムの情報が含まれます。

   $ oc get clusteroperators

2. Operator の namespace で実行されている Operator Pod をリスト表示し、Pod のステータス、再起動、および経過時間をリスト表示します。

   $ oc get pod -n <operator_namespace>

3. 詳細な Operator Pod の要約を出力します。

   $ oc describe pod <operator_pod_name> -n <operator_namespace>

手順

1. Operator の namespace で実行されている Operator Pod、Pod のステータス、再起動、および経過時間をリスト表示します。

   $ oc get pods -n <operator_namespace>

2. Operator Pod のログを確認します。

   $ oc logs pod/<pod_name> -n <operator_namespace>

   Operator Pod に複数のコンテナーがある場合、前述のコマンドにより各コンテナーの名前が含まれるエラーが生成されます。個別のコンテナーからログをクエリーします。

   $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>

3. API が機能しない場合には、代わりに SSH を使用して各コントロールプレーンノードで Operator Pod およびコンテナーログを確認します。<master-node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

   1. 各コントロールプレーンノードの Pod をリスト表示します。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods

   2. Operator Pod で Ready ステータスが表示されない場合は、Pod のステータスを詳細に検査します。<operator_pod_id> を直前のコマンドの出力にリスト表示されている Operator Pod の ID に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>

   3. Operator Pod に関連するコンテナーをリスト表示します。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

   4. Ready ステータスが Operator コンテナーに表示されない場合は、コンテナーのステータスを詳細に検査します。<container_id> を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. Ready ステータスが表示されない Operator コンテナーのログを確認します。<container_id> を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Dedicated 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Dedicated API が使用できない場合、または kubelet がターゲットノード上で適切に機能していない場合は、oc 操作が影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

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 ディレクトリーから、Linux 用の最新バージョンの tarball をダウンロードします。

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

   $ tar xvf operator-sdk-v1.31.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. amd64 アーキテクチャーの場合は、amd64 アーキテクチャーの OpenShift ミラーサイト に移動します。
2. 最新の 4 ディレクトリーから、macOS 用の最新バージョンの tarball をダウンロードします。

3. 以下のコマンドを実行して、amd64 アーキテクチャー用の Operator SDK アーカイブを解凍します。

   $ tar xvf operator-sdk-v1.31.0-ocp-darwin-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