Kubernetes の導入戦略を 1 つの記事で理解する

この記事では、Kubernetes のデプロイメントの概念と一般的な戦略について詳しく説明し、それぞれの長所と短所を見ていきます。適切な導入戦略により、ダウンタイムを最小限に抑え、顧客エクスペリエンスを向上させ、信頼性を高めながらアプリケーションをリリースできます。

Kubernetes のデプロイメント戦略とは何ですか?

Kubernetes デプロイメントは、通常 YAML ファイルで構成される宣言ステートメントであり、アプリケーションのライフサイクルと、そのアプリケーションの更新の管理方法を定義します。

アプリケーションを K8s クラスターにデプロイする場合、選択したデプロイメント戦略によって、アプリケーションが古いバージョンから新しいバージョンに更新される方法が決まります。一部の戦略ではダウンタイムが発生する可能性がありますが、他の戦略ではテストの概念を導入し、ユーザー分析を可能にする場合があります。この記事では、一般的に使用される 2 つの基本的な K8s デプロイメント戦略を紹介します。

再現
ローリング

次のポリシーは、トラフィックフローの方向をさまざまな方法で制御できるため、「高度な展開ポリシー」と見なされます。

青/緑
カナリア
AB型
シャドウデプロイメント

K8s はデフォルトの戦略としてローリングアップデート戦略を使用しますが、場合によっては適切ではないことがあります。それぞれの戦略について詳しく議論しましょう！

1. デプロイメントを再作成する

デプロイメントを再作成すると、すべてのポッドが終了し、新しいバージョンのポッドに置き換えられます。これは、アプリケーションの古いバージョンと新しいバージョンを同時に実行できない場合に役立ちます。この戦略を使用することで発生するダウンタイムは、アプリケーションのシャットダウンと起動にかかる時間によって異なります。完全な置き換えにより、アプリケーションの状態も完全に更新されます。

次の例は、type=Recreate が再作成を意味することを示しています。

 spec: replicas: 10 strategy: type: Recreate

2. ローリングデプロイメント

ローリングアップデートは、クラスターのダウンタイムを短縮することを目的とした K8s のデフォルトのデプロイメントモードです。ローリングアップデートでは、ダウンタイムなしで、アプリケーションの古いバージョンを実行している Pod を徐々に新しいバージョンに置き換えます。

これを実現するために、準備プローブが使用されます。

準備プローブは、アプリケーションがいつ利用可能になるかを監視します。プローブが失敗した場合、そのポッドにトラフィックは送信されません。これらのプローブは、データベース接続、キャッシュデータの初期化、アプリケーションリリースの登録など、準備前にいくつかの初期化手順を実行する必要があるアプリケーションに使用されます。

準備プローブがアプリケーションの新しいバージョンが利用可能であることを検出すると、アプリケーションの古いバージョンは削除されます。何か問題が発生した場合、デプロイメントを停止して以前のバージョンにロールバックすることで、クラスター全体のダウンタイムを回避できます。各ポッドは 1 つずつ置き換えられるため、大規模なクラスターではデプロイメントに時間がかかる場合があります。別のデプロイメントが完了する前に新しいデプロイメントがトリガーされた場合、バージョンは新しいデプロイメントで指定されたバージョンに更新され、まだ正常にデプロイされていない以前のデプロイメントバージョンは無視されます。

ローリングアップデートデプロイメントをトリガーする条件は、Pod のイメージ、環境変数、ラベルの更新など、Pod 仕様の何らかの変更です。 kubectl set image コマンドを使用してPod イメージを更新できます。

yaml ファイルの Spec: -> strategy: セクションでは、 maxSurgeとmaxUnavailableという 2 つのパラメータを使用してデプロイメントを調整できます。両方のパラメータは、パーセンテージまたは絶対値として指定できます。水平 Pod 自動スケーリングを使用する場合は、パーセンテージを使用する必要があります。

maxSurge は、デプロイメントが同時に作成できる Pod の最大数を指定します。
maxUnavailable は、デプロイメント中に使用不可にできる Pod の最大数を指定します。

たとえば、次の構成では 10 個のレプリカが必要で、同時に最大 3 個のレプリカが作成され、デプロイメント中に 1 つのレプリカが使用不可になることが許可されます。

 spec: replicas: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 3 maxUnavailable: 1

3. ブルー/グリーンデプロイメント

