컨테이너 네트워킹 (2) - 오버레이 네트워크 - soo:bak
작성일 :
여러 호스트의 컨테이너가 어떻게 통신하는가
Part 1에서 Linux Bridge를 통해 같은 호스트의 컨테이너들이 통신하는 방법을 살펴보았습니다.
하지만 실제 운영 환경에서는 컨테이너가 여러 호스트에 분산 배포됩니다.
1
2
3
4
5
6
7
8
호스트 A 호스트 B
┌─────────────────┐ ┌─────────────────┐
│ 컨테이너 1 │ │ 컨테이너 3 │
│ 172.17.0.2 │ │ 172.17.0.2 │
│ │ │ (IP 충돌!) │
│ 컨테이너 2 │ │ 컨테이너 4 │
│ 172.17.0.3 │ │ 172.17.0.3 │
└─────────────────┘ └─────────────────┘
이 상황에서 발생하는 문제점:
- 각 호스트의 Docker가 독립적으로 IP를 할당하여 IP 충돌 발생
- 서로 다른 호스트의 컨테이너끼리 직접 통신 불가
단일 호스트의 한계
docker0 브리지는 해당 호스트 내에서만 동작하는 로컬 네트워크입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
호스트 A 호스트 B
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ docker0 (172.17.0.1) │ │ docker0 (172.17.0.1) │
│ │ │ │ │ │
│ ┌──────────┴──────────┐ │ │ ┌──────────┴──────────┐ │
│ │ │ │ │ │ │ │
│ ┌───┐ ┌───┐│ │ ┌───┐ ┌───┐│
│ │C1 │ │C2 ││ │ │C3 │ │C4 ││
│ └───┘ └───┘│ │ └───┘ └───┘│
│ │ │ │
└─────────────────────────────┘ └─────────────────────────────┘
│ │
│ 물리 네트워크 │
└────────────────────────────────────┘
?
C1 → C3 어떻게 통신?
호스트 A의 C1(172.17.0.2)이 호스트 B의 C3(172.17.0.2)로 패킷을 보내면 어떻게 될까요? 목적지가 같은 서브넷으로 보이기 때문에 로컬 브리지에서 찾지만, 실제로는 다른 호스트에 있으므로 통신에 실패합니다.
이 문제를 해결하기 위해 오버레이 네트워크가 등장했습니다.
오버레이 네트워크 개념
오버레이 네트워크는 물리 네트워크(언더레이) 위에 가상의 논리적 네트워크를 구축하는 기술입니다. VPN과 터널링에서 설명한 터널링 개념과 유사합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ 오버레이 네트워크 │
│ (가상 L2/L3) │
│ │
│ 컨테이너들이 같은 네트워크에 있는 것처럼 동작 │
│ │
└─────────────────────────────────────────────────────────────┘
│
캡슐화/역캡슐화
│
┌─────────────────────────────────────────────────────────────┐
│ 언더레이 네트워크 │
│ (물리 L2/L3) │
│ │
│ 실제 호스트 간 통신 (IP 라우팅) │
│ │
└─────────────────────────────────────────────────────────────┘
컨테이너들은 같은 가상 네트워크에 있는 것처럼 동작하며, 실제 통신은 캡슐화된 패킷이 물리 네트워크를 통해 전달됩니다.
VXLAN (Virtual Extensible LAN)
VXLAN은 RFC 7348로 표준화된 오버레이 프로토콜로, L2 프레임을 L3 패킷에 캡슐화하여 전송합니다. 컨테이너 네트워킹에서 가장 널리 사용되는 오버레이 기술입니다.
VXLAN 헤더 구조
아래 도식은 VXLAN으로 캡슐화된 패킷의 구조를 보여줍니다.
1
2
3
4
5
6
7
┌────────────────────────────────────────────────────────────────┐
│ 외부 이더넷 │ 외부 IP │ 외부 UDP │ VXLAN │ 내부 이더넷 │ 내부 IP │
│ 헤더 │ 헤더 │ 헤더 │ 헤더 │ 헤더 │ 헤더 │
│ (14B) │ (20B) │ (8B) │ (8B) │ (14B) │ ... │
└────────────────────────────────────────────────────────────────┘
│ │ │ │
└─ 언더레이(물리) ───┘ └── 오버레이(원본) ────┘
왼쪽의 외부 헤더들은 물리 네트워크에서 라우팅에 사용되고, VXLAN 헤더 이후의 내부 헤더들은 원래 컨테이너가 보낸 패킷입니다.
VNI (VXLAN Network Identifier)
VXLAN 헤더에는 VNI라는 24비트 식별자가 포함됩니다. 이를 통해 최대 약 1,600만 개의 가상 네트워크를 구분할 수 있어, VLAN의 12비트(4,096개) 제한을 극복합니다.
VXLAN 동작
VXLAN이 실제로 어떻게 동작하는지 살펴보겠습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
호스트 A 호스트 B
10.0.0.1 10.0.0.2
┌────────────────────────┐ ┌────────────────────────┐
│ │ │ │
│ 컨테이너 C1 │ │ 컨테이너 C3 │
│ 192.168.1.10 │ │ 192.168.1.20 │
│ │ │ │ ▲ │
│ ▼ │ │ │ │
│ ┌─────────────────┐ │ │ ┌─────────────────┐ │
│ │ VTEP │ │ │ │ VTEP │ │
│ │ (캡슐화) │ │ │ │ (역캡슐화) │ │
│ └────────┬────────┘ │ │ └────────┬────────┘ │
│ │ │ │ │ │
└──────────┼─────────────┘ └──────────┼─────────────┘
│ │
│ 외부 IP: 10.0.0.1 → 10.0.0.2 │
│ 내부 IP: 192.168.1.10 → 192.168.1.20
│ UDP 포트: 4789 │
└───────────────────────────────────────┘
물리 네트워크
C1(192.168.1.10)이 C3(192.168.1.20)에 패킷을 보내면, 호스트 A의 VTEP가 이를 VXLAN으로 캡슐화하고 UDP 4789 포트를 통해 호스트 B로 전송합니다. 호스트 B의 VTEP는 캡슐화를 해제하여 원본 패킷을 C3에 전달합니다.
VTEP (VXLAN Tunnel Endpoint)
VTEP는 VXLAN 터널의 양 끝에서 캡슐화와 역캡슐화를 담당하는 구성요소입니다. 각 호스트에 VTEP가 존재하며, 다음과 같은 역할을 수행합니다:
| 방향 | 역할 |
|---|---|
| 송신 | 컨테이너의 프레임을 VXLAN으로 캡슐화 |
| 수신 | VXLAN 헤더를 제거하고 내부 프레임 추출 |
오버레이 네트워크의 핵심 문제
오버레이 네트워크를 구현할 때 해결해야 할 두 가지 핵심 문제가 있습니다.
1. 목적지 VTEP 찾기
컨테이너 IP가 어느 호스트에 있는지 어떻게 알 수 있을까요? 세 가지 방법이 있습니다:
- 중앙 컨트롤러: etcd, Consul 등에 컨테이너-호스트 매핑 정보 저장
- 학습: ARP 요청을 플러딩하여 위치 학습
- BGP: 라우팅 프로토콜로 경로 광고
2. BUM 트래픽 처리
BUM(Broadcast, Unknown Unicast, Multicast) 트래픽 처리도 중요한 문제입니다. L2 네트워크에서는 ARP 같은 브로드캐스트가 필요한데, 오버레이에서는 이를 다음과 같이 처리합니다:
- 멀티캐스트 언더레이: 물리 네트워크가 멀티캐스트를 지원하면 활용
- 유니캐스트 복제: 모든 VTEP에 유니캐스트로 복제 전송
- 프록시 ARP: VTEP가 ARP 요청에 대리 응답
대부분의 컨테이너 네트워크 솔루션은 중앙 컨트롤러와 프록시 ARP 조합을 사용합니다.
CNI (Container Network Interface)
오버레이 네트워크를 구현하는 방법은 다양합니다. 이런 다양한 네트워크 솔루션을 통일된 방식으로 사용할 수 있도록 CNI(Container Network Interface)가 표준 인터페이스를 정의합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────────────────────────────────────────┐
│ 컨테이너 런타임 │
│ (Docker, containerd, CRI-O) │
└──────────────────────────┬──────────────────────────────────┘
│
CNI 호출
│
▼
┌─────────────────────────────────────────────────────────────┐
│ CNI 플러그인 │
│ (Flannel, Calico, Weave, ...) │
└─────────────────────────────────────────────────────────────┘
│
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
veth 생성 IP 할당 라우팅 설정
CNI 명령
1
2
3
4
5
6
7
8
9
10
11
12
# 컨테이너 네트워크 추가
CNI_COMMAND=ADD
CNI_CONTAINERID=abc123
CNI_NETNS=/var/run/netns/abc123
CNI_IFNAME=eth0
# 플러그인 실행
/opt/cni/bin/flannel < config.json
# 컨테이너 네트워크 삭제
CNI_COMMAND=DEL
/opt/cni/bin/flannel < config.json
플러그인 체이닝
CNI는 여러 플러그인을 체인으로 연결하여 기능을 조합할 수 있습니다.
1
flannel (오버레이) → portmap (포트 매핑) → bandwidth (대역폭 제한)
주요 CNI 플러그인
다양한 CNI 플러그인이 있으며, 각각 다른 설계 철학과 특징을 가집니다.
Flannel
CoreOS가 개발한 Flannel은 가장 단순하고 쉽게 시작할 수 있는 오버레이 네트워크입니다.
Flannel은 여러 백엔드를 지원합니다:
- VXLAN: 기본 옵션으로 L2 오버레이 제공
- host-gw: 같은 L2 네트워크에서 호스트 라우팅 사용 (캡슐화 없음)
- UDP: 사용자 공간 캡슐화 (성능이 낮아 거의 사용하지 않음)
1
2
3
4
5
6
7
# Flannel 설정 예시
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
Flannel은 설정이 단순하고 Kubernetes와 잘 통합되지만, 네트워크 정책 기능이 없다는 제한이 있습니다.
Calico
Calico는 L3 라우팅 기반 네트워크로, Flannel과 다른 접근 방식을 취합니다.
1
2
3
4
5
6
7
8
9
10
11
12
호스트 A (192.168.1.1) 호스트 B (192.168.1.2)
┌─────────────────────┐ ┌─────────────────────┐
│ Pod: 10.244.0.10 │ │ Pod: 10.244.1.10 │
│ │ │ │ ▲ │
│ ▼ │ │ │ │
│ 라우팅 테이블 │ │ 라우팅 테이블 │
│ 10.244.1.0/24 → │ │ 10.244.0.0/24 → │
│ 192.168.1.2 │ │ 192.168.1.1 │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
│ BGP로 경로 교환 │
└──────────────────────────────────┘
Calico의 핵심 특징은 캡슐화 없이(또는 선택적 VXLAN) BGP로 경로를 광고한다는 점입니다. 오버레이 오버헤드가 없어 높은 성능을 제공하며, 네트워크 정책을 기본 지원합니다.
Weave
Weave는 메시 네트워크 방식으로 동작합니다.
1
2
3
4
5
6
7
호스트 A ◄────────► 호스트 B
│ Weave │
│ Mesh │
└──────┬────────┘
│
▼
호스트 C
Weave는 노드들이 자동으로 메시를 형성하고, 암호화를 기본 지원하며, 설정이 간단하다는 장점이 있습니다.
성능 비교 및 선택 가이드
1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────┬────────────┬──────────────┬────────────────────┐
│ 플러그인 │ 캡슐화 │ 성능 │ 네트워크 정책 │
├─────────────┼────────────┼──────────────┼────────────────────┤
│ Flannel │ VXLAN │ 중간 │ 없음 │
│ (host-gw) │ 없음 │ 높음 │ 없음 │
├─────────────┼────────────┼──────────────┼────────────────────┤
│ Calico │ 없음/VXLAN │ 높음 │ 있음 │
├─────────────┼────────────┼──────────────┼────────────────────┤
│ Weave │ VXLAN │ 중간 │ 있음 │
├─────────────┼────────────┼──────────────┼────────────────────┤
│ Cilium │ 없음/VXLAN │ 높음 │ 있음 (L7) │
└─────────────┴────────────┴──────────────┴────────────────────┘
캡슐화를 사용하면 MTU가 감소(VXLAN의 경우 약 50바이트)하고 CPU 오버헤드가 발생합니다. 반면 캡슐화 없는 방식은 언더레이 네트워크가 Pod IP를 라우팅해야 하므로 BGP 피어링이나 정적 라우팅 설정이 필요합니다.
어떤 플러그인을 선택해야 할까?
| 상황 | 권장 플러그인 |
|---|---|
| 처음 시작하거나 단순함을 원함 | Flannel |
| 네트워크 정책이 필요함 | Calico 또는 Cilium |
| 최고 성능이 필요함 | Calico (BGP 모드) |
| L7 정책이나 가시성이 필요함 | Cilium |
| 암호화가 기본 필요함 | Weave |
| 클라우드 환경 (AWS/GCP/Azure) | 클라우드 네이티브 CNI 또는 Calico |
일반적으로 처음 시작한다면 Flannel로 시작하고, 네트워크 정책이나 성능 요구가 생기면 Calico로 마이그레이션하는 경로를 많이 따릅니다.
정리
멀티호스트 컨테이너 네트워킹의 핵심 내용을 정리하면 다음과 같습니다:
- 문제: 단일 호스트의 docker0 브리지는 로컬에서만 동작
- 해결책: 오버레이 네트워크로 물리적 경계를 넘어 연결
- 기술: VXLAN이 가장 널리 사용되는 오버레이 프로토콜
- 표준: CNI가 다양한 네트워크 플러그인의 인터페이스 표준화
이러한 기술들이 Kubernetes의 Pod 네트워킹 기반을 형성합니다. Part 3에서는 Kubernetes가 이런 저수준 기술을 어떻게 추상화하는지 살펴봅니다.
관련 글