도커 & 쿠버네티스의 네트워크 모델
도커의 네트워크 모델
도커 기초 개념
+ 호스트 머신
- 컨테이너를 실행/운영하는 머신
- 1개의 호스트 머신 위에서 여러 개의 컨테이너들이 실행됨
+ 컨테이너
- 리눅스의 cgroups, namespaces 기술을 기반으로 만들어진 CPU/ File System/ Network이 격리된 환경
- 독자적인 CPU/ File System/ Network 환경을 갖는다는 측면에서 VM과 유사, 하지만 본질은 그냥 평범한 리눅스 프로세스
- 하이퍼바이저 같은 중간 레이어 없이 호스트 머신의 커널 바로 위에서 실행되기 때문에 실행 성능 저하가 전혀 없음
- 하이퍼바이저 & VM 모델에 비해 리소스 오버헤드가 없음
도커가 해결해야 하는 네트워크 문제
1개의 호스트 머신 위에서 여러 개의 컨테이너들이 동작하는 상황에서, 도커는 네트워크 측면에서 다음 문제들을 해결해야 함
1. 호스트 머신 내부에 존재하는 컨테이너들 사이의 네트워크 연결을 보장해야 함
2. 호스트 머신 외부와 컨테이너 사이의 네트워크 연결을 보장해야 함
도커는 네트워크 문제 해결을 위해 veth (Virtual ETHernet) 기술을 이용
+ veth는 서로 연결된 2개의 가상 네트워크 디바이스 (http://lwn.net/Articles/232688/ 참조)
+ 반드시 2개가 동시에 생성됨 (created in pairs)
- veth 생성 명령: $ ip link add veth0 type veth peer name veth1
- 어느 한쪽 디바이스에 패킷을 보내면, 다른쪽 디바이스로 패킷이 전달됨 (반대 방향도 마찬가지)
+ 네트워크 Namespace 장벽 사이의 통신을 위해 사용 (http://www.opencloudblog.com/?p=66 참조)
도커 네트워크 환경의 구성 과정
① 도커 데몬이 실행되면 호스트 머신에 docker0 (가상 네트워크 브릿지)가 생성됨
② 도커 컨테이너를 실행하면
해당 컨테이너를 위한 veth (가상 네트워크 장치) pair 가 생성됨
③ 생성된 veth pair의 한쪽 끝은 컨테이너 안으로 격리되어 eth0로 이름이 바뀜 (컨테이너 안에서만 보여짐)
④ 다른쪽 끝은 호스트 머신에 vethXXXX 이름으로 존재하며 docker0 브릿지에 연결됨
⑤ 같은 호스트 머신에서 실행되는 컨테이너들은 docker0 브릿지를 매개로 서로 연결 가능
도커 네트워크 모델
+ 호스트 머신 밖으로 서비스를 제공해야 하는 컨테이너는 호스트 머신의 네트워크 포트를 점유할 수 있음 (도커 run -p 옵션)
+ 호스트 머신의 네트워크 포트를 맵핑하는 컨테이너가 여러 개일 경우,
어플리케이션별 네트워크 포트 관리 필요 -->
개인 개발이 아닌 팀 단위 개발에서는 실질적으로 불가능 -->
쿠버네티스가 우아하게 해결!
컨테이너와 호스트 머신 사이의 포트 맵핑
쿠버네티스(이후 k8s)의 네트워크 모델
k8s 기초 개념
+ Master
- k8s 클러스터를 관리하는 머신
+ Node
- k8s 클러스터를 구성하는 머신
- 도커 컨테이너 실행을 담당
- 얼마 전까지 'Minion'이라고 불렸음
+ Pod
- 서로 관련된 컨테이너들을 묶어 놓은 집합
- k8s의 배포/운영/관리의 단위
+ Service
- 같은 일을 하는 Pod 들의 집합
- k8s 클러스터 내에서 고유한/고정된 IP 주소 부여
- Service에 소속된 멤버 pod들에 대해 로드밸런싱 기능 수행
k8s가 해결해야 하는 네트워크 문제
여러 노드로 구성된 클러스터를 운영하는 k8s는 네트워크 측면에서 다음 문제들을 해결해야 함
1. 긴밀한 관계가 있는 컨테이너와 컨테이너 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)
2. Pod 와 Pod 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)
3. 서버 역할을 수행하는 Pod가 크래쉬로 인해 다시 시작되더라도 클라이언트는 네트워크 설정 변경 없이 원래 서버에 접근할 수 있어야 함 (Service 네트워크 모델)
Pod 네트워크 모델
+ Pod는 k8s 운영/관리의 기본 단위
+ k8s 클러스터 안에서 실행되는 모든 컨테이너들은 Pod 단위로 관리됨
- 1개의 Pod에 여러 개의 컨테이너가 존재할 수 있음
- k8s는 Pod마다 고유한 IP주소를 부여
k8s 클러스터의 Pod 네트워크 모델
+ Pod를 실행하면 Pod 안에 ‘pause’라는 이름의 컨테이너가 생성/실행됨
+ pause 컨테이너는 Pod의 네트워크 환경 (IP주소, 라우팅 테이블, …)을 만드는 역할만 수행함 (다른 일은 전혀 하지 않음)
+ Pod 안의 다른 컨테이너들은 pause 컨테이너가 만든 네트워크 환경을 공유
Pod 네트워크 상세 (with pause 컨테이너)
Service 네트워크 모델
+ Pod는 크래쉬될 수 있음
+ Pod가 크래쉬되면 k8s가 Pod를 다시 살림 (k8s Replication Controller의 역할), 하지만 이 과정에서 IP 주소가 새로 할당 됨
+ 클라이언트 측의 네트워크 설정을 변경하지 않고 Pod가 제공하는 서비스에 안정적으로 접근할 수 있는 방법이 필요 ==> Service!
+ Service는 다수의 멤버 end-point들로 구성
+ Service는 멤버 end-point들에 대한 로드밸런싱 기능을 수행
k8s Service의 네트워크 모델
(이상)
