Operator

手順

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

2. スクロールするか、またはキーワードを Filter by keyword ボックスに入力し (この場合は Couchbase)、必要な Operator を見つけます。

   図4.1 キーワードによる Operator のフィルター

   
3. Operator を選択します。コミュニティー Operator の場合、Red Hat がそれらの Operator を認定していないことについての警告が出されます。作業を継続する前に、この警告を確認してください。Operator についての情報が表示されます。
4. Operator についての情報を確認してから、Install をクリックします。

5. Create Operator Subscription ページで以下を実行します。

   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. Update Channel を選択します (複数を選択できる場合)。
   3. 前述のように、自動 (Automatic) または 手動 (Manual) の承認ストラテジーを選択します。

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

   1. 手動の承認ストラテジーを選択している場合、Subscription のアップグレードステータスは、その Install Plan を確認し、承認するまで Upgrading のままになります。

      図4.2 Install Plan ページからの手動による承認

      

      Install Plan ページでの承認後に、Subscription のアップグレードステータスは Up to date に移行します。

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

      図4.3 Subscription のアップグレードステータス「 Up to date」

      

7. Subscription のアップグレードステータスが Up to date になった後に、Operators → Installed Operators を選択して、 Couchbase ClusterServiceVersion (CSV) が表示され、その ステータス が最終的に関連する 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
   amq-online                         Red Hat Operators     91m
   amq-streams                        Red Hat Operators     91m
   ...
   couchbase-enterprise-certified     Certified Operators   91m
   mariadb                            Certified Operators   91m
   mongodb-enterprise                 Certified Operators   91m
   ...
   etcd                               Community Operators   91m
   jaeger                             Community Operators   91m
   kubefed                            Community Operators   91m
   ...

   必要な Operator の CatalogSource をメモします。

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

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

3. OperatorGroup は、OperatorGroup と同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択する OLM リソースです。

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

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

   注記

   この手順の 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: <operator_name>
     namespace: openshift-operators 1
   spec:
     channel: alpha
     name: <operator_name> 2
     source: redhat-operators 3
     sourceNamespace: openshift-marketplace 4

   1

   AllNamespaces InstallMode の使用については、openshift-operators namespace を指定します。それ以外の場合は、SingleNamespace InstallMode の使用について関連する単一の namespace を指定します。

   2

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

   3

   Operator を提供する CatalogSource の名前。

   4

   CatalogSource の namespace。デフォルトの OperatorHub CatalogSource には openshift-marketplace を使用します。

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

   $ oc apply -f sub.yaml

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

1. 指定された Subscription オブジェクトは OLM によって選択されます。
2. OLM はこの Subscription に関連する OperatorGroup をフェッチします。
3. OLM は OperatorGroup にサービスアカウントが指定されていることを判別します。
4. OLM はサービスアカウントにスコープが設定されたクライアントを作成し、スコープ設定されたクライアントを使用して Operator をインストールします。これにより、Operator で要求されるパーミッションは常に OperatorGroup のそのサービスアカウントのパーミッションに制限されるようになります。
5. OLM は CSV で指定されたパーミッションセットを使用して新規サービスアカウントを作成し、これを Operator に割り当てます。Operator は割り当てられたサービスアカウントで実行されます。

