[Kyverno]🛠️ なぜHelmでインストールすべきなのでしょうか？

6月 7, 2026

—

こんにちは！Kubernetesセキュリティの核心、Kyvernoシリーズの第2回です。🛡️

前回はKyvernoの全体的なアーキテクチャについて見てみましたが、今回は実践に入り、「Kyvernoをクラスターに最も完璧にインストールし、最適化する方法は何か？」について掘り下げていきます。特に、現場で最も多く使われているHelm（ヘルム）を利用したインストールと、values.yamlファイルの主要な設定値を一つ一つ詳しく解説していきます。🚀

Kubernetesリソースを個別のYAMLで管理するのは非常に苦痛な作業です。Kyvernoのように多くのCRD（Custom Resource Definitions）と複雑なWebhook設定を持つソリューションでは、なおさらです。

バージョン管理: 特定バージョンのKyvernoを簡単にデプロイし、ロールバックできます。
設定自動化: 高可用性（HA）設定やリソース制限（Limit）などをvalues.yamlファイル一つで一元管理できます。
メンテナンス: helm upgradeコマンド一行で最新のセキュリティパッチを適用できます。

🏗️ ステップ1: Kyverno公式Helmリポジトリの登録

最初に行うべきことは、Kyverno公式チャートリポジトリを追加することです。

Bash

# リポジトリを追加
helm repo add kyverno https://kyverno.github.io/kyverno/

# 最新のチャート情報を更新
helm repo update

# インストール前にチャートバージョンを確認
helm search repo kyverno

⚙️ ステップ2: 核心中の核心、values.yamlの主要設定を徹底解説

単にhelm installと入力するだけでなく、私たちのサービス環境に合わせて設定をカスタマイズすることが重要です。KCA試験と実務で最も重視されるvalues.yamlの主要パラメータをまとめました。

① 高可用性およびレプリカ (Replica & HA) 🚀

運用環境では、Kyverno Podが一つだけでは危険です。APIサーバーがKyvernoから応答を受け取れない場合、リソースの作成がブロックされる可能性があるためです。

replicaCount: 少なくとも3つ以上を推奨します。
topologySpreadConstraints: 複数のノードやゾーンにPodを均等に分散させ、可用性を高めます。

YAML

replicaCount: 3
podDisruptionBudget:
  minAvailable: 1

② リソース管理 (Resources & Webhook) 🔋

Kyvernoはクラスターのすべてのリクエストを検査するため、リソース割り当てとタイムアウト設定が非常に重要です。

resources: requestsとlimitsを設定してOOM（Out Of Memory）を防ぎます。
webhook.timeoutSeconds: Webhook応答の待機時間を設定します。（デフォルト10秒、長すぎるとAPI応答速度が低下します。）

YAML

resources:
  limits:
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 256Mi

③ サービスおよび通信セキュリティ (Service & RBAC) 🔒

KyvernoがAPIサーバーとどのように通信し、どのような権限を持つかを決定します。

admissionController.container.image.tag: 使用するKyvernoのバージョンを明示的に指定します。
rbac.create: Kyvernoが必要な権限を自動的に作成するかどうかを決定します。（デフォルトtrue）
certManager.enabled: 外部のcert-managerを使用して証明書を管理するかどうかです。

④ ポリシーレポートおよびバックグラウンドスキャン (Background & Reports) 📋

backgroundController.enabled: 既存のリソースに対する定期的なポリシー準拠スキャンを実行するかどうかを決定します。
cleanupController.enabled: 有効期限が過ぎたリソースを削除する機能を有効にします。

📄 Kyverno最適化 my-values.yaml 例

# ---------------------------------------------------------
# 1. レプリカおよび高可用性 (HA) 設定
# ---------------------------------------------------------
replicaCount: 3

# Pod分散ポリシー: 複数のノードに均等に分散して可用性を確保
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app.kubernetes.io/instance: kyverno

# アップグレード中でも最低1つのPodは常に利用可能な状態を維持
podDisruptionBudget:
  minAvailable: 1

