쿠버네티스 개념과 구성요소ㅣ도커, 컨테이너 오케스트레이션

인사이트

쿠버네티스 개념과 구성요소ㅣ도커, 컨테이너 오케스트레이션

2022년 12월 09일

데브옵스(DevOps)및 클라우드 분야에 관심있는 분들이라면, 도커, 쿠버네티스, 컨테이너 오케스트레이션과 같은 용어를 한번 쯤 접하셨을 텐데요. 쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션 관리시스템으로 오픈 소스 기반입니다. 쿠버네티스가 생겨난 배경과 개념, 구성요소에 대해 알아보도록 하겠습니다.


컨테이너 오케스트레이션의 등장 배경

쿠버네티스에 대해 알아보기 전, 먼저 애플리케이션 실행 환경이 어떻게 변화했는지부터 살펴보겠습니다.

애플리케이션 실행 환경의 변화

애플리케이션 실행 환경의 변화는 아래 3단계로 나눠지는데요. 전통적인 환경에서의 배포 (On-premise)에서 가상 환경에서의 배포 (Virtual Machine)로, 또 컨테이너로의 배포 (Container)로 이어집니다. 아래에서 더 자세하게 살펴보도록 할게요.

1. 전통적인 환경에서의 배포 (On-premise)

초기의 개발 환경은 물리적 서버에서 애플리케이션을 실행하였습니다. 이 방법은 물리적 서버에 애플리케이션의 변경 사항을 쉽게 적용할 수 없고 물리적 서버를 유지 관리하는데도 비용이 많이 들었습니다.

2. 가상 환경에서의 배포 (Virtual Machine)

물리적 환경에 대한 솔루션으로 가상화가 도입이 되었습니다. 단일한 물리적 서버의 CPU에서 여러 대의 가상머신(VM)을 실행할 수 있게 되었습니다. 이러한 가상화를 사용하게 되면 애플리케이션 간에 격리를 할 수 있고 상호 간의 보안 환경 유지할 수 있습니다.

3. 컨테이너로의 배포 (Container)

컨테이너는 위의 가상머신과 유사하지만 컨테이너에는 자체 파일 시스템, CPU 공유, 메모리, 프로세스 공간 등이 있습니다. 기본 인프라에서 분리되기 때문에 클라우드 및 OS 배포 전반에 걸쳐 이식 가능합니다.

이러한 이유로 현재는 컨테이너로 배포하는 환경이 주를 이루고 있습니다.

컨테이너 기술의 장점 그리고 도커의 등장

컨테이너는 프로세스 단위의 격리 환경을 조성하고 있어 상호 간의 의존도를 낮추어 줍니다. 또한 VM에 비해 사이즈가 작아서 배포가 빠르고 성능 손실이 거의 없습니다. 다양한 컨테이너 런타임 기술이 존재하지만 단연 그중에 도커(Docker)가 사실상 표준으로 여겨지고 있습니다.

도커 컨테이너로 서비스를 한다는 것은?

도커 컨테이너로 서비스를 하게 되면 하나의 도커 이미지 안에 서비스 운영에 필요한 모든 것들이 들어 있어 개발자들이 손쉽게 협업을 할 수가 있습니다. 또한 서비스 운영 환경과 개발 환경의 느슨한 결합으로 한쪽의 에러에도 다른 한쪽은 작업을 계속해서 이어 나갈 수가 있습니다. 도커컨테이너는 배포가 쉽고 빠르며 시스템 의존성을 쉽게 업그레이드할 수 있어 스케일 아웃에 용이합니다. CPU limit, Memory limit 등의 시스템 자원을 효율적으로 활용할 수가 있고 무엇보다도 가상머신 보다 성능 면에서 뛰어납니다.

하지만 이렇게 컨테이너화된 애플리케이션도 역시 관리를 해야 합니다. 컨테이너화된 어플리케이션이 다운이 되면 직접 재실행 시켜야 합니다.

전통적인 방식과 VM보다 관리가 용이하지만 컨테이너의 스케일 아웃 장점 때문에 관리해야 하는 컨테이너 수가 많아지게 되면 그 또한 해결해야 하는 과제로 남습니다.

관리해야하는 컨테이너 수가 많아지게 되면?

오케스트레이션(Container Orchestration)이란?

수많은 연주자들이 지휘에 맞춰 연주하는 것을 “오케스트라”라고 합니다.

