DevOps Colleague

Kubernetes의 AdmissionReview는 Admission Webhook과 API 서버 사이의 통신에 사용되는 요청/응답 포맷입니다. 간단히 말하면, "Kubernetes가 webhook에게 묻는 질문과 webhook이 보내는 대답"이라고 생각하면 됩니다. AdmissionReview란?AdmissionReview는 Kubernetes API 서버가 외부 Webhook 서버에 리소스 생성/변경 요청을 검사해 달라고 보낼 때 사용하는 구조체입니다.Webhook 서버는 이 요청을 분석하고, 허용할지 거부할지 결정한 후 응답합니다.구성요소:AdmissionReview.Request: API 서버가 보내는 요청 정보AdmissionReview.Response: Webhook 서버가 응답하는 승인/거부..

CRD에 대한 Webhook은 보통 다음 두 가지 용도로 사용됩니다:Validation Webhook – 리소스의 생성/수정 요청이 유효한지 검사Mutation Webhook – 리소스를 자동으로 수정(default 값 설정 등) 왜 Webhook Validation을 사용할까?기본적으로 CRD의 유효성 검증은 OpenAPI v3 Schema로 처리할 수 있지만,복잡한 조건 (예: 필드 간 종속성, 외부 리소스 검사 등)은 Webhook을 통해 동적으로 처리할 수 있습니다.예를 들어:spec.replicas는 1 이상이어야 한다spec.env 값이 prod일 때는 spec.logging이 필수다특정 필드가 UUID 형식인지 검사이런 복잡한 로직은 오직 Validation Webhook으로만 가능합니다. ..

Kubernetes는 분산 환경에서 여러 클라이언트가 동시에 리소스를 수정할 수 있기 때문에, 충돌 관리가 중요합니다. 이를 해결하기 위해 Kubernetes는 Optimistic Concurrency Control(OCC) 방식을 사용합니다.이 글에서는 CRD(Custom Resource Definition) 리소스에서도 OCC를 어떻게 구현하고 사용하는지, 그리고 실제 Go 코드로 어떻게 처리하는지 알아보겠습니다. OCC란?OCC(낙관적 동시성 제어)는 "충돌이 자주 일어나지 않을 것"이라고 가정하고,리소스를 수정할 때마다 현재 버전(resourceVersion)을 확인하여 충돌 여부를 판단하는 방식입니다.최신 버전일 경우 → 정상 업데이트버전 불일치 시 → 409 Conflict 오류 발생 → 재시..

Kubernetes의 Optimistic Concurrency Control (OCC*은 여러 클라이언트가 동시에 리소스를 수정하려고 할 때 충돌을 방지하기 위한 방법입니다. Kubernetes는 분산 시스템이기 때문에 여러 사용자가 같은 리소스를 동시에 수정할 수 있는데, 이때 낙관적(optimistic) 접근으로 충돌을 감지하고 처리합니다. 핵심 개념: metadata.resourceVersion모든 Kubernetes 리소스에는 metadata.resourceVersion이라는 필드가 존재합니다.이 값은 해당 리소스가 변경될 때마다 변경되는 버전 번호입니다.apiVersion: v1kind: ConfigMapmetadata: name: my-config resourceVersion: "12345..

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 ..

AWS EKS(EKS: Elastic Kubernetes Service)에서 Auto Mode는 2023년 11월에 새롭게 출시된 EKS Pod 기반의 서버리스 실행 환경입니다. 공식 명칭은 EKS Pod Identity + EKS Fargate Auto Mode입니다. 이 모드는 Kubernetes 클러스터 운영을 더욱 단순화하고 자동화하기 위해 고안되었습니다. EKS Auto Mode란?EKS Auto Mode는 컨트롤 플레인과 워커 노드를 직접 관리하지 않고도 Kubernetes 클러스터를 실행할 수 있도록 해주는 완전 관리형 서버리스 실행 방식입니다. 전통적인 EKS(Managed Node Group, Self-managed Node Group, Fargate 등)보다 설정이 간단하고 운영이 편리..

spec은 사용자가 의도한 목표 상태이고, status는 현재 실제 시스템의 상태입니다.Operator는 이 둘을 비교해 Reconciliation을 수행하고, 이를 통해 시스템이 항상 원하는 상태를 유지하도록 합니다. 정리: spec과 status의 용도필드용도작성 주체spec사용자가 원하는 목표 상태 (Desired State)를 정의사용자 / Controller 외부 입력status실제 시스템의 현재 상태 (Observed State)를 반영Operator / Controller (자동 갱신)자세한 설명spec – "사용자가 원하는 상태"사용자가 어떻게 동작하길 원하는지를 정의합니다.예를 들어, 파드 개수, 이미지 버전, 리소스 제한, 설정 값 등이 여기에 들어갑니다.Controller는 이 spe..

“Operator는 Kubernetes의 Reconciliation Loop 기반으로 동작하기 때문에, 같은 이벤트가 반복적으로 들어오더라도 결과가 동일해야 하는 멱등성(idempotency) 이 매우 중요합니다.이를 보장하기 위해 저는 다음과 같은 전략을 사용합니다:현재 상태와 Desired 상태를 비교한 후 필요한 작업만 수행합니다. 예를 들어, 리소스를 항상 다시 생성하는 것이 아니라, 이미 존재하고 원하는 상태와 같다면 아무 작업도 하지 않습니다.Status 필드를 적극 활용합니다. 작업이 완료된 경우 해당 상태를 기록하고, 이후 동일한 작업이 재요청되더라도 다시 실행하지 않도록 합니다.생성 시에는 항상 CreateOrUpdate 패턴을 사용하고, 삭제나 업데이트 시에도 리소스가 실제 존재하고 변..