수동 배포의 문제점들

컨테이너가 충돌하는 이슈로 프로그램이 crashed될 수 있다. 이런 경우에 새 컨테이너를 다시 실행해야 하는데, 큰 애플리케이션에서 이런 작업은 상당히 불편하다. 그리고 트래픽이 많은 경우 하나의 기능을 수행하는 컨테이너를 하나만 쓰는 것이 아니라 컨테이너의 수를 조정하고 컨테이너들에 트래픽을 분산시킬 필요가 있다.

What is Kubernetes?

위에서 언급한 문제들은 aws의 auto-scaling, load-balancer등을 이용해 자동으로 처리할 수 있었다. 이러한 설정들을 적용하면 aws내에서는 문제를 해결할 수 있으나, 다른 클라우드 서비스에서는 작동하지 않을 수 있다. 예컨대 Google Cloud같은 곳에서는 또 다른 설정을 적용해야 할 수 있다.

물론 특정 클라우드 서비스만 사용하겠다면 큰 문제가 없을 수 있지만, 클라우드 플랫폼에 종속되지 않고 자동 배포를 도와줄 오픈소스 시스템이 있다. 이게 쿠버네티스이다.

쿠버네티스도 자동 배포, 스케일링, 로드 밸런싱, 관리에 필요한 기능들이 존재한다.

아까 클라우드 플랫폼과 쿠버네티스를 비교했지만 쿠버네티스는 클라우드 플랫폼들의 대체재가 아니다. 자동 배포와 관리에 필요한 기능들과 개념들이 모여있는 오픈 소스 프로그램일 뿐이지, 클라우드 프로바이더는 따로 제공되어야 한다. 다만 aws든 다른 클라우드 플랫폼이든, 온프레미스 환경이든 쿠버네티스라는 공통적 시스템을 이용하여 관리할 수 있다는 데 의의가 있다.

쿠버네티스는 도커의 대체재도 아니다. 쿠버네티스를 사용해 도커를 관리하고 자동 배포할 수 있는 것이다. 그래서 요약하자면 쿠버네티스는 여러 머신에서 사용할 수 있는 docker-compose같은 개념이라고 볼 수 있는 것이다.

Kubernetes 아키텍처

포드(Pod)

쿠버네티스는 여러 가지 개념과 구성 요소로 되어있는데, 우선 포드라는 게 있다. 포드는 하나 또는 그 이상의 애플리케이션 컨테이너들의 그룹을 나타내는 쿠버네티스의 추상적 개념이다. 쿠버네티스 세계에서는 이 포드가 최소 단위가 된다. 포드는 컨테이너의 자원들을 공유할 수 있는데,

• 공유 스토리지(ex: 볼륨)

• 네트워킹(ex: 클러스터 IP 주소)

• 컨테이너가 동작하는 방식에 대한 정보(ex: 컨테이너 이미지 버전, 사용할 특정 포트) 와 같은 자원들을 공유할 수 있다고 한다.

워커 노드(Workder Node)

포드에서 컨테이너 그룹을 나타냈다. 그럼 이 컨테이너들은 어디에서 실제로 실행되는가? 이에 대한 대답이 워커 노드라고 할 수 있다. 이렇게 보면 워커 노드는 일종의 인스턴스와 같은 개념이라고 할 수 있다.

프록시(Proxy)

또 다른 구성 요소로 프록시가 있다. 이는 워커 노드의 포드 네트워크 트래픽의 제어를 설정하는 도구이다. 그러니까, 프록시는 포드가 인터넷에 연결할 수 있는지의 여부와 외부에서 컨테이너를 어떻게 접근할 수 있는지와 같은 세팅을 제어할 수 있게 해준다고 보면 된다.

마스터 노드(Master Node)

쿠버네티스는 트래픽에 따라 컨테이너의 수를 조정한다. 트래픽에 따라 포드와 컨테이너를 만들고 실행 가능한 워커 노드에서 실행시키는 작업을 해야한다. 반대로 필요하지 않은 경우에는 줄이고 교체하는 작업도 필요하다.

이런 작업은 마스터 노드에 의해 이루어진다. 정확히는 마스터 노드가 호출하는 컨트롤 플레인(Control Plane)에 일어난다.

이런 작업을 마스터 노드와 컨트롤 플레인이 수행한다면 개발자는 뭘 하는가?

개발자는 원하는 종료 상태를 설정하면 쿠버네티스가 이를 고려하여 관리한다.

여기서 컨트롤 플레인이 실제로 무엇이냐 하면 마스터 노드에서 실행하는 다양한 서비스와 도구 모음이라고 할 수 있다.

클러스터(Cluster)

이렇게 마스터 노드와 컨트롤 플레인, 워커 노드들과 포드들이 구성된 단위를 클러스터라고 한다. AWS에서 설명하기론 컨테이너화된 애플리케이션을 실행하는 컴퓨팅 노드 또는 작업자 머신이라고 표현하고 있다.

위는 AWS에서 클러스터 연결에 대해 표현하고 있는 그림이다.

Node 좀 더 살펴보기