좌충우돌 kubernetes 익히기(2)
놓쳐서는 안 될 필수 사전 지식!
kubernetes 개념을 익히기 전에 반드시 알아두어야 하는 기술 스택이 있습니다. 바로 docker입니다! kubernetes는 docker container를 기본적으로 사용하고 있습니다. docker와 같은 containerization 기술이 없었다면 당연히 오늘날 kubernetes도 존재하지 않았을 것입니다.
혹시 docker를 처음 접하거나 아직 익숙하지 않다고 생각된다면 kubernetes를 익히기 전에 docker를 충분히 경험해 보시길 바랍니다. 인터넷상에 정말 많은 docker tutorial들과 관련 글들이 있는데 ‘왜 docker를 사용해야 하는가’부터 시작해도 좋을 듯합니다.
그 외에도 필수는 아니지만 linux bash 기본 command와 vim, curl, ssh 등의 tool들을 다룰 줄 안다면, kubernetes를 익히고 사용하는데 많은 도움이 됩니다. GUI 보다 우선 CLI 같은 터미널 환경을 의지적으로 사용하려는 노력도 필요하죠. kubernetes와 docker같은 세상은 GUI보다 CLI가 기본이라는 점을 염두에 둡시다!
▶︎ 필수지식1 : kubernetes 이름의 어원
그리스어인 kubernetes는 한국어로 직역하면 배의 ‘조타수’라는 뜻입니다. ‘왜 조타수라는 이름을 지었을까?’를 생각해 보면 kubernetes는 컨테이너를 체계적으로 관리 운영하는 환경을 제공하기 때문이 아닐까 싶습니다. 컨테이너는 원래 배(컨테이너선) 위에 얹고, 그 배는 조타수가 조정하고 관리합니다.
kubernetes용 package manager인 helm이라는 툴이 있는데, helm은 배의 ‘키’를 뜻합니다. 이처럼 kubernetes나 docker 관련된 것들의 이름이 모두 배, 컨테이너와 연관성이 있다는 것을 알아두면 학습에 소소한 재미를 더할 수 있습니다.
kubernetes라는 이름 자체가 어떤 의미인지 가늠했다면 앞으로 k8s라는 약어로 사용하겠습니다. 이는 kubernetes의 첫 철자인 k와 마지막 철자인 s 사이에 8개의 철자 (ubernete)가 들어 있어서 관례적으로 축약 표시합니다. (비슷한 예: i18n = internationalization)
다음으로 구체적인 k8s 개념에 대해 알아보겠습니다.
▶︎ 필수지식2 : k8s Concepts
k8s 공식 홈페이지 문서를 보면 Concepts 라는 메뉴가 별도로 존재합니다. 이곳에 k8s 관련 개념 정리가 매우 잘 되어 있어, 이를 천천히 읽어본다면 k8s를 이해하는데 많은 도움이 될 것입니다.
k8s Objects
java 같은 프로그래밍 언어에만 object가 있는게 아니라, k8s에도 object가 있습니다. k8s 공식 문서에는 다음처럼 object를 정의합니다.
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
한마디로 k8s 클러스터의 현재 상태 혹은 클러스터에 배포된 서비스의 현재 상태를 보관하고 표현하는 추상적인 개체를 가리킵니다. 한편 클러스터(cluster)란 1개 이상의 vm을 모아 가용성 높게 특정 서비스를 제공하는 vm 집합체라 보면 되겠습니다. 이 표현에서 가장 중요한 단어를 하나 뽑으라면, 바로 ‘state’ (상태)입니다.
상태… 상태… 상태… state… state… state… (왜 중요할까? 그 이유는 잠시 뒤에…)
k8s object의 구체적인 예로 Pod, Service, Volume, Namespace 등이 있습니다. 여기서 object는 상태를 나타냅니다. 결국 pod도, service도, volume도, namespace도 클러스터와 관련한 상태를 내포하고 있는 것입니다. 그렇다면 도대체 어떤 상태를 object가 내포하고 있을까요? pod를 예를 들면 해당 app의 docker image, tag, container의 초기 실행 명령, container에 전달할 환경 변수, container에 마운트할 스토리지 볼륨, container 현재 실행 상황 등 이 모든 것을 상태라고 보면 됩니다.
k8s에서 클러스터 상태를 얘기할 때, 크게 두가지로 이야기합니다. 하나는 사용자가 원하는 상태(the desired state), 나머지 하나는 현재 상태(current state)입니다. 명령 절차적인(imperative) 방식의 서비스 배포에서는 주로 vm의 현재 상태에 초점을 맞춰 작업이 이루어집니다. 그러나 k8s에 들어오면 사용자가 원하는, 사용자가 요구한 상태(the desired state)라는 개념이 두드러지게 강조됩니다. 방금 전에 언급한 k8s object의 한 예인 pod에도 사용자가 요구한 상태와 현재 상태가 공존한다고 보시면 됩니다.
뒤에서도 다시 설명하겠지만 결국 k8s의 주 역할은 한마디로 다음과 같습니다.
“현재 클러스터 상태(current state)가 사용자가 원하는 클러스터 상태(the desired state)에 도달할 수 있도록 끊임없이 k8s object들을 모니터링하고 조작하고 조정(control)한다.”
집에 있는 보일러 수온 조절기를 생각해보겠습니다. 현재 수온이 45°C(current state)고 사용자가 50 °C(the desired state)로 설정해 놓으면 수온 조절기(controller)는 자동적으로 수십초 안에 현재 수온을 50°C에 도달하도록 합니다. 이렇듯 k8s에서는 클러스터 상태(state)가 그만큼 중요합니다. 이 상태(state)를 k8s object가 내포하고 있습니다.
구체적인 k8s objects에 대해서는 다음 글에서 자세히 다뤄보겠습니다. 이제는 objects 다음으로 익혀야 하는 개념인 controllers에 대해 알아보겠습니다.
k8s Controllers
k8s 공식 문서를 살펴보면 controller를 다음과 같이 정의하고 있습니다.
Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features.
Controller는 위에서 설명드렸던 object들을 기초해서 추가적인 기능과 편의성을 제공하는 개념입니다. 한마디로 얘기하면 pod 같은 기본 objects를 특별한 기능으로 다룹니다. 단순 object만 가지고는 사용 가치가 떨어질텐데 controller라는 실용적인 기능을 object에 더해서 보다 편리하게 k8s를 사용할 수 있도록 도와줍니다.
controller도 좀 특별한 k8s object로 인식할 수 있고, 일반 object보다 기능적인 면이 더해진 특별한 목적성을 갖는 object라고 볼 수 있습니다. 또는 클러스터의 현재 상태(current state)를 사용자가 희망하는 상태(the desired state)로 조절해 주는 온도 조절기 같은 것이라고 보기도 합니다. 실제 k8s를 사용할 때 pod 같은 k8s object 보다 deployment 같은 k8s controller를 훨씬 더 많이 사용하게 됩니다.
k8s controller의 구체적인 예로 ReplicaSet, Deployment, StatefulSet, DaemonSet, Job 등이 있습니다. 재밌는 것은 Deployment는 내부적으로 ReplicaSet을 다루게 되고, ReplicaSet은 내부적으로 Pod를 다루게 됩니다. object와 contoller는 서로 밀접한 연관이 있고 경우에 따라서는 명확한 구분 없이 사용될 수도 있습니다. 중요한 것은 object와 controller를 구분하기보다는 각 구체적인 object와 controller들이 어떤 역할을 하고 어떤 기능성을 가지고 있어서 어느 때 어떤 용도로 사용되는지 파악해야 하는 것입니다. 이러한 파악이 제대로 되어야 실제 프로젝트에서 k8s를 효과적으로 사용할 수 있습니다.
마지막으로, k8s control plane에 대해 알아보겠습니다.
k8s Control Plane
혹시 control plane 혹은 data plane 이란 용어를 들어보셨나요? 원래 network 분야에서 먼저 쓰였던 용어인데 이곳을 살펴보면 그 정의를 어느 정도 파악할 수 있습니다. k8s 에서의 control plane은 쉽게 풀어 얘기하자면 현재의 클러스터 상태를 사용자가 원하는 클러스터 상태로 끊임없이 조정해 주는 컨트롤 센터라고 보면 됩니다. control plane에는 실제 서비스와는 무관한 기본적인 k8s 클러스터의 운영과 관련 있는 컴포넌트들이 존재합니다.
사용자가 원하는 클러스터 상태란 영어로 the desired state라고 표현합니다. 주로 사용자가 yaml 파일로 자신이 최종적으로 원하는 서비스(클러스터) 상태를 명세(manifest)해서 k8s object와 controller를 정의합니다. 이를 클러스터에 적용하면 k8s control plane에 있는 컴포넌트들이 사용자가 바라는 상태(사용자의 명세)대로 끊임없이 그리고 스마트하게 클러스터 상태를 맞춰 조정합니다.
하나의 k8s 클러스터의 control plane에는 크게 다음과 같은 두가지 컴포넌트가 존재합니다.
- Master: 클러스터의 컨트롤 타워 역할을 하고, master node라고도 불립니다. 보통 작은 규모의 클러스터라면 vm 한대를 사용하고, HA(고가용성, high-availability) 클러스터에서는 vm 3대로 구성됩니다. Master 안에는 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 등의 하위 컴포넌트들이 존재합니다.
- Nodes: 클러스터의 일꾼 역할을 하는 vm들인데, woker node라고도 불립니다. 서비스 규모에 따라 다르지만 보통 3대 이상의 vm으로 구성되며 CPU/메모리 리소스 사용 요구량에 따라 수평적으로 늘이거나 줄일 수 있습니다. worker node에는 실제 서비스 application들이 docker container 형태로 배포됩니다. 배포된 container들은 클러스터 master와 통신하는 kubelet이라는 에이전트 컴포넌트 통해 운영되며, 이 kubelet은 각 vm 별로 하나씩 존재합니다. 하나의 worker node에는 kubelet, kube-proxy, docker system이 하위 컴포넌트로 있습니다.
위 그림은 k8s 공식문서에서 가져온 k8s control plane 구성요소를 표현한 것입니다. 하나의 k8s 클러스터에 1개의 master node, 3개의 worker node가 존재합니다. 그리고, 각 worker node에 kubelet 과 docker system이 worker node 상에서 실행되고 있는 프로세스로 작게 그려져 있습니다.
‘kubernetes 익히기’를 마무리하며
이번 글에서는 k8s 경험을 공유하게 된 근거, k8s를 사용하는 이유, 필요한 사전 지식, k8s 이름 유래, k8s objects, k8s controllers, k8s control plane 등에 대해 살펴보았습니다. 다시 강조하지만 k8s 사용의 첫걸음은 주요 개념을 제대로 파악하는 것이라 생각됩니다. 처음에는 잘 와닿지 않더라도 이런 개념이 있다는 사실은 분명 알아두고 익혀야 합니다.
다음 글에서는 k8s pod, deployment, service 등에 대해서 상세히 알아보겠습니다. 아래 그림과 유사한 worker node 구성에 대해 이야기 할 예정입니다!
