トップKubernetes設計パターン

基本パターン

これらのパターンは、コンテナ化された作業がクラウド環境の一員として認識されるために従うべき基準やベストプラクティスに焦点を当てています。アプリの特性に左右されず、これらの基準が適用されることが望ましいです。これらの提案に従うことで、貴社のアプリがKubernetesによる自動化に対応できるようになります。

• ヘルスプローブ設計

ヘルスプローブが示すように、各コンテナは明確なAPIを利用し、環境がアプリを適切に判断・管理できるようにする必要があります。完全な自動化を実現するため、クラウド環境のアプリは自身の状態を明示し、Kubernetesがその稼働状況を判断して要求に応じるかどうかを決定できるようにすべきです。これらの情報は、Podのライフサイクルやアプリへのトラフィック制御に影響します。

• 需要予測設計

クリアデマンドパターンは、各コンテナが自らのリソースプロファイルを明示し、必要なリソース要求を緩やかに保持すべき理由を示しています。アプリの基本的なリソース状況や実行状態を把握・伝達することは、効率的なアプリ開発において重要です。これらは一般的なクラウド環境で集約・支援されます。このパターンは、パターン固有の前提条件、厳格な実行制約、リソース要求に応じたアプリの要件を整える方法を示し、必要事項を明示することでKubernetesが最適な配置ゾーンを選ぶ助けとなります。

• 自動配置設計

自動配置は、マルチゾーン配置における負荷移動にどう対応するかを示します。この仕組みは、Kubernetesスケジューラの核心部分であり、新しいPodを各コンテナのリソース要求や配置戦略に沿ったゾーンに割り当てます。このパターンは、Kubernetesのコンテナ評価基準と、運用によって配置判断に与える影響を外部視点で説明します。

構造パターン

優れたクラウド環境のコンテナを持つことは基本ですが、それだけでは十分ではありません。次に、コンテナを再利用してPod内に配置し、最適なパフォーマンスを実現する必要があります。この段階のパターンは、特定の利用ケースに応じてPod内に複数のコンテナを設計する方法を示しており、Pod内のコンテナに影響する要因の必然的な結果です。

• Initコンテナ設計

初期化に関するタスクや主要なアプリのコンテナに対して、Initコンテナは独自のライフサイクルを持ちます。Initコンテナは、初期化タスクを処理するためにメインのアプリコンテナとは別のライフサイクルで起動されます。このパターンは、支援が必要な状況下で利用するKubernetesの重要な概念を構築します。

• サイドカー設計

サイドカーは、既存のコンテナを置き換えることなく、その機能を追加・拡張する方法を示しています。単一の責任領域内で、隣接するコンテナが協調して動作します。

振る舞いのパターン

これらのパターンは、管理層によって保証されたPodのライフサイクルの性質を示しています。Podは、役割に応じて安定動作またはイベント駆動型として動作し、シングルトンやデーモンセットとして機能する場合があります。適切なライフサイクルを選ぶことで、最適な認証状態でPodを運用できます。

• バッチジョブ設計

バッチジョブは、分割可能な作業単位を効率的に実行するための方法を示しています。分散環境下では、個別の作業グループを管理するのに適しています。

• ステートフルサービス設計

ステートフルサービスは、Kubernetesを活用して大規模なステートフルアプリを構築・運用する方法を示します。各アプリでは、構造の一貫性、集約、順序性が必須となります。これらはStatefulSetによって明確に保証され、ステートフルアプリの連携が容易になります。

• サービスディスカバリー設計

このパターンは、クライアントがアプリの連携をどう検出しアクセスするかを示します。そのため、Kubernetesはクライアントやプロバイダがクラスタ内外にいる場合に合わせた様々な方式を提供しています。

上位レベルのパターン

このカテゴリのパターンはより抽象的で、幅広い要件を持つ上位プラン向けに提案されています。一部のパターン（例：コントローラー）は初期から存在し、Kubernetesで利用されています。

• コントローラー設計

Kubernetesのリソースであるコントローラーは、理想の状態を正しく導き維持する仕組みの一例です。Kubernetesの基盤は、コントローラーの集合体であり、現在の動作を理想状態へと絶えず調整します。このパターンは、この概念を利用しWallarmのアプリ拡張に役立てる方法を示しています。

