ithailey 님의 블로그

[네트워크 기초] 쿠버네티스 패킷의 여정 w/ Flannel

ithailey — Sat, 8 Aug 2026 10:29:46 +0900

안녕하세요!

오늘은 쿠버네티스 공부를 하면서 가장 자주 헷갈렸던 네트워크 통신을 정리해보려고 합니다.

Pod에 IP가 붙는다는 건 알겠고, Service를 만들면 이름으로 호출할 수 있다는 것도 알겠는데요. 막상 “그래서 패킷이 실제로 어디를 지나가는데?”라고 물으면 모르겠습니다... 저도 그랬습니다ㅎㅎ

특히 아래 질문들이 계속 꼬리를 물었습니다.

· 같은 Pod 안의 컨테이너끼리는 왜 localhost로 통신할 수 있을까?

· 다른 노드의 Pod IP를 물리 네트워크는 어떻게 찾아갈까?

· Pod가 재생성돼 IP가 바뀌는데 서비스는 왜 계속 멀쩡할까?

· curl http://web 한 줄 뒤에서 DNS, iptables, VXLAN은 무슨 일을 할까?

결국 쿠버네티스 통신을 이해하려면 기능 이름을 따로 외우기보다, Flannel을 기준으로 패킷 하나가 출발지 컨테이너에서 목적지 Pod까지 이동하는 장면을 순서대로 따라가보는게 좋을 것 같아서 이번 글에서는 컨테이너의 Namespace부터 CNI, Service, kube-proxy까지 하나의 흐름으로 이어보겠습니다.

1. 시작은 Namespace: 어디까지 격리하고 어디까지 공유할까?

컨테이너는 Linux Namespace를 사용해 서로의 자원을 격리합니다.

· UTS Namespace: hostname 분리

· IPC Namespace: 프로세스 간 통신 자원 분리

· Network Namespace: 네트워크 인터페이스, 라우팅 테이블, 포트 공간 분리

· PID Namespace: 프로세스 ID 분리

· Mount Namespace: 파일 시스템의 마운트 지점 분리

· User Namespace: 사용자와 그룹 ID 분리

여기까지만 보면 컨테이너마다 모든 것을 따로 쓰면 될 것 같습니다. 그런데 쿠버네티스의 최소 배포 단위는 컨테이너가 아니라 Pod입니다.

하나의 Pod 안에는 애플리케이션 컨테이너와 사이드카처럼 서로 긴밀하게 붙어 움직여야 하는 컨테이너가 함께 들어갈 수 있습니다. 이 컨테이너들이 네트워크까지 완전히 분리되어 있으면 매번 서로의 IP를 찾고 연결해야 하겠죠. 쿠버네티스는 여기서 조금 다른 선택을 합니다.

쉽게 말하면 같은 Pod의 컨테이너들은 한집에 사는 룸메이트입니다. 각자 방과 짐은 따로 관리할 수 있지만, 집 주소와 현관은 같이 씁니다. 그래서 같은 IP와 라우팅 테이블, 포트 공간을 공유하고 localhost로 서로 통신할 수 있습니다.

이 때문에 주의할 점도 있습니다. 같은 Pod의 컨테이너 A가 8080 포트를 이미 사용하고 있다면 컨테이너 B는 같은 8080 포트를 사용할 수 없습니다. 컨테이너가 둘이어도 네트워크 관점에서는 한 호스트처럼 보이기 때문입니다.

그런데 여기서 또 질문이 생깁니다.

애플리케이션 컨테이너가 죽었다가 다시 생기면, 공유하던 네트워크 공간도 함께 사라지는 것 아닐까?

그래서 Pod에는 흔히 pause container라고 부르는 아주 작은 인프라 컨테이너가 먼저 만들어집니다. 이 컨테이너가 Pod의 Network Namespace를 잡고 있고, 실제 애플리케이션 컨테이너들이 그 공간에 참여합니다. 앱 컨테이너가 재시작돼도 Pod라는 그릇과 네트워크 정체성은 유지할 수 있는 이유입니다.

2. Pod에 IP를 붙여주는 CNI

Pod 안의 통신은 이해했습니다. 이제 Pod 바깥으로 나가보겠습니다.

1. Pod의 Network Namespace에 네트워크 인터페이스를 만든다.

2. Pod에 IP 주소를 할당한다.

3. Pod 쪽 인터페이스와 노드 쪽 인터페이스를 veth pair로 연결한다.

