1. Kubernetes
구글은 2000년대 초부터 리눅스 커널 기능인 cgroups(Control Groups), nameSpace를 이용해 커널 레벨에서 리소스와 프로세스를 격리하는 자체 컨테이너 기술을 사용해왔다. 이후 2000년대 중반 구글은 도커 공개 전에도 해당 자체 컨테이너 기술을 기반으로 Borg 라는 대규모 클러스터 관리 시스템을 개발해, 애플리케이션을 배포, 실행, 관리해왔다.
그러나 Borg는 중앙 집중형 아키텍처로 인해 유연성에 한계가 있었고, 이를 보완하기 위해 구글은 분산형 스케줄링 아키텍처를 적용한 Omega라는 새로운 시스템을 개발했다. Omega는 여러 스케줄러가 동시에 동작하면서도 충돌을 해결할 수 있는 구조로, 보다 유연하고 확장성 높은 클러스터 관리를 가능하게 했다.
2013년 도커가 공개되며 이미지 포맷과 도구를 갖춘 표준화된 컨테이너를 활용한 애플리케이션 배포가 대중화되었다. 구글은 기존의 Borg 와 Omega 시스템을 기반으로 더 가볍고 오픈 커뮤니티 친화적인 형태로 재설계한 컨테이너 오케스트레이션 플랫폼인 쿠버네티스를 오픈소스로 공개했다.
쿠버네티스는 그리스어로 `배를 조종하는 사람(조타수)`을 뜻하며, 흔히 첫 글자인 k와 끝 글자인 s 사이의 8글자를 줄여 k8s 혹은 앞의 4글자를 따서 kube라고 부른다. 쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 운영할 수 있게 지원하며, 고가용성(High Availability)과 내결함성(Fault Tolerance)을 통해 서비스의 안정성과 운영 편의성을 높여준다.
구분 | Borg | Omega | Kubernetes |
개발 시기 | 2004년 ~ 2005년 | 2011년경 | 2014년 (오픈소스 공개) |
주요 목표 | 대규모 클러스터 통합 관리 | 유연성과 확장성 강화 | 오픈 커뮤니티용 범용 오케스트레이션 |
아키텍처 형태 | 중앙 집중형 (Monolithic) | 분산형 (Shared State) | 분산형 (Controller 기반) |
스케줄링 방식 | 단일 스케줄러, 엄격한 제어 | 다중 스케줄러, 낙관적 동시성 제어 | 다중 컨트롤러, 선언적 상태 관리 |
유연성 | 낮음 (고정된 시스템) | 높음 (여러 워크로드 지원) | 매우 높음 (Custom Resource 지원 등) |
사용 대상 | 구글 내부 전용 | 구글 내부 전용 | 전 세계 (오픈소스) |
컨테이너 기술 | 자체 격리 기술 (cgroups, namespace 기반) | 자체 격리 기술 + 분산 스케줄링 | 표준화된 컨테이너 (Docker, containerd 등) |
특징 요약 | 대규모 안정성 | 유연성과 확장성 강화 | 대중적 컨테이너 관리 표준 |
2. 고가용성 HA(High Availability)
고가용성이란, 일부 장애나 실패 상황에서도 전체 시스템이 지속적으로 서비스를 제공할 수 있도록 하는 것을 의미한다. 쿠버네티스는 다음 기능들을 통해 고가용성을 지원한다.
- Pod 복제(ReplicaSet): 여러 개의 Pod 인스턴스를 만들어 서비스 중단 없이 운영.
- Service와 로드밸런싱: 살아있는 Pod로 트래픽을 자동 분산시켜 요청을 안정적으로 처리.
- Control Plane 다중화: API 서버, etcd 등을 다중화하여 클러스터 자체가 장애에 강하도록 구성.
3. 내결함성 FT (Fault Tolerance)
내결함성이란, 일부 컴포넌트가 실패하더라도 전체 시스템이 정상적으로 작동을 유지할 수 있도록 하는 것을 의미한다. 쿠버네티스는 다음 기능들을 통해 내결함성을 확보한다.
- 헬스 체크(Liveness Probe, Readiness Probe): Pod 상태를 지속적으로 모니터링하고 비정상 Pod를 자동으로 복구하거나 제외.
- 셀프힐링(Self-Healing): 장애가 발생한 컨테이너나 노드를 감지하고, 자동으로 재시작하거나 다른 노드에 새로운 인스턴스를 생성.
- Pod 분산 배치(Anti-Affinity): 중요한 애플리케이션 복제본을 서로 다른 노드에 배치하여 단일 장애 지점을 방지.
4. 쿠버네티스 아키텍처
쿠버네티스는 크게 Control Plane(클러스터 전체 관리)과 Worker Node(실제 애플리케이션 실행)로 구성된다.
Control Plane은 클러스터의 상태를 관리하고, 스케줄링과 노드 관리를 담당하며, Worker Node는 실제로 컨테이너화된 애플리케이션(Pod)을 실행하는 역할을 한다.
Control Plane 구성요소
- API Server
클러스터의 모든 요청을 받아들이는 진입 지점.
사용자는 kubectl이나 다른 클라이언트를 통해 API Server에 명령을 보내게 된다. - etcd
쿠버네티스의 모든 상태 정보(클러스터 상태, 오브젝트 정보 등)를 저장하는 분산 키-값 저장소. - Scheduler
새로운 Pod이 생성되었을 때, 이를 어떤 Node에 배치할지 결정하는 컴포넌트. - Controller Manager
다양한 컨트롤러(예: ReplicaSet Controller, Node Controller 등)를 통합 관리하고 클러스터 상태를 원하는 상태로 유지하는 역할을 한다.
Worker Node 구성요소
- Kubelet
각 노드에서 실행되며, 컨테이너가 정상적으로 동작하는지 모니터링하고, API Server의 명령을 수행한다. - Kube-Proxy
클러스터 내부 네트워크 통신을 담당하며, 서비스와 Pod 간 로드밸런싱 역할을 한다. - Container Runtime
실제로 컨테이너를 실행하는 엔진. 예를 들어 Docker, containerd 등이 있다.
Kubernetes 리소스 개요
- Pod: 쿠버네티스에서 가장 작은 배포 단위. 하나 이상의 컨테이너를 감쌀 수 있다.
- Deployment: Pod의 생성과 업데이트를 관리하는 오브젝트.
- Service: 여러 Pod를 하나의 네트워크 엔드포인트로 묶어주는 오브젝트.
'Kubernetes > Common' 카테고리의 다른 글
[Kubernetes] Common - 3. Configmap & Secret (1) | 2025.05.01 |
---|---|
[Kubernetes] Common - 2. Pod & ReplicaSet & Deployment (0) | 2025.04.29 |