Kubernetes
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.
Kubernetes 환경 최적화 IBM 뉴스레터 구독하기
검정 및 파랑 배경
쿠버네티스란 무엇인가요?

'k8s' 또는 'kube'라고도 하는 Kubernetes는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 예약하고 자동화하기 위한 컨테이너 오케스트레이션 플랫폼입니다.

Kubernetes는 2014년에 오픈소스화되기 전에 Google의 엔지니어들이 처음 개발했습니다. Google 내부에서 사용되는 컨테이너 오케스트레이션 플랫폼인 Borg의 후속 제품입니다. Kubernetes는 그리스어로 조타수 또는 조종사를 의미하며, 그래서 Kubernetes 로고에 조타기가 있는 것입니다(ibm.com 외부 링크).

오늘날 Kubernetes와 더 광범위한 컨테이너 에코시스템은 현대 클라우드 인프라 및 애플리케이션의 기본 구성 요소인 가상 머신(VM)을 능가하지는 않더라도 이에 필적하는 범용 컴퓨팅 플랫폼 및 에코시스템으로 성숙하고 있습니다. 이 에코시스템을 통해 조직은 클라우드 네이티브 개발을 위한 여러 인프라 관련 및 운영 관련 작업과 문제를 해결하는 높은 생산성의 서비스형 플랫폼(PaaS)을 구현하여 개발 팀이 코딩과 혁신에만 집중할 수 있도록 지원합니다.     

다음 동영상은 Kubernetes 기본 사항에 대한 소개를 제공합니다.

애플리케이션 기반 컨테이너 탄력성 자동화

애플리케이션 성능을 보장하면서 시장 출시 속도를 높이려는 플랫폼 및 DevOps 엔지니어에게 적합합니다.

컨테이너란 무엇인가요?

컨테이너는 애플리케이션 소스 코드와 모든 환경에서 코드를 실행하는 데 필요한 모든 운영 체제(OS) 라이브러리 및 종속성을 결합하는 경량의 실행 가능한 애플리케이션 구성 요소입니다.

컨테이너는 프로세스를 격리하고 해당 프로세스가 액세스할 수 있는 CPU, 메모리, 디스크의 양을 제어하여 여러 애플리케이션이 단일 OS 인스턴스를 공유할 수 있도록 하는 운영 체제(OS) 가상화의 한 형태를 활용합니다. 컨테이너는 가상 머신(VM)보다 더 작고 리소스 측면에서 효율적이며 휴대성이 뛰어나기 때문에 최신 클라우드 네이티브 애플리케이션의 사실상의 컴퓨팅 단위로 자리 잡았습니다. 

최근 IBM에서 실시한 연구에서 사용자들은 컨테이너 및 관련 기술을 도입함으로써 얻은 몇 가지 구체적인 기술적, 비즈니스적 이점을 보고했습니다. 

컨테이너와 가상 머신, 기존 인프라의 비교

IT 인프라 자동화 및 추상화 연속체의 최신 지점으로 컨테이너를 이해하는 것이 더 쉽고 도움이 될 수 있습니다.

기존 인프라에서 애플리케이션은 물리적 서버에서 실행되며 얻을 수 있는 모든 리소스를 가져옵니다. 따라서 단일 서버에서 여러 애플리케이션을 실행하면서 한 애플리케이션이 다른 애플리케이션의 리소스를 차지하지 않기를 바라거나, 애플리케이션당 하나의 서버를 전용으로 사용하면서 리소스를 낭비하고 확장하지 않는 방법을 선택할 수 있습니다.

