operating-kubernetes

Kubernetes の運用

目的

Kubernetes クラスターを本番環境で運用するには、リソース管理、スケジューリングパターン、ネットワークアーキテクチャ、ストレージ戦略、セキュリティ強化、自動スケーリングを習得する必要があります。このスキルでは、ワークロードの適正なサイズ設定、高可用性パターンの実装、RBAC と Pod Security Standards によるクラスターの保護、一般的な障害の体系的なトラブルシューティングを行うための、運用を重視したフレームワークを提供します。

Kubernetes へのアプリケーションのデプロイ、クラスターリソースの設定、ゼロトラストセキュリティのための NetworkPolicies の実装、自動スケーリング（HPA、VPA、KEDA）の設定、永続ストレージの管理、CrashLoopBackOff やリソース枯渇などの運用上の問題の診断を行う場合に、このスキルを使用してください。

このスキルを使用するタイミング

よくあるきっかけ：

• 「アプリケーションを Kubernetes にデプロイして」
• 「リソースのリクエストと制限を設定して」
• 「Pod の自動スケーリングを設定して」
• 「セキュリティのために NetworkPolicies を実装して」
• 「Pod が Pending／CrashLoopBackOff のまま動かない」
• 「最小権限で RBAC を設定して」
• 「データベース用の永続ストレージを設定して」
• 「Pod をアベイラビリティゾーン全体に分散して」

対象となる運用：

• リソース管理（CPU／メモリ、QoS クラス、クォータ）
• 高度なスケジューリング（アフィニティ、テイント、トポロジー分散）
• ネットワーキング（NetworkPolicies、Ingress、Gateway API）
• ストレージ運用（StorageClasses、PVC、CSI）
• セキュリティ強化（RBAC、Pod Security Standards、ポリシー）
• 自動スケーリング（HPA、VPA、KEDA、クラスターオートスケーラー）
• トラブルシューティング（体系的なデバッグ手順）

リソース管理

Quality of Service（QoS）クラス

Kubernetes は、リソースのリクエストと制限に基づいて QoS クラスを割り当てます。

Guaranteed（最優先）：

• CPU とメモリのリクエストが制限と等しい
• 制限を超過しない限り、追い出されません
• 重要な本番サービスに使用します

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"  # Same as request
    cpu: "500m"

Burstable（中優先度）：

• リクエストが制限より小さい（またはリクエストのみ設定されている）
• リクエストを超えてバーストできます
• ノードに負荷がかかると追い出されます
• Web サーバーやほとんどのアプリケーションに使用します

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"  # 2x request
    cpu: "500m"

BestEffort（最優先度が低い）：

• リクエストも制限も設定されていません
• 負荷がかかると最初に追い出されます
• 開発／テストにのみ使用します

判断の目安：どの QoS クラスを選ぶか？

ワークロードの種類	QoS クラス	設定
重要な API／データベース	Guaranteed	requests == limits
Web サーバー、サービス	Burstable	limits は requests の 1.5～2 倍
バッチジョブ	Burstable	requests は低く、limits は高く
開発／テスト環境	BestEffort	制限なし

ResourceQuotas と LimitRanges

ResourceQuotas（名前空間の制限）と LimitRanges（コンテナーごとのデフォルト値）を使って、マルチテナンシーを適用します。

# ResourceQuota: Namespace-level limits
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

Vertical Pod Autoscaler（VPA）を含む詳細なリソース管理パターンについては、references/resource-management.md を参照してください。

高度なスケジューリング

Node Affinity

必須（ハード）または優先（ソフト）の制約を使って、Pod をスケジュールするノードを制御します。

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
          - g4dn.xlarge  # GPU instance

Taints と Tolerations

特定のワークロード用にノードを予約します（アフィニティとは逆の仕組みです）。

# Taint GPU nodes to prevent non-GPU workloads
kubectl taint nodes gpu-node-1 workload=gpu:NoSchedule

# Pod tolerates GPU taint
tolerations:
- key: "workload"
  operator: "Equal"
  value: "gpu"
  effect: "NoSchedule"

トポロジー分散制約

障害ドメイン（ゾーン、ノード）全体に Pod を均等に分散します。

topologySpreadConstraints:
- maxSkew: 1  # Max difference in pod count
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: critical-app

