‫このYAMLが少しは意味を持ち始めるといいのですが､
‫ここでは本質的にこのYAMLをゼロから作成する方法を学びます｡
‫KubernetesのYAMLフォーマットを学び始めたとき､
‫私はまずkubernetesのドキュメントにある例を使いました｡
‫ioのサイト､ または他の場所からかもしれません｡
‫他の場所については､ Dockerと同じように､ ブログなどはすべて時代遅れになってしまうのです｡
‫Kubernetesについては､ 特にデプロイメントやポッドなどのコアな部分については､ 時間の経過とともに変化しているものがあります｡
‫フォーマットを微調整したのです｡
‫APIに含まれるバージョンが変更になりました｡
‫今のものにこだわりたい､
‫つまり､ ゼロから始める方法を知る必要がある｡
‫ファイルを変更するタイミングは､
‫ドキュメントをランダムに読み返して何かが変わったかどうかを確認するのではなく､
‫どうやって知ることができるのですか？
‫この部分は､ 私がこのようなことを理解するのに時間がかかったこと､
‫そして､ ある種の既存のテンプレートを使用せずにファイルを構築する方法についての技術であると思います｡
‫前回の講義で4つのタイプの話をしましたが､
‫そのkindの根幹となるキー､ つまりリソースタイプにまず注目したいのです｡
‫クラスターでそれらのリストを得ることができるからです｡
‫今回のセットアップテストのクラスタでは､ そのほとんどが全員同じになります｡
‫実運用に入り､ サードパーティのものをクラスタに追加し始めると､
‫サードパーティのツールがAPIに新しいリソースオブジェクトを追加できるため､ 使用しているものによってこのリストは長くなっていきます｡
‫kubectl api-resourcesをやってみましょう｡
‫少なくとも何十種類ものオブジェクトが返ってくるので､
‫スクロールして何時間でも話していられそうです｡
‫そんなことはしない｡
‫デプロイメント､ Pod､ ReplicaSets､ Servicesなど､
‫そのうちのいくつかについては､ すでにお話しました｡
‫それらは､ 標準的なアウトオブザボックスです｡
‫この後の多くは､ あなたが触れることはないかもしれません｡
‫Kubernetesには非常に多くの機能があり､
‫実際にすべての機能を必要とすることはないかもしれません｡
‫これらをすべて通して暗記することは､
‫それほど重要ではありません｡
‫右側にこのような欄があるのがわかると思います｡
‫これがYAMLファイルに書かれる内容です｡
‫ポッドを作成する場合､ ここにkind podがあることがわかります｡
‫デプロイメントを作成する場合､
‫デプロイメントという種類があります｡
‫また､ APIグループも表示されます｡
‫そのAPIグループは､ APIのバージョンに関連しています｡
‫すぐに分かると思います｡
‫これは必ずしも規定されたマニュアルを与えてくれるわけではありません｡
‫しかし､
‫もし私がここに座っていて､ ポッドを作る必要があると言ったら､ このリストに目を通して､ リソースの種類でポッドを探すでしょう｡
‫という種類を見ることになる｡
‫それがYAMLに書くべきことだとわかっているのです｡
‫APIグループがあれば､
‫どこで使えるバージョンが見つかるかがわかります｡
‫なぜなら､ デプロイメントは時間とともに複数のバージョンを持つようになったからです｡
‫v1beta1､ v1beta2がありました｡
‫実際には､ 古いものと新しいものがあるので､ API内でも移動しており､
‫ちょっと混乱することもありますね｡
‫このリストを見ると､ 実は上にデプロイメントがあり､
‫下にデプロイメントがあることがわかると思います｡
‫両者の違いは､ この真ん中の列､ APIグループだけです｡
‫そのAPIグループは､ APIの中でこのタイプのリソースがアクセス､
‫作成､ 削除などできる場所である｡
‫これは少し雑多になりますが､ このようなものを扱うようになると､
‫ここで2種類のデプロイメントを見るようなケースを見たときに､
‫少し時間を費やすことになります｡
‫どれを使えばいいのでしょうか？
‫さて､ 実際に調査してみると､ ドキュメントやAPIガイド（これから少し見ていきます）に記載されています｡
‫この場合､ デプロイメントでは､
‫新しいバージョンのものが､
‫最新バージョンでは､ アプリのAPIとなります｡
‫それに付随して､ 種類､ プラスAPIバージョンを把握するための次のコマンドは､
‫kubectl API versionsコマンドです｡
‫これで､ 心配する必要のあるAPIの異なるバージョンのリストが短くなりました｡
‫デプロイメントの場合､
‫ここに見覚えのあるものが出てくるはずです｡
‫アプリとデプロイメント用のエクステンションがあるのを覚えていますか？
‫それらがここに現れてくるのを見ることができるのです｡
‫技術的には､ v1beta1のAPIの拡張があります｡
‫アプリのAPIがあり､
‫そこには3種類のバージョンを見ることができます｡
‫おそらく､ 古いベータ版ではなく､ V1のアプリを使いたいのでしょう｡
‫しかし､ このAPIは新しいものを展開する一方で､
‫非推奨のバージョンにしがみついているようなところがあるのがわかる｡
‫この方法では､ 基本的に､ 多くのバージョンが経過し､ 不要になったものがAPIから引き抜かれるまで､
‫古いYAMLが壊れることはありません｡
‫もしあなたがKubernetesの初期の頃､ APIバージョンにextensions/v1beta1と書かれたYAMLファイルを使っていて､
‫その種類がデプロイメントだった場合､ YAMLの寿命の間に通常何が起こるでしょうか｡
‫しかし､ APIが変更され､ apps
‫APIと呼ばれるようになり､ バージョンも異なるので､
‫デプロイの種類はそのままですが､ APIのバージョンをapps/v1に変更することになるでしょう｡
‫それを知る方法は､ 検索をする必要があって､ ドキュメントを見るからです｡
‫という例を見ると､ ああ､ ちょっと｡
‫今はアプリと書いてありますね｡ もうエクステンションとは言わない｡
‫それは変ですね｡ 調べてきますね｡ そして､ GitHubでそれに関するKubernetesのissueをいくつか見つけます｡
‫ちょっと雑な感じですね｡ 常に変化しているものすべてに明確な非推奨リストがあるわけではありませんから､
‫何かと問題になることがあります｡
‫これがうまくいかないとわかるのは､ 古い YAML を新しいクラスタに適用したときに､
‫「この API のバージョンはもうサポートしない」と表示されるときです｡
‫とか､ この種類はどうなんだろう？
‫そうすると､ 「これは問題だ」とわかるような､ いい感じのエラーが出るんです｡
‫そうすれば､
‫何が時代遅れなのか､ すぐに検索できるのではないでしょうか｡
‫私が言いたいのは､ 種類とAPIバージョンが一緒になって､
‫どのリソースを取得するか､ そのリソースにどのAPIバージョンを使えるようにするかを決定しているということです｡
‫この2つは､ YAMLを作成する前に把握すべき最初の事柄です｡
‫それができたら､ 次はメタデータの部分を作ります｡
‫そこに必要なのは､
‫作成するリソースの名前だけです｡
‫素敵な名前をつけてあげてください｡
‫そして､ スペックに臨むのです｡ 作成するリソースによって仕様が全く異なるため､
‫そこで全てのアクションが発生するのです｡
‫ストレージを作成する場合とデプロイする場合では､ YAMLがかなり異なることは想像がつくと思います｡
‫次の講義では､ さまざまなリソースのためにYAMLに入れることができる､
‫あらゆる異なる仕様のAPIを探索するのに役立つkubectlコマンドをいくつか見ていきます｡