가상 머신(VM)은 실제 컴퓨터 하드웨어에서 추상화된 서버로, 하나의 물리적 서버에서 여러 개의 VM을 실행하거나 두 개 이상의 물리적 서버에 걸쳐 있는 단일 VM을 실행할 수 있습니다. 각 가상 머신은 자체 OS 인스턴스를 실행하며, 각 애플리케이션을 자체 가상 머신에 격리하여 동일한 기본 물리적 하드웨어에서 실행되는 애플리케이션이 서로 영향을 미칠 가능성을 줄일 수 있습니다. VM은 리소스를 더 잘 활용하고 기존 인프라보다 확장이 훨씬 쉽고 비용 효율적입니다. 그리고 일회용입니다. 더 이상 애플리케이션을 실행할 필요가 없으면 VM을 종료합니다.

VM에 관한 더 자세한 내용은 '가상 머신이란 무엇인가요?'에서 확인하세요.

컨테이너는 이러한 추상화를 더 높은 수준으로 끌어올려, 기본 가상화 하드웨어를 공유할 뿐 아니라 기본 가상화 OS 커널도 공유합니다. 컨테이너는 VM과 동일한 격리, 확장성, 처분성을 제공하지만, 자체 OS 인스턴스의 페이로드를 가지고 있지 않기 때문에 VM보다 더 가볍습니다(공간을 덜 차지함). 더 적은 수의 머신(가상 및 물리적)에서 더 적은 수의 OS 인스턴스로 더 많은 애플리케이션을 실행할 수 있어 리소스 효율성이 높습니다. 컨테이너는 데스크톱, 데이터 센터, 클라우드 환경 전반에서 더 쉽게 이동할 수 있습니다. 그리고 애자일 및 DevOps 개발 방식에 매우 적합합니다.

'컨테이너란 무엇인가요?'에서는 컨테이너 및 컨테이너화에 대한 자세한 설명을 살펴볼 수 있습니다. 그리고 블로그 게시물 '컨테이너와 VM: 차이점은 무엇인가요?'에서는 차이점에 대한 전체 개요를 제시합니다.

Docker란?

Docker는 Linux® 컨테이너를 생성하고 실행하는 데 가장 많이 사용되는 툴입니다. 초기 형태의 컨테이너는 수십 년 전에 도입되었지만(FreeBSD Jails 및 AIX 워크로드 파티션과 같은 기술로), 컨테이너는 2013년에 Docker가 개발자 친화적이고 클라우드 친화적인 새로운 구현을 통해 대중에게 제공하면서 대중화되었습니다.

Docker는 오픈 소스 프로젝트로 시작되었지만, 오늘날에는 오픈 소스 프로젝트를 기반으로 하는 (그리고 개선 사항을 오픈 소스 커뮤니티에 다시 기여하는) 상용 컨테이너 툴킷인 Docker를 생산하는 회사인 Docker Inc.를 지칭하기도 합니다.

Docker는 기존 Linux 컨테이너(LXC) 기술을 기반으로 구축되었지만 Linux 커널 프로세스를 더욱 세밀하게 가상화할 수 있으며, 개발자가 컨테이너를 더욱 쉽게 구축, 배포, 관리 및 보호할 수 있는 기능을 추가합니다.

오늘날 대체 컨테이너 플랫폼이 존재하지만(예: OCI(오픈 컨테이너 이니셔티브), CoreOS, Canonical(Ubuntu) LXD), Docker는 컨테이너와 사실상 동의어라고 할 정도로 널리 선호되고 있으며, 때때로 Kubernetes와 같은 보완 기술의 경쟁자로 오인되기도 합니다(아래 'Kubernetes와 Docker: 양자택일의 문제가 아닙니다' 도영상 참고).

Kubernetes를 사용한 컨테이너 오케스트레이션

컨테이너가 확산됨에 따라(오늘날에는 한 조직에 수백, 수천 개의 컨테이너가 있을 수 있음) 운영팀은 컨테이너 배포, 네트워킹, 확장성, 가용성을 예약하고 자동화해야 했습니다. 그렇게 컨테이너 오케스트레이션 시장이 탄생했습니다.

