クラスタ内のすべての Pod は、ネットワーク アドレス変換(NAT)を使用しなくても、直接通信できます。異なるノード上にある Pod 同士も、直接通信できます。
ノード上のエージェント(システム デーモンや kubelet など)は、そのノード上のすべての Pod と通信できます。
ネットワークが以下に示すように 2 つのクラスタをホストしている場合、クラスタ 1 の Pod がクラスタ 2 の Pod とどのように通信するでしょうか。同様に、図の「その他のクライアント」や「その他のサーバー」とマークされたクラスタ外のクライアントやサーバーが、クラスタ内の Pod と通信するにはどうすればよいでしょうか。
完全統合ネットワークやフラットモード ネットワークでは、Pod にはクラスタ全体で一意の IP アドレスが割り振られます。たとえば、クラスタ 1 にある Pod-A の IP アドレスは、クラスタ 1 やクラスタ 2 の別の場所にはありません。同様に、クラスタ 2 内の Pod-G には、両方のクラスタで一意のアドレスがあります。つまり、クラスタ 1 の Pod は、クラスタ 2 の任意の Pod と直接通信できます(トラフィックをブロックするファイアウォールやその他のポリシーがないと仮定した場合)。Pod 間の通信にゲートウェイやアドレス変換は必要ありません。
同様に、ルーティングがネットワーク デバイスで静的に構成されている場合、または特定の IP 範囲のトラフィックを処理できるようにアドバタイズするために Border Gateway Protocol(BGP)を使用している場合、クラスタ外のクライアントとサーバーは、Pod の一意の IP アドレスを使用してクラスタ内の Pod と直接通信できます。
フラットモードのネットワーク モデルは、大規模な IP アドレス空間を用意する余裕があり、各 Pod に一意の IP アドレスを割り振ることが可能な場合に利用できます。しかし、大規模な IP アドレス空間を使用できない場合は、アイランド モード ネットワーク モデルが適しています。
アイランド モード ネットワークでは、限られた IP アドレスで経済的に済ませるため、ノードには一意の IP アドレスを使用しますが、Pod にはクラスタ全体で一意となるアドレスは使用されません。あるクラスタの Pod が別のクラスタの Pod と直接通信することはないため、これが問題になることはありません。その代わりに、次の図に示すように、あるクラスタの Pod と別のクラスタの Pod との間を仲介するゲートウェイがあります。
同様に、クライアントからクラスタへ送信される上り(内向き)トラフィックと、クラスタから出る下り(外向き)トラフィックは、同じようなゲートウェイによって処理されます。ゲートウェイはさまざまな方法で実装されます。たとえば、NAT、仮想 IP アドレス(VIP)、プロキシなどはゲートウェイの一例です。それらは、Pod の IP アドレス変換を行い、Pod の IP を非公開にします。
アイランド モード ネットワーク モデルでは、各クラスタで同じ Pod IP アドレスを使用できます。つまり、Pod IP アドレスはクラスタ間で一意である必要はありません。次の図に示すように、あるクラスタの Pod は別のクラスタの Pod と直接通信しないため、各クラスタで同じ Pod IP アドレスを使用できます。
アイランド モード ネットワーク モデルの大きなメリットは、Pod IP アドレスを再利用できる点です。
クラスタの問題のデバッグは、フラット ネットワークのほうが簡単です。ネットワーク内のすべてが一意の IP アドレスを持っているため、問題が発生している場所の特定が簡単になります。たとえば、Pod IP がノードの IP アドレスの背後に隠されないため、問題の原因となっている具体的な Pod の特定が簡単になります。同様に、フラットモードでは、アイランド モードのようにクライアント IP が隠されないこともデバッグの助けになります。
IP アドレスが少ない場合や、IP 空間が断片化している(IP アドレスの大きなまとまりがほとんどない)ため、フラット ネットワーク モデルを使用できない場合があります。その場合は、アイランド ネットワークのほうが適しています。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-01 UTC。"],[],[],null,["Kubernetes doesn't guarantee that anything outside a cluster can communicate\nwith the cluster and only promises to provide the following functionality:\n\n- All pods in a cluster can communicate directly with each other\n without having to resort to Network Address Translation (NAT). Even pods that\n are on different nodes can communicate directly with each other.\n\n- Agents on a node, such as system daemons or a kubelet, can communicate with\n all pods on that node.\n\nThus when a network is hosting two clusters, as pictured below, a question to\nask is how do pods in cluster 1 communicate with pods in cluster 2? Similarly,\nhow do clients or servers outside the clusters, marked as \"Other client\" and\n\"Other server\" in the diagram, communicate with a pod inside a cluster?\n\nThis document explains how a *flat-mode* network model and an *island-mode*\nnetwork model answer these questions differently.\n\nFlat mode network model\n\nIn a fully-integrated or flat-mode network, pods have unique IP addresses across\nall the clusters. For example, `Pod-A` in cluster 1 has an IP address that you\nwon't see anywhere else in cluster 1 or cluster 2. Similarly, `Pod-G` in cluster\n2 has a unique address across both clusters. This means that pods from cluster 1\ncan communicate directly with any of the pods in cluster 2 (assuming there are\nno firewalls or other policies that would block traffic). No gateway or address\ntranslation is needed for pod to pod communication.\n\nSimilarly, clients and servers outside a cluster can directly communicate with a\npod inside a cluster via the pod's unique IP address if, for instance,\nrouting is configured statically in network devices or [Border Gateway Protocol (BGP)](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)\nis used by the nodes to advertise that they can handle traffic for a given\nIP range.\n\nThus, in flat networks, communication is easy and direct: there are no\noverlapping IP addresses, and you don't need to use overlay networks or NAT.\n\nIsland mode network model\n\nA flat-mode network model is an option if you have the luxury of a large IP\naddress space, and you can afford to assign a unique IP address to each pod.\nHowever, if a large IP address space isn't an option for you, an island-mode\nnetwork model is a good choice.\n\nIn an island-mode network, nodes have unique IP addresses but, in order to be\neconomical with scarce IP addresses, pods don't have unique addresses across\nclusters. This doesn't cause problems because pods in one cluster never directly\ncommunicate with pods in another cluster. Instead, as the following diagram\nshows, there are gateways that mediate between a pod in one cluster and a pod\nin another cluster.\n\nSimilarly, (ingress) traffic from a client that's coming into a cluster and\n(egress) traffic leaving a cluster are handled by similar gateways. Gateways\ncan be implemented in various ways. For example, NAT, Virtual IP addresses\n(VIPs), and proxies are some examples of gateways. They perform IP address\ntranslations which have the effect of keeping pod IPs private.\n\nIn the island-mode network model, the same pod IP addresses can be used in each\ncluster. That is, the pod IP addresses don't have to be unique across clusters.\nAs the following diagram suggests, you can use the same pod IP addresses in each\ncluster because a pod in one cluster never communicates directly to a pod in\nanother cluster.\n\nA major advantage of the island-mode network model is that pod IP addresses can be\nre-used in this fashion.\n\nAdvantages and disadvantages of the two models\n\nSome of the advantages and disadvantages of the two models are listed here:\n\n- A flat network is faster than an island network because gateways in island\n mode perform address translations, and these translations incur a\n performance cost.\n\n- Debugging cluster problems is easier in flat networks because everything in\n the network has a unique IP address and so it's easier to pinpoint where a\n problem occurs. For instance, pod IPs aren't masked behind a node's IP address\n and so it's easier to determine exactly which pod is causing problems.\n Similarly, client IPs aren't obscured in flat mode the way they are in island\n mode and that also helps with debugging.\n\n- You may not be able to use the flat network model if you have scarce IP\n addresses or if your IP space is fragmented (that is, if you don't have large\n chunks of IP addresses). In that case an island network is a better option.\n\nIt's important to note that flat and island network models are just two of the\npossible network models, and there are lots of variations even within these\nmodels."]]