• オペレーター設計

オペレーターは、CustomResourceDefinitionsを活用して特定のアプリ向けにデータをアルゴリズム的かつ自動化された形で管理する仕組みです。この仕組みにより、より柔軟で明確なコントローラーパターンの構築が可能となります。Kubernetes向けオペレーターは増加しており、このパターンはシステム管理を行う上で欠かせない存在となっています。

マルチノードアプリ設計

マルチノードプランでは、コンテナは単一のマシンやノードに存在せず、複数のノードにまたがって動作します。

• リーダー選出設計

リーダー選出用のコンテナを使って、アプリに選出ライブラリを接続するパターンです。複数のリーダー選出コンテナが配置され、それぞれがアプリの同じイベントに合わせた選出処理を担当します。選出が必要なときは、進化したHTTP APIをlocalhost経由で利用できます。

• ワークキュー設計

これは分散処理でよく発生する問題です。コンテナ化はリーダー選出と同様の恩恵をもたらしますが、基盤が特定のプログラミング言語に依存する点に制限があります。最終的には、一般的なワークキューコンテナを構築することでこの制約を解消できます。専用ではないワークキューコンテナが、入力データを受け取り必要な出力へと変換する役割を果たします。

• スキャッター／アキュムレート設計

外部クライアントが、ウェブ検索エンジンに見られるようにリクエストを「ルート」または「親」ノードに送信します。ルートはそのリクエストを一群のワーカーに転送し、各ワーカーが部分的なデータを返します。ルートはこれらのデータをまとめ、メインのレスポンスを生成します。

‍

その他のパターン

• アンバサダー／プロキシ設計

アンバサダーモデルは、中心アプリの近くで他のサービスを実行するための外部的な選択肢です。アンバサダーコンテナの主な目的は、他のサービスが基本アプリにアクセスしやすくすることで、エージェントがガイド層として機能します。エージェントコンテナは、localhostを利用し全ての外部アクセスを管理します。また、接続維持、問題発生時の再接続、設定更新の役割も担います。

このパターンを利用する際、アプリはlocalhost上で単一のワーカーと連携していると見なせます。つまり、同じ仕組みで動作する全てのPodが同一のlocalhostネットワークインターフェイスを共有するため、特筆すべきモデルです。

• アダプター設計

アダプター設計は、元のコンテナの出力をアプリの要求にあった形に変換します。例えば、アダプターコンテナは、通常とは異なる動作をするアプリに対し、正規化されたインターフェイスを提供することがあります。アダプターは、この出力を利用可能な形へ変換する役割を担います。

どの配置パターンを選ぶか？

いくつかの要因が、これら七種類のパターンの中からどれを選ぶかに影響します。万能な解決策は存在せず、各パターンはそれぞれの理由と対応する問題を持っています。実際、一つのシステムで複数のパターンを併用することも可能です。

これらのコンテナ設計パターンは、分散システムの理解を深める手助けとなります。コードの再利用や柔軟で高可用性のシステム構築を実現するための基礎となるでしょう。

各ケースについて詳しく解説しました。ここまでの内容で、貴社の状況に合うパターンが十分に理解できたことと思います。直面する課題に最適なものを選ぶため、さらなる検討をお勧めします。

結論

Kubernetesは、今日最も優れたコンテナ設計プラットフォームです。オープンソースコミュニティによって進化・改善され、大手クラウドプロバイダーからもサポートされています。LinuxとWindowsのシステムが混在する大規模環境でも利用可能であり、ステートレス、ステートフル、バッチ、イベント駆動、サーバーレスといった様々なアプリの作成と自動化を実現します。

Kubernetesはクラウド全体に広がるミドルウェアであり、アプリの通信基盤でもあります。システムアーキテクトや開発者にとって、Kubernetesは最終的に有益な存在となるでしょう。ここで紹介したKubernetesのパターンを理解することで、プラットフォームの活用方法に影響を与えるはずです。

興味深い記事シリーズを読む - KubernetesクラスターをWallarmで守る方法