4. 라우팅 정보나 오버레이 네트워크 구성을 설정한다.

CNI 브리지와 veth 연결

veth pair는 양쪽이 붙어 있는 가상 랜 케이블이라고 생각하면 편합니다. 한쪽 끝은 Pod 안에서 eth0로 보이고, 다른 한쪽 끝은 Worker Node의 브리지에 붙습니다. PPT의 예시에서는 cni0가 가상 스위치 역할을 합니다.

같은 노드 안의 Pod끼리는 비교적 단순합니다. 출발지 Pod의 패킷이 veth를 타고 cni0 브리지에 도착하고, 브리지는 목적지 Pod와 연결된 다른 veth로 패킷을 전달합니다.

문제는 다른 Worker Node에 있는 Pod입니다.

3. 다른 노드의 Pod CIDR을 물리 스위치가 알 수 있을까?

예를 들어 Worker Node 1은 10.244.1.0/24, Worker Node 2는 10.244.2.0/24를 Pod CIDR로 사용한다고 해보겠습니다.

Node 1의 Pod가 10.244.2.10으로 패킷을 보냅니다. Node 1 내부까지는 라우팅할 수 있는데, 그 다음부터가 문제입니다.

서로 다른 노드의 Pod 통신 문제

물리 스위치나 기존 네트워크 장비는 보통 Worker Node의 실제 IP 대역은 알아도 쿠버네티스가 내부에서 만든 10.244.2.0/24 대역까지 자동으로 알지는 못합니다.

“목적지가 10.244.2.10인데… 그 주소가 어느 노드 뒤에 있지?”가 되는 겁니다.

이 문제를 푸는 대표적인 방법은 크게 두 가지입니다.

방법 1. Native Routing

각 Worker Node와 물리 네트워크가 모든 Pod CIDR의 경로를 알게 만드는 방식입니다.

예를 들면 Node 1의 라우팅 테이블에 아래와 같은 경로가 들어갑니다.

10.244.2.0/24 via 192.168.100.12

Native Routing 방식

Pod IP를 그대로 유지하기 때문에 출발지와 목적지를 추적하기 쉽고, 별도의 캡슐화 오버헤드도 적습니다. VPC 라우팅이나 BGP와 자연스럽게 통합할 수 있다는 장점도 있습니다.

다만 모든 네트워크 구간이 Pod CIDR을 알아야 합니다. 노드가 늘고 경로가 많아질수록 라우팅 정보를 어떻게 배포하고 관리할지가 중요해집니다.

방법 2. Overlay Network

기존 물리 네트워크가 Pod 대역을 모른다면, Pod 패킷을 Node 패킷 안에 한 번 더 포장해서 보낼 수도 있습니다.

Overlay와 캡슐화

택배로 비유하면 원래 목적지인 Pod 주소가 적힌 작은 상자를, Worker Node 주소가 적힌 큰 상자에 넣는 방식입니다. 물리 네트워크는 바깥 상자의 Node IP만 보고 목적지 노드까지 배송합니다. 목적지 노드에 도착하면 바깥 포장을 벗기고 원래 Pod로 전달합니다.

VXLAN 모드가 대표적인 예입니다. 기존 인프라 라우팅을 크게 건드리지 않아도 되는 대신 캡슐화에 따른 헤더와 처리 비용이 생깁니다.

정리하면 Native Routing은 “모두가 Pod 주소를 알게 하자”, Overlay는 “모르는 주소는 Node 주소로 포장해 보내자”에 가깝습니다.

4. 그런데 Pod IP를 직접 호출하면 안 되는 이유

여기까지 오면 Pod끼리 통신은 됩니다. 그러면 애플리케이션이 상대 Pod IP를 직접 저장해두고 요청하면 끝일까요?

Pod는 영구적인 서버가 아닙니다. 장애가 나거나 배포가 갱신되면 사라졌다가 새로운 IP로 다시 생성될 수 있습니다. Replica가 1개에서 4개로 늘어날 수도 있고, 반대로 줄어들 수도 있습니다.

오늘의 backend Pod가 10.244.1.20이었다고 해서 내일도 그 주소라는 보장은 없습니다. 음식점 직원에게 주문하려고 매번 주방 직원 개인 휴대폰 번호를 외우는 것과 비슷합니다. 직원이 바뀌면 주문 자체가 끊깁니다.

그래서 쿠버네티스는 Service라는 고정된 창구를 제공합니다.

