1. Kubernetes?

본 게시글은 'TTABAE-LEARN' 이성미 강사님의 강의를 정리한 내용입니다.

더 자세한 내용이 궁금하시다면 강의를 참고해보시길 바랍니다.

---

Kubernetes란?

개발을 하거나 시스템 엔지니어링을 해보셨다면 한 번쯤은 컨테이너를 들어보셨을 것입니다. 쿠버네티스는 컨테이너를 도커 플랫폼에 올려서 관리, 운영, 클러스터 서비스 지원 등을 도와주는 컨테이너 오케스트레이션 입니다.

대표적인 컨테이너 오케스트레이션 툴에는 다음과 같은 서비스들이 있습니다. (출처)

• Amazon ECS.
• Azure Container Service(ACS)
• Cloud Foundry's Diego.
• CoreOS Fleet.
• Docker Swarm.
• Google Container Engine.
• Kubernetes.

 

쿠버네티스를 이용하기 위해서는 컨테이너와 도커에 대한 학습이 선행되어야 합니다. 이전 도커 포스팅에서도 다뤘었지만 다시 정리해보도록 하겠습니다. 아울러 쿠버네티스에 대해서도 알아보겠습니다. 

 

컨테이너와 도커란

개념에 대해서 백번 다루기보다는.. 예를 들어 Java/Spring으로 웹 개발을 한다고 가정하겠습니다. Spring으로 제작된 프로그램이 실행되려면 당연히 Spring이 있어야 합니다. Spring을 설치하고 클래스 파일에 필요한 메소드들을 사용한다면 프로그램을 완성할 수 있을 것입니다. 일반적으로 우리의 노트북에서 개발하기 위해서는 노트북에 jdk, spring 등을 설치하는 작업이 필요한데 이러한 일련의 과정으로 컨테이너를 만들 수 있습니다.

Dockerfile을 만들어서 spring의 정보와 소스가 담긴 파일들의 경로를 복사하는 명령어를 추가해줍니다. Dockerfile로 생성된 컨테이너를 실행하게 되면 미리 만들어둔 프로그램이 실행되는 것입니다.

이렇게 만들어진 컨테이너를 실행시키기 위해선 플랫폼이 필요합니다. 즉, 도커와 같은 컨테이너 플랫폼이 필요하게 됩니다. 

 

컨테이너 이미지가 어떻게 생성되는지 알아보겠습니다.

• 네트워크가 가능한 Linux 운영체제에 도커를 설치해줍니다. 설치 후 도커 데몬을 스타트해주면 도커 플랫폼이 실행되고 컨테이너를 빌드/실행할 수 있습니다.
• hub.docker.com과 같은 원격 컨테이너 저장소에서 누구나 컨테이너를 관리할 수 있습니다. 컨테이너를 빌드하면 하드디스크에 컨테이너가 저장되고 푸쉬해주면 원격 저장소에 저장됩니다.
• 반면에 원격 저장소에 저장된 컨테이너를 가져와 사용할 수도 있습니다. 풀 명령어를 이용해 원하는 컨테이너를 가져옵니다.
• 가져온 컨테이너를 start 해주면 도커 플랫폼을 통해 컨테이너가 동작되면서 프로그램이 실행됩니다.
• 이처럼 컨테이너를 동작시키기 위해서 도커 플랫폼이 필요합니다.

 

여기까지 내용을 확인하셨다면 컨테이너가 가상머신과 같은 역할을 한다고 생각하실 수 있습니다. 그럼 가상머신과 컨테이너에 대해서 알아보겠습니다.

 

가상머신 vs. 컨테이너

가상머신 - 하드웨어 인프라에 Hypervisor(VMware, Virtual Box 등)를 설치합니다. 그런 다음 소프트웨어적 기술을 이용해 가상의 머신을 만들어줍니다. 물론 그 가상머신 안에는 하드웨어가 존재하고 애플리케이션을 동작시키기 위한 OS(Guest OS)도 존재합니다. 가상머신에 리소스를 할당할 때는 사용자의 비즈니스 요구사항에 맞게 리소스를 산정하여 딱 그만큼의 리소스만 넣어주면 됩니다. 나중에 운영하면서도 수많은 리퀘스트를 대비해 하드웨어 리소스나 CPU 코어 등을 늘려줄 수도 있습니다. 그렇기 때문에 일반적으로 하나의 가상머신에는 고유의 성격을 갖는 애플리케이션을 운영하곤 합니다.

(Hypervisor를 하나의 운영체제로 바라봅니다)

 

