Kubernetes 개요

이 페이지는 Kubernetes의 개요입니다.

Kubernetes라는 이름은 그리스어에서 유래되었으며, 조타수나 파일럿을 의미합니다. K8s라는 약어는 “K”와 “s” 사이의 8개 글자를 센 결과입니다. Google은 2014년에 Kubernetes 프로젝트를 오픈소스로 공개했습니다. Kubernetes는 프로덕션 워크로드를 대규모로 실행한 Google의 15년 이상의 경험과 커뮤니티의 최고 아이디어 및 모범 사례를 결합합니다.

Kubernetes가 필요한 이유와 할 수 있는 일

컨테이너는 애플리케이션을 번들링하고 실행하는 좋은 방법입니다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 다운타임이 없도록 보장해야 합니다. 예를 들어, 컨테이너가 다운되면 다른 컨테이너가 시작되어야 합니다. 이러한 동작을 시스템이 처리해 준다면 더 쉽지 않을까요?

바로 이런 상황에서 Kubernetes가 도움이 됩니다! Kubernetes는 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공합니다. 애플리케이션의 스케일링과 장애 조치를 처리하고, 배포 패턴을 제공하며, 그 외에도 많은 기능을 제공합니다. 예를 들어, Kubernetes는 시스템에 대한 카나리 배포를 쉽게 관리할 수 있습니다.

Kubernetes가 제공하는 기능:

  • 서비스 디스커버리와 로드 밸런싱: Kubernetes는 DNS 이름이나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있습니다. 컨테이너에 대한 트래픽이 높으면, Kubernetes는 네트워크 트래픽을 로드 밸런싱하고 분산하여 배포가 안정적으로 유지되도록 할 수 있습니다.

  • 스토리지 오케스트레이션: Kubernetes를 사용하면 로컬 스토리지, 퍼블릭 클라우드 제공업체 등 원하는 스토리지 시스템을 자동으로 마운트할 수 있습니다.

  • 자동화된 롤아웃과 롤백: Kubernetes를 사용하여 배포된 컨테이너의 원하는 상태를 설명할 수 있으며, 실제 상태를 제어된 속도로 원하는 상태로 변경할 수 있습니다. 예를 들어, Kubernetes가 배포용 새 컨테이너를 생성하고, 기존 컨테이너를 제거하며, 모든 리소스를 새 컨테이너로 채택하도록 자동화할 수 있습니다.

  • 자동 빈 패킹: 컨테이너화된 작업을 실행하는 데 사용할 수 있는 노드 클러스터를 Kubernetes에 제공합니다. 각 컨테이너에 필요한 CPU와 메모리(RAM) 양을 Kubernetes에 알려주면, Kubernetes가 리소스를 최대한 활용할 수 있도록 노드에 컨테이너를 배치할 수 있습니다.

  • 자가 치유: Kubernetes는 실패한 컨테이너를 재시작하고, 컨테이너를 교체하며, 사용자 정의 상태 확인에 응답하지 않는 컨테이너를 종료하고, 서비스할 준비가 될 때까지 클라이언트에 알리지 않습니다.

  • 시크릿과 구성 관리: Kubernetes를 사용하면 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하고 관리할 수 있습니다. 컨테이너 이미지를 재빌드하지 않고도 시크릿과 애플리케이션 구성을 배포하고 업데이트할 수 있으며, 스택 구성에서 시크릿을 노출하지 않습니다.

  • 배치 실행: 서비스 외에도, Kubernetes는 배치 및 CI 워크로드를 관리할 수 있으며, 원할 경우 실패한 컨테이너를 교체할 수 있습니다.

  • 수평 확장: 간단한 명령, UI 또는 CPU 사용량을 기반으로 자동으로 애플리케이션을 확장하거나 축소할 수 있습니다.

  • IPv4/IPv6 듀얼 스택: Pod와 Service에 IPv4 및 IPv6 주소 할당

  • 확장성을 위한 설계: 업스트림 소스 코드를 변경하지 않고도 Kubernetes 클러스터에 기능을 추가할 수 있습니다.

Kubernetes가 아닌 것

Kubernetes는 기존의 모든 것을 포함하는 PaaS(Platform as a Service) 시스템이 아닙니다. Kubernetes는 하드웨어 수준이 아닌 컨테이너 수준에서 작동하므로, 배포, 스케일링, 로드 밸런싱과 같은 PaaS 제품에 공통적인 일반적으로 적용 가능한 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있게 합니다. 하지만 Kubernetes는 모놀리식이 아니며, 이러한 기본 솔루션은 선택 사항이고 플러그인 방식입니다. Kubernetes는 개발자 플랫폼을 구축하기 위한 빌딩 블록을 제공하지만, 중요한 부분에서는 사용자의 선택과 유연성을 보존합니다.

