한빛출판네트워크

✅쿠버네티스의 개념

쿠버네티스는 어떻게 탄생했으며 어떤 역할을 수행하는지 알아봅시다.

1-1) 쿠버네티스의 어원과 역사

쿠버네티스^Kubernetes는 컨테이너화된 애플리케이션의 자동 배포, 확장 및 관리를 해주는 오픈소스^{Open Source} 플랫폼입니다. 쿠버네티스의 스펠링은 Kubernetes인데 이는 고대 그리스어로, 배의 조타수^Helmsman를 의미합니다. 그리고 첫 글자인 K와 마지막 글자인 s 사이에 여덟 글자가 있다고 해서 쿠버네티스를 줄여서 K8s라고도 부릅니다.

쿠버네티스는 구글에서 시작한 사내 프로젝트로 2014년에 발표되었습니다. 쿠버네티스의 초기 디자인 대부분은 구글의 Borg 클러스터 매니저의 영향을 많이 받았습니다. Borg는 구글 사내에서 사용하는 시스템으로 수천 개의 서버에서 수백만개의 작업을 실행하고 관리하는 시스템입니다. 시간이 지나 2015년에 쿠버네티스 1.0 버전이 발표되었고, 2016년에는 쿠버네티스 패키지 관리 프로그램인 헬름^Helm이 발표되었습니다. 이후 실습에서도 헬름을 사용할 예정입니다.

1-2) 쿠버네티스의 역할

쿠버네티스는 쉽게 말해 수많은 컨테이너를 관리하는 시스템입니다. 특히 서버를 다수 운영한다면 서로 다른 서버에서 작동하는 수많은 컨테이너를 한꺼번에 관리하는 것은 매우 어려운 일입니다.

예를 들어, 당장 컨테이너를 실행하려고 하는데, 컨테이너가 100개라면 docker container run 명령어를 100번 입력해야 합니다. 뿐만 아니라 실행 중인 컨테이너에 문제가 생겼을 때 대응하는 경우에도 비슷한 경우가 발생합니다. 따라서 컨테니어가 많을수록 당연히 컨테이너를 관리하는 것도 어렵습니다.

쿠버네티스를 사용하면 여러 개의 컨테이너를 쉽게 생성하고 관리할 수 있습니다. 바로 이런 부분 때문에 쿠버네티스를 사용하는 것입니다.

✅쿠버네티스의 구조

이 절에서는 쿠버네티스의 구조에 대해 알아보겠습니다. 쿠버네티스는 도커에 비해 더 복잡한 구성요소로 이루어져 있습니다. 지금부터 쿠버네티스를 구성하는 쿠버네티스 클러스터, 컨트롤 플레인, 노드, 워크로드, 네트워크, 스토리지에 대해 살펴봅시다.

2-1) 쿠버네티스 클러스터

쿠버네티스는 다수의 노드로 구성되는 경우가 많습니다. [그림 7-1]을 보면 쿠버네티스 클러스터는 크게 마스터 노드^{Mater Node}와 워커 노드^{Worker Node}로 구분되는 것을 알 수 있습니다. 개발자는 주로 마스터 노드와 통신하며 사용자는 인터넷을 통해 워커 노드와 통신하는 경우가 많습니다.

[그림1-1] 쿠버네티스 구조 (1)

[그림 1-1]과 같은 구조를 유지하기 위해서는 마스터 노드와 워커 노드 간의 유기적인 통신이 중요합니다. 이를 위해 CNI^{Container Network Interfaces} (컨테이너 네트워크 인터페이스)라는 개념이 사용됩니다. CNI는 말 그대로 쿠버네티스 클러스터에 존재하는 컨테이너 간의 통신을 위해 필요한 인터페이스를 의미합니다. CNI를 사용하려고 쿠버네티스 네트워크 플러그인^{Kubernetes network plugin}을 제공하는데, 대표적인 플러그인은 Flannel과 calico입니다. 이 책에서는 보안 기능이 뛰어나며 다양한 기능을 제공하는 calico를 사용할 예정입니다.

2-2) 컨트롤 플레인

쿠버네티스 마스터 노드는 컨트롤 플레인^{Control Plane}을 다루는데, 컨트롤 플레인이란 쿠버네티스 클러스터 전반의 작업을 관리하는 역할을 합니다. [그림 1-2]는 쿠버네티스의 구조를 나타낸 것입니다. 그림과 같이 마스터 노드에서 컨트롤 플레인을 구성하는 요소에는 API 서버, etcd, 스케줄러, 컨트롤러 매니저가 있습니다.

[그림1-2] 쿠버네티스 구조 (2)

API 서버