컨테이너 - 하드웨어 인프라에 Host OS가 설치되고 그 위에 도커 플랫폼이 설치됩니다. 도커 플랫폼에서 컨테이너 애플리케이션들이 동작됩니다. 

 

 

구조적으로 조금의 차이가 있지만 단지 이러한 이유로 두 가지를 나눠야만 할까요?

 

일반적으로 실행하는 프로그램은 많은 리소스를 차지하지 않습니다. 하지만 가상머신은 이 프로그램을 실행시키기 위해서 Guest OS를 설치해야 합니다. Guest OS는 약 3GB정도 차지하게 됩니다. 즉, 크기가 얼마 안 되는 프로그램을 실행시키려고 많은 비용이 추가적으로 발생하는 셈입니다. 가상머신 한 대라면 문제가 되지 않겠지만 여러 가상머신이 존재하고 각 가상머신마다 스케일링을 위한 복제본들도 존재합니다.

 

반면에 컨테이너는 사실상 실제 애플리케이션만 있다고 봐도 무방합니다. 가벼운 만큼 빠르게 확장/축소하고 빠르게 배포할 수 있습니다. 그렇기 때문에 컨테이너의 주 역할은 배포라고 할 수 있습니다. 어느 사용자든지 저비용으로 고효율을 내는 플랫폼이 있다면 당연히 그것을 선택할 것입니다.

 

하지만 아무리 스케일링에 있어 유리하다고 한들 시스템 자체에 장애가 발생하면 무용지물이 될 것입니다. 한 대의 시스템으로는 한계가 있기에 멀티 호스트 도커 플랫폼을 만들어줍니다. 예상치 못하게 시스템이 다운되더라도 다른 시스템에서 같은 애플리케이션을 서비스하는 컨테이너가 실행되고 있으므로 중단 없이 서비스가 가능해집니다.

 

여기서 한 가지 더 이슈가 있다면, 엔지니어가 모든 호스트에 대해 서비스를 배치하기란 쉽지 않습니다. 이러한 역할을 해주기 위해 컨테이너 오케스트레이션이 필요한 것입니다.

 

컨테이너 오케스트레이션

앞서 말했듯이 사람이 관리하기 힘들 정도로 웹 서버에 많은 애플리케이션들이 맞물리게 됩니다. 컨테이너 오케스트레이션은 웹 서비스에 가장 적합하게 애플리케이션을 배치하여 운영해주는 역할을 합니다.

도커 플랫폼이 설치된 다수의 노드(worker node)들이 있고 이 노드들을 지휘할 수 있는 마스터 노드(control plane)가 존재합니다. 지휘자는 애플리케이션들을 어떻게 배치했을 때 최적의 환경이 되는지 분석해서 배치합니다. 또한 특정 애플리케이션을 실행 중이던 노드가 다운되면 그 애플리케이션을 옮겨 다른 노드에서 실행되도록 관리해주기도 합니다. 

 

컨테이너 계층구조

• Layer 6 : Development Workflow, Opinionated Containers (OpenShift, Docker Cloud...)
• Layer 5 : Orchestration/Scheduling Service Model (Kubernetes, Docker Swarm...)
• Layer 4 : Container Engine (Docker, Rocket...)
• Layer 3 : Operating System (Ubuntu...)
• Layer 2 : Virtual Infrastructure (EC2. Azure, OpenStack...)
• Layer 1 : Physical Infrastructure (Raw Computer, Network, Storage)

 

K8s의 특징

• 워크로드 분리 (여러 노드가 실행되며 서로 네트워크로 연결되어 있습니다)
• 어디서나 실행 가능 (온프레미스, 퍼블릭 클라우드)
• 선언적 API (쿠버네티스 운영자는 쿠버네티스에게 본인의 요구사항을 선언할 수 있습니다. 예를 들어 쿠버네티스에게 웹 서버 3개 실행해달라고 선언하면 쿠버네티스는 알아서 적절한 노드들에 서버를 배치합니다. 또한 노드가 다운되면 다른 노드에서 서버가 실행되도록 해줍니다.)

 

선언적 API 때문에 쿠버네티스는 DevOps, NoOps가 되도록 해줍니다. 그래서 쿠버네티스를 OS라고 부르는 사람들도 있습니다. 그 이유로.. OS의 역할은 하드웨어에서 애플리케이션이 잘 동작하도록 도와주는 것입니다. 하드웨어 위에서 애플리케이션들이 잘 동작하도록 도와주는 것이 쿠버네티스의 역할이므로 OS처럼 바라볼 수 있는 것입니다.

 

 

---

Reference

• 이성미 강사님
• https://kiki-hihi.tistory.com/4