CKA 준비과정 - Networking (3) / 컨테이너 네트워크

도커는 컨테이너 실행 시 네트워크 옵션을 선택할 수 있다.

none : 네트워크 연결 없이 실행

host : host의 네트워크에 연결한다. 호스트의 80포트를 점유하고 사용하면, 다른 프로세스는 80포트를 사용할 수 없다.

bridge : 컨테이너 private network를 생성하고, 해당 네트워크 내 사설 IP를 할당받아 사용한다.

 

 

도커 설치시, 기본적으로 기본 bridge가 생성된다.

도커에서는 bridge로 보이지만, 호스트에서는 docker0 란 이름으로 확인된다.

 

bridge는 도커 내에서 스위치의 역할을 담당한다. 따라서 컨테이너가 생성되면 컨테이너와 연결된다.

브릿지와 컨테이너를 연결하는 방법은 앞서 리눅스 ns 간 연결하는 방법와 동일하다.

 

도커는 컨테이너를 생성하면 브릿지와 연결하는 통로를 생성한다. 호스트에서 ip link 명령어를 통해 확인해보면, docker0 에 연결된 인터페이스(veth~~) 가 확인된다.

컨테이너 id를 ns 옵션값으로 주고 addr 명령어를 통해 주소값을 확인할 수도 있다.

 

docker 컨테이너를 생성할 때마다 동일한 방식으로 bridge에 자동으로 컨테이너를 연결한다.

따라서 호스트 내 컨테이너들은 별도 설정 없이 서로 통신이 가능하다.

 

하지만 외부에서 컨테이너를 접근해야 하는 경우에는, 호스트의 특정 포트를 컨테이너의 포트로 매핑하는 포트포워딩 기능을 설정해주어야 한다.

docker run -p 8080:80 nginx => nginx 컨테이너를 80포트로 매핑하여 실행

위 명령어를 실행하면 외부에서 호스트 ip의 80포트로 접근할 때 nginx 컨테이너로 접속하게 된다.

 

이와 같이, Linux Namespace의 네트워크와 docker의 네트워크 설정은 매우 흡사한 구조임을 알 수 있다.

이러한 과정을 CNI로 규정하여, 후에 개발된 쿠버네티스도 CNI를 따르기 때문에 학습했던 네트워크 설정을 그대로 따라간다.

 

CNI(Container Networking Interface)

Linux Namespace 부터 쿠버네티스에 이르기까지, 모든 네트워크 구성 설정은 CNI 규정을 따라 만들어졌기 때문에 로직이 매우 비슷하다.

 

bridge, vlan과 같은 기본 솔루션은 Plugin 이라고 부르며

네트워크 설정을 돕는 서드 파티 프로그램들도 있다.

 

Cluster Networking

위와 같이 노드가 있고 각 파드들이 통신해야 하는 상황일 때, 어떻게 통신해야 하는지를 알아야 한다.

각 파드들의 통신은 쿠버네티스가 자체적으로 기능을 지원하지 않기 때문에, 외부 서드파티 솔루션을 활용해야 한다.

쿠버네티스에서 요구하는 네트워킹 모델에는 조건이 존재한다.

- 모든 파드는 IP주소를 가져야 한다.

- 모든 파드는 같은 노드 내 파드들과 통신이 가능해야 한다

- 모든 파드는 NAT 없이 다른 노드의 파드들과 통신이 가능해야 한다.

 

즉, 모든 파드들은 서로 통신이 가능해야 한다.

강의에서는 솔루션 없이 이전에 학습했던 내용을 토대로 직접 설정을 진행한다. (솔루션을 일반적으로 사용하는 듯함)

 

 

이전에 학습했던 것과 동일하게 진행한다. 

가상 케이블 생성 => ip link add

컨테이너 및 브릿지 연결 => ip link set

ip 주소 할당, default gateway에 route 설정한다.

위와 같은 작업은 반복적으로 이루어지기에, 보통 쉘 파일을 작성하여 자동화하는 편이 좋다.

작업을 모두 완료하면 노드 내 파드끼리는 통신이 가능하다. 다른 노드의 파드와 통신하기 위해서는 추가로 설정이 필요하다.

 

