Kubernetes

menu icon

Kubernetes

Kubernetes는 애플리케이션의 배치, 관리 및 확장을 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. Kubernetes가 비용 효율적인 클라우드 네이티브 개발을 어떻게 지원하는지 알아봅니다.

Kubernetes란?

“k8s” 또는 “kube”라고도 부르는 Kubernetes는 컨테이너화된 애플리케이션의 배치, 관리 및 스케일링을 스케줄링하고 자동화하기 위한 컨테이너 오케스트레이션 플랫폼입니다.

2014년에 오픈 소스가 되기 이전, Kubernetes은 처음에 Google의 엔지니어가 개발했습니다. 이는 Google 내부에서 사용되던 컨테이너 오케스트레이션 플랫폼인 Borg에서 유래합니다. Kubernetes는 조타수 또는 조종사에 해당하는 그리스어입니다. 따라서 Kubernetes 로고( IBM 외부 링크)에는 조타기가 있습니다.

오늘날, Kubernetes 및 보다 광범위한 컨테이너 에코시스템은 최신 클라우드 인프라와 애플리케이션의 기본 구성요소로서 가상 머신(VM)을 뛰어넘지는 못하더라도 이와 경쟁 구도를 형성하는 범용 컴퓨팅 플랫폼 및 에코시스템으로 발전하고 있습니다. 이러한 에코시스템을 통해 기업들은 개발 팀이 오직 코딩과 혁신에만 집중할 수 있도록 클라우드 네이티브 개발과 관련된 다수의 인프라/운영 관련 태스크와 문제를 처리하는 고가용성 PaaS(Platform-as-a-Service)를 제공할 수 있습니다.     

다음 동영상에서 Sai Vennam은 Kubernetes 기초에 대해 설명합니다. (10:59)

컨테이너란?

먼저 이를 정의하겠습니다. 컨테이너는 데스크탑, 기존 IT 또는 클라우드의 어디서나 실행될 수 있도록 일반적인 방식으로 애플리케이션 코드가 라이브러리 및 종속 항목들과 함께 패키징된 소프트웨어 실행 단위입니다.

컨테이너는 프로세스를 격리하고 해당 프로세스가 액세스할 수 있는 CPU, 메모리 및 디스크의 양을 제어함으로써 여러 애플리케이션이 OS를 공유할 수 있도록 하는 운영 체제(OS) 가상화의 형태를 활용합니다.

컨테이너 vs. 가상 머신 vs. 기존 인프라

IT 인프라 자동화 및 추상화의 연속체에 대한 최신 관점으로서 컨테이너를 이해하는 것이 더 쉽거나 더 유용할 수 있습니다.

기존 인프라에서 애플리케이션은 물리적 서버에서 실행되며, 얻을 수 있는 모든 리소스를 확보합니다. 이로 인해 단일 서버에서 여러 애플리케이션을 실행하면서 하나의 애플리케이션이 다른 애플리케이션을 희생하며 리소스를 독차지하지 않기를 기대하거나 애플리케이션당 하나의 서버를 전용함으로써 리소스를 낭비하고 스케일링하지 않도록 선택할 수 있습니다.

가상 머신(VM)은 실제 컴퓨터 하드웨어에서 추상화된 서버이며, 이를 통해 하나의 물리적 서버에서 다수의 VM을 실행하거나 둘 이상의 물리적 서버에 걸쳐있는 단일 VM을 실행할 수 있습니다. 각각의 VM은 자체 OS 인스턴스를 실행하고 사용자는 자체 VM에서 각 애플리케이션을 격리함으로써 동일한 기본 물리적 하드웨어에서 실행되는 애플리케이션이 서로 간에 영향을 줄 가능성을 줄일 수 있습니다. VM을 통해 리소스를 보다 효과적으로 사용할 수 있으며 기존 인프라보다 훨씬 쉽게 비용 효율적으로 스케일링이 가능합니다. 그리고 이는 일회용입니다. 애플리케이션을 더 이상 실행할 필요가 없으면 VM을 처분합니다.

