컨테이너 오케스트레이션
-
컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는것
-
MSA는 세부화된 기능들이 작은 서비스 단위로 분리되어 구축되는데, 동시에 수백, 수천개의 컨테이너를 배포해야하는 상황은 곤란하며 다음 4가지의 이슈에 대한 해답을 찾아야한다
-
배포 관리 : 어떤 컨테이너를 어느 호스트에 배치하여 구동할 것인가?
-
제어 및 모니터링 : 구동 중인 각 컨테이너들의 상태를 어떻게 추적하고 관리할 것인가?
-
스케일링 : 수시로 변화하는 운영 상황과 사용량 규모에 어떻게 대응할 것인가?
-
네트워킹 : 이렇게 운영되는 컨테이너들을 어떻게 상호 연결할 것인가?
-
-
컨테이너 오케스트레이션 툴로는 쿠버네티스, Docker Swarm, Apache Mesos가 대표적이다
쿠버네티스의 기능
-
서비스 디스커버리와 로드 밸런싱 : DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출
-
스토리지 오케스트레이션 : 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재
-
자동화된 롤아웃과 롤백 : 현재 상태를 원하는 상태로 설정한 속도에 따라 변경
-
자동화된 빈 패킹 : 컨테이너가 필요로 하는 CPU 와 메모리를 제공
-
자동화된 복구 : 실패한 컨테이너를 다시 시작, 컨테이너를 교체
-
시크릿과 구성 관리 : 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장 및 관리
Desired State
-
원하는 상태(Desired State) 는, 관리자가 원하는 환경을 의미하며, 몇개의 웹서버를 띄울지, 몇번 포트로 서비스할지 등을 의미
-
원하는 상태를 만들기 위해 사용하는 메커니즘이 Controller Loop이며 다음 사진과 같이 동작한다
-
Observe : Object들이 원하는 상태가 무엇인지 감시/확인
-
Diff : Object들의 현재 상태와 원하는 상태를 비교해 차이가 있는지 확인
-
Act : 현재 상태를 원하는 상태로 만들어줌
-
이러한 세가지 단계를 반복하며 지속적으로 원하는 상태를 유지하게 된다
helm
-
helm은 쿠버네티스 패키지 매니저
-
helm을 이용하여 원하는 소프트웨어(패키지)를 쿠버네티스에 쉽게 설치할 수 있다
-
helm chart의 구조는 크게 values.yaml , templates/ 디렉토리로 구성
-
values.yaml : 사용자가 원하는 값들을 설정하는 파일
-
templates/ : 설치할 리소스 파일들이 존재하는 디렉토리. 쿠버네티스 리소스가 YAML 파일 형태로 들어가있고, 각 파일들의 설정값은 비워져있고 values.yaml의 설정값으로 채워진다
service
-
Pod에 경우 ip가 랜덤하게 지정되고, 리스타트 때마다 변하기 때문에 고정된 엔드포인트로 호출이 어렵다 -
또한 여러
Pod에 같은 애플리케이션을 운용하는 경우,Pod간의 로드 밸런싱을 지원해줘야 하는데 서비스가 이러한 역할을 한다 -
지정된 ip로 생성이 가능
-
여러
Pod을 묶어서 로드 밸런싱이 가능 -
고유한 DNS 이름을 가질 수 있음
- targetPort :Pod어플리케이션 쪽에서 열려있는 포트를 의미
- port : 서비스 쪽에서Pod를 향해 열려있는 포트를 의미
replicas
-
몇개의
Pod을 사용하려고 하는지 정하는것 -
해당 resource를 감시하는 컨트롤러가
Pod에 변화가 생겼는지를 감지하고,Pod이 죽었을때 다시 복구
