Kubernetes의 Optimistic Concurrency Control (OCC)

Kubernetes의 Optimistic Concurrency Control (OCC*은 여러 클라이언트가 동시에 리소스를 수정하려고 할 때 충돌을 방지하기 위한 방법입니다. Kubernetes는 분산 시스템이기 때문에 여러 사용자가 같은 리소스를 동시에 수정할 수 있는데, 이때 낙관적(optimistic) 접근으로 충돌을 감지하고 처리합니다.

 

핵심 개념: metadata.resourceVersion

모든 Kubernetes 리소스에는 metadata.resourceVersion이라는 필드가 존재합니다.
이 값은 해당 리소스가 변경될 때마다 변경되는 버전 번호입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
  resourceVersion: "12345"

 

동작 방식 요약

1. 클라이언트가 리소스를 읽음 → 현재의 resourceVersion을 기억
2. 리소스를 수정 후 저장하려고 함
3. API 서버는 현재 서버에 있는 리소스의 resourceVersion과 일치하는지 확인
4. 일치 → 업데이트 허용
   불일치 → 충돌 발생, 업데이트 실패 (409 Conflict)

 

예제: 충돌 시나리오

1. Alice와 Bob이 둘 다 같은 ConfigMap을 읽음
2. Alice가 먼저 수정해서 저장함 → resourceVersion = 12345 → 12346으로 업데이트
3. Bob이 나중에 기존 내용(12345 버전)을 바탕으로 저장 시도
4. API 서버: ❌ "이미 12346이 최신인데, 너는 12345 버전으로 저장하려 하네?" → 409 Conflict 발생

 

실전 팁

1. kubectl apply가 사용하는 방식

kubectl apply -f config.yaml

 

• 내부적으로 PATCH 요청을 보내고 resourceVersion을 자동으로 사용합니다
• 만약 충돌이 발생하면 재시도하거나 수동으로 병합할 수 있습니다

2. 직접 API 호출 시

• PUT 요청 시 반드시 올바른 resourceVersion을 포함해야 합니다.
• 예시 (with curl or client-go):

{
  "metadata": {
    "name": "my-config",
    "resourceVersion": "12345"
  },
  "data": {
    "key": "value"
  }
}

 

 

3. Controller 구현 시

Custom Controller나 Operator에서 리소스를 업데이트할 때는:

• 현재 상태를 가져온 후 → 변경 → resourceVersion 포함하여 update
• 충돌이 발생하면 requeue하고 다시 시도 (재시도 메커니즘 필요)

OCC의 장점

• 병목 없는 고성능 처리 가능
• 락 없이도 데이터 정합성 유지
• 충돌은 예외 상황으로 처리

 

단점 및 주의사항

• 충돌이 빈번하면 성능 저하
• 복잡한 상태 변경 로직은 재시도/병합이 까다로움
• 일부 컨트롤러에서 충돌로 인한 "flapping"이 생길 수 있음 (반복 실패/재시도)