

쿠버네티스는 간단히 말하면, 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고 확장 가능한 오픈소스 플랫폼이다.
일단, 쿠버네티스가 뭐고 왜 나타나게 되었는지 이해하기 위해 애플리케이션 배포 환경의 변화부터 살펴보자.
쿠버네티스는 도커와 같은 컨테이너 런타임을 통해 컨테이너를 ‘오케스트레이션’하는 플랫폼이다.
컨테이너 오케스트레이션
컨테이너에 필요한 설정과 관리, 적절한 노드로 배치, 모니터링 등을 제공하는 것을 의미한다.
쿠버네티스는 물리머신에서 사람이 해왔던 업무 대부분을 해결한다. 사람이 거의 개입하지 않고도 배포부터 운영관리의 다양한 부분을 자동화할 수 있다. 구글의 사례를 통해 어떻게 대규모 서버에 배포와 관리를 할 수 있는지, 쿠버네티스 탄생의 역사를 한번 살펴보자

구글은 이미 오래전에 매주 20억 개가 넘는 컨테이너를 생성하고 운영하였다. 이 정도 규모에 사람을 마냥 늘려서 대응하는 것은 매우 비효율적이다.
그래서 구글은 ‘borg’라는 사내 플랫폼을 이용해 컨테이너를 관리하게 된다. 2014년에는 ‘borg의 오픈소스 버전인’ Kubernetes를 만들어 CNCF(Cloud Native Computing Foundation)에 기증하게 된다.
이게 바로 우리가 쓰고있는 쿠버네티스의 시작인 셈이다.
20억 개의 컨테이너를 관리하는 상상을 해보자!
이 많은 수의 컨테이너들을 실행하게 될 수많은 서버가 세계 데이터 센터에 나뉘어 있고, 컨테이너마다의 필요와 요구 사항을 판단하여 배치하여야 한다.
구름 너머 저 어딘가에 있겠지…
Kubernetes는 사용자의 명세를 기반으로 컨테이너의 스펙에 적합한 노드를 자동으로 선정한다. 전 세계 서버들을 컨테이너의 스펙과 비교하여 필터링하고 추려진 노드들을 스코어링 하여 가장 최적인 노드로 컨테이너를 배치한다.
개발자는 노드가 어떤 서버에 배치되었는지 몰라도 된다. Kubernetes가 노드 선정과 배포를 더 간단하게 할 수 있었던 것은 컨테이너가 실행환경을 포함하고 있고 서버에 따라 영향을 바디 않기 때문이다.
컨테이너가 없었다면 구글은 정말로 전세계 데이터센터에 수십억 개의 애플리케이션을 설치할 인력을 고민했을지도 모른다….😵💫
쿠버네티스는 명세를 기반으로 다양한 컨트롤러가 협력하는 방식으로 동작한다.
여러 종류의 빌트인 컨트롤러들이 있고 필요하면 커스텀 컨트롤러를 구현할 수도 있다. 각 컨트롤러는 각자 처리하는 명세를 정의하고 그에 맞춰 구현된다. 컨트롤러는 컨테이너를 배치하고, 상태를 모니터링 하고, 상태가 달라지면 명세에 정의된 스펙대로 맞추려는 노력도 한다.
👀 참조 문서
[K8s] 쿠버네티스란 무엇인가?
쿠버네티스 알아보기 1편: 쿠버네티스와 컨테이너, 도커에 대한 기본 개념 | 인사이트리포트 | 삼성SDS
쿠버네티스 알아보기 2편: 쿠버네티스를 만나는 여러 가지 방법 | 인사이트리포트 | 삼성SDS
쿠버네티스 알아보기 3편: 쿠버네티스를 이루고 있는 여러 가지 구성 요소 | 인사이트리포트 | 삼성SDS
서비스 개발자를 위한 컨테이너 뽀개기 (a.k.a 컨테이너 인터널)
[컨테이너 인터널 #1] 컨테이너 톺아보기
[컨테이너 인터널 #2] 컨테이너 파일시스템