Kubernetes의 동작 철학 중 하나인 Level-Triggered 방식의 개념

Kubernetes의 동작 철학 중 하나인 Level-Triggered 방식은 Kubernetes가 어떻게 상태를 감지하고 반응(reconcile) 하는지를 이해하는 데 아주 핵심적인 개념입니다.

이걸 Edge-Triggered와 비교하면서 설명하면 훨씬 명확해져요.

 

Kubernetes는 Level-Triggered 방식으로 동작하며,
이는 Polling 기반 + 이벤트 알림을 혼합한 구조예요.
핵심은 “현재 상태와 원하는 상태의 차이를 계속 관찰하고, 필요할 때만 동작”한다는 점입니다.

 

개념 정리

구분Edge-TriggeredLevel-Triggered (K8s 방식)

의미	변화가 발생했을 때만 트리거됨	원하는 상태와 현재 상태의 차이를 지속적으로 확인
예시	파일이 변경된 순간에만 이벤트 발생	“이 파일이 이 상태인지”를 계속 확인
상태 기반 vs 이벤트 기반	이벤트 기반	상태 기반
Kubernetes에서?	❌ 사용 안 함	✅ 사용

 

Kubernetes는 왜 Level-Triggered인가?

Kubernetes의 핵심은 선언적(desired state) 시스템이에요:

"나는 이 Deployment가 항상 3개의 Pod를 갖고 있기를 원해."

Kubernetes는 이 선언된 원하는 상태(desired state)와
현재의 실제 상태(current state)를 계속 비교하면서
차이가 있을 때만 reconcile 하도록 설계되어 있어요.

이걸 Level-Triggered 방식이라고 합니다.

 

동작 흐름 요약 (controller-runtime 기준)

1. 사용자가 Deployment를 생성 (desired state 선언)
2. Controller는 watch를 통해 이 리소스를 감지
3. Reconcile 루프가 돌며 현재 상태와 원하는 상태를 비교
4. 차이가 있다면 조치를 취해 desired state에 맞춤
5. 차이가 없으면 아무것도 하지 않음 (idempotent)

👉 이 과정은 단순히 이벤트에만 반응하는 게 아니라,
"내가 원하는 상태에 도달했는가?"라는 상태 기반 루프로 이루어져 있어요.

 

이벤트 vs Polling?

Kubernetes는 이벤트 기반과 polling의 중간입니다:

• Watch API를 통해 etcd의 리소스 변화 이벤트를 받지만,
• 결국 Reconcile 루프에서 상태를 비교해서 동작하기 때문에,
• 단순한 이벤트 기반(Edge-Triggered)와는 다르고,
• 매초마다 무조건 확인하는 Polling과도 달라요.

즉:

"상태 변화 이벤트로 Reconcile을 트리거하되, 실제로는 항상 상태를 확인하고 반응한다."

 

 

💡 예시로 이해해보기

Edge-Triggered 시스템이라면:

• Pod가 삭제되었는지 이벤트가 없으면 복구 못 함

Level-Triggered 시스템(Kubernetes):

• Pod가 사라졌든, 네트워크 문제로 이벤트를 못 받았든 상관없이
• "3개 있어야 되는데 지금 2개네?" → 1개 추가!

 

✅ 요약

• Kubernetes는 Level-Triggered 방식
• 상태 변화 이벤트로 Reconcile 루프를 트리거하지만,
• 실제 동작은 항상 현재 상태와 원하는 상태를 비교
• idempotent한 로직이 핵심
• Edge-Triggered와는 달리, 이벤트를 놓쳐도 다음 상태 비교에서 다시 복구 가능