第4章 Operator の開発


4.1. Operator SDK の使用を開始する

以下では、Operator SDK の基本事項についての概要を説明し、単純な Go ベースの Memcached Operator のビルドおよびインストールからアップグレードまでのそのライフサイクル管理の例を使って、(OpenShift Container Platform などの) クラスター管理者の Kubernetes ベースのクラスターへのアクセスを持つ Operator の作成者を支援します。

これは、Operator SDK (operator-sdk CLI ツールおよび controller-runtime ライブラリー API) と Operator Lifecycle Manager (OLM) という 2 つの Operator Framework の重要な設定要素を使用して実行されます。

注記

OpenShift Container Platform 4.5 は Operator SDK v0.17.2 をサポートします。

4.1.1. Operator SDK のアーキテクチャー

Operator FrameworkOperator という Kubernetes ネイティブアプリケーションを効果的かつ自動化された拡張性のある方法で管理するためのオープンソースツールキットです。Operator は、プロビジョニング、スケーリング、バックアップおよび復元などのクラウドサービスの自動化の利点を提供し、同時に Kubernetes が実行されるいずれの場所でも実行できます。

Operator により、Kubernetes の上部に複雑で、ステートフルなアプリケーションを管理することが容易になります。ただし、現時点で Operator の作成は、低レベルの API の使用、スケルトンコードの作成、モジュール化の欠如による重複の発生などの課題があるために困難になる場合があります。

Operator SDK は、以下を提供して Operator をより容易に作成できるように設計されたフレームワークです。

  • 運用ロジックをより直感的に作成するための高レベルの API および抽象化
  • 新規プロジェクトを迅速にブートストラップするためのスケルトンコードの作成およびコード生成ツール
  • 共通する Operator ユースケースに対応する拡張機能

4.1.1.1. ワークフロー

Operator SDK は、新規 Operator を開発するために以下のワークフローを提供します。

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

図4.1 Operator SDK ワークフロー

osdk ワークフロー

高次元では、Operator SDK を使用する Operator は Operator の作成者が定義するハンドラーで監視対象のリソースについてのイベントを処理し、アプリケーションの状態を調整するための動作を実行します。

4.1.1.2. マネージャーファイル

Operator の主なプログラムは、cmd/manager/main.go のマネージャーファイルです。マネージャーは、pkg/apis/ で定義されるすべてのカスタムリソース (CR) のスキームを自動的に登録し、pkg/controller/ 下のすべてのコントローラーを実行します。

マネージャーは、すべてのコントローラーがリソースの監視に使用する namespace を制限できます。

mgr, err := manager.New(cfg, manager.Options{Namespace: namespace})

デフォルトでは、これは Operator が実行されている namespace です。すべての namespace を確認するには、namespace オプションのオプションを空のままにすることができます。

mgr, err := manager.New(cfg, manager.Options{Namespace: ""})

4.1.1.3. Prometheus Operator のサポート

Prometheus はオープンソースのシステムモニタリングおよびアラートツールキットです。Prometheus Operator は、 OpenShift Container Platform などの Kubernetes ベースのクラスターで実行される Prometheus クラスターを作成し、設定し、管理します。

ヘルパー関数は、デフォルトで Operator SDK に存在し、Prometheus Operator がデプロイされているクラスターで使用できるように生成された Go ベースの Operator にメトリクスを自動的にセットアップします。

4.1.2. Operator SDK CLI のインストール

Operator SDK には、開発者による新規 Operator プロジェクトの作成、ビルドおよびデプロイを支援をする CLI ツールが含まれます。ワークステーションに SDK CLI をインストールして、独自の Operator のオーサリングを開始することができます。

注記

以下では、ローカル Kubernetes クラスターとしての minikube v0.25.0+ とパブリックレジストリーの quay.io を使用します。

4.1.2.1. GitHub リリースからのインストール

GitHub のプロジェクトから Operator SDK CLI の事前ビルドリリースのバイナリーをダウンロードし、インストールできます。

前提条件

  • Go v1.13+
  • docker v17.03+、podman v1.2.0+、または buildah v1.7+
  • OpenShift CLI (oc) v4.5+ (インストール済み)
  • Kubernetes v1.12.0+ に基づくクラスターへのアクセス
  • コンテナーレジストリーへのアクセス

