kubernetes

Name: kubernetes
Author: iuliandita

github.com/iulianditaクラウド・DevOps1050 回インストール今日更新

kubernetes について

kubernetesは、Kubernetesインフラの作成、レビュー、設計を支援するスキルです。マニフェスト、Helmチャート、クラスター構成を扱うチーム向けに、セキュリティ、検証、GitOps、コンプライアンス、復旧の実践方法をまとめています。

主な機能

01Kubernetesマニフェストの作成とレビュー
02Helmチャートのひな型作成
03クラスターと複数環境のデプロイ設計
04セキュリティとコンプライアンス要件の確認
05構成の検証とGitOps運用

活用シーン

01ワークロードマニフェストの作成やレビュー
02Helmチャートの作成や改善
03クラスター構成とマルチテナントの計画
04本番環境やPCI-DSSへの準備状況の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill kubernetes

インストール後、Claude Code で/kubernetesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

architecture.md

compliance.md

gitops-emergency-changes.md

manifest-templates.md

output-contract.md

production-checklist.md

sealed-secrets.md

詳細

Kubernetes と Helm：本番環境向けインフラストラクチャ

生のマニフェストから Helm チャート、マルチクラスター戦略まで、Kubernetes インフラストラクチャを作成、レビュー、設計します。チームが維持管理できる、本番環境に対応し、セキュリティが強化され、コストを考慮したインフラストラクチャを目指します。

対象バージョン（2026 年 10 月）：Kubernetes 1.35～1.37 がサポート対象のマイナーバージョンです（1.37.1／1.36.5／1.35.9）。Kubernetes がサポートするのは直近の 3 つのマイナーバージョン（1.37、1.36、1.35）です（リリース履歴を参照）。1.34 は 2026 年 8 月 27 日にメンテナンスモードに入り、2026 年 10 月 27 日に EOL を迎えます。上流の Kubernetes には LTS がありません。マネージドサービスのベンダーによる延長サポート（AKS／EKS）では、古いマイナーバージョンもより長期間サポートされますが、これは上流ではなくプラットフォームに帰属するものです。Helm 4.3.0 と Helm 3.22.0 は、現在並行してリリースされている系列です。新しいデプロイで Helm 3 を選択する前に、サポート状況を確認してください。リリースを組み合わせる前に、Helm の互換性マトリックスを確認してください。Helm 4.3.x と Helm 3.22.x はどちらも Kubernetes 1.34～1.37 のサポートを明記しており、上記のサポート対象マイナーバージョンをカバーしています。このスキルでは、状況に応じて次の 4 つの領域を扱います。

マニフェスト - Deployment、Service、Gateway API ルート、ConfigMap、Secret、PVC 用の生の YAML
Helm - Helm 4 チャートのひな形作成、OCI レジストリ、テンプレート、複数環境向けの値
アーキテクチャ - クラスタートポロジー、GitOps、セキュリティレイヤー、可観測性、コスト、DR
コンプライアンス - PCI-DSS 4.0 の管理策、CDE の分離、監査ログ、サプライチェーン

使用する場面

Kubernetes マニフェスト（Deployment、Service、StatefulSet、Job、HTTPRoute など）の作成またはレビュー
新しい Helm チャートのひな形作成、または既存のチャートの改善
クラスタートポロジー、GitOps 戦略、マルチテナンシーの設計
セキュリティコンテキスト、ネットワークポリシー、RBAC、アドミッション制御の実装
複数環境（開発／ステージング／本番）のデプロイ設定
本番環境またはコンプライアンスへの対応状況を考慮したインフラストラクチャのレビュー
可観測性、コスト最適化、または災害復旧の計画
Fintech／決済関連の K8s ワークロードにおける PCI-DSS 4.0 準拠

使用しない場面

CI/CD パイプラインの設定（ci-cd を使用）
Docker／コンテナイメージの最適化（docker を使用）
アプリケーションコードのセキュリティ監査（security-audit を使用）
IaC によるクラスター自体のプロビジョニング（terraform を使用）
K8s 上で稼働するデータベースエンジンの設定（databases を使用）
クラスター全体の読み取り専用のヘルスチェック、ステータスレポート、メンテナンス後の診断（kubernetes-health を使用）
計装、収集パイプライン、アラート、SLO の設計（observability を使用）- このスキルでは Kubernetes オブジェクトの設定を担当します

