Kubernetes のさまざまなデプロイメント戦略を探る

[51CTO.com クイック翻訳] ご存知のとおり、クラウドネイティブアプリケーションの開発プロセスでは、単位時間あたりのアプリケーション展開の量と品質をいかに高速化するかを競うことがよくあります。マイクロサービス アプローチを使用すると、開発者は完全にモジュール化されたアプリケーションを迅速に設計できるため、より多くのチーム メンバーが単一のアプリケーションに対して同時に変更とリリースを記述および展開できるようになります。より短期間で頻繁な展開により、企業に次のようなメリットがもたらされることがわかります。

• 市場投入までの時間を短縮します。
• 顧客は新機能をより早く利用できるようになります。
• さまざまな顧客からのフィードバックがより迅速に製品チームに届くようになり、製品チームも反復を通じて既存の問題をより迅速に解決できるようになります。
• より多くの新機能を本番環境にリリースすることで、開発者の士気を高めます。

もちろん、リリース頻度が高くなると、アプリケーションの信頼性や顧客エクスペリエンスの満足度にも悪影響が及ぶことになります。そのため、運用チームと DevOps チームが協力してプロセスを開発し、さまざまな展開戦略を管理して、製品と顧客へのリスクを最小限に抑える必要があります。 (CI/CD パイプラインの自動化の詳細については、以下を参照してください)

この記事では、ローリング デプロイメント、リビルド、ブルーグリーン、カナリア、およびそれらのバリエーションなどの高度な方法を含む、さまざまな Kubernetes デプロイメント戦略について説明します。

展開戦略

目標に応じて、Kubernetes のさまざまなデプロイメント戦略を採用できます。たとえば、より多くのテスト バージョンを起動するには、特定の環境または一部のユーザーと顧客に変更を加える必要がある場合があります。または、特定の機能を一般公開する前に、一部のユーザーに対してテストしたい場合もあります。

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

ローリング デプロイメントは、Kubernetes の標準化されたデフォルトのデプロイメント方法です。実行速度は遅くなりますが、クラスターのダウンタイムを発生させることなく、アプリケーションのポッドの古いバージョンを新しいバージョンに 1 つずつ置き換えることができます。

古いポッドの置き換えを開始する前に、ローリング アップデートでは、準備状況プローブ (準備状況プローブを参照) を通じて新しいポッドが配置されているかどうかを確認する必要があります。問題が発生した場合、クラスター全体のダウンタイムを回避するために、ローリング アップデートまたはデプロイメントが中断されます。したがって、次の YAML 定義ファイルを参照して、ローリング デプロイメント方式で古いイメージを新しいイメージに置き換えることができます。

 APIバージョン: アプリ/v1beta1
種類: デプロイメント
メタデータ:
名前: awesomeapp
仕様:
  レプリカ: 3
  テンプレート：
        メタデータ:
           ラベル:
             アプリ: 素晴らしいアプリ
        仕様:
          コンテナ:
            -名前: awesomeapp
              イメージ: imagerepo-ユーザー/awesomeapp:new
              ポート:
                - コンテナポート: 8080

以下に示すように、マニフェスト ファイル内のパラメータを調整することで、ローリング アップデートをさらに改良できます。

仕様:
  レプリカ: 3
  戦略：
        タイプ: ローリングアップデート
        ローリングアップデート:
           最大サージ: 25%
           最大利用不可: 25%
  テンプレート：
  ...

再現する

これは非常にシンプルなデプロイメント方法で、下の図に示すように、すべての古いポッドを直接「削除」し、すぐに新しいポッドに置き換えます。

対応する標準マニフェスト ファイルは次のとおりです。

仕様:
  レプリカ: 3
  戦略：
        タイプ: 再作成
  テンプレート：
  ...

青/緑または赤/黒の展開

ブルー/グリーン (レッド/ブラックと呼ばれることもあります) デプロイメント戦略では、アプリケーションの古いバージョン (グリーンと呼ばれる) とそれに対応する新しいバージョン (ブルー) が同時に本番環境にデプロイされます。下の図に示すように、一般ユーザーは緑色のバージョンにのみアクセスできます。一方、QA チームは、別のサービスまたは直接ポート転送を通じて、ブルー バージョンで自動テストを実行できます。

 APIバージョン: アプリ/v1beta1
種類: デプロイメント
メタデータ:
名前: awesomeapp-02
仕様:
  テンプレート：
        メタデータ:
           ラベル:
             アプリ: 素晴らしいアプリ
             バージョン: "02"  

したがって、新しいバージョンが完全にテストされ承認された後にのみ、ユーザー向けのサービスはブルー バージョンに切り替えられ、古いグリーン バージョンは最終的に「廃止」されます。

 APIバージョン: v1
