[Docker] 도커 네트워크의 이해를 위한 실습

Docker Network

추후 쿠버네티스로 넘어가면 컨테이너가 여러 대로 구성되는데, 이때 이 컨테이너들이 어떻게 통신을 하는지 이해가 필요하다.

컨테이너는 Linux Namespace 기술을 이용해 각자 격리된 네트워크 공간을 할당받는다. 기본적으로 172.17.0.0/16 대역의 IP를 순차적으로 할당 받는데, 이 IP는 컨테이너가 재시작할 때마다 변경될 수 있다.

컨테이너는 외부와 통신하기 위해 2개의 네트워크 인터페이스를 함께 생성한다. 하나는 컨테이너 내부 Namespace에 할당되는 eth0 인터페이스, 다른 하나는 호스트 네트워크 브리지 docker0에 바인딩 되는 vethXXXXXXX 형식의 veth 인터페이스이다. (“veth”는 “virtual eth”라는 의미)
컨테이너의 eth0인터페이스와 호스트의 veth 인터페이스는 서로 연결되어 있다.

네트워크 종류

1. bridge 타입

• 외부 네트워크와 연결되어 있는 독립적인 네트워크
• 컨테이너를 생성하면 기본적으로 설정됨
• 컨테이너는 외부의 리포지터리에 접근할 수 있으며 -p 옵션으로 외부에 포트도 공개 가능
  docker network inspect bridge

2. host 타입

• 컨터이너를 호스트 컴퓨터와 동일한 네트워크에서 운용하기 위해 사용
  docker network inspect host
  

3. none 타입

• 컨테이너가 어떤 네트워크와도 연결(attached)되지 않음
• 외부 네트워크나 다른 컨테이너에서 접근할 수 없음

네트워크 관련 명령어

docker network ls : 네트워크 리스트 출력
docker network inspect : 네트워크 명을 지정, 자세한 내용 표시
docker network create : 네트워크 생성
docker network rm : 네트워크 삭제
docker network connect : 컨테이너를 네트워크에 연결
docker network disconnect : 컨테이너를 네트워크에서 연결 해제

실습

네임스페이스끼리 통신

linux namespace를 이용해 직접 가상 네트워크를 설정하고 Docker Network의 연결을 이해해보자

리눅스 namespace는 현대 컨테이너 구현에 있어서 근간이 되는 기술로, 전체 시스템 리소스로부터 개별 프로세스를 격리 시켜 주는 기능이다.
예를 들어, PID namespace는 프로세스의 PID를 전체 process ID 공간으로부터 분리하는데, 이 뜻은 두개의 다른 프로세스가 한 호스트에서 각자만의 PID관리를 수행하여 동일한 PID를 가질 수 있다는 것

1. VM을 1대 준비한다. (k8s나 docker가 전혀 설치되지 않은 새로운 가상머신)
2. 네임 스페이스를 생성하여 확인한다.

   ip netns add ns1
   ip netns add ns2
   ip netns list

3. 가상의 링크를 생성한다.

   ip link add veth-ns1 type veth peer name veth-ns2

현재까지는 두 개의 namespace와 link만 생성되었고, 아무런 연결도 되지 않은 모습

4. 각 네임스페이스를 link에 연결

   ip link set veth-ns1 netns ns1
   ip link set veth-ns2 netns ns2

각 네임스페이스는 link에 연결되었으나 아직 네트워크는 올리지 않은 상태

5. 각 스페이스에 ip 설정

   ip netns exec ns1 ip address add [설정할 IP 1]/24 dev veth-ns1
   ip netns exec ns2 ip address add [설정할 IP 2]/24 dev veth-ns2

6. 인터페이스 활성화 (up)

   ip link set veth-ns1 netns ns1
   ip link set veth-ns2 netns ns2

위의 예시는 우선 ns1과 연결된 link만 up시킨 상태이다. 그림을 보면 ns1의 veth-부분만 UP된 걸 확인할 수 있다.

7. 통신 확인

   ip netns exec ns1 ping [ns2 IP]

ns2도 마저 UP시킨 다음 ping 테스트를 해보면 정상적으로 통신하는 걸 확인할 수 있다.

가상의 브릿지 장비를 통해서 통신

1. 가상의 namespace와 bridge 추가

   ip netns add ns1
   ip link add bridge1 type bridge

brctl show 명령어를 통해 확인해보면 아직은 연결이 안 된 상태임을 확인할 수 있다.

2. 가상의 링크(통신을 위한 선) 생성 후 bridge와 namespace를 각각 연결

   ip link add ns1-veth type veth peer name ns1-veth-br
   ip link set ns1-veth netns ns1
   ip link set ns1-veth-br master bridge1

여기서 왜 ns1-veth가 down(초록색)상태인가 싶을 수 있는데, 네임스페이스(ns1)에 veth 한쪽(ns1-veth) 연결함으로써 ns1-veth는 ns1 안에서만 보이기 때문에 이와 같이 표현했다.
이 인터페이스는 네임스페이스 안쪽에서 활성화해야 한다.

3. 가상의 네임스페이스와 bridge에 ip를 지정한 다음, bridge 연결을 활성화

   ip netns exec ns1 ip addr add [ns의 IP 설정]/24 dev ns1-veth
   ip addr add [bridge의 IP 설정]/24 dev bridge1
   ip link set bridge1 up
   ip link set ns1-veth-br up

bridge를 UP시키는 건 스위치를 ON하는 것과 같은 개념이라고 생각하면 된다.

4. 네임스페이스가 등록된 link를 UP

   ip netns exec ns1 ip link set ns1-veth up

ns1-veth는 ns1 안에서만 보이므로 이 인터페이스는 네임스페이스 안쪽에서 활성화된다.

5. ns2, bridge2 추가

같은 방법으로 bridge2와 ns2도 추가

ping test를 해보면 아직은 라우팅 테이블에 경로가 없기 때문에 외부 네트워크(브릿지)로 나가는 방법을 모르는 상태이다. 라우팅 테이블에 경로를 추가해야 통신이 가능하다.

6. 라우팅 테이블 추가 후 다시 ping test

   ip netns exec ns1 ip route add default via [bridge1 IP]
   ip netns exec ns1 ip route add default via [bridge2 IP]

ns1에서 각각의 bridge1으로 ping test
정상적으로 동작하는 걸 확인할 수 있다.

ns1에서 ns2와 bridge2로 각각 ping test

각 bridge에는 ping이 되지만 ns끼리는 통신이 불가능하다.

이는 네임스페이스(ns1, ns2)는 각 브릿지를 통해만 연결되며, 직접 서로의 IP를 인지하지 못하기 때문이다. 그래서 ns1과 ns2 간 직접 통신은 불가능하고, 브릿지 IP까지만 도달할 수 있다.
브릿지끼리 라우팅이나 NAT 설정을 해야 ns 간 통신이 가능하다. (포트포워딩)

7. 본인에게 온 IP가 아니어도 패킷을 버리지 않도록 설정

   sysctl -w net.ipv4.ip_forward=1

8. NAT 설정

   iptables -t nat -A POSTROUTING -s 111.111.113.0/24 -j MASQUERADE
   iptables -t nat -A POSTROUTING -s 111.111.114.0/24 -j MASQUERADE
   iptables -t nat -L #NAT 설정 확인

이렇게 하면 ns1과 ns2도 서로 통신이 가능하게 된다.

그 외 명령어

네임스페이스 지우는 명령어

ip netns del [네임스페이스 이름]

브릿지 다운

ip link set [브릿지이름] down

브릿지 삭제 명령어

brctl delbr [브릿지 이름]