Kubernetes란 무엇인가

1. 문제 / 필요성

• 컨테이너 기반으로 서비스를 구성하면 실행 환경은 표준화된다. 하지만 운영 단계에서는 오히려 관리 대상이 늘어난다.

실제로 다음과 같은 문제가 반복된다.

• 여러 서버에 컨테이너를 어떻게 배치할지 결정해야 함
• 특정 서버 장애 시 컨테이너가 함께 종료됨
• 트래픽 변화에 따라 컨테이너 수를 늘리거나 줄여야 함
• 배포 중 일부 실패 시 롤백 기준이 필요함
• 현재 전체 서비스 상태를 한 번에 파악하기 어려움

이 문제들의 공통점은 하나다.

컨테이너 “실행”이 아니라, 전체 “상태”를 관리해야 한다는 점

---

2. Kubernetes 전체 구조

Kubernetes는 단순 실행 도구가 아니라 클러스터 단위로 동작하는 시스템이다.

 

 

구조는 크게 두 영역으로 나뉜다.

• Control Plane: 상태를 기준으로 판단
• Worker Node: 실제로 컨테이너 실행

전체 동작 흐름

Kubernetes는 아래 흐름으로 동작한다.

1. 사용자가 원하는 상태 정의 (YAML)
2. API Server에 상태 저장
3. Scheduler가 실행 위치 결정
4. Worker Node에서 컨테이너 실행
5. Controller가 상태를 지속적으로 비교
6. 차이가 발생하면 자동으로 수정

Kubernetes는 “결정”과 “실행”을 분리한 시스템이다

---

3. Kubernetes란

• Kubernetes는 컨테이너로 구성된 애플리케이션을 정의(Define), 배치(Schedule), 실행(Execute), 유지(Maintain) 하는 컨테이너 오케스트레이션 도구다. 
• 여기서 오케스트레이션이란 여러 컨테이너를 개별적으로 실행하는 것이 아니라 전체 흐름과 상태를 기준으로 조율하는 것을 의미한다.

여기서 중요한 것은 “실행”이 아니라 “유지”다.

• 몇 개를 실행할지
• 어디서 실행할지
• 실패하면 어떻게 복구할지

이 모든 것을 포함해 전체 상태를 관리한다

Kubernetes는 컨테이너를 실행하는 도구가 아니라 컨테이너 “상태를 유지하도록 조율하는 시스템”이다

---

4. 핵심 개념: 상태 기반 시스템

일반적인 방식과 Kubernetes의 차이는 여기서 나온다.

• 일반 방식
  → “컨테이너 3개 실행”
• Kubernetes
  → “항상 3개 상태 유지”

차이는 단순하다.

• 실행 중심 → 한 번 실행하고 끝
• 상태 중심 → 계속 유지

Kubernetes는 항상 두 상태를 비교한다.

• Desired State (원하는 상태)
• Current State (현재 상태)

그리고 이 차이를 계속 줄인다.

---

5. 기존 방식과 차이

구분	단순 컨테이너	운영 Kubernetes
관리 대상	컨테이너	전체 상태
실행 방식	수동	자동
장애 대응	직접 처리	자동 복구
확장	수동	자동

👉 Kubernetes는 “컨테이너 실행 도구”가 아니라 “상태 유지 시스템”이다

---

6. 이 글에서 가져가야 할 기준

이 글에서 중요한 건 개념이 아니라 기준이다.

• Kubernetes는 실행이 아니라 상태를 관리한다
• 구조적으로 결정과 실행이 분리되어 있다
• 모든 동작은 상태 차이를 줄이는 방향으로 이루어진다

이 기준을 잡아두면 이후 개념이 자연스럽게 연결된다.

---

7. 회고

Kubernetes를 처음 접하면 Pod, Deployment 같은 객체부터 보게 된다. 하지만 이 방식은 구조를 이해하기 어렵다.

이번 글에서는

• 왜 Kubernetes가 필요한지
• 어떤 기준으로 동작하는지

에 집중했다.

 

이 기준을 먼저 잡고 들어가야  이후 개념이 단순 기능이 아니라 구조 안에서의 역할로 보인다.

---

8. 다음글

앞선 글에서는 Kubernetes를 개념이 아니라 구조를 기준으로 이해하는 것에 집중했다.

• Control Plane은 상태를 기준으로 판단하고
• Worker Node는 실제로 실행하며
• Controller는 상태를 계속 맞춘다

이 기준을 잡고 나면 다음 단계가 필요해진다.

이 구조가 실제로 어떻게 동작하는가

 

Kubernetes는 단순히 컴포넌트가 나뉘어 있는 것이 아니라 요청이 들어온 순간부터 실행되고, 다시 상태가 반영되기까지 하나의 흐름으로 이어진다.

 

다음 글에서는 이 과정을 기준으로

• 요청이 API Server에 들어온 이후
• Scheduler가 어떻게 Node를 선택하고
• Kubelet이 어떻게 컨테이너를 실행하며
• 상태가 어떻게 다시 반영되는지

를 아키텍처 흐름 단위로 정리할 예정이다.

 

Kubernetes 아키텍처 이해