Kubernetesのアーキテクチャの"肝"-「CRD」を使ってみよう

CRD（Custom Resource Definition）。

「時々見かけるワードだけど、何となく使っていてよくわからない」「そもそもCRDって何?」という方もいらっしゃると思います。

これを紐解くキーワードは「拡張性」です。Kubernetesのメリットの一つである優れた拡張性を実現するのが、CRDによるリソースの拡張なのです。

もちろんリソースの拡張をせずとも、Kubernetesの標準リソースだけでもさまざまなことが実現できますし、それで十分というケースもあるでしょう。ですが、世の中にある膨大なITシステムで実現するアーキテクチャにはさまざまなものがあります。Observability（可観測性）やCI/CD（継続的インテグレーション／継続的デリバリー）など含めた運用性を考慮すると、標準リソースだけで実現できるとは限りません。

そのため、求められるアーキテクチャを実現するにあたっては、CRDが重要な役割を担います。CRDを理解し、より深く／新しい視点でKubernetesの世界を堪能していきましょう。

今回の説明は、次の3ステップで構成しています。もう知っているよ、という部分は読み飛ばしてください。

• そもそも、Kubernetesの標準リソースはどうやって動いているのか
• 実はCRDは知らぬ間に使っていた?! CRDの具体的な使い方
• 世の中のCRDにはどんなものがあるか

Kubernetesの標準リソースはどうやって動いているのか

Kuberenetesの標準リソースは、Controllerとの協調動作により成り立っています。以降では、標準リソースの一つである「ReplicaSet」を例にとって説明していきましょう。

ReplicaSet Controllerの動作

ReplicaSet Controllerは、以下の3ステップにより動作します。

①ReplicaSet ControllerがReplicaSetが作成されたことを検知、Podを作成（ノード未割り当て）
②SchedulerがPodをノードに割り当て
③自ノードに割り当てられたkubeletがコンテナを起動し、ステータスを更新

Podが停止したら同様に、同じステップを踏んで再生成されます。

なお、本連載の第4回～第9回で各標準リソースについて説明しています。標準リソースの理解に不安がある方は、この機会にぜひ、復習してみてください。

実はCRDは知らぬ間に使っていた?! CRDの具体的な使い方

普段Kubernetesのマニフェストを書いていて見慣れないkindのリソースを見かけたことはないでしょうか。実は、「Argo CD」などさまざまなKubernetesのツールはCRD（＋Controller）を使って動作しているのです。

以下の2ステップを具体的なYAMLを活用して理解していきましょう。題材として、Argo CDを例にとって説明します。

• CRDを定義する
• CR（カスタムリソース）を定義する

まず、CRDを定義します。Argo CDの場合は、Argo CDのインストールスクリプトのなかで実行されるので、意識せずに実行していた方もいるかもしれません。

$kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

CRDを定義するYAML(install.yaml)のなかで、押さえておくべき点を説明します。次に示すコードでは、以下の2点を記述しています。

①CustomResourceDefinitionをkindに指定
②Application」というCR名を定義

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition　# ① kindがCustomResourceDefinition
metadata:
  labels:
    app.kubernetes.io/name: applications.argoproj.io
    app.kubernetes.io/part-of: argocd
  name: applications.argoproj.io
spec:
  group: argoproj.io
  names:
    kind: Application  # ② CR名がApplication

～後略～

次に、CRを定義します。

Argo CDでは、GUIから定義することも可能です。そのため、こちらも普段意識せずに実施していた方もいると思います。

次のコードでは、kind名を「Applilcation」として、各specを定義しています。DevOps系のCRということで、以下の事項が記載されています。

①アプリケーションを管理しているリポジトリを指定する
②アプリケーションをデプロイするクラスタを指定する

$kubectl apply -n argocd -f https://argoproj.github.io/argo-cd/operator-manual/application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source: # ① アプリケーションを管理しているリポジトリ
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination: # ② アプリケーションをデプロイするクラスタ
    server: https://kubernetes.default.svc
    namespace: guestbook

いかがでしたでしょうか? 「インストールスクリプトやGUIの裏側でこういったリソースが作成されているのだな」と理解しておくことで、Kubernetesのより深い理解につながります。

世の中のCRDにはどんなものがあるか

さて、世の中のCRDにはどんなものがあるのでしょうか。

以降では、Kubernetesの各ツールがどんなCRD(＋Controller)を作っているのか紹介します。実は知らぬ間に使っていた、というものもあるかもしれません。

それぞれのツールがおおよそどういったCRD／CRで構成されているかについて、ざっくり押さえておくと良いでしょう。なお、どのCRDとControllerが協調動作してツールの機能を実装しているのかは、公式ドキュメントやソースをご確認ください。

また、Kubernetesアプリケーションの運用ツールポータルである「OperatorHub.io」にも多くのCRDが登録されています。以下の多くは「Operator」と表記していますが、ここではざっくり「Operator = CRD＋Controller」だと理解しておいてください。

※　上表は2021年9月1日時点の情報に基づいて作成。

*　*　*

今回は、まず標準リソースとKubernetesのアーキテクチャを説明し、Operatorがどのように動作するのかを紹介しました。また、CRD/CRの具体的な利用方法や、世の中にどんなCRDがあるかを紹介しました。 Kubernetesの特徴の一つは拡張性の高さです。CRDはその中核に位置付けられます。CRDを理解し、その裏にあるアーキテクチャを理解することで、Kubernetesの理解を深めてみてください。