Kubernetes の高度なデプロイメント戦略

最新のアプリケーション テクノロジーの分野では、コンテナ オーケストレーション プラットフォームにより、マイクロサービス ベースのアプリケーションのインフラストラクチャ構成が簡素化され、モジュール化によって効率的なワークロード管理が実現されます。 Kubernetes は、さまざまなデプロイメント リソースをサポートする広く採用されているプラ​​ットフォームであり、企業が CI/CD パイプラインを通じてさまざまなアプリケーションを大規模にデプロイおよび管理することを容易にします。 Kubernetes はデフォルトのデプロイメント戦略としてローリング アップデートを提供しますが、一部のユース ケースでは、クラスター内でサービスをデプロイまたは更新するために従来とは異なる方法が必要になります。以下では、Kubernetes デプロイメントの基本的な概念を確認し、さまざまな高度な Kubernetes デプロイメント戦略、その長所と短所、およびユースケースについて説明します。

Kubernetes デプロイメントの概念

展開中に、クラスター管理者はアプリケーションのライフサイクルと更新の実行方法をカスタマイズできます。 Kubernetes は通常、デプロイメント リソースを使用し、さまざまなアプリケーションを宣言的に更新します。自動化されたデプロイメント方法により、各クラスター オブジェクトとアプリケーションの望ましい状態が実装され、維持されます。さらに、バックエンドは人間の介入なしに安全かつ繰り返し可能な方法でアプリケーションの更新を実行できます。言い換えれば、Kubernetes のデプロイメントは、クラスター管理者が次のことを達成するのに役立ちます。

• 単一のポッドまたはレプリカセットをデプロイする
• ポッドまたはレプリカセットのグループを更新する
• 以前のバージョンへのロールバック
• 展開を一時停止または再開する
• さまざまな展開のスケーリング

以下では、Kubernetes がコンテナ化されたアプリケーションの更新プロセスをどのように簡素化し、継続的デリバリーの課題にどのように対処するかについて説明します。

Kubernetes オブジェクト

Kubernetes は、クラスターの状態を管理するために、多くの種類のワークロード リソース オブジェクトを永続的なエンティティとして使用できますが、Kubernetes API は通常、Deployment、ReplicaSet、StatefulSet、および DaemonSet の 4 つのリソースを使用して、アプリケーションに宣言的な更新を行います。これら 4 つのリソースの特徴を詳しく見てみましょう。

展開

デプロイメントは、アプリケーションの望ましい状態を定義および識別するために使用できる Kubernetes リソースです。クラスター管理者は、コントローラーをデプロイし、実際の状態を徐々に期待される状態に変更するために、デプロイ YAML ファイルに期待される状態を記述します。高可用性を確保するために、デプロイメント コントローラーは継続的に監視し、必要に応じて障害が発生したクラスター ノードとポッドを正常なものに置き換えます。

レプリカセット

ReplicaSet を使用すると、特定の数のポッドを維持し、高可用性を確保できます。 ReplicaSet マニフェスト ファイルには、次のフィールドが含まれます。

• コレクションに属するポッドを識別するために使用されるセレクター。
• レプリカの数は、セット内に含めるべきポッドの数を示します。
• ポッド テンプレートは、レプリカ セットの基準を満たすために新しいポッドが作成する必要があるデータを示すために使用されます。

ステートフルセット

StatefulSet オブジェクトは、ステートフル アプリケーション内のポッドのデプロイメントとスケーリングを管理します。このリソースは、同じコンテナ仕様に基づいてポッドを管理し、ポッドのグループ全体の一意性と整然とした配置を保証します。 StatefulSet の永続的なポッド識別子により、クラスター管理者はワークロードを高可用性の永続ストレージ ボリュームに簡単に接続できるようになります。

デーモンセット

DaemonSet は、一連のノードがポッドのレプリカを実行していることを確認することで、アプリケーションのデプロイメントを維持するのに役立ちます。 DaemonSet リソースは主に、次のようなさまざまなエージェントのデプロイメントとライフサイクルを管理するために使用されます。

• 各ノード上の各クラスタストレージエージェント
• ログ収集デーモン
• ノード監視デーモン

https://kubernetes.io/docs/concepts/workloads/controllers/ で、さまざまな Kubernetes ワークロード リソースとその詳細の一覧を確認することもできます。

