Dynamic Admission Controller 사용하기

쿠버네티스는 선언형 패러다임을 통해 애플리케이션의 배포 및 운영을 보다 쉽게할 수 있도록 도와줍니다. 하지만 시스템 개발 측면에서는 쿠버네티스라는 새로운 개념 및 아키텍쳐를 이해해야하고 이로 인해 서비스의 복잡도 또한 증가하게 됩니다. 따라서 쿠버네티스 플랫폼을 제공하는 Provider의 입장에서는 운영에 있어 모범 사례를 구축하기 위해 어플리케이션의 구성 및 배포 방법을 추상화시켜 제공할 필요성이 존재합니다.

하지만 추상화를 달성할 때, 어느 정도의 추상화를 제공할지에 대한 고민이 필요합니다. 고수준의 추상화를 달성하면 개발자가 운영에 있어 모범 사례를 준수하도록 만들 수 있지만, 지나친 추상화는 세부 설정에 대해 접근을 어렵게하고, 닫힌 시스템이 될 위험이 존재합니다. 따라서 어느정도의 추상화를 달성할지에 대한 고민과 설계가 동반되어야 합니다.

추상화를 제공하는 방법은 일반적으로 2가지 방법이 존재합니다. 첫 번째는 쿠버네티스를 외부로 부터 감추고 플랫폼을 사용하는 개발자는 쿠버네티스의 존재를 알지 못한채 사용하는 방법입니다. 두 번째는 쿠버네티스 API 서버를 통해 새로운 리소스를 동적으로 추가하는 방법입니다. 플랫폼의 사용자의 유스 케이스가 명확하고 사용 편의성이 중요하다면 첫 번째 방법을 사용하는 것이 좋습니다. 하지만 어플리케이션 배포와 같이 유스케이스가 다양한 경우에는 API 서버 확장을 통해 제공하는 것이 다양한 유스케이스에 대응하기 좋습니다. 또한 확장의 경우에는 쿠버네티스 생태계에 존재하는 다양한 도구를 사용할 수 있는 장점도 존재합니다.

---

쿠버네티스를 확장하기 위한 방법으로 아래와 같은 방법이 존재합니다.

사이드카 컨테이너

사이드카 컨테이너는 메인 애플리케이션 컨테이너와 함께 실행되는 컨테이너로써 비즈니스 로직이 아닌 별도의 로직을 제공하기 위한 방법입니다. 예를 들면, 사이드카 컨테이너를 통해 로그를 전송하거나 서비스 메시 플랫폼에서 프록시 네트워크를 담당하는 것과 같이 사용할 수 있습니다.

어드미션 컨트롤러

어드미션 컨트롤러는 쿠버네티스 API 요청이 etcd에 저장되기 전에 유효성 검증과 같은 추가 기능을 수행할 수 있는 방법입니다. 

CRD

CRD는 쿠버네티스 클러스터에 사용자가 정의한 새로운 리소스를 추가하는 방법입니다. CRD를 사용하면 고수준의 추상화된 리소스를 제공할 수 있습니다. 예를 들면 Elasticsearch라는 CRD를 정의하면 이를 생성하면 자동으로 Elasticsearch Cluster를 생성해주는 방식으로 사용할 수 있습니다. CRD와 관련된 내용은 Operator SDK 관련 글을 통해 자세한 내용을 확인할 수 있습니다.

---

이번 글에서는 사이드카 컨테이너나 CRD는 기존에 사용해본적이 있지만 어드미션 컨트롤러에 대해서는 처음 접해보는 내용이기 때문에 어드미션 컨트롤러에 대해 자세히 알아보도록 하겠습니다. 

어드미션 컨트롤러?

어드미션 컨트롤러는 API 요청을 가로채 특정 기능을 활성화하는 방법을 의미합니다. 리소스를 정의하지 않거나 기본으로 사용되는 StorageClass가 결정되는 것의 내부에는 모두 어드미션 컨트롤러가 사용됩니다. 

아래 그림은 쿠버네티스 API가 etcd에 저장되기 전까지 흐름을 나타냅니다. 

