가비지 컬렉션(Garbage Collection) 컨트롤러의 동작 원리

가비지 컬렉션(Garbage Collection) 컨트롤러의 동작 원리

1. 쿠버네티스 가비지 컬렉션의 핵심: 객체 간의 소유권(Ownership)

쿠버네티스의 가비지 컬렉션(Garbage Collection, GC)은 프로그래밍 언어의 메모리 해제 메커니즘이 아니라, 클러스터 내부에 더 이상 필요 없어진 '고아(Orphan)' 리소스들을 자동으로 정리하여 시스템 자원 누수를 방지하는 핵심 컨트롤러 메커니즘입니다.

사용자가 디플로이먼트(Deployment)를 생성하면 시스템은 레플리카셋(ReplicaSet)을 만들고, 레플리카셋은 파드(Pod)들을 생성합니다. 만약 사용자가 최상위의 디플로이먼트를 삭제했을 때, 그 하위의 레플리카셋과 파드들이 클러스터에 그대로 남아있다면 심각한 자원 낭비가 발생할 것입니다. 쿠버네티스 GC 컨트롤러는 리소스 메타데이터 내부에 명시된 소유자 참조(OwnerReferences) 구조를 바탕으로 부모-자식 관계를 추적하고, 부모 리소스가 삭제되었을 때 종속된 자식 리소스들을 연쇄적으로 삭제하는 역할을 수행합니다.

2. 소유자 참조 (OwnerReference) 구조 해부

모든 쿠버네티스 리소스의 metadata에는 ownerReferences라는 배열 필드가 존재합니다. 자식 리소스(예: 파드)는 이 필드 안에 자신을 생성하고 관리하는 부모 리소스(예: 레플리카셋)의 정보를 기록합니다.

• apiVersion 및 kind: 부모 리소스의 API 그룹과 종류를 명시합니다.
• name 및 uid: 부모 리소스의 고유 식별자입니다. 이름(name)만으로는 재생성된 동명의 리소스를 구분할 수 없으므로, 반드시 고유한 uid를 함께 사용하여 정확한 소유자를 식별합니다.
• controller (boolean): 해당 부모 리소스가 자식의 생명주기를 전적으로 통제하는 핵심 컨트롤러인지 여부를 나타냅니다. 자식 리소스는 여러 개의 OwnerReference를 가질 수 있지만, controller: true로 설정된 부모는 단 하나만 존재할 수 있습니다.
• blockOwnerDeletion (boolean): 자식 리소스가 삭제되기 전까지 부모 리소스의 삭제를 차단(블로킹)할 수 있는 권한을 부여하는 플래그입니다. 포그라운드(Foreground) 삭제 정책에서 핵심적으로 사용됩니다.

3. 연쇄 삭제(Cascading Deletion)의 3가지 전파 정책

쿠버네티스 API 서버에 리소스 삭제(DELETE) 요청을 보낼 때, propagationPolicy 파라미터를 통해 하위 리소스들을 어떻게 처리할지 결정할 수 있습니다. GC 컨트롤러는 이 정책에 따라 각기 다른 로직을 수행합니다.

3.1. Background (백그라운드 연쇄 삭제 - 기본값)

가장 보편적이고 빠른 삭제 방식입니다. API 서버는 부모 리소스를 즉시 삭제하고 클라이언트에게 성공을 반환합니다. 이후 Kube-controller-manager 내부에 구동 중인 GC 컨트롤러가 백그라운드에서 부모를 잃은 자식 리소스(고아 객체)들을 찾아내어 일괄적으로 삭제 요청을 보냅니다. 사용자는 삭제 명령이 즉시 수행된 것처럼 느끼지만, 실제 하위 파드들이 완전히 종료되기까지는 약간의 지연이 발생할 수 있습니다.

3.2. Foreground (포그라운드 연쇄 삭제)

자식 리소스들이 모두 완전히 삭제될 때까지 부모 리소스의 삭제를 보류하는 안정적인 방식입니다.

1. API 서버는 부모 리소스를 즉시 지우지 않고, deletionTimestamp를 마킹한 뒤 metadata.finalizers 배열에 foregroundDeletion 파이널라이저를 삽입합니다. 이 상태에서 부모 리소스는 '삭제 진행 중(Deletion in progress)' 상태가 됩니다.
2. GC 컨트롤러는 이 상태를 감지하고, 해당 부모를 참조하는 모든 자식 리소스들에게 삭제 요청을 보냅니다.
3. GC 컨트롤러는 자식 리소스들이 클러스터에서 물리적으로 완전히 사라질 때까지 주기적으로 확인합니다.
4. 모든 자식이 지워진 것이 확인되면, GC 컨트롤러는 부모 리소스의 파이널라이저(foregroundDeletion)를 제거합니다. 비로소 API 서버가 부모 리소스를 etcd에서 완전히 삭제합니다.

