K8s 5分講座#09 Pod
今日は「Pod」について話していく。

Pod…初登場ワードですね。よろしくお願いします!

Podの最小構成
K8sを利用する目的は、クラスタのワーカーノードとして構成されたマシン群にコンテナという形でアプリケーションをデプロイすることにある。

これまでの講義で出てきた単語がたくさん出てきていますね。

ここで注意して欲しいのはK8sはワーカーノードに直接コンテナをデプロイするわけではない、と言うことだ。

直接ではない、と言いますと…?

コンテナはPodと呼ばれるK8sオブジェクトにカプセル化される。

出てきましたねPod。Podはコンテナが入っているカプセルなんですね。

Podは、アプリケーションの単一インスタンスであり、K8sで作成できる最小のオブジェクトだ。

拡張するとき
最もシンプルなケースとして、単一のノードのK8sクラスタで、アプリケーションの単一インスタンスを1つのコンテナで実行し、Podにカプセル化したとする。


この図のような最小構成ってことですね。

このアプリのユーザ数が増え、拡張する必要が出てきた場合、どう増やすのが良いと思う?

アプリケーションが動いているコンテナを2つに増やすのはどうでしょう?

残念、Podが最小のオブジェクトと言ったはずだ。よって、同じアプリケーションの新しいコンテナインスタンスを既存のPodに立ち上げるのではなく、Podごと新しいものを作成する。


K8sクラスタ上の別々のPodでアプリケーションのインスタンスが動作するんですね。

更にユーザ数が増えて今のノードリソースでは処理しきれないほどになってきたら、クラスタに新しいノードを追加して、そこにPodをデプロイすれば良い。


クラスタに新しいノードを追加することで、物理的な容量が拡張されますね。

ここで覚えて欲しいのは、Podはアプリケーションを実行するコンテナと1体1の関係が原則ということだ。

拡張する時はPodごと追加して、縮退する時はPodごと削除するということですね。

そうだ。需要増に伴って既存のPodに同じ種類のコンテナを追加することはしない。

- Podはコンテナをカプセル化するK8sオブジェクト
- PodはK8sで作成できる最小のオブジェクトでコンテナと原則1体1の関係になる
- スケーリングする際もPod単位で行う
Podとかカプセルとか、もしかしてK8s開発者はSF好きなのかもですね

K8sのシンボルは、船の操縦桿の舵輪だから、もしかすると宇宙戦艦が好きなのかもな!

ジェネレーションギャップを感じます・・・

