컨테이너 오케스트레이션

서버 관리

개발자가 직접 관리 → 문서화를 통한 관리(업데이트 누락 가능성) → 서버 관리 도구를 통한 관리(관리 도구에 대한 학습 필요) → 가상 머신을 이용한 관리(느림, 벤덩 종석적) → 도커

도커의 등장

도커 관련하여 참고

컨테이너 특징

• 생성 쉽고 효율적
• 배포와 롤백이 간단
• 애플리케이션을 동일한 방식으로 관리
• 로컬과 클라우드까지 동일한 환경을 구축
• 특정 벤더에 종속적이지 않음

만약 컨테이너의 수가 10000개라면?

개별적으로 관리하는 것은 불가능하다.

도커 그 이후

만약 컨테이너의 수가 10000개라면?

about 배포

(하나의 서버에 하나의 컨테이너가 있는 상황으로 생각됨)

• 개별적인 container 관리 어렵다.
• 여유가 있는 서버를 찾기 위한 모니터링 도구 필요하다.
• 개별적으로 롤백하기 어렵다.

about 서비스 검색(service discovery)

• 마이크로 서비스 환경에서 서비스 추가마다 로드밸런서를 두기 힘들다.

service discovery란?

• IP가 동적으로 변경되는 환경(auto-scaling, 컨터이너 기반 배포 환경)에서 새로 추가된 인스턴스를 알 수 있게 해주는 기능
• 참고

about 서비스 노출(Gateway)

• 도메인과 서버 연결을 위해 매번 nginx 설정 수정하기 귀찮다.

about 서비스 이상, 부하 모니터링

• 알아서 서비스가 잘 관리 되었으면 좋겠다.
  (ex. 죽은거는 알아서 다시 띄우기, 부하에 따른 컨테이너 추가)

컨테이너 오케스트레이션

복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구(서버 관리자 대신 일해라)

컨테이너 오케스트레이션 역할

CLUSTER

• 중앙제어
  • 서버가 많아지면 이를 모아 클러스터 단위로 관리한다.
  • 해당 클러스터를 master-node가 관리하게 된다.
• 네트워킹
  • 클러스터 내에 노드들 끼리 통신 가능해야 한다.
• 노드 스케일
  • 얼마나 많은 노드들이 있던 잘 작동해야한다.

STATE

• 상태 관리
  • 원하는 설정 대로 컨테이너들이 관리되어야 한다.
  • ex) 컨테이너 3개 → 언제나 이 상태를 컨테이너 오케스트레이션이 맞추어 줘야 한다.

SCHEDULING

• 배포 관리
  • 알아서 여유 있는 서버에 컨테이너를 띄워야 한다.
  • 필요에 따라서 서버를 알아서 추가로 띄운다.

ROLLOUT ROLLBACK

• 중앙에서 버전 관리

SERVICE DISCOVERY

• IP 주소(인스턴스)가 추가 또는 변경됨에 따라 알아서 설정 변경 및 프로세스 재시작

VOLUME

• 스토리지 연결을 설정으로 관리

EBS VOLUME 이란?

• EBS로 생성한 디스크 하나하나 저장단위
• ex) 윈도우 → C 드라이브, D 드라이브가 각각 EBS Volume이다.
• 참고

왜 쿠버네티스인가?

쿠버네티스

컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼

왜 쿠버네티스인가?

• 오픈소스
• 엄청난 인기
• 무한한 확장성
• 사실상의 표준