[kubernetes] 컨테이너 오케스트레이션? ~ 왜 쿠버네티스인가

728x90

강의 보면서 정리하기

서버를 관리한다는 것

: 서버의 상태를 관리하는 노력이 필요

문서화 -> 설정관리도구(CHEF, puppet, ANSIBLE) -> 가상머신(서버 하나에 가상머신을 여러개 올림) -> 컨테이너(대표: Docker)모든 실행환경을 컨테이너로 바꿈

컨테이너의 특징 -> 전체 서버의 환경을 가져옴

1. 가상머신과 비교하여 컨테이너 생성이 쉽고 효율적

2. 컨테이너 이미지를 이용한 배포와 롤백이 간단한

3. 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리

4. 개발, 테스팅, 운영환경은 물론 로컬PC와 클라우드 까지 동일한 환경을 구축

5. 특정 클라우드 벤더에 종속적이지 않음

Developer -> Build -> Ship -> Run

일단 Docker(클러스터) image로 만들기만 하면 관리가 매우 쉬워짐

여기서의 문제가

Docker의 사용량이 증가함에 따라 컨테이너 관리가 쉽지않음

그래서 Run 다음에 다음 단계가 생김

해당 도커에 대한 서버 모니터링이필요하고,

버전관리를 용이하게 만들고, 롤아웃/롤백을 용이하게 시킴

* Service Discovery 서비스 검색이란?

Proxy -> WEB서버 를 보고 있을 때, WEB 서버가 하나 더 생긴다면

LoadBalancer를 중간에 설치하여 proxy 를 두개로 늘일 수 있다

그러면 proxy -> loadbalancer -> webServer 의 순서가 된다

이 또한 자동화가 되지않아 불편함

* Service 노출(Gateway) 하는 방법?

* 서비스의 이상과 부하에 대한 관리?

서버가 죽었을 때에 대한 자동화 관리의 부재에서의 자동화 방법이 없음

그래서 생긴 기술이 바로 Container Orchestration

복잡한 컨테이너 환경을 효과적으로 관리함 -> 서버 관리를 이 오케스트레이션이 하게 된다

이 오케스트레이션의 역할

CLUSTER -> 중앙제어(master-node) 마스터서버를 두고 알아서 각 클러스트들에게 명령을 내림 , 네트워크 통신에 문제 없도록 설정, 노드 스케일 관리
STATE -> 상태관리, 만약 서버 세대 띄웠다가 하나가 죽으면 알아서 세개로 만들어줌
SCHEDULING -> 배포관리
ROLLOUT/ROLLBACK -> 배포버전관리
SERVICE DISCOVERY -> 서비스 등록 및 조회 (프로그램이 알아서 프록시 설정 및 프로세스 재시작)
VOLUME -> NFS, AWS EBS, GCE PD 등의 스토리지 연결을 추상적으로 관리 가능

도커의 경우에는 docker SWARM이라는 오케스트레이션이 있다

개념이 좀 잡혔다ㅠㅠ 감사합니다

728x90

개발을개발로할태니