[도커/쿠버네티스] 3장 도커 스웜

3.1 도커 스웜을 사용하는 이유

실제 도커를 운영환경에 적용한다면 하나의 호스트머신에서 도커엔진을 구동하기에는 CPU나 메모리, 디스크 용량이 부족할 수 있다.

-> 여러대의 서버를 클러스터로 만들어 자원을 병렬로 확장하여 해결

-> 오픈소스: 도커 스웜, 스웜모드

 

3.2 스웜 클래식과 도커 스웜 모드

: 여러대의 도커 서버를 하나의 클러스터로 만들어 컨테이너 생성하는 기능을 제공

-> 유동적 서버 확장, 컨테이너 관리 용이

 

도커스웜 종류

1. 스웜 클래식 (컨테이너로서의 스웜)

- 여러대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근점 제공

- 도커 명령어, 도커 API로 클러스터 서버 제어 관리

2. 스웜 모드

- 마이크로서비스 아키텍처 컨테이너를 다루기 위한 클러스링 기능에 초점

- 같은 컨테이너를 동시에 여러개 생성 

- 컨테이너로의 연결을 분산하는 로드밸런싱 지원

-> 스웜모드가 클래식보다 안정성, 확장성 측면에서 더 뛰어나서 많이 사용함 (스웤 클래식은 레거시)

 

여러개의 도커 서버를 하나의 클러스터로 구성하기 위해 필요한 것

- 분산 코디네이터:  각종 정보를 저장하고 동기화 ex) etcd, zookeeper, consul

- 클러스터 내의 서버를 관리하고 제어하는 매니저

- 각 서버를 제어하는 에이전트(클러스터 툴)

-> 스웜모드는 도커엔진 자체에 내장돼있음

 

 

3.3 스웜 모드

스웜모드 사용법

- 적어도 3대 이상의 도커 서버를 사용해야만 기능 테스트 가능

 

3.3.1 도커 스웜 모드의 구조

스웜 모드 구성

1. 매니저 노드: 워커 노드를 관리하기 위한 도커 서버

- 1개 이상 있어야함

- 매니저 역할 노드, 리더 역할 노드로 구분됨

2. 워커 노드: 실제로 컨테이너가 생성되고 관리되는 도커 서버

- 없을 수도 있음 (매니저 노드가 워커 노드의 역할도 포함하기 때문에)

-> But 워커 노드와 매니저 노드를 구분해서 사용하는 것을 권장

 

분산 클러스터에서 홀수개로 노드를 구성하는 이유

: 네트워크 파티셔닝, 데이터 일관성을 위한 투표 등 (합의 알고리즘 Ratt Consensus)

- 스웜 모드는 매니저 노드의 절반 이상에 장애가 생겨 정상적으로 작동하지 못할 경우 장애가 생긴 매니저 노드가 복구될 때까지 클러스터의 운영을 중단함.

-> 스웜 매니저는 가능한 홀수개로 구성하는것을 권장

 

 

3.3.2 도커 스웜 모드 클러스터 구축

3.3.3 스웜 모드 서비스

3.3.3.1 스웜 모드 서비스 개념

도커 명령어의 제어단위는 컨테이너

스웜 모드의 제어 단위는 서비스

 

서비스 (Service): 같은 이미지에서 생성된 컨테이너의 집합

-> 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이 수행됨

 

태스크 (Task): 서비스 내의 컨테이너

 

스웜 스케줄러: 서비스 정의에 따라 컨테이너를 할당할 적합한 노드를 선정하고, 해당 노드에 컨테이너를 분산해서 할당

-> 이처럼 함계 생성된 컨테이너 -> 레플리카 (replica)

 

서비스에 설정된 레플리카의 수만큼 컨테이너가 스웜 클러스터 내에 존재해야 함

 

롤링 업데이트(Rolling Update): 여러개의 서버, 컨테이너 등으로 구성된 클러스터의 설정이나 데이터 등을 변경하기 위해 하나씩 재시작하는 것

-> 하나를 업데이트해도 다른 서버나 컨테이너는 작동중이기 때문에 지속적인 서비스 가능

 

3.3.3.2 서비스 생성

3.3.3.3 스웜 모드의 서비스 장애 복구

3.3.3.4 서비스 롤링 업데이트

3.3.3.5 서비스 컨테이너에 설정 정보 전달하기: config, secret

3.3.3.6 도커 스웜 네트워크

3.3.3.7 서비스 디스커버리

3.3.3.8 스웜 모드 볼륨

 

3.3.4 도커 스웜 모드 노드 다루기

3.3.4.1 노드 AVAILABILITY 변경하기

3.3.4.2 노드 라벨 추가