VM에 대한 자세한 내용은 "가상 머신: 기본 안내서"를 참조하세요.

컨테이너는 이러한 추상화를 한 단계 위로 끌어올립니다. 특히 기본 가상 하드웨어의 공유 외에, 이는 기본 가상 OS 커널도 공유합니다. 컨테이너는 VM의 격리성, 확장성 및 처분 가능성을 동일하게 제공하지만, 자체 OS 인스턴스의 페이로드를 전달하지 않으므로 VM보다 경량입니다(즉, 공간을 덜 차지함). 이는 리소스 효율성이 더욱 높습니다. 이를 사용하면 보다 적은 OS 인스턴스로 보다 적은 수의 머신(가상 및 실제 머신)에서 보다 많은 애플리케이션을 실행할 수 있습니다. 컨테이너는 데스크탑, 데이터 센터 및 클라우드 환경에서 보다 손쉽게 포팅이 가능합니다. 그리고 이는 Agile 및 DevOps 개발 사례에 아주 안성맞춤입니다.

"컨테이너: 기본 안내서"는 컨테이너 및 컨테이너화에 대한 완벽한 설명을 제공합니다. 또한 블로그 포스트 "컨테이너 대 VM: 차이점"에서는 차이점에 대한 완벽한 설명을 제공합니다.

Docker란 무엇일까요?

Docker는 Linux® 컨테이너를 구축하고 실행하기 위한 가장 유명한 툴입니다. 초기 형태의 컨테이너가 (FreeBSD Jails 및 AIX Workload 등의 기술과 함깨) 수십 년 전에 소개되었긴 하지만, 컨테이너는 Docker가 개발자 친화적이고 클라우드 친화적인 새로운 구현을 통해 대중들에게 이를 제공했던 2013년에 보편화되었습니다.

Docker는 오픈 소스 프로젝트로 시작되었지만, 오늘날 이는 오픈 소스 프로젝트에서 구축되는 상용 컨테이너 툴킷인 Docker를 생산하는(또한 오픈 소스 커뮤니티에 다시 해당 개선사항을 제공하는) 회사인 Docker Inc.로도 지칭됩니다.

Docker는 기존 Linux 컨테이너(LXC) 기술을 기반으로 구축되었지만, Linux 커널 프로세스의 보다 세부적인 가상화를 작동시키며 개발자가 컨테이너를 보다 손쉽게 구축, 배치, 관리 및 보호할 수 있도록 하는 기능을 추가합니다.