다른 컨테이너 오케스트레이션 옵션, 특히 Docker Swarm과 Apache Mesos가 초기에 어느 정도 주목을 받았지만, Kubernetes는 빠르게 가장 널리 채택되었습니다(실제로 한 때는 오픈 소스 소프트웨어 역사상 가장 빠르게 성장하는 프로젝트이기도 했습니다).

개발자들은 Kubernetes의 광범위한 기능, 방대하고 성장하는 오픈 소스 지원 툴 에코시스템, 클라우드 서비스 제공업체 전반에 걸친 지원 및 이동성 때문에 Kubernetes를 선택했고 앞으로도 계속 선택할 것입니다. Amazon Web Services(AWS), Google Cloud, IBM Cloud, Microsoft Azure를 비롯한 모든 주요 퍼블릭 클라우드 제공업체는 풀 매니지드 Kubernetes 서비스를 제공합니다.

Kubernetes는 어떤 기능을 하나요?

Kubernetes는 다음을 포함하여 애플리케이션 라이프사이클 전반에 걸쳐 컨테이너 관련 작업을 예약하고 자동화합니다.

  • 배포: 지정된 수의 컨테이너를 지정된 호스트에 배포하고 원하는 상태로 계속 실행할 수 있습니다.

  • 롤아웃: 롤아웃은 배포를 변경하는 것입니다. Kubernetes를 사용하면 롤아웃을 시작, 일시 중지, 재개 또는 롤백할 수 있습니다.

  • 서비스 검색: Kubernetes는 DNS 이름 또는 IP 주소를 사용하여 컨테이너를 인터넷이나 다른 컨테이너에 자동으로 노출할 수 있다.

  • 스토리지 프로비저닝: 필요에 따라 컨테이너에 대한 영구 로컬 또는 클라우드 스토리지를 마운트하도록 Kubernetes를 설정합니다.

  • 로드 밸런싱: Kubernetes 로드 밸런싱은 CPU 사용률 또는 사용자 지정 메트릭을 기반으로 네트워크 전체에 워크로드를 분산하여 성능과 안정성을 유지할 수 있습니다. 

  • 오토스케일링: 트래픽이 급증하면 Kubernetes 자동 확장은 필요에 따라 새 클러스터를 스핀업하여 추가 워크로드를 처리할 수 있습니다.

  • 고가용성을 위한 자가 치료: 컨테이너에 장애가 발생하면 Kubernetes는 자동으로 컨테이너를 재시작하거나 교체하여 중단 시간을 방지할 수 있습니다. 또한 상태 확인 요구 사항을 충족하지 않는 컨테이너를 삭제할 수도 있습니다.

Kubernetes와 Docker 비교

여기까지 읽으셨다면, Kubernetes가 Docker Swarm의 대안이기는 하지만 (대중의 지속적인 오해와는 달리) Docker 자체의 대안이나 경쟁자가 아니라는 점을 이미 이해하셨을 것입니다.

실제로 Docker를 열정적으로 도입하여 대규모 Docker 기반 컨테이너 배포를 생성하고 있다면, 이러한 워크로드를 관리하기 위한 논리적 다음 단계로 Kubernetes 오케스트레이션을 고려할 수 있습니다.

더 자세히 알아보려면 'Kubernetes와 Docker: 양자택일의 문제가 아닙니다'를 시청하세요.

Kubernetes 아키텍처

Kubernetes 아키텍처의 주요 구성 요소는 다음과 같습니다.

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

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

각 클러스터는 클러스터의 제어 계획 역할을 하는 마스터 노드컨테이너화된 애플리케이션을 배포, 실행 및 관리하는 여러 작업자 노드로 구성됩니다. 마스터 노드는 개발자가 설정한 배포 요구 사항과 사용 가능한 컴퓨팅 용량에 따라 컨테이너를 배포하는 시기와 위치를 자동화하는 스케줄러 서비스를 실행합니다. 각 작업자 노드에는 컨테이너를 관리하는 데 사용되는 툴(예: Docker)과 마스터 노드로부터 명령을 수신하고 실행하는 Kubelet이라는 소프트웨어 에이전트가 포함됩니다.

