쿠버네티스 구조 살펴보기

 2013년도에 도커가 발표되면서 컨테이너 기술은 예~전에 사용하던 사용자 격리 수준의 LXC 방식, 배포에 더욱 신경을 쓴 Docker Container 방식, 오케스트레이션(컨테이너 관리)을 위한 Docker Swarm, Kubernetes로 진화하고 있다. 컨테이너 오케스트레이션이란 컨테이너를 관리하는 방법이라고 정리할 수 있다.

 물론 도커로도 컨테이너를 관리할 수 있다. 하지만 컨테이너가 만 개가 되면? 다른 서버에서 사용한 컨테이너와 통신하고 싶다면? 인프라의 규모가 커지면서 이러한 고민은 필연적인 숙명이 되고 결과적으로 나타난 것이 컨테이너 오케스트레이션이다. (갓) 구글에서 발표한 오케스트레이션 기술인 Kubernetes는 업계 표준이나 다름없어졌으며 많은 곳에서 사용되고 있다. 공부하다 보니 구조에 대해 더욱 알아야겠다는 생각이 들었고, 이번 포스팅은 쿠버네티스의 구조에 대해 살펴본다.

 쿠버네티스는 1대의 Master + N대의 Worker로 구성되어 있다. 먼저 마스터부터 살펴보자.

1. 마스터

 마스터는 Kube-API-Server, etcd, Kube-Scheduler, Kube-Controller-Manager로 구성되어 있다. 마스터는 클러스터의 상태를 관리하는 역할을 맡고 있다.

- Kube-API-Server

 Kubernetes Cluster의 게이트웨이 역할을 한다. 3가지 핵심 기능을 가지고 있다.

(1) API management

(2) Request processing

(3) Internal control loops

 kubernetes res api를 제공하며 kubectl로 들어오는 명령과 call에 의한 요청을 받아 worker들에게 전달해준다.

 - ETCD

 key-value 형태로 메타데이터를 저장한다.

- Kube-Scheduler 

 노드가 할당되지 않은 새로 생성 된 포드를 감시하고 어디에 배치할지 책임진다. 스케줄링에 다양한 기법들이 있다.

- Kube Controller Manager

(1) Node Controller : Node가 다운 되면 알려주고 조취를 취해줌

(2) Replication Controller : Replicaset에 정의 된 pod의 개수를 유지함

(3) Endpoints Controller : Endpoint를 채우고 Service와 Pod를 연결해줌

(4) Service Account & Token Controller : 새로운 Namespace를 위한 default account와 API access token을 생성해줌

2. Worker

- Kublet

 master의 API Server와 통신하며 전달받은 명령을 처리하고 현 상태를 전달해준다. Node 내의 pod-container를 관리해준다.

- Kube Proxy

 사용자에게 요청이 왔을 때 알맞은 pod를 프록시해준다. loadbalancing을 해주기도 한다.

- Container Runtime

 container 환경을 구성해준다.