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のシンボルは、船の操縦桿の舵輪だから、もしかすると宇宙戦艦が好きなのかもな!
ジェネレーションギャップを感じます・・・