‫正直に言います｡
‫初めてKubernetesのYAMLを見たとき､ 私は本当に怖くなりました｡
‫Compose形式よりもずっと複雑な感じがしました｡
‫それには理由があるんです｡
‫柔軟性が増し､ できることが格段に増えます｡
‫しかし､ それには代償が必要です｡
‫それは､ 基本を学び､ これらのファイルの作り方を学ぶというハードルを越えることです｡
‫初めてこのファイルを手にしたときは､
‫何が何だかわからないほど､ たくさんのことが書かれていましたね｡
‫KubernetesのYAMLを学ぶのに最適だと思う方法でこれを分解してみるつもりなので､
‫もしあなたがこれに関して少し混乱していると感じたら､
‫これらのビデオを再視聴してみてください｡
‫まず最初に､ 技術的にはJSONで書くこともできますが､
‫YAMLは人間にとって操作しやすく読みやすい傾向があり､
‫JSONはコンピュータにとってより良いものです｡
‫バックグラウンドで何が起こっているかというと､ 私たち人間の標準はYAMLを書き､
‫それをJSONに変換してくれることです｡
‫技術的にはJSONを書くこともできますが､
‫人間が書くKubernetesの標準はYAMLです｡
‫先ほども言ったように､ これらのファイルは混ぜて使うこともできます｡
‫多くの異なるリソースを1つのファイルにまとめたり､
‫逆にリソースごとに1つのファイルを作成することも可能です｡
‫どうでもいいことですが｡ それはあなた次第です｡
‫コマンドの動作は同じです｡
‫私たちはこれをマニフェストと呼んでいます｡
‫リソースの完全な記述はマニフェストであり､
‫そのマニフェストには要件があります｡
‫YAMLファイル内のルートキーについて､ これらの要件が表示されます｡
‫ルートとは､ 一番最初にあることを意味します｡
‫それは､ APIのバージョンから始まります｡
‫優しさがある｡
‫メタデータがある｡ そして､ スペックもある｡
‫そのため､ これらのリソースが機能するためには､ すべてのファイルでそれらを確認する必要があります｡
‫そして､
‫コマンドラインからいくつかの簡単な例を見てみましょう｡
‫Docker Masteryのレポを見ると､ k8s-yamlディレクトリがあり､
‫ここにいくつかの例を入れています｡
‫このディレクトリがない場合は､ git-pull を行ってリポジトリの最新更新を取得する必要があるかもしれません｡
‫この講座を受講したことでレポに何らかの変更があったとしても､
‫それはそれで問題ありません｡
‫git-stash を使ってそれらの変更を一時的に隠しておき､ それから git-pull
‫を実行することもできます｡
‫あるいは､ 別のディレクトリにコピーダウンしてください｡
‫この部分は､
‫このKubernetesのものが新しいので､ 別の場所にクローンすればいいだけです｡
‫そのため､ 後からこのページをご覧になる方の中には､ 最新のアップデート情報をお持ちでない方もいらっしゃるかもしれません｡
‫ここで最初の例は､ 単なるポッドです｡
‫これはおそらく私たちが作ることができるもっともシンプルなYAMLです｡
‫このコースの最初のほうで言ったように､ それはdocker
‫runのように作成するだけなので､ そんなに多くのpodを作ることはありません｡
‫それは､ あまりやりたくないことですね｡
‫ローリングアップデートを搭載していない｡ 展開ではないんですね｡
‫トラブルシューティングが必要になったときや､
‫ローカルで簡単なものを実行する必要があるときは､ こうすればいい｡
‫同じ4つの要件があることにお気づきでしょうか｡
‫APIバージョン､ 種類､ メタデータ､
‫仕様｡
‫それらが何であるかは､ 次回の講義でお話しします｡
‫とりあえず､ この種類がどのようにポッドなのかを見てほしいんです｡
‫そして､
‫metadataはname属性を持つ｡
‫このキーは､ すべてのYAMLオブジェクトの必須キーです｡
‫ドッカーランに名前が必要なように､ 全てにその名前が必要なのです｡
‫すべてのDockerオブジェクトは名前を持つ必要があります｡
‫Kubernetesも同じです｡ ここでのスペックは肉です｡
‫その話はまた今度｡ もう1度､ デプロイメントを見てみましょう｡
‫ここでは､ その同じコンテナのレプリカを2つ持つ1つのデプロイメントを紹介します｡
‫大きさは2倍くらいでしょうか､
‫それなりの理由があります｡
‫なぜなら､ 考えてみれば､ そのデプロイメントリソースを作成し､
‫それがReplicaSetを作成していることになるからです｡
‫そして､ それがポッドの作成です｡
‫スペック領域は､ 定義しなければならないことが増えるので､ 少し複雑になりますね｡
‫また､
‫APIのバージョンが若干異なることにお気づきでしょう｡
‫これは種類に関連しており､ この場合の種類はデプロイメントです｡
‫資源を意味するようなものですね｡
‫そして､ APIバージョンはその種類のAPIのバージョンです｡
‫あとは､
‫少しでも理解していただければ幸いです｡
‫見た目はComposeファイルに少し似ていますが､
‫明らかにフォーマットが違います｡
‫ですから､ 特にComposeとKubernetesの間を行ったり来たりしていると､
‫混乱することもあるかと思います｡
‫この例では､ 同じ種類のデプロイメントについて､
‫サービスとデプロイメントを1つのファイルにまとめました｡
‫このように､ 1つのファイルに複数のマニフェストがある場合は､ 3つのダッシュで2つのマニフェストを分割します｡
‫これは､
‫Kubernetesに「このオブジェクトはユニークですよ」と伝えるYAML的なものです｡
‫そして､
‫次のパーツは新しいオブジェクトです｡ 手に負えなくなるまで､ いくらでもこの中に入れておけるんだから､
‫もう壊すしかない｡
‫この最初の部分で､ APIのバージョンは､ サービスリソースの種類のV1であることがわかります｡
‫ここでいうkindは､ おそらくリソースでいいのでしょうが､ kindと呼んでしまっているのでしょう｡
‫またまたメタデータです｡ 名前がないとね｡
‫どのリソースを作るかによって､ 仕様も何もかもがまったく違ってきます｡
‫先ほどと同じようなデプロイですが､ 今回はレプリカを3つ用意し､
‫名前も少し変えていますが､ それ以外は同じNginxです｡
‫それを見ただけで､ すごいな､ と思いますよね｡ これはかなり複雑に思えるので､
‫私はどのように開始するかを知っているように､ 私は格納するつもりですテンプレートが必要でなければなりません｡
‫何十種類もあるリソースの種類と､ それぞれの設定方法について､
‫すべてを説明したドキュメントページはありません｡
‫それは残念ながら､ コンポーズで得たもので､ 長いけれどもいいシングルだったということです｡
‫DockerのドキュメントにあるComposeフォーマット全体のウェブページです｡
‫この場合､
‫Kubernetesでは､ 複雑すぎるため､
‫それが得られません｡
‫1つのアプリでもないんです｡ 実際には､ 後で説明するCRDと呼ばれるものを追加することで､
‫より多くのリソースタイプを追加することができます｡
‫そこに踏み込めばいいんです｡ つまり､ 基本的には､ より多くのリソースタイプでKubernetesを拡張できることを意味します｡
‫サードパーティのものが増えれば､ このYAMLにさらに多くのオプションが追加される｡
‫それはKubernetesならではですね｡
‫SwarmやDockerはそれを許さない｡
‫そのフォーマットは決まっていますが､ これはクラスタに何がインストールされているかによって､
‫かなり拡張可能です｡