Scheduling - Admission Controller

지금까지 kubectl로 Pod/Deployment 같은 오브젝트를 만들면, 요청이 API Server로 들어가고, 최종적으로 etcd에 저장된다는 흐름을 봤습니다.
이 요청은 API Server에서 여러 단계를 거치는데, 강의의 흐름을 정리하면 다음과 같습니다.

---

1) 요청 흐름: Authentication → Authorization → Admission Control → etcd

1) Authentication(인증)

요청을 보낸 “주체가 누구인지” 확인합니다.

• 보통 클라이언트 인증서/토큰 등을 사용
• kubectl은 kubeconfig에 설정된 인증 정보를 사용합니다.

2) Authorization(인가)

그 주체가 “이 작업을 해도 되는지” 권한을 확인합니다.

• 대표적으로 RBAC(Role-Based Access Control)

예: 개발자 역할이 있으면

• pods에 대해 get/list/create/update/delete 허용
• 특정 namespace에만 허용
• 특정 resourceName(예: pod 이름이 blue/orange인 것만)만 허용
  같은 “API 레벨의 접근 제어”가 가능합니다.

3) Admission Controller(입장 컨트롤러)

여기서부터가 강의의 핵심입니다.

RBAC는 “누가 어떤 API를 호출해도 되나”까지만 잘합니다.
그런데 실무에서 필요한 정책은 보통 이걸 넘습니다.

---

2) RBAC로 못 하는 것들: “리소스 내용(spec)을 검사/수정”하는 정책

RBAC는 “create pod 허용/거부”는 가능하지만,
Pod 스펙 내부를 들여다보고 아래 같은 정책을 강제하기는 어렵습니다.

예시(강의 내용):

• 이미지가 공용 DockerHub면 거부하고 내부 레지스트리만 허용
• :latest 태그 사용 금지
• 컨테이너가 root로 실행되는지 검사해서 거부
• 특정 라벨이 항상 붙도록 강제
• PVC 생성 시 default StorageClass가 없으면 자동으로 붙여주기
• API Server 요청 폭주 방지(레이트 제한)

이런 “내용 기반 정책/보정/자동 주입”을 처리하는 게 Admission Controller입니다.

---

3) Admission Controller는 “검증(Validate)”만 하는 게 아니라 “변경(Mutate)”도 한다

Admission Controller는 크게 두 일을 할 수 있습니다.

• Validate: 요청을 검사해서 통과/거부
• Mutate: 요청 내용을 수정해서 통과시키거나 기본값을 주입

강의 예시:

• DefaultStorageClass: PVC에 StorageClass가 없으면 기본값을 자동 추가(= mutate)
• AlwaysPullImages: Pod 생성 시 항상 이미지 pull하도록 강제(= mutate 성격)
• EventRateLimit: 요청 폭주를 제한(= validate/제어)

---

4) “NamespaceExists” 예시로 이해하기

강의의 예시는 매우 직관적입니다.

상황

존재하지 않는 네임스페이스 blue에 Pod를 만들려고 한다.

kubectl run nginx --image=nginx -n blue

결과

• 인증(Authentication) OK
• 인가(Authorization) OK (예: 개발자에게 create pod 권한이 있음)
• 하지만 Admission 단계에서 “네임스페이스가 존재하냐?”를 검사
• 없다면 거부
• 그래서 namespace "blue" not found 같은 오류가 발생

이처럼 Admission Controller는 “요청 자체가 클러스터 정책에 맞는지”를 마지막으로 체크하는 관문입니다.

---

5) 자동으로 네임스페이스를 만들어 주는 컨트롤러?

강의에서는 “NamespaceAutoProvision” 같은 컨트롤러도 언급합니다.

• 네임스페이스가 없으면 자동 생성 후 요청을 계속 진행

다만 강의 후반에 중요한 주석이 있습니다.

• 이런 일부 컨트롤러는 deprecated(더 이상 권장되지 않음) 되었고,
• 현재는 NamespaceLifecycle 같은 컨트롤러가 역할을 대체합니다.

NamespaceLifecycle의 핵심 역할(강의 요지):

• 존재하지 않는 네임스페이스로의 요청을 거부
• kube-system, kube-public 같은 기본 네임스페이스는 삭제되지 않도록 보호

---

6) 현재 활성화된 Admission Controllers 확인(개념)

Admission Controller는 API Server 설정으로 켜고 끕니다.
강의에서는 API Server 실행 옵션에서 admission plugin 목록을 grep해서 확인한다고 설명합니다.

실무적으로 중요한 포인트는 이것입니다.

• kubeadm 환경에서는 API Server가 보통 static pod로 떠 있으므로,
• API Server 설정을 바꾸려면 kube-apiserver 매니페스트에서 플래그를 수정합니다.

즉,

• “서비스로 실행되는 API Server”면 서비스 옵션을 수정
• “kubeadm(파드로 실행)”이면 /etc/kubernetes/manifests/kube-apiserver.yaml 같은 매니페스트에서 수정
  (경로는 환경에 따라 다르지만 kubeadm 기본은 이 경로가 흔함)

---

7) 핵심 정리

• RBAC: “누가 어떤 API를 호출할 수 있나”를 제어
• Admission Controller: “요청 내용이 정책에 맞는가”를 검사하고, 필요하면 수정까지 한다
• Pod/PVC/Namespace 등 리소스가 실제로 생성되기 직전에 동작하며, 최종적으로 etcd에 기록되기 전에 관문 역할을 한다
• 일부 옛 컨트롤러는 deprecated 되었고, NamespaceLifecycle처럼 현재 표준 플러그인으로 대체되었다

 

Access the lab here: https://learn.kodekloud.com/user/courses/udemy-labs-certified-kubernetes-administrator-with-practice-tests/module/8e4261a6-bac4-4dfe-82c5-0a1bb8c527da/lesson/d9398583-1f11-4b74-a8ee-2bc0790f3193