Member-only story
Kubernetes CRD：カスタムリソース定義(後半）
この記事では、CRDを定義し、それを使用してカスタムリソースを作成する方法を説明します。また、CRD に適したユースケースと適さないユースケースの例をいくつか紹介します。長い記事なので、前半と後半の２つに分けて投稿いたします。今回は前半です。
これで、クラスタ上にカスタムリソースタイプが作成されます。ここから、CRDを使って以下のようなYAMLでリソースオブジェクトを作成することができます：
apiVersion: "stable.example.com/v1"kind: CronTabmetadata:name: my-crontabspec:cronSpec: "* * * * */5"image: hello-world
これをcron.yamlなどのファイルに保存し、kubectl apply -f cron.yamlを実行します。これで、CRDを使ったリソースが作成されます。繰り返しますが、このカスタムリソースを処理するコントローラがなければ、単なるデータオブジェクトであり、従来のCronJobのようにスケジュールに従って実際に何かを行うことはありません。kubectl get crontabsを実行すると、今作成した新しいリソースを確認することができます。
CRD は基本的に単純なデータ・オブジェクトなので、多くのユースケースで導入できますが、最適とは言えないユースケースも多くあります。CRD がユースケースに適しているかどうかを判断するには、複数の事柄を考慮する必要があります。別のメカニズムに対するCRDの主な利点は、Kubernetesクラスタ内で自然で第一級オブジェクトを得ていることです。これは、ネームスペースのようなものを利用でき、kubectlを介して対話でき、Kubernetes UIツールで監視できることを意味します。
これらの特徴があなたのユースケースに有利かどうかを検討することが重要です。たとえば、特定のネームスペースをリソーススコープとすることは、多くの場合において有益である。同じアプリケーションを複数のネームスペースで実行するシナリオを考えてみましょう。上記の CronTab の例のようなものが、異なるネームスペースで実行されると有利になります。CronJobをprodとnon-prodに混在させるべきではありません。このため、この場合はカスタムリソースにするのがよいでしょう。
一方、ネームスペースに関係なく、すべてのアプリケーションインスタンスで共有できるものがあるかもしれません。たとえば、ワイルドカードのSSL証明書の詳細がそうです。このデータをカスタムリソースに格納することは技術的には可能ですが、 この場合、最適な方法とは言えません。同じ内容を複数のネームスペースで共有する可能性が高いので、ネームスペースのスコープは望ましくありません。
