Kubernetes本番環境運用で押さえるべき10のポイント

はじめに

Kubernetesの導入が進む中、開発環境では動いていたものが本番環境で問題を起こすケースが後を絶ちません。この記事では、複数のプロジェクトでKubernetes運用を経験した筆者が、本番環境で特に重要と感じたポイントを10個に絞って解説します。

1. リソース制限の適切な設定

なぜ重要か

リソース制限を設定しないと、1つのPodがノード全体のリソースを消費し、他のPodに影響を与える可能性があります。

推奨設定

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

ポイント:

• requests: Podのスケジューリングに使用される最小リソース
• limits: Podが使用できる最大リソース
• メモリ制限を超えるとPodがOOMKilledになる
• CPU制限を超えると、スロットリングされる

実際の設定値の決め方

1. 開発環境で kubectl top pod でリソース使用状況を確認
2. 本番負荷でのストレステスト実施
3. ピーク時の1.5倍を limits に設定
4. 通常時の使用量を requests に設定

2. Liveness Probe と Readiness Probe の設定

Liveness Probe

アプリケーションが正常に動作しているかを確認します。失敗するとPodが再起動されます。

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

Readiness Probe

Podがトラフィックを受け入れる準備ができているかを確認します。失敗するとServiceのエンドポイントから除外されます。

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

実装のコツ

• /health は軽量なチェック（アプリケーションプロセスが生きているか）
• /ready は依存サービスの接続確認も含める（DBへの接続など）
• initialDelaySeconds はアプリケーションの起動時間に合わせて設定

3. PodDisruptionBudget の設定

なぜ必要か

ノードのメンテナンスやクラスタのアップグレード時に、同時に停止できるPod数を制限し、サービスの可用性を保ちます。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

設定例

• minAvailable: 2: 常に最低2つのPodが稼働
• maxUnavailable: 1: 同時に停止できるのは1つまで

4. HorizontalPodAutoscaler (HPA) の活用

基本設定

CPU使用率に基づいた自動スケーリング:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

カスタムメトリクスの活用

Prometheus のメトリクスを使用した高度なスケーリングも可能です:

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: "1000"

5. NetworkPolicy によるトラフィック制御

デフォルト拒否ポリシー

まず、すべての通信を拒否するポリシーを設定:

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

必要な通信のみ許可

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

6. Secrets の安全な管理

避けるべき方法

• Secretをプレーンテキストでコミットする
• 環境変数として直接埋め込む

推奨される方法

External Secrets Operator の使用:

AWS Secrets Manager や HashiCorp Vault と連携し、Secretを外部で管理します。

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: myapp-secret
spec:
  secretStoreRef:
    name: aws-secrets-manager
  target:
    name: myapp-secret
  data:
  - secretKey: password
    remoteRef:
      key: prod/myapp/password

7. ログとメトリクスの集約

ログ集約

FluentdやFluent Bitを使用してログを集約:

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  fluent-bit.conf: |
    [OUTPUT]
        Name  es
        Match *
        Host  elasticsearch.logging.svc.cluster.local
        Port  9200

メトリクス監視

Prometheusでメトリクスを収集し、Grafanaで可視化:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics

8. デプロイ戦略の選択

ローリングアップデート

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Blue-Green デプロイ

Serviceのselectorを切り替えることで実現:

1. 新バージョンをデプロイ
2. Readiness Probeで正常性確認
3. Serviceのselectorを新バージョンに切り替え

Canary デプロイ

Istioなどのサービスメッシュを使用して、トラフィックを段階的に新バージョンに流します。

9. クラスタのバックアップ

etcd のバックアップ

Kubernetesのすべての状態はetcdに保存されています。定期的にバックアップを取得しましょう。

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Velero によるバックアップ

リソースとPersistentVolumeをまとめてバックアップできます。

10. セキュリティのハードニング

Pod Security Standards の適用

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

RBAC の適切な設定

最小権限の原則に従い、必要な権限のみを付与します。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

まとめ

本番環境でKubernetesを安全に運用するためには、リソース管理、監視、セキュリティなど多岐にわたる設定が必要です。ここで紹介した10のポイントは、最低限押さえておくべき基本事項です。

プロジェクトの規模や要件に応じて、さらに高度な設定やツールの導入を検討してください。

参考リンク

• Kubernetes公式ドキュメント
• Production Best Practices
• Pod Security Standards