1. 아키텍처 비교
1.1 Kyverno
- Kubernetes 네이티브 설계
- 3개의 컨트롤러: Admission, Background, Reports
- 정책이 Kubernetes CRD(ClusterPolicy/Policy)
- 하나의 프로젝트에서 validate, mutate, generate, verifyImages 모두 지원
1.2 OPA/Gatekeeper
- OPA는 범용 정책 엔진, Gatekeeper는 Kubernetes 어댑터
- Webhook Controller + Audit Controller
- ConstraintTemplate(정책 스키마) + Constraint(정책 인스턴스) 2계층 모델
- validate 중심, mutation은 Gatekeeper v3.10+에서 별도 알파 지원
2. 정책 언어 비교
2.1 Kyverno: YAML + CEL
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-labels
spec:
validationFailureAction: Enforce
rules:
- name: check-app-label
match:
any:
- resources:
kinds:
- Deployment
validate:
message: "Label 'app.kubernetes.io/name' is required"
pattern:
metadata:
labels:
app.kubernetes.io/name: '?*'
2.2 OPA/Gatekeeper: Rego
ConstraintTemplate 정의
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
spec:
crd:
spec:
names:
kind: K8sRequiredLabels
validation:
openAPIV3Schema:
type: object
properties:
labels:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[_]}
missing := required - provided
count(missing) > 0
msg := sprintf("Missing required labels: %v", [missing])
}
Constraint 인스턴스
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: require-app-label
spec:
match:
kinds:
- apiGroups: ['apps']
kinds: ['Deployment']
parameters:
labels:
- 'app.kubernetes.io/name'
2.3 비교 요약
| 항목 | Kyverno | OPA/Gatekeeper |
| --------- | --------------------------- | ----------------------------------- |
| 정책 언어 | YAML + CEL | Rego |
| 학습 곡선 | 낮음 (K8s YAML 경험 활용) | 높음 (Rego 별도 학습) |
| 정책 구조 | ClusterPolicy 1개 리소스 | ConstraintTemplate + Constraint 2개 |
| 재사용성 | include/exclude로 범위 조정 | ConstraintTemplate으로 파라미터화 |
| 표현력 | 패턴 매칭 + CEL | Rego (튜링 완전) |
| 디버깅 | kubectl + 정책 보고서 | OPA playground + Rego 테스트 |
3. 기능 비교
3.1 Validation
| 기능 | Kyverno | OPA/Gatekeeper |
| ---------------- | ------------------- | ---------------------- |
| 패턴 매칭 | 네이티브 지원 | Rego로 구현 |
| CEL 지원 | 지원 | v3.16+ 지원 |
| 조건부 검증 | 앵커 시스템 | Rego 로직 |
| foreach | 지원 | Rego 반복문 |
| 외부 데이터 참조 | API call, ConfigMap | External Data Provider |
3.2 Mutation
| 기능 | Kyverno | OPA/Gatekeeper |
| --------------------- | ------- | ------------------ |
| Strategic Merge Patch | 지원 | 미지원 |
| JSON Patch | 지원 | 알파 지원 (v3.10+) |
| 조건부 변형 | 지원 | 제한적 |
| foreach 변형 | 지원 | 미지원 |
3.3 Generation
| 기능 | Kyverno | OPA/Gatekeeper |
| ---------------- | ------------- | -------------- |
| 리소스 자동 생성 | 네이티브 지원 | 미지원 |
| 리소스 클론 | 지원 | 미지원 |
| 동기화 | 지원 | 미지원 |
3.4 Image Verification
| 기능 | Kyverno | OPA/Gatekeeper |
| ---------------- | ------------- | -------------- |
| cosign 서명 검증 | 네이티브 지원 | 외부 도구 필요 |
| Notary v2 | 지원 | 미지원 |
| Attestation 검증 | 지원 | 외부 도구 필요 |
| SBOM 검증 | 지원 | 미지원 |
4. 성능 비교
4.1 Webhook 레이턴시
일반적인 정책 수에서의 평균 레이턴시:
| 정책 수 | Kyverno | OPA/Gatekeeper |
| ------- | ------- | -------------- |
| 10개 | ~5ms | ~3ms |
| 50개 | ~15ms | ~8ms |
| 100개 | ~30ms | ~15ms |
| 500개 | ~80ms | ~40ms |
OPA/Gatekeeper는 Rego 정책을 미리 컴파일하여 평가 속도가 빠르지만, Kyverno는 YAML 파싱 오버헤드가 있습니다.
4.2 메모리 사용량
| 구성 | Kyverno | OPA/Gatekeeper |
| ---------------- | ------- | -------------- |
| 기본 설치 | ~200MB | ~150MB |
| 100개 정책 | ~500MB | ~300MB |
| 리포트 활성화 시 | +200MB | +100MB (Audit) |
4.3 성능 최적화 팁
**Kyverno:**
- match/exclude를 세밀하게 설정하여 불필요한 정책 평가 방지
- webhookTimeoutSeconds 적절히 설정
- Reports Controller 별도 스케일링
**OPA/Gatekeeper:**
- Data Sync 최소화
- Constraint 범위를 좁게 설정
- Audit 주기 최적화
5. 생태계 비교
5.1 정책 라이브러리
| 항목 | Kyverno | OPA/Gatekeeper |
| ---------------------- | -------------------------- | ------------------ |
| 공식 정책 수 | 300+ (kyverno.io/policies) | 200+ (OPA Library) |
| Pod Security Standards | 내장 정책 제공 | 별도 라이브러리 |
| 커뮤니티 | CNCF Incubating | CNCF Graduated |
5.2 도구 통합
| 도구 | Kyverno | OPA/Gatekeeper |
| ---------- | ------------- | -------------- |
| ArgoCD | 지원 | 지원 |
| Flux | 지원 | 지원 |
| Backstage | 플러그인 있음 | 플러그인 있음 |
| Prometheus | 메트릭 내장 | 메트릭 내장 |
6. 마이그레이션 가이드
6.1 OPA에서 Kyverno로
1. ConstraintTemplate의 Rego 로직을 Kyverno YAML 패턴으로 변환
2. Constraint의 match 조건을 Kyverno match/exclude로 변환
3. 파라미터를 Kyverno 변수(JMESPath, context)로 대체
4. Audit 모드로 먼저 배포하여 동작 검증
5. 점진적으로 Enforce 모드로 전환
6.2 선택 가이드
**Kyverno를 선택할 때:**
- Kubernetes 전용 환경
- YAML에 익숙한 팀
- mutation, generation, image verification이 필요한 경우
- 학습 곡선을 최소화하고 싶은 경우
**OPA/Gatekeeper를 선택할 때:**
- Kubernetes 외 환경에서도 OPA를 사용하는 경우
- 복잡한 정책 로직이 필요한 경우 (Rego의 표현력)
- 대규모 정책에서 성능이 중요한 경우
- 이미 Rego에 익숙한 팀
7. 정리
| 비교 항목 | Kyverno | OPA/Gatekeeper |
| ------------- | ---------------------- | ---------------------- |
| 접근성 | 높음 (YAML 기반) | 중간 (Rego 학습 필요) |
| 기능 범위 | 넓음 (4가지 규칙 타입) | 좁음 (validation 중심) |
| 성능 | 보통 | 우수 |
| 표현력 | 보통 (CEL로 보완) | 높음 (Rego) |
| 이미지 검증 | 네이티브 | 외부 도구 필요 |
| 생태계 성숙도 | Incubating | Graduated |
두 도구 모두 프로덕션에서 검증되었으며, 팀의 역량과 요구사항에 따라 선택하면 됩니다.
현재 단락 (1/155)
- Kubernetes 네이티브 설계