Kubernetes YAML検証ツール
Kubernetesマニフェスト（複数の場合は---で区切る）を貼り付けて、kubectl applyする前に実際のスキーマと照合してください。
ここに.yaml/.ymlファイルをドロップするか、上にマニフェストのテキストを貼り付けてください。
"---"で区切られた複数のマニフェストは、それぞれ別のドキュメントとして検証されます。
詳細オプション
解析と検証はブラウザ内で行われます — サーバーに送信されるのはリソースのスキーマのみで、マニフェスト自体は送信されません。
上に Kubernetes マニフェストを貼り付ける（またはサンプルを読み込む）と、ここに検証結果が表示されます。
kubectl より先に Kubernetes マニフェストの誤りを見つける
Kubernetes マニフェストの誤りに最初に気づくのは、`kubectl apply` が拒否されたときというのがよくあります。そのときはデプロイの最中で、編集していた YAML ファイルとすぐには結び付かない JSON Schema 検証のパス（`spec.template.spec.containers[0].image: Required value`）を示すエラーメッセージを見つめることになりがちです。同じ種類の誤りを、該当行をハイライトして早い段階で見つけられれば、作業を中断することなく数秒で修正できます。
YAML 自体の構文には、他の設定形式にはあまりない落とし穴があります。インデントが意味を持つため、タブとスペースが混在すると、エラーにならずに別の（誤った）構造になる場合があります。複数のリソースを含む長いファイルでは、`---` のドキュメント区切りを見失いやすく、余分なネストが 1 段増えても YAML としては有効なまま、Kubernetes にとってはまったく別の意味になります。このツールは、ソース上の位置情報を保持したままパースするライブラリを使っているため、構文の問題は「200 行のどこか」ではなく、実際に発生した行に対して報告されます。
非推奨の apiVersion は、ゆっくり効いてくる罠です。`extensions/v1beta1` の Deployment、`apps/v1beta1`／`apps/v1beta2` の StatefulSet と DaemonSet、`networking.k8s.io/v1beta1` の Ingress は、どれも YAML としては有効で、古いクラスターでは動作していました。しかし、Kubernetes が古い API グループを完全に削除するバージョンまでクラスターをアップグレードすると、それを使っているマニフェストはすべて、事前の警告なしに適用できなくなります。編集中に（置き換え先の apiVersion の提案とともに）見つけておけば、クラスターのアップグレード中に初めて気づく事態を避けられます。
残りの誤りは、本物の Kubernetes OpenAPI 仕様に基づくスキーマ検証で見つかります。数値のはずの `replicas` が引用符付きの文字列になっている、`containerPort` が有効な範囲を外れている、マニフェスト間でコピー＆ペーストするうちに Deployment の必須フィールド `spec.selector` が消えてしまった、といったものです。これらは YAML の構文エラーではなく、ファイルとしては問題なくパースできます。だからこそ、ざっと目で読んだだけでは見落としがちな点を、専用のスキーマチェックが拾い上げてくれます。
よくある質問
`kubectl apply --dry-run` や `kubeconform` の代わりになりますか？
いいえ。`kubectl apply --dry-run=server` は、インストール済みの CRD や admission webhook を含め、実際のクラスターの API サーバーに対して実行される唯一のチェックです。また `kubeconform`／`kubeval` は CI パイプライン向けに作られた成熟した CLI ツールです。このツールは、YAML の構文、スキーマの形、非推奨の apiVersion といった同じ種類の確認を、ブラウザのタブ上で行います。`kubectl` をまだどこにも設定していないときや、他の人から送られたマニフェストをレビューするときに便利です。
スキーマはどこから取得していますか？
`yannh/kubernetes-json-schema` から取得しています。これは Kubernetes 自身の OpenAPI から生成された JSON Schema を、コミュニティが自動更新しているミラーで、選択した Kubernetes のバージョンに応じて公開 CDN から必要なときに取得されます。マニフェストの内容はどこにも送信されません。ダウンロードされるのは、その kind／バージョンを検証するすべてのユーザーに共通の、バージョン管理された公開スキーマファイルだけです。
なぜリソースの種類が 10 個だけなのですか？
Deployment、Service、Ingress、ConfigMap、Secret、StatefulSet、DaemonSet、Job、CronJob、PersistentVolumeClaim で、手書きされるマニフェストの大半をカバーできます。その他の kind でも、YAML の構文チェックと非推奨 apiVersion の検出は完全に行われます。スキーマの形による検証だけが、まだ対象外です。
YAML がブラウザの外に出ることはありますか？
いいえ。パースもスキーマ検証も、このタブ内の素の JavaScript で実行されます。このツールが行う唯一のネットワークリクエストは、選択したリソースの種類と Kubernetes のバージョンに対応する公開 JSON Schema ファイルの取得だけで、マニフェストの内容を送ることはありません。