도커 교과서(엘튼 스톤맨, 심효섭) - 10. 도커 스웜과 쿠버네티스 소개

 

1. 컨테이너 오케스트레이션

 

오케스트레이션의 개념

각 서비스를 실행하는데 1개의 컴퓨터( = 서버, 호스트, 노드)에서 1개의 컨테이너만 실행하지 않는다. 앞서 배운 것처럼 1개의 서버에서 여러 개의 컨테이너를 띄우고, 여러 대의 서버에서 여러 컨테이너를 띄운다. 오케스트레이션 도구는 컨테이너 관리, 로드 밸런싱(요청을 여러 컴퓨터에 분배), 트래픽 분산, 불량 컨테이너 정상화 등의 작업을 담당한다.

 

 

오케스트레이션 도구의 구성

오케스트레이션 도구를 통칭하여 클러스터라고 부른다. 클러스터는 여러 대의 서버, 데이터베이스, 비밀값, 설정값, 공유 스토리지, 네트워크 등으로 구성된다.

 

<그림 12-2> 그리기

 

 

2. 도커 스웜

 

도커 스웜과 쿠버네티스는 컨테이너 오케스트레이션 도구이다. 클라우드 환경에서 기능이나 활성화 정도가 쿠버네티스가 훨씬 우세하지만, 도커를 배우는 입장에서는 도커 스웜을 먼저 배우고 실습한 뒤 나중에 쿠버네티스를 배우는 것도 오케스트레이션 도구를 배우는데 도움이 된다. 도커 스웜이 상대적으로 실행하기가 간편하기도 하다.

 

도커 CLI에 이미 스웜 실행을 위한 명령어가 준비되어있다. 

docker swarm init

 

호스트 컴퓨터가 하나 이상의 네트워크에 접속돼있다면 스웜 통신에 사용할 IP 주소를 선택하라고 오류를 일으킨다고 한다. 나의 경우는 별 문제 없이 실행되었다. 이제 도커 엔진이 스웜 모드로 전환되었다.

이제 스웜에 컴퓨터를 추가할 수 있다. 클러스터에 추가된 컴퓨터를 노드(node)라고 한다. 노드가 되기 위한 조건은 다음과 같다.

- 노드가 스웜과 같은 네트워크상에 있어야한다.

- 스웜의 참가 토큰을 매니저 노드로부터 발급받아야한다.

 

관련 명령어

docker swarm join-token worker  # 워커 노드로 스웜에 참여하기 위한 명령을 출력한다
docker swarm join-token manager # 매니저 노드로 스웜에 참여하기 위한 명령을 출력한다
docker node ls # 스웜에 참여 중인 노드의 목록을 출력한다.

 

 

3. 애플리케이션 실행

 

도커 컴포즈에서 배운 것과 마찬가지로 애플리케이션을 서비스라고 부른다. 다만 클러스터를 이용하면 개별 컨테이너의 관리는 오케스트레이션 도구에 맡긴다는 차이가 있다.

 

docker service create --name timecheck --replicas 1 diamol/ch12-timecheck:1.0
docker service ls

 

명령어를 입력하면 컴포즈때와는 다르게 실행 준비 단계를 거쳐서 verify 후 Service converged라는 메시지가 뜬다.

 

컨테이너도 서비스별로 레플리카라는 용어로 표시된다.

 

컨테이너의 관리는 스웜에게 일임

상기 언급한대로 컨테이너의 관리는 오케스트레이션 도구가 한다. 수많은 노드와 각 노드에 레플리카가 여러 개 배치된 경우 사용자가 직접 각각의 레플리카(컨테이너)에 접근하여 관리하는 것은 어려운 일이기 때문이다. 사용자는 구성 정보와 원하는 상태를 환경설정 값으로 클러스터에게 전달할 뿐, 직접 관리는 스웜에게 일임한다.

 

 

강제로 레플리카를 종료시켜본다.

docker service ps timecheck
docker container ls
docker container rm -f $(docker container ls --last 1 -q)
docker service ps timecheck

 

그럼 알 수 없는 이유(non-zero exit)으로 컨테이너가 종료되었다고 뜨고, 사용자가 레플리카 1개 상태를 유지하라는 명령을 주었으므로 오케스트레이션 도구가 자동으로 컨테이너를 복구하여 Ready 상태의 컨테이너가 생성되었다.

 

