OperatorLifecycleManager 101

そ～いうことね。完全に理解した

運用の知見をコード化し、ステートフルアプリケーションの運用を自動化するアプリ運用における運用の知見をコード化し、パッケージ化したもの。アプリケーション運用に必要な以下のような作業を自動的に行う。・インストール・リソーススケーリング・バックアップ・アップデート運用の知見をコード化

『』ではあるものの。話の流れ上、「」と言う意味で使っているところがあります。適宜、解釈お願いします。を解説するために、本資料内で未実装機能を実装済みのように取り
上げている箇所があります。あくまで例の場合は、注釈をつけています。本資料ではを例としてあげています

を簡単統一的に実装利用するためのフレームワーク容易にを作成の詳細を知らなくてもを作成できる。のインストールアップデートと依存関係を管理
のリソース使用量をレポート

も管理を行わなければ、技術負債となる自体のマニフェストを管理してくれる仕組みが

を利用することで、を自動的に最新の状態に保つための方式を提供する。プラットフォームや他のへの依存関係を解決し、自動で必要なリソースをインストールする。インストールされたとそのサービスを、テナン
トのに展開する。同じを所有して、競合するがインストールされることを防ぐ。を活用し、マネージドサービスプロバイダのように管理のインターフェイスを提供する。

展開先作成設定が利用する作成展開の作成 $ kubectl create
ns <namespace> $ kubectl create -f deploy/service_account.yaml –n <namespace> $ kubectl create -f deploy/crds/operator_crd.yaml $ kubectl create -f deploy/operator.yaml -n <namespace> $ kubectl create –f deploy/crds/operator_cr.yaml とりあえず全部手動でを作る方法

展開先作成設定が利用する作成展開の作成 $ kubectl create
ns <namespace> $ kubectl create -f deploy/service_account.yaml –n <namespace> $ kubectl create -f deploy/crds/operator_crd.yaml $ kubectl create -f deploy/operator.yaml -n <namespace> $ kubectl create –f deploy/crds/operator_cr.yaml $ helm repo add jenkins https://raw.githubusercontent.com/jenkinsci/kubernetes- operator/master/chart $ helm install jenkins/jenkins-operator 追加が化されているもある。

$ export olm_release=0.15.1 $ kubectl apply -f https://github.com/operator-framework/operator- lifecycle-manager/releases/download/${olm_release}/crds.yaml $
kubectl apply -f https://github.com/operator-framework/operator- lifecycle-manager/releases/download/${olm_release}/olm.yaml $ kubectl get crd NAME catalogsources.operators.coreos.com clusterserviceversions.operators.coreos.com installplans.operators.coreos.com operatorgroups.operators.coreos.com subscriptions.operators.coreos.com $ kubectl get deploy -n olm NAME READY UP-TO-DATE AVAILABLE AGE catalog-operator 1/1 1 1 88s olm-operator 1/1 1 1 88s packageserver 2/2 2 2 73s $ kubectl get packagemanifest NAME CATALOG AGE federatorai Community Operators 23m mariadb-operator-app Community Operators 23m nuodb-operator-bundle Community Operators 23m cluster-manager Community Operators 23m tidb-operator Community Operators 23m kubemq-operator Community Operators 23m jaeger Community Operators 23m …

【】単一のバージョンのを形成するパッケージ。・を識別するメタ情報・・リソースなどが記載されたでは、
として管理される。展開先作成設定が利用する作成展開の作成 $ kubectl create ns <namespace> $ kubectl create -f deploy/service_account.yaml –n <namespace> $ kubectl create -f deploy/crds/operator_crd.yaml $ kubectl create -f deploy/operator.yaml -n <namespace> $ kubectl create –f deploy/crds/operator_cr.yaml

は、が必要とする、それが管理したり、依存したりするカスタムリソースなど、実行に必要な技術情報源のを展開するための情報が入っている「」

ターゲット内のを監視し、で指定されたリソース要件が満たされていることを確認し、にしたがって、をデプロイする。クラスタのアプリケーション定義とを維持し、
のを監視し、それに基づいてを作成する。

ターゲット内のを監視し、で指定されたリソース要件が満たされていることを確認し、にしたがって、をデプロイする。クラスタのアプリケーション定義とを維持し、
のを監視し、それに基づいてを作成する。商品を紹介する販売員購入商品を届ける配達員

