Kubernetes（AKS）をやさしく学ぶ旅　その6 - SE（しがないエンジニア）のブログ

まだまだつかめない Kubernetes の世界。。

その1～その5まで紹介してきている Kubernetes ですが、まだまだ、色々と理解しきれていないところがあります。そこで、今回は Pod についてもう少し掘り下げてみようと思います！

Pod とは

以前の記事で Pod の大まかな部分は記述していますが、設計思想を含め、Pod はどう扱っていくのが最適なのかの細かな話はできていません。

コンテナーの世界では「1コンテナーで1プロセス」という鉄則があるようで、シンプルな機能をもつアプリケーションにすることが理想とされています。ただし、Web - Proxy、SSL、OAuth等、メインコンテナーに付随する1つのまとまりになったコンテナーを作るのが便利なようです。Kubernetes では関連するコンテナーの集合体を Pod と呼びます。また、Podの特性を下記に記載します。

・アプリケーションのスケールアウトは Pod 単位

・Pod 内のコンテナーはネットワークとストレージを共有

Pod のデザインパターン

Pod をどのように設計していくかは作成するアプリケーションの機能・非機能要件によります。

・同一 Node で実行する必要があるか？

・同じタイミングでスケールする必要があるか？

プロキシの役割をするコンテナー

元は HTTP にしか対応していない Web アプリケーションを HTTPS に対応させる場合です。

f:id:btsn:20191014225255p:plain

上記のケースの場合、SSL Proxy Container から本来の HTTP Web Application に対しては http://localhost/ でアクセスできるので既存の Web Application のコードに対して変更は不要になります。

認証処理を行うコンテナー

Web Application が OAuth 認証を必要とする場合は Web Application 本体とは分離して認証処理の Pod を配置する必要があります。

f:id:btsn:20191014231145p:plain

上記2例は以上にして、注意点があります。それは Kubernetes のデプロイの最小単位は Pod だということです。アプリケーションを今後拡張していく上で将来的にどうスケールしたいかがデザインパターンを決定する上で重要になります。Web Application において前段のフロントとバックのビジネスロジックは必ずしもスケールのタイミングが一緒ではない（可能性が高い）ため、Pod は別管理にした方が望ましくなります。