쿠버네티스를 처음 공부할 때 가장 어려웠던 점은 바로 익숙하지 않은 '새로운 용어'들이었습니다.
그래서 쿠버네티스란 무엇인지, 그리고 자주 등장하는 핵심 용어들을 정리해보았습니다.
컨테이너 오케스트레이션의 세계로 첫걸음을 내딛는 분들께 도움이 되길 바랍니다.
쿠버네티스란
쿠버네티스는 컨테이너 오케스트레이션 플랫폼입니다.
컨테이너는 가상머신과 달리 호스트 OS를 공유하는 구조로 인해, 가상머신보다 가볍고 빠르며, 동시에 가상머신처럼 실행 환경의 독립성도 제공합니다. 이러한 특성 덕분에 가벼움과 이식성을 갖춘 컨테이너는 점점 더 많이 사용되고 있습니다.
하지만 수백에서 수천 개에 이르는 컨테이너를 운영자가 수동으로 관리하는 데에는 한계가 있습니다. 이에 따라, 컨테이너의 배포, 확장, 스케줄링, 네트워크설정 등을 자동화할 수 있는 컨테이너 오케스트레이션 도구의 필요성이 대두되었습니다.
구글은 자사 내부에서 이러한 도구를 개발하여 사용해 왔고, 이후 이를 오픈소스로 공개한 것이 바로 쿠버네티스입니다.
쿠버네티스의 장점 3가지
- 실행환경 고립화: 모든 프로세스는 컨테이너환경에서 실행되기 때문에 각 서버 실행 환경에 대해 고민할 필요가 없습니다.
- 리소스관리: 쿠버네티스는 여러 서버를 하나로 묶은 클러스터 시스템으로 각 서버의 리소스 하나씩 관리할 필요 없이 클러스터 단위에서 전반적인 리소스 관리를 할 수 있습니다.
- 자가치유: 쿠버네티스 내부적으로 바라는 상태를 정의하면, 컨테이너의 문제가 생겨 죽더라도, 시스템에서 이를 인지하고 컨테이너를 재실행합니다.
쿠버네티스는 OS이다.
쿠버네티스는 보통 OS라고 불립니다.
OS란 CPU, 메모리, 디스크, 네트워크 카드와 같은 부품으로 구성된 컴퓨터 자원을 제어할수 있도록 지원하는 인터페이스를 제공하는 것입니다. 일반 PC를 사용할 때 우리는 직접 물리 장치를 제어하지 않고 윈도우나 리눅스 OS를 통해 컴퓨터를 직접 제어하고 프로그램을 실행합니다.
쿠버네티스도 마찬가지로, 여러대의 물리적인 컴퓨터의 집합인 클러스터를 제어할 때 kubectl을 통해 클러스터를 관리할 수 있기 때문에 쿠버네티스는 마치 OS와 같습니다.
애완동물과 가축
쿠버네티스에서 생성되는 컨테이너는 애완동물보다 가축에 비유합니다.
애완동물은 사랑스러운 이름을 짓고, 옷을 입히는 등 세심한 관리가 필요하지만, 가축은 떼로 방목해서 낙오된 개체는 죽을수도 있지만 한두 마리 죽는 것에 슬퍼하지 않습니다.
마찬가지로 각 노드의 서버마다 특별한 이름을 부여하지 않고 워커서버로 동일하게 부릅니다. 또한 가축과 마찬가지로 한두 개의 서버가 망가져도 문제가 생기지 않고, 쿠버네티스 플랫폼이 자동으로 새로운 서버로 자리를 대체합니다.
바라는 상태(Desired State)
바라는 상태는 에어컨 온도 시스템을 떠올리면 이해하기 쉽습니다.
에어컨에는 희망온도와 현재온도가 있으며, 에어컨은 희망온도에 도달하기 위해 온도를 조절하는 것처럼 쿠버네티스에도 사용자의 바라는 상태에 도달하기 위해 작업을 수행합니다.
예를 들어 현재 컨테이너의 개수가 3개일 때, 바라는 컨테이너 개수는 5개이면 쿠버네티스에서 2개를 자동으로 생성하여 개수가 5개가 되도록 유지합니다.
컨트롤러
사용자의 요청에 따라 바라는 상태를 유지하기 위해 지속적으로 모니터링하고, 변경하라는 요청을 하는 대상이 컨트롤러입니다. 컨트롤러는 control-loop라는 루프를 돌며, 지속적으로 바라는 상태와 현재 상태를 모니터링합니다.
쿠버네티스 리소스
쿠버네티스에서 생성되는 것은 모두 리소스라고 지칭합니다. 리소스의 종류에는 Pod, ReplicaSet, Deployment 등이 있으며, 리소스의 최소단위는 Pod입니다.
구체적으로 Pod는 하나이상의 컨테이너를 가지는 쿠버네티스의 최소단위입니다.
선언형 커맨드와 명령형 커맨드
선언형 커맨드(Declarative Command)는 사용자가 시스템의 상태를 직접 조작하지 않고, 원하는 최종 상태를 문서 형태로 정의하여 시스템에 전달하는 방식을 의미합니다. 시스템은 이 정의된 상태에 도달하기 위해 필요한 작업을 자동으로 수행합니다.
이와 반대되는 개념은 명령형 커맨드(Imperative Command)입니다.
명령형 방식에서는 사용자가 시스템에 수행할 작업을 하나하나 직접 지시합니다.
예를 들어, SQL 쿼리는 명령형 커맨드의 대표적인 예입니다. 사용자가 데이터베이스에 특정 쿼리를 보내면, 그에 따른 결과가 반환됩니다. 마치 함수처럼 입력에 따라 출력이 결정되는 방식입니다.
명령형 커맨드는 빠르게 실행할 수 있다는 장점이 있지만, 재사용이 어렵고, 수행한 작업에 대한 이력이 남지 않는다는 단점이 있습니다.
(참고) 쿠버네티스는 기본적으로 선언형 커맨드를 지향합니다.
네임스페이스
쿠버네티스는 클러스터를 논리적으로 분리하는 네임스페이스라는 개념이 존재합니다. 하나의 클러스터 위에서 여러 개의 네임스페이스단위로 나누어 리소스를 관리할 수있습니다. 예를들어 prod, test, deploy등으로 네임스페이스를 나누어 관리할수 있습니다.
각 네임스페이스마다 서로 다른 권한설정, 네트워크설정을 수행할 수 있습니다.
또한 리소스를 구분할 때 해당 리소스가 클러스터 레벨의 리소스인지, 네임스페이스 레벨의 리소스인지 파악해야 리소스 관리에 유용합니다.
예를 들어 Pod, Deployment, Service는 네임스페이스 레벨 리소스이지만, Node, PersistentVolume, StorageClass는 클러스터 레벨 리소스입니다.
레이블&셀렉터(Label&Selector)
쿠버네티스에서는 특정 리소스에 명령을 전달하거나 조회하고 싶을 때 해당 리소스에 레이블을 추가하는 방식을 사용합니다. 추후 다른 리소스가 해당 리소스를 찾고 싶으면, 해당 레이블을 찾는 셀렉터를 추가하여 특정 레이블을 가진 리소스를 찾아가도록 설정할 수 있습니다.
서비스 디스커버리(?)
파드는 동적으로 생성되고, 삭제되어 IP가 변경됩니다. 따라서 고정된 IP로 통신하기 어려워 서비스라는 리소스를 동해 여러 파드를 하나의 네트워크 엔드포인트로 묶어 통신합니다.
서비스에 접근하기 위해서는 IP를 알고 있어야 하는데, 쿠버네티스에서는 서비스의 IP를 찾을 필요 없이 도메인 주소를 기반으로 서비스에 접근할 수 있도록 DNS기반 서비스 디스커버리를 지원합니다.
설정관리
쿠버네티스에서는 Secret, ConfigMap이라는 리소스를 이용하여, 컨테이너를 실행할 때 필요한 설정값과 민감정보들을 플랫폼레벨에서 관리합니다. 이러한 기능 덕분에 사용자는 서버마다 필요한 설정값을 관리하거나, 서버 간 설정값 동기화 문제를 해결할 필요가 없습니다.
참고자료