# 3 kubernetes 동작 원리

쿠버네티스는 애플리케이션을 실행하려면 애플리케이션을 하나 이상의 컨테이너 이미지로 패키징하고, 해당 이미지를 registry로 푸시한 다음 kube-apiserver에 애플리케이션 description을 게시해야 한다.

 

이 description에는 컨테이너 이미지, 애플리케인션의 구성요소가 포함된 이미지, 해당 구성요소가 서로 통신하는 방법, 동일 서버에 함께 배치돼야 하는 구성 요소와 같은 정보가 포함된다.

 

Description으로 컨테이너를 실행하는 방법 이해

API 서버가 애플리케이션 디스크립션을  처리할 때 스케줄러는 각 컨테이너에 필요한 리소스를 계산하고 해당 시점에 각 노드에 할당되지 않은 리소스를 기반으로 사용 가능한 워커 노드에 지정된 컨테이너를 할당한다.

이후 해당 노드의 kubelet은 컨테이너 런타임에 필요한 컨테이너 이미지를 가져와 컨테이너를 실행하도록 지시한다.

 

실행된 컨테이너의 유지

애플리케이션이 실행되면 쿠버네티스는 애플리케이션의 배포 상태가 사용자가 제공한 디스크립션과 일치하는지 지속적으로 확인한다.

예를 들어 항상 다섯 개의 웹 서버 인스턴스를 실행하도록 지정하면 쿠버네티스는 항상 정확히 다섯 개의 인스턴스를 계속 실행한다.

 

프로세스가 중단되거나, 응답이 중지될 때와 같이 인스턴스가 제대로 작동하지 않으면 쿠버네티스가 자동으로 시작한다.

 

마찬가지로 워커 노드 전체가 종료되거나 액세스 할 수 없게 되면 쿠버네티스는 이 노드에서 실행 중인 모든 컨테이너의 노드를 새로 스케줄링하고, 새로 선택한 노드에서 실행한다.

 

Replica 스케일링

애플리케이션이 실행되는 동안 복제본 수를 늘릴지 줄일지 결정할 수 있으며, 쿠버네티스는 추가 복제본을 기동 하거나 초과 복제본을 정지시킬 것이다.

 

최적의 복제본 수를 결정하는 작업을 쿠버네티스에 맡길 수도 있다. cpu 부하, 메모리 사용량, 초당 요청수, 애플리케이션이 노출하는 다른 메트릭과 같은 실시간 메트릭을 기반으로 복제본 수를 자동으로 조정할 수 있다.

 

이동한 애플리케이션에 접근하기

쿠버네티스는 컨테이너를 클러스터 안에서 이동시킬 수도 있다.

이는 실행 중인 노드가 정지됐거나 다른 컨테이너를 위한 공간을 만들려고 노드에서 제거됐기 때문에 발생할 수 있다.

 

컨테이너가 외부 클라이언트나 클러스터에서 지속적으로 이동한다면 컨테이너를 어떻게 적절하게 사용할 수 있을까?

그리고 이 컨테이너가 복제돼 전체 클러스터에 분산되면 클라이언트가 서비스를 제공하는 컨테이너에 어떻게 접근할 수 있을까?

 

클라이언트가 특정 서비스를 제공하는 컨테이너를 쉽게 찾을 수 있도록 쿠버네티스에게 동일한 서비스를 제공하는 컨테이너를 알려주면 쿠버네티스는 하나의 고정 ip주소로 모든 컨테이너를 노출하고 해당 주소를 클러스터에서 실행 중인 모든 애플리케이션에 노출한다. 이는 환경변수로 제공되지만 클라이언트는 오래전부터 사용된 DNS로 서비스 IP를 조회할 수도 있다. 

 

kube-proxy는 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 load-balancing 되도록 한다. 서비스의 IP는 일정하게 유지되므로 클라이언트는 컨테이너가 클러스터 내에서 이동하더라도 컨테이너에 항상 연결할 수 있다.
(컨테이너는 다른 노드로 옮겨지면 재시작하여 새IP를 할당받지만, 서비스는 여전히 동일한 IP를 가진다.)