개발자는 Kubernetes API와 직접 통신하는 명령줄 인터페이스(cli)인 kubectl을 사용하여 클러스터 작업을 관리합니다. 

Kubernetes 클러스터에 대해 더 자세히 알아보려면 'Kubernetes 클러스터: 신속하고 통제된 클라우드 앱 제공을 위한 아키텍처'를 읽어보세요.

팟 및 배포(소프트웨어)

은 동일한 컴퓨팅 리소스와 동일한 네트워크를 공유하는 컨테이너 그룹이며 Kubernetes의 확장성 단위이기도 합니다. 팟의 컨테이너가 처리할 수 있는 것보다 더 많은 트래픽을 받는 경우, Kubernetes는 팟을 클러스터의 다른 노드에 복제합니다.따라서 리소스를 공유해야 하는 컨테이너만 포함되도록 팟을 컴팩트하게 유지하는 것이 좋습니다.

배포는 컨테이너화된 애플리케이션의 생성과 상태를 제어하고 이를 계속 실행합니다. 클러스터에서 실행해야 하는 팟의 복제본 수를 지정합니다. 팟이 실패하면 배포가 새 팟을 생성합니다.

Kubernetes 배포에 대한 자세한 내용은 'Kubernetes 배포: 빠르게 시작하기'에서 확인하세요.

Istio 서비스 메시

Kubernetes는 포드를 배포하고 확장할 수 있지만 포드 간의 라우팅을 관리하거나 자동화할 수 없으며 이러한 연결을 모니터링, 보호 또는 디버깅하는 툴을 제공하지 않습니다. 클러스터의 컨테이너 수가 증가함에 따라 컨테이너 간에 가능한 연결 경로의 수가 기하급수적으로 증가(예를 들어, 컨테이너 2개는 2개의 잠재적 연결이 있지만 10개 팟은 90개)하여 구성 및 관리가 상당히 복잡해질 수 있습니다.

Kubernetes 클러스터를 위한 오픈 소스 서비스 메시 레이어인 Istio를 소개합니다. Istio는 각 Kubernetes 클러스터에 기본적으로 프로그래머와 관리자에게 보이지 않는 사이드카 컨테이너를 추가하여 다른 컨테이너 간의 상호 작용을 구성, 모니터링 및 관리합니다.

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

또한 Istio는 개발자 팀과 관리자가 대기 시간, 서비스 중 오류 및 컨테이너 간 연결의 기타 특성을 모니터링하는 데 사용할 수 있는 대시보드를 제공합니다. 또한 보안, 특히 권한이 없는 사용자가 컨테이너 간 서비스 호출을 스푸핑하는 것을 방지하는 ID 관리와 보안 전문가가 클러스터를 모니터링하는 데 사용할 수 있는 인증, 권한 부여 및 감사(AAA) 기능이 내장되어 있습니다.

Istio에 대해 자세히 알아보기
Knative 및 서버리스 컴퓨팅

Knative('kay-native(케이네이티브)'로 발음)는 Kubernetes 위에 위치하며 클라우드 네이티브 개발에 두 가지 중요한 이점을 제공하는 오픈 소스 플랫폼입니다.

서버리스 컴퓨팅으로의 쉬운 진입을 제공하는 Knative

서버리스 컴퓨팅은 클라우드 네이티브 애플리케이션을 더 효율적이고 비용 효율적으로 만드는 비교적 새로운 코드 배포 방법입니다. 요청을 기다리는 동안 유휴 상태로 유지되는 코드의 지속적인 인스턴스를 배포하는 대신, 서버리스는 필요에 따라 코드를 불러와 수요 변동에 따라 크기를 늘리거나 줄인 다음 사용하지 않을 때는 코드를 중단합니다. 서버리스는 코드가 실제로 실행될 때만 비용을 지불하므로 컴퓨팅 용량과 전력 낭비를 방지하고 비용을 절감합니다.

