컨테이너 오케스트레이션의 등장 배경
서버를 관리하기 위한 노력
서버의 상태를 관리하기 위한 다양한 노력이 있었다.
서버가 갑자기 죽을 수도 있는데 이런걸 어떻게 하면 잘 관리할 수 있을까?
1. 문서화
- 업데이트가 안될수도 있다.
- 환경이 바뀌면 잘 안될수도 있다
2. 서버를 관리하는 도구
- CHEF, PUPPET, ANSIBLE
- 설정 관리도구 자체를 배워아함
- 서버를 복잡하게 관리하다보면 도구 자체의 난이도도 높아짐
3. 가상머신
- 가상머신을 띄우고 프로그램을 설치하면 된다
- 충돌날 위험도 적다
- 근데 느림
- 벤더 dependency 발생
도커의 등장
- 모든 실행환경을 컨테이너로 바꿈
- 도커만 설치되어있으면 어디서든 동작
- 사용법도 쉬움
- 효율적으로 동작
컨테이너 특징
- 가상머신과 비교하여 생성이 쉽고 효율적
- 컨테이너 이미지를 이용한 배포와 롤백이 간단
- 언어나 프레임워크 상관없이 애플리케이션을 동일한 방식으로 관리
- 개발, 테스팅, 운영 환경은 물론 로컬 PC와 클라우드까지 동일한 환경을 구축
- 특정 클라우드 벤더에 종속적이지 않음
새로운 문제점
그런데 컨테이너가 많아지니까 관리가 좀 여전히 어려움이 있다
예시
- 일부 container를 v1에서 v2로 변경해야하는 경우
일일이 접속해서 하기에 번거로움 - 이렇게 배포한 v2가 문제가 발생하면 v1으로 rollback 해야함
이것도 일일이 접속하기가 번거로움
중앙에서 모두 관리하고 싶다는 요구가 생김
서비스 디스커버리
서비스간의 서로의 위치를 알아야 하는 경우가 생긴다
proxy server가 애플리케이션으로 라우팅을 해주고 있는데 애플리케이션이 추가된다면?
MSA로 인해 내부 서비스간의 통신이 많아지는데 ip가 변경될때마다 일일이 반영해주기 어려움
서비스 노출
public 영역에 proxy server를 두고 들어오는 host에 따라 private 영역에 있는 컨테이너에 연결한다.
자동으로 설정이 안될까?
서비스 이상, 부하 모니터링
일부 컨테이너가 죽으면 어떻게 하는가?
일일이 접속해서 컨테이너 로그 보고 다시 동작시키는 등 해야한다
특정 서버의 부하가 늘어나 응답속도가 느려지는 경우 갯수를 늘려야한다
자동화 되거나 쉬운 방법이 필요하다
컨테이너 오케스트레이션
복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구이다
서버 관리자가 하는 일들을 대신하는 프로그램
Cluster
node를 하나하나 관리하는 것이 아니라 cluster화 해서 추상화해서 관리한다.
node에 일일이 접속하기 어려우니, master server에 명령어를 내리면 알아서 node에 명령어를 보내게 된다.
cluster 내부의 node 끼리는 네트워크 통신이 잘 되어야 한다.
node의 갯수가 많아져도 잘 동작해야 한다.
State
상태관리를 한다.
컨테이너가 3개인 상태를 설정하면 자동으로 띄워준다.
혹여나 1개가 문제가 생긴다면 그걸 없애고 새로운 컨테이너 띄운다.
Scheduling
배포 관리.
자동으로 여러 서버 중에서 자원이 여유가 되는 적절한 서버에서 새로운 애플리케이션이 배포될 수 있게 한다.
서버가 부족한 경우 서버를 더 띄우고 거기에 컨테이너를 띄우기도 한다.
Rollout Rollback
중앙에서 배포 버전을 관리하면 컨테이너들에 반영된다.
Service Discovery
서비스 등록 및 조회
서비스가 뜨면 중앙에 등록을 하게 되면, ip가 변경될때 마다 일일이 직접 수정하는 것이 아닌 중앙에 등록된 정보만 이용하면 된다.
Volume
볼륨 스토리지
스토리지를 연결해야 하는 경우 설정으로 관리할 수 있게 한다.
참조
