コンテナの解剖学 101: クラスターとは何ですか?

ネットワークの観点から見ると、コンテナはネットワークの「エッジ」(ネットワーク転送の決定とパケットが最終目的地に到達するまでの境界)をホストの奥深くまで拡張します。エッジはもはやホストのネットワーク インターフェイスではなく、ホスト内の論理構造の奥深くにある数層です。また、ネットワークトポロジーは抽象化され、オーバーレイネットワークトンネリング、仮想インターフェイス、NAT境界、ロードバランサー、ネットワークプラグインの形で、ホスト内のこれらの論理構造に深くまで達します。ネットワークおよびセキュリティアーキテクトは、アーキテクチャを設計する際にOSの内部を無視することはできなくなりました。コンテナは、これらのアーキテクチャに、パケットがホストの NIC を通過した後の行き先を理解するように強制します。

オーケストレーションシステム

そうは言っても、コンテナ環境に何らかの形の秩序をもたらすには、オーケストレーションシステムが必要です。オーケストレーションシステムは、コンテナの整理、スケーリング、自動化に関する詳細を管理し、コンテナの動作に関連するさまざまなコンポーネントに関する論理構造を作成します。また、コンテナランタイムに関連付けられた論理境界を整理し、IPアドレスを割り当てることができる論理構造を作成する役割も担います。とはいえ、このようなシステムは外部であり、たとえば Docker によって処理される特定のコンテナランタイムインスタンスのライフサイクルを実際にデプロイおよび管理することはできません。  

コンテナオーケストレーションシステムは数多くありますが、現在最も一般的に使用されているのは Kubernetes と OpenShiftの2つです。どちらも同じ基本的な目標を達成しますが、主な違いは、一方がプロジェクトであり、もう一方が製品であるということです: Kubernetes は主に Google から生まれたプロジェクトであり、OpenShift は Red Hat が所有する製品です。一般的に、Kubernetesはパブリッククラウド環境で最も多く見られ、OpenShiftはオンプレミスのデータセンターで最もよく見られますが、この2つの間にはかなりの重複があります。つまり、Kubernetesは両方のアプローチの根底にありますが、それぞれの用語に若干の違いがあります。

コンテナの簡単な歴史

信じられないかもしれませんが、コンテナは Kubernetes よりも前から存在していました。たとえば、Docker は 2013 年にコンテナ プラットフォームを初めてリリースしましたが、Kubernetes は 2014 年までパブリック クラウドに焦点を当てたプロジェクトをリリースしませんでした。OpenShift は、オンプレミスのデータセンターにデプロイされたホストに焦点を当てて、両方よりも前にリリースされました。  

ランタイムは「localhost」と一意のポートを介して相互に通信できるため、ローカルホストにコンテナランタイムをデプロイするだけで、通常、開発者のニーズを満たすことができます。コンテナーランタイムには特定の IP アドレスが割り当てられません。高速で効率的なコードを作成し、関連するコンテナランタイムのコレクションにアプリケーションをデプロイすることに重点を置いている場合、このアプローチは正常に機能します。ただし、そのアプリケーションをローカルホストの外部の外部リソースにアクセスさせる場合、または外部クライアントにそのアプリケーションにアクセスする場合は、ネットワークの詳細を無視することはできません。これがオーケストレーションシステムが必要な理由の1つです。  

Kubernetesは、コンテナランタイムの動作を整理するための一連のビルディングブロックとAPI駆動型のワークフローを中心に作成されました。このアプローチでは、Kubernetesは、特定のコンテナ化された環境に関連付けられたホスト内およびホスト間で一連の論理構造を作成し、これらの構成を参照するためのまったく新しい語彙セットを作成します。Kubernetesは、CPU割り当て、メモリ要件、およびストレージ、認証、メータリングなどのその他のメトリックに関連する一連のコンピューティングメトリックを中心に、これらのビルディングブロックとAPI駆動型ワークフローを適用しますが、ほとんどのセキュリティおよびネットワーキングの専門家は、1つのことに焦点を当てています。