Kubernetes는:

  • 지원하는 애플리케이션 유형을 제한하지 않습니다: Kubernetes는 상태 없는 워크로드, 상태 있는 워크로드, 데이터 처리 워크로드를 포함하여 극도로 다양한 워크로드를 지원하는 것을 목표로 합니다. 애플리케이션이 컨테이너에서 실행될 수 있다면, Kubernetes에서 잘 실행되어야 합니다.

  • 소스 코드를 배포하지 않고 애플리케이션을 빌드하지 않습니다: CI/CD(지속적 통합, 배포 및 배치) 워크플로는 조직 문화와 선호도뿐만 아니라 기술적 요구사항에 의해 결정됩니다.

  • 미들웨어(예: 메시지 버스), 데이터 처리 프레임워크(예: Spark), 데이터베이스(예: MySQL), 캐시, 클러스터 스토리지 시스템(예: Ceph)과 같은 애플리케이션 수준 서비스를 내장 서비스로 제공하지 않습니다: 이러한 구성 요소는 Kubernetes에서 실행될 수 있으며, Open Service Broker와 같은 포터블 메커니즘을 통해 Kubernetes에서 실행되는 애플리케이션에서 액세스할 수 있습니다.

  • 로깅, 모니터링 또는 알림 솔루션을 지시하지 않습니다: 개념 증명으로서의 일부 통합과 메트릭을 수집하고 내보내는 메커니즘을 제공합니다.

  • 구성 언어/시스템(예: Jsonnet)을 제공하거나 요구하지 않습니다: 임의 형태의 선언적 사양에 의해 대상이 될 수 있는 선언적 API를 제공합니다.

  • 포괄적인 머신 구성, 유지 관리, 관리 또는 자가 치유 시스템을 제공하거나 채택하지 않습니다.

  • 추가로, Kubernetes는 단순한 오케스트레이션 시스템이 아닙니다: 사실, 오케스트레이션의 필요성을 제거합니다. 오케스트레이션의 기술적 정의는 정의된 워크플로의 실행입니다: 먼저 A를 수행하고, 그 다음 B를, 그 다음 C를 수행합니다. 반대로, Kubernetes는 제공된 원하는 상태로 현재 상태를 지속적으로 추진하는 독립적이고 구성 가능한 제어 프로세스 집합으로 구성됩니다. A에서 C로 가는 방법은 중요하지 않습니다. 중앙 집중식 제어도 필요하지 않습니다. 이로 인해 사용하기 더 쉽고 더 강력하고, 견고하며, 탄력적이고 확장 가능한 시스템이 만들어집니다.

Kubernetes의 역사적 맥락

시간을 거슬러 올라가서 Kubernetes가 왜 그렇게 유용한지 살펴보겠습니다.

전통적 배포 시대:

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

가상화 배포 시대:

해결책으로 가상화가 도입되었습니다. 단일 물리 서버의 CPU에서 여러 가상 머신(VM)을 실행할 수 있게 해줍니다. 가상화를 통해 애플리케이션을 VM 간에 격리할 수 있고, 한 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로 보안 수준을 제공합니다.

가상화를 통해 물리 서버의 리소스를 더 잘 활용할 수 있고, 애플리케이션을 쉽게 추가하거나 업데이트할 수 있어 더 나은 확장성을 제공하며, 하드웨어 비용을 줄이는 등 많은 이점이 있습니다. 가상화를 통해 물리 리소스 집합을 일회용 가상 머신 클러스터로 제시할 수 있습니다.

각 VM은 가상화된 하드웨어 위에서 자체 운영 체제를 포함한 모든 구성 요소를 실행하는 완전한 머신입니다.

컨테이너 배포 시대:

컨테이너는 VM과 유사하지만, 애플리케이션 간에 운영 체제(OS)를 공유하기 위해 격리 속성이 완화되었습니다. 따라서 컨테이너는 경량으로 간주됩니다. VM과 마찬가지로, 컨테이너는 자체 파일 시스템, CPU 공유, 메모리, 프로세스 공간 등을 가지고 있습니다. 기본 인프라에서 분리되어 있어서 클라우드와 OS 배포판 간에 이식 가능합니다.

