‫Docker Swarmと同様に､
‫実行中の異なるコンテナのことをレプリカと呼び､ レプリカの数とscaleコマンドでスケールアップ､
‫スケールダウンを決定します｡
‫Kubernetesの時も､
‫それと同じような経験をしました｡ kubectlのコマンドラインとその動作を確認してみましょう｡
‫まず､ 新しいDeploymentを開始する必要があります｡
‫では､ 戻ってkubectl run my-apacheを実行してみましょう｡
‫-- image httpd.
‫Nginx とは異なり､ 今回は Apache ウェブサーバを実行します｡
‫Apache はデフォルトでログを記録してくれるので､ 少なくともログを見ることができるというのが主な理由です｡
‫これらのオブジェクトがすべてデプロイされたかどうかは､ 別の get
‫all で確認することができます｡
‫ReplicaSetとポッドで希望と電流の準備ができたら､
‫次のコマンドを実行する準備ができていることがわかります｡
‫このデフォルトの実行では､ 1つのポッドまたはレプリカが得られます｡
‫それを2にスケールアップしてみましょう｡
‫ここで､ --replicas 2 と入力したのは､ scale
‫コマンドです｡ オブジェクトの種類も入れました｡
‫つまり､ Deploymentと､ そのDeploymentの名前です｡
‫しかし､
‫私がここで使っているのは別の形式であることにお気づきでしょうか｡ Deploymentではなくdeployを使い､
‫スペースではなくフォワードスラッシュを使いました｡
‫ここでは､ Kubernetesのコマンドラインの柔軟性にまつわる話を少しします｡
‫多くのコマンドには､ コマンド自体の短縮版があることにお気づきでしょう｡
‫コマンドの異なる部分は､ スラッシュとスペースのように様々な方法で省略したり代用したりすることができます｡
‫そんな感じです｡ この場合､ scale
‫deploy / my-apache は､ scale space deployment
‫space my-apache と同じになります｡
‫それらは同じ等価物でしょう｡
‫基本的には､ デプロイメントオプションが表示される多くの場所で､ デプロイ､
‫デプロイメント､ デプロイメントを複数の状態で指定することができるかもしれません｡
‫これは､
‫コマンドラインの他の部分でも同様で､ 複数形でも単数形でも同じように機能することがあることにお気づきでしょう｡
‫あるいは､ コマンドの一部を省略することもあります｡
‫正直なところ､ 年月が経つにつれて､ これは変わってきました｡
‫だから､ どの部分を省略したり､ スペースをスラッシュで入れたりしてもいいのか､
‫あまりわからないんです｡
‫でも､ 自分のやり方に慣れると､ それだけでうまくいくようになると思うんです｡
‫ここで､ もう一度､ kubectlで全部取得を実行してみると｡
‫ポッドが2つあることにお気づきでしょうか｡
‫一番下のReplicaSetは､ 希望する状態が2つで､
‫2つが実行されていることがわかります｡
‫ここでの一般的な概念で言えば､ まさにSwarmのサービスが行っていることです｡
‫お客様の要件に応じて､
‫レプリカをスケールアップしたり､ スケールダウンしたりすることができます｡
‫この場合､ タスクではなくポッドの話だけです｡
‫スケールコマンドを行ったとき､ バックグラウンドで何が行われていたのか､
‫基本的なことを説明します｡
‫抽象化のレベルが増えたので､ これらのレベルが互いにどのように反応するかを理解する必要があります｡
‫scaleコマンドを入力したとき､ 技術的にはDeploymentの仕様を更新していることになります｡
‫Kubernetesでは､ すべてのものに仕様があります｡
‫このDeploymentの仕様では､ ReplicaSetが2つのレプリカのセットに変更されています｡
‫そして､ そのReplicaSetコントローラは､ それを2つのPodに変更し､
‫各レプリカに1つのPodを用意することにしたのです｡
‫この場合､ ノードは1つしかありませんが､ どのノードにポッドを割り当てるかは､
‫コントロールプレーンが決定します｡
‫そして､ マルチノードの場合､ kubeletエージェントはそのPodを割り当てられ､
‫それを実行してローカルのDocker Engine上にコンテナを作成します｡
‫これは､ 単に別のコンテナを開始するためにバックグラウンドで行われている多くの作業のように見えますが､
‫実際には本当に速く行われます｡
‫実際､
‫Swarmとほぼ同じ速度で発生します｡ 一般的に､ 1台のマシンの場合､
‫1秒とか2秒とか､ そういう話になってきますね｡
‫Swarmの場合､ すべてが単一のバイナリに収まっていることが利点の一つです｡
‫コンテナの起動も含めて､ 同じプロセスの中で行われているので､
‫より速く実行できます｡
‫Kubernetesでは､ このような抽象化されたレイヤーを追加することができます｡
‫そのため､
‫DockerやSwarmと比べると若干の遅れが生じます｡
‫しかし､ 本当にほとんどの場合､ それは無視できるものです｡
‫その代償として､ このような抽象化された異なるレイヤーによって､ より多くの柔軟性と制御性を得ることができるのです｡
‫おお！ これで片付けないでください｡
‫次回の講義では､ Kubernetesで何が起こっているのかを検査する際に､
‫このApacheコンテナを使用する予定です｡