Kubernetes のデプロイ戦略

自分のアプリケーションに最適な Kubernetes ロールアウトを見つけてください。

Kubernetes デプロイオプションを把握する

市場に届けるまでの時間を短縮する、回復性の高いデプロイをダウンタイムなしで作成する、アプリや機能を高速に、またはより頻繁にリリースする、より柔軟に運営するなどのニーズがある場合は、適切な Kubernetes デプロイ戦略を選択することが、回復性の高いアプリケーションとインフラストラクチャを提供するための鍵となります。各 Kubernetes デプロイ戦略には、目標やニーズに応じてそれぞれの利点があります。

Kubernetes を初めてご利用になりますか? 基本を学ぶ

Kubernetes のデプロイのしくみ

Kubernetes デプロイ戦略を実装する前に、Kubernetes デプロイの構成要素と、それらがどのように連携して機能するかについて理解しておく必要があります。

Kubernetes のデプロイとは

YAML ファイル

Kubernetes クラスター (ポッドの構成) の望ましい状態を記述します。Kubernetes デプロイの基礎として動作します。

ポッド

アプリやワークフローで実行する必要があるコンテナー、共有リソース、環境です。

ReplicaSet

まったく同じ内容で構成されたポッドのグループを ReplicaSet と呼びます。これにより、Kubernetes デプロイ用に YAML ファイルに記述されたポッドの種類と数が常に確実に実行されます。1 つのポッドが失敗すると、新しいポッドが 1 つ作成されます。

Kube-controller-manager

YAML に記述された望ましい状態に一致するよう、クラスターの現在の状態を変更します。新しいポッドと ReplicaSet を作成したり、既存のものを更新または削除したりします。

Kube-scheduler

ポッドと ReplicaSet をワーカーノードにどのようにデプロイするかを決定し、これらのノードにトラフィックを分散します。

ロールアウト

現在の状態から望ましい状態にクラスターを再構成するプロセスで、ほとんどの場合はダウンタイムなしで実行できます。

Kubernetes ロールアウトのしくみ

YAML ファイル (クラスターの望ましい状態を記述) を作成します。
YAML ファイルを kubectl (Kubernetes コマンドラインインターフェイス) 経由でクラスターに適用します。
Kubectl はリクエストを kube-apiserver (変更をデータベース (etcd) に記録する前にリクエストを認証して承認する) に送信します。
kube-controller-manager は、新しいリクエストについて継続的にシステムを監視し、システムの状態が望ましい状態になるよう調整し、プロセス内に ReplicaSet、デプロイ、ポッドを作成します。
すべてのコントローラーが実行されたら、kube-scheduler が "一時停止" 状態のポッドがあるかどうかを確認します。それらのポッドはノードで実行されるようまだスケジュールされていないからです。scheduler はポッドに適切なノードを探し、次に各ノードの kubelet と通信して制御し、デプロイを開始します。

Kubernetes デプロイのユースケース

コンテナー化したアプリとワークフローを Kubernetes デプロイでロールアウトする 4 つの方法があります。お客様が使用する Kubernetes デプロイ戦略では、これらのうち 1 つまたは複数のユースケースが使用される可能性があります。

作成

まったく新しい Kubernetes ポッドと ReplicaSet をロールアウトします。

更新

望ましい状態を新たに宣言し、新しいポッドと ReplicaSet を制御された方法でロールアウトします。

ロールバック

Kubernetes デプロイを以前の状態に戻します。現在の状態が安定していないときに有効です。

スケール

Kubernetes デプロイ内のポッドと ReplicaSet の数を増やします。ポッドと ReplicaSet の内容は変更されません。

Kubernetes のデプロイ戦略

お客様のシナリオに対する最適な Kubernetes デプロイ戦略は、許容できるダウンタイム (発生する場合)、デプロイ環境、新しいバージョンやプラットフォームの安定性についてどの程度確信があるか、テストの必要性があるかどうかと学習する内容、リソースのコストと可用性、ビジネス上の目標など、多くの要素により変わります。ここでは、組織が運用環境で使用する、4 つの一般的なデプロイ戦略をご紹介します。

Ramped

Kubernetes の既定のロールアウト手法は、Ramped または Rolling デプロイです。このデプロイでは、ダウンタイムを避けるためにポッドを 1 つずつゆっくりと置換します。新しいポッドの準備が整った場合のみ、古いポッドはスケールダウンされます。デプロイで問題が発生した場合は、クラスター全体をオフラインにすることなく、Kubernetes デプロイを一時停止またはキャンセルすることができます。

Blue - Green

Blue - Green デプロイでは、アプリケーションやワークフローの新しいバージョン (Blue) を、現在のバージョン (Green) の実行中にリリースします。これにより、Blue バージョンを運用環境でテストすることができる一方で、ユーザーに安定した Green バージョンを利用してもらうことができます。テストが完了すると、Blue バージョンが段階的に Green バージョンに置き換わります。

カナリア

新しいバージョンを少数のユーザーグループにリリースすることで、お客様の顧客が、お客様の Kubernetes デプロイをテストすることができます。新しいバージョンの 1 つの ReplicaSet を現在のバージョンと並行して実行し、その後、エラーなしの特定期間が経過すると、新しいバージョンをスケールアップし、古いバージョンを削除します。

A/B テスト

Kubernetes のカナリアデプロイ戦略によく似ている A/B テスト戦略は、特定の顧客グループを対象としています。ただし A/B テストデプロイでは、さらに安定性のあるバージョンを確立することを目的にしており、ビジネス上の目標を達成するのに、そのバージョンがどの程度効果的であるかをテストするために使用されます。新しいバージョンが、Cookie、位置情報、オペレーティングシステム、デバイスの種類を基にユーザーに配布されます。これはよく現在のバージョンと並行して実行され、新しいバージョンの方が優れていると証明された場合にスケールアップされます。