이 그림에서 알 수 있듯이 어드미션 컨트롤러는 API 요청을 처리하는 과정 중 한 단계이며 요청을 검증하거나 변경하는 역할을 수행할 수 있습니다. (검증 어드미션 컨트롤러는 요청을 수정할 수 없는 반면에 변경 어드미션 컨트롤러는 요청을 수정할 수 있습니다.)

종류

어드미션 컨트롤러에는 standard와 dynamic이라는 2가지 등급이 존재합니다. standard는 API 서버와 함께 컴파일되고, API가 시작될 때 설정해야하는 컨트롤러를 의미합니다. dynamic는 런타임 시점에 설정할 수 있는 컨트롤러로써 쿠버네티스의 외부에서 개발됩니다. (dynamic 어드미션 컨트롤러는 HTTP 콜백을 통해 요청을 받는 webhook이 유일하게 존재합니다.)

Standard

쿠버네티스에는 default로 제공되는 standard 어드미션 컨트롤러가 존재합니다. 각각의 어드미션 컨트롤러가 수행하는 역할은 쿠버네티스 문서에서 확인하실 수 있습니다.
API 서버에 `--enable-admission-plugins=<controller-name-1>,<controller-name-2>`의 형태로 설정을 추가함으로써 원하는 어드미션 컨트롤러를 활성화할 수 있습니다. 

Dynamic

쿠버네티스에서 제공하는 기본 어드미션 컨트롤러이외에 특정한 유스케이스를 대응하기 위한 어드미션 컨트롤러를 정의할 수도 있습니다. 이 때 사용되는 플러그인이 MutatingAdmissionWebhook과 ValidatingAdmissionWebhook입니다. MutatiingAdmissionWebhook은 요청의 변경, ValidatingAdmissionWebhook은 요청의 검증을 수행하게 됩니다. 위의 그림에서처럼 webhook 부분을 직접 개발함으로써 커스텀한 변경, 검증 로직을 추가할 수 있습니다.

---

Webhook 동작 과정

먼저, WebHook이 동작하는 과정은 다음과 같습니다. 

1. Mutating/ValidatingWebhookController는 AdmissionRequest를 webhook server에 POST로 요청을 전송합니다.

• AdmissionRequest에는 AdmissionReview라는 객체를 가지고 있으며 이 객체는 API server가 클라이언트로부터 받은 메니페스트를 담고 있는 객체입니다.

2. Webhook Server는 원하는 로직을 수행하여 요청의 유효성을 검증하거나 요청을 변경하고 이에 대한 응답을 AdmissionResponse 형태로 보냅니다.

• AdmissionResponse는 webhook server에서 admission controller에게 요청에 대한 결과를 담고 있는 객체입니다. AdmissionResponse는 UID, Allowed, Status와 같은 필드가 존재합니다. UID는 webhook server가 받은 AdmissionReview와 동일한 UID를 반환해줘야합니다. Allowed는 해당 요청을 승인할지, 거절할지에 대한 표시로 이에 대한 상태값으로 Status를 넘겨주는 것도 가능합니다. 
• Allowed가 True이고 MutatingAdmissionController의 경우, webhook server는 원본 요청을 수정하여 전송할 수도 있습니다. 이 때 수정된 부분을 알려주는 방법으로 현재 Kubernetes는 JSON patch 방법만 지원합니다.

JSON Patch

간략하게 JSON Patch 방법에 대해 예시를 들어보겠습니다. 만약, Deployment의 replicas수가 지정되어 있지 않은 경우, 기본적으로 3이라는 값을 설정해주는 상황을 가정해보겠습니다. 이 때, 해당하는 JSON patch는 다음과 같습니다.

[{"op": "add", "path": "/spec/replicas", "value": 3}]

이 JSON Patch를 전송하기 위해서는 patchType으로 JSONPatch를 patch 값으로 위의 JSON을 base64로 인코딩한 데이터를 넣어줘야 합니다. 최종적으로 생성되는 Response는 다음과 같습니다.

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<value from request.uid>",
    "allowed": true,
    "patchType": "JSONPatch",
    "patch": "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0="
  }
}

