쿠버네티스 입문 - 09 - 클러스터 네트워킹

도커 컨테이너의 네트워킹

일반적인 도커 컨테이너 네트워크는 브리지 타입 네트워크 구조로 되어있다.

브리지 타입 네트워크 구조는 아래와같다.

1. 호스트는 호스트 네트워크 네임스페이스를 가진다. 그리고 여기에 docker0 라는 브리지를 만든다.
2. 컨테이너는 컨테이너 네트워크 네임스페이스를 가진다. 그리고 여기에 컨테이너를 만든다.
3. 컨테이너 네트워크 네임스페이스에는 가상 이더넷(베스)을 가지고 있다.
4. 도커는 docker0에 베스들을 연결하여 통신한다.

네트워크 네임스페이스는 서로 연결되기 전까지 독립적으로 동작한다.

네트워크 네임스페이스는 별도의 ARP, 라우팅, iptable 을 가진다.

 

 

 

도커 컨테이너의 네트워크 타입

• 브리지 :  호스트에 브리지를 만들고 컨테이너와 호스트는 가상 이더넷(베스)을 이용해 연결한다.
• 오버레이 : 호스트들 각각에 있는 컨테이너 네트워크를 오버레이 네트워크로 연결한다. (도커 스웜이 기본으로 사용하는 타입이다.)
• 맥브이렌 : 하나의 이더넷 장치에 여러개의 가상 MAC 주소를 할당하는 기술
• 호스트 : 컨테이너 네트워크 네임스페이스를 사용하지 않고 호스트 네트워크 네임스페이스를 직접 사용한다.
• 링크 : 컨테이너 네트워크 네임스페이스를 사용하지 않고 이미 생성되어 있는 네트워크 네임스페이스를 사용한다. 

 

 

 

보그의 네트워킹

쿠버네티스의 전신인 보그에서는 파드마다 IP 를 할당하지 않고 노드의 포트를 다르게 해서 파드로 접근했다.

하지만 파드의 포트를 관리하는 것은 너무 힘든일이고 쿠버네티스의 개발에와서는 파드에 IP 를 할당하게 됬다.

 

 

 

쿠버네티스 파드의 네트워크

쿠버네티스는 도커와 달리 기본 도커 네트워크 타입이 링크 타입이다.

쿠버네티스는 도커와 달리 파드 단위로 컨테이너를 관리한다.

파드 하나에 속한 컨테이너는 veth0 를 공유한다.

파드 하나에 속한 컨테이너는 같은 IP를 가진다. (Pause 컨테이너 네트워크 네임스페이스의 IP)

파드 안 컨테이너의 Network 모드를 보면 bridge, host 가 아닌 container 다.

즉 컨테이너가 pause 컨테이너의 네트워크를 공유한다는 의다.

파드 안 컨테이너 사이의 구분은 포트로 한다.

 

 

 

다른 노드에 있는 파드와 통신

파드는 각각 고유한 IP 를 갖게 되므로 노드들 사이에 연관 관계가 없다면 호스트는 다른데 IP는 같은 파드가 생기게 된다.

 

 

 

쿠버네티스 서비스 네트워킹

쿠버네티스 컴포넌트 간의 통신은 단순히 파드들만의 통신이 아니다. 서비스와이 통신이 대부분이다.

쿠버네티스의 CIDR 은 크게 두개로 나뉘어 지정된다. (CIDR : Classless Inter Domain Routing, 클래스가 없는 도메인 사이의 라우팅 기법)

1. 파드용 CIDR  (—cluster-cidr 옵션)
2. 서비스용 CIDR (—service-cluster-ip-range 옵션)

옵션이 다른만큼 서로 다른 IP 대역을 사용한다.

 

 

 

kube-proxy

서비스용 IP 연결은 NAT 테이블을 이용해 파드의 IP 로 연결해주는데 이 기능을 kube-proxy 가 해준다.

NAT 영역 설정도 kube-proxy 가한다.

kube-proxy 는 kube-apiserver 를 지켜보다 파드의 변경사항이 발생하면 서비스에 해당하는 NAT 규칙을 업데이트한다.

이러한 연유로 모든 클러스터 노드는 kube-proxy 가 설치되어있다.

 

 

 

쿠버네티스 네트워크 플러그인

플라넬 : 쿠버네티스 위에 레이어 3 네트워크를 구성하는 가장 쉬운 방법, 파드 IP 를 관리하는데 별동의 데이터베이스를 필요로하지 않는다.

칼리코 : 쿠버네티스 클러스터 네트워크를 직접 구성할 때 가장 기본으로 선택하는 플러그인, 사실상 최선의 선택

실리엄 : 최근 각광받는 플러그인. 커널 수준에서 네트워크 경로를 조정하므로 (다 하위 레이어인 네트워크 카드까지 가지도 않는다.) 같은 노드 안의 컨테이너라면 통신 성능이 좋아진다.