Docker Network, 제대로 이해하기 (1)

📌  Docker Series

Docker Engine, 제대로 이해하기 (1) -  docker engine deep dive

Docker Engine, 제대로 이해하기 (2) - namespace, cgroup

> Docker Network, 제대로 이해하기 (1) - libnetwork

Docker Network, 제대로 이해하기 (2) - bridge, host, none drivers

Docker, 제대로 사용하기 - Commands

 

 

안녕하세요.

오늘은 Docker Network를 Deep Dive하고자 합니다.

지난 Docker 시리즈로 Docker Engine에 대해 다루고 3부로 진행하려 했던 Network에 해당됩니다.

내용도 많고 가벼운 주제가 아니라 시리즈를 따로 구성했습니다 〰️

 

해당 포스팅은 네트워크에 대한 기본적인 내용을 충분히 익혔다는 가정하에 작성했습니다.

또한, 모든 그림은 직접 그린 것으로, 사용시 출처 표시 부탁드립니다 🙏🏻.

 

---------------    INDEX     --------------

 

[ 1부 ]

CNM

Libnetwork

Driver

- Bridge

 

[ 2부 ]

- Overlay

- Macvlan

 

----------------------------------------------

 

 

 

Docker의 네트워킹 구조는 Container Network Model(CNM)을 기반으로 형태를 갖춥니다.

즉, Docker 네트워킹의 디자인 가이드 역할을 하죠.

 

CNM이 무엇인지 알고나면, 구현체이자 Docker Network를 담당하는 libnetwork의 자연스럽게 이해 될 것입니다.

그래서 CNM에 대한 내용을 먼저 알아보도록 할게요.

해당 링크를 통해 더 자세히 알아보실 수 있습니다.

 

 

 

CNM

Container Network Model

 

CNM은 디자인 스펙specification입니다.

이 CNM은 Docker Network의 아주 근본적인 아웃라인을 잡습니다.

 

도커 컨테이너 간의 연결을 중개하는 것은 CNM이고,

네트워킹에서 흔히 볼 수 있는 다양성과 복잡성을 추상화하는 것도 CNM입니다.

 

지금부터 아래의 CNM 구성 성분의 주요 세가지인 Sandbox, Endpoint, Network를 같이 살펴볼게요.

 

 

Container Network Model

 

✔️ Sandboxes

Sandbox는 격리된 Network Stack입니다.

 

Network Namespace나 FreeBSD Jail등을 통한 격리된 네트워크 구성으로 생각하시면 됩니다.

Container의 인터페이스나 routing table, DNS 세팅 등을 관리할 수 있습니다. 

Sandbox는 많은 여러 네트워크의 많은 Endpoints들을 가질 수 있습니다.

 

✔️ Endpoints

Endpoint는 Sandbox와 네트워크를 연결합니다. veth와 같은 가상 네트워크 인터페이스입니다.

단 하나의 네트워크와 하나의 Sandbox만을 연결합니다.

 

✔️ Networks

네트워크는 다수의 Endpoint로 구성된, Switch(802.1d bridge)를 소프트웨어로 구현한 것입니다. 

따라서, 서로 통신해야 하는 Endpoint 그룹을 그룹화하거나 격리합니다.

 

 

 

위와 같은 구성으로 마치 격리된 것 같은 네트워크 구조를 구성하고,

설정에 따라 로컬 컨테이너나 원격 컨테이너와 통신할 수도 있게 됩니다.

 

이제 실제로 구현된 내용을 알아보며 제대로 알아보도록 하겠습니다.

 

 

Libnetwork

CNM이 설계 문서라면, libnetwork는 그에 대한 표준 구현체입니다.

실제로 구현되어 Docker Network의 컨테이너 네트워킹이 가능하게 만들었죠.

 

Libnetwork는 위에서 소개한 Sandboxes, Endpoints, Networks를 모두 구현했습니다.

또, libnetwork는 오픈소스이며, Go로 작성되어 cross-flatform을 지원합니다.

libnetwork Repository에서 오픈소스 코드를 확인할 수 있습니다.

 

 

libnetwork

 

✔️ History

지난 포스팅에서 잠시 다뤘던 것처럼, 초기 도커에서는 대부분의 역할을 도커 데몬이 했습니다.

네트워킹도 마찬가지로, 네트워킹에 관련된 코드가 데몬 내에 존재했습니다.

 

시간이 지나면서 데몬은 점점 무거워졌고, 무엇보다 리눅스 원칙을 따르지 않았습니다.

“작은 것이 아름답다”라는 리눅스 원칙은 독립적으로 잘 작동하는 작고 모듈화된 복합적인 도구들을 개발한다는 철학으로,

이로인해 도커 네트워킹이 다른 프로젝트에 활용하기 쉽게 구성되지도 않았습니다 (재사용 불가)

 

 

✔️ Nowadays

결과적으로, CNM에 기반을 둔 libnetwork 외부의 라이브러리로 리팩터링되었습니다.

그래서 현재는 모든 핵심 도커 네트워킹 코드는 libnetwork에 존재합니다.

 

libnetwork는 독립적이고, 모듈화되어 조립하여 사용할 수 있게끔 제작되었습니다.

기본 Service Discovery, 수신 기반의ingress-based 컨테이너 로드밸런싱, 네트워크 제어부분와 관리부분 기능을 구현합니다.

 

 

 

Driver

Libnetwork가 네트워크에 대해 제어하고 관리한다면 네트워크 드라이버는 데이터들을 다룹니다.

Libnetwork의 이식성이 커진데에는 Driver의 큰 영향을 받았습니다.

그 이유는 Driver가 플러그형 인터페이스로 인해 연결될 수 있기 때문입니다.

 