Service가 제공하는 핵심은 세 가지입니다.

· 변하지 않는 가상 IP(ClusterIP)

· 변하지 않는 DNS 이름

여러 Pod Endpoint로의 로드밸런싱

Service는 selector와 일치하는 Pod들을 Endpoint로 묶습니다. 예를 들어 app: backend 라벨을 가진 Pod가 2개라면 둘 다 같은 Service 뒤에 붙습니다. Pod가 교체되거나 추가되면 Endpoint 목록도 바뀝니다.

클라이언트는 변화하는 Pod IP를 몰라도 됩니다. 그냥 backend-api라는 Service만 바라보면 됩니다.

5. `curl http://backend-api` 뒤에서 벌어지는 일

이제 실제 요청 한 번을 따라가 보겠습니다.

Order Pod에서 아래처럼 요청했다고 가정합니다.

curl http://backend-api/api

1) CoreDNS가 Service 이름을 IP로 바꾼다

Pod 안의 DNS 설정은 클러스터 DNS를 바라봅니다. backend-api라는 짧은 이름은 같은 Namespace를 기준으로 탐색되고, 최종적으로 backend-api.default.svc.cluster.local 같은 FQDN으로 해석될 수 있습니다.

CoreDNS는 이 이름에 대응하는 Service의 ClusterIP를 돌려줍니다.

2) 클라이언트는 Service IP를 목적지로 패킷을 만든다

예를 들어 Service IP가 10.96.0.50, 포트가 80이라면 클라이언트는 그 주소로 요청을 보냅니다.

그런데 ClusterIP는 특정 네트워크 카드에 실제로 붙어 있는 일반 IP가 아닙니다. 말 그대로 가상 IP입니다. 그렇다면 이 패킷을 누가 가로채서 실제 Pod로 보내줄까요?

3) kube-proxy가 만든 규칙이 실제 Pod로 DNAT한다

전통적인 iptables 모드에서는 kube-proxy가 Service와 Endpoint 변화를 감시하면서 노드의 iptables 규칙을 계속 갱신합니다.

Service 요청의 DNS와 DNAT 흐름

패킷이 Service IP와 포트에 해당하면 Service 전용 체인으로 이동하고, 거기서 여러 Endpoint 중 하나가 선택됩니다. 이후 목적지 주소가 실제 Pod IP와 포트로 바뀝니다. 이것이 DNAT입니다.

예를 들면 아래처럼 바뀔 수 있습니다.

10.244.1.10:41000 → 10.96.0.50:80
↓ DNAT
10.244.1.10:41000 → 10.244.2.30:8080

목적지가 실제 Pod IP로 바뀐 다음부터는 앞에서 본 Pod-to-Pod 통신 방식이 다시 등장합니다. 목적지 Pod가 다른 노드에 있다면 Native Routing으로 가거나, Flannel 같은 CNI가 VXLAN 터널로 전달합니다.

즉 curl http://backend-api 한 줄 안에는 DNS 조회 → Service IP 매칭 → Endpoint 선택 → DNAT → 노드 간 라우팅이 연달아 들어 있습니다. 한 줄 치고 끝났는데 뒤에서는 꽤 많은 분들이 일하고 계십니다..

이 다음은 CNI별로 어떤식으로 동작이 바뀌는지 차이점이 뭔지 궁금하여 관련하여 테스트해본걸 작성하도록 하겠습니다.

감사합니다.

[Network 기초] 2. L2 스위치 기본동작 이해하기 - 왜 L2 스위치가 필요하지?

ithailey — Sat, 18 Apr 2026 15:45:14 +0900

안녕하세요, 오늘은 네트워크 기초 1에서 생략 되었던 내용중 하나인 L2 스위치 기본동작에 대해서 이해하는 시간을 가져보겠습니다.

일단 L2 스위치가 어떻게 동작 하는지 알기 이전에 왜 L2스위치가 나왔지?에 대해서 공부를 하고자 합니다.

왜 L2스위치가 나왔지?

우리가 컴퓨터가 총 4대있다고 가정합니다. 이 4대가 서로 통신할 수 있게 하는 가장 간단한 방법이 뭘까요? 바로 모든 컴퓨터를 서로 선으로 연결하는거겠죠. 초기의 네트워크에서는 컴퓨터를 여러대 연결하기 위해서 1:1로 선을 연결해야했습니다. 그런데 이게 컴퓨터 수가 너무 많아지다보니.. 이걸 다 연결하기가 어려워진거죠.