Pod の優先度やプリエンプションを含む高度なスケジューリングパターンについては、references/scheduling-patterns.md を参照してください。

ネットワーキング

NetworkPolicies（ゼロトラストセキュリティ）

NetworkPolicies を使ってデフォルト拒否のセキュリティを実装します。

# Default deny all traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

# Allow specific ingress (frontend → backend)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Ingress と Gateway API の比較

Ingress（レガシー）：

• 幅広くサポートされ、エコシステムが成熟しています
• 表現力に制限があります
• 既存のアプリケーションに使用します

Gateway API（最新）：

• 役割を中心とした設計（クラスター運用者とアプリ開発者）
• より高い表現力（HTTPRoute、TCPRoute、TLSRoute）
• 新しいアプリケーションに推奨されます（Kubernetes 1.29 以降で GA）

# Gateway API example
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-routes
spec:
  parentRefs:
  - name: production-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend
      port: 8080

サービスメッシュとの統合を含む詳細なネットワークパターンについては、references/networking.md を参照してください。

ストレージ

StorageClasses（パフォーマンス階層の定義）

StorageClasses は、さまざまなワークロードのニーズに合わせたストレージ階層を定義します。

# AWS EBS SSD (high performance)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iopsPerGB: "50"
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete

ストレージ選択マトリックス

ワークロード	パフォーマンス	アクセスモード	ストレージクラス
データベース	高	ReadWriteOnce	SSD (gp3/io2)
共有ファイル	中	ReadWriteMany	NFS/EFS
ログ（一時）	低	ReadWriteOnce	標準 HDD
ML モデル	高	ReadOnlyMany	オブジェクトストレージ (S3)

アクセスモード：

• ReadWriteOnce (RWO)： 単一ノードで読み書き可能（最も一般的）
• ReadOnlyMany (ROX)： 複数ノードで読み取り専用
• ReadWriteMany (RWX)： 複数ノードで読み書き可能（ネットワークストレージが必要）

ボリュームスナップショットや CSI ドライバーを含むストレージ操作の詳細については、references/storage.md を参照してください。

セキュリティ

RBAC（ロールベースアクセス制御）

RBAC を使用して最小権限のアクセスを実装します。

# Role (namespace-scoped)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# RoleBinding (assign role to user)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Pod セキュリティ標準

名前空間レベルでセキュアな Pod 構成を適用します。

# Namespace with Restricted PSS (most secure)
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Pod セキュリティレベル：

• Restricted： 最もセキュアで、すべての権限昇格を排除します（アプリケーションで使用）
• Baseline： 制限は最小限で、既知の権限昇格を防止します
• Privileged： 制限なし（システムワークロードのみで使用）

ポリシーの適用（Kyverno/OPA）やシークレット管理を含むセキュリティパターンの詳細については、references/security.md を参照してください。

オートスケーリング

Horizontal Pod Autoscaler (HPA)

CPU、メモリ、またはカスタムメトリクスに基づいて Pod のレプリカ数をスケーリングします。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # Wait 5min before scaling down

KEDA（イベント駆動型オートスケーリング）

CPU／メモリ以外のイベント（キュー、Cron スケジュール、Prometheus メトリクス）に基づいてスケーリングします。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-scaler
spec:
  scaleTargetRef:
    name: message-processor
  minReplicaCount: 0   # Scale to zero when queue empty
  maxReplicaCount: 30
  triggers:
  - type: rabbitmq
    metadata:
      queueName: tasks
      queueLength: "10"  # Scale up when >10 messages

オートスケーリング選択マトリックス

シナリオ	HPA を使用	VPA を使用	KEDA を使用	Cluster Autoscaler を使用
トラフィックの急増があるステートレス Web アプリ	✅	❌	❌	場合による
単一インスタンスのデータベース	❌	✅	❌	場合による
キュー処理（イベント駆動型）	❌	❌	✅	場合による
Pod が Pending（ノード不足）	❌	❌	❌	✅

VPA やクラスターオートスケーラーの構成を含むオートスケーリングパターンの詳細については、references/autoscaling.md を参照してください。

トラブルシューティング

よくある Pod の問題

Pod が Pending のままになる場合：

kubectl describe pod <pod-name>

