Docker 기초 9편: Docker 및 Kubernetes 네트워크

1. Docker 네트워크

먼저 알아둘 단어

쉬운 비유: Bridge 네트워크는 가상 공유기에 여러 컨테이너를 연결한 모습입니다. 컨테이너는 내부 주소를 쓰고, 외부로 나갈 때 호스트가 주소를 바꿉니다.

1.1 Bridge 네트워크 구조

flowchart LR
    APP["Container App"] --> E0["container eth0"]
    E0 --> V1["veth pair"]
    V1 --> BR["docker0 또는<br/>사용자 정의 bridge"]
    BR --> IP["Host IP stack"]
    IP --> NAT["Netfilter<br/>NAT,필터링"]
    NAT --> NIC["Physical NIC"]
    NIC --> INTERNET["Internet"]

Bridge 네트워크의 특징은 다음과 같습니다.

• 컨테이너마다 별도의 Network Namespace와 내부 IP를 사용합니다.
• 컨테이너의 eth0와 호스트의 Bridge를 veth pair로 연결합니다.
• 같은 Bridge에 있는 컨테이너끼리는 내부 네트워크로 통신합니다.
• 외부로 나갈 때는 보통 SNAT/MASQUERADE가 적용됩니다.
• 외부에서 들어오려면 일반적으로 포트를 게시합니다.

1.2 기본 Bridge, 사용자 정의 Bridge, Host 비교

사용자 정의 Bridge를 만드는 예.

docker network create my-bridge

docker run -d --name web --network my-bridge nginx
docker run -d --name api --network my-bridge my-api

같은 사용자 정의 Bridge에 연결된 컨테이너는 Docker의 내장 DNS를 통해 web, api 같은 컨테이너 이름으로 서로를 찾을 수 있습니다.

Host 네트워크는 다음처럼 사용합니다.

docker run --network host nginx

이 모드에서는 컨테이너가 호스트의 Network Namespace를 공유하므로 별도의 컨테이너 IP, veth, Bridge를 사용하지 않습니다. 호스트의 다른 프로세스와 포트가 충돌할 수 있으며, 일반적인 -p 포트 게시의 의미도 없어집니다. 동작과 지원 범위는 운영체제 및 Docker 환경에 따라 차이가 있습니다.

1.3 외부에서 컨테이너로: Port Publishing과 DNAT

docker run -d -p 8080:80 nginx

-p 8080:80은 호스트의 8080 포트로 들어온 요청을 컨테이너의 80 포트로 전달한다는 뜻입니다.

flowchart LR
    C["External Client"] --> H["HostIP:8080"]
    H -->|"DNAT<br/>목적지 변경"| R["Routing,Forwarding"]
    R --> BR["Linux Bridge"]
    BR --> V["veth pair"]
    V --> N["ContainerIP:80<br/>nginx"]

패킷 수준의 개념적인 흐름은 다음과 같습니다.

1. 패킷이 호스트의 물리 NIC로 들어옵니다.
2. Netfilter 규칙이 목적지를 HostIP:8080에서 ContainerIP:80으로 바꿉니다(DNAT).
3. 커널 라우팅 테이블이 컨테이너 네트워크로 전달할 경로를 고릅니다.
4. Bridge가 FDB를 보고 대상 MAC 주소가 연결된 veth 포트를 찾습니다.
5. veth를 통해 컨테이너의 eth0와 Nginx에 도착합니다.

• Neighbor/ARP Table: 같은 L2 네트워크에서 IP 주소와 MAC 주소의 관계를 저장합니다.
• FDB(Forwarding Database): Bridge가 MAC 주소와 Bridge 포트(veth)를 연결해 기억합니다.

Docker가 사용하는 실제 방화벽 백엔드는 환경에 따라 iptables 또는 nftables 기반일 수 있지만, 핵심은 Linux Kernel의 Netfilter 경로에서 주소 변환과 필터링이 이뤄진다는 점입니다.

1.4 외부로 나가기: SNAT와 MASQUERADE

컨테이너가 인터넷에 요청을 보내는 흐름입니다.

flowchart LR
    C["ContainerIP:5000"] --> BR["Bridge"]
    BR --> H["Host routing"]
    H -->|"SNAT 또는 MASQUERADE"| P["HostPublicIP:임시포트"]
    P --> I["Internet"]

• SNAT는 패킷의 출발지 주소를 바꿉니다.
• MASQUERADE는 호스트 인터페이스의 현재 주소를 사용하도록 만든 SNAT 방식입니다.
• 응답이 돌아오면 연결 추적 정보에 따라 원래 컨테이너의 IP와 포트로 복원됩니다.

1.5 DHCP, 사설 IP, NAT, NAPT 구분

Docker 네트워크를 이해하려면 가정용 공유기를 떠올리면 쉽습니다.

flowchart LR
    A["노트북<br/>192.168.1.42:5000"] --> R["공유기<br/>DHCP,Gateway,NAPT"]
    B["태블릿<br/>192.168.1.23:5000"] --> R
    R --> P["공인 IP<br/>203.0.113.57"]
    P --> I["Internet"]