Ⅰ Ⅱ Ⅲ Ⅳ を監視の作成を作成リソースを作成を定義判定
の利用

をに届けてください。【】との更新元を定義し、パッケージ内のとバインドしての更新を維持するもの。 Operator
Ⅰ を監視 apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: argocd-operator namespace: olm spec: channel: alpha installPlanApproval: Automatic name: argocd-operator source: operatorhubio-catalog sourceNamespace: olm startingCSV: argocd-operator.v0.0.12

Ⅱ の作成にはととが入っています。こちらでいいですか？【】の自動インストール、またはアップグレードするため
に作成されるリソースの計算された一覧。おねがいします。 $ kubectl -n olm get installplan NAME CSV APPROVAL APPROVED install-gbtsx argocd-operator.v0.0.12 Automatic true

$ kubectl -n olm get csv NAME DISPLAY VERSION REPLACES
PHASE argocd-operator.v0.0.12 Argo CD 0.0.12 Succeeded $ kubectl get crd |grep argo applications.argoproj.io appprojects.argoproj.io argocdexports.argoproj.io argocds.argoproj.io Ⅲ を作成【】のデプロイを支援するリソース。を監視

Ⅳ リソースを作成【】と同じにデプロイされたのデプロイ制限を行う。が届けられる。を確認あのぉ
。届いたんだけど $ kubectl -n olm get deployment,pod,sa NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/argocd-operator 1/1 1 1 11m NAME READY STATUS RESTARTS AGE pod/argocd-operator-5d59c9c447 1/1 Running 0 11m NAME SECRETS AGE serviceaccount/argocd-application-controller 2 11m serviceaccount/argocd-dex-server 2 11m serviceaccount/argocd-operator 2 11m serviceaccount/argocd-redis-ha 2 11m serviceaccount/argocd-server 2 11m $ kubectl -n openshift-operator-lifecycle-manager logs pod/olm- operator-7d9844479b-wlcx5 --tail=10 time="2020-08-16T09:17:30Z" level=info msg="csv in operatorgroup" csv=argocd-operator.v0.0.12 id=GP0ZJ namespace=olm opgroup=olm- wxgq8 phase=Succeeded

Ⅰ を監視 Ⅱ の作成 Ⅳ リソースを作成 Ⅲ を作成

このあたりの仕組みについて再掲

Ⅰ を監視 Ⅱ の作成 Ⅳ リソースを作成 Ⅲ を作成再掲

は、が必要とする、それが管理したり、依存したりするカスタムリソースなど、実行に必要な技術情報源の名前、説明、、、、
などの定義配置に必要なリソースの定義、、、などが管理または依存するの定義

apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: <…ellipsis…> description: | ##
Overview The Argo CD Operator manages the full lifecycle… displayName: Argo CD icon: - base64data: PD94bWwgdmVyc2lvbj0iMS4w… mediatype: image/svg+xml links: - name: Argo CD Project url: https://argoproj.github.io/argo-cd/ - name: Operator Documentation url: https://argocd-operator.readthedocs.io - name: Operator Source Code url: https://github.com/argoproj-labs/argocd-operator maintainers: - email: [email protected] name: John McKenzie maturity: alpha provider: name: Argo CD Community replaces: argocd-operator.v0.0.11 version: 0.0.12 の情報を記載することで、特定のやソースコードの情報を提供。

などに記載される情報は、のから生成される。のリソースを取りまとめるメタデータはのごとに存在する

の中では、はとという更新ストリームで編成される。のリソースを取りまとめるメタデータごとに存在する内のタグリリースされたバージョンを管理するディレクトリー
を構成することによって、同じでも安定性だけでなく、異なる構成のを管理できる。例

apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: argocd-operator namespace: olm spec:
channel: alpha installPlanApproval: Automatic name: argocd-operator source: operatorhubio-catalog sourceNamespace: olm startingCSV: argocd-operator.v0.0.12 status: installedCSV: argocd-operator.v0.0.13 currentCSV: argocd-operator.v0.0.13 に到達するまでをバージョンずつ更新が作成されると、そのパッケージの最新がインストールされる。

