개요

개요 (Overview)

이 페이지는 Kubernetes에 대한 개요예요.

Kubernetes라는 이름은 그리스어에서 유래했으며 "키잡이(helmsman)" 또는 "조종사(pilot)"를 뜻해요. K8s라는 약어는 "K"와 "s" 사이의 여덟 글자를 세어 만든 것이에요. Google은 2014년에 Kubernetes 프로젝트를 오픈 소스로 공개했어요. Kubernetes는 규모에 맞춰 프로덕션 워크로드를 실행해 온 15년 이상의 Google 경험과 커뮤니티의 모범 아이디어·실천을 결합했어요.

출처: 문서

본문

왜 Kubernetes가 필요한가, 무엇을 할 수 있나

컨테이너는 애플리케이션을 번들링(bundle)하고 실행하기 좋은 방법이에요. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 다운타임이 없도록 보장해야 해요. 예를 들어 컨테이너가 다운되면 다른 컨테이너가 시작되어야 해요. 이런 동작을 시스템이 처리해 준다면 훨씬 편하지 않을까요?

바로 그게 Kubernetes가 구원해 주는 부분이에요! Kubernetes는 분산 시스템을 복원력 있게 실행하기 위한 프레임워크를 제공해요. 애플리케이션의 확장과 장애 조치(failover)를 처리하고, 배포 패턴 등을 제공해요. 예를 들어 Kubernetes는 시스템의 카나리(canary) 배포도 쉽게 관리할 수 있어요.

Kubernetes가 제공하는 것들:

  • 서비스 디스커버리와 로드밸런싱 — Kubernetes는 컨테이너를 DNS 이름이나 자체 IP 주소로 노출할 수 있어요. 컨테이너에 대한 트래픽이 많으면 Kubernetes가 로드밸런싱하고 네트워크 트래픽을 분산해서 배포가 안정적으로 유지되게 해요.
  • 스토리지 오케스트레이션 — Kubernetes는 로컬 스토리지, 퍼블릭 클라우드 프로바이더 등 선택한 스토리지 시스템을 자동으로 마운트하게 해줘요.
  • 자동화된 롤아웃과 롤백 — Kubernetes로 배포된 컨테이너의 원하는 상태를 설명하고, 실제 상태를 통제된 속도로 원하는 상태로 바꿀 수 있어요. 예를 들어 배포를 위해 새 컨테이너를 만들고, 기존 컨테이너를 제거하고 그 리소스를 새 컨테이너에 옮기도록 자동화할 수 있어요.
  • 자동 빈 패킹 (Automatic bin packing) — Kubernetes에 컨테이너화된 작업을 실행하는 데 사용할 노드 클러스터를 제공해요. 각 컨테이너가 필요한 CPU와 메모리를 알려주면, Kubernetes는 리소스를 가장 잘 활용하도록 컨테이너를 노드에 맞춰 배치할 수 있어요.
  • 자기 치유 (Self-healing) — Kubernetes는 실패한 컨테이너를 재시작하고, 컨테이너를 대체하며, 사용자 정의 상태 확인에 응답하지 않는 컨테이너를 죽이고, 서비스를 제공할 준비가 되기 전까지 클라이언트에 광고하지 않아요.
  • 시크릿과 구성 관리 — Kubernetes는 비밀번호, OAuth 토큰, SSH 키 같은 민감 정보를 저장·관리하게 해줘요. 컨테이너 이미지를 다시 빌드하지 않고, 스택 구성에 시크릿을 노출하지 않으면서 시크릿과 애플리케이션 구성을 배포·업데이트할 수 있어요.
  • 배치 실행 (Batch execution) — 서비스 외에도 Kubernetes는 배치와 CI 워크로드를 관리하고, 원한다면 실패한 컨테이너를 대체할 수 있어요.
  • 수평 확장 (Horizontal scaling) — 간단한 명령, UI, 또는 CPU 사용량 기반으로 자동으로 애플리케이션을 확장·축소할 수 있어요.
  • IPv4/IPv6 이중 스택 — 파드와 서비스에 IPv4와 IPv6 주소를 할당해요.
  • 확장성을 위해 설계 — 업스트림 소스 코드를 변경하지 않고 Kubernetes 클러스터에 기능을 추가해요.

Kubernetes가 아닌 것

Kubernetes는 전통적인 종합(all-inclusive) PaaS(Platform as a Service) 시스템이 아니에요. Kubernetes는 하드웨어 수준이 아니라 컨테이너 수준에서 동작하므로, 배포·확장·로드밸런싱 같은 PaaS 제공물에 흔한 일반적으로 적용 가능한 기능을 일부 제공하고, 사용자가 로깅·모니터링·알림 솔루션을 통합하게 해줘요. 하지만 Kubernetes는 모놀리식이 아니며, 이런 기본 솔루션들은 선택 사항이고 플러그인이 가능해요. Kubernetes는 개발자 플랫폼을 구축하기 위한 빌딩 블록을 제공하지만, 중요한 곳에서는 사용자의 선택과 유연성을 보존해요.

