왜 Docker Driver + Minikube에선 안되는 게 많을까

📍 Epilogue

CSP의 K8s 서비스를 사용하기 전에 Minikube를 사용하여 프로젝트를 진행하였다.
노드에 올려놓은 파드에 대해서 여러 가지 타입으로 서비스를 배포하고자 하였다.
그런데 NodePort, LoadBalancer 타입은 Minikube에서 Docker Driver 특성상 완벽하게 동작하지 않는 것이었다.
- NodePort → Container IP로 접속 불가능
- LoadBalancer → External IP 제공 불가능
  - MetalLB addon으로 External IP 제공 가능하지만 접속 불가능
  - minikube service 명령어로 tunneling을 이용해서 접속 가능
그래서 여기서 의문점 ❗️
- Docker Driver의 특성이 뭐길래?

일단 소프트웨어 드라이버에 대하여 알아보았다.

▪ Software Driver

커널 모드에서 실행되는 코드를 통해서만 접근 가능한 핵심 OS 데이터 구조에 접근할 수 있는 도구가 필요한 경우
위 도구를 두 가지 요소로 분할하여 수행 가능
- User mode에서 실행되고 사용자 인터페이스를 제공 → 애플리케이션
- Kernel mode서 실행되며 핵심 OS 데이터에 접근 → 소프트웨어 드라이버
소프트웨어 드라이버는 항상 커널 모드로 실행
커널 모드에서만 사용할 수 있는 보호된 데이터에 접근하기 위한 주된 목적

⇒ 여기까지로 도커 드라이버는 커널 단의 여러 모듈들에 접근하여 컨테이너의 생성 / 관리를 도와준다고 생각할 수 있다.

▪︎ Minikube Service

Accessing apps

How to access applications running within minikube

minikube.sigs.k8s.io

Minikube 공식 문서에서 minikube service를 지원하는 이유를 찾아보았다.

Using minikube service with tunnel

The network is limited if using the Docker driver on Darwin, Windows, or WSL, and the Node IP is not reachable directly.

Running minikube on Linux with the Docker driver will result in no tunnel being created.

…

💡 Darwin : Open-source UNIX OS by Apple
WSL : Window Subsystem for Linux

Darwin, Windows 또는 WSL 기반의 도커 드라이버를 사용한다면 네트워크에 제한이 생기며 Node IP는 직접적으로 도달하지 않는다고 한다.

⇒ 공식문서에서 위 OS에 대한 NodePort, LoadBalancer Type 서비스는 직접적으로 외부에서 접근이 불가능하여 minikube service를 제공하는 것으로 보아 관련 OS에서의 특징이 존재하다고 생각하였다.

그럼 내가 Mac OS를 쓰는 입장이므로 Mac OS에서 도커가 어떠한 형태로 작동하고 컨테이너를 생성하는지 알아보자

▪︎ Docker in Mac OS

Mac OS에서는 도커를 사용하기 위해선 Hypervisor Type 2를 사용한다.
Hypervisor Type 2란 Host OS 위에 VM을 올려서 VM 안에 Guest OS를 설치하는 방식이다.
- 가상화에 대한 더 자세한 이야기는 추후..

Mac OS에서의 Hypervisor인 Xhyve는 HyperKit를 사용하여 Host내 VM을 생성한다.

💡 Xhyve : Bhyve의 Mac OS용 버전
Bhyve : Hypervisor의 Type-2

💡 HyperKit : 애플리케이션에 하이퍼바이저 기능을 포함하기 위한 툴킷

GitHub - moby/hyperkit: A toolkit for embedding hypervisor capabilities in your application

A toolkit for embedding hypervisor capabilities in your application - GitHub - moby/hyperkit: A toolkit for embedding hypervisor capabilities in your application

github.com

생성한 VM의 Guest OS에는 Linux Kit을 사용하여 만든 경량화 Linux OS를 올린다.

💡 Linux Kit : 컨테이너용으로 구축된 미니멀한 Linux OS 이미지를 만들기 위한 프레임워크

그 후 도커를 올려 컨테이너를 생성 및 관리를 수행한다.
$ docker info → Guest OS가 Linux OS인 것을 확인

여기까지 Mac OS 상에서 도커가 어떻게 설치되고 동작하는지에 대한 구조를 확인하였다.
다음으로 위 같은 구조를 가지고선 왜 직접 컨테이너 IP로 접근을 할 수 없는지 네트워크 부분에서 살짝 분석해보고자 한다.

▪︎ Docker Network in Mac OS

일단 정답은 다음과 같다.
Mac OS에서 도커는 L4(포트 바인딩)를 통한 컨테이너 연결을 지원하지만 L3(IP 주소간)은 지원하지 않기 때문이다.
왜 L3(IP 주소 간)은 지원하지 않는지 살펴보자 !

도커는 여러 가지 네트워크 모드가 존재한다.
- bridge mode (default)
- host mode
- none mode

만약 네트워크 모드를 변경하고 싶다면 --net=[NETWORK-TYPE] 옵션 추가

bridge mode (default)
- docker0이라는 bridge가 자동으로 생성된다.
- 컨테이너는 각자 독립적인 네트워크 네임스페이스 영역을 가진다.
- 먼저 생성된 컨테이너 내부 네트워크 인터페이스와 veth(virtual ethernet)랑 바인딩한다.
- 바인딩된 veth는 docker0 bridge랑 다시 한번 바인딩을 통해 호스트의 네트워크 인터페이스 eth0과 통신할 수 있게 된다.
host mode
- 컨테이너만의 독립적인 네트워크 인터페이스를 가지지 않고 호스트와 동일한 네트워크를 함께 사용한다.
none
- 아무것도 없는 격리된 상태의 네트워크
- 네트워크 인터페이스 없음
그런데 호스트에 docker0에 대한 네트워크 인터페이스가 존재하지 않는 것을 확인할 수 있다.

이유를 생각해보면 Mac OS에서는 Linux VM 위에 Docker가 있기 때문에 그에 대한 bridge는 Linux VM안에 있다고 생각할 수 있다.

위와 같이 호스트에서 bridge 네트워크 인터페이스가 존재하지 않기 때문에 컨테이너에 IP로는 접근을 못하고 포트 포워딩을 통한 터널링으로 접근을 할 수 있다.
- Localhost(127.0.0.1:65180) → Tunneling → Docker container(192.168.49.2:32517)