新しく入れるクラスタは、新しいバージョンを導入最新バージョンに到達するまで、全てののバージョンを更新することは、安全ではない。 apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…>
spec: <…ellipsis…> description: | ## Overview The Argo CD Operator manages the full lifecycle… displayName: Argo CD icon: - base64data: PD94bWwgdmVyc2lvbj0iMS4w… replaces: argocd-operator.v0.0.11 skips: - argocd-operator.v0.0.12 version: 0.0.13 すでに導入済みのクラスタへの影響を与えないように

apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: <…ellipsis…> install: spec: clusterPermissions:
- rules: - apiGroups: - '*' resources: - ‘*’ … verbs: - get - list serviceAccountName: argocd-application-controller deployments: - name: argocd-operator spec: replicas: 1 selector: matchLabels: name: argocd-operator strategy: {} template: を実行するために必要なリソースの定義、などが直接行われる。

で定義されたが所属するを特定することで、メンバー内のに必要なを生成する。 ▶ クラスタ管理者がを介してに付与する権限を制
御することが目的 kind: OperatorGroup apiVersion: operators.coreos.com/v1 metadata: name: og-single namespace: argocd spec: targetNamespaces: - argocd とみなす条件がと同じにあるがをサポートしている場合でインストール対象情報を伝える基本はつのに対して、つのの指定を行う。

でインストール対象情報を伝えるメンバーに必要なアクセスを生成するための情報をでに提供 env: -
name: WATCH_NAMESPACE valueFrom: fieldRef: fieldPath: 'metadata.annotations[''olm.targetNamespaces'']' の名前の内にあるターゲットのを介して、のインスタンスに反映されるの配置方法で異なる

では、４つのをサポートしている。「」「」のどちらかをサポートしているが多い。管理のなどにをインストールし、ク
ラスタのすべてのを監視します。がデプロイされている以外の複数の指定されたのイベントを監視します。がデプロイされている以外の単一ののイベントを監視します。がデプロイされているのイベントだけを監視します。では、すべてが上記の構成をサポートしているわけではない。たとえば、クラスターレベルで実行するように設計されたに対して、単一のを定義するを設定すべきではない。

を設定したと同じののみを監視する。 kind: OperatorGroup apiVersion: operators.coreos.com/v1 metadata: name:
og-ownnamespace namespace: argocd spec: targetNamespaces: - argocd 他のユーザーに影響を与えることなくのアップグレードなどを処理できる。・内に指定されるのみを監視する・リソースにアクセスするおよびを設定

すべてののを監視する。 kind: OperatorGroup apiVersion: operators.coreos.com/v1 metadata: name: og-allnamespaces
namespace: olm リソースの再利用性を促進し、クラスター全体で定義されたリソースを管理する。・クラスター内の全てのに指定されるを監視する・およびを設定

installModes: - supported: true type: OwnNamespace で指定したにあったを展開できるようにを構成しておく
はの調整はしてくれない。

・の作成時にが生成され、のメンバーがになった時にが設定される。・・・
・・・・をリストで指定することで、に対応したをまとめられる

apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: customresourcedefinitions: owned: - kind:
Application name: applications.argoproj.io version: v1alpha1 displayName: Application description: An Application is a group… - kind: AppProject name: appprojects.argoproj.io version: v1alpha1 displayName: AppProject description: An AppProject is a logical… - kind: ArgoCDExport name: argocdexports.argoproj.io version: v1alpha1 displayName: ArgoCDExport description: ArgoCDExport describes… - kind: ArgoCD name: argocds.argoproj.io version: v1alpha1 displayName: ArgoCD description: ArgoCD is the representation… に必要なのリンク、依存関係の管理を設定する。

自体が所有しているの指定が使用できるには「」と「」のつのタイプがある。が必要としている、別が持つ
の指定を持つは動的にされる

apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: <…ellipsis…> spec: customresourcedefinitions: owned: -
kind: ArgoCD name: argocds.argoproj.io version: v1alpha1 displayName: ArgoCD description: ArgoCD is the representation… <…ellipsis…> specDescriptors: - description: 'The container image tag (version) … displayName: Version path: version x-descriptors: - 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:ArgoCD' - 'urn:alm:descriptor:com.tectonic.ui:text’ - description: 'The container image … displayName: Image path: image x-descriptors: - 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:ArgoCD' - 'urn:alm:descriptor:com.tectonic.ui:text’ - description: 'The number of operation processors… displayName: 'Operation Processor Count' path: controller.processors.operation x-descriptors: - 'urn:alm:descriptor:com.tectonic.ui:fieldGroup… - 'urn:alm:descriptor:com.tectonic.ui:number'

