- 1. CNPE란?
- 2. 시험 도메인 개요
- 3. Domain 1: GitOps 및 지속적 배포 (25%)
- 4. Domain 2: 플랫폼 API 및 셀프 서비스 (25%)
- 5. Domain 3: 관측성 및 운영 (20%)
- 6. Domain 4: 플랫폼 아키텍처 및 인프라 (15%)
- 7. Domain 5: 보안 및 정책 적용 (15%)
- 8. 추천 학습 계획 (12주)
- 9. 필수 학습 리소스
- References
1. CNPE란?
CNPE(Certified Cloud Native Platform Engineer)는 CNCF에서 2025년 11월에 공식 발표한 최고급 수준의 자격증이다. 엔터프라이즈 규모의 내부 개발자 플랫폼(IDP)을 설계하고 운영하는 고급 실무 역량을 검증한다.
CNCF CTO Chris Aniszczyk가 밝힌 바에 따르면, 이 자격증은 "플랫폼 아키텍처, GitOps, Observability, 보안, 개발자 경험을 아우르는 프로덕션 수준의 클라우드 네이티브 시스템 역량"을 인증한다.
1.1 시험 형식
| 항목 | 내용 |
|---|---|
| 시간 | 120분 |
| 형식 | 100% 실습형(Performance-based), 온라인 감독 |
| 환경 | Linux 기반 원격 데스크톱 (터미널 + 웹 인터페이스) |
| 오픈북 | kubernetes.io/docs 및 과제별 Quick Reference 문서 참조 가능 |
| 응시료 | $445 USD |
| 재응시 | 1회 무료 포함 |
| 유효기간 | 2년 |
| 시뮬레이터 | Killer.sh 2회 포함 |
1.2 선행 요건
공식적인 필수 선행 요건은 없으나, CNPA(Certified Cloud Native Platform Associate) 또는 CKA 수준의 Kubernetes 관리 경험이 강력히 권장된다.
1.3 대상
- 숙련된 Platform Engineer
- Senior DevOps / SRE
- Platform Architect
- Infrastructure Engineer
2. 시험 도메인 개요
CNPE 시험은 5개 핵심 도메인으로 구성된다.
| 도메인 | 비중 |
|---|---|
| GitOps 및 지속적 배포 (GitOps and Continuous Delivery) | 25% |
| 플랫폼 API 및 셀프 서비스 (Platform APIs and Self-Service Capabilities) | 25% |
| 관측성 및 운영 (Observability and Operations) | 20% |
| 플랫폼 아키텍처 및 인프라 (Platform Architecture and Infrastructure) | 15% |
| 보안 및 정책 적용 (Security and Policy Enforcement) | 15% |
업계에서 자주 언급되는 레퍼런스 아키텍처는 BACK 스택: Backstage + Argo CD + Crossplane + Kyverno이다. 단, 시험은 벤더 중립적이므로 Argo CD 대신 Flux, Kyverno 대신 OPA/Gatekeeper 등으로 대체 가능하다.
3. Domain 1: GitOps 및 지속적 배포 (25%)
3.1 GitOps 핵심 원칙
OpenGitOps(opengitops.dev)에서 정의한 4가지 핵심 원칙이다.
| 원칙 | 설명 |
|---|---|
| Declarative | 시스템의 원하는 상태를 선언적으로 표현한다 |
| Versioned and Immutable | 원하는 상태를 Git에 저장하여 변경 이력을 추적한다 |
| Pulled Automatically | 에이전트가 소스에서 원하는 상태를 자동으로 가져온다 (Push가 아닌 Pull) |
| Continuously Reconciled | 실제 상태와 원하는 상태의 차이를 지속적으로 감지하고 자동 복원한다 |
3.2 Argo CD 아키텍처
Argo CD는 Kubernetes를 위한 선언적 GitOps CD 도구로, 3개의 핵심 컴포넌트로 구성된다.
- API Server (
argocd-server): gRPC/REST 서버로 Web UI와 CLI API를 제공한다. 애플리케이션 관리, RBAC 적용, Git webhook 수신을 담당한다. - Repository Server (
argocd-repo-server): Git 저장소의 로컬 캐시를 유지하고, 리비전과 경로에 따른 Kubernetes 매니페스트를 생성한다. - Application Controller (
argocd-application-controller): 실행 중인 애플리케이션을 지속 감시하며, 현재 상태와 Git의 목표 상태를 비교하여 OutOfSync를 탐지한다.
Application CRD 예시:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true # Git에서 제거된 리소스 삭제
selfHeal: true # 수동 변경 자동 복원
3.3 Argo CD Sync 정책
| 정책 | 기본값 | 설명 |
|---|---|---|
automated | disabled | OutOfSync 감지 시 자동 동기화 |
prune | false | Git에서 삭제된 리소스를 클러스터에서도 제거 |
selfHeal | false | 클러스터의 수동 변경(drift)을 Git 상태로 자동 복원 |
allowEmpty | false | 매니페스트가 0개일 때 동기화 허용 여부 |
3.4 ApplicationSet으로 멀티 클러스터 배포
ApplicationSet은 단일 템플릿에서 여러 Application 리소스를 생성하는 CRD다. Generator를 통해 파라미터를 동적으로 생성한다.
주요 Generator:
| Generator | 설명 |
|---|---|
| Cluster | Argo CD에 등록된 클러스터 자동 탐지 |
| Git Directory | 리포지토리의 디렉토리 구조에서 앱 생성 |
| Matrix | 두 Generator의 파라미터를 조합 (Cartesian Product) |
| Pull Request | 열린 PR마다 프리뷰 환경 생성 |
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: cluster-apps
namespace: argocd
spec:
generators:
- clusters:
selector:
matchLabels:
env: production
template:
metadata:
name: '{{.name}}-my-app'
spec:
project: default
source:
repoURL: https://github.com/myorg/apps.git
targetRevision: HEAD
path: deploy/production
destination:
server: '{{.server}}'
namespace: my-app
3.5 Flux CD
Flux는 CNCF GitOps Toolkit 기반의 CD 도구로, 5개의 전문화된 컨트롤러로 구성된다.
| 컨트롤러 | CRD | 역할 |
|---|---|---|
| Source Controller | GitRepository, HelmRepository, OCIRepository | Git/Helm/OCI에서 아티팩트 가져오기 |
| Kustomize Controller | Kustomization | Kustomize 오버레이 또는 Plain YAML 적용 |
| Helm Controller | HelmRelease | Helm 차트 라이프사이클 관리 |
| Notification Controller | Provider, Alert, Receiver | 알림 발송 및 인바운드 웹훅 처리 |
| Image Automation | ImageRepository, ImagePolicy | 컨테이너 레지스트리 스캔 및 자동 업데이트 |
Flux Kustomization 예시:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: my-app
namespace: flux-system
spec:
interval: 10m
sourceRef:
kind: GitRepository
name: my-app
path: ./deploy/production
prune: true
wait: true
dependsOn:
- name: cert-manager
- name: ingress-nginx
postBuild:
substitute:
CLUSTER_NAME: production
DOMAIN: example.com
3.6 Progressive Delivery: Argo Rollouts
Argo Rollouts는 Canary, Blue-Green 등의 점진적 배포 전략을 자동화한다.
Canary 배포 예시:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
canaryService: my-app-canary
stableService: my-app-stable
steps:
- setWeight: 10
- pause: { duration: 5m }
- analysis:
templates:
- templateName: success-rate
- setWeight: 30
- pause: { duration: 5m }
- setWeight: 60
- pause: { duration: 5m }
- setWeight: 100
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: myapp:v2
Blue-Green 배포 핵심 설정:
| 설정 | 설명 |
|---|---|
autoPromotionEnabled | 프리뷰 후 자동 프로모션 여부 (기본: true) |
autoPromotionSeconds | 자동 프로모션까지 대기 시간 |
scaleDownDelaySeconds | 이전 버전 Pod 종료까지 대기 시간 (기본: 30초) |
prePromotionAnalysis | 트래픽 전환 전 메트릭 검증 |
postPromotionAnalysis | 전환 후 검증, 실패 시 롤백 |
4. Domain 2: 플랫폼 API 및 셀프 서비스 (25%)
4.1 Crossplane으로 셀프 서비스 인프라 구축
Crossplane은 Kubernetes를 범용 Control Plane으로 확장하여 클라우드 인프라를 Kubernetes API로 프로비저닝할 수 있게 한다.
아키텍처: Provider → Managed Resources → Compositions → Composite Resources (XRDs)
Composite Resource Definition (XRD):
apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
name: mydatabases.example.org
spec:
scope: Namespaced
group: example.org
names:
kind: XMyDatabase
plural: mydatabases
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
region:
type: string
size:
type: string
required:
- region
- size
Composition (구현 템플릿):
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: example-database
spec:
compositeTypeRef:
apiVersion: example.org/v1alpha1
kind: XMyDatabase
mode: Pipeline
pipeline:
- step: patch-and-transform
functionRef:
name: function-patch-and-transform
input:
apiVersion: pt.fn.crossplane.io/v1beta1
kind: Resources
resources:
- name: rds-instance
base:
apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
spec:
forProvider:
region: us-east-2
engine: postgres
instanceClass: db.t3.micro
patches:
- type: FromCompositeFieldPath
fromFieldPath: spec.region
toFieldPath: spec.forProvider.region
셀프 서비스 패턴은 다음과 같다:
- 플랫폼 팀이 XRD(API 스키마)와 Composition(구현)을 정의한다.
- 개발자는 자신의 네임스페이스에서 XRD 인스턴스를 생성한다.
- Crossplane이 자동으로 클라우드 리소스를 프로비저닝하고 관리한다.
- 개발자는 클라우드 Provider API를 직접 다루지 않는다.
4.2 Backstage: Internal Developer Portal
Backstage(CNCF Incubating)는 Spotify가 개발한 오픈소스 IDP 프레임워크다.
핵심 기능:
| 기능 | 설명 |
|---|---|
| Software Catalog | 모든 소프트웨어 자산의 중앙 레지스트리 |
| Software Templates | 표준화된 프로젝트 생성 자동화 |
| TechDocs | Docs-like-code 방식의 기술 문서 |
| Plugin 아키텍처 | 확장 가능한 플러그인 시스템 |
Software Catalog 엔티티 정의:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: Payment processing microservice
tags:
- java
- spring-boot
spec:
type: service
lifecycle: production
owner: payments-team
system: payment-platform
dependsOn:
- resource:default/payments-db
providesApis:
- payment-api
Software Template 예시:
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: new-microservice
title: Create New Microservice
spec:
owner: platform-team
type: service
parameters:
- title: Service Details
required:
- name
- owner
properties:
name:
title: Service Name
type: string
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
steps:
- id: fetchBase
name: Fetch Template
action: fetch:template
input:
url: ./skeleton
values:
name: ${{parameters.name}}
- id: publish
name: Publish to GitHub
action: publish:github
input:
repoUrl: github.com?owner=myorg&repo=${{parameters.name}}
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: ${{steps.publish.output.repoContentsUrl}}
catalogInfoPath: /catalog-info.yaml
4.3 CRD와 Operator 패턴
플랫폼 API의 기반은 Kubernetes Custom Resource Definitions(CRD)와 Operator 패턴이다.
Operator는 도메인별 운영 지식을 Kubernetes 컨트롤러에 인코딩한다.
Control Loop:
1. Observe: Custom Resource 변경 감시
2. Analyze: 현재 상태와 목표 상태 비교
3. Act: 종속 리소스 생성/업데이트/삭제로 상태 조정
주요 Operator 프레임워크:
| 프레임워크 | 언어 |
|---|---|
| Kubebuilder | Go |
| Operator SDK | Go, Ansible, Helm |
| Kopf | Python |
| kube-rs | Rust |
| Metacontroller | 모든 언어 (웹훅 방식) |
5. Domain 3: 관측성 및 운영 (20%)
5.1 OpenTelemetry
OpenTelemetry(OTel)는 CNCF Observability 프레임워크로, 3가지 핵심 신호를 통합 수집한다.
| 신호 | 설명 | 용도 |
|---|---|---|
| Traces | 분산 시스템에서의 요청 경로 추적 | 마이크로서비스 간 요청 흐름 이해 |
| Metrics | 런타임 측정값 (Counter, Gauge, Histogram) | 성능 추세 및 리소스 사용률 모니터링 |
| Logs | 타임스탬프가 있는 이벤트 기록 | 특정 시점의 디버깅 컨텍스트 |
OTel Collector 설정:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
memory_limiter:
check_interval: 1s
limit_mib: 2000
batch:
timeout: 10s
exporters:
otlp/jaeger:
endpoint: jaeger-collector:4317
tls:
insecure: true
prometheus:
endpoint: 0.0.0.0:8889
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/jaeger]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [prometheus]
Kubernetes Auto-Instrumentation:
OTel Operator를 사용하면 코드 수정 없이 자동 계측이 가능하다.
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: demo-instrumentation
spec:
exporter:
endpoint: http://otel-collector:4318
propagators:
- tracecontext
- baggage
sampler:
type: parentbased_traceidratio
argument: '1'
Deployment에 어노테이션 추가로 자동 계측 활성화:
metadata:
annotations:
instrumentation.opentelemetry.io/inject-java: 'true' # Java
instrumentation.opentelemetry.io/inject-python: 'true' # Python
instrumentation.opentelemetry.io/inject-nodejs: 'true' # Node.js
5.2 Prometheus와 Grafana 스택
Prometheus 아키텍처:
| 컴포넌트 | 역할 |
|---|---|
| Prometheus Server | 시계열 데이터 수집 및 저장 (Pull 기반) |
| Alertmanager | 알림 라우팅, 중복 제거, 발송 |
| Exporters | 서드파티 시스템 메트릭 어댑터 |
| Service Discovery | Kubernetes, Consul, DNS 등 자동 타겟 탐지 |
ServiceMonitor CRD (Prometheus Operator):
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app-monitor
labels:
release: prometheus
spec:
selector:
matchLabels:
app: my-app
endpoints:
- port: metrics
path: /metrics
interval: 30s
PromQL 핵심 쿼리:
# 초당 요청률 (5분 윈도우)
rate(http_requests_total[5m])
# Job별 합산
sum by (job) (rate(http_requests_total[5m]))
# P99 지연시간
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# 에러율
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
Grafana 관측성 스택:
+-----------+
| Grafana | (대시보드, 알림)
+-----+-----+
|
+------------+------------+
| | |
+----+----+ +---+---+ +-----+-----+
| Mimir | | Loki | | Tempo |
| Metrics | | Logs | | Traces |
+----+----+ +---+---+ +-----+-----+
| | |
+------------+------------+
|
+--------+--------+
| OTel Collector |
+-----------------+
|
[Applications]
- Mimir: 수평 확장 가능한 장기 메트릭 저장소
- Loki: 라벨 기반 인덱싱의 경량 로그 집계 시스템
- Tempo: 대규모 분산 트레이싱 백엔드
5.3 SLI/SLO와 Error Budget
| 개념 | 정의 | 예시 |
|---|---|---|
| SLI | 서비스 성능의 정량적 측정값 | 요청 성공률, P99 지연시간 |
| SLO | SLI의 목표 범위 | "99.9%의 요청이 200ms 이내 완료" |
| SLA | SLO 미달 시 책임이 있는 계약 | "가용성 99.95% 미만 시 서비스 크레딧 제공" |
Error Budget 계산:
Error Budget = 1 - SLO
SLO 99.9% → Error Budget 0.1% → 월간 약 43.2분 다운타임 허용
SLO 99.99% → Error Budget 0.01% → 월간 약 4.32분 다운타임 허용
Error Budget 정책:
| 소진률 | 조치 |
|---|---|
| 0-50% (Green) | 정상 기능 개발 진행 |
| 50-80% (Yellow) | 안정성 중심 작업 강화, 코드 리뷰 강화 |
| 80-100% (Red) | 기능 동결, 안정성 작업에 전력 집중 |
5.4 DORA 메트릭
플랫폼 효율성을 측정하는 핵심 메트릭이다.
| 메트릭 | 설명 |
|---|---|
| Deployment Frequency | 배포 빈도 |
| Lead Time for Changes | 코드 커밋에서 프로덕션 배포까지의 시간 |
| Change Failure Rate | 배포 후 장애가 발생한 비율 |
| Mean Time to Recovery | 장애 발생부터 복구까지의 평균 시간 |
6. Domain 4: 플랫폼 아키텍처 및 인프라 (15%)
6.1 멀티 테넌시 패턴
| 패턴 | 격리 수준 | 적합한 상황 |
|---|---|---|
| Namespace 기반 | 논리적 격리 | 신뢰할 수 있는 내부 팀 |
| Cluster 기반 | 물리적 격리 | 강력한 보안 요구, 규제 환경 |
| 하이브리드 | 혼합 | 환경별 차등 격리 필요 시 |
Namespace 기반 격리 도구:
# ResourceQuota로 리소스 제한
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-quota
namespace: team-a
spec:
hard:
requests.cpu: '10'
requests.memory: 20Gi
limits.cpu: '20'
limits.memory: 40Gi
pods: '50'
---
# NetworkPolicy로 네트워크 격리
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: team-a
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
6.2 비용 관리: OpenCost
OpenCost(CNCF Sandbox)는 Kubernetes 비용 가시성과 할당을 제공하는 오픈소스 도구다. 네임스페이스, 팀, 서비스별 비용을 추적하고 리소스 Right-Sizing을 지원한다.
6.3 오토스케일링 전략
| 스케일러 | 대상 | 기준 |
|---|---|---|
| HPA | Pod 수평 확장 | CPU/메모리/커스텀 메트릭 |
| VPA | Pod 리소스 요청 조정 | 실제 사용량 분석 |
| Cluster Autoscaler | 노드 수평 확장 | Pending Pod 감지 |
| KEDA | 이벤트 기반 확장 | 큐 길이, HTTP 요청 등 |
7. Domain 5: 보안 및 정책 적용 (15%)
7.1 OPA/Gatekeeper
OPA Gatekeeper는 ConstraintTemplate(Rego로 정책 로직 정의)과 Constraint(정책 적용 대상 지정) 두 리소스로 운영된다.
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, "details": {"missing_labels": missing}}] {
provided := {label | input.review.object.metadata.labels[label]}
required := {label | label := input.parameters.labels[_]}
missing := required - provided
count(missing) > 0
msg := sprintf("you must provide labels: %v", [missing])
}
Constraint 적용:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-team
spec:
match:
kinds:
- apiGroups: ['']
kinds: ['Namespace']
parameters:
labels: ['team', 'environment']
7.2 Kyverno
Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML + CEL 기반이라 별도 언어 학습이 필요 없다. validate, mutate, generate 세 가지 유형의 룰을 지원한다.
ClusterPolicy 예시 (리소스 제한 필수):
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resource-limits
spec:
validationFailureAction: Enforce
rules:
- name: check-limits
match:
any:
- resources:
kinds:
- Pod
validate:
message: 'CPU and memory resource limits are required.'
pattern:
spec:
containers:
- resources:
limits:
cpu: '?*'
memory: '?*'
7.3 OPA/Gatekeeper vs Kyverno 비교
| 항목 | OPA/Gatekeeper | Kyverno |
|---|---|---|
| 정책 언어 | Rego (전용 언어) | YAML + CEL |
| 학습 곡선 | 높음 | 낮음 |
| Validate | 지원 | 지원 |
| Mutate | 제한적 | 완전 지원 |
| Generate | 제한적 | 완전 지원 (네임스페이스 간 동기화) |
| 범용성 | 멀티 플랫폼 (K8s 외 사용 가능) | Kubernetes 전용 |
| CNCF 상태 | Graduated (OPA) | Incubating |
7.4 Supply Chain 보안
- SBOM(Software Bill of Materials): 소프트웨어 구성 요소 목록 생성 및 관리
- 컨테이너 이미지 스캔: CI/CD 파이프라인에 Shift Left 보안 통합
- Falco: 런타임 보안 위협 탐지 (CNCF Graduated)
8. 추천 학습 계획 (12주)
| 주차 | 내용 |
|---|---|
| 1-3주 | Kubernetes 기초 복습 + GitOps 원칙 + ArgoCD/Flux 실습 |
| 4-5주 | Crossplane XRD/Composition 설계 + CRD/Operator 개발 |
| 6-7주 | Backstage 셋업 + Software Template 작성 |
| 8-9주 | OpenTelemetry + Prometheus + Grafana 스택 구성 |
| 10주 | OPA/Kyverno 정책 적용 + 보안 파이프라인 구축 |
| 11-12주 | 통합 플랫폼 실습 + CNCF 공식 리소스 복습 + Killer.sh 모의시험 |
9. 필수 학습 리소스
| 리소스 | URL |
|---|---|
| CNPE 공식 페이지 | training.linuxfoundation.org/certification/cnpe |
| CNCF 커리큘럼 (오픈소스) | github.com/cncf/curriculum |
| CNCF Platforms White Paper | tag-app-delivery.cncf.io/whitepapers/platforms |
| Platform Engineering Maturity Model | tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model |
| Killer.sh 시뮬레이터 | 시험 등록 시 2회 포함 |
관련 보조 자격증: CKA, CNPA, CGOA(Certified GitOps Associate), OTCA(OpenTelemetry Certified Associate), CBA(Certified Backstage Associate)
References
- CNCF CNPE Certification. https://www.cncf.io/training/certification/cnpe/
- Linux Foundation CNPE Page. https://training.linuxfoundation.org/certification/certified-cloud-native-platform-engineer-cnpe/
- CNCF Curriculum Repository. https://github.com/cncf/curriculum
- CNCF Platforms White Paper. https://tag-app-delivery.cncf.io/whitepapers/platforms/
- Argo CD Documentation. https://argo-cd.readthedocs.io/en/stable/
- Flux CD Documentation. https://fluxcd.io/flux/
- Argo Rollouts Documentation. https://argo-rollouts.readthedocs.io/en/stable/
- OpenGitOps Principles. https://opengitops.dev/
- Crossplane Documentation. https://docs.crossplane.io/latest/
- Backstage Documentation. https://backstage.io/docs/
- OpenTelemetry Documentation. https://opentelemetry.io/docs/
- Prometheus Documentation. https://prometheus.io/docs/
- Grafana Loki Documentation. https://grafana.com/docs/loki/latest/
- OPA Gatekeeper Documentation. https://open-policy-agent.github.io/gatekeeper/website/docs/
- Kyverno Documentation. https://kyverno.io/docs/
- Google SRE Book - Service Level Objectives. https://sre.google/sre-book/service-level-objectives/
- Google SRE Workbook - Error Budget Policy. https://sre.google/workbook/error-budget-policy/
현재 단락 (1/591)
**CNPE**(Certified Cloud Native Platform Engineer)는 CNCF에서 2025년 11월에 공식 발표한 최고급 수준의 자격증이다. 엔터프라이즈 규...