2.8. CRD
2.8.1. カスタムリソース定義による Kubernetes API の拡張 リンクのコピーリンクがクリップボードにコピーされました!
ビルトイン Kubernetes オブジェクトのように動作するカスタムオブジェクトタイプで Kubernetes API を拡張するために、クラスター管理者は OpenShift Container Platform クラスターでカスタムリソース定義(CRD)を作成し、管理できます。
2.8.1.1. カスタムリソース定義 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes API では、リソース は特定の種類の API オブジェクトのコレクションを保管するエンドポイントです。たとえば、ビルトインされた Pods リソースには、Pod オブジェクトのコレクションが含まれます。
カスタムリソース定義 (CRD) オブジェクトは、クラスター内に新規の固有オブジェクト kind を定義し、Kubernetes API サーバーにそのライフサイクル全体を処理させます。
カスタムリソース (CR) オブジェクトは、クラスター管理者によってクラスターに追加された CRD から作成され、すべてのクラスターユーザーが新規リソースタイプをプロジェクトに追加できるようにします。
クラスター管理者が新規 CRD をクラスターに追加する際に、Kubernetes API サーバーは、クラスター全体または単一プロジェクト (namespace) によってアクセスできる新規の RESTful リソースパスを作成することによって応答し、指定された CR を提供し始めます。
CRD へのアクセスを他のユーザーに付与する必要のあるクラスター管理者は、クラスターロールの集計を使用して admin、edit、または view のデフォルトクラスターロールを持つユーザーにアクセスを付与できます。また、クラスターロールの集計により、カスタムポリシールールをこれらのクラスターロールに挿入することができます。この動作は、新規リソースを組み込み型のインリソースであるかのようにクラスターの RBAC ポリシーに統合します。
Operator はとりわけ CRD を必要な RBAC ポリシーおよび他のソフトウェア固有のロジックでパッケージ化することで CRD を利用します。またクラスター管理者は、Operator のライフサイクル外にあるクラスターに CRD を手動で追加でき、これらをすべてのユーザーに利用可能にすることができます。
クラスター管理者のみが CRD を作成できる一方で、開発者は CRD への読み取りおよび書き込みパーミッションがある場合には、既存の CRD から CR を作成することができます。
2.8.1.2. カスタムリソース定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムリソース (CR) オブジェクトを作成するには、クラスター管理者はまずカスタムリソース定義 (CRD) を作成する必要があります。
前提条件
-
cluster-adminユーザー権限を使用した OpenShift Container Platform クラスターへのアクセス
手順
以下の例のようなフィールドタイプを含む YAML ファイルを作成します。
CRD の YAML ファイルの例
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ctここでは、以下のようになります。
apiVersion-
apiextensions.k8s.io/v1API パラメーターを指定します。 metadata.name-
定義の名前を指定します。これは
groupおよびpluralフィールドの値を使用する<plural-name>.<group>形式である必要があります。 spec.group-
API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、
JobまたはScheduledJobなどのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.comなど) である可能性があります。組織の完全修飾ドメイン名 (FQDN) を使用することが奨励されます。 spec.versions.name-
URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンに存在させることができます (例:
v1alpha、v1beta、v1)。 spec.scope-
カスタムオブジェクトがプロジェクト(
Namespaced)で利用できるか、クラスター内のすべてのプロジェクト(クラスター)で使用可能であるかを指定します。 spec.names.plural-
URL で使用される複数形の名前を指定します。
pluralフィールドは API URL のリソースと同じになります。 spec.names.singular- CLI および表示用にエイリアスとして使用される単数形の名前を指定します。
spec.names.kind- 作成できるオブジェクトの種類を指定します。type はキャメルケースにすることができます。
spec.names.shortNamesCLI のリソースに一致する短い文字列を指定します。
注記デフォルトで、CRD のスコープはクラスターで設定され、すべてのプロジェクトで利用可能です。
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フィールドに基づいています。
2.8.1.3. カスタムリソース定義のクラスターロールの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存のクラスタースコープのカスタムリソース定義 (CRD) にパーミッションを付与できます。admin、edit、および view のデフォルトクラスターロールを使用する場合、これらのルールについてクラスターロールの集計を利用できます。
これらのロールのいずれかにパーミッションを付与する際は、明示的に付与する必要があります。より多くのパーミッションを持つロールはより少ないパーミッションを持つロールからルールを継承しません。ルールをあるロールに割り当てる場合、より多くのパーミッションを持つロールにもその動詞を割り当てる必要もあります。たとえば、get crontabs パーミッションを表示ロールに付与する場合、これを edit および admin ロールにも付与する必要があります。admin または edit ロールは通常、プロジェクトテンプレートでプロジェクトを作成したユーザーに割り当てられます。
前提条件
- CRD を作成します。
手順
CRD のクラスターロール定義ファイルを作成します。クラスターロール定義は、各クラスターロールに適用されるルールが含まれる YAML ファイルです。OpenShift Container Platform Controller はデフォルトクラスターロールに指定するルールを追加します。
カスタムロール定義の YAML ファイルの例
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-admin-edit labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: # Add these permissions to the "view" default role. rbac.authorization.k8s.io/aggregate-to-view: "true" rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch"]ここでは、以下のようになります。
apiVersion-
rbac.authorization.k8s.io/v1API を指定します。 metadata.name- 定義の名前を指定します。
metadata.labels.rbac.authorization.k8s.io/aggregate-to-admin-
"true"を指定して、admin ロールにクラスターロールの集計を有効にします。 metadata.labels.rbac.authorization.k8s.io/aggregate-to-edit-
パーミッション
を edit デフォルトロールに付与するために trueを指定します。 rules.apiGroups- CRD のグループ名を指定します。
rules.resources- これらのルールが適用される CRD の複数形の名前を指定します。
rules.verbs-
ロールに付与されるパーミッションを表す動詞を指定します。たとえば、読み取りおよび書き込みパーミッションを
adminおよびeditロールに適用し、読み取り専用パーミッションをviewロールに適用します。 metadata.labels.rbac.authorization.k8s.io/aggregate-to-view-
パーミッションを
viewのデフォルトロールに付与するためにtrueを指定します。 metadata.labels."rbac.authorization.k8s.io/aggregate-to-cluster-reader"-
cluster-readerのデフォルトロールにパーミッションを付与するためにtrueを指定します。
クラスターロールを作成します。
$ oc create -f <file_name>.yaml
2.8.1.4. ファイルからのカスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムリソース定義(CRD)をクラスターに追加した後に、CLI を使用してカスタムリソース(CR)をファイルから作成できます。
前提条件
- CRD がクラスター管理者によってクラスターに追加されている。
手順
CR の YAML ファイルを作成します。以下の定義例では、
cronSpecとimageのカスタムフィールドがKind: CronTabの CR に設定されます。このKindは、CRD オブジェクトのspec.kindフィールドから取得されます。CR の YAML ファイルサンプル
apiVersion: "stable.example.com/v1" kind: CronTab metadata: name: my-new-cron-object finalizers: - finalizer.stable.example.com spec: cronSpec: "* * * * /5" image: my-awesome-cron-imageここでは、以下のようになります。
apiVersion- CRD からグループ名および API バージョン(名前/バージョン)を指定します。
kind- CRD のタイプを指定します。
metadata.name- オブジェクトの名前を指定します。
metadata.Finalizers- オブジェクトのファイナライザーを指定します(ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。
spec- オブジェクトのタイプに固有の条件を指定します。
ファイルの作成後に、オブジェクトを作成します。
$ oc create -f <file_name>.yaml
2.8.1.5. カスタムリソースの検査 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用してクラスターに存在するカスタムリソース (CR) オブジェクトを検査できます。
前提条件
- CR オブジェクトがアクセスできる namespace にあること。
手順
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 ctCR の未加工の 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' image: my-awesome-cron-image出力の
specセクションには、オブジェクトの作成時に定義したcronSpecやimageなどのカスタム設定が表示されます。