この記事では、 Azure Kubernetes Service (AKS) での信頼性のサポートについて説明します。 可用性ゾーン と 複数リージョンのデプロイによるリージョン内の回復性について説明します。
信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。
運用環境のデプロイに関する推奨事項
AKS で信頼性の高い運用ワークロードをデプロイする方法に関する推奨事項については、次の記事を参照してください。
信頼性アーキテクチャの概要
AKS クラスターを作成すると、Azure プラットフォームによって自動的に作成および構成されます。
API サーバー、etcd、スケジューラ、およびワークロードの管理に必要なその他のポッドを含む コントロール プレーン 。
サブスクリプションのシステム ノード プール は、kube-system 名前空間で実行されるアドオンやその他のポッドをホストします。
この初期ノード プールのセットアップが完了したら、独自のユーザー ワークロードの ノード プールを追加または削除 できます。 AKS は信頼性のためにノード プールを管理しないため、ワークロードがインフラストラクチャの障害に対して確実に回復可能であることを確認する必要があります。
回復性は、お客様と Microsoft との共同責任になります。 コンピューティング サービスとして、AKS はクラスターの信頼性のいくつかの側面を管理しますが、他の側面を管理する責任があります。
Microsoft は、AKS のコントロール プレーンとその他のマネージド コンポーネントを管理します。
お客様の責任は次のとおりです。
サービスに接続するノード プールやロード バランサーなどのコンポーネントを、信頼性の要件を満たすように構成する方法を定義します。 コンポーネントを定義した後、Microsoft はユーザーに代わってコンポーネントをデプロイおよび管理します。
ストレージやデータベースなど、AKS クラスターの外部にあるコンポーネントを管理します。 これらのコンポーネントが信頼性要件を満たしていることを確認します。 ワークロードをデプロイするときは、それらのサービスのベスト プラクティスに従って、他の Azure コンポーネントも回復性のために構成されていることを確認します。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
AKS を使用すると、アプリケーションのクラッシュ、ポッドのスケーリングと分散操作、ノードの修正プログラムの適用、ハードウェアやネットワークの問題などの一時的なインフラストラクチャの障害など、さまざまな理由で一時的な障害が発生する可能性があります。
一時的な障害をすべて排除することは不可能であるため、AKS でホストされているアプリケーションにアクセスするクライアントは、失敗した要求を再試行し、他の一時的なエラー処理の推奨事項に従う準備をする必要があります。 デプロイで Kubernetes と Azure のベスト プラクティスに従うことで、一時的な障害の可能性を最小限に抑え、発生する可能性のあるダウンタイムを回避または軽減できます。
ポッド YAML にポッド中断予算 (PDB) を設定して、特定の時点で
Ready
状態にする必要があるポッドの数を指定します。 PDB を設定すると、AKS はノードを切断してドレインする操作を実行するときにレプリカの最小可用性を確保します。 アップグレードなどのプロセス中に PDB が満たされない場合、ポッドは引き続き機能し、操作が失敗する可能性があります。 詳細については、 PDB を参照してください。maxUnavailable
を使用して、特定の時点で使用できなくなる可能性があるレプリカの最大数を定義します。 たとえば、ローリング再起動を実行すると、AKS によって、特定の時点でポッドの数がmaxUnavailable
を超えてチャーンされないことが保証されます。 詳細については、「 maxUnavailable」を参照してください。デプロイのベスト プラクティスに従います。 ポッドレプリカは、アプリケーションの問題のために失敗する可能性もあります。 詳細については、AKS クラスター の信頼性に関するデプロイ レベルのベスト プラクティス を参照してください。
注
AKS でベスト プラクティスに準拠するようにデプロイを検証し、ブロック通知または警告通知を提供する場合は、 デプロイセーフガード (プレビュー) を使用できます。 デプロイセーフガードは、コードがクラスターにデプロイされる前に製品のベスト プラクティスを適用するのに役立つマネージド オファリングです。
可用性ゾーンのサポート
可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
可用性ゾーンをサポートするリージョンに AKS クラスターをデプロイする場合、コンポーネントごとに異なる種類の構成が必要になります。
AKS コントロール プレーンは、既定でゾーン回復性があります。 ゾーンが失敗した場合、コントロール プレーンは回復性を実現するために構成や管理を必要としません。 ただし、コントロール プレーンの回復性は、ゾーンで障害が発生してもクラスターが動作し続けるのに十分ではありません。 デプロイするシステム ノード プールとユーザー ノード プールの場合は、可用性ゾーンのサポートを有効にして、ワークロードが可用性ゾーンの障害に対する回復性を確保できるようにする必要があります。
リージョンのサポート
ゾーン回復性の高い AKS クラスターは、可用性ゾーンをサポートする任意のリージョンにデプロイできます。
考慮 事項
リージョン内の AKS 実稼働ワークロードの信頼性と回復性を高めるためには、次の構成を行ってゾーン冗長性のために AKS を構成する必要があります。
複数のレプリカをデプロイします。 Kubernetes は、ノード ラベルに基づいてポッドを複数のノードに分散します。 ワークロードを複数のゾーンに分散するには、ポッドの複数のレプリカをデプロイする必要があります。 たとえば、3 つのゾーンでノード プールを構成したが、ポッドのレプリカを 1 つだけデプロイする場合、デプロイはゾーン回復性がありません。
自動スケーリングを有効にします。 Kubernetes ノード プールには、手動および自動のスケーリング オプションが用意されています。 手動スケーリングを使用すると、必要に応じてノードを追加または削除でき、保留中のポッドはノード プールをスケールアップするまで待機します。 AKS マネージド スケーリングでは、 クラスター オートスケーラー または ノード自動プロビジョニング (NAP) が使用されます。 AKS は、サブスクリプションの SKU クォータと容量内のポッドの要件に基づいてノード プールをスケールアップまたはスケールダウンします。 この方法は、可用性ゾーン内の使用可能なノードでポッドがスケジュールされていることを確認するのに役立ちます。
ポッド トポロジの制約を設定します。 ポッド トポロジの分散制約を使用して、ポッドが異なるノードまたはゾーンに分散する方法を制御します。 制約は、HA、回復性、および効率的なリソースの使用を実現するのに役立ちます。 ポッドをゾーン間で厳密に分散する場合は、制約を設定してポッドを強制的に保留中の状態にし、ゾーン間のポッドのバランスを維持できます。 詳細については、「 ポッド トポロジの分散制約」を参照してください。
ゾーン回復性のあるネットワークを構成します。 ポッドが外部トラフィックを処理する場合は、 Azure Application Gateway、AzureLoad Balancer、Azure Front Door などのサービスを使用してクラスター ネットワーク アーキテクチャを構成します。
依存関係がゾーン耐性を確保していることを確認します。 ほとんどの AKS アプリケーションは、ストレージ、セキュリティ、またはネットワークに他のサービスを使用します。 これらのサービスのゾーンの回復性に関する推奨事項を確認してください。
費用
AKS で可用性ゾーンのサポートを有効にするための追加料金は発生しません。 可用性ゾーンにデプロイした仮想マシン (VM) とその他のリソースに対して支払います。
可用性ゾーンのサポートを設定する
- 可用性ゾーンがサポートされている新しい AKS クラスターを作成します 。可用性ゾーンのサポートを構成するには、可用性ゾーン を使用する Azure Kubernetes Service (AKS) クラスターの作成に関するページを参照してください。
- 移動: クラスターの作成後に可用性ゾーンのサポートを有効にすることはできません。 代わりに、可用性ゾーンのサポートが有効になっている新しいクラスターを作成し、既存のクラスターを削除する必要があります。
- 可用性ゾーンのサポートを無効にします。 クラスターの作成後に可用性ゾーンのサポートを無効にすることはできません。 代わりに、可用性ゾーンのサポートが無効になっている新しいクラスターを作成し、既存のクラスターを削除する必要があります。
通常の運用
ゾーン間のトラフィック ルーティング: 可用性ゾーンを使用する AKS クラスターをデプロイする場合は、ネットワーク コンポーネントもゾーンの回復性を確保することが重要です。 使用するロード バランサーとその他のネットワーク コンポーネントによっては、正しいゾーン内の適切なノードにトラフィックをルーティングし、ゾーンの停止に対応するために、コンポーネントを明示的に構成することが必要になる場合があります。 詳細については、「 AKS のゾーンの回復性に関する考慮事項」を参照してください。
ゾーン間のデータ レプリケーション:ステートレス ワークロードを実行する場合は、Azure データベース、Azure Cache for Redis、AzureStorage などのマネージド Azure サービスを使用して、アプリケーション データを格納する必要があります。 これらのサービスを使用すると、データの損失やユーザー エクスペリエンスへの影響を危険にさらすことなく、ノードとゾーン間でトラフィックを確実に移動できます。 Kubernetes のデプロイメント、サービス、ヘルスプローブを使用すると、ステートレスポッドを管理し、ゾーン間で均等に分散させることができます。
Azure ディスクを使用してクラスター内に状態を格納する必要がある場合は、Azure ゾーン冗長ストレージを使用して、データが複数の可用性ゾーンにレプリケートされるようにします。 詳細については、「 アプリケーションのニーズに基づいて適切なディスクの種類を選択する」を参照してください。
ゾーンダウン エクスペリエンス
検出と応答: ゾーンの停止が発生すると、コントロール プレーンは自動的にフェールオーバーします。 ノード プールで可用性ゾーンを使用し、 ゾーンの回復性のベスト プラクティスに従っている場合は、AKS が運用可能なゾーン内のノードとレプリカを起動することを期待できます。 クラスター オートスケーラーや NAP などのマネージド ソリューションを使用すると、AKS によってこのタスクが自動的に実行されます。 自動スケールを使用しない場合、ノードとレプリカは 保留中 の状態のままになり、手動による介入によってノード プールがスケールアップされるのを待ちます。
また、AKS は、正常なゾーン間でポッドの再調整を試みます。 ゾーンダウンシナリオでノード プールを手動でスケーリングすることを選択した場合、正常なゾーンで使用可能なノードがない場合、ポッドは 保留中 の状態のままになることがあります。 残りのゾーンでのスケールアウトは、使用する VM SKU のクォータと容量の可用性にも影響します。
通知: AKS では、ゾーンがダウンしても通知されません。 ノードまたはポッドの正常性メトリックを使用して、ノードとポッドの正常性を監視できます。
アクティブな要求: アクティブな要求では中断が発生する可能性があります。 一部の要求は失敗する可能性があり、ワークロードが別のゾーンにフェールオーバーする間に待機時間が長くなる可能性があります。
予想されるデータ損失: Azure ディスクを使用してクラスター内に状態を格納し、ゾーン冗長ストレージを使用する場合、ゾーン障害によってデータが失われることは想定されません。
予想されるダウンタイム: クラスターとポッドのゾーンの回復性を正しく構成した場合、ゾーンの障害によって AKS ワークロードのダウンタイムが発生することは想定されません。
トラフィックの再ルーティング: ロード バランサーは、正常なノードで実行されるポッドに新しい受信要求を再ルーティングします。
詳細については、「 AKS のゾーンの回復性に関する考慮事項」を参照してください。
フェールバック
可用性ゾーンが復旧すると、フェールバックの動作はコンポーネントによって異なります。
コントロール プレーン: AKS は、すべての可用性ゾーンにわたってコントロール プレーン操作を自動的に復元します。 手動による介入は必要ありません。
ノード プールとノード: フェールバックの直後、ノードは以前は正常なゾーンに残り、復旧されたゾーンでは復元されません。 ただし、ノード プールをスケールアウトするときなど、次にノードスケーリング操作を実行すると、ノード プールは復旧されたゾーンにノードを作成できます。
ポッド: フェールバックの直後、ポッドは現在実行されているノードで引き続き実行されます。 新しいポッドが作成されるか、既存のポッドが再作成されると、復旧されたゾーン内のノードを使用する資格があります。
貯蔵: ポッドに接続されているストレージは、 ゾーン冗長ストレージのしくみに基づいて復旧されます。
ゾーン障害のテスト
次の方法を使用して、可用性ゾーンの障害に対する回復性をテストできます。
マルチリージョン サポート
AKS クラスターは、単一リージョンのリソースです。 リージョンが使用できない場合は、AKS クラスターも使用できません。
代替のマルチリージョン アプローチ
Kubernetes ワークロードを複数の Azure リージョンにデプロイする必要がある場合は、これらのクラスターのオーケストレーションを管理するための 2 つのオプションがあります。
よりシンプルで管理されたエクスペリエンスが必要な場合は、 Azure Kubernetes Fleet Manager を使用します。 Azure Kubernetes Fleet Manager を使用すると、次のことができます。
AKS クラスターのセットを 1 つのユニットとして管理します。これらのクラスターは複数の Azure リージョンに分散できます。
クラスターやノード イメージのアップグレードなど、クラスター管理の特定の側面を自動化します。
トラフィック分散機能を使用して、クラスター間でトラフィックを分散し、リージョンが使用できない場合は自動的にフェールオーバーします。
ワークロードで地域間フェールオーバーのさまざまなコンポーネントをより細かく制御する必要がある場合は、手動のアクティブ/アクティブ/アクティブ/パッシブ デプロイ モデルを使用してフェールオーバーを調整します。 詳細については、 AKS の HA と DR の概要に関するページを参照してください。
バックアップ
Azure Backup には、AKS クラスター リソースとクラスターに接続する永続ボリュームをバックアップするために使用できる拡張機能があります。 Backup コンテナーは、拡張機能を介して AKS クラスターと通信して、バックアップと復元の操作を実行します。
AKS クラスターが ペアになっているリージョンにある場合は、geo 冗長ストレージに格納されるようにバックアップを構成できます。 geo 冗長バックアップは、ペアになっているリージョンに復元できます。
詳細については、次の記事を参照してください。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「 冗長性、レプリケーション、バックアップ」を参照してください。
バックアップの必要性を最小限に抑えるステートレス クラスターの使用に努めます。 クラスター内ではなく、外部ストレージ システムとデータベースにデータを格納します。
サービスメンテナンス中の信頼性
AKS は、クラスターとノード イメージの更新を含め、クラスターに対してメンテナンスを実行します。 Kubernetes がアップグレード中でも運用トラフィックを処理するために必要なポッド インスタンスの最小数を維持するには、ポッド中断予算を使用するようにポッドを構成する必要があります。
重要な期間中のサービスの中断を減らすために、AKS では、計画メンテナンス時間を指定できるように制御が提供されます。 詳細については、「 計画メンテナンスを使用して Azure Kubernetes Service クラスターのアップグレードをスケジュールおよび制御する」を参照してください。
サービス水準合意書
AKS のサービス レベル アグリーメント (SLA) には、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。 詳細については、 オンライン サービスの SLA を参照してください。
AKS には、 クラスター管理用の 3 つの価格レベル ( Free、 Standard、 Premium) が用意されています。 Free レベルを使用すると、AKS を使用してワークロードをテストできます。 Standard レベルと Premium レベルは、運用環境のワークロード向けに設計されています。 可用性ゾーンが有効になっている AKS クラスターをデプロイすると、SLA で定義されているアップタイムの割合が増加します。 ただし、SLA は、Standard または Premium 価格レベルでクラスターをデプロイする場合にのみ適用されます。