쿠버네티스의 보이지 않는 엔진: 컨트롤러와 조정 루프(Reconciliation Loop)의 모든 것

15 sec read

시스템이 스스로 상태를 맞추는 마법의 원리

지난 글에서 우리는 쿠버네티스의 핵심 철학인 ‘선언적 API 모델’에 대해 알아보았습니다. 개발자는 YAML 파일에 ‘원하는 상태(Desired State)’를 설계도처럼 정의하고, kubectl apply를 통해 쿠버네티스에 제출하기만 하면 됩니다.

하지만 여기서 한 가지 근본적인 질문이 남습니다.

우리가 원하는 상태를 API 서버에 전달한 뒤, 쿠버네티스는 ‘실제 상태(Actual State)’를 어떻게 파악하고, 만약 둘의 상태가 다를 경우 어떻게 자동으로 조정할 수 있을까요?

이 마법 같은 일을 묵묵히 수행하는 존재가 바로 쿠버네티스의 보이지 않는 엔진, ‘컨트롤러(Controller)’이며, 그 작동 원리가 바로 ‘조정 루프(Reconciliation Loop)’입니다.


🔁 조정 루프(Reconciliation Loop)란 무엇인가?

조정 루프는 쿠버네티스의 모든 컨트롤러가 수행하는 끝없는 작업 사이클을 의미합니다. 마치 집 안의 자동 온도 조절 장치와 같습니다.

  • 원하는 상태: 실내 온도를 24도로 설정한다.
  • 실제 상태: 현재 온도가 26도이다.
  • 조정 작업: 에어컨을 켠다.

쿠버네티스의 각 컨트롤러(Deployment 컨트롤러, Node 컨트롤러 등)는 자신이 담당하는 리소스에 대해 이와 같은 작업을 무한히 반복하며, 실제 상태를 원하는 상태로 끊임없이 맞추려고 노력합니다.


🌀 조정 루프의 3단계 작동 방식

모든 컨트롤러의 조정 루프는 다음과 같은 세 가지 단계를 거칩니다.

1. 관찰 (Observe)

컨트롤러는 가장 먼저 API 서버를 통해 자신이 담당하는 리소스의 현재 상태(Actual State)를 감시합니다. 예를 들어, Deployment 컨트롤러는 현재 실행 중인 Pod가 몇 개인지, 각 Pod의 버전은 무엇인지 등의 정보를 지속적으로 확인합니다.

2. 비교 (Compare)

다음으로, 관찰한 ‘실제 상태’를 사용자가 YAML로 정의한 ‘원하는 상태(Desired State)’와 비교합니다. 이 과정에서 둘 사이에 차이가 있는지 정확하게 판단합니다.

3. 조정 (Reconcile / Act)

만약 비교 결과, 현재 상태가 원하는 상태와 다르다고 판단되면, 그 차이를 메우기 위한 조정 작업(Action)을 수행합니다. 이 작업은 API 서버에 또 다른 요청을 보내는 형태로 이루어집니다.


🧠 예시: Deployment 컨트롤러의 하루

Deployment 컨트롤러가 어떻게 조정 루프를 통해 일하는지 구체적인 시나리오로 살펴보겠습니다.

상황: 개발자가 replicas: 3으로 설정된 Deployment를 배포했습니다.

  • 시나리오 1: Pod 부족
    1. (관찰) 현재 실행 중인 Pod가 2개인 것을 발견합니다.
    2. (비교) 원하는 상태(3개)와 실제 상태(2개)가 다름을 인지합니다.
    3. (조정) Pod를 1개 추가 생성하도록 API 서버에 요청합니다.
  • 시나리오 2: Pod 비정상 종료 (Self-Healing)
    1. (관찰) 실행 중이던 Pod 하나가 Crash로 인해 사라져, 현재 2개의 Pod만 남은 것을 발견합니다.
    2. (비교) 원하는 상태(3개)와 다르다고 판단합니다.
    3. (조정) 즉시 새로운 Pod를 생성하여 3개를 맞추도록 요청합니다.
  • 시나리오 3: 불필요한 Pod 존재
    1. (관찰) 알 수 없는 이유로 관련 Pod가 4개 실행 중인 것을 발견합니다.
    2. (비교) 원하는 상태(3개)보다 1개가 많다고 판단합니다.
    3. (조정) 불필요한 Pod 1개를 삭제하도록 API 서버에 요청합니다.

🔄 이 모든 과정은 쿠버네티스의 수많은 컨트롤러들에 의해 24시간 내내, 1초에도 몇 번씩 반복적으로 실행됩니다. 이처럼 끊임없이 상태를 맞추는 구조를 조정 루프(Reconciliation Loop) 또는 제어 루프(Control Loop)라고 부릅니다.


🎁 개발자가 얻는 궁극적인 혜택

이 보이지 않는 엔진 덕분에 개발자와 운영자는 막대한 이점을 얻습니다.

자동화된 상태 복원: 사람이 개입하기 전에 시스템이 스스로 이상을 감지하고 원하는 상태로 복원합니다. 장애 대응과 리소스 관리가 완전히 자동화됩니다.

높은 신뢰성과 예측 가능성: 우리는 더 이상 시스템의 현재 상태를 걱정하며 일일이 들여다볼 필요가 없습니다. 선언된 상태대로 시스템이 유지될 것이라는 강한 신뢰를 가질 수 있습니다.

사람의 실수 방지: 수동 작업으로 인한 실수를 원천적으로 차단하고, 모든 변경 사항이 선언적 정의를 통해 이루어지므로 인프라의 안정성이 극대화됩니다.

결론적으로, 조정 루프는 쿠버네티스의 선언적 모델을 현실로 만들어주는 핵심적인 구현체입니다. 우리가 누리는 쿠버네티스의 거의 모든 자동화 기능은 바로 이 단순하고 강력한 루프의 결과물입니다.

쿠버네티스 시크릿 관리, 어떤 방법이 최선일까? 4가지 방식 장단점…

쿠버네티스에서 애플리케이션을 운영할 때, DB 접속 정보나 API 키 같은 민감한 정보, 즉 ‘시크릿(Secret)’을 어떻게 관리해야 할지는 모두의 공통된 고민입니다. 관리 방식은 보안, 운영...
eve
13 sec read

[MSA] Spring Cloud Gateway VS Apache APISIX : 단계별…

마이크로서비스 아키텍처(MSA)에서 API 게이트웨이는 시스템의 관문 역할을 하는 핵심 컴포넌트입니다. 수많은 Java 개발팀이 Spring 생태계와의 완벽한 통합성을 자랑하는 Spring Cloud Gateway를 선택해왔습니다. 그러나 시스템이...
eve
1 min read

[Kafka] 카프카의 심장: 토픽, 파티션, 프로듀서, 컨슈머 완벽 해부

Apache Kafka가 어떻게 대용량 데이터를 실시간으로, 그리고 안정적으로 처리할 수 있는지 궁금하신가요? 그 비밀은 Kafka를 구성하는 핵심 요소들의 유기적인 협력에 있습니다. Kafka는 마치 잘...
eve
1 min read