# ---------------------------------------------------------
# 2. リソース割り当てとタイムアウト (パフォーマンス最適化)
# ---------------------------------------------------------
admissionController:
  container:
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 500m
        memory: 512Mi

# Webhookタイムアウト: 短すぎるとリクエストが失敗し、長すぎるとAPI応答が遅くなる
webhook:
  timeoutSeconds: 15

# ---------------------------------------------------------
# 3. 証明書管理 (cert-manager連携時)
# ---------------------------------------------------------
# 内部の自己署名証明書の代わりに外部のcert-managerを使用する場合はtrueに設定
certManager:
  enabled: false 

# ---------------------------------------------------------
# 4. モニタリングおよびメトリックの有効化
# ---------------------------------------------------------
# PrometheusおよびGrafana連携のためのメトリックサービスを有効化
metricsService:
  enabled: true
  serviceMonitor:
    enabled: false # Prometheus Operatorがインストールされている場合はtrueに変更

# ---------------------------------------------------------
# 5. バックグラウンドスキャンおよびリソースクリーンアップ (コントローラー設定)
# ---------------------------------------------------------
backgroundController:
  enabled: true
  resources:
    requests:
      cpu: 50m
      memory: 64Mi
    limits:
      cpu: 200m
      memory: 128Mi

cleanupController:
  enabled: true # 有効期限が過ぎたリソースの自動削除機能を有効化
  resources:
    requests:
      cpu: 50m
      memory: 64Mi

# ---------------------------------------------------------
# 6. セキュリティおよびフィルタリング (RBAC & Filters)
# ---------------------------------------------------------
# 特定のネームスペースやリソースを検査対象から除外 (障害防止)
config:
  resourceFilters:
    - "[Event,*,*]"
    - "[*,kube-system,*]"
    - "[*,kube-public,*]"
    - "[*,kube-node-lease,*]"
    - "[Node,*,*]"
    - "[APIService,*,*]"
    - "[TokenReview,*,*]"
    - "[SubjectAccessReview,*,*]"
    - "[SelfSubjectAccessReview,*,*]"

🚀 ステップ3: 実際のインストールコマンドを実行

最適化されたmy-values.yamlファイルが準備できたら、以下のコマンドでインストールを進めます。

# ネームスペースを作成
kubectl create namespace kyverno

# 最適化された設定でインストール
helm install kyverno kyverno/kyverno -n kyverno -f my-values.yaml

インストールが完了したら、必ず以下のコマンドで全てのコンポーネントがRunning状態であることを確認してください！ kubectl get pods -n kyverno

🔍 ステップ4: インストール後のカスタム設定の検証

インストールが終わっても終わりではありません。設定した値が正しく反映されているかを確認する必要があります。

CRD確認: Kyvernoが使用するポリシーリソースが正しく作成されているかを確認します。（kubectl get crd | grep kyverno）
Webhook確認: APIサーバーにKyvernoウェブフックが正しく登録されているかを確認します。（kubectl get mutatingwebhookconfigurations）
ConfigMap確認: フィルタリング設定などが反映されたConfigMapを確認します。

💡 運用者のための実務ヒント

Dry-runの活用: helm install –dry-run –debugを使用して、実際のインストール前に生成されるYAMLを事前に確認してください。
リソースフィルター: kube-systemネームスペースなど、コアシステムリソースはポリシー検査から除外して、障害の伝播を防ぐのが安全です。
Prometheus連携: metricsService.enabled: true設定を通じて、GrafanaでKyvernoの状態をリアルタイムで監視してください。

🌟 終わりに

今日は、Helmを使ってKyvernoをスマートにインストールし、values.yamlの主要な設定をどのように最適化するかを学びました。「基本的な設定は誰でもできますが、精巧なチューニングが安定したクラスターを構築する第一歩です。」今日学んだ設定値をうまく活用して、強固なセキュリティ環境を構築してください。

次回は、多くの方がお待ちかねの

Chapter 3. Writing Policies（ポリシー作成方法）

を通じて、実際のルールをどのようにコーディングするかを扱います。ご期待ください！ 🙋‍♂️