01
対象バージョンを固定する
初期値は1.37.0で、検証は手動です。入力や設定を変えると古い結果のコピーと保存を無効にします。ボタンまたはCtrl/Cmd+Enterで再実行してください。入力のたびに重いスキーマをコンパイルする動作ではありません。
Kubernetes / Helm
Kubernetes YAML検証：文書ごとの診断と関連を確認
対象バージョンを選び、フィールドの診断を確認してから必要な文書を出力します。
Kubernetes YAML検証
マニフェストYAML
リソースと結果
結果が古いため、エクスポートできません。
マニフェストとスキーマはブラウザー内で処理します。送信やクラスター接続は行いません。
結果が古いため、エクスポートできません。
静的検証はデプロイ成功を保証しません。エラーがあっても整形済みYAMLを出力できるため、先に診断を確認してください。
Kubernetes YAML検証が役立つのは、YAML構文チェックでは問題がないのにリソースを適用できない場面です。replicasが文字列になっていたり、フィールド名を一文字間違えていたりしても、YAMLの文法だけでは原因を絞れません。
この作業台は、レンダリング済みのKubernetesマニフェストを文書単位で扱います。対象は1.35.0、1.36.0、1.37.0の固定スナップショットです。手元のクラスターを推測せず、選んだ定義に対するスキーマ検証を行います。
Kubernetes YAML検証で確認しやすくなること
診断を元の文書へたどれる
Kubernetes YAML検証は、kind、名前空間、名前を文書番号とともに表示します。診断には入力の行列位置とフィールドのパスが付くため、同じ名前のServiceとDeploymentが並んでいても対象を区別できます。ひとつのリソースを選んでも元の入力全体は保持されます。
見えている関連だけを確かめる
Serviceのselectorは同じ名前空間のPodラベルとワークロードのテンプレートに照合します。環境変数やボリュームにあるConfigMap、Secretの参照も調べます。入力に参照先がなくてもクラスターには存在する可能性があるため、警告として扱います。
書き戻す前に確認する三つの点
02
独自kindの定義を用意する
カスタム欄に正確なapiVersion、kind、draft-07のJSON Schemaを入力します。対象が一致するリソースにだけ適用されます。内部参照は使えますが、未提供の外部参照はエラーになり、自動取得されません。
03
プレビューと出力範囲を使い分ける
YAML整形とファイル結合では、置換する文字数と文書数を先に表示します。適用してから一度だけ元に戻せます。出力は全文か選択した文書を指定でき、分割のために入力を削る必要はありません。
構造と文書をまとめて点検
固定された定義を使う
Kubernetes OpenAPIから派生した上流の完全な定義セットを同梱します。追加フィールド、必須値、型を検証し、各リソースで最初のスキーマ違反を示します。一つ直した後に別の違反が現れる場合があるため、修正後も確認してください。
リソース名の例外を区別
一般的なkindにはDNSの命名検査を行い、RBACにはパス要素の規則を使います。APIグループ、kind、名前空間、名前が同じなら、APIバージョンが違っても重複として検出します。追加の名称検査がないkindは要確認になります。Job名は63文字、CronJob名は52文字までに制限します。
テンプレート内の参照も対象
Podのほか、Deployment、StatefulSet、Job、CronJobなどのテンプレートを参照チェックに含めます。コンテナー環境変数、通常のボリューム、投射ボリュームに対応します。ConfigMapの個々のキーや実際のネットワーク接続までは調べません。
コメントを残して整形
JSONへ変換し直すのではなく、YAMLの構文木から整形します。コメント、アンカー、数値の元の表記を保持し、文書の分割出力にも対応します。フィールドの削除、並べ替え、文字列への型変換は自動では行いません。
静的な結果を読み違えないために
- クラスターの判定とは別
- CEL、webhook、RBAC、スケジューリング、イメージ取得、機能ゲートは実行しません。サーバーの既定値も追加しません。Service名は先頭を英字とする通常の規則で検査し、緩和された命名ゲートは模倣しません。
- 独自リソースを推測しない
- 対応するスキーマがないkindは未検証です。CRDオブジェクトからの自動抽出、HelmやKustomizeのレンダリング、遠隔スキーマの取得は対象外です。独自定義が使えてもKubernetes拡張キーワードの意味までは実行できません。
- Listを文書の区切りとして扱わない
- 複数リソースは---で区切ってください。Listや末尾がListのラッパーは展開せず、itemsが個別に検証されたとは表示しません。空の文書は一覧から除きますが、他の文書番号は元のままです。
- 入力と計算量に上限がある
- 最大500,000文字、100文書、100階層、50,000解析ノード、1,000診断です。ワーカーは8秒で停止します。重複キー、未対応タグ、大量の別名展開、安全に扱えない整数は明示的なエラーとなります。
- 保存できても適用可能とは限らない
- 構造エラーのある途中の原稿も整形済みYAMLとして保存できます。構文エラーや古い結果は出力できません。空白やフロー形式は変わることがあるため、入力への書き戻しにはプレビューの確認が必要です。
Kubernetes YAML検証のよくある質問
どのようなYAMLエラーを検出できますか？
構文、重複キー、未対応タグに加え、対象リソースのフィールド型や必須値を検査します。Kubernetes YAML検証の診断は文書番号とパスを示しますが、全エラーの列挙ではありません。各リソースの最初のスキーマ違反を直して再実行してください。
Kubernetes以外のYAMLにも使えますか？
整形はYAML文書を扱えますが、リソース検証にはapiVersion、kind、metadataが必要です。GitHub Actionsなどの一般設定は専用のYAML整形・検証ツールを使う方が適切です。このページの判定を別の設定形式の合格証として使わないでください。
コメントは整形後も残りますか？
残ります。構文木を使って整形し、コメントやアンカーを保持します。ただし改行、縮進、フロー形式は変わる場合があります。プレビューで確認してから適用すると、後で入力と結果をまとめて元に戻せます。
ファイルは外部へ送信されますか？
入力とカスタムスキーマはブラウザー内で処理します。ページ用のプログラムと定義はサイトから読み込みますが、入力中のURLを取得したりクラスターへ接続したりはしません。共有URLや永続ストレージへの保存も行いません。
重複キーは検出できますか？
同じマッピング内の重複キーはエラーにして、後の値で黙って上書きしません。異なる文書で同じフィールド名を使うことは問題ありません。リソースの重複は別の検査で、グループ、kind、名前空間、名前の組み合わせを比較します。
処理が合わない設定がありましたか？