컨테이너 오케스트레이션은 말 그대로 컨테이너들을 지휘하는 메인 컨트롤러가 있고 그 지휘에 맞춰 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 것을 말합니다. 컨테이너를 사용하는 어떤 환경에서든 사용할 수 있습니다.

여기서 잠깐!
컨테이너의 계층구조는?

아래 이미지에서 컨테이너의 계층 구조를 잠깐 살펴볼까요? 컨테이너 상위계층에 오케스트레이션이 자리 잡고 있습니다. 5단계의 도커 엔진으로 구현되고 있는 컨테이너를 재설계할 필요없이 각기 다른 환경 전반에 동일한 애플리케이션을 배포하는 데 도움이 됩니다.

쿠버네티스 (Kubernetes)란?

쿠버네티스는 원래 구글(Google) 엔지니어들이 개발하고 설계한 플랫폼입니다. 구글은 초창기에 Linux 컨테이너 기술에 기여하였으며 구글 제품이 컨테이너에서 어떻게 작동하는지 대중에게 공개하였습니다. 이는 구글의 클라우드 서비스를 구동하는 기술이기도 합니다. 구글은 내부 플랫폼인 Borg를 통해 일주일에 20억 개 이상의 컨테이너 배포를 생성하고 있습니다. Borg는 쿠버네티스의 전신이었으며 수년 동안 Borg를 개발하는 과정에서 축적된 경험은 쿠버네티스 기술의 주요 원동력이 되었습니다.

쿠버네티스는 원래 조타수를 의미하는 단어입니다. 주어진 명령을 핸들에 의해 반복 실행됨을 의미합니다.

쿠버네티스 기능과 장점은?

실제 프로덕션 환경에서의 애플리케이션들은 여러 컨테이너에 걸쳐 있으며 이러한 컨테이너는 여러 서버 호스트에 배포되어야 합니다.  이 때문에 컨테이너를 위한 보안은 멀티 레이어 구조로 되어 있고 복잡할 수 있습니다. 바로 여기에 쿠버네티스가 사용됩니다. 쿠버네티스는 이러한 워크로드를 위해 규모에 맞는 컨테이너를 배포하는 데 필요한 오케스트레이션 및 관리 기능을 제공합니다. 쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리할 수 있습니다. 또한 IT 보안을 한층 강화할 수 있습니다.

쿠버네티스 주요 구성 요소

클러스터

컨트롤 플레인 및 하나 이상의 컴퓨팅 머신 또는 노드로 구성된 클러스터는 최소 하나 이상의 제어판(Control Plane) 컴포넌트와, 이것과 연결된 몇 개의 워커노드로 구성되어 있습니다.

(21세기에 마스터 노드라는 표현은 쓰지 않도록 합시다. )

컨트롤 플레인(제어판)

쿠버네티스 노드를 제어하는 프로세스들이 모여있는 곳입니다. 여기에서 모든 태스크 할당이 시작되고 제어판 컴포넌트는 클러스터가 잘 작동할 수 있게 돕습니다. 제어판의 구성 요소도 자세히 알아보겠습니다.

1. etcd

  • 쿠버네티스 클러스터의 모든 데이터를 담고 있는 key-value 저장소입니다.
  • 인프라를 원하는 상태로 만들기 위해 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터를 저장합니다.

2. kube-api-server

  • 쿠버네티스 클러스터의 허브로서 클라이언트와 etcd에 저장된 데이터 사이의 상호작용을 중개합니다.
  • 사용자 (운영자), 클러스터 내 구성요소, 그리고 외부 컴포넌트가 서로 통신 할 수 있도록 HTTP API를 제공합니다.
  • kube-api-server 작동 원리

3. kube-scheduler

  • 새로운 POD를 감지하여 어떤 워커노드에 실행시킬지를 선택하는 역할을 합니다.
  • 노드의 현재 상태와 Pod의 요구사항을 체크합니다. 노드에 라벨을 부여합니다.

4. kube-conroller-manager

  • API 서버를 통해 클러스터의 다양한 컴포넌트들의 상태를 감지하고, 원하는 상태로 만드는 역할을 합니다.
  • 다양한 컨트롤러가 하나로 패키징되어 단일 프로세스 내에서 실행되게 합니다.

워커노드

