Kubernetes の一般的なネットワーク

1 Kubernetesネットワークの概要

Kubernetes ネットワーキングは、異なるクラスター内外のコンポーネントが相互に通信できるようにするシステムです。このシステムは多くの状況を処理しますが、重要な状況としては、ポッド間の通信、サービス間の通信、クラスターが外部からのトラフィックを処理する方法などがあります。

Kubernetes は分散システムであるため、そのネットワーク プレーンはクラスター内のすべての物理ノードにまたがります。 Kubernetes は仮想オーバーレイ ネットワークを使用して、クラスター リソースにフラットな接続ファブリックを提供します。この仮想オーバーレイ ネットワークにより、クラスター内のリソースは、それらが配置されている物理ノードに関係なく、相互に接続できるようになります。

以下は Kubernetes ネットワーク図です。

写真

Kubernetes ネットワークは、IP アドレスを自動的に割り当て、DNS 名を設定し、開発者のポッドとサービスへのポートに接続します。通常、Kubernetes を使用する場合、開発者はネットワークまたはノード ホスト上でこれらのタスクを手動で処理する必要はありません。

Kubernetes ネットワーク モデルは、クラスター内の各ポッドに一意の IP アドレスを割り当てます。これにより、ポッドはネットワーク アドレス変換 (NAT) などの追加の設定を必要とせずに、IP アドレスを使用して相互に通信できるようになります。

この基本的なセットアップは、Kubernetes サービス モデルによって改善されます。サービス モデルでは、トラフィックを Pod セットのいずれかに送信できるほか、ネットワーク ポリシーなどのネットワーク制御方法も含まれます。ネットワーク ポリシーにより、ポッド間の不要な通信を防止できるため、ネットワークのセキュリティと信頼性が向上します。

2 従来の仮想マシンとKubernetesネットワークの違い

Kubernetes ネットワークは、既知のネットワーク概念を使用し、それを Kubernetes クラスターのコンテキストに適用します。従来の物理デバイスおよび仮想マシン (VM) ネットワーク モデルと比較すると、Kubernetes ネットワークはよりシンプルで、より均一で、より自動化されています。

これまで、開発者は IP アドレスの構成、ファイアウォールでのポートの開放、DNS ルーティングの設定など、新しいエンドポイントを手動で設定する必要がありました。ただし、Kubernetes を使用する場合、開発者はこれらの操作を実行する必要がなくなります。 Kubernetes は、開発者のクラスター タスクに対してこれらすべての操作を自動的に実行します。

開発者や運用スタッフは、リソースを展開して他のユーザーが利用できるようにするために、ネットワーク設定の詳細を理解する必要はありません。これにより、すべての管理を Kubernetes 自体内で実行できるため、セキュリティ要件の設定、保守、最新の状態の維持が容易になります。

Docker と Kubernetes ネットワークの 3 つの違い

VM ネットワークと Kubernetes ネットワークの違いについて説明したので、Docker ネットワークについても触れておきます。

Kubernetes のネットワーク設計は非常にシンプルでフラットなので、分散システムに非常に適しています。この設計では、各 Pod は、異なる物理マシン (ノード) 上にある場合でも、他の Pod と通信できます。

Docker は主に単一のマシン上でコンテナを実行するために設計されているため、ネットワークの処理方法が異なります。デフォルトでは、Docker はすべてのコンテナをブリッジと呼ばれるネットワークに接続し、開発者のコ​​ンピューターに接続します。ただし、開発者は独自のコンテナ用にさまざまな種類のネットワークを設定することもできます。これらのネットワークには、ブリッジ ネットワーク (同じマシン上のコンテナーを接続)、ホスト ネットワーク (コンテナーがマシンのネットワークを直接使用できるようにする)、オーバーレイ ネットワーク (複数のコンテナーを管理するためのツールである Docker Swarm に必要な、複数のマシンにまたがるネットワークを作成する) が含まれます。

Docker コンテナは、同じネットワーク内にある場合に相互に通信できます。各コンテナには独自の IP アドレスと DNS 名があり、ネットワーク内でのみ使用されます。こうすることで、他のネットワーク内のコンテナがそれらに接続できるようになります。ただし、Docker は開発者のコ​​ンピューターからコンテナーへの接続 (ポート マッピング) を自動的に設定しません。開発者はコンテナを起動するときにこれらの接続を手動で設定する必要があります。

Docker と Kubernetes はどちらもネットワークに関してはいくつかの類似点がありますが、それぞれ独自のユースケースとネットワーク設計があります。 Docker は主に単一のマシン上でコンテナを実行するために使用されるため、ネットワーク設計はよりシンプルで、ブリッジ モードを使用してコンテナを接続します。一方、Kubernetes は分散システム向けに設計されているため、システムのさまざまな部分を接続して、同じマシン上になくても相互に通信できるようにするには、より複雑なネットワーク設計が必要です。したがって、Kubernetes はオーバーレイ ネットワークを使用してこれを実現します。