は、相互に機能しないの共存を防止する。・提供できないを必要とするのインストール・依存関係のあるに対して、障害を発生させる方法での
の更新が複数のによって所有される場合、は、後方互換性の条件を全て満たす場合にアップグレードされる。希望に更新えっまぢで新しいの

は、相互に機能しないの共存を防止する。・提供できないを必要とするのインストール・依存関係のあるに対して、障害を発生させる方法での
の更新が複数のによって所有される場合、は、後方互換性の条件を全て満たす場合にアップグレードされる。希望に更新えっまぢで新しいのバージョンの依存関係とは

kind: CustomResourceDefinition apiVersion: apiextensions.k8s.io/v1beta1 spec: names: kind: GitRepo <…ellipsis…> versions:
- name: v1alpha1 served: true storage: true apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: customresourcedefinitions: required: - kind: GitRepo name: gitrepos.gitproj.io version: v1alpha1 displayName: GitRepo description: GitRepo is the representation… のに新たなを追記の提供可能可否のメイン提供

- name: v1alpha1 served: true storage: false - name: v1beta1 served: true storage: true apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: customresourcedefinitions: required: - kind: GitRepo name: gitrepos.gitproj.io version: v1alpha1 displayName: GitRepo description: GitRepo is the representation… のに新たなを追記の提供可能可否のメイン提供非推奨バージョンで提供

- name: v1alpha1 served: true storage: false - name: v1beta1 served: true storage: true apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: customresourcedefinitions: required: - kind: GitRepo name: gitrepos.gitproj.io version: v1beta1 displayName: GitRepo description: GitRepo is the representation… 側の利用バージョンを変更する更新時点で、自身が新規バージョンに対応の入れ替えする必要がある。対応

- name: v1alpha1 served: false storage: false - name: v1beta1 served: true storage: true apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion <…ellipsis…> spec: customresourcedefinitions: required: - kind: GitRepo name: gitrepos.gitproj.io version: v1beta1 displayName: GitRepo description: GitRepo is the representation… をバージョンアップするには以下を満たす必要がある。・既存として有効化されたバージョンが、新規に存在する。・検証が新規の検証スキーマに対して行われる場合、の有効にされたバージョンに関連付けられる既存インスタンスまたはカスタムリソースすべてが有効である。提供廃止削除可能

の作成を含むをブラウザ上で作成可能

このあたりの仕組みについて再掲

Operator によってが並べられている？ $ kubectl get packagemanifests NAME CATALOG AGE
federatorai Community Operators 23m mariadb-operator-app Community Operators 23m nuodb-operator-bundle Community Operators 23m cluster-manager Community Operators 23m tidb-operator Community Operators 23m kubemq-operator Community Operators 23m jaeger Community Operators 23m …

/argocd-operator ├── 0.0.12 │ ├── Dockerfile │ ├── manifests │
│ ├── argocd-operator.v.0.0.12.clusterserviceversion.yaml │ │ ├── argoproj.io_applications_crd.yaml │ │ ├── argoproj.io_appprojects_crd.yaml │ │ ├── argoproj.io_argocdexports_crd.yaml │ │ └── argoproj.io_argocds_crd.yaml │ └── metadata │ ├── annotations.yaml │ └── dependencies.yaml └── 0.0.11 ├── Dockerfile ├── manifests │ ├── argocd-operator.v.0.0.11.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml └── metadata ├── annotations.yaml └── dependencies.yaml /argocd-operator ├── 0.0.12 │ ├── argocd-operator.v.0.0.12.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml ├── 0.0.11 │ ├── argocd-operator.v.0.0.11.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml ├── 0.0.9 ├── 0.0.8 ├── … └── argocd-operator.package.yaml は、「」「」ディレクトリで構成され、拡張が容易になっている

│ ├── argocd-operator.v.0.0.12.clusterserviceversion.yaml │ │ ├── argoproj.io_applications_crd.yaml │ │ ├── argoproj.io_appprojects_crd.yaml │ │ ├── argoproj.io_argocdexports_crd.yaml │ │ └── argoproj.io_argocds_crd.yaml │ └── metadata │ ├── annotations.yaml │ └── dependencies.yaml └── 0.0.11 ├── Dockerfile ├── manifests │ ├── argocd-operator.v.0.0.11.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml └── metadata ├── annotations.yaml └── dependencies.yaml に追加する方法についての形式や、から選択できるなどを定義する annotations: mediatype.v1: "registry+v1" manifests.v1: "manifests/" metadata.v1: "metadata/" package.v1: “argocd-operator" channels.v1: “alpha, beta" channel.default.v1: “alpha" 利用可能なを指定