---

Custom Mutating Webhook 개발

위의 설명을 기반으로 커스텀한 mutating을 수행하는 webhook 서버를 만들어보겠습니다. 시나리오로는 inject annotation이 존재하는 deployment가 생성될 때, init container를 inject해주는 기능이 필요하다고 가정해보겠습니다.

인증서 발급

Admission Controller는 Webhook Server와 HTTPS를 통해 통신하기 떄문에, 가장 먼저 해야할 작업은 Webhook Server에서 필요한 인증서를 발급받는 일입니다. 여기서 주의할 점은 Common Name에 대한 설정입니다. alice_k106님의 글을 참고하면 인증서의 Common Name으로 쿠버네티스 내부 DNS에서 사용되는 이름을 지정해야 합니다. 제가 생성할 서비스의 이름은 mutate-server-svc, 네임스페이스는 mutate-webhook이기 때문에 최종적으로 mutate-server-svc.mutate-webhook.svc라는 이름으로 CN을 설정해줬습니다.

➜  mkdir certsopenssl

➜ req -nodes -new -x509 -keyout certs/ca.key -out certs/ca.crt -subj "/CN=Admission Controller Demo"

➜ openssl genrsa -out certs/admission-tls.key 2048

➜ openssl req -new -key certs/admission-tls.key -subj "/CN=mutate-server-svc.mutate-webhook.svc" | openssl x509 -req -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/admission-tls.crt

---

TLS Secret 생성

다음으로 위에서 발급받은 인증서를 Mutate Webhook Server에서 사용하기 위해 TLS Secret을 생성해줍니다.

➜  kubectl create -n mutate-webhook secret tls admission-tls \ --cert "certs/admission-tls.crt" \ --key "certs/admission-tls.key"

---

Mutate Webhook Server

제가 수행할 Mutate 로직은 Deployment의 initContainer 필드에 사전에 정의한 메니페스트를 추가하는 로직입니다. github.com/morvencao/kube-mutating-webhook-tutorial 을 참고해 제가 필요한 로직으로 수정하여 구축한 Webhook Server는 Github에서 확인하실 수 있습니다. 

간단하게 설명하면 먼저 AdmissionReview 객체를 받아 Deployment에 대한 정보를 얻어옵니다.

