Operator

手順

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

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

   ヒント

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

   $ oc get csv

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

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

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

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

5. 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

   1

   AllNamespaces インストールモードの使用については、openshift-operators namespace を指定します。それ以外の場合は、SingleNamespace インストールモードの使用について関連する単一の namespace を指定します。

   2

   サブスクライブするチャネルの名前。

   3

   サブスクライブする Operator の名前。

   4

   Operator を提供するカタログソースの名前。

   5

   カタログソースの namespace。デフォルトの OperatorHub カタログソースには openshift-marketplace を使用します。

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

   1

   AllNamespaces インストールモードの使用については、openshift-operators namespace を指定します。それ以外の場合は、SingleNamespace インストールモードの使用について関連する単一の namespace を指定します。

   2

   サブスクライブするチャネルの名前。

   3

   サブスクライブする Operator の名前。

   4

   Operator を提供するカタログソースの名前。

   5

   カタログソースの namespace。デフォルトの OperatorHub カタログソースには openshift-marketplace を使用します。

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

6. Automatic 承認ストラテジーのある Subscription の場合、アップグレードは自動的に開始します。Operators → Installed Operators ページに戻り、アップグレードの進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。

   Manual 承認ストラテジーのある Subscription の場合、Subscription タブからアップグレードを手動で承認できます。

手順

1. OpenShift Container Platform 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 ページからスクロールするか、または Filter by name にキーワードを入力して必要な Operator を見つけます。次に、それをクリックします。

2. Operator Details ページの右側で、Actions ドロップダウンメニューから Uninstall Operator を選択します。

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

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

   Operator、Operator デプロイメントおよび Pod はこのアクションで削除されます。CRD および CR を含む Operator によって管理されるリソースは削除されません。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. 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 セクションを追加します。

   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 を作成します。

   $ 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. 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. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

   $ podman login <registry_host_name>

   また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

   $ oc adm catalog build \
       --appregistry-org redhat-operators \1
       --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
       --filter-by-os="linux/amd64" \3
       --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
       [-a ${REG_CREDS}] \5
       [--insecure] \6
       [--auth-token "${AUTH_TOKEN}"] 7

   1

   App Registry インスタンスからのプルに使用する組織 (namespace)。

   2

   ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--from を ose-operator-registry ベースイメージに設定します。

   3

   --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64、linux/ppc64le、および linux/s390x です。

   4

   カタログイメージに名前を付け、v1 などのタグを追加します。

   5

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   6

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

   7

   オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

   出力例

   INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
   ...
   Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

   無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

   エラーのある出力の例

   ...
   INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
   W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
   Uploading ... 244.9kB/s

   通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

手順

1. disableAllDefaultSources: true を仕様に追加してデフォルトの OperatorSource オブジェクトを無効にします。

   $ oc patch OperatorHub cluster --type json \
       -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

   これにより、OpenShift Container Platform のインストール時にデフォルトで設定されるデフォルトソースが無効になります。

2. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

   • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
   • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

   ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

   $ oc adm catalog mirror \
       <registry_host_name>:<port>/olm/redhat-operators:v1 \1
       <registry_host_name>:<port> \
       [-a ${REG_CREDS}] \2
       [--insecure] \3
       --filter-by-os='.*' \4
       [--manifests-only] 5

   1

   Operator カタログイメージを指定します。

   2

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   3

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

   4

   このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。

   5

   オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。

   警告

   --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

   出力例

   using database path mapping: /:/tmp/190214037
   wrote database to /tmp/190214037
   using database at: /tmp/190214037/bundles.db 1
   ...

   1

   コマンドで生成される一時的なデータベース。

   コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

   • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
   • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。

3. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

   1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

         たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

         $ echo "select * from related_image \
             where operatorbundle_name like 'clusterlogging.4.3%';" \
             | sqlite3 -line /tmp/190214037/bundles.db 1

         1

         oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

         出力例

         image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         
         image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

         たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

         mapping.txt の一致するイメージマッピング。

         registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
         registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

         この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

   2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt

      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

4. ImageContentSourcePolicy オブジェクトを適用します。

   $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml

5. カタログイメージを参照する CatalogSource オブジェクトを作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc

      1

      Operator カタログイメージを指定します。

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

      $ oc create -f catalogsource.yaml

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

   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
      etcd    My Operator Catalog  34s

手順

1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

   $ podman login <registry_host_name>

   また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. Quay.io から redhat-operators カタログをベースに新規カタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

   $ oc adm catalog build \
       --appregistry-org redhat-operators \1
       --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
       --filter-by-os="linux/amd64" \3
       --to=<registry_host_name>:<port>/olm/redhat-operators:v2 \4
       [-a ${REG_CREDS}] \5
       [--insecure] \6
       [--auth-token "${AUTH_TOKEN}"] 7

   1

   App Registry インスタンスからのプルに使用する組織 (namespace)。

   2

   ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--from を ose-operator-registry ベースイメージに設定します。

   3

   --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64、linux/ppc64le、および linux/s390x です。

   4

   カタログイメージに名前を付け、タグを追加します (更新済みのカタログの場合は v2 などのタグ)。

   5

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   6

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

   7

   オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

   出力例

   INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
   ...
   Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v2

