‫これまで使ってきたコマンドの中には､ ジェネレーターと呼ばれるちょっとした自動化機能がついているものがあります｡
‫ジェネレーターはテンプレートのようなものだと思えばいい｡
‫これらは基本的に､ コマンドラインオプションに基づいてKubernetesクラスタに適用するスペック（仕様）を作成します｡
‫run､ expose､ createといったコマンドを思い浮かべますよね｡
‫多くの場合､
‫その背後にはジェネレータがあり､ すべてのフィールドと､
‫コマンドラインで必ずしも指定する必要のないデフォルト値で必要なテンプレートを提供します｡
‫基本的に､ これらのジェネレータのポイントは､ DockerやDocker
‫Compose､ Swarmで慣れているような､ 1行コマンドを簡単に使えるようにすることです｡
‫Kubernetesでそれらの一行コマンドを使いながら､
‫より高度な設定の一部をデフォルトのままにしておくこと｡
‫本当に､ Swarmはこんなこともしてくれるんですね｡
‫Swarmは､ サービスやスタックを作成する際に､ 多くのデフォルトがあり､
‫それらはすべてバックグラウンドで起こっています｡
‫あなたが気づいていないだけです｡ この発電機もそうです｡
‫ここでは､ createコマンドでDeploymentを作成し､
‫最小限の要件を満たすためにいくつかのオプションを与えている例です｡
‫残りのスペックをジェネレーターで埋めてくれます｡
‫これらのジェネレーターは､ 作成するものの種類によって異なります｡
‫サービスであれ､
‫デプロイメントであれ､ ジョブであれ､ cronジョブであれ｡
‫その他はまた後日｡
‫これらのジェネレータは､ Kubernetesの各バージョンが登場するたびに､
‫実際には時間の経過とともに変化する可能性があります｡
‫その仕様のプロパティを1つ､ 2つ変更するかもしれないのです｡
‫だから､ これらにはバージョンがある｡
‫ドキュメントを見ると､ KubernetesのYAMLが表示されることがあり､
‫そこにはベータ版について書かれています｡
‫それは､ ジェネレーターが最初に作られたときはベータ版で､
‫その後､ 成熟したジェネレーターに卒業するとV1ができることが多いのです｡
‫コマンドラインからジェネレータのリストを得ることはできません｡ なぜなら､
‫異なるコマンドや異なるオプションにまたがって､ どのジェネレータが使われる可能性があるかがわかるからです｡
‫これらのコマンドの中で､ クラスタに対してコマンドを入力した場合に何が生成されるかを確認する最も簡単な方法は､
‫2つのオプションを使用することです｡
‫ドライランというのは､ 入力した内容の出力を実にきれいに表示するもので､
‫それはちょっと見てみましょう｡
‫次に-o､
‫これは出力を意味します｡ YAMLで出力してほしいと言っているのです｡
‫このコマンドを実行しても､ 技術的にはクラスタ上で実行する必要はない､
‫ということです｡
‫ただ､ 自分がやったらどうなるかということを試してみる｡
‫そして同時に､ このコマンドを終了した場合に生成されるであろうYAML出力を見せてください｡
‫基本的に小さなテンプレートが手に入ります｡
‫これを利用して､ 後の講義で使用する独自のYAMLを作成することもできます｡
‫最後に､ こちらのジェネレーター｡
‫また､ オピニオン・デフォルトと考えることもできるかもしれません｡
‫本当に意見しないんです｡
‫超小型なんですよ｡
‫通常､ 10行から15行のYAMLです｡
‫物事を始めるのに最低限必要なものだけ｡
‫でも､ 意見があるからバージョンアップしているわけです｡
‫β版卒業とか出てくるかもしれませんね｡
‫ご意見番とは思っていますが､ いいんじゃないですか？
‫開発・テスト用にいろいろと試している場合､
‫ほとんどのユースケースで使えると思います｡
‫コマンドラインでこれらのジェネレータを見るために､
‫いくつかの例を見てみましょう｡
‫最初に紹介するのは､ これまで使ってきたようなDeploymentです｡
‫createの展開図です｡
‫最後に-dry-runをつけたのがお分かりになると思います｡
‫ドライランをするだけでは､ 作成するリソースの種類を吐き出すだけです｡
‫これは､ kubectl getコマンドでリソースをリストアップしたときに表示されるリソース名と同様です｡
‫上矢印を押して､ 最後に -o yaml と入力すると､
‫そのコマンドで生成された
‫YAML 出力が表示されます｡
‫YAMLの仕様については､
‫後ほど説明します｡ とりあえず､ create deploymentコマンドを実行したときにバックグラウンドで行われたことの主要な部分を見ることができます｡
‫まず､ APIバージョン､ この種のリソースのバージョンが表示されます｡
‫そこで､ ここではapps/v1版を使用しています｡
‫種類はデプロイメントで､
‫Deploymentを作成するからです｡
‫ジョブなら､ ジョブと言っていた｡
‫サービスだったら､ サービスと書いてあるはずです｡
‫そういうことです｡ 作成したリソースには､
‫必ずメタデータが付きます｡
‫タイムスタンプはオプションで､ 実際に作成するときに自動的に生成されるからです｡
‫そして､
‫ラベルと､ ここに指定できるname属性があります｡
‫この場合､ コマンドラインで指定した内容で､ 多くの部分が埋め尽くされているのがわかりますね｡
‫テストということにしたいと伝えました｡
‫だから､ テストという名前をつけているのです｡
‫ここではDeploymentを使っているので､ サービスなどではなく､
‫アプリとみなして割り当てているのです｡
‫そのラベルテストを呼んでいるのです｡
‫これらは､ あくまでもデフォルトの状態です｡
‫そうすると､ Deploymentの仕様は､ 1つのレプリカとなります｡
‫セレクタについては後で説明しますが､ 基本的にはこのDeploymentの中でPodを選択することを決定する方法です｡
‫基本的には､
‫そのDeploymentとPodをマッチングさせるものです｡
‫そして戦略｡ 空白のままです｡
‫ここでのテンプレートはReplicaSet用です｡
‫そして､ その仕様の下に､ 作成されるコンテナが表示されます｡
‫つまり､
‫スペックというものが少し入れ子になっているんですね｡ それは､ このレイヤーの複雑さによるものですね｡
‫Podsがあり､
‫ReplicaSetsがあり､ その上にDeploymentsがあります｡
‫このコマンドを実行すると､
‫APIにそれが適用されます｡
‫ここで､ もう少し作ってみましょう｡ 2つ目は､ デプロイメントの代わりにジョブを使っていることです｡
‫通常､
‫一度だけ実行されるポッドのセットを作成したい場合に設計されます｡
‫デフォルトで再起動しないように設定される傾向があります｡
‫今回は､ 同じ画像､ 同じ名前のものを使用します｡
‫ここでは､
‫-output yamlでドライランすることにします｡ どれだけ違うか､ おわかりいただけると思います｡
‫この場合､ ReplicaSetをネストしたDeploymentのような複数階層は存在しないので､
‫複数階層のspecは必要ないのです｡
‫まず見ていただきたいのは､ こちらの方がずっと短いということです｡
‫これは､ Deploymentsの場合､ ネストしたReplicaSetを作成し､
‫それがPodを作成することが大きな原因です｡
‫つまり､ そこには複数のレベルがあるのです｡
‫ここでは､ このバッチジョブが直接ポッドを生成してくれています｡
‫上部にあるAPIのバージョンと種類が変わっているのがわかると思います｡
‫メタデータは非常によく似ていますが､ この場合はアプリのラベルを作成しませんでした｡
‫仕様書はジョブズだけのもので､ その下にある､
‫テンプレートの中にある仕様書は､
‫各コンテナ・ポッドの仕様書ですね｡
‫この1つの仕様が､ 私が依頼した数だけ作られることになるのです｡
‫デフォルトでは1つしか作成していません｡
‫つまり､ testという名前でNginxを動かしているコンテナが1つあることになります｡
‫リスタートポリシーがneverであることがわかると思います｡
‫Kubernetesでコンテナを作成する他の方法のほとんどは､
‫本当にそのような変化です｡
‫自動的に再作成､
‫または再起動を試みます｡ ジョブで､ あるいは後でcronジョブで､
‫再起動ポリシーがneverに設定されていることがわかります｡
‫というのも､
‫通常､ 仕事は一度終わると､ それだけで終わってしまうので､ そのコンテナで再作成して欲しくないのです｡
‫最後に､ exposeコマンドをやってみましょう｡
‫ドライランがあるにもかかわらず､ デプロイメントを公開すると､
‫そのデプロイメントが存在しないことに気づき､ 有効な入力がないため､ サンプル出力を提供できません｡
‫この場合､ 技術的にはDeploymentを作成する必要があります｡
‫この中では､ ドライランとアウトプットである必要はない｡
‫私たちはただ､ それを作りたいだけなのです｡
‫では､ そうしましょうか｡
‫では､ そのexposeコマンドまで戻って､ もう一度やってみましょう｡
‫そうすれば､
‫そのドライランが今度はうまくいく｡ V1のAPI版を用意する｡
‫DeploymentやJobの代わりにServiceが種類になっているのが分かると思います｡
‫それから､ 他にも似たようなレーベルがありますね｡
‫この仕様はポートやプロトコルに関するもので､ それこそがサービスであることがおわかりいただけるでしょう｡
‫ネットワークルートやIPサブネット､ TCPやUDPのポート､
‫そういったものの組み合わせです｡
‫ジェネレーターは必ずしも大掛かりなものではありません｡
‫それらを暗記する必要も､ すべての違いを学ぶ必要もないのです｡
‫なぜなら､
‫すぐに分かると思いますが､ kubectlのrunコマンドを使ったものがたくさん消えていくからです｡
‫この後の講義では､
‫コンテナを作成する方法の種類と､ 運用ワークロードで実行と作成をあまり使用しない理由について詳しく説明します｡
‫最後に公開をテストするために作成したテストデプロイメントは､
‫忘れずに削除してください｡