Kubernetes オペレータ

付録B. カスタムリソースの検証

新しいAPIを追加する場合、Operator SDKはカスタムリソース定義のスケルトンを生成します。 このスケルトンはそのままユーザビリティがあり、カスタムリソースを作成するためにさらに変更または追加する必要はない。

スケルトンCRDは、ユーザー入力とカスタム・リソースの状態をそれぞれ表すspec 、セクションをオープンエンドなオブジェクトとして定義するだけで、この柔軟性を実現している。 statusセクションを、それぞれオープンエンドのオブジェクトとして定義することによって、この柔軟性を実現している：

spec:
    type: object
status:
    type: object

このアプローチの欠点は、Kubernetesがこれらのフィールドのいずれかのデータを検証できないことだ。Kubernetesはどのような値が許可されるべきか、または許可されるべきではないかを知らないので、マニフェストが解析される限り、値は許可される。

この問題を解決するために、CRDには、各フィールドのバリデーション制約を記述するOpenAPI仕様のサポートが含まれている。このバリデーションを手動でCRDに追加して、spec と statusセクションの許容値を記述する。

CRDのspec ：

• properties マップを追加する。このタイプのカスタムリソースに指定される可能性のある各属性について、パラメータのタイプと許容値に関する情報とともに、このマップにエントリを追加する。

• オプションで、Kubernetesがその存在を強制すべきプロパティをリストしたrequired フィールドを追加できる。このリストのエントリとして、各必須プロパティの名前を追加する。リソース作成中にこれらのプロパティを省略すると、Kubernetesはリソースを拒否する。

また、spec と同じ規則に従って、status セクションにプロパティ情報を追加することもできる。ただし、required フィールドを追加する必要はない。

警告

どちらの場合も、既存の行type: object 。この「タイプ」宣言と同じレベルに新しい追加を挿入する。

spec とstatus の両フィールドは、CRDの以下のセクションで発見できる：

spec -> validation -> openAPIV3Schema -> properties

一例として、VisitorsApp CRDに追加された内容は以下の通りである：

spec:
    type: object
    properties:
        size:
            type: integer
        title:
            type: string
    required:
    - size
status:
    type: object
    properties:
        backendImage:
            type: string
        frontendImage:
            type: string

このスニペットは、OpenAPIバリデーションを使って実現できることのほんの一例に過ぎない。 カスタムリソース定義の作成に関する詳しい情報は、Kubernetesのドキュメントで発見できる。