Kubernetes 개념편: 쿠버네티스의 구조와 동작 원리

1. Kubernetes 전체 구조 훑어보기

Kubernetes를 처음 접하면 Pod, Deployment, Service, Ingress 같은 용어들이 한꺼번에 등장한다. 그런데 세부 개념을 이해하기 전에 먼저 전체 구조를 보는 것이 훨씬 중요하다.

Kubernetes는 한 문장으로 이렇게 정리할 수 있다.

여러 서버에 분산된 컨테이너들을 하나의 클러스터로 관리하고, 그 실행과 확장, 복구를 자동화하는 플랫폼이다.

1) Kubernetes는 클러스터 단위로 동작한다

Kubernetes는 단일 서버를 관리하는 도구가 아니다. 기본적으로 클러스터(Cluster)라는 단위로 동작한다.

클러스터는 여러 대의 서버를 하나의 묶음으로 구성한 운영 환경이다.

즉, 컨테이너 하나를 실행하는 도구가 아니라 여러 서버에 분산된 컨테이너들을 통합 관리하는 플랫폼이다.

2) 노드: 실제로 컨테이너가 실행되는 곳

클러스터 안에는 여러 개의 노드(Node)가 있다.

노드는 실제로 컨테이너가 실행되는 서버다. 물리 서버일 수도 있고, 클라우드의 가상 머신일 수도 있다.

Kubernetes는 어떤 노드에 어떤 컨테이너를 배치할지 자동으로 결정한다.

3) 제어 영역과 실행 영역

Kubernetes 구조를 단순화하면 두 개의 영역으로 나눌 수 있다.

제어 영역(Control Plane): 전체 상태를 관리하고, 어떤 컨테이너를 몇 개 실행할지 결정하며, 문제가 생기면 다시 실행하도록 지시한다.
실행 영역(Worker Node): 실제로 컨테이너가 실행되는 공간이다.

쉽게 말해 제어 영역이 "계획"을 세우고, 실행 영역이 "실행"을 담당한다.

Cluster
├── Control Plane (제어 영역)
│   ├── kube-apiserver  — 모든 요청의 진입점
│   ├── etcd            — 클러스터 상태 저장소
│   └── scheduler       — 어떤 노드에 배치할지 결정
└── Worker Node 1, Node 2, ... (실행 영역)
    └── 컨테이너(Pod)가 실제로 동작

4) Kubernetes의 핵심 특징

Kubernetes는 단순히 실행만 하는 시스템이 아니다.

예를 들어, 아래와 같이 운영 기준을 설정해둘 수 있다.

user-service는 항상 3개 유지 → 하나가 죽으면 자동으로 다시 실행
트래픽이 급증하면 설정에 따라 Pod 개수를 자동으로 늘려 부하를 분산 (Auto Scaling)
노드 자체에 장애가 생기면 다른 노드로 컨테이너를 자동 이전

이렇게 설정해두면 컨테이너가 죽더라도 Kubernetes가 자동으로 다시 실행한다.

즉, 사용자가 정해둔 운영 기준을 Kubernetes가 지속적으로 유지해준다.

5) 전체 그림 정리

클러스터: 전체 운영 공간
노드: 컨테이너가 실행되는 서버
제어 영역(Control Plane): 운영을 관리
실행 영역(Worker Node): 실제로 동작

이 구조 위에서 Pod, Deployment, Service, Ingress가 동작한다.

전체 그림을 잡았다면, 이제 가장 기본 단위부터 뜯어보자.

2. Pod: Kubernetes의 최소 실행 단위

Kubernetes에서 가장 먼저 이해해야 할 개념은 Pod이다. Pod은 하나 이상의 컨테이너를 담는 실행 단위다. 하지만 실무에서는 대부분 1 Pod = 1 컨테이너 로 이해하면 충분하다.

개념	설명	비유
Cluster	전체 운영 공간	공장 단지 전체
Node	컨테이너가 실행되는 서버	개별 공장 건물
Pod	컨테이너 실행 단위	생산 라인 한 세트
Container	실제로 동작하는 프로세스	생산 라인의 기계

3. Deployment: Pod의 개수와 상태를 유지하는 관리자

"Pod이 죽으면 누가 다시 만들어 주지?" , "Pod를 항상 3개 유지하려면 어떻게 하지?"

Pod 자체는 그냥 실행 단위일 뿐이다. 스스로를 유지하지는 못하는데 여기서 등장하는 게 Deployment다.

replicas: 3 # Pod 3개 생성, 하나 죽으면 새로 생성, 개수가 부족하면 다시 맞춤

Deployment가 실질적으로 하는 일은 세 가지다.

자동 복구: Pod이 죽으면 즉시 다시 생성한다.
복제 관리: 선언한 개수(replicas)를 항상 유지한다.
무중단 배포: 새 버전 배포 시 Pod를 하나씩 교체하며, 문제가 생기면 이전 버전으로 롤백한다.

특히 무중단 배포는 실무에서 가장 체감이 큰 기능이다. 배포 중에도 서비스가 끊기지 않는다.

4. Service: Pod에 안정적으로 접근하기

Service는 기본적으로 ClusterIP라는 내부 전용 주소를 생성한다. 이 부분은 실제 동작 구조를 바로 보는게 이해하기 쉽다.

Deployment가 Pod 3개를 생성하면, Service는 그 Pod들을 하나의 진입점으로 묶는다.

클라이언트
    │
    ▼
Service (member-service)   ← 고정된 접근 주소
    │
    ├──▶ Pod A
    ├──▶ Pod B
    └──▶ Pod C

클라이언트는 Pod에 직접 요청하지 않는다. Service로 요청하면, Service가 내부적으로 3개의 Pod 중 하나를 선택해서 전달한다.

Pod이 죽고 새로 생성되더라도 클라이언트 입장에서는 항상 같은 주소로 요청하면 된다. 이것이 Service가 존재하는 핵심 이유다.

5. Ingress: 외부 트래픽이 들어오는 관문

Ingress는 클러스터 외부에서 들어오는 요청을 적절한 Service로 연결해주는 입구다.

Service만으로는 외부에서 직접 접근하기 어렵다. Ingress는 도메인과 경로를 기준으로 요청을 적절한 Service로 라우팅한다.

외부 클라이언트
    │
    ▼
Ingress
    ├──▶ /api/member  →  member-service
    ├──▶ /api/order   →  order-service
    └──▶ /api/product →  product-service

예를 들어 example.com/api/member로 요청이 들어오면 Ingress가 이를 member-service로 전달한다. 각 Service가 별도의 포트나 IP를 노출하지 않아도 되기 때문에, 외부 접근을 한 곳에서 통합 관리할 수 있다.

Service와 Ingress의 차이

항목	Service	Ingress
역할	Pod 집합에 대한 고정된 내부 접근 지점 제공	외부 요청을 Service로 라우팅
접근 범위	클러스터 내부	클러스터 외부
트래픽 처리	여러 Pod 중 하나로 로드밸런싱	도메인/경로 기반 라우팅

6. 정리

지금까지 개별 개념을 살펴봤다.

Pod — 실행 단위
Deployment — Pod 상태 유지
Service — Pod 고정 접근 주소
Ingress — 외부 요청 라우팅

개념을 아는 것과 직접 실행해보는 것은 다르다. 눈으로 확인했을 때 비로소 제대로 이해된다.

목차