Service、負荷分散とネットワーク
Kubernetesのネットワークモデル
Kubernetesのネットワークモデルは、いくつかの要素で構成されています:
クラスター内の各Podは、クラスター全体で一意のIPアドレスを取得します。
- Podは独自のプライベートネットワーク名前空間を持ち、Pod内のすべてのコンテナで共有されます。
同じPod内の異なるコンテナで実行されているプロセスは、
localhostで相互に通信できます。
- Podは独自のプライベートネットワーク名前空間を持ち、Pod内のすべてのコンテナで共有されます。
同じPod内の異なるコンテナで実行されているプロセスは、
Podネットワーク(クラスターネットワークとも呼ばれます)は、Pod間の通信を処理します。 これにより、以下が保証されます(意図的なネットワークセグメンテーションがない限り):
すべてのPodは、同じノード上にあるか、異なるノード上にあるかに関わらず、他のすべてのPodと通信できます。 Podは、プロキシやアドレス変換(NAT)を使用せずに直接通信できます。
Windowsでは、このルールはホストネットワークPodには適用されません。
ノード上のエージェント(システムデーモンやkubeletなど)は、そのノード上のすべてのPodと通信できます。
Service APIは、複数のバックエンドPodによって実装されるサービスに対して、安定した(長期的な)IPアドレスまたはホスト名を提供します。 サービスを構成する個々のPodが時間とともに変化しても、このIPアドレスやホスト名は変わりません。
Kubernetesは、Serviceを構成するPodに関する情報を提供するため、EndpointSliceオブジェクトを自動的に管理します。
サービスプロキシ実装は、ServiceとEndpointSliceオブジェクトのセットを監視します。 そして、オペレーティングシステムまたはクラウドプロバイダーAPIを使用してパケットをインターセプトまたは書き換えることで、サービストラフィックをバックエンドにルーティングするようデータプレーンをプログラムします。
Gateway API(またはその前身であるIngress)を使用すると、クラスター外部のクライアントからServiceにアクセスできるようになります。
- サポートされているクラウドプロバイダーを使用している場合、Service APIの
type: LoadBalancerを使用することで、シンプルではあるものの、設定の自由度が低いクラスターイングレスの仕組みを利用することができます。
- サポートされているクラウドプロバイダーを使用している場合、Service APIの
NetworkPolicyは、Pod間、またはPodと外部との間のトラフィックを制御できる組み込みのKubernetes APIです。
古いコンテナシステムでは、異なるホスト上のコンテナ同士は自動的には通信できませんでした。 そのため、コンテナ間のリンクを明示的に作成したり、コンテナポートをホストポートにマッピングして他のホストから到達可能にしたりする必要がありました。 Kubernetesではこのような作業は不要です。 Kubernetesのネットワークモデルでは、ポート割り当て、名前解決、サービスディスカバリ、負荷分散、アプリケーション設定、マイグレーションといった観点から、Podは、VMや物理ホストと同じように扱えます。
Kubernetes本体で実装されているのは、このモデルの一部のみです。 その他の部分については、KubernetesがAPIを定義し、実際の機能は外部コンポーネントが提供します。これらのコンポーネントの一部はオプションです:
Podネットワーク名前空間のセットアップは、コンテナランタイムインターフェースを実装するシステムレベルのソフトウェアによって処理されます。
Podネットワーク自体は、Podネットワーク実装によって管理されます。 Linuxでは、ほとんどのコンテナランタイムがコンテナネットワークインターフェース(CNI)を使用してPodネットワーク実装と連携するため、これらの実装は CNIプラグイン と呼ばれることがよくあります。
Kubernetesは、kube-proxyと呼ばれるサービスプロキシのデフォルト実装を提供していますが、一部のPodネットワーク実装は、実装の他の部分とより密に統合された独自のサービスプロキシを使用します。
一般的には、NetworkPolicyもPodネットワーク実装によって実装されます(一部のシンプルなPodネットワーク実装ではNetworkPolicyを実装していない場合や、管理者がNetworkPolicyサポートなしでPodネットワークを設定する場合があります。これらの場合、APIは引き続き存在しますが、効果はありません)。
Gateway APIの実装は多数存在し、特定のクラウド環境に特化したもの、「ベアメタル」環境に焦点を当てたもの、より汎用的なものなどがあります。
次の項目
アプリケーションをServiceに接続するチュートリアルでは、実践的な例を通じてServiceとKubernetesネットワークについて学ぶことができます。
クラスターのネットワークでは、クラスターのネットワークを設定する方法について説明し、関連する技術の概要も提供しています。
Ingressコントローラー
クラスターでIngressを動作させるためには、ingress controller が動作している必要があります。 少なくとも1つのIngressコントローラーを選択し、クラスター内にセットアップされていることを確認する必要があります。 このページはデプロイ可能な一般的なIngressコントローラーをリストアップします。
Gateway API
Gateway APIは動的なインフラストラクチャの展開と高度なトラフィックルーティングを提供するAPIの種類のファミリーです。
トポロジーを意識したルーティング
Topology Aware Routingは、ネットワークトラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。クラスター内のPod間で同じゾーンのトラフィックを優先することで、信頼性、パフォーマンス(ネットワークの待ち時間やスループット)の向上、またはコストの削減に役立ちます。