- Published on
CNPE(Certified Cloud Native Platform Engineer)完全ガイド — 試験範囲から実践技術スタックまで
- Authors
- Name
- 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ベースのリモートデスクトップ(ターミナル+Webインターフェース) |
| オープンブック | 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 | 2つのGeneratorのパラメータを組み合わせ(直積) |
| 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オーバーレイまたはプレーンな YAMLの適用 |
| Helm Controller | HelmRelease | Helmチャートのライフサイクル管理 |
| Notification Controller | Provider, Alert, Receiver | 通知発送およびインバウンドWebhook処理 |
| 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(実装)を定義する。
- 開発者は自分のNamespaceで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 | すべての言語(Webhook方式) |
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自動計装:
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 Observabilityスタック:
+-----------+
| 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のコスト可視性と割り当てを提供するオープンソースツールである。Namespace、チーム、サービス別のコストを追跡し、リソース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(ポリシー適用対象を指定)の2つのリソースで運用される。
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の3種類のルールをサポートする。
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 | 制限的 | 完全サポート(Namespace間同期) |
| 汎用性 | マルチプラットフォーム(K8s外でも使用可能) | Kubernetes専用 |
| CNCF状態 | Graduated(OPA) | Incubating |
7.4 サプライチェーンセキュリティ
- 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/