概要
KubernetesではPod内の各コンテナのネットワークが共有されておりローカルホスト（127.0.0.1）上のポート番号で相互にアクセス可能で、以下のようなパターンを実現できる
- Sidecar（サイドカーパターン)
- Ambassador（アンバサダーパターン）
- Adapter（アダプターパターン）
各パターンの解説
サイドカーパターン
Pod内の機能を独立して用意できる
ログの出力はメインのアプリ、ログの転送部分はサイドカーとして共通の機能をコンテナで用意
そのほかに、同期サービスやプロセスのウォッチャーなど
アンバサダーパターン
外部プロセスとの接続をプロキシする構造のこと。例えば本番と開発環境で異なるDBへ接続する必要があるときに、アプリ側はローカルホストを参照するようにしておき、データベースへの接続をアンバサダーコンテナが行う
アダプターパターン
Podに接続するインターフェイスをアダプターパターンで共通化する考え方。例えばアプリケーションのモニタリングを行う際に、アダプターコンテナが一貫したAPIを提供することによって監視システムからの要求にこたえる。とくにモニタリングにおいては、異なる環境下に配置されているアプリケーションを動的に検出して監視に必要なシステムを一環して提供できることが重要なため、これが利用される。ただし、多くの場合DaemonSetによって、ワーカーノードごとに配置される。
気づいたことなど
- コンテナ単位ではなくPod単位で管理する意味を感じた
- いわゆるxxxagentのようなものはアダプターパターンということになりそう
- ネットワークの共有はPodが提供する基本機能なのか確認したい
→ KubernetesのネットワークモデルのIP-per-podの説明を見ると基本機能でよさそう
その他
調べてる最中に見かけたのでついでにメモ
- Serviceについて
Loadbalancerタイプの場合、外部のロードバランサーを使用することになるとのこと、それで、いずれかのノードで起動しているサービスに接続し、そこからまたどこかのノードにあるPodにルーティングされる模様（そのノードのPodに限らないという意味）