NAPT의 예는 다음과 같습니다.

192.168.1.42:5000  → 203.0.113.57:2001
192.168.1.23:5000  → 203.0.113.57:2002

두 기기가 하나의 공인 IP를 공유해도 외부 포트가 다르므로, 공유기는 돌아온 응답을 올바른 내부 기기에 전달할 수 있습니다. 실무에서 단순히 NAT라고 부르는 기능이 실제로는 포트까지 변환하는 NAPT인 경우가 많습니다.

2. Kubernetes CNI와 Calico

먼저 알아둘 단어

쉬운 비유: CNI는 Kubernetes와 네트워크 플러그인 사이의 계약서이고, Calico는 그 계약에 맞춰 Pod의 랜선과 경로, 보안 규칙을 실제로 구성합니다.

2.1 Pod가 생성될 때

flowchart LR
    K["Kubernetes가 Pod 생성"] --> CNI["CNI 플러그인 호출"]
    CNI --> IP["Pod IP 할당"]
    IP --> V["veth,route 구성"]
    V --> READY["Pod 네트워크 준비"]

Calico는 CNI를 통해 Pod 인터페이스와 경로를 구성하며, NetworkPolicy를 실제 네트워크 규칙으로 적용할 수 있습니다.

2.2 같은 노드와 다른 노드의 통신

flowchart LR
    PA["Pod A"] --> VA["veth"]
    VA --> RA["Node A routing"]
    RA -->|"직접 라우팅,IP-in-IP,VXLAN 등"| RB["Node B routing"]
    RB --> VB["veth"]
    VB --> PB["Pod B"]

• 같은 노드: 보통 veth와 노드의 라우팅 경로를 통해 다른 Pod로 전달됩니다.
• 다른 노드: 환경 설정에 따라 직접 라우팅, IP-in-IP, VXLAN 등의 방식으로 전달됩니다.
• BGP: 어떤 Pod CIDR이 어느 노드 또는 라우터 뒤에 있는지 경로를 교환하는 데 사용할 수 있습니다.
• NetworkPolicy: 출발지와 목적지 Pod, Namespace, 포트를 기준으로 통신을 허용하거나 차단합니다.

Calico가 항상 tunl0를 사용하는 것은 아닙니다. IP-in-IP 모드에서는 tunl0가 보일 수 있지만, VXLAN이나 비캡슐화 라우팅 모드에서는 구조가 달라집니다.

2.3 Docker Bridge와 Calico 비교

Docker도 Swarm Overlay처럼 멀티 호스트 네트워크 기능이 있지만, 여기서의 비교는 일반적인 단일 호스트 Bridge 네트워크를 기준으로 합니다.

2.4 CIDR 읽는 법

192.168.0.0/24에서 /24는 앞의 24비트가 네트워크 영역이라는 뜻입니다.

192.168.0.0/24
└─ 전체 주소 수: 2^(32-24) = 256개
└─ 주소 범위: 192.168.0.0 ~ 192.168.0.255

일반적인 IPv4 서브넷에서는 네트워크 주소와 브로드캐스트 주소를 제외해 호스트에 254개를 할당할 수 있습니다. 다만 클라우드나 CNI는 일부 주소를 추가 예약할 수 있으므로 실제 사용 가능 수는 구현에 따라 달라질 수 있습니다.

Prefix 숫자가 커질수록 → 주소 범위가 작아짐
Prefix 숫자가 작아질수록 → 주소 범위가 커짐

3. 전체 요약

구성 요소 한눈에 보기

최종 연결 다이어그램

flowchart TD
    DF["Dockerfile"] -->|build| IMG["Image<br/>읽기 전용 Layers + Metadata"]
    IMG -->|run| D["dockerd"]
    D --> CTD["containerd"]
    CTD --> SHIM["containerd-shim"]
    SHIM --> R["runc"]
    R --> P["Container Process"]
    P --> NS["Namespace"]
    P --> CG["cgroups"]
    P --> FS["OverlayFS rootfs"]
    P --> SEC["Capabilities,SELinux/AppArmor"]
    P --> NET["veth,Bridge,Netfilter"]

초압축 암기

Image       = 실행 환경을 담은 읽기 전용 설계도
Layer       = 이미지의 파일 변경분
Container   = 격리되고 제한된 Linux 프로세스 그룹
dockerd     = Docker 전체 관리
containerd  = 이미지와 컨테이너 생명주기 관리
runc        = OCI 설정대로 실제 컨테이너 생성
Namespace   = 무엇이 보이는가
cgroups     = 얼마나 사용할 수 있는가
OverlayFS   = 어떤 파일 시스템을 보는가
Capability  = 어떤 시스템 동작을 할 수 있는가
SELinux     = 어떤 대상에 접근할 수 있는가
Bridge      = 같은 호스트의 컨테이너 네트워크 연결
NAT         = 패킷의 주소 변환
CNI         = Kubernetes 네트워크 설정 표준
Calico      = Pod 네트워크와 NetworkPolicy 구현