3. カタログのコンテンツをターゲットレジストリーに対してミラーリングします。以下の oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成し、イメージをレジストリーにミラーリングします。

   $ oc adm catalog mirror \
       <registry_host_name>:<port>/olm/redhat-operators:v2 \1
       <registry_host_name>:<port> \
       [-a ${REG_CREDS}] \2
       [--insecure] \3
       --filter-by-os='.*' 4

   1

   新規の Operator カタログイメージを指定します。

   2

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   3

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

   4

   このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。--filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

4. 新たに生成されたマニフェストを適用します。

   $ oc apply -f ./redhat-operators-manifests

   重要

   imageContentSourcePolicy.yaml マニフェストを適用する必要がない場合があります。ファイルの diff を完了して、変更が必要かどうかを判断します。

5. カタログイメージを参照する CatalogSource オブジェクトを更新します。

   1. この CatalogSource オブジェクトの元の catalogsource.yaml ファイルがある場合:

      1. catalogsource.yaml ファイルを編集し、spec.image フィールドで新規カタログイメージを参照できるようにします。

         apiVersion: operators.coreos.com/v1alpha1
         kind: CatalogSource
         metadata:
           name: my-operator-catalog
           namespace: openshift-marketplace
         spec:
           sourceType: grpc
           image: <registry_host_name>:<port>/olm/redhat-operators:v2 1
           displayName: My Operator Catalog
           publisher: grpc

         1

         新規の Operator カタログイメージを指定します。

      2. 更新されたファイルを使用して CatalogSource オブジェクトを置き換えます。

         $ oc replace -f catalogsource.yaml

   2. または、以下のコマンドを使用してカタログソースを編集し、spec.image パラメーターで新規カタログイメージを参照します。

      $ oc edit catalogsource <catalog_source_name> -n openshift-marketplace

手順

1. Operator カタログイメージをプルします。

   $ podman pull <registry_host_name>:<port>/olm/redhat-operators:v1

2. イメージを実行します。

   $ podman run -p 50051:50051 \
       -it <registry_host_name>:<port>/olm/redhat-operators:v1

3. grpcurl を使用して利用可能なパッケージの実行中のイメージをクエリーします。

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

   出力例

   {
     "name": "3scale-operator"
   }
   {
     "name": "amq-broker"
   }
   {
     "name": "amq-online"
   }