도커에서는 플러그형의 드라이브를 사용하여 네트워크를 구성할 수 있는데요.

그렇다면 어떤 드라이브를 사용해야할지 알아봐야겠죠?

 

드라이버는 이제부터 알아볼 Docker Engine에 포함된 내장 네트워크 드라이버가 있고,

혹은 네트워킹 벤더와 커뮤니티에서 제공하는 플러그인 네트워크 드라이버도 있습니다.

 

 

 

Docker Network Drivers

 

내장 네트워크 드라이버는 bridge, overlay, macvlan 등이 있습니다.

해당 포스팅에서는 container를 실행할 때 default로 설정되는 내용에 대한 큰 그림을 다루고,

다음 포스팅에서 driver에 대해서 알아보겠습니다.

 

 

Docker Container를 아무런 설정없이 실행하면 어떻게 네트워크 구성이 되는지 알아보겠습니다.

기본 네트워크를 알기 위해서 docker0를 알아보도록 할게요.

 

 

✔️ docker0

도커를 처음 설치하게 되면 도커 호스트에 docker0라는 가상 네트워크 인터페이스가 생성됩니다.

아래와 같이 네트워크 인터페이스를 직접 확인할 수 있습니다.

 

# docker host
$ ip link show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc...
    link/ether 02:42:af:f9:eb:4f brd ff:ff:ff:ff:ff:ff

 

docker0는 일반적인 가상 인터페이스가 아니며,

도커가 자체적으로 제공하는 네트워크 드라이버 중 브리지(Bridge)에 해당합니다.

브리지에 대해 간단히 요약하자면 아래와 같습니다.

 

 

Bridge ?

일반적인 네트워킹에서 브리지는 네트워크 세그먼트 간에 트래픽을 전달하는 링크 계층 장치입니다. 

브리지는 하드웨어 장치일 수도 있고 호스트 시스템의 커널 내에서 실행되는 소프트웨어 장치일 수도 있습니다.

*네트워크 세그먼트 : 네트워크 세그먼테이션은 네트워크를 여러 개의 세그먼트나 서브넷으로 나누는 아키텍처 방식으로, 각각이 소규모 네트워크 역할을 함

 

Docker에서 브리지는 컨테이너 간 통신을 할 수 있게 하는 소프트웨어 브리지 입니다. 

동시에, 서로 다른 브리지 네트워크에 연결된 컨테이너와 격리를 하기도 합니다.

 

 

 

자, 다시 docker0에 집중해볼게요.

 

도커 컨테이너를 생성하면 자동으로 이 docker0 브리지를 활용하도록 설정되어 있습니다.

내용을 자세히 보고 싶다면 아래와 같은 명령어를 입력하면 됩니다.

 

$ docker network inspect bridge
[
    {
        "Name": "bridge",
        ...
        "IPAM": {
	        ...
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        ...
        "Options": {
            ...
            "com.docker.network.bridge.name": "docker0",
            ...
        },
        "Labels": {}
    }
]

 

 

docker0 인터페이스는 172.17.0.0/16 서브넷을 갖기 때문에 컨테이너가 생성되면 이 대역 안에서 IP를 할당받게 됩니다. (예: 172.17.0.2, 172.17.0.3)

 

 

✔️ Big Picture

Docker Container를 실행 run 하게 되면, 가장 먼저 Container 기술로 설정된 환경을 격리시킵니다.

이때, Container 기술이라고 하면 지난 포스팅에서 다뤘던 Linux Namespace와 Cgroup을 통한 격리를 의미합니다.

 

 

"docker0" bridge network

 

 

도커 컨테이너는 기본적으로 lo, eth0 인터페이스를 가지는데요.

각 컨테이너의 eth0에는 127.17.x.x/16 대역에 해당하는 IP를 할당 받습니다.

이 대역은 호스트 내부의 사설 IP이므로 외부에서 접속이 불가능합니다.

Container에 할당되는 IP는 컨테이너가 재시작될 때마다 변경될 수 있으니 참고하세요.

그래서 도커 엔진에서는 호스트에 veth 라는 가상 네트워크 인터페이스를 만들고, 각 컨테이너의 eth0와 연결합니다.

 

 

정리하자면, 컨테이너가 처음 실행될 때 도커 엔진은 외부 환경과 통신을 위해 한쌍(2개)의 네트워크 인터페이스를 생성합니다.

 

✔️ 컨테이너 내부 Namespace에 할당되는 eth0 인터페이스

✔️ 호스트 네트워크 브리지 docker0에 바인딩될 vethXXXXXXX 이름을 갖는 veth 가상 네트워크 인터페이스

veth: virtual ethernet

 

컨테이너의 eth0인터페이스와 호스트의 veth 인터페이스는 서로 연결되어 있고,

veth 인터페이스들은 호스트의 docker0 브릿지에 바인딩되어 외부와의 통신을 가능하게 합니다.

이 docker0 bridge는 도커 컨테이너들의 게이트웨이 역할을 하게 됩니다.

 

결국 docker0 브리지는 veth 가상 인터페이스와 호스트의 eth0 인터페이스를 이어주는 중간 다리 역할을 하게 되는 것이죠.

docker0 Bridge에 대한 이해가 됐다면, 다음 포스팅에서 다룰 User-defined Bridge Networks에 대한 이해도 아주 쉬울 거에요.

 

 

 

이렇게 docker network 1 포스팅을 마무리 하고, 

다음 포스팅에서 드라이버에 대해 더 자세히 다루겠습니다.

수정사항이나 잘못된 부분은 댓글 남겨주시면 감사하겠습니다 🙌🏻

 

 

 

참고

https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/

https://docs.docker.com/network/