day-log

올해 2월에 Kyverno 1.17이 나오면서 재밌는 변화가 하나 있었다. ClusterPolicy와 CleanupPolicy가 공식적으로 Deprecated로 마킹된 것. 아직 지워지진 않았지만, Kyverno 팀이 CEL(Common Expression Language) 중심 아키텍처로 방향을 확 틀었다는 신호다. 우리 팀은 지난달부터 조금씩 이 전환을 시작했는데, 처음 시작하는 팀들을 위해 몇 가지 정리해두려고 한다.왜 갑자기 CEL인가간단히 말하면, Kubernetes 자체가 1.30부터 ValidatingAdmissionPolicy(VAP)를 GA로 넣으면서 admission control 계층에 CEL 기반 표현식을 표준으로 밀기 시작했다. Kyverno가 오랫동안 자체 DSL로 정책을 표현해..

정책 엔진 이야기다. 두 달 전쯤 팀 내부에서 Kyverno로 다 밀어붙이던 policy를 재정비하기로 했다. 계기는 별거 아니다. 신규 클러스터를 하나 더 세팅하는데 Kyverno controller 파드가 죽었다는 알람이 새벽에 두 번 울렸고, 새벽에 눈 뜬 내가 생각했다. "이거, 정말 다 Kyverno여야 되나."Kubernetes 1.30에서 ValidatingAdmissionPolicy(이하 VAP)가 GA된 게 2024년 4월이다. 지금은 2026년 중반이니 GA된 지 2년이 넘었고, EKS든 GKE든 안정 채널에서 이미 쓸 수 있는 상태다. CEL 기반이라 API 서버 안에서 바로 평가되고, 웹훅이 없다. 이 두 가지가 결국 우리 결정의 핵심이 됐다.Kyverno 하나로 밀어붙였을 때의 문..

Kyverno ClusterPolicy를 ValidatingPolicy(CEL)로 옮기는 법Kyverno가 3월 KubeCon EU 암스테르담에서 CNCF graduated 프로젝트로 승격됐다. 같은 흐름에서 1.17부터 CEL 기반의 새 정책 타입(ValidatingPolicy, MutatingPolicy 등)이 GA로 바뀌었고, 기존 ClusterPolicy API는 2026년 10월 제거 예정이라는 공지가 같이 나왔다. 우리 팀은 그동안 ClusterPolicy로 30개 가까운 정책을 운영하고 있었는데, 일정상 7월까지는 옮겨야 한다. 이번 글은 그 마이그레이션 작업을 하면서 정리한 가이드다.대상 독자는 Kyverno를 이미 한 번이라도 운영해 본 사람이다. CEL 자체가 처음이라면 마지막 섹션의 ..

작년쯤 Kubernetes 1.30이 풀리고 ValidatingAdmissionPolicy(이하 VAP)가 정식으로 GA되었을 때, 솔직히 의심이 좀 있었다. CEL로 정책을 쓴다는 발상 자체는 깔끔한데, Kyverno 같은 PaC(Policy-as-Code) 엔진이 이미 잘 돌아가는 클러스터에서 굳이 또 한 겹을 더 얹을 필요가 있나 싶었다. 그러다 작년 말쯤 우리 팀에서도 일부 정책을 VAP로 옮기는 실험을 시작했고, 6개월쯤 지난 지금 시점에 정리해두면 좋겠다는 생각이 들었다.결론부터 적자면, 모든 걸 VAP로 옮길 일은 없다. 그럼에도 옮길 가치가 있는 정책이 분명히 있다. 그 경계가 어디에 있는지가 이 글의 본론이다.왜 VAP를 썼나원래 우리 클러스터에서는 Kyverno 하나로 모든 admiss..