🏗️ Kyverno 아키텍처: 왜 "Kubernetes Native"인가?

안녕하세요! 오늘은 쿠버네티스 운영의 필수 아이템이자, KCA 시험의 핵심 주제인 Kyverno의 아키텍처와 그 속을 채우고 있는 핵심 구성 요소들에 대해 아주 깊숙이 파헤쳐 보겠습니다. 🕵️‍♂️

쿠버네티스를 운영하다 보면 "누가 내 클러스터에 보안 설정도 안 된 Pod을 올렸지?"라는 고민을 하게 됩니다. 이때 구원 투수로 등판하는 것이 바로 Kyverno입니다. 이 친구가 내부적으로 어떻게 움직이는지 알면 운영과 트러블슈팅이 훨씬 쉬워집니다.

 

Kyverno를 설명할 때 가장 많이 나오는 단어가 "Kubernetes Native"입니다. 이는 Kyverno가 쿠버네티스의 기존 메커니즘을 그대로 활용하기 때문인데요.

 

가장 중요한 개념은 Admission Webhooks입니다. 쿠버네티스 API 서버에 리소스 생성/수정 요청이 들어오면, API 서버는 이 요청을 처리하기 전에 Kyverno에게 "이거 괜찮아?"라고 물어봅니다. Kyverno는 설정된 정책(Policy)을 바탕으로 승인, 거부, 혹은 수정을 제안하죠.

https://kyverno.io/docs/introduction/how-kyverno-works/

---

🧩 Kyverno의 3대 핵심 구성 요소 (Core Components)

Kyverno 설치 시 생성되는 주요 Pod들을 중심으로 각 컨트롤러가 어떤 역할을 수행하는지 상세히 알아봅시다.

1. Admission Controller (The Gatekeeper) 🛡️

Kyverno의 심장부입니다. 모든 MutatingWebhook과 ValidatingWebhook 요청을 직접 처리합니다.

• Mutation (변형): 요청이 들어오면 설정된 정책에 따라 리소스의 내용을 자동으로 수정합니다. 예를 들어, 모든 Pod에 특정 레이블을 넣거나 사이드카 컨테이너를 주입하는 일을 합니다.
• Validation (검증): 리소스가 보안 규칙을 잘 지켰는지 확인합니다. "Privileged 모드는 안 돼!"라고 설정했다면, 이를 위반한 요청을 즉시 차단(Enforce)하거나 보고서에 기록(Audit)합니다.
• Generation (생성): 새로운 네임스페이스가 생길 때 기본 NetworkPolicy나 Role 등을 자동으로 만들어줍니다.

2. Background Controller (The Auditor) 📋

Admission Controller가 "현재 들어오는 요청"에 집중한다면, Background Controller는 "이미 클러스터에 떠 있는 리소스"들을 감시합니다.

• Policy 적용 확인: 정책이 나중에 만들어졌을 경우, 기존에 이미 실행 중인 Pod들이 새 정책을 잘 지키고 있는지 스캔합니다.
• 보고서 생성: 주기적으로 클러스터를 훑으며 정책 위반 사항을 정리하여 PolicyReport를 생성합니다. 덕분에 관리자는 실시간 요청 차단뿐만 아니라 클러스터의 전반적인 건강 상태를 확인할 수 있습니다.

3. Cleanup Controller (The Janitor) 🧹

Kyverno 1.9 버전부터 도입된 구성 요소로, 클러스터 내의 지저분한 리소스들을 청소하는 역할을 전담합니다.

• 유효 기간 설정: 특정 리소스에 "1시간 뒤에 삭제해"라는 정책을 걸어두면, 이 컨트롤러가 시간을 체크하다가 삭제해 버립니다.
• 임시 리소스 관리: 테스트용으로 생성한 리소스나 유효 기간이 지난 인증서 등을 자동으로 정리하여 클러스터 자원을 아껴줍니다.

---

🔄 정책 처리 흐름: 요청부터 실행까지

리소스를 생성할 때 Kyverno 내부에서 일어나는 일을 순서대로 따라가 봅시다.

1. API 요청 발송: 사용자가 kubectl apply -f pod.yaml 명령을 내립니다.
2. Mutating Webhook: API 서버가 Kyverno에 요청을 보냅니다. Kyverno는 필요한 설정을 주입(Mutate)하고 결과를 돌려줍니다.
3. Object Schema Validation: API 서버가 수정된 리소스의 형식이 맞는지 자체 검증합니다.
4. Validating Webhook: 다시 한번 Kyverno에 묻습니다. "이제 진짜 생성해도 돼?" Kyverno는 최종 검토(Validate) 후 승인 또는 거절을 결정합니다.
5. Persistence: 모든 관문을 통과하면 etcd에 데이터가 저장되고 리소스가 생성됩니다.

---

🛠️ 운영자를 위한 꿀팁: 트러블슈팅 포인트

Kyverno가 갑자기 작동하지 않는다면 다음 세 가지를 먼저 체크하세요!

• Webhook 인증서 확인: Kyverno는 API 서버와 TLS 통신을 합니다. 인증서가 만료되거나 설정이 꼬이면 모든 API 요청이 멈출 수 있으므로 cert-manager 활용을 권장합니다.
• Resource Filters: 가끔 "왜 이 Pod은 정책이 안 먹지?" 싶을 때가 있습니다. Kyverno 기본 설정에서 특정 네임스페이스(kube-system 등)가 필터링되어 제외되어 있는지 확인해 보세요.
• Admission Report: 정책이 적용되지 않는 이유는 PolicyReport 커스텀 리소스에 상세히 기록되어 있습니다. kubectl get polr 명령어를 적극 활용하세요.

---

🌟 마치며

Kyverno는 단순한 보안 도구를 넘어, 쿠버네티스 운영의 자동화와 표준화를 이끄는 강력한 프레임워크입니다. 아키텍처를 이해하는 것은 그 강력한 기능을 100% 활용하기 위한 첫걸음이죠.

 

오늘 설명해 드린 Admission, Background, Cleanup이라는 세 명의 관리자가 클러스터를 어떻게 지키고 있는지 머릿속에 그려보신다면, Kyverno 시험(KCA)은 물론 실무에서도 전문가 포스를 뽐내실 수 있을 겁니다! 🚀