検索
連載

Kubernetesに無限の可能性を生み出す「Operator」「CRD」「カスタムコントローラー」とは：Cloud Nativeチートシート（8）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Kubernetesの機能を拡張する「Operator」「CRD」「カスタムコントローラー」について解説します。

Share
Tweet
LINE
Hatena

ヤフーやサイボウズも使っている、Kubernetesの「Operator」とは

　Kubernetesでは、「Pod」「ReplicaSet」「Deployment」「Service」などの標準のリソースが用意されていますが、「Operator」を利用すると、独自のリソースを追加してKubernetesを拡張することができます。

　Operatorは既に広く利用されています。

　世の中の先進企業の例を見ると、ヤフーのKubernetes as a ServiceによるKubernetesクラスタの払い出しや、サイボウズの「MOCO」によるMySQL環境の払い出しなどがあります。

　パブリッククラウドのマネージドサービスを見ると、「AWS Controllers for Kubernetes」（ACK）、「Azure Service Operator」などが出てきています。これらはパブリッククラウドのインフラをKubernetesで管理するというコンセプトで開発されています。

　CI/CD（継続的インテグレーション／継続的デリバリー）関連でいえば、本連載第7回で紹介した「ArgoCD」も、その動作を実現するOperatorが定義されているのです。

　Observability関連においては、「Prometheus Operator」「Grafana Operator」などがあります。

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回は、Operatorとは何かを解説し、Operatorを開発するツール「Kubebuilder」の利用方法を紹介します。Operatorをどうやって作ればいいかを、実践的なコードレベルで理解できます。

Operatorと、その構成要素

　Kubernetesの機能を拡張する方法の一つ、「Operator Pattern」は、CRD（Custom Resource Definitions）とカスタムコントローラーを組み合わせたものです。

CRD――中華料理店のメニューに追加される新たな料理

　CRD（Custom Resource Definitions）とは、その名の通り、カスタムリソース定義です。カスタムというからには標準があるわけですが、Kubernetesにおける標準リソースはPodやReplicaSetなどです。

　フランチャイズ型中華料理店でいうと、ラーメン、ギョーザ、チャーハンといった全店舗共通メニューが標準リソースで、店舗独自メニューのあんかけチャーハンがCRDのようなイメージです。

　厳密には、リソースとリソース定義は下記の関係にあります。Javaでいうところのクラスがリソース定義、インスタンスがリソースだとざっくりとイメージしておけばいいでしょう。

Kubernetes標準リソースとCRDの関係性
リソース リソース定義
標準 Pod、ReplicaSet、Deploymentなど 標準リソースの定義
カスタム CR（Custom Resource）
個別のプロジェクト用にカスタマイズされたリソース		 CRD（Custom Resource Definition）
CRを定義するリソース
（参考：Javaのイメージ） インスタンス クラス
（もっと参考：中華のイメージ） あんかけチャーハンの注文 あんかけチャーハンというメニュー

　「標準リソースだけじゃダメなんですか？」と思う方もいると思います。確かに、標準リソースだけでも、次のようなユースケースには対応できます。

  • ReplicaSet：Podの状態を監視し、常に必要なPod数をキープする
  • Deployment：新しいバージョンのアプリケーションをロールアウトする

　しかし、標準リソースだけでは、システム運用における全てのユースケースを網羅することはできません。そこで、CRDにより、標準リソースにはない属性を持つリソース定義を行い、Kubernetesを拡張することが可能になります。

カスタムコントローラー――オーダーを調理する究極の料理人

　CRDを使えば何でもできるのかというと、決してそうではありません。CRDは単にKubernetes上で独自オブジェクトの読み書きを可能にしてくれるだけのものです。CRDだけ存在する状態は、あんかけチャーハンを新しくメニューに載せただけで、レシピを知る料理人がいない状態に相当します。

　CRDがその真価を発揮するためには、カスタムリソースが存在するときに、その定義に従って“世界”※をあるべき状態に保つコントローラーが必要になります。それが「カスタムコントローラー」です。

※補足

　ここであえて「世界」と記載したのは、カスタムコントローラの管理範囲は、私たちの実装次第でKubernetesの外部にも拡張可能だからです。先述の例のようにKubernetesクラスタを払い出したり、パブリッククラウドのマネージドサービスを作成したりなど、実装次第で可能性は無限大です。


カスタムコントローラーと制御ループ

　カスタムコントローラーは、Kubernetesの標準リソースのコントローラーと同様にKubernetesの「制御ループ」（調整ループ、Reconciliation Loop）の仕組みを活用します。そのため、カスタムコントローラーの説明に入る前に、簡単にこの制御ループの仕組みについて説明します。

　Kubernetesでは、Deploymentを作成するとReplicaSetが出来上がり、ReplicaSetができるとPodができますが、これを行っているのは「kube-controller-manager」というKubernetesのコントローラーの集合体です。kube-controller-manager中のDeploymentのコントローラーは、Deploymentリソースの状態を見てReplicaSetの作成、削除を行い、ReplicaSetのコントローラーは、ReplicaSetリソースの状態を見てPodの作成、削除を行います。スケジューラはPodのノードに割り当て、kubeletは自ノードに割り当てられたPod定義が存在する場合にPodを起動します。


Deploymentリソースを作成してからノードでPodが起動するまで

　ReplicaSetのspecにはreplicasという数値型のプロパティが定義されています。ReplicaSetのコントローラーは、このreplicasプロパティを読み取り、作成されているPodの数をクラスタから取得し、これらを見比べて現在の状態が望ましい状態になっているかどうかを比較し、望ましい状態でなければ是正します。このロジックは全てコントローラーに内包されています。


ReplicaSetコントローラーの動作イメージ

　これらの現在の状態取得、あるべき状態との比較、現在の状態の是正、というコントローラーの処理は定期的に動作します。これが、先述の制御ループです。

　同じ理屈で、カスタムリソースのオプジェクトで定義した状態を保証するプログラムがカスタムコントローラーです。カスタムコントローラーはkube-apiserverから関連リソースの状態を取得し、現状をあるべき状態に保ちます。

CRDと、簡易コントローラーの作成

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る