Kubernetes のマルチコンテナ Pod 設計パターン

[[436040]]

【51CTO.com クイック翻訳】ポッド

Kubernetes では、Pod はデプロイ可能なユニットです。アプリケーションをデプロイする場合は、Pod 内のコンテナとしてデプロイする必要があります。アプリケーションはコンテナ内で実行できますが、コンテナは Pod の一部である必要があります。 Pod 仕様には、コンテナ仕様を宣言するプロパティ container があります。このプロパティは複数形です。つまり、Pod 仕様で複数のコンテナを宣言できます。

マルチコンテナ設計の考慮事項

しかし、Kubernetes 管理者は常に、マルチコンテナ Pod よりもシングルコンテナ Pod を選択します。ポッドごとに 1 つのコンテナを使用することは、業界では暗黙の慣習となっています。マルチコンテナ Pod がどのような利点をもたらすかを見てみましょう。

Pod には 1 つの IP があり、Pod 内のすべてのコンテナは同じ IP を共有できます。 Pod にボリュームが作成されると、Pod を構成するすべてのコンテナがそのボリュームをマウントできるようになります。したがって、コンテナはストレージスペースを共有でき、ローカルホストを介して相互に通信することもできます。

この場合、なぜ単一コンテナ Pod が依然として好まれるのでしょうか。ユーザー インターフェイス (UI)、バックエンド、データベース、メッセージング レイヤーを備えた Web アプリケーションの例を考えてみましょう。 4 つのレイヤーすべてを 1 つの Pod 内の 4 つのコンテナとしてデプロイします。 4 つのコンテナーにはそれぞれ異なるリソース、構成、および運用要件があります。バックエンドとフロントエンドは顧客向けです。これらを異なるレベルにスケーリングする必要がある場合、コンテナをスケーリングすることはできず、ポッドのみをスケーリングできるため、個別に実行することはできません。したがって、Pod をスケールアップすると、データベース層とメッセージング層の複数のインスタンスも作成されますが、これは必須ではありません。

したがって、単一の Pod として管理および拡張できるため、個別にデプロイすることをお勧めします。

どのような場合に同じ Pod で複数のコンテナを使用できますか?

ケース 1 – コンテナのライフサイクルが同じ場合。

ケース 2 – 2 つのコンテナーが高度に結合されている場合。

ケース 3 – コードを変更せずにアプリケーションを Kubernetes にデプロイできるようにする必要がある場合。この場合、アプリケーション コードには Kubernetes の機能を活用するためのものが欠けています。この場合、アプリケーション コンテナー内にセカンダリ コンテナーを導入することで、この障壁を打破できます。

マルチコンテナ設計パターン

1. アダプタパターン

今日の家庭では通常、交流 (AC) が使用されていますが、人々が使用するラップトップでは直流 (DC) が使用されています。この場合、AC アダプターを使用してコンセントから電力を引き出し、それを DC に変換してラップトップに電力を供給します。電源モードを変更せずに、アダプターを使用してラップトップを充電できます。

では、このパターンは Kubernetes とどのように関係するのでしょうか?たとえば、Kubernetes クラスターに集中監視ツールがインストールされている場合、すべてのアプリケーション ログを「APP-NAME-HOSTNAME-DATE-SEVERITY」の形式で出力する必要があります。しかし、クラスターには、さまざまな言語で記述された多くのアプリケーションがあり、さまざまな形式でログを印刷することができます。この場合、将来ツールが変更され、形式が再び変更される可能性があるため、すべてのアプリケーションでログ形式を変更するのは賢明ではありません。この問題を解決するには、2 番目のコンテナーを生成して、プライマリ アプリケーション コンテナーのログを読み取り、監視ツールに必要な形式に処理します。これにより、不一致の問題が解決されます。

2. アンバサダーモード

大使とは各国が他国に派遣する特使のことです。このパターンは Kubernetes Pod でどのように役立ちますか?

たとえば、アプリケーション内で DB URL が localhost としてハードコードされているレガシー アプリケーションがあるとします。レガシー アプリケーションを変更すると、他の多くの場所に変更がもたらされるため、困難です。 Kubernetes クラスターにデプロイできるようにするには、コードを変更する必要があります。コードを変更せずにこれを行うには、Ambassador パターンを使用できます。アンバサダー コンテナは、アプリケーション コンテナを同じ Pod 内に共存させます。これは、開発、品質保証 (QA)、またはステージ環境に応じて適切なデータベースに接続するプロキシです。

メイン アプリケーションは、Ambassador コンテナーを介して localhost などの外部 URL に接続できます。アンバサダー モードは正しい URL を見つけ、それを localhost にあるアプリケーション コンテナーに提供します。メイン アプリケーション コンテナーは、正しい URL について心配する必要はありません。これは、Ambassador コンテナに割り当てられます。

3. サイドカーモード

サイドカーの原理は、サイドカー バイクの原理に似ており、メインの構成に変更を加えずにシートを追加するだけです。このシートはバイクの不可欠な部分ではありませんが、パフォーマンスを向上させます。サイドカー コンテナーも同様に動作します。サイドカーは、メイン コンテナに変更を加えることなく、デプロイされているメイン コンテナの機能を強化します。たとえば、アプリケーションは特定のフォルダーにログ ファイルを生成します。

Kubernetes クラスターでアプリケーション監視ツールを採用する場合、クラスターにデプロイされたすべてのアプリケーションのログを外部ストレージ スペースに保存する必要がありますが、これはアプリケーション レベルではまったく実行できません。代わりに、サイドカー コンテナーを使用すると、メイン アプリケーション レベルでコードを変更することなく、ログ ファイルを目的のストレージ スペースに簡単に保存できます。

結論は

これらのパターンはすべて、メイン アプリケーションを変更せずに横断的なジョブを実行するのに役立ちます。これらはプライマリ コンテナーのサポートを提供するため、セカンダリ コンテナーとしてデプロイする必要があります。これらのワークロードは、異なるポッドで再利用できるように記述する必要があります。

このアプローチを説明すると、アダプタ パターンでは、メイン コンテナーの出力を何らかの標準形式に変換または処理する必要があります。 Ambassador パターンはネットワーク プロキシを提供するために使用されます。サイドカー パターンは、メイン コンテナーにヘルパー/ユーティリティ サービスを提供するために使用されます。

人々はこれらのパターンを使用して、Kubernetes クラスターを最大限に活用しようとします。

オリジナルリンク: Kubernetes のマルチコンテナ ポッド設計パターン、著者: Aditya Bhuyan

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。