쿠버네티스(Kubernetes) 핵심 정리
쿠버네티스는 컨테이너가 많아지는 순간부터 거의 필수처럼 등장하는 도구다.
아래 내용은 “도커는 알겠는데, 쿠버네티스는 뭐가 다른지, 구조가 어떻게 생겼는지”를 빠르게 정리한 요약본이다.
1. 쿠버네티스란 무엇인가
1-1. 정의
-
쿠버네티스(Kubernetes, K8s)
컨테이너의 배포, 스케일링, 장애 복구, 롤링 업데이트 등을 자동화해 주는 컨테이너 오케스트레이션 도구 -
구글 내부의 Borg 시스템을 바탕으로 만들어졌고, 지금은 CNCF(Cloud Native Computing Foundation)에서 관리
-
목표
- 컨테이너화된 애플리케이션을 쉽고 안정적으로 배포
- 무중단 서비스, 자동 복구, 수평 확장, 높은 가용성 보장
컨테이너 오케스트레이션
여러 개의 컨테이너를 “시스템 단위”로 묶어서 배치·관리·감시하는 것
컨테이너 생성/삭제/스케일링을 사람이 직접 관리하지 않도록 자동화하는 도구
1-2. 쿠버네티스가 등장한 배경
-
2013년 도커 등장 이후 대부분의 서비스에서 컨테이너 도입
-
컨테이너 수가 늘어나면서 다음 문제가 생김
- 인스턴스 상태 관리가 복잡해짐
- 자동 배포, 자동 복구, 스케일링 도구 필요
-
이 요구를 해결하기 위해 쿠버네티스가 등장
- 2015년 첫 버전 공개
- 현재는 사실상 컨테이너 오케스트레이션 표준
1-3. 도커 컴포즈 vs 쿠버네티스
도커 컴포즈
- 여러 컨테이너를 한 번에 올리고 내리는 데 적합
- 스케일 조정도 수동으로 직접
docker-compose up --scale같은 식으로 관리 - “원하는 상태를 계속 유지”해 주지 않음 → 사람이 직접 상태 맞춰줘야 함
쿠버네티스
-
yaml(매니페스트)에 “바람직한 상태(Desired State)”를 정해두면- 파드가 죽으면 자동으로 새 파드 생성
- 설정한 레플리카 수와 실제 상태가 다르면 자동으로 맞춰 줌
-
상태 저장은 etcd라는 키-값 DB에 기록
-
컨테이너에 문제가 생겼을 때
- 컨테이너를 직접 삭제하는 게 아니라
- 매니페스트에서 “원하는 상태”를 수정하는 방식으로 관리
요약하면
도커 컴포즈는 “여러 컨테이너를 한 번에 띄우는 도구”
쿠버네티스는 “컨테이너 클러스터 전체 상태를 계속 감시하고, 원하는 상태로 맞춰 주는 시스템”
2. 쿠버네티스 클러스터 구조
2-1. 클러스터란
-
여러 개의 서버(노드)가 모여 하나의 시스템처럼 동작하는 단위
-
쿠버네티스 클러스터는 두 종류의 노드로 구성
- 마스터 노드(컨트롤 플레인)
- 워커 노드(실제 애플리케이션 실행)
관리자는 주로 마스터 노드에 설정을 넣고, 워커 노드는 거의 직접 건드리지 않는다.
워커 관리, 파드 배치, 복구 등은 클러스터가 알아서 처리한다.
2-2. 마스터 노드(컨트롤 플레인)
컨테이너를 직접 실행하지 않고, 클러스터 전체를 “조종”하는 노드
-
특징
- 클러스터 상태를 etcd에 저장
- 어떤 파드를 어느 워커 노드에 띄울지 결정
- 클러스터 전반의 라이프사이클 관리
- 관리자는 로컬에
kubectl을 설치해 마스터에 명령 전달
-
주요 컴포넌트
| 컴포넌트 | 역할 |
|---|---|
| kube-apiserver | 모든 요청의 입구. kubectl과 통신하는 쿠버네티스 API 서버 |
| etcd | 클러스터 상태를 저장하는 키-값 DB |
| kube-scheduler | 어떤 파드를 어느 워커 노드에 배치할지 결정 |
| kube-controller-manager | 여러 컨트롤러들을 통합 실행 (노드 관리, 레플리카 수 보장 등) |
| cloud-controller-manager | AWS, GCP 같은 클라우드 서비스와 연동 (로드밸런서, 노드 관리 등) |
2-3. 워커 노드
실제 컨테이너(파드)가 실행되는 노드
-
특징
- 최소 1개 이상 필요
- 도커 같은 컨테이너 런타임이 설치되어 있어야 함
- 파드들이 이 워커 노드에서 돌아간다
-
주요 컴포넌트
| 컴포넌트 | 역할 |
|---|---|
| kubelet | 각 노드에서 돌아가는 에이전트. 마스터와 통신하며 파드를 생성·관리 |
| kube-proxy | 서비스 개념을 구현하는 네트워크 프록시. 트래픽을 적절한 파드로 라우팅 |
3. 쿠버네티스 핵심 리소스
3-1. 파드(Pod)
-
쿠버네티스에서 컨테이너를 다루는 최소 단위
-
구성
- 하나 이상의 컨테이너
- 볼륨 등 스토리지 설정
-
보통 “파드 1개 = 컨테이너 1개”로 쓰지만
사이드카 패턴처럼 여러 컨테이너를 하나의 파드에 넣을 수도 있다.
3-2. 디플로이먼트(Deployment)와 레플리카셋(ReplicaSet)
-
ReplicaSet
- “동일한 파드가 몇 개 떠 있어야 하는가?”를 관리
- 실제로 파드를 생성·삭제하면서 레플리카 수를 맞춘다.
-
Deployment
-
ReplicaSet을 감싸고 있는 상위 개념
-
롤링 업데이트, 롤백, 의도한 상태 관리의 중심
-
디플로이먼트 기준으로 선언해 두면
- 내부에서 ReplicaSet과 Pod를 자동으로 관리
-
현업에서는 거의 항상 Deployment 단위로 정의한다.
ReplicaSet만 따로 직접 다루는 경우는 드물다.
3-3. 서비스(Service)
-
여러 파드를 하나의 엔드포인트로 묶어 주는 리소스
-
역할
- 같은 역할을 하는 파드들을 하나의 “서비스”로 묶기
- 서비스에 고정 IP(ClusterIP)를 부여
- 외부/내부에서 이 IP로 접근하면, 서비스가 적절한 파드로 트래픽 분배
- 내부 로드밸런서 역할
주의할 점
-
서비스는 클러스터 내부(노드 간, 파드 간)에서의 트래픽 분배에 집중
-
클러스터 밖에서 들어오는 요청은
- 실제 클라우드 로드밸런서
- 또는 Ingress가 담당
3-4. 구성 요소 정리
| 리소스 | 역할 |
|---|---|
| Pod | 컨테이너 + 볼륨을 묶은 실행 단위 |
| Service | 여러 파드에 대한 트래픽 분배, 고정 IP 제공 |
| Deployment | 파드 배포, 롤링 업데이트, ReplicaSet 관리 |
| ReplicaSet | 레플리카(파드 개수) 유지 |
4. 매니페스트(Manifest)
4-1. 매니페스트란
-
쿠버네티스 리소스를 정의하는 설정 파일
-
형식: 주로 YAML (JSON도 가능하지만 사람이 보기 불편)
-
대상
- Pod, Service, Deployment, ReplicaSet 등
-
보통
- Deployment만 정의하면 그 안에서 ReplicaSet과 Pod가 함께 설정
- Pod/ReplicaSet만 따로 직접 쓰는 것은 권장되지 않음
(쿠버네티스의 “바람직한 상태 유지” 기능을 온전히 활용하기 어렵다)
4-2. 기본 매니페스트 구조
apiVersion: # API 그룹 및 버전
kind: # 리소스 타입 (Deployment, Service, Pod 등)
metadata: # 이름, 라벨 등 메타데이터
spec: # 실제 동작을 정의하는 설정예를 들어, Deployment라면 spec 안에
파드 템플릿, 레플리카 수, 컨테이너 이미지 등을 정의한다.
4-3. 자주 쓰는 리소스의 apiVersion / kind
최신 버전 기준으로 자주 쓰는 조합은 다음과 같다.
| 리소스 | apiVersion | kind |
|---|---|---|
| Pod | v1 (core/v1) | Pod |
| Service | v1 (core/v1) | Service |
| Deployment | apps/v1 | Deployment |
| ReplicaSet | apps/v1 | ReplicaSet |
실제 클러스터의 지원 버전은
kubectl api-resources명령으로 확인할 수 있다.
정리
-
쿠버네티스는 “컨테이너를 많이 쓰는 환경에서, 사람 대신 상태를 유지해 주는 시스템”
-
핵심 키워드
- 클러스터: 마스터 + 워커 노드
- 파드: 컨테이너 실행 단위
- 디플로이먼트: 파드/ReplicaSet를 선언적으로 관리
- 서비스: 파드 트래픽 분배, 고정 IP 제공
- 매니페스트: 원하는 상태를 정의해 두는 YAML 파일
-
도커 컴포즈와의 가장 큰 차이점은
단순히 “컨테이너를 올리는 도구”를 넘어, 클러스터 전체를 계속 감시하면서 설정한 바람직한 상태를 자동으로 유지한다는 점이다.