AI によるセルフチェック

このスキルは AI エージェント内で実行されます。AI ツールは、K8s のセキュリティに関する同じ間違いを繰り返し起こします。生成したマニフェストを返す前に、必ずこのリストに照らして確認してください。

生成したマニフェストは、利用可能な場合、kube-score score <manifest> と checkov（ステップ 4）で確認してください。リポジトリですでに kube-linter が標準化されている場合は、kube-score の代わりに kube-linter を使用してください。

パフォーマンスと運用の実践

測定したワークロードの動作に基づいて requests と limits を設定してください。requests がないと、スケジューリングとオートスケーリングに悪影響があります。
適用する前にサーバーサイドのドライランと差分確認を行い、短いループの中でクラスター全体のレンダリングを繰り返すことは避けてください。
大規模なクラスターでは、watch、ログ、kubectl get の呼び出し対象を名前空間やラベルで絞り込んでください。
本番環境では、稼働中の命令的な変更よりも、宣言的な GitOps またはレビュー済みのマニフェストを優先してください。
アップグレードやオペレーターの変更前に、CRD とカスタムリソースをバックアップしてください。
特権 Pod、hostPath、広範な RBAC、変更可能なイメージタグには、ポリシーゲートを適用してください。

シークレットの配布と復旧

ワークロードアイデンティティ、名前空間／RBAC アクセス、更新、アプリケーションの再読み込みを通じて、外部シークレットの所有者を追跡してください。ローテーションの成功だけでなく、期限切れのリースや失効した認証情報も確認してください。Secret を更新すればプロセスが再読み込みされると思い込まないでください。発行者とパイプラインの設定は terraform と ci-cd で管理してください。復元訓練では、分離されたクラスターまたは名前空間を使用し、アプリケーションによる読み書きと依存関係を確認し、RTO／RPO に対する復旧時間とデータ損失を測定して、クリーンアップを記録してください。バックアップジョブが完了しただけでは、復元可能であることの証明にはなりません。

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

ステップ 1：ドメインを特定
ステップ 2：要件を収集
ステップ 3：マニフェスト、チャート、または設計を作成
ステップ 4：検証に問題がない（ドライラン、Lint、またはスコアリングに失敗した場合は修正し、ステップ 3 に戻る）
ステップ 5：稼働中の変更を行う前に GitOps の担当者を確認
本番環境チェックリストと AI によるセルフチェックに合格

ステップ 1：ドメインを特定する

リクエストに基づいて判断します。

「デプロイメント／サービス／マニフェストを作成」 -> マニフェスト
「Helm チャートを作成」／「デプロイ用のパッケージ」 -> Helm
「クラスターを設計」／「どのような構成にすべきか」 -> アーキテクチャ
「これを PCI 準拠にする」／「フィンテック」 -> コンプライアンス
「このマニフェスト／チャートをレビュー」 -> 本番環境チェックリスト + 重要ルール + AI のセルフチェックを適用

実際のタスクの多くは複数のドメインにまたがります。下から順に進めます。まずマニフェストを適切に作成し、次にテンプレート化してから、デプロイを計画します。

ステップ 2：要件を収集する

YAML を作成する前に、以下を確認します。

ワークロードの種類：ステートレス（Deployment）か、ステートフル（StatefulSet）か、バッチ（Job／CronJob）か
コンテナーイメージと固定されたタグまたは SHA256 ダイジェスト
公開するポート（コンテナーポート、サービスポート、プロトコル）
設定：環境変数、設定ファイル、シークレット
ストレージ：一時的（emptyDir）か永続的（PVC）か。アクセスモードとサイズも指定します
リソース：CPU／メモリのリクエストと上限
ヘルスチェック：起動、稼働、生存性の各プローブのエンドポイント
アクセス：内部専用（ClusterIP）か外部公開（Gateway API HTTPRoute／LoadBalancer）か
スケーリング：レプリカ数、HPA のしきい値、PodDisruptionBudget
コンプライアンス：PCI-DSS の対象範囲か。CDE ワークロードか。規制対象の環境か
サイドカー：ロギング、セキュリティ、プロキシ用のサイドカーが必要か。ネイティブサイドカーを使用します（1.33 で GA）