3.3. Orphan (고아 정책)

부모 리소스만 단독으로 삭제하고, 자식 리소스들은 클러스터에 그대로 남겨두는 방식입니다. 이 정책을 사용하면 GC 컨트롤러는 하위 객체들에 개입하지 않습니다. 주로 파드의 중단 없이 상위 컨트롤러(예: 디플로이먼트)의 설정만 초기화하거나 교체하고 싶을 때 유용하게 사용됩니다.

4. GC 컨트롤러의 내부 아키텍처: Graph Builder와 워커 루프

Kube-controller-manager 내부에서 동작하는 Garbage Collector는 수만 개의 리소스 간의 복잡한 종속성을 효율적으로 처리하기 위해 고도화된 아키텍처를 가집니다.

4.1. Graph Builder와 방향성 비순환 그래프(DAG)

GC 컨트롤러는 단순히 API 서버에 쿼리를 날려 고아 리소스를 찾지 않습니다. 컨트롤러 내부의 Graph Builder 컴포넌트는 클러스터 내의 모든 리소스를 모니터링(Watch)하여 로컬 메모리에 거대한 방향성 비순환 그래프(Directed Acyclic Graph, DAG)를 구축합니다.
이 그래프의 각 노드(Node)는 개별 쿠버네티스 리소스를 의미하며, 간선(Edge)은 ownerReferences를 기반으로 한 부모-자식 관계를 나타냅니다. Graph Builder는 API 서버로부터 리소스 생성, 수정, 삭제 이벤트를 스트리밍 받아 이 인메모리 그래프를 실시간으로 최신화합니다. 이 구조 덕분에 GC 컨트롤러는 무거운 데이터베이스(etcd) 조회 없이, 메모리 상의 그래프 탐색만으로 특정 리소스의 소유자 존재 여부를 마이크로초 단위로 판단할 수 있습니다.

4.2. Dirty Queue와 Item Processor

Graph Builder가 이벤트 변화를 감지하면, 검토가 필요한 리소스들을 Dirty Queue라는 작업 대기열에 집어넣습니다. 예를 들어, 특정 파드의 부모 레플리카셋이 삭제되는 이벤트가 발생하면, 해당 파드들은 종속성 검사를 위해 Dirty Queue에 인입됩니다.

워커 스레드 집합인 Item Processor는 Dirty Queue에서 리소스를 하나씩 꺼내어 처리합니다.

1. 해당 리소스의 소유자(Owner)가 그래프 상에 여전히 존재하는지 확인합니다.
2. 소유자가 더 이상 존재하지 않거나, 소유자가 '삭제 진행 중' 상태라면 해당 리소스를 가비지로 판정합니다.
3. 가비지로 판정된 객체에 대해 API 서버에 즉시 DELETE 요청을 비동기적으로 발송하여 정리를 수행합니다.

5. 파이널라이저(Finalizer)와의 데드락(Deadlock) 방지 메커니즘

가비지 컬렉션 과정에서 매우 주의해야 할 요소는 파이널라이저(Finalizer)입니다. 파이널라이저는 특정 비즈니스 로직(예: 외부 클라우드 로드밸런서 삭제, 퍼시스턴트 볼륨 데이터 정리 등)이 완료되기 전까지 해당 리소스가 etcd에서 삭제되는 것을 API 서버 차원에서 강력하게 차단하는 안전장치입니다.

만약 자식 리소스에 커스텀 파이널라이저가 걸려있어 지워지지 않고 무한정 대기한다면, 포그라운드 삭제 정책으로 지워지고 있는 부모 리소스 역시 자식이 지워지기를 기다리며 영원히 'Terminating' 상태에 빠지는 데드락 현상이 발생할 수 있습니다. GC 컨트롤러는 이러한 상황을 타개하기 위해 강제로 개입하지 않으며, 철저히 선언적 상태 머신에 따라 동작합니다. 따라서 클러스터 관리자나 오퍼레이터 개발자는 자식 리소스에 부여한 파이널라이저 로직이 반드시 유한한 시간 내에 정상적으로 해제(Remove)되도록 구현해야만, GC 컨트롤러의 연쇄 삭제 파이프라인이 클러스터 전역에서 막힘없이 원활하게 구동될 수 있습니다.