Knative를 사용하면 개발자가 일단 컨테이너를 구축하고 소프트웨어 서비스 또는 서버리스 기능으로 실행할 수 있습니다. 개발자에게는 모든 것이 투명합니다. Knative는 백그라운드에서 세부 사항을 처리하므로 개발자는 코드에 집중할 수 있습니다.

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

개발자의 경우 코드를 컨테이너화하려면 많은 반복 단계가 필요하고 컨테이너를 오케스트레이션하려면 많은 구성 및 스크립팅(예: 구성 파일 생성, 종속성 설치, 로깅 및 추적 관리, 지속적 통합/지속적 배포(CI/CD) 스크립트 작성)이 필요합니다.

Knative는 세 가지 구성 요소를 통해 이러한 작업을 자동화하여 더 쉽게 수행할 수 있도록 지원합니다:

구축: Knative의 구축 구성 요소는 소스 코드를 클라우드 네이티브 컨테이너 또는 함수로 자동 변환합니다. 구체적으로 리포지토리에서 코드를 가져오고, 필요한 종속 요소를 설치하고, 컨테이너 이미지를 구축하고, 다른 개발자가 사용할 수 있도록 컨테이너 레지스트리에 넣습니다. 개발자는 이러한 컴포넌트의 위치를 지정해야 Knative가 해당 컴포넌트를 찾을 수 있지만, 일단 지정이 완료되면 Knative가 구축을 자동화합니다.

서비스 제공: 서비스 제공 구성 요소는 컨테이너를 확장 가능한 서비스로 실행하며, 컨테이너 인스턴스를 수천 개까지 확장하거나 전혀 없는 상태로 축소할 수 있습니다(0으로 규모 축소). 또한, 컨테이너를 프로덕션 환경으로 푸시할 때마다 컨테이너 버전(스냅샷이라고 함)을 저장하고 해당 버전을 동시에 실행할 수 있는 구성과, 이러한 버전으로 다양한 트래픽을 보낼 수 있는 서비스 라우팅이라는 매우 유용한 두 가지 기능이 있습니다. 이러한 기능을 함께 사용하여 컨테이너 롤아웃을 점진적으로 단계적으로 진행하거나 컨테이너화된 애플리케이션을 글로벌 프로덕션에 적용하기 전에 카나리아 테스트를 단계적으로 진행할 수 있습니다.

이벤트: 이벤트는 지정된 이벤트가 컨테이너 기반 서비스 또는 함수를 트리거할 수 있도록 합니다. 이는 특히 Knative의 서버리스 기능에 필수적입니다. 필요할 때 기능을 불러오도록 시스템에 지시해야 합니다. 이벤트는 팀이 이벤트 유형에 대한 관심을 표현하면 자동으로 이벤트 프로듀서에 연결하여 이벤트를 컨테이너로 라우팅하므로 이러한 연결을 프로그래밍할 필요가 없습니다.

Knative에 대해 자세히 알아보기
Kubernetes GitHub 커밋과 급증하는 인기의 증거