種類: サービス
メタデータ:
名前: awesomeapp
仕様:
  セレクタ：
    アプリ: 素晴らしいアプリ
    バージョン: "02"  
 ...

カナリア

カナリアデプロイメントはブルー/グリーンデプロイメントに似ていますが、より制御されているため、より広く使用されています。カナリア デプロイメント タイプの主な特徴は、段階的なプログレッシブ配信モデルの使用です (を参照)。現在、ダークローンチや A/B テストなど、多くの戦略がこのカテゴリに分類されます。

新しい機能をテストしたい場合は、通常、アプリケーションのバックエンドにカナリア デプロイメント メソッドを使用できます。ここでは、ほぼ同一のサーバーを 2 つ準備できます。1 つは元の機能を引き続き使用し、すべてのユーザーが利用できるサーバーです。もう 1 つは、新機能が導入され、少数のユーザーにのみ公開されているものです。動作結果を比較することで、報告されたエラーが発生しなくなったら、新しいバージョンを運用システムのアーキテクチャの残りの部分に徐々に「ロールアウト」することができます。

このような戦略は、Kubernetes リソースを使用して古い Pod を新しい Pod に置き換えることで実現できますが、通常は Istio などのサービス メッシュを使用して、より便利かつ簡単に実装します。

以下の例に示すように、2 つの異なるマニフェストを Git に配置することができます。1 つは 0.1.0 としてタグ付けされた GA (GitApp) で、もう 1 つは 0.2.0 としてタグ付けされたカナリア バージョンです。 Istio 仮想ゲートウェイのマニフェスト ファイルでは、異なる重みを変更することで、2 つのデプロイメントのトラフィック パーセンテージ クォータを管理します。

Istio を使用してカナリア デプロイメントを実装する方法のステップ バイ ステップ ガイドについては、「GitOps ワークフローでの Istio の使用」チュートリアルを参照してください。

Weaveworks Flagger を使用したカナリア デプロイメント

カナリアデプロイメントを管理するもう一つのシンプルで効果的な方法は、Weaveworks Flaggerを使用することです（

Flagger は、カナリア デプロイメントの自動化を容易にします。 Istio または App Mesh を使用してトラフィックをルーティングおよびシフトし、Prometheus メトリックによるカナリア分析を使用します。さらに、Canary Analysis では、さまざまな受け入れテスト、負荷テスト、その他の種類のカスタム検証用に WebHook を拡張することもできます。

Flagger は Kubernetes デプロイメントを使用し、HPA (水平ポッドオートスケーラー) を選択して一連のオブジェクト (Kubernetes デプロイメント、ClusterIP サービス、Istio および APP Mesh 仮想サービスを含む) を作成し、カナリアスタイルの分析とプッシュを実行します。

制御ループを実装することにより、Flagger は HTTP リクエストの成功率、平均リクエスト期間、Pod の健全性などの主要なパフォーマンス指標を継続的に監視し、トラフィックを徐々にカナリア サービスに移行します。同時に、KPI を分析してカナリア サービス レベルの向上と低下を把握し、分析結果を Slack に公開することもできます。詳細と例については、「APP Mesh のプログレッシブ配信」を参照してください。

ダークデプロイメントとA/Bデプロイメント

ダークデプロイメントは、カナリアの別のバリエーションです。ダークデプロイメントとカナリアデプロイメントの違いは、ダークデプロイメントは主にフロントエンドの処理に使用されるのに対し、カナリアデプロイメントはバックエンドで使用されることが多いことです。

ダークデプロイメントの別名は A/B テストです。新しい機能をテストするには、少数のユーザーを選択し、ユーザーに知られずに展開してプッシュする必要がある場合があります。これはいわゆる「ダーク」展開です。

機能トグルやその他の種類のツールを使用することで、ユーザーが新しい機能とどのように対話するかを知ることができます。これにより、機能をユーザーに正式にプッシュするかどうか、新しい UI がわかりにくいかどうか、その他の種類の指標を判断するのに役立ちます。

フラグとA/B展開

実際、重み付けルーティングに加えて、Flagger は HTTP のさまざまな一致条件に基づいてアクセス トラフィックをカナリア サービスにルーティングすることもできます。たとえば、A/B テストのシナリオでは、さまざまな HTTP ヘッダーまたは Cookie を使用して特定のユーザーをルーティングできます。明らかに、これはセッションの関連付けを実行する必要があるフロントエンド アプリケーションに特に役立ちます。もちろん、具体的な内容については、Flagger の関連ドキュメントを参照できます。

原題: Kubernetes デプロイメント戦略、著者: Anita Buehrle

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。