Kubernetes カスタムリソース定義 (CRD) の説明

Kubernetes カスタムリソース定義 (CRD) の説明

  • ITOps・DevOps
6分で読めます 更新日 Apr 16, 2019

ポイント: Kubernetes カスタムリソース定義 (CRD) は、ユーザーがカスタム API オブジェクトを作成し、Kubernetes の機能を強化することを可能にします。このガイドでは、CRD の作成、管理、および利用について詳しく説明します。

  • CRD は Kubernetes 内のカスタムリソースを定義します。
  • CRD を作成するには、そのメタデータ、バージョン、およびスコープを指定します。
  • 宣言的アプローチのためにカスタムコントローラーを追加できます。

この投稿では、カスタムリソース定義 (CRD) について説明します。以下の内容を扱います:

  • CRD とは
  • どのように使用されるか
  • それを作成する方法
  • いくつかのヒントとコツ

続けていくために、Kubernetes、kubectl の事前知識があり、minikube が動作していると仮定します。

K8S における CRD の概念

CRD が何であるかを理解するためには、Kubernetes のいくつかの概念について説明する必要があります:

  • リソースとは、任意の種類の API オブジェクトを保存するための k8s API のエンドポイントです。
  • カスタムリソースとは、Pod、Deployment、ReplicaSet などのように、自分独自の API オブジェクトを作成し、自分の種類を定義することを可能にします。

カスタムリソースは、アプリケーションに役立つ任意の種類の API オブジェクトを追加することで Kubernetes の機能を拡張することを可能にします。カスタムリソース定義は、カスタムリソースを定義するために使用します。これは、デフォルトのインストールを超えて Kubernetes の機能を拡張する強力な方法です。

CRD を作成する方法

以下のマニフェストは、CRD crd.yaml の例を示しています。

    apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: appconfigs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: appconfigs
    singular: appconfig
    kind: AppConfig
    shortNames:
    - ac

上記の CRD が何を作成するかを説明しましょう:

  • 最初の 2 行は apiversion が何であるかを定義しており、カスタムリソース定義を作成することを示しています。
  • metadata フィールドは、リソースの名前を定義するのに役立ちます。私たちのケースでは appconfigs(複数形)です。
  • Spec group は、グループ名を定義するのに役立ちます。
  • Spec version は、バージョンを定義するのに役立ちます。v1 であり、このバージョンをストレージバージョンにしたいと言っています。
  • ご覧の通り、CRD のバージョンを定義でき、同時にストレージバージョンは 1 つのバージョンのみである必要があるため、その点を考慮してください。次に、この CRD が名前空間にあり、クラスター全体ではないことを確認しました。これにより、特定の名前空間またはクラスター全体のいずれかに対して CRD を作成できます。
  • 次に、CRD の単数形と複数形の名前を定義しました。
  • 最後に、種類の名前と短縮名を定義しました。次に、kubectl create -f crd.yaml を使用して作成できます。CRD の新しい名前空間 RESTful API エンドポイントは /apis/stable.example.com/v1/namespaces/*/appconfigs に見つかります。

したがって、この CRD を使用することがどのように役立つかを考えているかもしれません。上記の CRD を使用するには、CRD で作成した種類を使用してマニフェストを作成します。たとえば、my-kind.yaml があります。

    apiVersion: "stable.example.com/v1"
kind: AppConfig
metadata:
  name: demo-appconfig
spec:
  uri: "some uri"
  Command: "some command"
  image: my-image

ご覧のように、CRD で定義した種類を使用しており、次に、私たちの種類オブジェクトに持たせたいフィールドを定義しました。ここでは、アプリの URI、コマンド、およびイメージを定義したいと考えています。今、kubectl create -f my-kind.yaml を実行すると、アプリケーションは上記のマニフェストで作成したデータを消費できます。何が起こっているかを確認するには、kubectl get ac -o yaml を実行すると、作成したものの詳細情報が表示されます。CRD で定義した短縮名 (ac) を使用していることに注意してください。

CRD を削除する方法

作成した CRD とリソースを削除するには、他のリソースと同様に kubectl delete を実行します。上記の CRD は、ストレージされて取得できるデータにすぎないため、完全に宣言的な API を提供しないことを知っておくことが重要です。このリソースを完全に宣言的にする方法は、現在の状態と望ましい状態が常に同期していることを確認するカスタムコントローラーを追加することです。例としては、レプリケーションコントローラーのようなものがあります。

CRD は Kubernetes を拡張します

CRD は Kubernetes を拡張する方法であり、カスタムリソースを選択して作成し、カスタムコントローラーの助けを借りて宣言的にすることを可能にします。

追加のリソース

Kubernetes に関する詳細情報については、これらのリソースを探求してください:

これらの投稿は私自身のものであり、必ずしも BMC の立場、戦略、または意見を表すものではありません。

ITOps・DevOpsの関連記事

The Briefを購読する

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ありがとう

あなたはThe Briefに登録されました
The Briefはメインフレームとエンタープライズオーケストレーション—BMC AMIとControl-M—および、両者に関するアナリストの研究、顧客の展開、イベントをカバーしています。