Kubernetes YAML から JSON への安全な変換

Kubernetes YAML から JSON: そもそもなぜ変換するのでしょうか?

• 実際の API 形状を使用したデバッグ: フィールドが拒否された場合、JSON にはサーバーが認識する内容が正確に表示され、YAML の入力の曖昧さはありません。
• フィード パイプライン: 多くのツール (ポリシー エンジン、CI スクリプト、jq パイプライン) は、YAML よりも快適に JSON を消費します。
• レンダリングされた出力の差分: JSON として 2 つの Helm リリースを比較すると、型の変更が表示されます。これは古典的な「true は「true」ではない」というバグです。
• ドキュメンテーションと教育: JSON 中括弧により、spec.template.spec.containers のネストが明確になります。

複数文書の問題

通常、マニフェスト ファイルには、--- で区切られた多くのリソースが含まれています: 名前空間、ConfigMap、デプロイメント、サービス、イングレス、HPA。単純な YAML から JSON へのコンバータは、最初のドキュメントを読み取り、残りを黙って削除します。これは、インフラストラクチャ作業にとって非常に危険な障害モードです。優れたコンバータは、ドキュメントごとに 1 つの要素を含む JSON 配列を生成し、見つかった数を通知します。

Helm、アンカー、および「出力にアンカーがないのはなぜですか?」

YAML アンカーとエイリアスは、1 つのファイル内のブロックを重複排除できます。 Helm テンプレートはさらに進んでおり、レンダリングされるまではまったく YAML ではありません。レンダリングされた出力 (helm テンプレート / helm get マニフェスト) のみを変換し、生のテンプレート ファイルは変換しません。アンカーをその値に統合するのは正しい動作です。JSON には別名がないため、コンバータはそれらを逆参照する必要があります。

タイピングの罠

• ブール値: 「y」、「yes」、「on」などのバージョンと名前は、YAML 1.1 ではブール値です。 Kubernetes では、「on」などのイメージ タグや「1.10」などのバージョンは、典型的なサイレント破損ケースです。常にソース内で引用します。
• ポートとリソース:containerPort:8080 は int です。文字列としての「8080」は、型付きフィールドの API によって拒否されます。 JSON は区別を明確に保ちます。
• メモリ量: 128Mi は両方の形式の文字列です。これは YAML ではなく Kubernetes によって解析されるため、正しいです。
• 環境値: env 値は仕様による文字列です。値: YAML の 3000 は数値 3000 になり、API は拒否します。これは最も一般的なマニフェスト バグの 1 つであり、JSON の出力を見ればすぐにわかります。

実践的なワークフロー

1. 最初にレンダリングします (Helm の場合): Helm テンプレート mychart > rendered.yaml。
2. マルチドキュメントサポートを使用して JSON 配列に変換するため、リソースはドロップされません。
3. クラスターの内容と比較します: kubectl getdeploy web-app -o json を JSON diff ツールと比較すると、重要な変更がすぐにわかります。
4. 自信を持ってパッチを適用: JSON パッチ (RFC 6902) と戦略的マージ パッチは、明確な JSON に対して簡単に作成できます。

どちらのステップもこのサイトのツールでカバーされています。変換には YAML から JSON へ、結果と kubectl 出力との比較には JSON Diff が使用されます。クラスター データはマシンから送信されません。