Docker と Kubernetes はコンテナの分離の点で異なります。 Docker では、コンテナを異なるネットワークに配置することで、コンテナ同士の通信を防ぐことができます。 Kubernetes では、すべての Pod が同じオーバーレイ ネットワークに自動的に追加されます。したがって、どの Pod が相互に通信できるかを制御するために、Kubernetes はネットワーク ポリシーを使用してネットワーク内のトラフィックを管理します。この方法により、Pod 間の通信をより細かく制御し、ネットワークのセキュリティと制御性を向上させることができます。

4 Kubernetes ネットワーク アーキテクチャ

Kubernetes ネットワークは、次の主要な機能を備えたシンプルでフラットな構造に基づいて構築されています。

• 各ポッドには独自の IP アドレスが付与されます。
• ノードには、ポッドのネットワーク インターフェースが接続されるプライマリ ネットワーク空間 (ルート ネットワーク名前空間) があります。つまり、ポッドは、どのノード上にあるかに関係なく、IP アドレスを使用して相互に通信できます。
• ネットワーク アドレス変換 (NAT) は必要ありません。
• 各ポッドには独自のネットワーク スペースとインターフェースがあります。 Pod とのすべての通信は、その特定のネットワーク インターフェースを介して行われます。
• クラスター全体のネットワーク層は、ノード レベルでネットワーク空間を接続します。これにより、異なるノード間でトラフィックが正しく移動されることが保証されます。
• 通常、Pod ポートをノードに手動でリンクする必要はありません。ただし、必要に応じて、特定のポート (hostPort) を Pod に割り当てることでこれを実現できます。

これらの原則により、クラスターのユーザーと管理者の両方にとって、Kubernetes ネットワークが予測可能で一貫したものになります。 Kubernetes によってセットアップされたシステムにより、手動でセットアップしなくても、すべての Pod が確実にネットワークに接続できるようになります。

5.ポッドにIPアドレスを割り当てる

Kubernetes は、クラスレス ドメイン間ルーティング (CIDR) と呼ばれる方法を使用して、Pod に IP アドレスを割り当てます。このシステムは、ポッドが使用できる IP アドレスの範囲を決定します。各ポッドは、開発者のクラスターに固有のこの範囲から一意の IP アドレスを取得します。新しいクラスター ネットワークを設定する場合、開発者は使用可能な IP アドレス範囲 (CIDR 範囲) を選択する必要があります。

さらに、Kubernetes にネットワーク機能を追加するさまざまなツール (ネットワーク プラグイン) を使用すると、開発者は IP アドレスをより細かいレベルで管理できます。これらのツールを使用すると、特定の IP アドレス、IP アドレスの一部、または IP アドレスのグループを選択できます。これは、より複雑なネットワーク設定を扱う場合に非常に便利です。

6 Kubernetes クラスターの DNS

Kubernetes クラスターには組み込みの DNS サポートが含まれています。 CoreDNS は最も人気のある Kubernetes DNS プロバイダーの 1 つであり、多くの Kubernetes ディストリビューションでデフォルトで有効になっています。

Kubernetes は、次の形式でポッドとサービスに DNS 名を自動的に割り当てます。

• ポッド — pod-ip-address.pod-namespace-name.pod.cluster-domain.example (例: 10.244.0.1.my-app.svc.cluster.local)
• サービス — service-name.service-namespace-name.svc.cluster-domain.example (例: database.my-app.svc.cluster.local)

Pod で実行されるアプリケーションは通常、DNS 名を使用してサービスと通信するように構成する必要があります。名前は予測可能ですが、サービスが削除され、置き換えられると、サービスの IP アドレスは変更されます。

7 ネットワークポリシーを使用した Kubernetes ネットワーク分離

Kubernetes では、すべての Pod がデフォルトで相互に通信できます。これは、特に複数の個別のアプリケーション、環境、チーム、または顧客に使用されるクラスターでは、場合によってはセキュリティ リスクをもたらす可能性があります。クラスターのセキュリティを保護するには、Pod 間のネットワーク通信を制御するための適切な対策を講じる必要があります。

これを管理するために、Kubernetes にはネットワーク ポリシーと呼ばれるものがあります。これらは、開発者がポッドがトラフィックを送受信する方法 (イングレスおよびエグレス) を制御するために設定できるルールです。たとえば、トラフィックが app-component:api タグの付いた Pod からのものでない限り、app-component:database タグの付いた Pod へのすべてのトラフィックを停止するポリシーを作成できます。これは、セキュリティを強化するために、どのポッドが相互に通信できるかを制御する方法です。

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database-network-policy namespace: default spec: podSelector: matchLabels: app-component: database policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app-component: api

Kubernetes では、すべての Pod に対してネットワーク ポリシーを作成するのが最適です。これらのポリシーは、潜在的に侵害されたポッドが他の近くのポッドに有害なトラフィックを送信するのを防ぐことで、クラスターを保護するのに役立ちます。これにより、開発者の Kubernetes 環境にセキュリティの層が追加されます。