# Common causes:
# - Insufficient CPU/memory: Reduce requests or add nodes
# - Node selector mismatch: Fix nodeSelector or add labels
# - PVC not bound: Create PVC or fix name
# - Taint intolerance: Add toleration or remove taint

CrashLoopBackOff：

kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # Check previous crash

# Common causes:
# - Application crash: Fix code or configuration
# - Missing environment variables: Add to deployment
# - Liveness probe failing: Increase initialDelaySeconds
# - OOMKilled: Increase memory limit or fix leak

ImagePullBackOff：

kubectl describe pod <pod-name>

# Common causes:
# - Image doesn't exist: Fix image name/tag
# - Authentication required: Create imagePullSecrets
# - Network issues: Check NetworkPolicies, firewall rules

Service にアクセスできない場合：

kubectl get endpoints <service-name>  # Should list pod IPs

# If endpoints empty:
# - Service selector doesn't match pod labels
# - Pods aren't ready (readiness probe failing)
# - Check NetworkPolicies blocking traffic

ネットワークやストレージの問題を含む、体系的なトラブルシューティング手順については、references/troubleshooting.md を参照してください。

リファレンスドキュメント

詳細解説

• references/resource-management.md - リソースのリクエスト／制限、QoS クラス、ResourceQuotas、VPA
• references/scheduling-patterns.md - ノードアフィニティ、taints/tolerations、トポロジー分散、優先度
• references/networking.md - NetworkPolicies、Ingress、Gateway API、サービスメッシュ統合
• references/storage.md - StorageClasses、PVCs、CSI ドライバー、ボリュームスナップショット
• references/security.md - RBAC、Pod セキュリティ標準、ポリシー適用、シークレット
• references/autoscaling.md - HPA、VPA、KEDA、クラスターオートスケーラーの構成
• references/troubleshooting.md - よくある障害に対する体系的なデバッグ手順

例

• examples/manifests/ - コピーしてすぐに使える YAML マニフェスト
• examples/python/ - 自動化スクリプト（監査、コスト分析、検証）
• examples/go/ - オペレーター開発の例

ツール

• scripts/validate-resources.sh - リソース制限のない Pod を監査
• scripts/audit-networkpolicies.sh - NetworkPolicies が設定されていない名前空間を検出
• scripts/cost-analysis.sh - 名前空間ごとのリソースコストの内訳

関連スキル

• building-ci-pipelines - CI/CD から Kubernetes にデプロイ（kubectl apply、Helm、GitOps）
• observability - クラスターとワークロードを監視（Prometheus、Grafana、トレーシング）
• secret-management - Kubernetes のシークレットを保護（External Secrets、Sealed Secrets）
• testing-strategies - マニフェストとデプロイをテスト（Kubeval、Conftest、Kind）
• infrastructure-as-code - Kubernetes クラスターをプロビジョニング（Terraform、Cluster API）
• gitops-workflows - 宣言的なクラスター管理（Flux、ArgoCD）

ベストプラクティスの概要

リソース管理：

• CPU／メモリのリクエストと上限を必ず設定します
• 自動的な適正サイズ設定には VPA を使用します
• 名前空間ごとにリソースクォータを設定します
• 実際の使用量とリクエストを監視します

スケジューリング：

• 高可用性を実現するためにトポロジー分散制約を使用します
• ワークロードを分離するには、テイントを適用します（GPU、スポットインスタンス）
• 重要なワークロードにはポッドの優先度を設定します

ネットワーキング：

• デフォルト拒否で NetworkPolicies を実装します
• 新しいアプリケーションには Gateway API を使用します
• イングレス層でレート制限を適用します

ストレージ：

• CSI ドライバーを使用します（レガシーなプロビジョナーは使用しません）
• パフォーマンス階層ごとに StorageClasses を定義します
• ステートフルアプリのボリュームスナップショットを有効にします

セキュリティ：

• Pod Security Standards を適用します（アプリには Restricted を使用します）
• 最小権限の原則に基づいて RBAC を実装します
• ガードレールとしてポリシーエンジンを使用します（Kyverno／OPA）
• イメージの脆弱性をスキャンします

オートスケーリング：

• ステートレスワークロードには HPA を使用します
• イベント駆動型ワークロードには KEDA を使用します
• 上限を設定してクラスターオートスケーラーを有効にします
• 過剰な中断を防ぐために PodDisruptionBudgets を設定します