쿠버네티스의 작업은 kubectl 명령어를 통해 마스터 노드의 kube-apiserver에게 API 요청을 보냄으로써 이루어집니다. API 서버는 쿠버네티스 컨트롤 플레인에서의 프런트엔드 역할을 합니다.

etcd

쿠버네티스 클러스터에 존재하는 모든 데이터를 저장하는 key-value 저장소입니다.

스케줄러

쿠버네티스에서는 이후 배울 파드^pod라는 오브젝트를 통해 애플리케이션을 실행합니다. 파드는 쿠버네티스 클러스터를 구성하는 노드 중 하나에 실행됩니다. 이때 새롭게 생성되는 파드를 어느 노드에 실행시킬지 정하는 역할을 kube-scheduler가 수행합니다.

컨트롤러 매니저

쿠버네티스 컨트롤러 매니저는 쿠버네티스 리소스를 관리하고 제어하는 역할을 합니다. 컨트롤러는 마스터 노드에서 실행되며 클러스터 상태를 모니터링합니다. 컨트롤러에는 디플로이먼트^Deployment 컨트롤러, 서비스^Service 컨트롤러, 레플리카셋^ReplicaSet 컨트롤러 등의 여러 종류가 있습니다. 각 컨트롤러는 특정 리소스 타입을 관리합니다.

3. 노드

이번에는 쿠버네티스 노드를 구성하는 구성 요소와 역할에 대해 알아보겠습니다. 쿠버네티스의 노드는 다음과 같은 요소로 구성됩니다.

Kubelet

쿠버네티스 클러스터를 구성하는 각 노드에는 Kubelet이 실행되는데 Kubelet은 파드 내부의 컨테이너 실행을 담당합니다. Kubelet은 파드의 상태를 모니터링하고, 파드의 상태에 이상이 있다면 해당 파드를 다시 배포합니다.

Kube-Proxy

Kube-Proxy는 노드에서 네트워크 역할을 수행합니다. Kube-Proxy는 노드에 존재하는 파드들

이 쿠버네티스 내부/외부와 네트워크 통신을 가능하게 합니다.

컨테이너 런타임

컨테이너 런타임^{Container Runtime}은 컨테이너의 생명주기를 담당합니다. 이를 위해 Kubelet은 컨테이너 런타임과 통신하는데, 이때 사용하는 것이 컨테이너 런타임 인터페이스^{Container Runtime Interface}입니다. 쿠버네티스가 사용하는 컨테이너 런타임에는 containerd, CRI-O 등이 있는데 이 책에서는 가장 보편적으로 사용하는 런타임인 containerd를 사용하겠습니다.

파드

앞서 도커에서는 컨테이너가 단독으로 실행되었지만 쿠버네티스에서는 컨테이너가 단독으로 실행하는 것이 아닌 파드^Pod 내에서 실행됩니다. 파드는 컨테이너를 실행하기 위한 오브젝트인데, 각 파드는 한 개 혹은 여러 개의 컨테이너를 담을 수 있습니다. 즉, 파드는 컨테이너를 그룹화한 것이라고 생각하면 됩니다. 앞서 도커의 최소 실행 단위가 컨테이너였다면 쿠버네티스의 최소 실행 단위는 파드인 것입니다. 쿠버네티스에서 다수의 파드들은 여러 워커 노드에 분산되어 실행되는데, 하나의 파드에 속하는 컨테이너들은 모두 같은 노드에서 실행됩니다. 즉, 서로 다른 파드는 서로 다른 노드에서 실행될 수 있지만, 하나의 파드가 분할되어 여러 노드에 실행되는 일은 없다는 것입니다. 하나의 파드는 하나의 노드에서 실행됩니다.

하나의 파드에 속한 컨테이너들은 하나의 목적을 위해 구성된 컨테이너들입니다. 파드는 컨테이너처럼 일시적인 존재입니다. 파드는 실행할 때마다 IP 주소를 배정받으므로 파드의 IP 주소는 실행할 때마다 변경됩니다.

4. 워크로드

워크로드^Workload는 쿠버네티스에서 실행되는 애플리케이션을 의미합니다. 워크로드가 하나의 컴포넌트 형태로 실행하든, 다수의 컴포넌트가 함께 실행하든 쿠버네티스는 파드 내부에서 워크로드를 실행하게 됩니다. 이때 파드는 실행 중인 컨테이너의 집합을 나타냅니다. 워크로드의 종류는 다음과 같습니다.

레플리카셋

레플리카셋^ReplicaSet은 파드의 복제를 관리하며 클라이언트가 요구하는 복제본 개수만큼 파드를 복제하고 모니터링하고 관리합니다.