func (ws WebhookServer) mutate(admissionReview *admissionv1.AdmissionReview) *admissionv1.AdmissionResponse {
	request := admissionReview.Request
	var deployment appv1.Deployment
	if err := json.Unmarshal(request.Object.Raw, &deployment); err != nil {
		log.Errorf("Couldn't unmarshall raw object : %v", err)
		return &admissionv1.AdmissionResponse{
			Result: &metav1.Status{
				Message: err.Error(),
			},
		}
	}
    ....

 

해당 Deployment에 대해 Mutation 대상(Init Container를 추가할 대상)인지 판단합니다. 저는 init-container-injector-webhook.sphong.com/inject = "true" 어노테이션을 통해 Mutation 대상을 선정하였습니다.

func isMutationTarget(ignoreNamespaces []string, metadata *metav1.ObjectMeta) bool {
	...

	annotation := metadata.GetAnnotations()
	if annotation == nil {
		annotation = make(map[string]string)
	}

	status := annotation[admissionWebhookAnnotationInjectKey]
	if strings.ToLower(status) == "true" {
		return true
	}
	return false
    
}

 

 

Mutataion Target인 경우, init container 필드에 기존에 정의한 메니페스트를 추가해줍니다. 또한, 다음번부터 mutation의 대상이 되지 않도록 init-container-injector-webhook.sphong.com/inject = "injected"로 업데이트합니다. 위에서 언급했던 것처럼 이런 추가, 업데이트에 대한 정보는 JSON Patch를 통해 전달합니다.

func createPatch(deployment *appv1.Deployment, config *Config, annotations map[string]string) ([]byte, error) {
	var patch []patchOperation
	patch = append(patch, addInitContainer(deployment.Spec.Template.Spec.InitContainers, config.Containers, "/spec/template/spec/initContainers")...)
	patch = append(patch, updateAnnotation(deployment.Annotations, annotations)...)

	return json.Marshal(patch)
}

 

최종적으로 AdmissionReview객체를 생성해서 응답을 Admission Controller에게 전송합니다. 

func (ws WebhookServer) Serve(responseWriter http.ResponseWriter, request *http.Request) {
	...
    // 응답을 담을 객체
    var admissionResponse *admissionv1.AdmissionResponse
    
    // Webhook Server가 받은 AdmissionReview 객체 (원본)
	originAdmissionReview := admissionv1.AdmissionReview{}
    
    // Deserializer 
	if _, _, err := deserializer.Decode(requestBody, nil, &originAdmissionReview); err != nil {
		log.Errorf("Can't decode request body: %v", err)
		admissionResponse = &admissionv1.AdmissionResponse{
			Result: &metav1.Status{
				Message: err.Error(),
			},
		}
	} else {
    	// Mutate Login 수행
		admissionResponse = ws.mutate(&originAdmissionReview)
	}

	// Admission Review 객체의 TypeMeta 필드가 Required이기 때문에 명시적으로 정의해줘야 한다.
	typeMeta := metav1.TypeMeta{
		Kind:       "AdmissionReview",
		APIVersion: "admission.k8s.io/v1",
	}
	
    // 응답을 위한 AdmissionReview 객체
	mutatedAdmissionReview := admissionv1.AdmissionReview{TypeMeta: typeMeta}
	mutatedAdmissionReview.Response = admissionResponse
	
    // UID는 Request AdmissionReview 객체의 UID와 동일
    if originAdmissionReview.Request != nil {
		mutatedAdmissionReview.Response.UID = originAdmissionReview.Request.UID
	}
    
    // return json response
    data, err := json.Marshal(mutatedAdmissionReview)
    if _, err := responseWriter.Write(data); err != nil {
		log.Errorf("Can't Write Response : %v", err)
		http.Error(responseWriter, fmt.Sprintf("Can't write response : %v", err), http.StatusInternalServerError)
	}
    ...
    

---

Webhook Server Deployment

해당 서버에 대해 Deployment와 Service를 생성합니다.  이 때, 앞서 생성한 tls 시크릿과 init container에 대한 설정을 마운트 해줍니다.

Deployment

Service

---

 

Mutate Webhook Configuration 

다음으로 Mutate Webhook에 대한 ConfigMap을 생성합니다. 이 설정을 통해 mutate server에 대한 연결 정보와 caBundle, 언제 mutate webhook이 실행될지에 대해 정의할 수 있습니다. 

위에서 생성한 ca.crt를 통해 CA_BUNDLE 값을 채워주고 ConfigMap을 생성하면 앞으로 Deployment를 생성할 떄마다 Mutate 로직을 수행하게 됩니다.

➜ export CA_BUNDLE=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.ca\.crt}")

➜ export CA_BUNDLE=$(cat certs/ca.crt | base64 | tr -d '\n')

➜ cat deploy/webhook-config.yaml | sed "s|\${CA_BUNDLE}|${CA_BUNDLE}|g" | kubectl apply -n mutate-webhook -f -

---

최종적으로 아래의 Deployment를 생성해 MutatingWebhook이 정상적으로 동작하는지 확인해보겠습니다.

확인해보면 nginx-deployment에 속하는 Pod들은 Init Container 설정이 추가된 것을 확인할 수 있습니다. 

Result

---

이번글에서는 쿠버네티스에서 고수준의 추상화를 제공할 수 있는 방법 중 하나인 Admission Controller에 대해서 알아보았습니다. 사용된 모든 코드는 Github에서 확인하실 수 있습니다.

참고자료

- kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

- kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

- blog.naver.com/alice_k106/221546328906

- github.com/morvencao/kube-mutating-webhook-tutorial