kubelet이라는 프로세스가 돌아가고 있는데, 이 kubelet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 합니다. 한 개 이상의 컨테이너가 자리 잡고 있으며, 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳이라고 할 수 있습니다. 그럼 워커 노드의 구성요소도 자세히 알아보도록 하겠습니다.

1. kubelet

  • 각 노드에서 실행되는 기본 노드 에이전트 입니다. 일종의 데몬이라고 생각하면 이해가 빠를 겁니다.
  • 컨테이너를 생성, 삭제하고 상태를 모니터링하며 마스터 노드와 통신을 담당 역할을 합니다.
  • 큐베렛이 작동하는 원리는 PodSpec 측면에서 작동합니다. 파일로 명시된 PodSpec 부분에 그 코드에 설명된 컨테이너가 실행되고 정상적으로 작동하는 지를 확인합니다.
  • 큐베렛은 쿠버네티스에서 생성되지 않은 컨테이너는 관리하지 않습니다.

2. kube-proxy

  • 모든 워커 노드마다 실행되는 네트워크 프록시입니다.
  • 다른 Pod간의 네트워크 통신과 클러스터 바깥에서 Pod로 네트워크 통신을 할 수 있게 해줍니다.
  • 성능 상의 이유로 별도의 프록시 프로그램 대신 iptable 또는 IPVS를 사용합니다. 즉 설정만 관리한다는 뜻이지요.
(이미지 출처 : https://www.alibabacloud.com )

3. kube-proxy

단일 노드에 배포된 하나 이상의 컨테이너 그룹입니다. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유합니다.

채용 시장에서의 블루오션 스펙,
쿠버네티스 🚀

COVID19 시기를 겪어낸 전 세계의 기업들은 클라우드 서비스의 중요성을 실감하였고 그 시장의 규모가 나날이 커지고 있는 것은 분명합니다. 클라우드 산업의 발전과 규모의 확장으로 IT 기업들은 대량의 서비스를 운영해 낼 수 있는 핵심 기술인 쿠버네티스를 도입하고 있습니다. 현재 북미와 유럽에서 가장 많이 활용되고 있는 쿠버네티스 기술이 그 다음 순위의 동남아시아권으로 이어지고 있으며 Job Offer의 수치를 통해 객관적으로 확인을 할 수가 있습니다.

2021년 Kubernetes Job Offer Located (출처: https://kube.careers/)

이와 더불어 기업들이 요구하는 기술 자격증 중에 가장 인기 있는 aws 자격증을 이어 쿠버네티스 자격증(CKA)이 2위를 차지하고 있습니다.

2021년 자격증 인기순위 (출처: https://kube.careers/)

현재 kubernetes 기술 환경이 많이 활성화되어 있는 미국에서는 kubernetes 기술 스택을 가진 DevOps 엔지니어, 시니어 소프트웨어 엔지니어, 솔루션 아키텍트 등의 연봉이 적게는 $120,000 에서 많게는 $260,000로 분포되어 있습니다.

쿠버네티스 역량을 갖춘 DevOps 엔지니어 커리어
데브옵스 부트캠프에서 시작하세요.

현대의 고도화된 서비스로서의 소프트웨어(SaaS)의 개발 및 운영을 위해서 각 분야의 엔지니어 간의 소통과 협업이 더욱 중요해졌습니다. 데브옵스 엔지니어는 이러한 각 분야의 엔지니어의 소통과 협업, 통합 및 자동화를 이끌어나가는 역할로, 소프트웨어 분야의 꽃이라 할 수 있습니다. 이는 곧 DevOps 엔지니어가 백엔드, 프론트엔드, 데이터, 인프라 엔지니어들이 가진 전문 지식 또한 구비하고 있는 엔지니어라는 의미입니다.

데브옵스 엔지니어의 우대역량인 쿠버네티스를 코드스테이츠 부트캠프에서 배울 수 있습니다.

쿠버네티스의 수요가 늘어나고 그에 맞는 엔지니어의 수요도 늘어나고 있는 지금. 기업이 먼저 찾는 인재가 되기 위한 지름길, 코드스테이츠 데브옵스(DevOps) 부트캠프에서 17주의 기적을 경험을 하시길 바랍니다.

 김은아 DevOps Entry Engineer (DevOps)
편집 조주연 Content Manager


💻️ 데브옵스 엔지니어 커리어의 시작,
DevOps 부트캠프가 더 궁금하다면?

목록 보기

추천글