ステップ 3：構築する

以下のドメイン別セクションに従います。完了前に、必ずステップ 4、references/production-checklist.md の本番環境チェックリスト、および AI のセルフチェックを実施します。

ステップ 4：検証する

# Always verify kube context first
KUBE_CONTEXT="$(kubectl config current-context)"
printf 'Using kube context: %s\n' "$KUBE_CONTEXT"

# Manifests
kubectl --context "$KUBE_CONTEXT" apply -f <manifest> --dry-run=server  # Server-side validation
if command -v kube-score >/dev/null; then
  kube-score score <manifest>                   # Best practice scoring
else
  echo "kube-score not installed: scoring NOT run; report it as unverified"
fi
if command -v checkov >/dev/null; then
  checkov -d . --framework kubernetes
else
  echo "checkov not installed: policy scan NOT run; report it as unverified"
fi
# Fix and return to Step 3 until dry-run errors and findings this change introduced are clean; report pre-existing ones

# Helm 4
helm lint <chart>/                              # Lint chart
helm template <release> <chart>/               # Render templates locally
helm template <release> <chart>/ -f values-prod.yaml  # With env overlay
helm --kube-context "$KUBE_CONTEXT" install <release> <chart>/ --dry-run=server --debug  # Server-side dry run

ステップ 5：GitOps 管理下での緊急変更またはスケーリング変更

ArgoCD、Flux、または別のリコンシラーが管理する稼働中のワークロードを変更する場合は、references/gitops-emergency-changes.md を読みます。望ましい状態も変更しない限り、稼働中の kubectl scale、kubectl patch、または手動での適用は元に戻される場合があります。

マニフェスト

完全なコピー＆ペースト可能な YAML テンプレート（Deployment、Service、Gateway API HTTPRoute、ConfigMap、PVC、StatefulSet、ネイティブサイドカー）については、references/manifest-templates.md を読みます。

主なパターン