이걸 다 1:1로 연결하긴 어렵다..

그래서 처음에 등장했던게 허브(Hub)입니다. 허브는 여러 장비를 허브에 꽂으면 허브에 들어온 신호들을 허브에 있는 모든 포트로 뿌려줍니다. 훨씬 간단하죠? 그런데 여기에서 네트워크 규모가 점점 더 커지니까 여러가지 문제가 생깁니다.

허브를 사용하니까 간단하다!

사실 허브는 물리 연장선에 가까워요. 들어오는 모든 프레임을 모든 포트로 복제해서 뿌리는 원리라서 그렇습니다. 그렇다보니 네트워크 규모가 커지면서 많은 장비들이 내가 받을 필요가 없는 데이터를 계속 받게 됩니다. 또한 여러 장비가 동시에 송신할 경우 충돌도 생각해야합니다. 왜냐하면 신호들이 분리가 되지 않거든요.. 만약에 두 신호가 동시에 들어오면 충돌이 일어나버립니다. 그래서 충돌을 막기위해서 눈치보면서 비어있는지 보고, 비어있으면 전송하고, 그러다가도 충돌나면 멈추고, 적당히 기다리다가 다시 전송하고 이런 동작을 합니다. 이런 동작의 이름을 CSMA/CD라고 하는데, 결국은 규모가 커지면 커질수록 재전송도 많아지고, 속도가 느려질 수 밖에 없겠죠. 마지막으로는 모두가 받게 되다보니 귓속말이 안됩니다.. 그냥 안내방송이랑 다를게 없어요. 난 B한테만 이야기하고싶은데 C도 D도 E도 알게 됩니다.

그래서 이러한 어려움들을 극복하기 위해서 스위치라는 장비가 만들어집니다.

그래서 스위치가 어떻게 해결했는데?

일단 첫번째로 스위치는 신호를 받을때 충돌나는지 눈치 보지 않아도 되도록 각 포트들을 독립적으로 봅니다. 이게 용어로 말을 하자면 collision domain을 분리를 했다고 하죠. 허브는 모두가 다 같은 collision domain안에 있어서 서로 눈치싸움을 한건데 스위치는 각각이 다른 collision domain을 가지고 있으니까 눈치 싸움 안해도 됩니다. 대신에 스위치 안에 버퍼가 있어서 받아서 버퍼에 저장했다가 판단 후 전송하는 방법을 사용합니다.

두번째로 스위치는 받은 모든걸 모든 포트에 뿌리지 않습니다. 받아야하는 애만 받을 수 있도록 판단이라는걸 합니다. 이 판단을 하기 위해서 스위치에 크게 4가지 기본 동작이 생깁니다.

-누가(장비) 어디에(포트) 있는지 알아야 하니까 이 정보를 배우자(Learning)

-특정 포트로만 보낼 수 있게 해야함(Forwarding)

-특정 포트를 모를 때는 어쩔 수 없으니 한번만 다 뿌리자(Flooding)

-들어온 포트로는 보내지 않고,보내지 않을 때는 drop하자(filtering)

이렇게 하니까 충돌이 사라지고 성능도 좋아지면서 귓속말도 가능해졌네요!

근데 여기서 한가지 더 생각할 부분이 생겼습니다. 귓속말이 가능하긴 한데.. 만약 내가 귓속말 하고 싶은 친구가 어떤 포트에 연결되어있는지를 모르겠습니다. 그러면 어떻게 하죠? 허브에서는 어찌되었던 안내방송을 하니까 그 친구가 듣게 될텐데.. 그래서 결국은 스위치에서도 아까 이야기한 기본 동작중에 flooding이 있습니다. 모를때는 어쩔 수 없으니 다 뿌리자! 그래서 이렇게만 동작하면 만약 전 A랑 B친구한테는 이야기해도 괜찮은데 C, D친구랑은 사이가 안좋아서 말 안하고 싶을 경우 문제가 생깁니다. 이럴 경우는 물리적으로 다른 스위치에 두는 수 밖에 없습니다 ㅠㅠ

그런데 이게 물리적으로 분리를 하려니까 포트가 너무 아깝습니다. 스위치하나에 포트가 몇개일까요?

이게 예시용으로 가져온 시스코 스위치인데, 딱봐도 포트가 엄청 많습니다. 이 포트를 다 안쓰고 하나를 더 사다니.. 비용적으로 아깝습니다. 그래서 스위치 안에서 논리적으로 분리를 해보자! 해서 나온 개념이 바로 “VLAN”입니다. VLAN도 설명할 내용이 꽤나 있으므로.. VLAN은 다음 글로 넘어가보도록 하겠습니다.

