노드가 다르면 패킷은 어떻게 건너가는가 — VXLAN으로 네임스페이스 연결하기

Open Table of contents

1. 네트워크 세팅의 본질
2. 문제 — 물리 네트워크가 파드 IP를 모른다
3. 해결 — 파드 IP 대역을 물리 IP 위에 올린다
4. 실습 — 실제 서버 2대에서
5. 패킷 경로
6. Calico는 이걸 자동으로 한다
8. 정리

1. 네트워크 세팅의 본질

이전 글에서 단일 노드 안에서 네임스페이스를 인터넷에 연결했다. 노드 간으로 확장할 때도 해야 하는 일은 결국 같다.

1. IP 대역 배분  — 어떤 노드가 어떤 서브넷을 담당하는가
2. 라우팅 정의   — 이 대역은 어떤 인터페이스(터널)로 가는가

노드 간 파드 네트워크를 이해하는 핵심은 이 두 가지다. CNI, VXLAN, Felix, IPAM은 모두 이걸 자동화하거나 구현하는 도구다.

2. 문제 — 물리 네트워크가 파드 IP를 모른다

단일 노드에서는 모든 것이 같은 커널 위에 있다. veth pair로 연결하고 라우팅만 추가하면 끝.

노드가 달라지면 패킷이 물리 네트워크를 건너야 한다.

server-01 (172.30.1.98)             server-02 (172.30.1.60)
┌──────────────┐                   ┌──────────────┐
│ banana        │                   │ mango         │
│ 10.200.0.2    │                   │ 10.200.1.2    │
└──────┬───────┘                   └──────┬───────┘
       │ veth                             │ veth
┌──────┴───────┐                   ┌──────┴───────┐
│ 호스트        │                   │ 호스트        │
│ 172.30.1.98   │                   │ 172.30.1.60   │
└──────┬───────┘                   └──────┬───────┘
       │          물리 네트워크             │
       └───────────────────────────────────┘
              172.30.1.0/24만 알고 있음

물리 네트워크(공유기/스위치)는 10.200.x.x를 모른다. 172.30.1.0/24만 안다. 파드 IP는 호스트 안에서만 의미 있는 주소다.

banana → mango 패킷:
  물리 네트워크: "10.200.1.2? 모르는 주소."
  → 패킷 폐기.

3. 해결 — 파드 IP 대역을 물리 IP 위에 올린다

물리 네트워크가 모르는 패킷을 물리 네트워크가 아는 주소로 감싸서 보내는 것이 VXLAN이다.

VXLAN이 감싸기:
  ┌───────────────────────────────────┐
  │ 외부: 172.30.1.98 → 172.30.1.60  │  ← 물리 네트워크가 아는 주소
  │       UDP 4790                    │
  │  ┌─────────────────────────┐      │
  │  │ 내부: 10.200.0.2        │      │  ← 원본 그대로 보존
  │  │     → 10.200.1.2        │      │
  │  └─────────────────────────┘      │
  └───────────────────────────────────┘

이전 글의 MASQUERADE와 비교:

MASQUERADE: 출발지 IP를 "바꿈". 원본 사라짐. (단일 노드 → 인터넷)
VXLAN:      패킷을 통째로 "감쌈". 원본 유지. (노드 → 노드)

여기서 앞서 말한 두 가지가 다시 나온다.

1. IP 대역 배분:
   server-01 → 10.200.0.0/24 담당
   server-02 → 10.200.1.0/24 담당
   (겹치면 어느 노드 건지 구분 불가)

2. 라우팅 정의:
   "10.200.1.0/24로 가는 패킷 → vxlan 터널로"
   (이게 없으면 커널이 어디로 보낼지 모름)

4. 실습 — 실제 서버 2대에서

개념을 직접 손으로 만들어본다. server-01(172.30.1.98), server-02(172.30.1.60).

server-01

# 네임스페이스 + veth (이전 글과 동일)
ip netns add banana
ip link add wire-host type veth peer name wire-banana
ip link set wire-banana netns banana
ip link set wire-host up
ip addr add 10.200.0.1/24 dev wire-host
ip netns exec banana ip addr add 10.200.0.2/24 dev wire-banana
ip netns exec banana ip link set wire-banana up
ip netns exec banana ip link set lo up
ip netns exec banana ip route add default via 10.200.0.1
echo 1 > /proc/sys/net/ipv4/ip_forward

