Kubernetes Admission Controller의 두 가지 유형

Admission Controller의 두 가지 유형

1. Validating Admission Controller

 

요청을 검증한 후 통과/거부 여부를 결정한다. 에를 들어 NamespaceExists가 활성화되어 있는경우 Namespace가 없으면 요청을 거부한다.

 

2. Mutating Admission Controller

 

요청을 수정하여 API 서버로 전달한다.

예를 들어 DefaultStorageClass가 설정된 경우 PVC 생성 요청에 StorageClass가 없으면 DefaultStorageClass를 자동으로 삽입한다.

 

실행 순서

Mutating Admission Controller가 먼저 실행된 후 Validating Admisson Controller가 요청을 검증한다.

 

해당 순서가 중요한 이유는 검증이 먼저 수행될 경우 mutating 이후에 통과할 수 있는 명령을 미리 검증과정에서 거부할 수 있기 때문이다. 예를 들면 NamespaceAutoProvisioning이 켜져있는 상황에서 NamespaceExists가 먼저 동작할 경우, 실제로는 mutating 이후 통과될 수 있는 명령이지만 mutating 이전에 거부되어 실행되지 않을 수 있다.

 

External Admission Controller

kubernetes는 MutatingAdmissionWebhook / ValidatingAdmissionWebhook components를 활용하여 외부 Admission Controller또한 지원한다.

외부에 서버를 두고 요청을 HTTP로 주고받으며 AdmissionReview 객체를 JSON 형태로 전달한다.

WebHook의 구성 흐름은 다음과 같다.

 

1. Webhook server를 개발하고 배포한다.

원하는 로직으로 요청을 mutate 혹은 validate해야하며 Go, Python, Node.js 등으로 개발 가능하다

로직은 자유롭게 구성하되, return은 특정한 response format을 준수하여 전달하여야한다.

 

2. 서비스 등록

클러스터 내부에 deployment로 서버를 배포한 경우 Kubernetes 내에서 서비스를 등록하고, 외부 서버인 경우는 서비스 등록 없이 Webhook Configuration 작성 시 외부 URL을 적어주면된다.

 

3. Webhook Configuration 작성

• MutatingWebhookConfiguration or ValidatingWebhookConfiguration 에 등록하면 API server는 web-hook server로 트래픽을 전송한다. TLS 통신이 필수이므로 caBundle을 추가로 설정해야한다.

 

4. Rule 설정

언제 webhook을 호출할지 정의하는 과정으로 create pods만 대상으로 호출하도록 설정할 수 있다.