🏗️ Kyvernoアーキテクチャ: なぜ「Kubernetes Native」なのか？

6月 7, 2026

—

こんにちは！今日は、Kubernetes運用の必須アイテムであり、KCA試験の主要テーマでもあるKyvernoのアーキテクチャと、それを構成する主要コンポーネントについて深く掘り下げていきます。🕵️‍♂️

Kubernetesを運用していると、「誰が私のクラスターにセキュリティ設定されていないPodをデプロイしたんだ？」という悩みに直面することがあります。この時、救世主として登場するのがKyvernoです。このKyvernoが内部でどのように動作するかを知ることで、運用とトラブルシューティングが格段に楽になります。

Kyvernoを説明する際によく使われる言葉が「Kubernetes Native」です。これは、KyvernoがKubernetesの既存のメカニズムをそのまま活用しているためです。

最も重要な概念はAdmission Webhooksです。Kubernetes APIサーバーにリソースの作成/変更リクエストが来ると、APIサーバーはこのリクエストを処理する前にKyvernoに「これで大丈夫？」と尋ねます。Kyvernoは設定されたポリシーに基づいて、承認、拒否、または修正を提案します。

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

🧩 Kyvernoの3つの主要コンポーネント (Core Components)

Kyvernoのインストール時に作成される主要なPodを中心に、各コントローラーがどのような役割を果たすか詳しく見ていきましょう。

1. Admission Controller (ゲートキーパー) 🛡️

Kyvernoの心臓部です。すべてのMutatingWebhookとValidatingWebhookのリクエストを直接処理します。

Mutation (変形): リクエストが来ると、設定されたポリシーに従ってリソースの内容を自動的に修正します。例えば、すべてのPodに特定のラベルを追加したり、サイドカーコンテナを注入したりします。
Validation (検証): リソースがセキュリティルールを遵守しているか確認します。「Privilegedモードは禁止！」と設定されている場合、これを違反したリクエストは即座にブロック(Enforce)するか、レポートに記録(Audit)します。
Generation (生成): 新しいネームスペースが作成された際に、デフォルトのNetworkPolicyやRoleなどを自動的に作成します。

2. Background Controller (監査役) 📋

Admission Controllerが「現在入ってくるリクエスト」に焦点を当てるのに対し、Background Controllerは「すでにクラスターに存在するリソース」を監視します。

ポリシー適用確認: ポリシーが後から作成された場合、既存の実行中のPodが新しいポリシーを遵守しているかをスキャンします。
レポート生成: 定期的にクラスターをスキャンし、ポリシー違反事項を整理してPolicyReportを生成します。これにより、管理者はリアルタイムのリクエストブロックだけでなく、クラスター全体の健全性も確認できます。

3. Cleanup Controller (清掃員) 🧹

Kyverno 1.9バージョンから導入されたコンポーネントで、クラスター内の不要なリソースをクリーンアップする役割を専門に担当します。

有効期限設定: 特定のリソースに「1時間後に削除する」というポリシーを設定すると、このコントローラーが時間をチェックし、削除します。
一時リソース管理: テスト用に作成されたリソースや有効期限が切れた証明書などを自動的に整理し、クラスターリソースを節約します。

🔄 ポリシー処理フロー: リクエストから実行まで

リソースを作成する際にKyverno内部で何が起こるかを順を追って見ていきましょう。

APIリクエスト送信: ユーザーが`kubectl apply -f pod.yaml`コマンドを実行します。
Mutating Webhook: APIサーバーがKyvernoにリクエストを送信します。Kyvernoは必要な設定を注入(Mutate)し、結果を返します。
Object Schema Validation: APIサーバーは、修正されたリソースの形式が正しいか自体で検証します。
Validating Webhook: 再びKyvernoに尋ねます。「本当に今作成しても大丈夫？」Kyvernoは最終的なレビュー(Validate)を行い、承認または拒否を決定します。
Persistence: すべての関門を通過すると、etcdにデータが保存され、リソースが作成されます。

🛠️ 運用者向けヒント: トラブルシューティングのポイント

Kyvernoが突然動作しなくなった場合は、まず次の3つの点を確認してください！

Webhook証明書の確認: KyvernoはAPIサーバーとTLS通信を行います。証明書が期限切れになったり、設定が壊れたりすると、すべてのAPIリクエストが停止する可能性があります。cert-managerの活用を推奨します。
Resource Filters: 時々、「なぜこのPodにはポリシーが適用されないのだろう？」と思うことがあります。Kyvernoのデフォルト設定で特定のネームスペース(kube-systemなど)がフィルタリングされて除外されていないか確認してください。
Admission Report: ポリシーが適用されない理由は、PolicyReportカスタムリソースに詳細に記録されています。`kubectl get polr`コマンドを積極的に活用してください。

🌟 終わりに

Kyvernoは単なるセキュリティツールではなく、Kubernetes運用の自動化と標準化を推進する強力なフレームワークです。そのアーキテクチャを理解することは、強力な機能を100%活用するための第一歩です。

今日説明したAdmission、Background、Cleanupという3人の管理者がクラスターをどのように守っているかを頭の中で描くことができれば、Kyverno試験(KCA)はもちろん、実務でも専門家としての実力を発揮できるでしょう！ 🚀