4. チャネルの最新の Operator バンドルを取得します。

   $  grpcurl -plaintext -d '{"pkgName":"kiali-ossm","channelName":"stable"}' localhost:50051 api.Registry/GetBundleForChannel

   出力例

   {
     "csvName": "kiali-operator.v1.0.7",
     "packageName": "kiali-ossm",
     "channelName": "stable",
   ...

5. イメージのダイジェストを取得します。

   $ podman inspect \
       --format='{{index .RepoDigests 0}}' \
       <registry_host_name>:<port>/olm/redhat-operators:v1

   出力例

   example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3

6. Operator グループが Operator とその依存関係をサポートする namespace my-ns にあることを前提とし、イメージダイジェストを使用して CatalogSource オブジェクトを作成します。以下に例を示します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: custom-redhat-operators
     namespace: my-ns
   spec:
     sourceType: grpc
     image: example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3
     displayName: Red Hat Operators

7. カタログイメージから、利用可能な最新の servicemeshoperator およびその依存関係を解決するサブスクリプションを作成します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: servicemeshoperator
     namespace: my-ns
   spec:
     source: custom-redhat-operators
     sourceNamespace: my-ns
     name: servicemeshoperator
     channel: "1.0"

手順

1. 新規プロジェクトを作成します。

   CLI を使用して新規 memcached-operator プロジェクトを作成します。

   $ mkdir -p $GOPATH/src/github.com/example-inc/

   $ cd $GOPATH/src/github.com/example-inc/

   $ operator-sdk new memcached-operator

   $ cd memcached-operator

2. 新規カスタムリソース定義 (CRD) を追加します。

   1. APIVersion を cache.example.com/v1apha1 に設定し、Kind を Memcached に設定した状態で、CLI を使用して Memcached という新規 CRD API を追加します。

      $ operator-sdk add api \
          --api-version=cache.example.com/v1alpha1 \
          --kind=Memcached

      これにより、pkg/apis/cache/v1alpha1/ の下で Memcached resource API のスキャフォールディングが実行されます。

   2. pkg/apis/cache/v1alpha1/memcached_types.go ファイルで、 Memcached カスタムリソース (CR) の仕様およびステータスを変更します。

      type MemcachedSpec struct {
      	// Size is the size of the memcached deployment
      	Size int32 `json:"size"`
      }
      type MemcachedStatus struct {
      	// Nodes are the names of the memcached pods
      	Nodes []string `json:"nodes"`
      }

   3. *_types.go ファイルを変更後は、以下のコマンドを常に実行し、該当するリソースタイプ用に生成されたコードを更新します。

      $ operator-sdk generate k8s

3. オプション: カスタム検証を CRD に追加します。

   OpenAPI v3.0 スキーマは、マニフェストの生成時に spec.validation ブロックの CRD マニフェストに追加されます。この検証ブロックにより、Kubernetes が作成または更新時に Memcached CR のプロパティーを検証できます。

   さらに、pkg/apis/<group>/<version>/zz_generated.openapi.go ファイルが生成されます。このファイルには、デフォルトで存在する +k8s:openapi-gen=true annotation が Kind 型の宣言の上に存在する場合に、この検証ブロックの Go 表現が含まれます。この自動生成コードは Go の Kind タイプの OpenAPI モデルです。これを使用して完全な OpenAPI 仕様を作成し、クライアントを生成できます。

   Operator の作成者は Kubebuilder マーカー (アノテーション) を使用して API のカスタム検証を設定できます。これらのマーカーには、+kubebuilder:validation 接頭辞が常に必要です。たとえば、以下のマーカーを追加して enum 型の仕様を追加できます。

   // +kubebuilder:validation:Enum=Lion;Wolf;Dragon
   type Alias string

   API コードのマーカーの使用については、Kubebuilder ドキュメントの Generating CRDs および Markers for Config/Code Generation を参照してください。OpenAPIv3 検証マーカーの詳細の一覧については、Kubebuilder ドキュメントの CRD Validation を参照してください。

   カスタム検証を追加する場合は、以下のコマンドを実行し、CRD の deploy/crds/cache.example.com_memcacheds_crd.yaml ファイルの OpenAPI 検証セクションを更新します。

   $ operator-sdk generate crds

   生成される YAML の例

   spec:
     validation:
       openAPIV3Schema:
         properties:
           spec:
             properties:
               size:
                 format: int32
                 type: integer

4. 新規コントローラーを追加します。

   1. 新規コントローラーをプロジェクトに追加し、Memcached リソースを確認し、調整します。

      $ operator-sdk add controller \
          --api-version=cache.example.com/v1alpha1 \
          --kind=Memcached

      これにより、pkg/controller/memcached/ の下で新規コントローラー実装のスキャフォールディングが実行されます。

   2. この例では、生成されたコントローラーファイル pkg/controller/memcached/memcached_controller.go を 実装例 に置き換えます。

      コントローラーのサンプルは、それぞれの Memcached リソースについて以下の調整 (reconciliation) ロジックを実行します。

      • Memcached デプロイメントを作成します (ない場合)。
      • Deployment のサイズが、 Memcached CR 仕様で指定されるのと同じであることを確認します。
      • Memcached リソースのステータスを Memcached Pod の名前で更新します。

      次の 2 つのサブステップでは、コントローラーがリソースを監視する方法および調整ループがトリガーされる方法を検査します。これらの手順を省略し、直接 Operator のビルドおよび実行に進むことができます。

   3. pkg/controller/memcached/memcached_controller.go ファイルでコントローラーの実装を検査し、コントローラーのリソースの監視方法を確認します。

      最初の監視は、プライマリーソースとしての Memcached タイプに対して実行します。それぞれの Add、Update、または Delete イベントについて、reconcile ループに Memcached オブジェクトの reconcile Request (<namespace>:<name> キー) が送られます。

      err := c.Watch(
        &source.Kind{Type: &cachev1alpha1.Memcached{}}, &handler.EnqueueRequestForObject{})

      次の監視は、Deployment オブジェクトに対して実行されますが、イベントハンドラーは各イベントを、デプロイメントのオーナーの reconcile (調整) Request にマップします。この場合、これはデプロイメントが作成された Memcached オブジェクトです。これにより、コントローラーはデプロイメントをセカンダリーリソースとして監視できます。

      err := c.Watch(&source.Kind{Type: &appsv1.Deployment{}}, &handler.EnqueueRequestForOwner{
      		IsController: true,
      		OwnerType:    &cachev1alpha1.Memcached{},
      	})

   4. すべてのコントローラーには、reconcile ループを実装する Reconcile() メソッドのある Reconciler オブジェクトがあります。この reconcile ループには、キャッシュからプライマリーリソースオブジェクトの Memcached を検索するために使用される <namespace>:<name> キーである Request 引数が渡されます。

      func (r *ReconcileMemcached) Reconcile(request reconcile.Request) (reconcile.Result, error) {
        // Lookup the Memcached instance for this reconcile request
        memcached := &cachev1alpha1.Memcached{}
        err := r.client.Get(context.TODO(), request.NamespacedName, memcached)
        ...
      }

      Reconcile() 関数の返り値に応じて、reconcile Request は再度キューに入れられ、ループが再びトリガーされる可能性があります。

      // Reconcile successful - don't requeue
      return reconcile.Result{}, nil
      // Reconcile failed due to error - requeue
      return reconcile.Result{}, err
      // Requeue for any reason other than error
      return reconcile.Result{Requeue: true}, nil

5. Operator をビルドし、実行します 。

   1. Operator の実行前に、CRD を Kubernetes API サーバーに再度登録する必要があります。

      $ oc create \
          -f deploy/crds/cache_v1alpha1_memcached_crd.yaml

   2. CRD の登録後に、Operator を実行するための 2 つのオプションを選択できます。

      • Kubernetes クラスター内の Deployment を使用
      • クラスター内の Go プログラムを使用

      以下の方法のいずれかを選択します。

      1. オプション A: クラスター内のデプロイメントとして実行する。

         1. memcached-operator イメージをビルドし、これをレジストリーにプッシュします。

            $ operator-sdk build quay.io/example/memcached-operator:v0.0.1

         2. デプロイメントマニフェストは deploy/operator.yaml に生成されます。デフォルトはプレースホルダーでしかないため、以下のようにデプロイメントイメージを更新します。

            $ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml

         3. 次のステップについての quay.io にアカウントがあることを確認するか、または優先しているコンテナーレジストリーで置き換えます。レジストリーには、memcached-operator という名前の 新規パブリックイメージ リポジトリーを作成します。

         4. イメージをレジストリーにプッシュします。

            $ podman push quay.io/example/memcached-operator:v0.0.1

         5. RBAC をセットアップし、memcached-operator マニフェストを作成します。

            $ oc create -f deploy/role.yaml

            $ oc create -f deploy/role_binding.yaml

            $ oc create -f deploy/service_account.yaml

            $ oc create -f deploy/operator.yaml

         6. memcached-operator デプロインが稼働していることを確認します。

            $ oc get deployment

            出力例

            NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
            memcached-operator       1         1         1            1           1m

      2. オプション B: クラスター外でローカルに実行する。

         この方法は、迅速にデプロイメントおよびテストを実行するための開発サイクルで優先される方法です。

         $HOME/.kube/config にあるデフォルトの Kubernetes 設定ファイルを使用して Operator をローカルで実行します。

         $ operator-sdk run --local --namespace=default

         フラグ --kubeconfig=<path/to/kubeconfig> を使用して特定の kubeconfig を使用できます。

6. Memcached CR を作成して、Operator が Memcached アプリケーションをデプロイできることを確認します。

   1. deploy/crds/cache_v1alpha1_memcached_cr.yaml で生成された Memcached CR のサンプルを作成します。

   2. ファイルを表示します。

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      出力例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 3

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

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   4. memcached-operator が CR のデプロイメントを作成できることを確認します。

      $ oc get deployment

      出力例

      NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator       1         1         1            1           2m
      example-memcached        3         3         3            3           1m

   5. CR ステータスが Pod 名で更新されていることを確認するために、Pod および CR を確認します。

      $ oc get pods

      出力例

      NAME                                  READY     STATUS    RESTARTS   AGE
      example-memcached-6fd7c98d8-7dqdr     1/1       Running   0          1m
      example-memcached-6fd7c98d8-g5k7v     1/1       Running   0          1m
      example-memcached-6fd7c98d8-m7vn7     1/1       Running   0          1m
      memcached-operator-7cc7cfdf86-vvjqk   1/1       Running   0          2m

      $ oc get memcached/example-memcached -o yaml

      出力例

      apiVersion: cache.example.com/v1alpha1
      kind: Memcached
      metadata:
        clusterName: ""
        creationTimestamp: 2018-03-31T22:51:08Z
        generation: 0
        name: example-memcached
        namespace: default
        resourceVersion: "245453"
        selfLink: /apis/cache.example.com/v1alpha1/namespaces/default/memcacheds/example-memcached
        uid: 0026cc97-3536-11e8-bd83-0800274106a1
      spec:
        size: 3
      status:
        nodes:
        - example-memcached-6fd7c98d8-7dqdr
        - example-memcached-6fd7c98d8-g5k7v
        - example-memcached-6fd7c98d8-m7vn7

7. デプロイメントのサイズを更新し、Operator がデプロイ済みの Memcached アプリケーションを管理できることを確認します 。

   1. memcached CR の spec.size フィールドを 3 から 4 に変更します。

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      出力例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 4

   2. 変更を適用します。

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   3. Operator がデプロイメントサイズを変更することを確認します。

      $ oc get deployment

      出力例

      NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      example-memcached    4         4         4            4           5m

8. リソースをクリーンアップします。

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_crd.yaml

   $ oc delete -f deploy/operator.yaml

   $ oc delete -f deploy/role.yaml

   $ oc delete -f deploy/role_binding.yaml

   $ oc delete -f deploy/service_account.yaml

手順

1. Operator マニフェストを生成します 。

   Operator マニフェストは、アプリケーションを表示し、作成し、管理する方法について説明します (この場合は Memcached)。これは ClusterServiceVersion (CSV) オブジェクトで定義され、OLM が機能するために必要です。

   Memcached Operator のビルド時に作成された memcached-operator/ ディレクトリーから CSV を生成します。

   $ operator-sdk generate csv --csv-version 0.0.1

   注記

   マニフェストファイルの手動による定義についての詳細は、Building a CSV for the Operator Framework を参照してください。

2. Operator がターゲットとする namespace を指定する Operator グループを作成します。以下の Operator グループを、CSV を作成する namespace に作成します。この例では、default namespace が使用されます。

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: memcached-operator-group
     namespace: default
   spec:
     targetNamespaces:
     - default

3. Operator をデプロイします。これらのファイルは、Memcached Operator のビルド時に Operator SDK よって deploy/ ディレクトリーに生成されたファイルを使用します。

   1. 各カスタムリソース定義 (CRD) kind の displayName フィールドを spec.customresourcedefinitions.owned セクションに追加して、生成される CSV マニフェストファイルを編集します。

      deploy/olm-catalog/memcached-operator/0.0.1/memcached-operator.v0.0.1.clusterserviceversion.yaml ファイル

      ...
      spec:
        customresourcedefinitions:
          owned:
          - kind: Memcached
            name: memcacheds.cache.example.com
            version: v1alpha1
            description: Memcached is the Schema for the memcacheds API
            displayName: Memcached 1
      ...

      1

      CRD の表示名を指定します。

   2. CSV マニフェストをクラスターの指定された namespace に適用します。

      $ oc apply -f deploy/olm-catalog/memcached-operator/0.0.1/memcached-operator.v0.0.1.clusterserviceversion.yaml

      このマニフェストを適用する際に、クラスターはマニフェストで指定された要件を満たしていないためにすぐに更新を実行しません。

   3. リソースパーミッションを Operator に付与するためにロール、ロールバインディング、およびサービスアカウントを作成し、Operator が管理する Memcached カスタムリソースを作成するためにカスタムリソース定義 (CRD) を作成します。

      $ oc create -f deploy/crds/cache.example.com_memcacheds_crd.yaml

      $ oc create -f deploy/service_account.yaml

      $ oc create -f deploy/role.yaml

      $ oc create -f deploy/role_binding.yaml

      マニフェストの適用時に OLM は Operator を特定の namespace に作成するため、管理者は、Operator をインストールできるユーザーを制限するためのネイティブの Kubernetes RBAC パーミッションモデルを利用できます。

4. アプリケーションインスタンスを作成します 。

   Memcached Operator が default namespace で実行されるようになります。ユーザーはカスタムリソースのインスタンス経由で Operator と対話します。この場合、リソースには Memcached の種類が設定されます。ネイティブの Kubernetes RBAC はカスタムリソースに適用され、管理者は各 Operater と対話できるユーザーへの制御が可能になります。

   この namespace で Memcached オブジェクトのインスタンスを作成することにより、Operator で管理される memcached サーバーを実行する Pod をインスタンス化するために Memcached Operator がトリガーされます。カスタムリソースをより多く作成すると、Memcached アプリケーションのより多くの固有なインスタンスがこの namespace で実行されている Memcached Operator によって管理されます。

   $ cat <<EOF | oc apply -f -
   apiVersion: "cache.example.com/v1alpha1"
   kind: "Memcached"
   metadata:
     name: "memcached-for-wordpress"
   spec:
     size: 1
   EOF

   $ cat <<EOF | oc apply -f -
   apiVersion: "cache.example.com/v1alpha1"
   kind: "Memcached"
   metadata:
     name: "memcached-for-drupal"
   spec:
     size: 1
   EOF

   $ oc get Memcached

   出力例

   NAME                      AGE
   memcached-for-drupal      22s
   memcached-for-wordpress   27s

   $ oc get pods

   出力例

   NAME                                       READY     STATUS    RESTARTS   AGE
   memcached-app-operator-66b5777b79-pnsfj    1/1       Running   0          14m
   memcached-for-drupal-5476487c46-qbd66      1/1       Running   0          3s
   memcached-for-wordpress-65b75fd8c9-7b9x7   1/1       Running   0          8s

手順

1. 新規 Operator プロジェクトを作成します。namespace スコープの Operator は単一 namespace でリソースを監視し、管理します。namespace スコープの Operator は柔軟性があるために優先して使用されます。これらの Operator は切り離されたアップグレード、障害対応およびモニターリングのための namespace の分離、および API 定義の差異化を可能にします。

   新規の Ansible ベース、namespace スコープの memcached-operator プロジェクトを作成し、新規ディレクトリーに切り換えるには、以下のコマンドを使用します。

   $ operator-sdk new memcached-operator \
       --api-version=cache.example.com/v1alpha1 \
       --kind=Memcached \
       --type=ansible

   $ cd memcached-operator

   これにより、とくに API バージョン example.com/v1apha1 および Kind Memcached の Memcached リソースを監視するための memcached-operator プロジェクトが作成されます。

2. Operator ロジックをカスタマイズします。

   この例では、memcached-operator はそれぞれの Memcached カスタムリソース (CR) について以下の調整 (reconciliation) ロジックを実行します。

   • memcached デプロイメントを作成します (ない場合)。
   • デプロイメントのサイズが Memcached CR で指定されるのと同じであることを確認します。

   デフォルトで、memcached-operator は watches.yaml ファイルに示されるように Memcached リソースイベントを監視し、Ansible ロール Memcached を実行します。

   - version: v1alpha1
     group: cache.example.com
     kind: Memcached

   オプションで、以下のロジックを watches.yaml ファイルでカスタマイズできます。

   1. role オプションを指定して、ansible-runner を Ansible ロールを使って起動する際に Operator がこの特定のパスを使用するように設定します。デフォルトで、operator-sdk new コマンドでは、ロールが置かれる場所への絶対パスを入力します。

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        role: /opt/ansible/roles/memcached

   2. playbook オプションを watches.yaml ファイルに指定して、ansible-runner を Ansible Playbook で起動する際に Operator がこの指定されたパスを使用するように設定します。

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        playbook: /opt/ansible/playbook.yaml

3. Memcached Ansible ロールをビルドします。

   生成された Ansible ロールを roles/memcached/ ディレクトリーの下で変更します。この Ansible ロールは、リソースの変更時に実行されるロジックを制御します。

   1. Memcached 仕様を定義します。

      Ansible ベースの Operator の定義は Ansible 内ですべて実行できます。Ansible Operator は CR 仕様フィールドのすべてのキー/値ペアを 変数 として Ansible に渡します。仕様フィールドのすべての変数の名前は、Ansible の実行前に Operator によってスネークケース (小文字 + アンダースコア) に変換されます。たとえば、仕様の serviceAccount は Ansible では service_account になります。

      ヒント

      Ansible で変数についてのタイプの検証を実行し、アプリケーションが予想される入力を受信できることを確認する必要があります。

      ユーザーが spec フィールドを設定しない場合、 roles/memcached/defaults/main.yml ファイルを変更してデフォルトを設定します。

      size: 1

   2. Memcached デプロイメントを定義します。

      Memcached 仕様が定義された状態で、リソースの変更に対する Ansible の実行内容を定義できます。これは Ansible ロールであるため、デフォルトの動作は roles/memcached/tasks/main.yml ファイルでタスクを実行します。

      ここでの目的は、Ansible で memcached:1.4.36-alpine イメージを実行するデプロイメントを作成することにあります (デプロイメントがない場合)。Ansible 2.7+ は k8s Ansible モジュール をサポートします。この例では、このモジュールを活用し、デプロイメントの定義を制御します。

      roles/memcached/tasks/main.yml を以下に一致するように変更します。

      - name: start memcached
        k8s:
          definition:
            kind: Deployment
            apiVersion: apps/v1
            metadata:
              name: '{{ meta.name }}-memcached'
              namespace: '{{ meta.namespace }}'
            spec:
              replicas: "{{size}}"
              selector:
                matchLabels:
                  app: memcached
              template:
                metadata:
                  labels:
                    app: memcached
                spec:
                  containers:
                  - name: memcached
                    command:
                    - memcached
                    - -m=64
                    - -o
                    - modern
                    - -v
                    image: "docker.io/memcached:1.4.36-alpine"
                    ports:
                      - containerPort: 11211

      注記

      この例では、size 変数を使用し、 Memcached デプロイメントのレプリカ数を制御しています。この例では、デフォルトを 1 に設定しますが、任意のユーザーがこのデフォルトを上書きする CR を作成することができます。

4. CRD をデプロイします。

   Operator の実行前に、Kubernetes は Operator が監視する新規カスタムリソース定義 (CRD) について把握している必要があります。Memcached CRD をデプロイします。

   $ oc create -f deploy/crds/cache.example.com_memcacheds_crd.yaml

5. Operator をビルドし、実行します 。

   Operator をビルドし、実行する方法として 2 つの方法を使用できます。

   • Kubernetes クラスター内の Pod を使用
   • operator-sdk up コマンドを使用してクラスター外で Go プログラムを使用

   以下の方法のいずれかを選択します。

   1. Kubernetes クラスター内で Pod として実行 します。これは実稼働環境での優先される方法です。

      1. memcached-operator イメージをビルドし、これをレジストリーにプッシュします。

         $ operator-sdk build quay.io/example/memcached-operator:v0.0.1

         $ podman push quay.io/example/memcached-operator:v0.0.1

      2. Deployment マニフェストは deploy/operator.yaml ファイルに生成されます。このファイルの Deployment イメージは、プレースホルダー REPLACE_IMAGE から直前にビルドされたイメージに変更される必要があります。これを実行するには、以下を実行します。

         $ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml

      3. memcached-operator マニフェストをデプロイします。

         $ oc create -f deploy/service_account.yaml

         $ oc create -f deploy/role.yaml

         $ oc create -f deploy/role_binding.yaml

         $ oc create -f deploy/operator.yaml

      4. memcached-operator デプロイメントが稼働していることを確認します。

         $ oc get deployment

         NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
         memcached-operator       1         1         1            1           1m

   2. クラスター外で実行します。この方法は、デプロイメントおよびテストの速度を上げるために開発サイクル時に優先される方法です。

      Ansible Runner および Ansible Runner HTTP プラグインがインストールされていることを確認します。 インストールされていない場合、CR の作成時に Ansible Runner から予想しないエラーが発生します。

      さらに、watches.yaml ファイルで参照されるロールパスがマシン上にある必要があります。通常、コンテナーはディスク上のロールが置かれる場所で使用されるため、ロールは設定済みの Ansible ロールパス (例: /etc/ansible/roles) に手動でコピーされる必要があります。

      1. $HOME/.kube/config にあるデフォルトの Kubernetes 設定ファイルを使って Operator をローカルに実行するには、以下を実行します。

         $ operator-sdk run --local

         提供された Kubernetes 設定ファイルを使って Operator をローカルに実行するには、以下を実行します。

         $ operator-sdk run --local --kubeconfig=config

6. Memcached CR を作成します。

   1. 以下に示されるように deploy/crds/cache_v1alpha1_memcached_cr.yaml ファイルを変更し、 Memcached CR を作成します。

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      出力例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 3

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. memcached-operator が CR のデプロイメントを作成できることを確認します。

      $ oc get deployment

      出力例

      NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator       1         1         1            1           2m
      example-memcached        3         3         3            3           1m

   3. Pod で 3 つのレプリカが作成されていることを確認します。

      $ oc get pods

      NAME                                  READY     STATUS    RESTARTS   AGE
      example-memcached-6fd7c98d8-7dqdr     1/1       Running   0          1m
      example-memcached-6fd7c98d8-g5k7v     1/1       Running   0          1m
      example-memcached-6fd7c98d8-m7vn7     1/1       Running   0          1m
      memcached-operator-7cc7cfdf86-vvjqk   1/1       Running   0          2m

7. サイズを更新します。

   1. memcached CR の spec.size フィールドを 3 から 4 に変更し、変更を適用します。

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      出力例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 4

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. Operator がデプロイメントサイズを変更することを確認します。

      $ oc get deployment

      出力例

      NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      example-memcached    4         4         4            4           5m

8. リソースをクリーンアップします。

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   $ oc delete -f deploy/operator.yaml

   $ oc delete -f deploy/role_binding.yaml

   $ oc delete -f deploy/role.yaml

   $ oc delete -f deploy/service_account.yaml

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_crd.yaml

手順

1. CR ステータスをアプリケーションから手動で追跡するには、manageStatus フィールドを false に設定して watches.yaml ファイルを更新します。

   - version: v1
     group: api.example.com
     kind: Test1
     role: Test1
     manageStatus: false

2. operator_sdk.util.k8s_status Ansible モジュールを使用してサブリソースを更新します。たとえば、キー test1 および値 test2 を使用して更新するには、operator_sdk.util を以下のように使用することができます。

   - operator_sdk.util.k8s_status:
       api_version: app.example.com/v1
       kind: Test1
       name: "{{ meta.name }}"
       namespace: "{{ meta.namespace }}"
       status:
         test1: test2

   コレクションは、新たにスキャフォールディングされた Ansible Operator に含まれるロールの meta/main.yml で宣言することもできます。

   collections:
     - operator_sdk.util

   ロールのメタでコレクションを宣言すると、k8s_status モジュールを直接起動することができます。

   k8s_status:
     <snip>
     status:
       test1: test2

手順

1. 新規 Operator プロジェクトを作成します。namespace スコープの Operator は単一 namespace でリソースを監視し、管理します。namespace スコープの Operator は柔軟性があるために優先して使用されます。これらの Operator は切り離されたアップグレード、障害対応およびモニタリングのための namespace の分離、および API 定義の差異化を可能にします。

   新規の Helm ベース、namespace スコープの nginx-operator プロジェクトを作成するには、以下のコマンドを使用します。

   $ operator-sdk new nginx-operator \
     --api-version=example.com/v1alpha1 \
     --kind=Nginx \
     --type=helm

   $ cd nginx-operator

   これにより、とりわけ API バージョン example.com/v1apha1 および Kind Nginx の Nginx リソースを監視する目的で nginx-operator プロジェクトが作成されます。

2. Operator ロジックをカスタマイズします。

   この例では、nginx-operator はそれぞれの Nginx カスタムリソース (CR) について以下の調整 (reconciliation) ロジックを実行します。

   • Nginx デプロイメントを作成します (ない場合)。
   • Nginx サービスを作成します (ない場合)。
   • Nginx Ingress を作成します (有効にされているが存在しない場合)。
   • デプロイメント、サービス、およびオプションの Ingress が Nginx CR で指定される必要な設定 (レプリカ数、イメージ、サービスタイプなど) に一致することを確認します。

   デフォルトで、nginx-operator は watches.yaml ファイルに示されるように Nginx リソースイベントを監視し、指定されたチャートを使用して Helm リリースを実行します。

   - version: v1alpha1
     group: example.com
     kind: Nginx
     chart: /opt/helm/helm-charts/nginx

   1. Nginx Helm チャートを確認します。

      Helm Operator プロジェクトの作成時に、Operator SDK は、単純な Nginx リリース用のテンプレートセットが含まれる Helm チャートのサンプルを作成します。

      この例では、Helm チャート開発者がリリースについての役立つ情報を伝えるために使用する NOTES.txt テンプレートと共に、デプロイメント、サービス、および Ingress リソース用にテンプレートを利用できます。

      Helm チャートの使用に慣れていない場合は、Helm Chart 開発者用のドキュメント を参照してください。

   2. Nginx CR 仕様を確認します。

      Helm は 値 (value) という概念を使用して、Helm チャートの values.yaml ファイルに定義される Helm チャートのデフォルトをカスタマイズします。

      CR 仕様に必要な値を設定し、これらのデフォルトを上書きします。例としてレプリカ数を使用することができます。

      1. まず、helm-charts/nginx/values.yaml ファイルで、チャートに replicaCount という値が含まれ、これがデフォルトで 1 に設定されていることを検査します。デプロイメントに 2 つの Nginx インスタンスを設定するには、CR 仕様に replicaCount: 2 が含まれる必要があります。

         deploy/crds/example.com_v1alpha1_nginx_cr.yaml ファイルを以下のように更新します。

         apiVersion: example.com/v1alpha1
         kind: Nginx
         metadata:
           name: example-nginx
         spec:
           replicaCount: 2

      2. 同様に、デフォルトのサービスポートは 80 に設定されます。8080 を代わりに使用するには、サービスポートの上書きを追加して deploy/crds/example.com_v1alpha1_nginx_cr.yaml ファイルを再度更新します。

         apiVersion: example.com/v1alpha1
         kind: Nginx
         metadata:
           name: example-nginx
         spec:
           replicaCount: 2
           service:
             port: 8080

         Helm Operator は、helm install -f ./overrides.yaml コマンドが機能するように、仕様全体を values ファイルの内容のように適用します。

3. CRD をデプロイします。

   Operator の実行前に、Kubernetes は Operator が監視する新規カスタムリソース定義 (CRD) について把握している必要があります。以下の CRD をデプロイします。

   $ oc create -f deploy/crds/example_v1alpha1_nginx_crd.yaml

4. Operator をビルドし、実行します 。

   Operator をビルドし、実行する方法として 2 つの方法を使用できます。

   • Kubernetes クラスター内の Pod を使用
   • operator-sdk up コマンドを使用してクラスター外で Go プログラムを使用

   以下の方法のいずれかを選択します。

   1. Kubernetes クラスター内で Pod として実行 します。これは実稼働環境での優先される方法です。

      1. nginx-operator イメージをビルドし、これをレジストリーにプッシュします。

         $ operator-sdk build quay.io/example/nginx-operator:v0.0.1

         $ podman push quay.io/example/nginx-operator:v0.0.1

      2. Deployment マニフェストは deploy/operator.yaml ファイルに生成されます。このファイルの Deployment イメージは、プレースホルダー REPLACE_IMAGE から直前にビルドされたイメージに変更される必要があります。これを実行するには、以下を実行します。

         $ sed -i 's|REPLACE_IMAGE|quay.io/example/nginx-operator:v0.0.1|g' deploy/operator.yaml

      3. nginx-operator マニフェストをデプロイします。

         $ oc create -f deploy/service_account.yaml

         $ oc create -f deploy/role.yaml

         $ oc create -f deploy/role_binding.yaml

         $ oc create -f deploy/operator.yaml

      4. nginx-operator デプロイメントが稼働していることを確認します。

         $ oc get deployment

         出力例

         NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
         nginx-operator       1         1         1            1           1m

   2. クラスター外で実行します。この方法は、デプロイメントおよびテストの速度を上げるために開発サイクル時に優先される方法です。

      watches.yaml ファイルで参照されるチャートパスがマシン上に存在している必要があります。デフォルトで、 watches.yaml ファイルは operator-sdk build コマンドでビルドされる Operator イメージを使用できるようにスキャフォールディングされます。Operator を operator-sdk run --local コマンドで開発し、テストする場合、SDK はローカルファイルシステムでこのパスを検索します。

      1. この場所に、Helm チャートのパスを参照するシンボリックリンクを作成します。

         $ sudo mkdir -p /opt/helm/helm-charts

         $ sudo ln -s $PWD/helm-charts/nginx /opt/helm/helm-charts/nginx

      2. $HOME/.kube/config にあるデフォルトの Kubernetes 設定ファイルを使って Operator をローカルに実行するには、以下を実行します。

         $ operator-sdk run --local

         提供された Kubernetes 設定ファイルを使って Operator をローカルに実行するには、以下を実行します。

         $ operator-sdk run --local --kubeconfig=<path_to_config>

5. Nginx CR をデプロイします。

   これまでに変更した Nginx CR を適用します。

   $ oc apply -f deploy/crds/example.com_v1alpha1_nginx_cr.yaml

   nginx-operator が CR のデプロイメントを作成することを確認します。

   $ oc get deployment

   出力例

   NAME                                           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   example-nginx-b9phnoz9spckcrua7ihrbkrt1        2         2         2            2           1m

   Pod で 2 つのレプリカが作成されていることを確認します。

   $ oc get pods

   出力例

   NAME                                                      READY     STATUS    RESTARTS   AGE
   example-nginx-b9phnoz9spckcrua7ihrbkrt1-f8f9c875d-fjcr9   1/1       Running   0          1m
   example-nginx-b9phnoz9spckcrua7ihrbkrt1-f8f9c875d-ljbzl   1/1       Running   0          1m

   サービスポートが 8080 に設定されていることを確認します。

   $ oc get service

   出力例

   NAME                                      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
   example-nginx-b9phnoz9spckcrua7ihrbkrt1   ClusterIP   10.96.26.3   <none>        8080/TCP   1m

6. replicaCount を更新し、ポートを削除します。

   spec.replicaCount フィールドを 2 から 3 に変更し、spec.service フィールドを削除して、変更を適用します。

   $ cat deploy/crds/example.com_v1alpha1_nginx_cr.yaml

   出力例

   apiVersion: "example.com/v1alpha1"
   kind: "Nginx"
   metadata:
     name: "example-nginx"
   spec:
     replicaCount: 3

   $ oc apply -f deploy/crds/example.com_v1alpha1_nginx_cr.yaml

   Operator がデプロイメントサイズを変更することを確認します。

   $ oc get deployment

   出力例

   NAME                                           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   example-nginx-b9phnoz9spckcrua7ihrbkrt1        3         3         3            3           1m

   サービスポートがデフォルトの 80 に設定されていることを確認します。

   $ oc get service

   出力例

   NAME                                      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
   example-nginx-b9phnoz9spckcrua7ihrbkrt1   ClusterIP   10.96.26.3   <none>        80/TCP   1m

7. リソースをクリーンアップします。

   $ oc delete -f deploy/crds/example.com_v1alpha1_nginx_cr.yaml

   $ oc delete -f deploy/operator.yaml

   $ oc delete -f deploy/role_binding.yaml

   $ oc delete -f deploy/role.yaml

   $ oc delete -f deploy/service_account.yaml

   $ oc delete -f deploy/crds/example_v1alpha1_nginx_crd.yaml