ブルー/グリーンデプロイメントでは、新しいアプリケーションバージョン (グリーン) を古いバージョン (ブルー) と並行してデプロイします。サービスセレクターオブジェクトがロードバランサーとして機能し、新しいアプリケーション (緑) がテストおよび検証されると、トラフィックは古いアプリケーションではなく新しいアプリケーションに送信されます。ブルー/グリーンデプロイメントでは、デプロイメント中に 2 倍のアプリケーションリソースを起動する必要があるため、コストが増加する可能性があります。

これを実現するには、サービスをデプロイする前に設定する必要があります。たとえば、web-app という名前のアプリケーションのバージョン v1.0.0 のブルーデプロイメントの場合、yaml ファイルのサービスセレクターセクションは次のようになります。

 kind: Service metadata: name: web-app-01 labels: app: web-app selector: app: web-app version: v1.0.0

青い Web アプリの展開は次のとおりです。

 kind: Deployment metadata: name: web-app-01 spec: template: metadata: labels: app: web-app version: "v1.0.0"

トラフィックをアプリケーションの新しい (グリーン) バージョンに誘導する場合は、マニフェストファイルを更新して新しいバージョン v2.0.0 を指すようにします。

 kind: Service metadata: name: web-app-02 labels: app: web-app selector: app: web-app version: v2.0.0

グリーンアプリケーションの展開は次のとおりです。

 kind: Deployment metadata: name: web-app-02 spec: template: metadata: labels: app: web-app version: "v2.0.0"

4. シャドウデプロイメント

カナリアという用語は、シャドウデプロイメントと同じ意味で使用されます。

シャドウデプロイメントとは、主に監視とテストの目的で、アプリケーションの新しいバージョンを既存の運用バージョンと並行してデプロイする戦略です。シャドウデプロイメントでは、ユーザートラフィックは新しいバージョンにアクティブにルーティングされません。これは、新機能の本番負荷をテストする場合に特に役立ちます。

このテクノロジーはより複雑であり、特にエクスポートフローには特別な要件が必要です。たとえば、製品がある場合、シャドウテストのために支払いサービスを呼び出すと、顧客が注文に対して 2 回支払いをすることになり、複雑さが比較的高くなります。

5. カナリアデプロイメント

カナリアデプロイメントは、一部のユーザーを対象にアプリケーションの新しいバージョンをテストする場合や、新しいバージョンの機能に完全に自信がない場合に使用できます。新しいバージョンのコピーは古いバージョンと一緒にリリースされ、古いバージョンのアプリケーションは大多数のユーザーに使用され、新しいバージョンのアプリケーションは少数のテストユーザーに使用されます。新しい展開が成功した場合、徐々により多くのユーザーに拡大されます。

たとえば、100 個の実行中のポッドを持つ K8s クラスターでは、95 個がアプリケーションのバージョン v1.0.0 を実行しており、5 個が新しいバージョン v2.0.0 を実行しています。ユーザーの 95% は古いバージョンにルーティングされ、5% は新しいバージョンにルーティングされます。これを実現するために、個別にスケーリングできる 2 つのデプロイメントを並行して使用します。

古いアプリケーションの yaml ファイルの spec セクションは次のようになります。

 spec: replicas: 95

新しいアプリケーションの yaml ファイルの spec セクションは次のようになります。

 spec: replicas: 5

上記の例では、100 個の Pod を実行するのは現実的ではない可能性があります。より良いアプローチとしては、NGINX、HAProxy、Traefik などのロードバランサー、または Istio、Hashicorp Consul、Linkrd などのサービスメッシュを使用して、トラフィックをより細かく制御することができます。

6. A/Bデプロイメント

カナリアデプロイメントと同様に、A/B デプロイメントでは、いくつかのターゲティングパラメータ (通常は HTTP ヘッダーや Cookie など) に基づいて特定のユーザーをターゲットにし、重みに基づいて異なるバージョン間でトラフィックを分散できます。この手法は、特定の機能の変換率をテストし、最終的な展開のために変換率が最も高いバージョンを選択するために広く使用されています。

このアプローチは、多くの場合、収集されたユーザー行動データに基づいており、より優れたビジネス上の意思決定を行うために使用されます。 A/B テスト中は通常、ユーザーには新しい機能は通知されないため、古いバージョンと新しいバージョンを使用するユーザー間のエクスペリエンスを現実的にテストして比較することができます。 A/B デプロイメントを使用したデプロイメントは、追加のテスト期間とユーザーエクスペリエンス分析のために遅くなる可能性があります。

A/B デプロイメントは、Istio とFlaggerを使用して自動化できます。