디플로이먼트

디플로이먼트^Deployment는 배치라는 의미가 있습니다. 이 의미에 맞게 디플로이먼트는 애플리케이션의 배포와 스케일링을 관리하는 역할을 담당합니다.

스테이트풀셋

스테이트풀셋^StatefulSet은 파드 사이에서 순서와 고유성이 보장되어야 하는 경우에 사용합니다.

데몬셋

데몬셋^DaemonSet은 쿠버네티스를 구성하는 모든 노드가 파드의 복사본을 실행하도록 합니다. 쿠버네티스 클러스터에 새로운 노드가 추가되면 파드 역시 추가됩니다. 데몬셋은 주로 로깅, 모니터링, 스토리지 등과 같은 시스템 수준의 서비스를 실행하는 데 사용됩니다.

잡과 크론잡

잡^Job과 크론잡^Cronjob은 작업^Task이 정상적으로 완료되고 종료되는 것을 담당합니다. 만약, 파드가 정상적으로 종료되지 않는다면 재실행시킵니다. 잡은 작업이 한 번 종료되는 것을 담당하고 크론잡은 동일한 작업이 스케줄에 따라 여러 번 수행하는 것을 담당합니다. 크론잡은 리눅스에서 사용하는 크론 탭^Crontab과 비슷한 역할을 합니다.

5. 네트워크

쿠버네티스에서는 네트워크와 관련이 있는 두 가지 요소가 있습니다.

서비스

쿠버네티스의 서비스^Service를 사용하면 파드를 여러 개 묶어서 클러스터 외부로 노출시킬 수 있습니다. 서비스를 사용하는 방법의 장점은 이미 실행 중인 파드를 외부로 노출시키기 위해 파드 내부를 수정할 필요가 없다는 것입니다. 쿠버네티스 서비스를 활용하면 실행 중인 파드 수정 없이도 외부에 노출시켜 클라이언트와 통신할 수 있습니다.

인그레스

인그레스^Ingress를 활용하면 쿠버네티스 내부에 존재하는 서비스를 HTTP/HTTPS 루트를 클러스터외부로 라우팅하는 역할을 합니다.

6. 스토리지

컨테이너 내부에 존재하는 파일들은 수명이 짧습니다. 컨테이너에 이런저런 문제가 생기거나 컨테이너가 삭제되거나 재실행되면 해당 컨테이너 내부에 존재하는 파일을 모두 삭제되기 때문입니다. 하지만 쿠버네티스 스토리지를 활용하면 파드의 상태와 상관없이 파일을 보관할 수 있습니다.

'한 권으로 배우는 도커 & 쿠버네티스'는 현재 IT 환경에서 필수적인 이 두 가지 기술을 단계별로 깊이 있게 다룹니다. 도커의 기본 개념과 원리, 도커 설치와 기초 명령어, 컨테이너 네트워크와 스토리지에 대해 자세히 설명합니다. 그리고 실제로 Django와 Flask 애플리케이션을 도커 컨테이너로 실행해보는 실습이 곁들여 있죠.

쿠버네티스 파트에서는 쿠버네티스의 구조와 구성 요소를 꼼꼼히 알아본 뒤, 실습 환경에 쿠버네티스 클러스터를 직접 구축해봅니다. 디플로이먼트, 서비스, 스토리지 볼륨 등 쿠버네티스 기초부터 익히고, Django와 Flask를 쿠버네티스에 배포하는 방법까지 다룹니다. 나아가 CI/CD 파이프라인 구축, 모니터링 환경 구성까지 자세히 소개하고 있습니다.

무엇보다 실습 환경 구축 방법을 친절하게 안내하고, 각 장마다 실습 예제를 통해 이론을 실무에 바로 적용할 수 있도록 했습니다. 초심자라도 차근차근 단계를 밟아가다 보면 어느새 도커와 쿠버네티스 전문가가 되어있을 것입니다.

현재 클라우드 네이티브 애플리케이션 개발과 데브옵스가 점점 더 중요해지고 있습니다. 도커와 쿠버네티스로 컨테이너 기반 개발과 운영 환경을 구축하는 것은 필수적인 역량입니다. 이 책을 통해 이러한 기술 역량을 기르신다면, 현대 IT 기술의 중심에 서실 수 있을 것입니다. 더 효율적이고 확장 가능한 애플리케이션 개발과 운영 환경을 구축할 수 있는 발판이 되어줄 것입니다.

✅컨테이너 개념부터 쿠버네티스를 활용한 배포까지 『한 권으로 배우는 도커 & 쿠버네티스』

도서구매 교보문고 / 예스24 / 알라딘