デプロイメントアップデートの使用

Kubernetes デプロイメントは、ポッドを開始および停止するための予測可能な方法を提供します。これらのリソースを使用すると、デプロイメント、変更のロールバック、ソフトウェアのリリース サイクルを自律的かつ反復的に簡単に管理できます。現在、Kubernetes は、より小規模で頻繁な更新を実現し、アプリケーションに次の利点をもたらすさまざまなデプロイメント戦略を提供しています。

• 顧客からのフィードバックを迅速化し、機能の最適化を向上
• 市場投入までの時間を短縮
• DevOpsチームの生産性を向上

デフォルトでは、Kubernetes が提供するローリング アップデートを標準のデプロイメント戦略として使用して、クラスターのダウンタイムを回避するために、古いポッドを一度に新しいバージョンに置き換えることができます。さらに、Kubernetes は、機能の目標とタイプに応じて、ブルーグリーン、カナリア、A/B デプロイメントなどのさまざまな高度なデプロイメント戦略もサポートします。以下では、これらの戦略の特徴と、その長所と短所について詳しく説明します。

Kubernetes デプロイメントの高度な戦略

デプロイメント構成とルーティング機能の組み合わせにより、リリース チームは、完全バージョンを送信する前に、実際の運用環境で新機能の有効性をテストしやすくなります。このため、開発者は Kubernetes がサポートする高度なデプロイメント戦略を活用して、特定のバージョンの品質を正確に制御できます。もちろん、アプリケーションの更新や新機能をリリースするために採用すべき具体的な Kubernetes デプロイメント方法は、実際のユースケースとワークロードによって異なります。

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

ブルーグリーン戦略では、アプリケーションの新しいインスタンスと古いインスタンスが同時にデプロイされます。ユーザーは引き続き既存のバージョン (青) にアクセスできますが、サイト信頼性エンジニアリング (SRE) チームと QA チームには、同じ数の新しいバージョン (緑) のインスタンスが提供されます。 QA チームがグリーン バージョンがすべてのテスト要件を満たしていることを確認すると、ユーザーは新しいバージョンにリダイレクトされます。これは通常、負荷分散サービスのセレクター フィールドのバージョン タグを更新することによって行われます。通常、ブルーグリーン デプロイメントは、開発者がバージョン管理の問題を回避したい場合に適しています。

ブルーグリーン展開戦略の使用

アプリケーションの最初のバージョンが v1.0.0 で、2 番目のバージョンが v2.0.0 であると仮定します。次に、次のコード スニペットはサービスの最初のバージョンを指します。

 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: ダーウィン- サービス- A
 仕様:
 タイプ: ロードバランサー
セレクター:
 アプリ: nginx
 バージョン: v1.0.0
 ポート:
 - 名前: http
 ポート: 80
 ターゲットポート: 80

そして、2 番目のバージョンを指すサービスは次のとおりです。

 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: ダーウィン- サービス- b
 仕様:
 タイプ: ロードバランサー
セレクター:
 アプリ: nginx
 バージョン: v2.0.0
 ポート:
 - 名前: http
 ポート: 80
 ターゲットポート: http

必要なテストを完了し、2 番目のバージョンを承認したら、最初のサービスを指すセレクターを v2.0.0 に変更する必要があります。

 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: ダーウィン- サービス- A
 仕様:
 タイプ: ロードバランサー
セレクター:
 アプリ: nginx
 バージョン: v2.0.0
 ポート:
 - 名前: http
 ポート: 80
 ターゲットポート: http

新しいバージョンのアプリケーションが期待どおりに動作する場合は、バージョン v1.0.0 を「リリース」できます。

カナリアデプロイメント

カナリア戦略では、一部のユーザーは新しいバージョンを運ぶポッドにルーティングされます。このユーザーベースは徐々に増加し、古いバージョンに接続するグループはそれに応じて減少します。この戦略は、2 つのバージョンを使用する一連のユーザーのエクスペリエンスを比較するために使用できます。エラーが検出されない場合は、古いバージョンを使用しているユーザーに新しいバージョンをプッシュできます。

カナリアデプロイメント戦略の使用

ネイティブ Kubernetes カナリア デプロイメント プロセスには、次の手順が含まれます。

1. 次の手順に従って、バージョン 1 を実行するために必要なレプリカをデプロイします。