│ ├── argocd-operator.v.0.0.12.clusterserviceversion.yaml │ │ ├── argoproj.io_applications_crd.yaml │ │ ├── argoproj.io_appprojects_crd.yaml │ │ ├── argoproj.io_argocdexports_crd.yaml │ │ └── argoproj.io_argocds_crd.yaml │ └── metadata │ ├── annotations.yaml │ └── dependencies.yaml └── 0.0.11 ├── Dockerfile ├── manifests │ ├── argocd-operator.v.0.0.11.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml └── metadata ├── annotations.yaml └── dependencies.yaml 明示的にバージョンの依存関係を指定することで、利用時にによって検出される。 dependencies: - type: olm.package packageName: git-operator version: >0.21.0 - type: olm.gvk group: gitproj.io kind: GitRepo version: v1alpha1 特定のバージョンを指定

│ ├── argocd-operator.v.0.0.12.clusterserviceversion.yaml │ │ ├── argoproj.io_applications_crd.yaml │ │ ├── argoproj.io_appprojects_crd.yaml │ │ ├── argoproj.io_argocdexports_crd.yaml │ │ └── argoproj.io_argocds_crd.yaml │ └── metadata │ ├── annotations.yaml │ └── dependencies.yaml └── 0.0.11 ├── Dockerfile ├── manifests │ ├── argocd-operator.v.0.0.11.clusterserviceversion.yaml │ ├── argoproj.io_applications_crd.yaml │ ├── argoproj.io_appprojects_crd.yaml │ ├── argoproj.io_argocdexports_crd.yaml │ └── argoproj.io_argocds_crd.yaml └── metadata ├── annotations.yaml └── dependencies.yaml は、とに関連付けられたメタデータを格納するコンテナイメージ。は、の特定のバージョンを提示する。 FROM scratch # We are pushing an operator-registry bundle # that has both metadata and manifests. LABEL operators.operatorframework.io.bundle.mediatype.v1=registry+v1 LABEL operators.operatorframework.io.bundle.manifests.v1=manifests/ LABEL operators.operatorframework.io.bundle.metadata.v1=metadata/ LABEL operators.operatorframework.io.bundle.package.v1=test-operator LABEL operators.operatorframework.io.bundle.channels.v1=beta,stable LABEL operators.operatorframework.io.bundle.channel.default.v1=stable ADD test/*.yaml /manifests ADD test/metadata/annotations.yaml /metadata/annotations.yaml

すべてのバージョンの情報が含まれるデータベースイメージ。へのポインター参照先が記載されたデータベースが含まれている。の実態ではない $ grpcurl
-plaintext localhost:50051 ¥ api.Registry/ListPackages { "name": "3scale-community-operator" } <…ellipsis…> { "name": "argocd-operator" } { "name": "argocd-operator-helm" } $ grpcurl -plaintext -d '{"pkgName":"argocd- operator","channelName":"alpha"}’ ¥ localhost:50051 ¥ api.Registry/GetBundleForChannel "providedApis": [ { "group": "argoproj.io", "version": "v1alpha1", "kind": "Application", "plural": "applications" } <…ellipsis…>

$ kubectl -n olm get pod NAME READY STATUS catalog-operator-c8bc7f97c-2fxds
1/1 Running olm-operator-84cfcdbdb8-qdzwd 1/1 Running operatorhubio-catalog-7bg4v 1/1 Running packageserver-7bc5d956c5-pxtz2 1/1 Running packageserver-7bc5d956c5-rffbv 1/1 Running を増やしていくことによって、導入できるのパッケージ数カタログを増やせる同一のカタログが入っているを同じクラスタ上に展開するとを起こす。