# VXLAN 터널 생성
ip link add vxlan100 type vxlan \
    id 100 local 172.30.1.98 dstport 4790 dev enp1s0 nolearning
ip addr add 10.100.0.1/24 dev vxlan100
ip link set vxlan100 up

# 라우팅 정의 (두 명령이 역할이 다르다)
# ip route: "10.200.1.0/24 대역을 vxlan100 인터페이스로 보내라"
# bridge fdb: "vxlan100으로 나가는 패킷의 실제 목적지는 172.30.1.60이다"
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 172.30.1.60
ip route add 10.200.1.0/24 via 10.100.0.2

server-02

# 같은 구조, IP 대역만 다름
ip netns add mango
ip link add wire-host type veth peer name wire-mango
ip link set wire-mango netns mango
ip link set wire-host up
ip addr add 10.200.1.1/24 dev wire-host
ip netns exec mango ip addr add 10.200.1.2/24 dev wire-mango
ip netns exec mango ip link set wire-mango up
ip netns exec mango ip link set lo up
ip netns exec mango ip route add default via 10.200.1.1
echo 1 > /proc/sys/net/ipv4/ip_forward

# VXLAN 터널 생성 (반대 방향)
ip link add vxlan100 type vxlan \
    id 100 local 172.30.1.60 dstport 4790 dev enp1s0 nolearning
ip addr add 10.100.0.2/24 dev vxlan100
ip link set vxlan100 up

# 라우팅 정의: "10.200.0.0/24 → vxlan 터널로"
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 172.30.1.98
ip route add 10.200.0.0/24 via 10.100.0.1

양쪽 모두 등록해야 한다. 한쪽만 등록하면 패킷은 나가지만 응답이 못 돌아온다.

결과

ip netns exec banana ping -c 2 10.200.1.2
# 64 bytes from 10.200.1.2: icmp_seq=1 ttl=62 time=0.48 ms ✅

TTL이 64 → 62로 줄었다. banana에서 나간 패킷이 server-01 커널에서 한 번, server-02 커널에서 한 번 L3 포워딩을 거쳤기 때문이다. 네임스페이스 자체는 홉이 아니다.

5. 패킷 경로

banana(10.200.0.2) → mango(10.200.1.2):

1. banana: "default via 10.200.0.1"
   → wire-banana → wire-host → server-01 커널

2. server-01 커널: "10.200.1.0/24 via 10.100.0.2 dev vxlan100"
   → VXLAN 캡슐화 (내부: 파드 IP, 외부: 172.30.1.98 → 172.30.1.60 UDP 4790)
   → enp1s0 → 물리 네트워크

3. server-02 커널: UDP 4790 수신 → VXLAN 역캡슐화
   → "10.200.1.0/24 dev wire-host"
   → wire-host → wire-mango → mango 도착

6. Calico는 이걸 자동으로 한다

우리가 수동으로 한 두 가지를 Calico가 자동으로 수행한다.

우리가 수동으로              Calico가 자동으로
──────────────────          ──────────────────────
IP 대역 수동 지정            IPAM이 노드별 서브넷 배분
ip link add vxlan100        vxlan.calico 자동 생성
bridge fdb append           Felix가 FDB 자동 등록
ip route add                Felix가 라우팅 자동 추가

실제 Calico 클러스터의 라우팅 테이블:

같은 노드 파드:
  10.1.30.193 dev cali421b5de6a2e   ← veth 직접. VXLAN 안 거침.

다른 노드 파드:
  10.1.97.64/26 via vxlan.calico    ← VXLAN 터널 경유.

같은 노드면 veth 직접, 다른 노드면 VXLAN. 라우팅 정의만 다를 뿐 구조는 우리가 수동으로 한 것과 동일하다.

8. 정리

노드 간 네트워크 세팅의 본질:

1. IP 대역 배분  → 노드마다 겹치지 않는 서브넷
2. 라우팅 정의   → 이 대역은 이 터널(인터페이스)로

VXLAN은 "물리 네트워크가 모르는 IP를 감싸서 보내는" 터널.
나머지(CNI, Felix, IPAM)는 이 두 가지를 자동화한 것.

단일 노드에서 노드 간으로 확장할 때 추가되는 개념은 하나뿐이다 — 물리 네트워크 위에 파드 IP 대역을 어떤 레벨에서 라우팅할지.