생성한 service에 대한 정보도 확인할 수 있다. 아래 명령어를 입력하면 서비스가 생성된 시각, 베이스가 되는 이미지, 레플리카 설정 등을 볼 수 있다.

docker service inspect timecheck(서비스 이름)

 

이 정보는 클러스터의 데이터베이스에서 가져오는 것이다. 이런 정보들은 모든 매니저 노드마다 복제본으로 보관된다. 따라서 도커 컴포즈처럼 개별적으로 환경설정에 대한 YAML 파일이 필요하지 않다.

 

 

서비스 업데이트: 롤링 업데이트

서비스의 버전을 업데이트하면 여러 개의 레플리카가 한개씩 차례대로 업데이트되는 롤링 업데이트 방식으로 업데이트 된다. 쿠버네티스는 블루-그린 업데이트 등 다양한 방식을 지원하지만 도커 스웜은 롤링 업데이트만 지원한다.

 

롤링 업데이트의 주의점

레플리카가 여러 개인 경우 v1.0 -> v2.0으로 업데이트가 된다면 롤링 업데이트 중에는 사용자의 요청이 v1.0의 레플리카에 들어갈 수도 있고, 업데이트된 v2.0의 레플리카에 들어갈 수도 있다. 이러한 이유로 롤링 업데이트 시 사용자 경험이나 데이터 관리를 철저히 해줄 필요가 있다.

 

롤백

스웜의 데이터베이스에는 이전 버전의 서비스 정의내용도 기록된다. 따라서 롤백도 가능하다.

docker service update --rollback timecheck # 이전 버전으로 롤백
docker service ps timecheck # 레플리카 목록 확인
docker service logs --since 25s timecheck # 지난 25초간 모든 레플리카의 로그 출력

 

 

 

4. 네트워크 관리: 오버레이 네트워크

 

스웜에서는 오버레이 네트워크(overlay network)라는 가상 네트워크를 만들어서 모든 노드들을 연결한다. 오버레이 네트워크에 연결된 서비스는 서비스 이름을 도커 DNS에서 조회할 수 있도록 기반으로해서 다른 서비스와 통신한다.

 

스웜은 서비스당 1개의 가상 IP(VIP) 주소만 사용

 

서비스 실행하기

docker service rm timecheck
docker network create --driver overlay iotd-net
docker service create --detach --replicas 3 --network iotd-net --name iotd diamol/ch09-image-of-the-day
docker service create --detach --replicas 2 --network iotd-net --name accesslog diamol/ch09-access-log
docker service ls

 

레플리카 컨테이너에서 터미널로 접속하여 가상 IP 주소를 확인

docker container exec -it $(docker container ls --last 1 -q) sh
nslookup iotd
nslookup accesslog

 

직접 각 컨테이너에 들어가보니 nslookup이 정상 동작은 안했다. 하지만 교재에서는 이런 서비스 종류마다 레플리카(컨테이너)에 상관없이 똑같은 VIP 주소를 갖는다고 설명한다. 이렇게 하면 하나의 서비스에 접근할 때 하나의 IP 주소에만 신경쓰면 되므로 신뢰성을 높이고 부하를 잘 분산할 수 있다. 클라이언트가 IP 주소로 요청을 보내면 운영체제의 네트워크 계층에서 부하를 분산해준다.

 

인그레스 네트워크

위에서 하나의 서비스가 하나의 VIP주소를 갖는 것처럼, 스웜을 구성하는 모든 노드가 서비스가 공개한 포트를 감시하는 방식으로 작동하는 것을 인그레스 네트워크라고 한다.

 

서비스에서 80번 포트를 열어뒀다면, 그와 연결된 모든 노드가 80번 포트를 감시하고 있는다. 만약 노드 안에 컨테이너가 실행 중이지 않는다면 해당 노드는 다른 노드로 요청을 포워딩한다. 그리고 만약 노드 1개에 컨테이너가 5개 있는데 3개가 처리 중이라면, 노드에서 처리 중 상태가 아닌 컨테이너로 요청을 고르게 분배한다.

 

다만 로컬 인그레스 네트워크로의 접속은 윈도우 컨테이너에서는 불가하다. 리눅스 컨테이너에서만 가능하다.