「」を管理しているプロセス。が追加されると、情報を取りに行き、特定の名とのリストを作る。 $ kubectl -n
olm get pod NAME READY STATUS catalog-operator-c8bc7f97c-2fxds 1/1 Running olm-operator-84cfcdbdb8-qdzwd 1/1 Running operatorhubio-catalog-7bg4v 1/1 Running packageserver-7bc5d956c5-pxtz2 1/1 Running packageserver-7bc5d956c5-rffbv 1/1 Running $ kubectl get packagemanifests NAME CATALOG AGE federatorai Community Operators 23m mariadb-operator-app Community Operators 23m nuodb-operator-bundle Community Operators 23m cluster-manager Community Operators 23m tidb-operator Community Operators 23m kubemq-operator Community Operators 23m jaeger Community Operators 23m …

## Create Index Image $ opm index add ¥ --bundles
quay.io/<registry-namespace>/bundle:0.0.1 ¥ --tag quay.io/<registry-namespace>/my-index:1.0.0 $ podman push quay.io/<registry-namespace>/my- index:1.0.0 ## Add Index to a current Image $ opm index add ¥ --bundles quay.io/<registry-namespace>/bundle:0.0.2 ¥ --from-index quay.io/<registry-namespace>/my- index:1.0.0 ¥ --tag quay.io/<registry-namespace>/my-index:1.0.1 の作成は「」というプロジェクトによって管理されている。管理者は、コマンドを利用することで、を作ることができる。

## Create Index Image $ opm index add ¥ --bundles
quay.io/<registry-namespace>/bundle:0.0.1 ¥ --tag quay.io/<registry-namespace>/my-index:1.0.0 $ podman push quay.io/<registry-namespace>/my- index:1.0.0 ## Add Index to a current Image $ opm index add ¥ --bundles quay.io/<registry-namespace>/bundle:0.0.2 ¥ --from-index quay.io/<registry-namespace>/my- index:1.0.0 ¥ --tag quay.io/<registry-namespace>/my-index:1.0.1 の作成は「」というプロジェクトによって管理されている。管理者は、コマンドを利用することで、を作ることができる。誰がを管理しているのか $ kubectl -n olm get pod NAME READY STATUS catalog-operator-c8bc7f97c-2fxds 1/1 Running olm-operator-84cfcdbdb8-qdzwd 1/1 Running operatorhubio-catalog-7bg4v 1/1 Running packageserver-7bc5d956c5-pxtz2 1/1 Running packageserver-7bc5d956c5-rffbv 1/1 Running $ kubectl -n olm get deploy NAME READY UP-TO-DATE AVAILABLE catalog-operator 1/1 1 olm-operator 1/1 1 packageserver 2/2 2 「」には、は、存在しない。

が、の情報をもとにを管理し、メタデータのストア先を指示する。を作成すると、のが作成される。同様に監視を行う
apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-catalog namespace: olm spec: sourceType: grpc image: quay.io/operator-framework/upstream- community-operators:latest displayName: Community Operators publisher: OperatorHub.io

が、の情報をもとにを管理し、メタデータのストア先を指示する。を作成すると、のが作成される。同様に監視を行う
を更新することで、新しいパッケージ情報などが更新される。利用しているのが新しくなると、動的に更新される。

「」はクラスタ内のの管理として機能するのプラグイン。・容易にのインストール、アンインストール、すでにインストールされたの一覧を表示が可能・
を経由した、やなどの概念をなくした管理が可能

には、つのがある。を提供するをポーリングし、を管理する。所定アドレスに対するへのアクセスを試し、そこから情報
を取得する。データを解析して、を提供できるを管理する。 apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource <…ellipsis…> spec: address: community-operators.openshift- marketplace.svc:50051 displayName: Community Operators インターネット上のを通じて情報を取得する community-operators.openshift- marketplace.svc:50051

は、を管理しているリソース。で利用されており、によってを管理している。

のの認定を受けたが、サポートしている群コミュニティで提供されているであり、基本はプロダクトのコントリビューターによってサポート
されている。社がミドルウェアプロダクトを化して提供している。がデフォルトで管理しているには、以下の種類がある。すべて、を経由して展開される。

まとめも管理を行わなければ、技術負債となるを使う際は、を使おう

著特別マテリアルダウンロード

創る側なのか。活用する側なのか。

参考資料

徹底解説「徹底解説」抜粋版無料プレゼント以下よりダウンロードください。

OperatorLifecycleManager 101

OperatorLifecycleManager 101

More Decks by Shingo.Kitayama

Other Decks in Technology

Featured

Transcript