Kubernetes는 클러스터 외부의 모든 항목이 클러스터와 통신할 수 있다고 보장하지 않으며 다음과 같은 기능의 제공만을 약속합니다.
클러스터의 모든 포드는 네트워크 주소 변환(NAT)을 사용하지 않고도 서로 직접 통신할 수 있습니다. 서로 다른 노드에 있는 포드도 서로 직접 통신할 수 있습니다.
시스템 데몬이나 kubelet과 같은 노드의 에이전트는 해당 노드의 모든 포드와 통신할 수 있습니다.
그렇다면 아래의 그림과 같이 네트워크가 두 개의 클러스터를 호스팅하는 경우 클러스터 1의 포드는 어떻게 클러스터 2의 포드와 통신할까요? 마찬가지로, 다이어그램에 '기타 클라이언트' 및 '기타 서버'로 표시된 클러스터 외부의 클라이언트나 서버는 어떻게 클러스터 내의 포드와 통신할까요?
이 문서에서는 위의 질문에 대한 답이 플랫 모드 네트워크 모델과 섬(island) 모드 네트워크 모델에서 어떻게 다른지 설명합니다.
플랫 모드 네트워크 모델
완전 통합 또는 플랫 모드 네트워크에서는 포드가 모든 클러스터에서 고유한 IP 주소를 갖습니다. 예를 들어 클러스터 1의 Pod-A에는 클러스터 1 또는 클러스터 2의 다른 곳에서는 확인되지 않는 IP 주소가 있습니다. 마찬가지로 클러스터 2의 Pod-G도 두 클러스터 모두에서 고유한 주소를 갖습니다. 즉, 클러스터 1의 포드가 클러스터 2의 모든 포드와 직접 통신할 수 있습니다(트래픽을 차단하는 방화벽이나 기타 정책이 없다고 가정). 포드 간 통신에는 게이트웨이나 주소 변환이 필요하지 않습니다.
마찬가지로, 라우팅이 네트워크 기기에서 정적으로 구성되어 있거나 지정된 IP 범위의 트래픽을 처리할 수 있다고 공지하기 위해 노드에서 Border Gateway Protocol(BGP)을 사용하는 경우 클러스터 외부의 클라이언트와 서버가 포드의 고유한 IP 주소를 통해 클러스터 내의 포드와 직접 통신할 수 있습니다.
따라서 플랫 네트워크에서는 통신이 쉬우며 직접적으로 이루어집니다. IP 주소가 겹치지 않으며 오버레이 네트워크 또는 NAT를 사용할 필요가 없습니다.
섬(Island) 모드 네트워크 모델
평면 모드 네트워크 모델은 대규모 IP 주소 공간이 있고 포드마다 고유한 IP 주소를 할당할 수 있는 옵션입니다.
하지만 큰 IP 주소 공간을 사용할 수 없다면 섬(island) 모드 네트워크 모델을 사용하는 것이 좋습니다.
섬(island) 모드 네트워크에서는 노드에 고유한 IP 주소가 있지만 부족한 IP 주소를 경제적으로 사용하기 위해 포드에는 클러스터 전체에서 고유한 주소가 없습니다. 한 클러스터의 포드가 다른 클러스터의 포드와 직접 통신하지 않으므로 문제가 발생하지는 않습니다. 대신 다음 다이어그램과 같이 한 클러스터의 포드와 다른 클러스터의 포드를 중재하는 게이트웨이가 있습니다.
마찬가지로 클러스터에 들어오는 클라이언트의 (인그레스) 트래픽과 클러스터에서 나가는 (이그레스) 트래픽은 비슷한 게이트웨이에서 처리됩니다. 다양한 방법으로 게이트웨이를 구현할 수 있습니다. 예를 들어 NAT, 가상 IP 주소(VIP), 프록시가 게이트웨이의 예시입니다. 포드 IP를 비공개로 유지하는 효과가 있는 IP 주소 변환을 수행합니다.
섬(island) 모드 네트워크 모델에서는 각 클러스터에서 같은 포드 IP 주소를 사용할 수 있습니다. 즉, 포드 IP 주소가 클러스터 전체에서 고유할 필요는 없습니다.
다음 다이어그램과 같이 한 클러스터의 포드가 다른 클러스터의 포드와 직접 통신하지 않으므로 각 클러스터에서 같은 포드 IP 주소를 사용할 수 있습니다.
섬(island) 모드 네트워크 모델의 주요 이점은 포드 IP 주소를 이러한 방식으로 재사용할 수 있다는 것입니다.
두 모델의 장단점
두 모델의 장점과 단점 몇 가지를 소개합니다.
섬(island) 모드의 게이트웨이는 주소 변환을 수행하므로 플랫 네트워크가 섬(island) 네트워크보다 빠르며 변환 시 성능 비용이 발생합니다.
플랫 네트워크에서는 네트워크의 모든 항목에 고유한 IP 주소가 있기 때문에 클러스터 문제를 쉽게 디버깅할 수 있어 문제가 발생한 위치를 더 쉽게 파악할 수 있습니다. 예를 들어 포드 IP가 노드의 IP 주소 뒤에 표시되지 않기 때문에 문제를 일으키는 포드를 정확히 파악하기가 더 용이합니다.
마찬가지로 클라이언트 IP가 섬(island) 모드에서처럼 플랫 모드에서 가려지지 않아 디버깅에도 도움이 됩니다.
IP 주소가 부족하거나 IP 공간이 파편화된 경우(즉, 대량의 IP 주소가 없는 경우) 플랫 네트워크 모델을 사용하지 못할 수 있습니다. 이러한 경우에는 섬(island) 네트워크가 더 나은 옵션입니다.
플랫 및 섬(island) 네트워크 모델은 가능한 네트워크 모델 중 두 개에 불과하며 이러한 모델 내에서도 많은 변형이 있습니다.
[[["이해하기 쉬움","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."]]