手順

  1. リリースバージョン変数を設定します。

    $ RELEASE_VERSION=v0.17.2
  2. リリースバイナリーをダウンロードします。

    • Linux の場合

      $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu
    • macOS の場合

      $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin
  3. ダウンロードしたリリースのバイナリーを確認します。

    1. 提供された .asc ファイルをダウンロードします。

      • Linux の場合

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc
      • macOS の場合

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc
    2. バイナリーと対応する .asc ファイルを同じディレクトリーに置き、以下のコマンドを実行してバイナリーを確認します。

      • Linux の場合

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc
      • macOS の場合

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc

      保守管理者のパブリックキーがワークステーションにない場合は、以下のエラーが出されます。

      エラーのある出力例

      $ gpg: assuming signed data in 'operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin'
      $ gpg: Signature made Fri Apr  5 20:03:22 2019 CEST
      $ gpg:                using RSA key <key_id> 1
      $ gpg: Can't check signature: No public key

      1
      RSA キー文字列。

      キーをダウンロードするには、以下のコマンドを実行し、 <key_id> を直前のコマンドの出力で提供された RSA キー文字列に置き換えます。

      $ gpg [--keyserver keys.gnupg.net] --recv-key "<key_id>" 1
      1
      キーサーバーが設定されていない場合、これを --keyserver オプションで指定します。
  4. リリースバイナリーを PATH にインストールします。

    • Linux の場合

      $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu
      $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu /usr/local/bin/operator-sdk
      $ rm operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu
    • macOS の場合

      $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin
      $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin /usr/local/bin/operator-sdk
      $ rm operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin
  5. CLI ツールが正しくインストールされていることを確認します。

    $ operator-sdk version

4.1.2.2. Homebrew からのインストール

Homebrew を使用して SDK CLI をインストールできます。

前提条件

  • Homebrew
  • docker v17.03+、podman v1.2.0+、または buildah v1.7+
  • OpenShift CLI (oc) v4.5+ (インストール済み)
  • Kubernetes v1.12.0+ に基づくクラスターへのアクセス
  • コンテナーレジストリーへのアクセス

手順

  1. brew コマンドを使用して SDK CLI をインストールします。

    $ brew install operator-sdk
  2. CLI ツールが正しくインストールされていることを確認します。

    $ operator-sdk version

4.1.2.3. ソースを使用したコンパイルおよびインストール

Operator SDK ソースコードを取得して、SDK CLI をコンパイルし、インストールできます。

前提条件

  • Git
  • Go v1.13+
  • docker v17.03+、podman v1.2.0+、または buildah v1.7+
  • OpenShift CLI (oc) v4.5+ (インストール済み)
  • Kubernetes v1.12.0+ に基づくクラスターへのアクセス
  • コンテナーレジストリーへのアクセス

手順

  1. operator-sdk リポジトリーのクローンを作成します。

    $ mkdir -p $GOPATH/src/github.com/operator-framework
    $ cd $GOPATH/src/github.com/operator-framework
    $ git clone https://github.com/operator-framework/operator-sdk
    $ cd operator-sdk
  2. 必要なリリースブランチをチェックアウトします。

    $ git checkout master
  3. SDK CLI ツールをコンパイルし、インストールします。

    $ make dep
    $ make install

    これにより、$GOPATH/bin に CLI バイナリー operator-sdk がインストールされます。

  4. CLI ツールが正しくインストールされていることを確認します。

    $ operator-sdk version

4.1.3. Operator SDK を使用した Go ベースの Operator のビルド

Operator SDK は、詳細なアプリケーション固有の運用上の知識を必要とする可能性のあるプロセスである、Kubernetes ネイティブアプリケーションのビルドを容易にします。SDK はこの障壁を低くするだけでなく、メータリングやモニタリングなどの数多くの一般的な管理機能に必要なスケルトンコードの量を減らします。

この手順では、SDK によって提供されるツールおよびライブラリーを使用して単純な Memcached Operator をビルドする例を示します。

前提条件

  • 開発ワークステーションにインストールされる Operator SDK CLI
  • OpenShift Container Platform 4.5 などの、Kubernetes ベースのクラスター (v1.8 以上の apps/v1beta2 API グループをサポートするもの) にインストールされる Operator Lifecycle Manager (OLM)
  • cluster-admin パーミッションのあるアカウントを使用したクラスターへのアクセス
  • OpenShift CLI (oc) v4.5+ (インストール済み)

手順

  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. APIVersioncache.example.com/v1apha1 に設定し、KindMemcached に設定した状態で、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 annotationKind 型の宣言の上に存在する場合に、この検証ブロックの 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

追加リソース

4.1.4. Operator Lifecycle Manager を使用した Go ベースの Operator の管理

直前のセクションでは、Operator を手動で実行することについて説明しました。次のセクションでは、実稼働環境で実行される Operator のより堅牢なデプロイメントモデルを可能にする Operator Lifecycle Manager (OLM) の使用方法について説明します。

OLM は、Kubernetes クラスターで Operator およびそれらの関連サービスをインストールし、更新し、通常はそれらすべての Operator のライフサイクルを管理するのに役立ちます。これは、Kubernetes 拡張として実行され、追加のツールなしにすべてのライフサイクル管理機能について oc を使用できます。

前提条件

  • OLM が (apps/v1beta2 API グループをサポートする v1.8 以上のバージョンの) Kubernetes ベースのクラスターにインストールされていること (例: OpenShift Container Platform 4.5)。
  • Memcached Operator がビルドされていること。

手順

  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) kinddisplayName フィールドを 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

4.1.5. 追加リソース

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.