Kubernetes는 역사상 가장 빠르게 성장하는 오픈 소스 프로젝트 중 하나이며 성장이 가속화되고 있습니다. 개발자와 개발자를 고용하는 회사 사이에서 도입이 계속 급증하고 있습니다. 주목할 가치가 있는 몇 가지 데이터 포인트는 다음과 같습니다.

  • 이 글을 쓰는 시점 기준으로 GitHub의 Kubernetes 리포지토리(ibm.com 외부 링크)에 120,190건 이상의 커밋이 이루어졌으며, 이는 지난 18개월 동안 거의 3만 4,000건의 커밋이 증가한 수치이며, 이 프로젝트에는 3,100명 이상의 적극적인 기여자가 있습니다. 클라우드 네이티브 컴퓨팅 재단(CNCF)에 따르면, 모든 Kubernetes 관련 리포지토리(Kubernetes 대시보드 및 Kubernetes MiniKube 포함)에서 14만 8,000개 이상의 커밋이 있었습니다. 여기에서 모든 통계 데이터를 확인할 수 있습니다(ibm.com 외부 링크).

  • 2,000개 이상의 기업이 프로덕션 소프트웨어 스택에서 Kubernetes를 사용하고 있습니다. 여기에는 AirBnB, Ancestry, Bose, CapitalOne, Intuit, Nordstrom, Philips, Reddit, Slack, Spotify, Tinder, 그리고 물론 IBM과 같은 세계적으로 유명한 기업들이 포함됩니다. 이 사례와 다른 도입 사례 연구(ibm.com 외부 링크)를 확인해 보세요.

  • Container Journal에 인용된 2021년 설문조사(ibm.com 외부 링크)에 따르면, IT 전문가의 68%가 코로나19 팬데믹 기간 동안 Kubernetes의 사용을 늘린 것으로 나타났습니다.

  • ZipRecruiter(ibm.com 외부 링크)에 따르면, Kubernetes 관련 직종의 평균 연봉(북미 기준)은 14만 7,732달러입니다. 이 글을 쓰는 시점 기준으로 LinkedIn에는 5만 7,000개 이상의 구인 정보가 등록되어 있으며(ibm.com 외부 링크), 이는 불과 18개월 전의 2만 1,000개에 비해 크게 증가한 수치입니다.
관련 솔루션
Red Hat OpenShift on IBM Cloud

Red Hat OpenShift on IBM Cloud를 통해 OpenShift 개발자는 빠르고 안전하게 엔터프라이즈 워크로드를 컨테이너화하여 Kubernetes 클러스터에 배포할 수 있습니다.

Red Hat OpenShift 살펴보기
IBM Cloud Satellite

툴체인, 데이터베이스 및 AI를 포함한 공통 클라우드 서비스 세트를 사용하여 모든 클라우드 공급업체의 온프레미스, 엣지 컴퓨팅 및 퍼블릭 클라우드 환경에서 일관되게 앱을 배포하고 실행하세요.

IBM Cloud Satellite 솔루션 살펴보기
IBM Cloud Code Engine

완전 관리형 서버리스 플랫폼인 IBM Cloud Code Engine은 컨테이너, 애플리케이션 코드 또는 일괄 처리 작업을 완전 관리형 컨테이너 런타임에서 실행할 수 있게 해줍니다.

Code Engine 살펴보기
자원 엔터프라이즈의 컨테이너

IBM의 새로운 연구 결과는 컨테이너 및 Kubernetes 도입의 급증하는 모멘텀을 보여 줍니다.

하이브리드 클라우드를 위한 유연성, 복원력, 보안성을 갖춘 IT

컨테이너는 어디서나 워크로드를 구축하고 관리할 수 있게 해주는 하이브리드 클라우드 전략의 일환입니다.

서버리스란 무엇인가요?

서버리스는 개발자가 서버를 관리하거나 유휴 클라우드 인프라에 대한 비용을 지불하지 않고도 코드를 빌드하고 실행할 수 있게 해 주는 클라우드 애플리케이션 개발 및 실행 모델입니다.

Kubernetes에서의 YAML 기본 사항

Kubernetes에서 YAML 파일이 어떻게 사용되는지 예시를 살펴보세요.

다음 단계 안내

Red Hat OpenShift on IBM Cloud를 통해 OpenShift 개발자는 빠르고 안전하게 엔터프라이즈 워크로드를 컨테이너화하여 Kubernetes 클러스터에 배포할 수 있습니다. 클릭 한 번만으로 컨테이너화된 애플리케이션을 위한 높은 가용성의 풀 매니지드 Kubernetes 클러스터를 배포하세요. IBM이 OCP(OpenShift Container Platform)를 관리하므로 핵심 작업에 더 많은 시간을 집중할 수 있습니다.

Red Hat OpenShift on IBM Cloud 살펴보기