컨테이너는 다음과 같은 추가적인 이점을 제공하기 때문에 인기가 높아졌습니다:

  • 민첩한 애플리케이션 생성 및 배포: VM 이미지 사용에 비해 컨테이너 이미지 생성의 용이성과 효율성이 증가합니다.

  • 지속적인 개발, 통합 및 배포: (이미지 불변성으로 인한) 빠르고 효율적인 롤백과 함께 신뢰할 수 있고 빈번한 컨테이너 이미지 빌드 및 배포를 제공합니다.

  • 개발과 운영의 관심사 분리: 배포 시간이 아닌 빌드/릴리스 시간에 애플리케이션 컨테이너 이미지를 생성하여 애플리케이션을 인프라에서 분리합니다.

  • 관찰 가능성: OS 수준 정보와 메트릭뿐만 아니라 애플리케이션 상태 및 기타 신호도 표시합니다.

  • 개발, 테스트 및 프로덕션 환경의 일관성: 랩톱에서 실행되는 것과 클라우드에서 실행되는 것이 동일합니다.

  • 클라우드 및 OS 배포 이식성: Ubuntu, RHEL, CoreOS, 온프레미스, 주요 퍼블릭 클라우드 및 기타 모든 곳에서 실행됩니다.

  • 애플리케이션 중심 관리: 가상 하드웨어에서 OS를 실행하는 것에서 논리적 리소스를 사용하여 OS에서 애플리케이션을 실행하는 것으로 추상화 수준을 높입니다.

  • 느슨하게 결합되고, 분산되며, 탄력적이고, 해방된 마이크로서비스: 애플리케이션이 더 작고 독립적인 조각으로 나뉘며 동적으로 배포 및 관리될 수 있습니다 – 하나의 큰 단일 목적 머신에서 실행되는 모놀리식 스택이 아닙니다.

  • 리소스 격리: 예측 가능한 애플리케이션 성능.

  • 리소스 활용: 높은 효율성과 밀도.

Kubernetes 구성 요소

이 페이지는 Kubernetes 클러스터를 구성하는 필수 구성 요소에 대한 고수준 개요를 제공합니다.

쿠버네티스 클러스터의 구성요소

Kubernetes 클러스터의 구성 요소

핵심 구성 요소

Kubernetes 클러스터는 컨트롤 플레인과 하나 이상의 워커 노드로 구성됩니다. 주요 구성 요소에 대한 간략한 개요는 다음과 같습니다:

컨트롤 플레인 구성 요소

클러스터의 전체 상태를 관리합니다:

  • kube-apiserver - Kubernetes HTTP API를 노출하는 핵심 구성 요소 서버입니다.

  • etcd - 모든 API 서버 데이터를 위한 일관되고 고가용성을 갖춘 키-값 저장소입니다.

  • kube-scheduler - 아직 노드에 바인딩되지 않은 Pod를 찾아서 각 Pod를 적절한 노드에 할당합니다.

  • kube-controller-manager - Kubernetes API 동작을 구현하기 위해 controllers를 실행합니다.

  • cloud-controller-manager (선택사항) - 기반 클라우드 제공업체와 통합합니다.

노드 구성 요소

모든 노드에서 실행되어 실행 중인 파드를 유지하고 Kubernetes 런타임 환경을 제공합니다:

  • kubelet - 컨테이너를 포함한 Pod가 실행되도록 보장합니다.

  • kube-proxy (선택사항) - Services를 구현하기 위해 노드에서 네트워크 규칙을 유지합니다.

  • Container runtime - 컨테이너 실행을 담당하는 소프트웨어입니다. 자세한 내용은 Container Runtimes를 참조하세요.

추가 정보

클러스터에서 각 노드에 추가 소프트웨어가 필요할 수 있습니다. 예를 들어, Linux 노드에서 로컬 구성 요소를 감독하기 위해 systemd를 실행할 수도 있습니다.

애드온

애드온은 Kubernetes의 기능을 확장합니다. 몇 가지 중요한 예는 다음과 같습니다:

  • DNS - 클러스터 전체 DNS 해석을 위한 구성 요소입니다.

  • Web UI (Dashboard) - 웹 인터페이스를 통한 클러스터 관리를 위한 구성 요소입니다.

  • Container Resource Monitoring - 컨테이너 메트릭을 수집하고 저장하기 위한 구성 요소입니다.

  • Cluster-level Logging - 컨테이너 로그를 중앙 로그 저장소에 저장하기 위한 구성 요소입니다.

아키텍처의 유연성

Kubernetes는 이러한 구성 요소가 배포되고 관리되는 방식에서 유연성을 허용합니다. 아키텍처는 소규모 개발 환경부터 대규모 프로덕션 배포까지 다양한 요구사항에 맞게 조정될 수 있습니다.

각 구성 요소와 클러스터 아키텍처를 구성하는 다양한 방법에 대한 자세한 정보는 클러스터 아키텍처 페이지를 참조하세요.

출처

Kubernetes 공식 문서

Kubernetes 공식 문서