각 노드마다 일일히 라우팅을 모두 해줘서 통신을 하도록 설정할 수 있지만, 조금만 네트워크의 규모가 커지면 관리가 정말 어려워진다. 따라서 라우터를 따로 두고, 모든 노드가 라우터를 기본 게이트웨이로 사용하도록 설정하는 쪽이 더 편하다.

별도의 가상 네트워크를 생성하고 각 노드의 라우팅, 게이트웨이 정보를 한 곳으로 묶어 통신이 가능하도록 만든다.

 

대규모 네트워크에서는 분당 수천 개의 파드가 생성된다. net-script.sh 와 같은 파일을 수동으로 일일히 실행시킬 수는 없다. 스크립트를 자동으로 실행하는 방법이 필요한데, 여기서 활용하는 것이 CNI 이다.

각 노드에서 컨테이너를 생성하는 역할은 kubelet 이 담당한다. 컨테이너가 생성될 때마다 kubelet이 CNI configuration 을 확인하는데, 이 때 CNI conf 파일의 경로는 --cni-conf-dir=/etc/cni/net.d 이다.

net.d 파일에서 --cni-bin-dir=/etc/cni/bin 옵션에 설정된 경로에서 net-script.sh 파일을 찾아 자동으로 실행한다.

 

 

Container Network Interface In Kubernetes

앞선 강의들에서 CNI 가 왜 정의되었는지와 지원되는 플러그인에 대해 확인했다. 

쿠버네티스에서 CNI가 어떻게 구성되는지 알아본다.

 

CNI는 클러스터 내 각 노드의 kubelet.service 에서 구성된다.

kubelet.service 파일을 조회해보면 --network-plugin 이라는 부분이 있다. 해당 부분이 cni로 설정되어 있음을 확인할 수 있다. 아래 하위 옵션들도 확인할 수 있다.

kubelet 프로세스에서도 cni 옵션을 확인할 수 있다.

 

 

CNI weave

weaveworks 는 외부 솔루션으로, 이전에 학습했던 쿠버네티스내 노드와 파드들의 통신 설정을 도와주는 프로그램이다.

학습했던 방법은 네트워크의 규모가 커지면 관리에 한계가 있다.(라우팅 테이블 크기 등) 따라서 외부 솔루션을 일반적으로 사용하게 된다.

weaveworks는 트래픽을 전달하는 위탁업체의 역할이라고 이해할 수 있다. 

각 노드에는 weaveworks service 라는 에이전트가 설치된다. 이 에이전트가 설치된 파드끼리는 서로 통신을 하며 위치 정보를 교환한다. 이 정보를 토대로, 파드에서 다른 파드로 통신할 때 weaveworks 가 중간에서 라우팅 역할을 한다.

패킷 전달 과정은 다음과 같다

pod - weaveworks service - weaveworks - weaveworks service - pod

 

 

IPAM (CNI)

IPAM(IP Address Management) 에서는 IP 주소 관리 방법에 대해 알아본다.

가상 네트워크에서 서브넷 대역 할당, 파드에 IP 할당을 자동으로 하는 메커니즘을 확인해본다.

 

이전에 net-script.sh 파일을 통해 네임스페이스에 IP를 할당하는 부분 (link set) 이 있었다. 중복된 IP를 할당하면 안되기 때문에 관리가 필요하다.

첫째로 가용한 IP 주소 리스트를 따로 저장하여 net-script.sh 가 실행 시 리스트를 참조하여 할당하는 방식을 사용할 수 있다.  하지만 CNI는 플러그인을 내장하여 스크립트 없이 IP를 할당할 수 있다.

CNI는 DHCP와 host-local 두 가지 방법으로 IP를 찾아 할당한다. 위 이미지에서는 host-local 방식을 사용했다. 

스크립트를 구동할 필요는 없지만, 사용자가 플러그인 호출까지는 진행해주어야 한다.

 

따라서 플러그인 호출을 하지 않도록 동적 스크립트를 생성할 수도 있다. CNI 구성 파일에는 IPAM 필드가 존재한다. 여기서 사용될 플러그인의 유형과 서브넷, 라우트도 지정할 수 있다.

 

외부 솔루션인 weave를 통해서도 IP 할당을 할 수 있다.

10.32.0.0/12 를 디폴트 값으로 예로 들었을 때, 총 IP 개수는 1,048,574 개의 IP를 할당할 수 있다. 이 중 특정 범위를 지정하여 범위 내에서 IP를 할당하게 된다.