Kubernetes는:

  • 지원하는 애플리케이션 유형을 제한하지 않아요. Kubernetes는 무상태(stateless), 유상태(stateful), 데이터 처리 워크로드를 포함한 극도로 다양한 워크로드를 지원하는 것을 목표로 해요. 애플리케이션을 컨테이너에서 실행할 수 있다면 Kubernetes에서도 잘 실행되어야 해요.
  • 소스 코드를 배포하지 않고 애플리케이션을 빌드하지 않아요. CI/CD(지속적 통합·전달·배포) 워크플로는 조직 문화와 선호, 그리고 기술적 요구 사항에 따라 결정돼요.
  • 미들웨어(예: 메시지 버스), 데이터 처리 프레임워크(예: Spark), 데이터베이스(예: MySQL), 캐시, 클러스터 스토리지 시스템(예: Ceph) 같은 애플리케이션 수준 서비스를 내장 서비스로 제공하지 않아요. 이런 컴포넌트는 Kubernetes에서 실행될 수 있고/또는 Open Service Broker 같은 이식 가능한 메커니즘을 통해 Kubernetes에서 실행되는 애플리케이션이 접근할 수 있어요.
  • 로깅, 모니터링, 알림 솔루션을 강요하지 않아요. 개념 증명으로 일부 통합을 제공하고, 메트릭을 수집·내보낼 메커니즘을 제공해요.
  • 구성 언어/시스템(예: Jsonnet)을 제공하거나 요구하지 않아요. 임의 형태의 선언적 사양이 대상이 될 수 있는 선언적 API를 제공해요.
  • 포괄적인 머신 구성, 유지보수, 관리, 자기 치유 시스템을 제공하지도 채택하지도 않아요.
  • 게다가 Kubernetes는 단순한 오케스트레이션 시스템도 아니에요. 사실 오케스트레이션의 필요성을 없애요. 오케스트레이션의 기술적 정의는 정의된 워크플로의 실행, 즉 A를 하고 다음에 B, 그다음 C를 하는 것이에요. 대조적으로 Kubernetes는 현재 상태를 제공된 원하는 상태로 지속적으로 끌어가는 독립적이고 조합 가능한 일련의 제어 프로세스로 구성돼요. A에서 C로 가는 방법은 중요하지 않아요. 중앙 집중식 제어도 필요 없어요. 그 결과 더 사용하기 쉽고, 더 강력하고 견고하며 복원력 있고 확장 가능한 시스템이 돼요.

Kubernetes의 역사적 배경

왜 Kubernetes가 그렇게 유용한지 시간을 거슬러 살펴볼게요.

전통적 배포 시대 (Traditional deployment era)

초기에는 조직이 물리 서버에서 애플리케이션을 실행했어요. 물리 서버에서는 애플리케이션에 대한 리소스 경계를 정의할 방법이 없어서 리소스 할당 문제가 생겼어요. 예를 들어 물리 서버에서 여러 애플리케이션을 실행하면, 어떤 애플리케이션이 리소스 대부분을 차지해 다른 애플리케이션의 성능이 저하되는 경우가 생길 수 있었어요. 해결책은 각 애플리케이션을 서로 다른 물리 서버에서 실행하는 것이었지만, 리소스가 충분히 활용되지 않아 확장이 어려웠고, 조직이 많은 물리 서버를 유지하는 데 비용이 많이 들었어요.

가상화 배포 시대 (Virtualized deployment era)

해결책으로 가상화가 도입되었어요. 가상화는 단일 물리 서버의 CPU에서 여러 가상 머신(VM)을 실행하게 해줘요. 가상화는 VM 간에 애플리케이션을 격리하고, 한 애플리케이션의 정보를 다른 애플리케이션이 자유롭게 접근할 수 없게 하는 보안 수준을 제공해요.

가상화는 물리 서버의 리소스 활용을 개선하고, 애플리케이션을 쉽게 추가·업데이트할 수 있어 확장성을 좋게 하며, 하드웨어 비용을 줄이고 그 밖의 많은 이점을 제공해요. 가상화로 물리 리소스 집합을 일회용 가상 머신 클러스터로 제시할 수 있어요.

각 VM은 가상화된 하드웨어 위에서 자체 운영체제를 포함한 모든 컴포넌트를 실행하는 완전한 머신이에요.

컨테이너 배포 시대 (Container deployment era)

컨테이너는 VM과 비슷하지만, 애플리케이션 간에 운영체제(OS)를 공유하도록 완화된 격리 특성을 가져요. 그래서 컨테이너는 가볍다고 여겨져요. VM과 비슷하게 컨테이너는 자체 파일시스템, CPU·메모리·프로세스 공간 몫 등을 가져요. 기반 인프라스트럭처에서 분리되어 있어 클라우드와 OS 배포판을 가로질러 이식 가능해요.

컨테이너는 추가 이점을 제공해 인기를 얻었어요.

  • 민첩한 애플리케이션 생성·배포: VM 이미지 사용에 비해 컨테이너 이미지 생성이 더 쉽고 효율적
  • 지속적 개발·통합·배포: 빠르고 효율적인 롤백(이미지 불변성 덕분)으로 컨테이너 이미지 빌드·배포를 안정적이고 자주
  • 개발과 운영의 관심사 분리: 빌드/릴리스 시점이 아닌 배포 시점에 애플리케이션 컨테이너 이미지를 만들어 애플리케이션을 인프라스트럭처에서 분리
  • 관찰성(Observability): OS 수준 정보·메트릭뿐 아니라 애플리케이션 상태와 다른 신호까지 표면화
  • 개발·테스트·프로덕션 간 환경 일관성: 노트북에서나 클라우드에서나 똑같이 실행
  • 클라우드 및 OS 배포판 이식성: Ubuntu, RHEL, CoreOS, 온프레미스, 주요 퍼블릭 클라우드 등 어디서든 실행
  • 애플리케이션 중심 관리: 가상 하드웨어에서 OS를 실행하는 것에서, 논리적 리소스를 사용해 OS 위에서 애플리케이션을 실행하는 것으로 추상화 수준을 높임
  • 느슨하게 결합된 분산·탄력적·자유로운 마이크로서비스: 애플리케이션을 더 작고 독립적인 조각으로 나누고 동적으로 배포·관리
  • 리소스 격리: 예측 가능한 애플리케이션 성능
  • 리소스 활용: 높은 효율과 밀도

다음 단계

더 알아보기 (Learn more)