현재 OCI(Open Container Initiative), CoreOS 및 표준(Ubuntu) LXD 등 대체 컨테이너 플랫폼이 존재하는 상황에서 Docker는 매우 널리 이용되고 있으며, 따라서 사실상 이는 컨테이너와 동의어이며 종종 Kubernetes 등의 무상 제공되는 기술에 대한 경쟁자로서 잘못 오인되기도 합니다. (동영상 참조: “Kubernetes 대 Docker: 이는 양자택일의 문제가 아님").

Kubernetes의 컨테이너 오케스트레이션

컨테이너가 빠르게 확산되고 오늘날 기업이 수많은 컨테이너를 보유할 수 있게 되면서, 운영 팀들은 컨테이너 배치, 네트워킹, 확장성 및 가용성을 스케줄하고 자동화해야 했습니다. 따라서 컨테이너 오케스트레이션 시장이 생겼습니다.

기타 컨테이너 오케스트레이션 옵션(가장 유명하게는 Docker Swarm 및 Apache Mesos)이 초기에 약간 인기를 끌긴 했지만, Kubernetes는 빠르게 가장 널리 채택이 되었습니다(사실상 한 때 이는 오픈 소스 소프트웨어의 역사상 가장 빠르게 성장하는 프로젝트였음).

개발자들은 매우 다양한 기능, 방대하고 계속 성장하는 오픈 소스 지원 툴의 에코시스템 그리고 선도적인 클라우드 제공자(이들 중 일부는 현재 완전 관리형 Kubernetes 서비스를 제공함)들 간의 지원과 이식성 때문에 Kubernetes를 선택했으며 지금도 지속해서 선택하고 있습니다.

컨테이너 오케스트레이션에 대한 자세한 정보를 알아보려면 "컨테이너 오케스트레이션 설명"(08:59)" 동영상을 시청하세요.

Kubernetes의 역할은 무엇일까요?

Kubernetes는 다음과 함께 기타 컨테이너 관련 태스크를 스케줄하고 자동화합니다.

  • 배치: 지정된 수의 컨테이너를 지정된 호스트에 배치하고 이를 원하는 상태로 계속 실행합니다.
  • 롤아웃: 롤아웃은 배치에 대한 변경입니다. Kubernetes를 사용하여 롤아웃을 시작, 일시정지, 재개 또는 롤백할 수 있습니다.
  • 서비스 검색: Kubernetes는 DNS 이름 또는 IP 주소를 사용하여 컨테이너를 인터넷이나 기타 컨테이너에 자동으로 노출할 수 있습니다.
  • 스토리지 프로비저닝: 필요에 따라 컨테이너에 대해 지속적 로컬 또는 클라우드 스토리지를 마운트하도록 Kubernetes를 설정합니다.
  • 로드 밸런싱 및 스케일링: 컨테이너에 대한 트래픽이 급증할 때 Kubernetes는 로드 밸런싱 및 스케일링을 이용하여 이를 네트워크에서 분산함으로써 안정성을 유지할 수 있습니다.
  • 고가용성을 위한 자가 치료: 컨테이너에서 장애가 발생하면 Kubernetes는 자동으로 이를 다시 시작하거나 교체할 수 있습니다. 또한 상태 확인 요구사항을 충족하지 않는 컨테이너를 중지시킬 수도 있습니다.

Kubernetes vs. Docker

지금까지의 설명을 읽어 왔다면, 아마도 Kubernetes가 Docker Swarm에 대한 대안이면서도 (지속적으로 널리 알려진 오해와는 상반되게) Docker 자체와는 대안이나 경쟁자가 아님을 파악하셨을 것입니다.

사실상 적극적으로 Docker를 채택했으며 대규모 Docker 기반 컨테이너 배치를 구축 중인 경우, Kubernetes 오케스트레이션은 이러한 워크로드를 관리하기 위한 논리적 차기 단계입니다. 자세한 내용은 "Kubernetes vs. Docker: 이는 양자택일의 문제가 아님" (08:03)을 시청하세요.

Kubernetes 아키텍처

Kubernetes 아키텍처의 주요 구성요소에는 다음이 포함됩니다.

클러스터 및 노드(컴퓨팅)

클러스터는 Kubernetes 아키텍처의 구성 요소입니다. 클러스터는 노드로 구성되며, 이들 각각은 단일 컴퓨팅 호스트(가상 또는 물리적 시스템)를 나타냅니다.

각각의 클러스터는 컨테이너화된 애플리케이션을 배치, 실행 및 관리하는 다수의 작업자 노드와 작업자 노드를 제어하고 모니터하는 하나의 마스터 노드로 구성되어 있습니다.

마스터 노드는 개발자가 설정한 배치 요구사항과 사용 가능한 컴퓨팅 용량을 기반으로 컨테이너가 배치되는 시점과 위치를 자동화하는 스케줄러 서비스를 실행합니다. 각각의 작업자 노드에는 Docker 등의 컨테이너를 관리하는 데 사용되는 툴과 함께 마스터 노드에서 주문을 받아서 이를 실행하는 Kubelet이라고 부르는 소프트웨어 에이전트가 포함되어 있습니다.

Kubernetes 클러스터에 대한 자세한 정보를 보려면 블로그 게시물 "Kubernetes 클러스터: 빠르고 통제된 클라우드 앱 딜리버리를 위한 아키텍처"를 확인하세요.

팟(Pod) 및 배치(소프트웨어)

팟(Pod)은 동일 컴퓨팅 리소스와 동일 네트워크를 공유하는 컨테이너의 그룹입니다. 이는 또한 Kubernetes에서 확장성의 유닛입니다. 팟의 컨테이너가 자체 처리할 수 있는 양보다 많은 트래픽을 받는 경우, Kubernetes는 해당 팟을 클러스터의 다른 노드로 복제합니다. 이러한 이유로 인해 리소스를 공유해야 하는 컨테이너만 포함하도록 팟(Pod)을 최소한으로 유지하는 것이 좋습니다.

배치는 컨테이너화된 애플리케이션의 구축과 상태를 제어하며 이의 실행을 유지합니다. 이는 클러스터에서 실행해야 하는 팟(Pod)의 복제본 수를 지정합니다. 팟(Pod)이 실패하면 배치에서 새 팟(Pod)을 작성합니다.

Kubernetes 배치에 관한 자세한 내용은 "Kubernetes 배치: 빠르게 시작(03:54)"을 시청하세요.

Kubernetes 아키텍처의 요소들을 보다 자세히 알아보려면 자가 진도형 온라인 과정인 “Kubernetes 101”을 들어보세요.

블로그 포스트 "Kubernetes 아키텍처: 컨테이너 솔루션에 대한 네 가지 접근 방법"을 사용하여 자세히 살펴볼 수도 있습니다.

Istio 서비스 메시

Kubernetes가 팟(Pod)을 배치하고 스케일링할 수 있지만, 이는 팟(Pod) 간의 라우팅을 관리하거나 자동화할 수 없으며 이러한 연결을 모니터, 보호 또는 디버그할 수 있는 툴을 제공하지 않습니다. 클러스터에서 컨테이너의 수가 증가하면 이들 간에 가능한 연결 경로의 수가 기하급수적으로 늘어나며(예: 2개의 컨테이너에는 2개의 잠재적 연결이 있지만, 10개의 팟에는 90개의 잠재적 연결이 있음), 이의 잠재적인 구성과 관리는 정말 끔찍한 일이 됩니다.

Kubernetes 클러스터의 오픈 소스 서비스 메시 계층인 Istio에 진입합니다. 각각의 Kubernetes 클러스터에 대해 Istio는 기타 컨테이너들 간의 상호작용을 구성, 모니터 및 관리하며 기본적으로 프로그래머와 관리자에게는 보이지 않는 사이드카 컨테이너를 추가합니다.

Istio를 사용하여 사용자는 각 연결을 개별적으로 구성할 필요가 없도록 컨테이너 간의 연결을 구성하는 단일 정책을 설정합니다. 이를 통해 컨테이너 간의 연결을 더 쉽게 디버그할 수 있습니다.

또한 Istio는 DevOps 팀과 관리자가 대기 시간, 서비스 시간 오류 및 컨테이너 간 연결의 기타 특성을 모니터하는 데 사용할 수 있는 대시보드를 제공합니다. 또한 이는 보안(특히, 비인가된 사용자의 컨테이너간 서비스 호출에 대한 스푸핑을 방지하는 ID 관리) 및 보안 전문가가 클러스터의 모니터링에 사용할 수 있는 AAA(Authentication, Authorization and Auditing) 기능으로 구축됩니다.

사용 중인 Istio의 일부 예제와 동영상을 포함한 세부사항은 "Istio란 무엇일까요?" 기사를 참조하세요.

Knative 및 서버리스 컴퓨팅

Knative(발음은 ‘kay-native’)는 Kubernetes 상에 위치한 오픈 소스 플랫폼이며, 클라우드 네이티브 개발을 위한 두 가지 중요한 유형의 장점을 제공합니다.

Knative은 서버리스 컴퓨팅에 대한 손쉬운 온램프를 제공함

서버리스 컴퓨팅은 클라우드 네이티브 애플리케이션을 보다 효율적이고 높은 가성비를 지닐 수 있도록 하는 코드를 배치하는 비교적 새로운 방법입니다. 요청 대기 중에 유휴 상태인 코드의 진행 중인 인스턴스를 배치하는 대신, 서버리스는 필요에 따라 코드를 가져와서 수요 변동에 따라 이를 확장/축소한 후 미사용 시에는 해당 코드를 제거합니다. 서버리스는 컴퓨팅 용량과 전력의 낭비를 방지하고, 실제 실행 중일 때만 코드 실행 비용을 지불하므로 비용을 절감합니다.

Knative를 사용하여 개발자는 컨테이너를 한 번만 빌드하고 이를 소프트웨어 서비스 또는 서버리스 기능으로 실행할 수 있습니다. 이는 개발자에게 투명합니다. Knative은 백그라운드에서 세부사항을 처리하며, 개발자는 코드에 집중할 수 있습니다.

컨테이너 개발 및 오케스트레이션을 간소화하는 Knative

개발자의 경우 코드의 컨테이너화는 수많은 반복 단계가 필요하며, 컨테이너의 오케스트레이션은 수많은 구성 및 스크립팅(예: 구성 파일 생성, 종속 항목 설치, 로깅 및 추적 관리 그리고 CI/CD(Continuous Integration/Continuous Deployment) 스크립트 작성)을 필요로 합니다.

Knative는 세 개의 컴포넌트를 통해 자동화함으로써 이러한 태스크를 보다 손쉽게 만듭니다.

  • Build: Knative의 Build 컴포넌트는 소스 코드를 클라우드 네이티브 컨테이너 또는 함수로 자동 변환합니다. 특히 이는 저장소에서 코드를 가져와서 필수 종속 항목을 설치하고 컨테이너 이미지를 구축한 후 다른 개발자가 사용할 수 있도록 이를 컨테이너 레지스트리에 넣습니다. 개발자는 Knative가 찾을 수 있도록 이러한 컴포넌트의 위치를 지정해야 하지만, 일단 작업이 완료되면 Knative는 빌드를 자동화합니다.
  • Serve: Serve 컴포넌트는 컨테이너를 확장형 서비스로 실행합니다. 이는 수천 개의 컨테이너 인스턴스로 확장하거나 "제로"(0으로 스케일링)로 축소할 수 있습니다. 또한 Serve에는 두 가지 매우 유용한 기능이 있습니다.
    • 구성 - 이는 프로덕션으로 컨테이너를 푸시할 때마다 컨테이너 버전(스냅샷이라고 함)을 저장합니다. 그리고 사용자가 해당 버전을 동시에 실행할 수 있도록 합니다.
    • 서비스 라우팅 - 다양한 양의 트래픽을 이러한 버전에 라우팅할 수 있도록 합니다. 이러한 기능을 함께 사용함으로써 글로벌 프로덕션에 두기 전에 컨테이너 롤아웃을 점진적으로 단계화하거나 컨테이너화된 애플리케이션의 카나리아 테스트를 스테이징할 수 있습니다.
  • Event: Event는 지정된 이벤트가 컨테이너 기반 서비스 또는 기능을 트리거하도록 해줍니다. 이는 특히 Knative의 서버리스 기능에 필수적이며, 무언가는 필요할 때 기능을 가져오도록 시스템에 전해야 합니다. 이벤트를 통해 팀들은 이벤트의 유형에 관심을 표현할 수 있으며, 이는 다시 자동으로 이벤트 생성자에 연결하고 이벤트를 컨테이너에 라우팅함으로써 이러한 연결을 프로그래밍해야 할 필요성을 제거합니다.

"Knative: 기본 안내서"를 읽고 Knative에 대해 자세히 알아볼 수 있습니다.

Kubernetes GitHub 커미트와 인기

Kubernetes는 역사상 가장 빠르게 성장하는 오픈 소스 프로젝트 중 하나이며 성장이 가속화되고 있습니다. 개발자와 이를 채택하는 회사들 간에 계속해서 선정이 늘어나고 있습니다. 주목할 만한 몇 가지 데이터 포인트는 다음과 같습니다.

  • 이 글을 작성하는 시점에, 지난 4개월 간의 거의 6,000건의 커미트를 포함하여 GitHub의 Kubernetes 저장소(IBM 내부 링크)에 대해 작성된 86,200건 이상의 커미트가 있었으며, 프로젝트에 대한 2,300명 이상의 적극적인 기여자가 있습니다. Cloud Native Computing Foundation(IBM 내부 링크)에 따르면, 모든 Kubernetes 관련 저장소(Kubernetes Dashboard 및 Kubernetes MiniKube 포함)에서 148,000건 이상의 커미트가 있었습니다.
  • 1,500개 이상의 기업들이 자체 프로덕션 소프트웨어 스택에서 Kubernetes를 사용하고 있습니다. 여기에는 AirBnB, Bose, CapitalOne, Intuit, Nordstrom, Philips, Reddit, Slack, Spotify, Tinder 및 IBM 등을 포함하여 전세계의 유명 기업들이 포함되어 있습니다. 이와 함께 기타 채택 사례 연구 읽기(IBM 외부 링크)를 참조하세요.
  •  컨테이너 저널(IBM 외부 링크)에서 인용한 2019년 7월 설문조사에 따르면 지난 6개월 동안 Kubernetes 채택이 51% 증가했습니다.
  • 12,000명이 넘는 사람들이 KubeCon + CloudNative Con North America 2019(IBM 외부 링크) 컨퍼런스에 참석했으며, 이는 전년도 참석자들 수의 최고 기록보다 3,000명 이상이 늘어난 수치입니다.
  • ZipRecruiter(IBM 외부 링크)에 따르면, Kubernetes 관련 직종의 평균 연봉(북미 지역)은 USD 144,628입니다.이 글을 작성하는 시점에, 현재 21,000개 이상의 Kubernetes 관련 자리가 LinkedIn(IBM 외부 링크)에 나열되어 있습니다.

Kubernetes 학습서

Kubernetes 관련 작업을 시작하거나 Kubernetes 및 Kubernetes 에코시스템 툴을 사용하여 스킬을 구축할 준비가 되면 다음 튜토리얼 중 하나를 실행해 보세요.

Kubernetes 및 IBM Cloud

관리형 컨테이너 오케스트레이션 솔루션인 IBM Cloud® Kubernetes Service는 IBM 특화 기능에 추가하여 컴퓨팅 호스트의 클러스터에서 컨테이너화된 앱의 배치, 조작, 스케일링 및 모니터링을 자동화합니다. 이로써 애플리케이션의 신속한 딜리버리가 가능하며, 블록체인IBM® Watson 등의 고급 서비스에 바인딩이 가능합니다.

클라우드 여정에서 관리형 Kubernetes 서비스의 유용성을 간략하게 살펴보려면 "관리형 Kubernetes의 장점" 동영상(03:14)을 시청하세요.

Red Hat® OpenShift® on IBM Cloud는 IBM Cloud 플랫폼에서 완전 관리형 OpenShift 클러스터를 제공하는 포괄적 서비스입니다. (OpenShift는 Red Hat Enterprise Linux에서 실행되는 엔터프라이즈 Kubernetes 플랫폼입니다.)

새로 발간된 Forrester Wave: Multicloud Container Development Platforms 보고서(PDF, 415KB)에서 OpenShift와 관련된 자세한 내용을 읽어보세요.

시작하려면 IBM ID에 등록하고 IBM Cloud 계정을 작성하세요.