最初のアプリケーションをデプロイします。

 $ kubectl apply -f darwin - v1 .yaml ​

必要なレプリカ数に合わせてスケールします。

 $ kubectl スケール-- レプリカ= 9 darwin - v1 をデプロイします

2. インスタンスのバージョン 2 をデプロイします。

 $ kubectl apply -f darwin - v2 .yaml ​

3. バージョン 2 が正常にデプロイされたかどうかをテストします。

 $ service = $ ( minikube サービスdarwin -- url )
 $ スリープ中0.1 ; curl "$service" を実行します。 終わり

4. デプロイメントが成功したら、バージョン 2 のインスタンスの数を増やします。

 $ kubectl スケール-- レプリカ= 10 デプロイDarwin - v2

5. すべてのレプリカがオンラインになったら、バージョン 1 を「正常に」削除できます。

 $ kubectl 削除デプロイdarwin - v1

A/B展開

A/B 展開を使用すると、管理者は特定の制限や条件を付けて、特定のユーザーのサブセットを新しいバージョンにルーティングできます。このような展開は主に、特定の新機能に対するユーザーベースの反応を評価するために使用されます。テスト中に新しい機能が提示されたことをユーザーが認識しないため、A/B 展開は「ダーク ローンチ」と呼ばれることもあります。

A/B展開戦略の使用

以下は、Istio サービス メッシュで A/B テストを実行する方法の例です。トラフィックの重みを使用して、さまざまなバージョンを展開すると役立ちます。

1. クラスターに Istio がインストールされていると仮定して、まずアプリケーションの 2 つのバージョンをデプロイする必要があります。

 kubectl を適用します。 ​ ​ yaml -f ダーウィン- v2 。 ヤム

2. 次に、Istio ゲートウェイを通じて 2 つのバージョンを公開し、次のコマンドを使用してリクエストを最初のサービスに一致させます。

 $ kubectl apply -f ./gateway .yaml -f ./virtualservice .yaml ​ ​

3. 次に、次のコマンドを使用して、重みに基づいて Istio の VirtualService ルールを適用します。

 kubectl apply -f ./virtualservice -weight . ​ ​ ​ ヤム

トラフィックの重みをバージョン間で 1:10 の比率で分散します。トラフィックの重みを変更するには、各サービスの重みを編集し、Kubernetes CLI を通じて VirtualService ルールを更新します。

それぞれの高度な展開戦略を使用するタイミング

Kubernetes のユースケースは、可用性の要件、予算の制約、利用可能なリソース、その他の考慮事項によって異なるため、すべてのケースに適したデプロイメント戦略は存在しません。展開戦略を選択するときは、次の表を考慮してください。

Kubernetes 導入戦略の比較

まとめ

Kubernetes 管理者は、さまざまなデプロイメント リソースを使用して、効率的なバージョン管理システムを確立し、ポッドを更新したり、以前のバージョンにロールバックしたり、インフラストラクチャを拡張して増大するワークロードに対応したり、さまざまなバージョンのアプリケーションを管理することでダウンタイムを最小限に抑えたりすることができます。

上記で紹介したさまざまな Kubernetes の高度なデプロイメント戦略により、管理者はトラフィックとリクエストを特定のバージョンにルーティングし、実際のテスト環境でさまざまなエラーを処理できるようになります。同時に、これらの戦略は、管理者や開発者が変更を完全にコミットする前に新しい機能が計画どおりに実行できることを確認したり、十分なロールバック オプションを通じて複数の疎結合サービスを実装したりして、アプリケーションの更新や機能を迅速に提供するためにもよく使用されます。もちろん、具体的な選択は実際のアプリケーション環境と上記の比較表によって異なります。

その他の参考資料

• kubectl を使用してデプロイメントを作成する
• Kubernetes のさまざまなデプロイメントユースケース
• Kubernetes デプロイメント ライフサイクルのさまざまな状態

翻訳者について

51CTO コミュニティの編集者である Julian Chen 氏は、IT プロジェクトの実装において 10 年以上の経験を持っています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティの知識と経験の普及に注力しています。彼は、ブログ投稿、特別トピック、翻訳の形で最先端のテクノロジーと新しい知識を共有し続けています。彼はオンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。

原題: Advanced Kubernetes Deployment Strategies、著者: Sudip Sengupta