Kubernetes API 서버에서 "Lock"을 관리하는 방법

Kubernetes API 서버에서 "Lock"을 관리하는 방법은 주로 Leader Election, Coordination API, 그리고 ResourceVersion 기반 동시성 제어를 통해 이루어집니다.

 

1. Leader Election (리더 선출)

Kubernetes에서 여러 컨트롤러나 프로세스 중 하나만 특정 작업을 수행해야 할 때 leader election이 필요합니다.

동작 방식

• Kubernetes의 client-go 라이브러리는 leader election 기능을 제공합니다.
• 특정 리소스(예: ConfigMap 또는 Lease)를 이용해 리더를 정하고 상태를 주기적으로 갱신합니다.

사용되는 리소스

• 과거: ConfigMap, Endpoints
• 현재(권장): Lease (Coordination API 리소스, 경량화됨)

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: my-controller-leader-election
spec:
  holderIdentity: controller-1
  leaseDurationSeconds: 15

 

2. Coordination API (Lease)

Kubernetes 1.14부터 정식으로 도입된 Coordination API는 클러스터 내부의 여러 컴포넌트나 컨트롤러 간 동기화/잠금 기능을 위한 경량화된 리소스입니다.

🔧 주요 특징

• Lease 리소스는 단순한 키-값 저장소처럼 동작
• spec.renewTime을 갱신하여 "누가 현재 이 리소스를 점유하고 있는지"를 표현
• Kubelet, Controller Manager, Kube Scheduler 등에서도 사용

 

3. Optimistic Concurrency Control (낙관적 동시성 제어)

리소스를 업데이트할 때 resourceVersion을 활용해 충돌 감지를 합니다.

예:

kubectl get configmap my-config -o yaml > config.yaml
# 수정 후 적용 시도
kubectl apply -f config.yaml

이때 누군가 먼저 변경했다면 resourceVersion 불일치로 충돌 발생 → 실패

 

4. Custom Controller에서 Lock 구현하기

사용자가 작성한 Custom Controller에서도 다음과 같이 락 기능을 넣을 수 있어요:

• 특정 CRD(Custom Resource)에 spec.lockedBy 필드를 추가해 간단한 soft-lock 구현
• Lease API를 사용하여 실제 리더 선출 기능 포함

 

Kubernetes에는 파일 락이나 POSIX 락 같은 건 없다?

맞습니다. Kubernetes API 서버는 분산 시스템 환경에 맞게 API 기반의 "논리적 락"을 제공하며, 로컬 파일 시스템 락은 사용하지 않습니다. 대신 리소스의 상태(state)를 가지고 조율하는 구조예요.

 

정리하면

기능	설명	리소스
Leader Election	하나의 인스턴스만 작업 수행	Lease
Coordination API	컴포넌트 간의 락 및 상태 동기화	Lease
동시성 제어	resourceVersion 기반 업데이트 충돌 방지	모든 리소스
사용자 락 구현	CRD에 soft-lock 필드 추가 or Lease 사용	Custom