1. Admission Controller의 두 가지 주요 유형

1. Validating Admission Controller
   • 요청을 검증(Validation)만 수행
   • 예: NamespaceExists, NamespaceLifecycle
   • 조건에 맞지 않으면 요청 거부
   • Pod 생성 요청 시 → 네임스페이스 존재 여부 확인 후 없으면 거부
2. Mutating Admission Controller

   • 요청을 변경(Mutation) 가능

   • 예: DefaultStorageClass

     PVC 생성 시 StorageClass 지정이 없으면 자동으로 기본 StorageClass 추가

   • 요청 자체를 수정 후 API 서버에 전달

➡️ 순서: Mutating → Validating

(먼저 변형된 요청을 반영한 후 검증을 수행해야 하기 때문)

2. Built-in Admission Controllers vs. Custom

• Built-in → Kubernetes에 내장, 소스코드와 함께 제공
• Custom → 직접 구현 가능
  • Kubernetes는 이를 위해 MutatingAdmissionWebhook, ValidatingAdmissionWebhook 제공

3. Webhook Admission Controller 동작 방식

1. 사용자가 리소스 생성/변경 요청 (예: Pod 생성)
2. API Server → Built-in Admission Controller 실행
3. 이후 Webhook 실행
   • API Server가 AdmissionReview 객체(JSON) 를 Webhook 서버로 전달
   • 요청 정보(사용자, 리소스 종류, 오퍼레이션, 객체 내용 등) 포함
4. Webhook 서버는 로직 수행 후 AdmissionReview 응답 반환
   • allowed: true → 요청 허용
   • allowed: false → 요청 거부
   • Mutating Webhook의 경우 → JSON Patch로 객체 수정 후 반환

4. Custom Webhook 서버 구현 예시

• Webhook 서버는 HTTP(S) 서버로 구현
• 어떤 언어든 가능 (Go, Python 등)
• 반드시 AdmissionReview 요청을 받고 AdmissionReview 응답을 반환해야 함