Kubernetes 상태 유지 구조 (Controller & Reconciliation Loop)

1. 문제 / 필요성

Kubernetes를 사용하면서 가장 먼저 드는 의문은 이거다.

• 컨테이너가 죽었는데 왜 자동으로 다시 생성되는가
• Pod 개수를 왜 계속 유지하는가
• 수동으로 삭제해도 왜 다시 생기는가

이건 기능이 아니라 구조에서 나오는 결과다.

Kubernetes는 “실행”이 아니라“상태를 유지하는 시스템”이기 때문

---

2. 핵심 개념: Desired State vs Current State

Kubernetes는 항상 두 가지 상태를 가진다.

• Desired State → 사용자가 원하는 상태
• Current State → 실제 실행 상태

예시:

• Desired: Pod 3개
• Current: Pod 2개

이 상태 차이를 없애는 것이 Kubernetes의 역할이다.

---

3. Reconciliation Loop란 무엇인가

Reconciliation Loop는 다음 과정을 반복한다.

1. 현재 상태 관찰 (Observe current state)
2. 원하는 상태 확인 (Observed desired state)
3. 차이 발생
4. 수정 작업 수행 (Take action)
5. 다시 상태 확인

그리고 이 과정을 계속 반복한다.

“한 번 맞추는 것이 아니라 계속 맞춘다”

---

4. Controller의 역할

• Controller는 Reconciliation Loop를 실행하는 주체다.
• 각 Controller는 특정 리소스를 담당한다.

예:

• Deployment Controller → Deployment 상태 유지
• ReplicaSet Controller → Pod 개수 유지
• Node Controller → Node 상태 관리

Controller 동작 흐름

1. API Server에서 상태 조회
2. 리소스 변경 감지 (watch)
3. desired vs current 비교
4. 필요 시 수정 요청

모든 수정은 API Server를 통해 이루어진다

---

5. 실제 동작 예시

상황: Pod 3개 유지

• Desired State: 3
• Current State: 2

Controller 판단:
→ 1개 부족 → Pod 생성 요청

상황: Pod 하나 삭제

• Current State: 2

Controller 판단:
→ 다시 3개로 맞춤

사용자가 삭제해도 “상태 기준”이 유지되면 다시 생성된다.

---

6. 왜 수동 변경이 유지되지 않는가

Kubernetes에서는 다음이 중요하다.

• 직접 Pod 삭제 → 의미 없음
• 직접 수정 → 곧 덮어씀

이유:

Controller는 항상 “desired state”를 기준으로 다시 맞추기 때문

---

7. 선언형 방식의 의미

Kubernetes는 명령형이 아니라 선언형이다.

• 명령형
  → “Pod 3개 실행해라”
• 선언형
  → “항상 3개 상태 유지해라”

차이:

• 명령형 → 1회 실행
• 선언형 → 지속 유지

---

8. Reconciliation Loop의 특징

① 이벤트 기반이 아님

• 특정 이벤트에서 끝나는 구조가 아님
• 계속 반복

② idempotent (멱등성)

• 같은 작업을 여러 번 수행해도 결과 동일
• 상태 기반이기 때문에 가능

③ 느슨한 결합

• Controller / Scheduler / Kubelet
• 서로 직접 호출하지 않음
• API Server 통해 연결

---

9. 전체 구조와 연결하면

이전 글과 연결해서 보면

• Control Plane → 상태 저장
• Controller → 상태 비교
• Scheduler → 실행 위치 결정
• Worker Node → 실행

이 중 Controller가 “유지”를 담당한다

---

10. 핵심 정리

• Kubernetes는 상태 기반 시스템
• Desired vs Current 상태를 항상 비교
• Controller가 Reconciliation Loop 수행
• 상태 차이를 계속 줄임

Kubernetes는 “상태를 한 번 맞추는 시스템이 아니라, 계속 유지하는 시스템”

---

11. 마치며

• 이전 글에서 Control Plane과 Worker Node 구조를 이해했다면, 이번 글에서는 그 구조가 왜 “자동으로 유지되는지”를 설명했다.
• 처음에는 단순히 자동 복구 기능처럼 보였지만, 실제로는 Controller와 Reconciliation Loop라는 구조에서 나온 결과였다.

이 관점을 이해하면 Kubernetes의 동작이 예측 가능해진다.

• 왜 Pod가 다시 생성되는지
• 왜 수동 변경이 유지되지 않는지
• 왜 Deployment를 기준으로 관리해야 하는지

결국 Kubernetes는 명령을 수행하는 시스템이 아니라 상태를 기준으로 계속 보정하는 시스템이라는 점이 핵심이다.

---

12. 다음 글

이번 글에서는 Kubernetes가 왜 자동으로 상태를 유지하는지에 대해 Controller와 Reconciliation Loop를 중심으로 정리했다.

• Desired State와 Current State를 비교하고
• 그 차이를 계속 줄이는 구조로 동작하며
• 이 반복 과정이 자동 복구와 상태 유지로 이어진다

이 기준을 이해하면 Kubernetes의 동작은 더 이상 예외처럼 보이지 않는다.

• Pod이 삭제되면 다시 생성되는 이유
• 수동 변경이 유지되지 않는 이유
• Deployment를 기준으로 관리해야 하는 이유

가 모두 하나의 구조로 설명된다.

상태를 정의하는 단위는 무엇인가
어떤 객체를 기준으로 관리해야 하는가

 

다음 글에서는

• Pod은 왜 직접 관리 대상이 아닌지
• Deployment는 어떤 역할을 하는지
• Service는 어떤 문제를 해결하는지

를 중심으로 Kubernetes 객체를 구조 기준으로 해석할 예정이다.