ラベル：すべてのリソースで標準の app.kubernetes.io/* ラベルを使用します。

app.kubernetes.io/name - アプリ名
app.kubernetes.io/version - バージョン文字列
app.kubernetes.io/component - 役割（フロントエンド、バックエンド、データベース）
app.kubernetes.io/part-of - 親システム

外部アクセス（新しいクラスターでは、従来の Ingress ではなく Gateway API を使用する必要があります）。

Gateway API HTTPRoute（GA v1.5）：役割指向で表現力の高いルーティングを実現し、アノテーション地獄を回避できます。Ingress-NGINX は 2026 年 3 月に廃止されました。メンテナンスされているコントローラーに移行してください。その後の CVE-2026-4342 により、設定のインジェクションとコントローラーのコード実行が可能になります。影響を受けるブランチのバージョンは、それぞれ 1.13.9／1.14.5／1.15.1 より前です。これらの修正によって継続的なサポートが再開されるわけではありません。
ClusterIP（デフォルト）：内部のみ
LoadBalancer：HTTP ルーティングを行わないクラウド LB
ヘッドレス（clusterIP: None）：StatefulSet の Pod 検出

セキュリティコンテキスト（すべての Pod で必須。Pod レベルとコンテナーレベルの両方に適用します）。完全な YAML については、manifest-templates.md の Deployment テンプレートを参照してください。主なフィールド：runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation: false、drop: ["ALL"]、seccompProfile: RuntimeDefault。

プローブの種類（ワークロードに適したチェックを選択します。補助的なサイドカーで readiness が必要なのは、Pod のトラフィックを制御する必要がある場合のみです）。

startupProbe：アプリの準備が整うまで、他のプローブを実行させません（failureThreshold は高め、periodSeconds は中程度）
livenessProbe：健全でない Pod を再起動します（慎重に設定し、応答が遅いだけで再起動しないようにします）
readinessProbe：サービスエンドポイントから Pod を除外します（失敗時にすばやくトラフィックを引き上げます）

Pod の分散：ゾーンレベルの分散には、Pod のアンチアフィニティより topologySpreadConstraints を優先します（アンチアフィニティは大規模環境では O(n^2) になります）。両方を組み合わせ、ゾーンには topologySpreadConstraints を使い、ゾーン内のノードレベルの分離にはソフトアンチアフィニティを使います。

ネイティブサイドカー（K8s 1.33 で GA）：restartPolicy: Always を指定した init コンテナーです。メインコンテナーより先に起動し、メインコンテナーと並行して稼働し続け、メインコンテナーの終了後に終了します。サイドカーのライフサイクルに関する小細工（preStop フック、shareProcessNamespace の kill スクリプト）をすべて置き換えます。

Pod のインプレースリサイズ（K8s 1.35 で GA）：実行中の Pod を再起動せずに、CPU とメモリーを更新できます。VPA は InPlaceOrRecreate モードを使って、中断なしでリサイズできるようになりました。

設定／シークレット：機密性のないデータには ConfigMap を使用します。シークレットには、Vault／クラウド KMS と同期する External Secrets Operator、または暗号化して Git に保存するワークフロー向けの Sealed Secrets を使用します（references/sealed-secrets.md を参照）。平文のシークレットをどこにもコミットしないでください。

Helm チャート

Helm 4（2025 年 11 月 12 日に 4.0.0 がリリース、現行バージョンは 4.3.0）が現行版です。3.22.0 を選択する前に、Helm 3 の現在のサポートポリシーを確認してください。

Helm 4 での変更点

Server-side apply（SSA）が新しいリリースのデフォルトになりました。 複数のコントローラーが同じリソースを操作する際の競合検出が向上します。
OCI ダイジェストによるインストール：helm install myapp oci://registry/chart@sha256:abc... - 不変で、改ざんを防止します。
WASM プラグインシステム - ポストレンダラーでは、実行ファイルを直接指定するのではなく、プラグイン名を参照する必要があります（破壊的変更）。
CLI フラグの名称変更：--atomic -> --rollback-on-failure、--force -> --force-replace。旧フラグも install と upgrade の両方で非推奨の別名として引き続き使用できます（helm install --atomic が動作しなくなる一時的な Helm 4.0 のリグレッションは v4.1.3 で修正されました）。新しいスクリプトでは --rollback-on-failure を優先してください。
helm registry login にはドメインのみを指定します（例：完全な URL ではなく ghcr.io）。
OCI レジストリーが推奨される配布方法です。 従来の index.yaml リポジトリも引き続き動作しますが、デフォルトの方法ではなくなりました。

チャートの構成

helm create <app-name>

<app-name>/
+-- Chart.yaml           # Metadata (apiVersion: v2, name, version, appVersion)
+-- values.yaml          # Default config values
+-- values.schema.json   # JSON schema for values validation
+-- charts/              # Bundled dependencies
+-- crds/                # CRDs (not templated, installed first)
+-- templates/
|   +-- NOTES.txt        # Post-install usage instructions
|   +-- _helpers.tpl     # Template helper functions
|   +-- deployment.yaml
|   +-- service.yaml
|   +-- httproute.yaml   # Gateway API (prefer over ingress.yaml)
|   +-- configmap.yaml
|   +-- hpa.yaml
|   +-- tests/
|       +-- test-connection.yaml
+-- .helmignore

Chart.yaml

必須項目：apiVersion: v2、name、version（SemVer）、description、type（application|library）。

パッチレベルの範囲には ~ を使って依存関係を固定します。

dependencies:
  - name: postgresql
    version: "~12.0.0"          # matches 12.0.x
    repository: "oci://registry-1.docker.io/bitnamicharts"  # OCI preferred
    condition: postgresql.enabled

依存関係を追加した後、helm dependency update を実行します。

values.yaml の設計

階層構造に整理します。主要なセクションは次のとおりです。

image（リポジトリ、タグ／ダイジェスト、pullPolicy）
replicaCount
service（type、port、targetPort）
gateway（enabled、parentRefs、hostnames）— ingress よりこちらを優先します
resources（requests と limits — 必ず両方を設定します）
autoscaling（enabled、min/maxReplicas、targetCPU）
securityContext（runAsNonRoot、readOnlyRootFilesystem、すべての capabilities を削除）
nodeSelector、tolerations、affinity

複数環境への対応：オーバーレイとして values-dev.yaml、values-staging.yaml、values-prod.yaml を作成します。環境固有の設定で values.yaml を変更してはいけません。

テンプレートのパターン

ヘルパー（_helpers.tpl）：<chart>.name、<chart>.fullname、<chart>.labels、<chart>.selectorLabels、<chart>.image を定義します。名前は 63 文字に切り詰めます。

主な Go テンプレートのパターン：

条件分岐：{{- if .Values.gateway.enabled }}
反復：{{- range .Values.env }}
ファイルの読み込み：{{ .Files.Get "config/app.yaml" | nindent 4 }}
デフォルト値：{{ .Values.image.tag | default .Chart.AppVersion }}
必須値：{{ required "image.repository is required" .Values.image.repository }}
リリースの名前空間：{{ .Release.Namespace }}（名前空間をハードコードしてはいけません）
ネストした値へのアクセス：スパゲッティ化を避けるため、{{- $var := .Values.deep.nested }} でエイリアスを設定します

Helm のアンチパターン

テンプレート内のハードコードされた値（values.yaml から取得する必要があります）
静的な文字列への tpl の使用（動的なテンプレートのレンダリングに使うものです）
オプションの値に default を指定しないまま、.Values.foo.bar.baz と連鎖させること
チャート依存関係のバージョンを固定しないこと（~ の範囲指定または正確なバージョンを使用します）
NOTES.txt がない
.helmignore がない（test／ci ファイルがパッケージに含まれます）
ArgoCD でデプロイするテンプレート内で randAlphaNum を使うこと（OutOfSync が解消されなくなります）
巨大なアンブレラチャート（サブチャートが 15 個以上、値のオーバーライドが 200 個以上）— 代わりに ArgoCD ApplicationSets を使用します
本番環境の高可用性ワークロードに replicaCount: 1 を設定すること（冗長性がなく、単一障害点になります）
本番環境の値で authentication.enabled: false または persistence.enabled: false を設定すること（データ損失や不正アクセスにつながります）
Helm の値にシークレットを含めること（ESO／sealed-secrets／vault を使用します。Helm の値はクラスターの Secrets 内で読み取り可能になります）
helm.sh/hook-delete-policy のないフックリソース（Job が孤立して蓄積します）
生の実行可能ファイルを --post-renderer とともに使うこと（Helm 4 では動作しません。プラグイン名を使う必要があります）
SSA の移行を無視すること（既存のリリースで Helm 4 にアップグレードすると、これまで隠れていた競合が表面化する場合があります）

ArgoCD と Helm の注意点

ArgoCD が実行するのは helm template のみであり、Helm のライフサイクル管理は行いません。重要な処理を Helm フックに依存させず、代わりに ArgoCD の同期ウェーブを使用します。
ArgoCD では test フックはサポートされていません。
チャートのバージョンと環境値を分離するには、複数ソースの Applications（ArgoCD 2.6 以降）を使用します。
OCI チャート：ArgoCD の repoURL フィールドでは oci:// プレフィックスを省略します。

Kustomize

Kustomize は kubectl に組み込まれており（kubectl apply -k）、単体の CLI としても利用できます。

オーバーレイのパターン（ベース + 環境）

app/
+-- base/
|   +-- kustomization.yaml   # references resources
|   +-- deployment.yaml
|   +-- service.yaml
+-- overlays/               # dev/ staging/ prod/, each a kustomization.yaml with resources: [../../base]

各オーバーレイの kustomization.yaml で resources を設定し、続いてその環境用の patches、images、configMapGenerator／secretGenerator のオーバーライドを追加します。

コンポーネント

再利用可能な横断的パッチ（監視、セキュリティコンテキスト、サイドカーの挿入）で、任意のオーバーレイから components: [../../components/monitoring] を指定して利用できます。オーバーレイ間でパッチを重複させるより、コンポーネントを優先します。

secretGenerator／name-suffix-hash の落とし穴

secretGenerator と configMapGenerator は、リソース名にコンテンツハッシュのサフィックスを追加します（例：app-config-abc12345）。固定名で生成リソースを参照する Deployment は、編集のたびにハッシュが変わるため動作しなくなります。生成リソースは常にベース名で参照し、Kustomize にサフィックスを解決させるか、ハッシュベースのローリングアップデートが不要な場合は options.disableNameSuffixHash: true を設定します。

アーキテクチャ

アーキテクチャの意思決定フレームワークの全容については、references/architecture.md を参照してください。主なパターンは次のとおりです。

クラスターのトポロジー

単一クラスターを選択するケース：サービスが50未満、単一チーム、単一リージョン、重要度の低いワークロード。

マルチクラスターを選択するケース：マルチリージョンの高可用性、チームの分離、影響範囲の縮小、コンプライアンス上の境界（PCI CDE）。

GitOps

ArgoCDを選択するケース：UIが重要、アプリ・オブ・アプリズ、単一のコントロールプレーンからのマルチクラスター管理、デプロイに対するRBAC。

Fluxを選択するケース：Gitネイティブな方法を優先、軽量な構成、完全なHelmライフサイクル（インストール／アップグレード／テスト／ロールバック／アンインストール）、Kustomizeによるポストレンダリング。

昇格：PRベースの昇格でdev -> staging -> prodへ進めます。prodへの自動同期は行いません。

ネットワーキング

新しいクラスターではGateway API（GA v1.5）が標準です（Rule 10を参照）。

CNI：Cilium（eBPF、新規構築）またはCalico（既存環境／マルチOS／Windows）。CiliumにはHubbleによる可観測性、L3～L7ポリシー、オプションのサイドカー不要サービスメッシュが含まれます。

kube-proxy：nftablesモードが今後の標準です。IPVSは1.35で非推奨となり、1.40以降はデフォルトで無効になります（KubeProxyIPVSフィーチャーゲートで再有効化可能）。1.43で削除されます（https://kubernetes.io/docs/reference/networking/virtual-ips/）。

サービスメッシュ（必要な場合にのみ追加）：

Istio ambient（1.24でGA）：ztunnelによるサイドカー不要のL4 mTLS、オプションでwaypointプロキシによるL7。
Cilium：WireGuard／IPsecによるmTLS、メッシュの抽象化はありません。よりシンプルですが、L7制御は限定的です。
Linkerd：安定版ビルドは現在ベンダー経由のみです（Buoyant）。ソースコードはApache 2.0ですが、自分でビルドするか、有料で利用する必要があります。

セキュリティ（多層防御）

本番環境向けの8つのレイヤー：

クラスターの強化：CISベンチマーク、APIサーバーの監査ログ記録、KMS v2によるetcd暗号化
Pod Security Standards：すべてのアプリ用名前空間で、enforce: restrictedをデフォルトにします。restrictedで追加が許可されるのはNET_BIND_SERVICEのみです。そのため、rootで起動し、SETUID／SETGID／CHOWNを必要とするイメージは、まず設定を変更するか、非rootで動作するように再ビルドしてください。それが不可能な場合は、例外の内容（所有者、理由、レビュー日）を文書化したうえで、baselineを強制する専用の名前空間に隔離し、その名前空間でもaudit／warnはrestrictedに設定します。それ以外のすべての場所では、強制前に問題が発生する箇所を把握できるよう、audit: restrictedとwarn: restrictedを設定します。
アドミッション制御：標準ポリシーにはValidatingAdmissionPolicy（CEL、1.30以降ネイティブ）を使用します。変更／生成にはKyvernoを使用します。クロスプラットフォームの組織にはOPA Gatekeeperを使用します。
ネットワークポリシー：名前空間ごとにingress／egressをデフォルト拒否にします。L7ポリシーにはCiliumを使用します。
RBAC：名前空間スコープのロールを使用し、アプリにcluster-adminを付与せず、MFA付きのOIDC認証を使用します。
サプライチェーン：イメージ署名にはcosign／Sigstoreを使用し、SLSA Level 2～3に準拠し、SBOMを用意します。すべてのCIアクションとツールをコミットSHAに固定してください。Trivyのサプライチェーン侵害（2026年3月、CVE-2026-33634）により、変更可能なタグにマルウェアを含む内容が強制プッシュされる可能性があることが明らかになりました。Trivyの教訓、安全なバージョン、シークレットのローテーション期間については、references/architecture.md（CI/CD Supply Chain Hardening）を参照してください。
シークレット：External Secrets Operator + クラウドKMS（主要な選択肢）。動的シークレット／PKIにはVaultを使用します。外部依存なしでGit内に暗号化して保存する場合はSealed Secretsを使用します（references/sealed-secrets.mdを参照）。小規模チームではSOPSを使用します。
ランタイムセキュリティ：検知にはFalco（CNCF Graduated）、eBPFによる強制にはTetragon（オーバーヘッド1%未満）を使用します。

プラットフォームの認識

cgroup v2 が必須です。K8s 1.36 以降では、FailCgroupV1 のデフォルト値は true であり、failCgroupV1: false を設定しない限り、kubelet は cgroup v1 上で起動しません。cgroup v1 を使用するノード（CentOS 7、RHEL 7、Ubuntu 18.04）では失敗します。
containerd 2.0 が必須です。K8s 1.36 以降で必要になります。containerd 1.x をサポートする最後のリリースは 1.35 です。
AppArmor アノテーションの自動設定は 1.34 で終了し、1.36 で完全に削除されます。securityContext.appArmorProfile フィールドを使用してください。
DRA（Dynamic Resource Allocation） が 1.34 で GPU／FPGA／ハードウェアのスケジューリング向けに GA になりました。デバイスプラグインモデルに代わるものです。
ユーザーネームスペース（hostUsers: false）は、K8s 1.33 以降デフォルトで有効です。コンテナーの UID 0 を、ホスト上の非特権 UID にマッピングします。PCI のマルチテナンシーにおいて非常に重要です。コンテナーからの脱出が起きても、ホストの root 権限は得られません。
Pod レベルの mTLS（KEP-4317）は 1.35 でベータ版となりました。フィーチャーゲート PodCertificates を手動で有効にする必要があります。サービスメッシュを使わずに、Pod 用のネイティブ X.509 証明書を使用できます。Req 4 のコンプライアンス対応において、将来的に Istio／Cilium に代わる選択肢となります。

コンプライアンス

Kubernetes のコントロールに対する PCI-DSS 4.0 要件の完全なマッピングについては、references/compliance.md を参照してください。

クイックリファレンス：K8s における PCI-DSS 4.0

PCI-DSS 4.0.1 が唯一有効なバージョンです（4.0 は 2024 年 12 月 31 日に、3.2.1 は 2024 年 3 月に廃止されました）。発効日が将来に設定されていた 51 件の要件は、2025 年 3 月 31 日に必須となりました。

K8s 固有の重要な要件：

Req 1：ネットワークのセグメンテーション -> デフォルト拒否の NetworkPolicies、プライベート API サーバー、VPC ネイティブクラスター
Req 3.5：データの暗号化 -> KMS v2 による etcd の暗号化（ディスク暗号化だけでは不十分です。Req 3.5.1.2 では、ディスクレベルの暗号化だけに依存することが禁止されています）
Req 4：通信の暗号化 -> すべての CDE サービス間での mTLS（Istio strict／Cilium mutual auth）
Req 6.3.2：コンポーネントのインベントリ -> すべてのイメージの SBOM
Req 8.4.2：すべての CDE アクセスに MFA を適用 -> すべての kubectl 経路で OIDC と MFA を使用
Req 8.6.2：シークレットのハードコード禁止 -> External Secrets Operator を使用し、マニフェスト／values／環境変数には決して含めない
Req 10.4.1.1：監査ログの自動レビュー -> 機密性の高いペイロードには Metadata を、レビュー済みの非機密リソースに限って RequestResponse を使用する K8s 監査ポリシーを設定し、アラートルールとともに SIEM に送信
Req 11.5：FIM／変更検知 -> Falco によるランタイム検知、ArgoCD によるドリフト検知、イメージダイジェストの固定

CDE の分離：専用クラスターが強く推奨されます。クラスターを共有すると、クラスター全体が PCI のスコープに含まれ、専用ノードプールとテイント、CDE Pod 用の gVisor／Kata、DNS と監査ストリームの分離、さらに広範な QSA 向け文書が必要になります。多くの QSA はクラスターの共有に難色を示します。

PCI MPoC：MPoC バックエンド（タッチ決済向けのアテステーション／モニタリング）は、PCI-DSS の完全なスコープに含まれます。K8s 固有の補遺はなく、標準の PCI-DSS 4.0 コントロールが適用されます。

参照ファイル

references/manifest-templates.md - マニフェストのテンプレートと再利用可能なワークロードパターン
references/production-checklist.md - マニフェスト、Helm、アーキテクチャ、PCI-DSS のチェックリスト。ビルドやレビューを完了する前に実行してください
references/architecture.md - Trivy の侵害後のサプライチェーンの完全性を含む、クラスターとプラットフォームの設計ガイダンス
references/sealed-secrets.md - Sealed Secrets のパターンと注意事項
references/compliance.md - PCI-DSS とプラットフォームのセキュリティ強化に関するガイダンス
references/gitops-emergency-changes.md - GitOps 管理下のワークロードに緊急変更を安全に適用するワークフロー

出力仕様

仕様の全文については、references/output-contract.md を参照してください。

スキル名： KUBERNETES
成果物の分類： audits
モード： 条件付き。既存のリポジトリコンテンツの分析、レビュー、監査、改善を行う場合は、references/output-contract.md のレポートの分量と証拠に関するルールを適用し、成果物を docs/local/audits/kubernetes/<YYYY-MM-DD>-<slug>.md に書き込んでください。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成を行う場合は、仕様に縛られず自由に回答してください。
重大度スケール： P0 | P1 | P2 | P3 | info（共通仕様を参照。監査／レビューモードでのみ使用）。

ルール

これらは譲れないルールです。違反はすべてバグです。

:latest タグは禁止です。 イメージは特定のバージョンまたは SHA256 ダイジェストに固定してください。
すべてに名前空間を指定してください。 デフォルトの名前空間を使うのはコードの匂いです。
すべての Pod にリソースのリクエストと制限を設定してください。 例外はありません。
クラスターを変更する前に、依頼者の権限を確認してください。 共有チャットでは、管理者以外の参加者からの管理者権限を要する依頼に対して、kubectl、Helm、ArgoCD の実行や GitOps の編集を行わないでください。作業を中止し、権限を持つオーナーに明示的な承認を求めてください。
本番環境への自動同期は禁止です。 手動承認または PR ベースの昇格を必須にしてください。
依存関係のバージョンを固定してください。 Helm チャートの依存関係、プロバイダーバージョンなど、すべてが対象です。
適用する前に毎回 helm template を実行してください。 クラスターに反映される前にテンプレートエラーを検出します。
シークレットを平文で扱ってはいけません。 Git、ConfigMap、Helm の値、マニフェスト内の環境変数に保存してはいけません。
変更はまずステージング環境でテストしてください。 ポリシーの変更、アドミッションコントローラー、アップグレード、SSA への移行が対象です。
新たな外部アクセスには Gateway API を使用してください。 Ingress-NGINX は 2026 年 3 月に廃止されます。新しい Ingress リソースのデプロイはやめてください。
cosign でイメージに署名してください。 アドミッション時に検証してください。本番環境では SLSA Level 2 以上が最低要件です。
リソースメトリクスの意味を理解してください。 HPA の CPU 目標は、ノードの容量ではなく、CPU の リクエスト に対する割合です。例：cpu: 100m をリクエストし、averageUtilization: 70 を設定した Pod は、Pod ごとの CPU 使用量が 70m（100m * 70%）に達するとスケールします。ノードが 2 コアか 64 コアかは関係ありません。リクエスト（スケジューリングの下限）、制限（強制される上限）、実際の使用量（コンテナが現在消費している量）を混同しないでください。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: クラウド・DevOps
インストール数: 50
GitHub スター: 10

問題を報告