본문 바로가기
IT Security/Docker & Kubernetes

[Docker & Kubernetes] 2. 도대체 Kubernetes는 뭘 하는 녀석일까?

by Rosmary 2022. 5. 8.
728x90
반응형

 

 

 

 

지난 포스팅에서 리눅스 컨테이너(LXC) 기술을 기반으로 동작하는 Docker 플랫폼의 탄생 배경과 기능에 대해 간략하게 알아보았다. 요점만 정리하자면, 하나의 서버에서 여러 어플리케이션(서비스)를 구동하기 위한 환경을 OS 수준의 가상화로 구현할 수 있는 기술인 LXC를 조금 더 쉽게 사용하도록 만들어 놓은 플랫폼이 Docker다. 

 

Docker와 함께 요즘 자주 볼 수 있는 단어로 Kubernetes(쿠버네티스)가 있다. Docker와 Kubernetes는 마치 바늘과 실처럼 한 쌍을 이루어 언급되는 경우가 거의 대부분이다. 그럼 여기서 의문이 생긴다. 도대체 Kubernetes는 무엇이며, Docker와의 관계는 어떻게 되는 것일까?

 

 

1. Kubernetes의 등장 배경

 

Docker를 사용하여 제공하고자 하는 서비스의 환경이 구성된 Image(이미지)를 하나 실행한다고 해보자. Docker Image는 구동하고자 하는 프로그램의 환경 정보를 추상화한 것이며, 이 Image를 실행하는 경우 Image에 정의된 Service Container가 다른 프로세스들과 독립적으로 작동하게 된다.

 

docker run 명령어로 특정 환경을 가지는 Container를 구동할 수 있다.

 

Docker를 사용하는 이유는 Hyper-V와 다르게 경량화된 가상환경을 구성하여 각 프로세스를 독립적으로 구동시키려는 목적이 크다. 따라서 위의 예시처럼 하나의 서버에 하나의 Docker Image를 실행하기보다, 복수의 Docker Image를 실행하는 경우가 대부분이다. 

 

 

* 참고: Pod는 Container를 서버에 배포하는 Docker의 가장 기본 단위다.

          Pod 내에 존재하는 Container는 외부와 통신 시, Pod의 IP를 공유하여 통신을 진행한다.

          각 Pod가 보유하는 통신 IP는 각기 다르게 설정된다.

 

 

여러 개의 컨테이너가 등록되는 경우 발생할 수 있는 문제점들은 무엇이 있을까?

 

(1) 컨테이너가 등록된 서버가 고장나면 어떡하지?

컨테이너가 등록된 서버가 한 대라고 가정해보자. 만약 하드웨어 이슈가 서버에 발생한다면 서버에 등록된 모든 Container들이 서비스 제공을 할 수 없게 된다. 이 때문에 Docker 서버를 여러 대 구성한 뒤, 하나의 서버에 문제가 발생하는 경우, Docker Image 를 정상 서버에서 run 하여 기존의 컨테이너를 등록할 수 있다. 그런데, 서버에 문제가 생겼음에도 불구하고, 해당 서비스가 사람들에게 많이 사용되지 않는 경우라면, 서버 이슈가 발생하고 몇 달이 지나도 모르고 넘어가는 경우가 많다(필자가 담당했던 제품이 간간히 그런 일이 있었다). 즉, 업무의 연속성이 끊어지는 문제가 발생하게 된다. 

 

(2) Scale Up이 필요한 경우 손쉽게 할 수 있는 방법이 없을까?

서버에 등록한 서비스 중에 웹 서비스가 있다고 가정해보자. 사람이 많이 몰려 해당 웹 서비스 컨테이너의 Scale Up(조선말로 '확장' 또는 '증설' 정도로 보면 될 듯 하다)을 진행해야한다고 해보자. 서로 다른 서버에 존재하는 동일한 서비스는 별개의 서비스가 아닌 분산(또는 이중화) 구조를 이루어야한다. 그런데, 사람이 많이 몰려오는 것을 어떻게 알 수 있을까? 이를 자동으로 감지해서 다른 서버에 동일한 Container를 올려 이중화해주는 기능까지 자동으로 구성해주는 Tool은 없는 것일까?

 

 

(3) 특정 Container가 비정상으로 종료되면 자동으로 재시작하도록 할 수 있을까? 

서버의 하드웨어 이슈가 발생하는 경우가 아니라, 등록한 Container에서 이상이 생겨 서비스 중단이 일어났다고 가정해보자. Kubernetes가 없다면 서비스 중단은 클라이언트에서 보고를 받지 않는 이상 관리자가 알기 매우 힘들다. 

 

 

위에서 예시로 들었던 문제점 외에도, Docker 사용 시 나타나는 관리적인 측면에서 나타날 수 있는 문제점을 해결해야 할 필요성이 생겼다. 즉, Container의 조율, 자동화와 관련된 별도의 제품이 나타나야만 Docker를 효율적으로 운영할 수 있겠다는 공감대가 생기게 된 것이다.

 

 

 

2. Docker Orchestration 제품군의 등장과 Kubernetes

 

Kubernetes의 로고

 

Docker Container의 조율, 자동화와 관련된 제품을 "Docker Orchestration"이라고 한다. Docker가 상용화되고 난 후, Docker swarm, Apache Mesos, kubernetes 등의 제품이 시장에 등장했다. 각 제품마다 주요한 특장점이 있지만, 현재 Docker Orchestration 제품으로 Kubernetes가 가장 많이 언급되고 있다. 

 

Kubernetes는 그리스어로 배의 조타수(Pilot)를 의미한다. 이름의 의미에서도 알 수 있듯이, Docker를 통해 실행되는 모든 Container를 적절한 위치에 배치하고 관리하는 역할을 한다.

 

Kubernetes의 구성은, Container가 올라오는 Worker Node(서버)와 Worker Node를 관리하는 Master Node로 이루어진다. 이들 Master Node와 Worker Node는 Kubernetes의 클러스터를 이루며, Master Node에서는 YAML이라 불리는 파일 확장자를 사용하여 클러스터 서비스를 정의한다. 또한 Kubernetes는 Docker 서버가 온프레미스(On-Premise), 퍼블릭 클라우드(Public Cloud), 하이브리드로 구성되어 있더라도 동작이 가능하다는 장점이 있어 최근 Docker Orchestration 제품으로 가장 많이 사용되고 있다.

 

출처: https://mohan08p.medium.com/simplified-kubernetes-architecture-3febe12480eb, Kubernetes 클러스터 아키텍쳐.

 

 


 

Docker와 Kubernetes는 택 1을 할 수 있는 별개의 기능을 가진 제품이 아니다. 정리하자면 Docker는 서버 자원을 최대한 효율적으로 사용하기 위한 LXC(리눅스 컨테이너)를 쉽게 생성할 수 있도록 만드는 경량 가상화 플랫폼이고, Kubernetes는 Docker를 사용한 Container 관리를 자동화, 조율하는 제품이라고 보면 된다.

 

다음 포스팅부터는 Docker 및 kubernetes의 설치, 사용법에 대해 하나씩 알아보려 한다. 필자 나름대로 Docker와 Kubernetes의 등장 배경에 대해 정리하긴 했는데, 직접 사용해보지 않으니 와닿지가 않아서 설치부터 Container 생성, 배포 등을 진행하며 관련 내용을 포스팅하려고 한다.

 

Docker 설치에 대해 다음 포스팅에서 언급하려 한다. Kubernetes는 Docker 사용법에 익숙해진 뒤 진행해보려 한다.

 

 

 

 

Fin.

반응형

댓글