KubernetesのDeployment strategy

Deployment strategy（デプロイ戦略）は、新しいバージョンのアプリケーションを本番環境にリリースする際に、ダウンタイムを最小限に抑え、リスクを軽減するための様々な手法です。Kubernetesなどのコンテナオーケストレーションツールでは、これらの戦略を簡単に実装できます。

以下に代表的なDeployment strategyとその使い方を説明します。

1. Rolling Update (ローリングアップデート)

• 概要: 最も一般的な戦略です。古いバージョンのPodを徐々に新しいバージョンに置き換えていきます。一度に置き換えるPodの数や、新しいPodが利用可能になるまでの待機時間を設定できます。
• メリット:
  ダウンタイムを最小限に抑えられる。
  問題が発生した場合、ロールバックが容易。
• デメリット:
  • 新旧バージョンが一時的に共存するため、互換性の問題が発生する可能性がある。
  • デプロイに時間がかかる場合がある。
• 使い方 (Kubernetes):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1  # 最大で何個のPodを余分に作成するか (例: 1個)
      maxUnavailable: 1 # 最大で何個のPodが利用不可になるか (例: 1個)
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2  # 新しいイメージバージョン

maxSurgeとmaxUnavailableを調整することで、デプロイの速度と可用性のバランスを調整できます。

• rollingUpdate パラメータ:
  • maxSurge: 更新プロセス中に作成できる、期待されるレプリカ数を超える Pod の最大数を指定します。 絶対値（例：2）またはパーセンテージ（例：25%）を指定できます。 パーセンテージは、期待されるレプリカ数に基づいて計算されます。 デフォルト値は 25% です。
  • maxUnavailable: 更新プロセス中に許可される、最大数の利用不可 Pod を指定します。 絶対値（例：1）またはパーセンテージ（例：25%）を指定できます。 パーセンテージは、期待されるレプリカ数に基づいて計算されます。 デフォルト値は 25% です。
• 適用可能なシナリオ:
  • 高い可用性が求められるアプリケーション。
  • ほとんどのアプリケーションの更新。
  • 新しいバージョンが古いバージョンと互換性がある場合。
• RollingUpdate ストラテジーの詳細な説明:
  たとえば、replicas が 3 に設定され、maxSurge が 1 に設定され、maxUnavailable が 0 に設定されている Deployment があるとします。 更新プロセスは次のようになります。
  1.Kubernetes は、最初に新しい Pod を作成します（maxSurge が 1 であるため、期待されるレプリカ数を超える 1 つの Pod が許可されます）。 現在、合計 4 つの Pod が実行されています（3 つの古い Pod と 1 つの新しい Pod）。
  2.新しい Pod が準備完了になり、リクエストの処理を開始すると、Kubernetes は古い Pod を 1 つ削除します（maxUnavailable が 0 であるため、利用不可の Pod は許可されません）。 現在、合計 3 つの Pod が実行されています（2 つの古い Pod と 1 つの新しい Pod）。
  3.Kubernetes は、すべての古い Pod が新しい Pod に置き換えられるまで、この方法でローリング更新を続行します。

2. Recreate (リクリエイト)

• 概要: 古いバージョンのPodをすべて停止してから、新しいバージョンのPodを作成します。
• メリット:
  新旧バージョンが同時に存在しないため、互換性の問題を回避できる。
  設定が簡単。
• デメリット:
  ダウンタイムが発生する。
• 使い方 (Kubernetes):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2  # 新しいイメージバージョン

ストラテジーの選択に関する推奨事項:

• デフォルトで RollingUpdate を選択: ほとんどのアプリケーションでは、RollingUpdate ストラテジーが最適な選択肢です。これは、可用性への影響を最小限に抑えるためです。
• Recreate ストラテジーを検討: 短いダウンタイムが許容される場合、または古い状態を完全にクリアする必要がある場合にのみ、Recreate ストラテジーの使用を検討する必要があります。
• rollingUpdate パラメータの調整: アプリケーションの可用性の要件と更新速度の要件に基づいて、maxSurge および maxUnavailable パラメータを調整します。 たとえば、より高速な更新が必要な場合は、maxSurge の値を大きくすることができます。 より高い可用性が必要な場合は、maxUnavailable の値を小さくすることができます。