IP パケットは、IP アドレスが割り当てられている論理構造に向かう途中で、どのような境界を通過しますか?

ネットワーキングの観点からは、Kubernetes と OpenShift はどちらも、各システム間の語彙にわずかな違いがあるだけで、階層的なアプローチで論理的で関連性の高い構造を作成します。これを以下に示します。

コンテナークラスターの ABC

この図は、Kubernetes 環境の基本的な論理構造を示しています。各構造が何をするかを説明するのではなく、それらが互いに論理的にどのように関連しているかのみを説明します。

最も広い構造から最小の構造まで、簡単な説明を次に示します。

• クラスタ: クラスタは、特定のコンテナ化されたデプロイメントに関連付けられたホストの集合です。
• ノード: クラスター内にはノードがあります。ノードは、コンテナが存在するホストです。ホストは物理コンピューターまたは VM のいずれかであり、オンプレミスのデータ センターまたはパブリック クラウドのいずれかに存在できます。一般に、クラスターには「マスターノード」と「ワーカーノード」の2つのカテゴリのノードがあります。物事を単純化しすぎると、マスターノードは、クラスターとAPIサーバーの中央データベースを提供するコントロールプレーンです。ワーカーノードは、実際のアプリケーションポッドを実行しているマシンです。
• Pods: 各ノード内で、Kubernetes と OpenShift の両方が Pod を作成します。各ポッドは 1 つ以上のコンテナーランタイムを含み、オーケストレーションシステムによって管理されます。Pod には、Kubernetes と OpenShift によって IP アドレスが割り当てられます。
• コンテナ: ポッドの内部は、コンテナランタイムが存在する場所です。特定のポッド内のコンテナーはすべて、そのポッドと同じIPアドレスを共有し、一意のポートを使用してLocalhostを介して相互に通信します。
• 名前空間: 特定のアプリケーションは、クラスター内の複数のノードに "水平" にデプロイされ、リソースとアクセス許可を割り当てるための論理境界を定義します。Pod (したがってコンテナー) とサービスだけでなく、ロール、シークレット、その他多くの論理構造も名前空間に属します。OpenShift はこれをプロジェクトと呼んでいますが、同じ概念です。一般的に、名前空間は特定のアプリケーションにマップされ、そのアプリケーションは、その中のすべての関連するコンテナーにデプロイされます。名前空間は、ネットワークおよびセキュリティ構造とは何の関係もありません (Linux IP 名前空間とは異なります)
• サービス: ポッドは一時的なものであり、突然消えて後で動的に再デプロイされる可能性があるため、サービスは「フロントエンド」であり、関連付けられた一連のポッドの前にデプロイされ、ポッドが消えても消えないVIPを備えたロードバランサーのように機能します。サービスは、独自の IP アドレスを持つ非一時的な論理構造です。Kubernetes と OpenShift 内のいくつかの例外を除き、外部接続はサービスの IP アドレスを指し、その後「バックエンド」ポッドに転送されます。
• Kubernetes API サーバー: これは API ワークフローが一元化される場所であり、Kubernetes はこれらすべての論理構造の作成とライフサイクルを管理します。

コンテナのセキュリティ上の課題 

ワークロードの境界に沿ってセキュリティセグメントを作成するには、Kubernetesによって作成されたこれらの基本的な論理構造を理解する必要があります。ホストされたアプリケーションから出入りする外部ネットワークトラフィックは、通常、基盤となるホストであるノードのIPアドレスを指していません。代わりに、ネットワークトラフィックは、そのホスト内のサービスまたはポッドのいずれかを指します。したがって、 効果的なセグメンテーションセキュリティアーキテクチャを作成するには、ワークロードに関連するサービスとポッドを十分に理解する必要があります。

もっと興味がありますか?コンテナセグメンテーションに対するネットワークベースのアプローチの課題と、ホストベースのセグメンテーションを使用してそれらを克服する方法に関する論文 をご覧ください 。