[Network 기초] 1. 동일 서브넷 내 통신 과정 이해하기

ithailey — Sun, 22 Feb 2026 20:50:24 +0900

안녕하세요, 오늘은 네트워크의 가장 기본이 되면서도 중요한 동일 서브넷(L2) 내에서의 통신 과정을 시나리오를 통해 자세히 알아보려고 합니다.

Web 서버에서 WAS 서버로 ping을 보낼 때, 실제 패킷과 프레임이 어떤 과정을 거쳐 전달되는지 단계별로 정리해 보겠습니다.

1. 시나리오 환경 설정

먼저, 테스트 환경의 구성은 다음과 같습니다.

VLAN 10 (WEB/WAS): eth1/1 (Web), eth1/2 (WAS) 연결
VLAN 20 (DB): eth1/3 연결
Switch (ToR): 모든 포트는 Access Port로 설정
Web 서버: IP 192.168.1.10 / MAC 52:54:00:43:3e:77
WAS 서버: IP 192.168.1.20 / MAC 52:54:00:55:38:67
DB 서버: IP 192.168.2.10 / MAC 52:54:00:B4:E9:FB

전제 조건: Web 서버와 WAS 서버 모두 ARP Table이 비어 있는 상태입니다.

2. 통신 시작: 동일 네트워크 판단

Web 서버에서 ping 192.168.1.20 명령을 실행하면, 서버 OS는 자신의 IP/Mask와 목적지 IP를 비교합니다.

판단: 192.168.1.10/24와 192.168.1.20은 동일 네트워크에 있습니다.
결과: 게이트웨이를 거치지 않고 목적지 MAC 주소로 직접 전달을 시도합니다.

3. ARP 단계: 상대방의 MAC 주소를 찾아라!

하지만 현재 Web 서버는 WAS 서버의 MAC 주소를 모릅니다. 이때 ARP(Address Resolution Protocol) 과정이 시작됩니다.

1. ARP Request 송신: Web 서버는 "IP 192.168.1.20 쓰시는 분 MAC 주소 좀 알려주세요!"라는 메시지를 브로드캐스트(FF:FF:FF:FF:FF:FF)로 보냅니다.

2. 스위치 학습 및 플러딩: 스위치는 Web 서버의 MAC을 학습하고, 해당 VLAN 10의 모든 포트로 프레임을 뿌립니다(Flooding).> 이때 L2스위치의 여러 기본 동작이 있고 많이 생략되었는데, 해당 글에서는 다루지 않고 따로 글을 작성해볼 예정입니다.

3. WAS 서버 응답: WAS 서버는 타겟 IP가 자신임을 확인하고 자신의 MAC 주소를 담아 ARP Reply를 유니캐스트로 보냅니다.

4. 학습 완료: Web 서버는 수신한 ARP Reply를 통해 WAS 서버의 MAC 주소를 ARP Table에 저장합니다.

4. ICMP 단계: 드디어 Ping 발송!

상대방의 MAC 주소를 알았으니 이제 진짜 Ping(ICMP)을 보낼 차례입니다.

1. ICMP Echo Request 전송: Web 서버는 목적지 MAC에 WAS 서버의 주소를 넣어 프레임을 전송합니다.

2. 스위치 포워딩: 스위치는 이미 학습된 MAC Table을 조회하여 eth1/2(WAS 연결 포트)로만 프레임을 정확히 전달합니다.

3. ICMP Echo Reply 응답: 프레임을 받은 WAS 서버는 목적지가 자신임을 확인하고 Echo Reply를 만들어 다시 Web 서버로 보냅니다.

5. 결과 확인

Web 서버가 WAS 서버로부터 Echo Reply 패킷을 최종 수신하면, 우리 화면에는 드디어 익숙한 Ping 결과가 출력됩니다.

마무리하며

동일 서브넷 통신에서 핵심은 "상대방의 MAC 주소를 아느냐"입니다. MAC 주소를 모르면 ARP 브로드캐스트가 먼저 발생하고, 그 이후에 유니캐스트 통신이 이루어진다는 점입니다.

다음 포스팅에서는 라우팅을 통한 서로 다른 서브넷 간의 통신(L3) 과정도 다뤄보도록 하겠습니다.