‫やれやれです｡ Kubernetesのコマンドラインにアクセスできるようになるのを､
‫ずっと待っていたのではないでしょうか｡
‫でも､ 幸いなことに､ いくつかのコンセプトはクリアできています｡
‫では､ さっそくコマンドラインを見てみましょう｡
‫まず確認しなければならないのは､ Kubernetesのセットアップを行ったとしても､
‫それが実行されていることです｡
‫その方法は､ Docker版とかCompose版とかと似ていますね｡
‫シェルでkubectlと入力すれば､ K
‫U B E C T Lバージョンになります｡
‫バージョンに戻すといい｡
‫これはDockerのように､ クライアント版とサーバー版を取得するのと同じです｡
‫これらのコマンドラインツールが行っているのは､ リモートのAPIとの対話であることを忘れないでください｡
‫この場合､ あなたのマシンのAPIが原因でしょう｡
‫DockerやSwarm､ Composeと同様に､ kubectlコマンドラインはリモートのKubernetes
‫APIと対話することができます｡
‫これで､ クライアント・サーバーのバージョンを取り戻したので､
‫もう大丈夫です｡ もしエラーが出たのなら､ おそらくサーバーのバージョンが表示されず､
‫接続できないと言っているのでしょう｡
‫つまり､
‫なぜか設定が間違っていて､ ローカルのCLIがKubernetesサーバーと会話できないのです｡
‫私なら､
‫どのように展開したかを確認して､ 実行するようにします｡
‫Docker Desktopを使っている場合は､ Dockerを起動して､ Kubernetesが起動していることを設定で確認する必要があるかもしれませんね｡
‫他の方法であれば､
‫インストールビデオを確認すればいい｡ もし何か問題があれば､ Q&AやSlackで連絡してください｡
‫わかりました｡ KubernetesでPodをデプロイするには､
‫実に2つの方法があります｡ コマンドラインですべてのオプションを指定する方法もあります｡
‫あるいは､ YAMLを使うという手もある｡
‫これは､ Swarmのサービスやスタックとコンセプトが似ているかもしれませんが､
‫もちろん､ 本当に突き詰めていくと､ いろいろなものが隠れているんです｡
‫このような例えをするのは嫌ですが､
‫コマンドラインかYAMLかの2択になります｡
‫少し､ コマンドラインに注目してみましょう｡
‫ここで最初に実行するコマンドは､ kubectl
‫runです｡
‫つまり､ Dockerの実行に似ていますね｡
‫私のNginxですが､ 好きなように呼んでください｡
‫これは､ デプロイメントの名前です｡ そして､ --image､
‫ここで画像名を指定します｡
‫今まで通りNginxを使って､ リターンを押してみましょう｡
‫最近のKubernetesの一部のバージョンでdepreciatedの警告が出ている場合は､
‫ちょっと無視しましょう｡
‫それについては､ また少しお話します｡
‫でも､ とりあえず､ 今何が起こったか見てみましょう｡
‫それをkubectlのgetコマンドで利用することができます｡
‫kubectl get podsを実行します｡
‫そこに表示されるのは､ あなたの名前のオブジェクトと､
‫その末尾にあるいくつかの文字で､ 1 in 1が実行されていることがわかるはずです｡
‫これは､ Swarmのサービスの概念に非常に似ていて､
‫デフォルトでは1つのレプリカを走らせるだけだったんだ｡
‫そこに名前が書いてあるんです｡
‫なんでそんな変な名前なんだ？
‫さて､ これはkubectlのrunコマンドの動作に関係があります｡
‫今のVer.1のままランを使う場合｡
‫14､
‫それは技術的にはDeploymentコントローラを使用することです｡
‫そのDeploymentコントローラはReplicaSetコントローラを作成する｡
‫そのReplicateSetコントローラがPodを作成する｡
‫この場合､ レプリカは1つだけです｡
‫だから､ ポッドは1つでいいんです｡
‫kubectl get allを実行すると､ そこにあるすべてのオブジェクトが一覧表示されます｡
‫ポッドが見えるようになる｡
‫サービスはひとまず無視｡
‫それについては､ また少しお話します｡
‫Deploymentで､ ReplicaSetで｡
‫オブジェクトモデルとKubernetesの異なるレイヤーを見てみると､
‫ここでは1つのコマンドを実行しただけなのに､ 実際には複数のオブジェクトが作成されていることがわかります｡
‫では､ 私の図面を見て､ これらのオブジェクトが互いにどのように関連しているかを説明しましょう｡
‫Kubernetesでお分かりのように､ 以前のSwarmやDockerそのものよりも､
‫より多くの抽象化と制御のレベルを持つようになったのです｡
‫この場合､ kubectlを実行すると､ バックグラウンドで､
‫複数の異なる抽象化を自動生成してくれました｡
‫Podを作成し､ その周りにReplicaSetを作成し､ その周りにDeploymentを作成しました｡
‫それでは､ これらの抽象的な表現がどのように関係し合っているのか､
‫図面に沿って説明します｡
‫注意点として､ 下にはDockerが動いています｡
‫それから､ Kubernetesを管理しているコンテナもいくつか起動していますが､ これについては今は触れません｡
‫ここでは､ Kubeを実行するためだけに､ 別のコンテナのセットを用意していることを確認しましょう｡
‫kubectl を実行すると､
‫明らかに Nginx コンテナが作成されました｡
‫しかし､ 制御のレベル､ つまり抽象度が違うのが面白いところです｡
‫ここで最初に紹介するのは､ ポッドです｡
‫この場合も､ このポッドの中で1つ以上のコンテナを実行することができる｡
‫そのポッドの一部として､ 必要であればボリュームを作ることも可能でした｡
‫ポッド用のNICを作成した｡
‫ポッドの作成方法は､ kubectl
‫runと入力すると､ Deploymentが作成されました｡
‫DeploymentコントローラはReplicaSetを管理する｡
‫私たちは､ 複数の抽象的なレベルを持っています｡
‫そのDeploymentは､ ローリングアップデートやBlue/Green
‫Deploysなど､ Swarmサービスのようなオーケストレーションサービスを考えるときに思いつくようなことをやってくれるんです｡
‫そのDeploymentが作成されると､ 1つのReplicaSetが作成されます｡
‫それ自体が､ もうひとつのコントローラーなのです｡
‫ReplicaSetの仕事は､ 要求した数のPodが現在稼働しているかどうかを確認することです｡
‫今回は､ すべてデフォルトのままとしました｡
‫つまり､ Deploymentは1つのReplicaSetを作成し､ そのReplicaSetは1つのPodを作成しました｡
‫このような異なる抽象度のものをそれぞれコントロールすることができるのです｡
‫コマンドを打ち込んでDeploymentを制御することができました｡
‫ReplicaSet､ またはPodそのものを直接管理しますが､
‫通常このような状況では､ 常にDeploymentそのものを管理することになります｡
‫そうすれば､ あとは勝手にやってくれる｡
‫なぜ真ん中のReplicaSet自体が存在するかというと､
‫Swarmのサービスレプリカを作るときのように､
‫このPodのコピーをもう一つ作りたい場合です｡
‫この絵では､ そのポッドのコピーを作りました｡
‫それは､ レプリカを2つに拡張した場合です｡
‫Swarmのやり方と非常によく似ています｡
‫ReplicaSetの仕事は､ やはり､ 2つのPodが同一のテンプレートで実行されていることを確認することです｡
‫Deploymentの仕事はReplicaSetの構成を管理することです｡
‫次の講義に飛ぶ前に､ 先ほどrunコマンドで作成したこれらのリソースをdeleteコマンドですべて削除してみましょう｡
‫これは､ Dockerがremoveコマンドを持っていたのとは異なる｡
‫さて､ 今回はkubectlでdeleteコマンドを使っています｡
‫オブジェクトの種類を指定し､ 次にそれ自身の名前を指定していることに気づくだろう｡
‫そこで､
‫デプロイメントスペース､ デプロイメントの名称をやっています｡
‫そうすると､ その下にあるものがすべて削除されます｡
‫ReplicaSet､
‫ポッドそのもの､ そしてその中のコンテナ｡
‫同じようにget allコマンドですぐに確認できます｡
‫そこには､ KubernetesサーバそのものであるクラスタIPしか表示されません｡