1. 以下の例のようなフィールドタイプを含む YAML ファイルを作成します。

   CRD の YAML ファイルサンプル

   apiVersion: apiextensions.k8s.io/v1beta1 1
   kind: CustomResourceDefinition
   metadata:
     name: crontabs.stable.example.com 2
   spec:
     group: stable.example.com 3
     version: v1 4
     scope: Namespaced 5
     names:
       plural: crontabs 6
       singular: crontab 7
       kind: CronTab 8
       shortNames:
       - ct 9

   1

   apiextensions.k8s.io/v1beta1 API を使用します。

   2

   定義の名前を指定します。これは group および plural フィールドの値を使用する <plural-name>.<group> 形式である必要があります。

   3

   API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、Job または ScheduledJob などのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.com など) である可能性があります。組織の完全修飾ドメイン名を使用することが奨励されます。

   4

   URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンで存在させることができます。たとえば、v1alpha、v1beta、v1 などが使用されます。

   5

   カスタムオブジェクトがクラスター (Cluster) の 1 つのプロジェクト (Namespaced) またはすべてのプロジェクトで利用可能であるかどうかを指定します。

   6

   URL で使用される複数形の名前を指定します。plural フィールドは API URL のリソースと同じになります。

   7

   CLI および表示用にエイリアスとして使用される単数形の名前を指定します。

   8

   作成できるオブジェクトの種類を指定します。タイプは CamelCase にすることができます。

   9

   CLI でリソースに一致する短い文字列を指定します。

   注記

   デフォルトで、CRD のスコープはクラスターで設定され、すべてのプロジェクトで利用可能です。

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

   $ oc create -f <file_name>.yaml

   新規の RESTful API エンドポイントは以下のように作成されます。

   /apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

   たとえば、サンプルファイルを使用すると、以下のエンドポイントが作成されます。

   /apis/stable.example.com/v1/namespaces/*/crontabs/...

   このエンドポイント URL を使用して CR を作成し、管理できます。オブジェクトの Kind は、作成した CRD オブジェクトの spec.kind フィールドに基づいています。

手順

1. CRD のクラスターロール定義ファイルを作成します。クラスターロール定義は、各クラスターロールに適用されるルールが含まれる YAML ファイルです。OpenShift Container Platform Controller はデフォルトクラスターロールに指定するルールを追加します。

   カスタムロール定義の YAML ファイルサンプル

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1 1
   metadata:
     name: aggregate-cron-tabs-admin-edit 2
     labels:
       rbac.authorization.k8s.io/aggregate-to-admin: "true" 3
       rbac.authorization.k8s.io/aggregate-to-edit: "true" 4
   rules:
   - apiGroups: ["stable.example.com"] 5
     resources: ["crontabs"] 6
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7
   ---
   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: aggregate-cron-tabs-view 8
     labels:
       # Add these permissions to the "view" default role.
       rbac.authorization.k8s.io/aggregate-to-view: "true" 9
       rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10
   rules:
   - apiGroups: ["stable.example.com"] 11
     resources: ["crontabs"] 12
     verbs: ["get", "list", "watch"] 13

   1

   rbac.authorization.k8s.io/v1 API を使用します。

   2 8

   定義の名前を指定します。

   3

   パーミッションを管理のデフォルトロールに付与するためにこのラベルを指定します。

   4

   パーミッションを編集のデフォルトロールに付与するためにこのラベルを指定します。

   5 11

   CRD のグループ名を指定します

   6 12

   これらのルールが適用される CRD の複数形の名前を指定します。

   7 13

   ロールに付与されるパーミッションを表す動詞を指定します。たとえば、読み取りおよび書き込みパーミッションを admin および edit ロールに適用し、読み取り専用パーミッションを view ロールに適用します。

   9

   このラベルを指定して、パーミッションを view デフォルトロールに付与します。

   10

   このラベルを指定して、パーミッションを cluster-reader デフォルトロールに付与します。

2. クラスターロールを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の YAML ファイルを作成します。以下の定義例では、cronSpec と image のカスタムフィールドがKind: CronTab のCR に設定されます。この Kind は、CRD オブジェクトの spec.kind フィールドから取得します。

   CR の YAML ファイルサンプル

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

   2

   CRD にタイプを指定します。

   3

   オブジェクトの名前を指定します。

   4

   オブジェクトのファイナライザーを指定します (ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

   5

   オブジェクトのタイプに固有の条件を指定します。

2. ファイルの作成後に、オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の特定の Kind についての情報を取得するには、以下を実行します。

   $ oc get <kind>

   以下は例になります。

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。以下は例になります。

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. CR の未加工の YAML データを確認することもできます。

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。

手順

1. CR の YAML ファイルを作成します。以下の定義例では、cronSpec と image のカスタムフィールドがKind: CronTab のCR に設定されます。この Kind は、CRD オブジェクトの spec.kind フィールドから取得します。

   CR の YAML ファイルサンプル

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

   2

   CRD にタイプを指定します。

   3

   オブジェクトの名前を指定します。

   4

   オブジェクトのファイナライザーを指定します (ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

   5

   オブジェクトのタイプに固有の条件を指定します。

2. ファイルの作成後に、オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の特定の Kind についての情報を取得するには、以下を実行します。

   $ oc get <kind>

   以下は例になります。

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。以下は例になります。

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. CR の未加工の YAML データを確認することもできます。

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。

手順

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 openapi

   生成される 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 CR について以下の調整 (reconciliation) ロジックを実行します。

      • Memcached Deployment を作成します (ない場合)。
      • Deployment のサイズが、 Memcached CR 仕様で指定されるのと同じであることを確認します。
      • Memcached CR ステータスを 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 に対して実行されますが、イベントハンドラーは各イベントを、Deployment のオーナーの reconcile Request にマップします。この場合、これは Deployment が作成された Memcached オブジェクトです。これにより、コントローラーは Deployment をセカンダリーリソースとして監視できます。

      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: クラスター内の Deployment として実行する。

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

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

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

            $ 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 up local --namespace=default

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

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

   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 の Deployment を作成できることを確認します。

      $ 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. ステータスが memcached 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 が Deployment サイズを変更することを確認します。

      $ 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 olm-catalog gen-csv --csv-version 0.0.1

   注記

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

2. Operator がターゲットとする namespace を指定する OperatorGroup を作成します。以下の OperatorGroup を、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. Operator の CSV マニフェストをクラスターの指定された namespace に適用します。

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

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

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

      $ 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 で実行されるようになります。ユーザーは CustomResources のインスタンス経由で Operator と対話します。この場合、リソースには Memcached の種類が設定されます。ネイティブの Kubernetes RBAC は CustomResources に適用され、管理者には各 Operater と対話できるユーザーへの制御が提供されます。

   この namespace で Memcached のインスタンスを作成することにより、Operator で管理される memcached サーバーを実行する Pod をインスタンス化するために Memcached Operator がトリガーされます。CustomResources をより多く作成すると、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

5. アプリケーションを更新します。

   新規 Operator マニフェストを、古い Operator マニフェストを参照する replaces フィールドを使って作成し、更新を Operator に手動で適用します。OLM は、古い Operator で管理されているすべてのリソースの所有権が、いずれのプログラムも停止することなく新規 Operator に移行できるようにします。新規バージョンの Operator 下で実行するリソースのアップグレードに必要なデータ移行を実行するかどうかは Operator によって異なります。

   以下のコマンドは、新規バージョンの Operator を使用して新規 Operator マニフェストファイルを適用する方法を示し、Pod が実行状態であることを示します。

   $ curl -Lo memcachedoperator.0.0.2.csv.yaml https://raw.githubusercontent.com/operator-framework/getting-started/master/memcachedoperator.0.0.2.csv.yaml
   $ oc apply -f memcachedoperator.0.0.2.csv.yaml
   $ oc get pods
   NAME                                       READY     STATUS    RESTARTS   AGE
   memcached-app-operator-66b5777b79-pnsfj    1/1       Running   0          3s
   memcached-for-drupal-5476487c46-qbd66      1/1       Running   0          14m
   memcached-for-wordpress-65b75fd8c9-7b9x7   1/1       Running   0          14m

手順

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

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

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

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

   • memcached Deployment を作成します (ない場合)。
   • Deployment のサイズが 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 がこの特定のパスを使用するように設定します。デフォルトでは、新規コマンドでロールが置かれる場所への絶対パスが入力されます。

      - 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 イメージを実行する Deployement を作成することにあります (Deployment がない場合)。Ansible 2.7+ は k8s Ansible モジュールをサポートします。 この例では、このモジュールを活用し、Deployment 定義を制御します。

      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 Deployment のレプリカ数を制御しています。この例では、デフォルトを 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 up local

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

         $ operator-sdk up 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 の Deployment を作成できることを確認します。

      $ 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 が Deployment サイズを変更することを確認します。

      $ 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 に設定して監視ファイルを更新します。

   - version: v1
     group: api.example.com
     kind: Foo
     role: /opt/ansible/roles/Foo
     manageStatus: false

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

   - k8s_status:
     api_version: app.example.com/v1
     kind: Foo
     name: "{{ meta.name }}"
     namespace: "{{ meta.namespace }}"
     status:
       foo: bar

手順

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

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

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

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

   • Nginx デプロイメントを作成します (ない場合)。
   • Nginx サービスを作成します (ない場合)。
   • Nginx Ingress を作成します (有効にされているが存在しない場合)。
   • Deployment、Service、およびオプションの 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 テンプレートと共に、Deployment、Service、および 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 up 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 up local

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

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

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

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

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

   nginx-operator が CR の Deployment を作成することを確認します。

   $ 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 が Deployment サイズを変更することを確認します。

   $ 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

手順

1. Operator プロジェクトで、必要な場合に deploy/olm-catalog/csv-config.yaml ファイルを変更して CSV 構成を設定します。

2. CSV を生成します。

   $ operator-sdk olm-catalog gen-csv --csv-version <version>

3. deploy/olm-catalog/ ディレクトリーに生成される新規 CSV で、すべての必須で、手動で定義されたフィールドが適切に設定されていることを確認します。