高可用性 Kubernetes クラスター パターン

この記事では、Azure Stack Hub 上の Azure Kubernetes Service (AKS) エンジンを使用して、高可用性 Kubernetes ベースのインフラストラクチャを設計および運用する方法について説明します。 このシナリオは、厳しく制限された規制された環境で重要なワークロードを持つ組織で一般的です。 財務、防衛、政府などのドメイン内の組織。

コンテキストと問題

多くの組織では、Kubernetes などの最先端のサービスとテクノロジを活用するクラウドネイティブ ソリューションを開発しています。 Azure は世界のほとんどのリージョンにデータセンターを提供していますが、ビジネス クリティカルなアプリケーションを特定の場所で実行する必要があるエッジ ユース ケースやシナリオが存在する場合があります。 考慮事項は次のとおりです。

• 場所の敏感性
• アプリケーションとオンプレミス システム間の待機時間
• 帯域幅の節約
• 接続
• 規制または法令要件

Azure は、Azure Stack Hub と組み合わせて、これらの問題のほとんどに対処します。 Azure Stack Hub で実行されている Kubernetes の正常な実装に関する幅広いオプション、決定事項、および考慮事項を以下に示します。

ソリューション

このパターンでは、厳密な制約セットに対処する必要があることを前提としています。 アプリケーションはオンプレミスで実行する必要があり、すべての個人データがパブリック クラウド サービスに到達してはなりません。 監視やその他の PII 以外のデータを Azure に送信し、そこで処理できます。 パブリック Container Registry などの外部サービスにはアクセスできますが、ファイアウォールまたはプロキシ サーバーを介してフィルター処理される場合があります。

ここで示すサンプル アプリケーションは、可能な限り Kubernetes ネイティブ ソリューションを使用するように設計されています。 この設計により、プラットフォームネイティブ サービスを使用する代わりに、ベンダーのロックインを回避できます。 たとえば、アプリケーションでは、PaaS サービスまたは外部データベース サービスではなく、セルフホステッド MongoDB データベース バックエンドが使用されます。 詳細については、「Azure での Kubernetes の概要」ラーニング パスを参照してください。

上の図は、Azure Stack Hub 上の Kubernetes で実行されているサンプル アプリケーションのアプリケーション アーキテクチャを示しています。 アプリは、次のようないくつかのコンポーネントで構成されています。

1. Azure Stack Hub 上の AKS エンジン ベースの Kubernetes クラスター。
2. cert-manager。これは、Let's Encrypt から証明書を自動的に要求するために使用される、Kubernetes の証明書管理用の一連のツールを提供します。
3. フロントエンド (ratings-web)、API (ratings-api)、およびデータベース (ratings-mongodb) のアプリケーション コンポーネントを含む Kubernetes 名前空間。
4. HTTP/HTTPS トラフィックを Kubernetes クラスター内のエンドポイントにルーティングするイングレス コントローラー。

サンプル アプリケーションは、アプリケーション アーキテクチャを示すために使用されます。 すべてのコンポーネントが例です。 アーキテクチャに含まれるアプリケーションのデプロイは 1 つだけです。 高可用性 (HA) を実現するために、2 つの異なる Azure Stack Hub インスタンスで少なくとも 2 回デプロイを実行します。これらは、同じ場所または 2 つ以上の異なるサイトで実行できます。

Azure Container Registry、Azure Monitor などのサービスは、Azure またはオンプレミスの Azure Stack Hub の外部でホストされます。 このハイブリッド設計により、1 つの Azure Stack Hub インスタンスの停止からソリューションが保護されます。

コンポーネント

全体的なアーキテクチャは、次のコンポーネントで構成されています。

Azure Stack Hub は、データセンターで Azure サービスを提供することで、オンプレミス環境でワークロードを実行できる Azure の拡張機能です。 詳細については、Azure Stack Hub の概要 に関するページを参照してください。

Azure Kubernetes Service Engine (AKS エンジン) は、現在 Azure で利用できるマネージド Kubernetes サービス オファリング Azure Kubernetes Service (AKS) の背後にあるエンジンです。 Azure Stack Hub の場合、AKS エンジンを使用すると、Azure Stack Hub の IaaS 機能を使用して、フル機能のセルフマネージド Kubernetes クラスターをデプロイ、スケーリング、アップグレードできます。 詳細については、「AKS エンジンの概要」を参照してください。

Azure 上の AKS エンジンと Azure Stack Hub 上の AKS エンジンの違いの詳細については、 既知の問題と制限事項に関するページを参照してください。

Azure Virtual Network (VNet) は、Kubernetes クラスター インフラストラクチャをホストする仮想マシン (VM) 用の各 Azure Stack Hub 上のネットワーク インフラストラクチャを提供するために使用されます。

Azure Load Balancer は、Kubernetes API エンドポイントと Nginx イングレス コントローラーに使用されます。 ロード バランサーは、外部 (インターネットなど) トラフィックを、特定のサービスを提供するノードと VM にルーティングします。

Azure Container Registry (ACR) は、クラスターにデプロイされるプライベート Docker イメージと Helm チャートを格納するために使用されます。 AKS エンジンは、Microsoft Entra ID を使用してコンテナー レジストリで認証できます。 Kubernetes には ACR は必要ありません。 Docker Hub などの他のコンテナー レジストリを使用できます。

Azure Repos は、コードの管理に使用できる一連のバージョン管理ツールです。 GitHub やその他の Git ベースのリポジトリを使用することもできます。 詳細については、Azure Repos の概要 参照してください。

Azure Pipelines は Azure DevOps Services の一部であり、自動ビルド、テスト、デプロイを実行します。 Jenkins などのサードパーティの CI/CD ソリューションを使用することもできます。 詳細については、Azure Pipeline Overview をご覧ください。

Azure Monitor では、ソリューション内の Azure サービスのプラットフォーム メトリックやアプリケーション テレメトリなどのメトリックとログが収集および格納されます。 このデータを使用して、アプリケーションを監視し、アラートとダッシュボードを設定し、障害の根本原因分析を実行します。 Azure Monitor は Kubernetes と統合され、コントローラー、ノード、コンテナー、およびコンテナー ログとマスター ノード ログからメトリックを収集します。 詳細については、Azure Monitor の概要 参照してください。

Azure Traffic Manager は DNS ベースのトラフィック ロード バランサーであり、さまざまな Azure リージョンまたは Azure Stack Hub デプロイ間でサービスにトラフィックを最適に分散できます。 Traffic Manager では、高可用性と応答性も提供されます。 アプリケーション エンドポイントには、外部からアクセスできる必要があります。 他のオンプレミス ソリューションも利用できます。

Kubernetes イングレス コントローラー は、Kubernetes クラスター内のサービスに HTTP(S) ルートを公開します。 この目的には、Nginx または任意の適切なイングレス コントローラーを使用できます。

Helm は Kubernetes デプロイのパッケージ マネージャーであり、デプロイ、サービス、シークレットなどのさまざまな Kubernetes オブジェクトを 1 つの "グラフ" にバンドルする方法を提供します。 グラフ オブジェクトの発行、展開、バージョン管理の制御、および更新を行うことができます。 Azure Container Registry は、パッケージ化された Helm Chart を格納するためのリポジトリとして使用できます。

設計に関する考慮事項

このパターンは、この記事の次のセクションで詳しく説明されているいくつかの大まかな考慮事項に従います。

• アプリケーションは、ベンダーのロックインを回避するために、Kubernetes ネイティブ ソリューションを使用します。
• アプリケーションはマイクロサービス アーキテクチャを使用します。
• Azure Stack Hub は受信を必要としませんが、送信インターネット接続を許可します。

これらの推奨プラクティスは、実際のワークロードとシナリオにも適用されます。

スケーラビリティに関する考慮事項

スケーラビリティは、アプリケーションへの一貫性のある信頼性とパフォーマンスの高いアクセスをユーザーに提供するために重要です。

サンプル シナリオでは、アプリケーション スタックの複数のレイヤーでのスケーラビリティについて説明します。 さまざまなレイヤーの概要を次に示します。

アーキテクチャ レベル	影響	どう。
アプリケーション	アプリケーション	ポッド/レプリカ/コンテナー インスタンスの数に基づく水平方向のスケーリング*
クラスター	Kubernetes クラスター	ノードの数 (1 から 50 の間)、VM SKU サイズ、およびノード プール (Azure Stack Hub 上の AKS エンジンは現在、1 つのノード プールのみをサポートしています)。AKS エンジンのスケール コマンドを使用する (手動)
インフラ	Azure Stack Hub	Azure Stack Hub デプロイ内のノード、容量、スケール ユニットの数

* Kubernetes の水平ポッド オートスケーラー (HPA) の使用。コンテナー インスタンス (cpu/memory) のサイズ変更によるメトリック ベースの自動スケーリングまたは垂直スケーリング。

Azure Stack Hub (インフラストラクチャ レベル)

Azure Stack Hub はデータセンター内の物理ハードウェア上で実行されるため、Azure Stack Hub インフラストラクチャがこの実装の基盤となります。 ハブ ハードウェアを選択するときは、CPU、メモリ密度、ストレージ構成、およびサーバーの数を選択する必要があります。 Azure Stack Hub のスケーラビリティの詳細については、次のリソースを確認してください。

• Azure Stack Hub の 容量計画の概要
• Azure Stack Hub にスケール ユニット ノードを追加する

Kubernetes クラスター (クラスター レベル)

Kubernetes クラスター自体は、コンピューティング、ストレージ、ネットワーク リソースを含む Azure (Stack) IaaS コンポーネントで構成され、その上に構築されています。 Kubernetes ソリューションには、Azure (および Azure Stack Hub) に VM としてデプロイされるマスター ノードとワーカー ノードが含まれます。

• コントロール プレーン ノード (マスター) は、コア Kubernetes サービスとアプリケーション ワークロードのオーケストレーションを提供します。
• ワーカー ノード (worker) は、アプリケーション ワークロードを実行します。

初期デプロイの VM サイズを選択する場合、いくつかの考慮事項があります。

• コスト - ワーカー ノードを計画するときは、発生する VM あたりの全体的なコストに留意してください。 たとえば、アプリケーションワークロードで限られたリソースが必要な場合は、より小さなサイズの VM をデプロイすることを計画する必要があります。 Azure と同様、Azure Stack Hub は通常、使用量ベースで課金されるため、Kubernetes ロール用の VM の適切なサイズ設定は、消費コストを最適化するために不可欠です。

• スケーラビリティ - クラスターのスケーラビリティは、マスター ノードとワーカー ノードの数をスケールインおよびスケールアウトするか、ノード プールを追加することによって実現されます (現時点では Azure Stack Hub では使用できません)。 クラスターのスケーリングは、Container Insights (Azure Monitor + Log Analytics) を使用して収集されたパフォーマンス データに基づいて行うことができます。

  アプリケーションで必要なリソースの数が多い (または少ない) 場合は、現在のノードを水平方向 (1 ~ 50 ノード) にスケールアウト (またはスケールイン) できます。 50 を超えるノードが必要な場合は、別のサブスクリプションに追加のクラスターを作成できます。 クラスターを再デプロイしないと、実際の VM を別の VM サイズに垂直方向にスケールアップすることはできません。

  スケーリングは、最初に Kubernetes クラスターのデプロイに使用された AKS エンジン ヘルパー VM を使用して手動で行われます。 詳細については、「Kubernetes クラスターのスケーリング 」の項を参照してください。

• クォータ - Azure Stack Hub での AKS デプロイを計画するときに、設定した クォータ を考慮します。 各 サブスクリプション に適切なプランとクォータが構成されていることを確認します。 サブスクリプションは、クラスターがスケールアウトする際に必要なコンピューティング、ストレージ、その他のサービスの量に対応する必要があります。

• アプリケーション ワークロード - Azure Kubernetes Service の Kubernetes のコア概念に関するドキュメントで クラスターとワークロードの概念を参照してください。 この記事は、アプリケーションのコンピューティングとメモリのニーズに基づいて適切な VM サイズのスコープを設定するのに役立ちます。

アプリケーション (アプリケーション レベル)

アプリケーション 層では、Kubernetes Horizontal Pod Autoscaler (HPA)を使用します。 HPA は、さまざまなメトリック (CPU 使用率など) に基づいて、デプロイ内のレプリカ (ポッド/コンテナー インスタンス) の数を増減できます。

もう 1 つのオプションは、コンテナー インスタンスを垂直方向にスケーリングすることです。 これを実現するには、要求された CPU とメモリの量を変更し、特定のデプロイで使用できます。 詳細については、kubernetes.io の コンテナーのリソースの管理に関する を参照してください。

ネットワークと接続に関する考慮事項

ネットワークと接続は、Azure Stack Hub 上の Kubernetes で前述した 3 つのレイヤーにも影響します。 次の表に、レイヤーとそのレイヤーに含まれるサービスを示します。

レイヤー	影響	何？
アプリケーション	アプリケーション	アプリケーションはどのようにしてアクセスできますか? インターネットに公開されますか?
クラスター	Kubernetes クラスター	Kubernetes API、AKS エンジン VM、コンテナー イメージのプル (エグレス)、監視データとテレメトリの送信 (エグレス)
インフラ	Azure Stack Hub	ポータルや Azure Resource Manager エンドポイントなどの Azure Stack Hub 管理エンドポイントのアクセシビリティ。

アプリケーション

アプリケーション 層の最も重要な考慮事項は、アプリケーションが公開され、インターネットからアクセスできるかどうかです。 Kubernetes の観点から見ると、インターネット アクセシビリティとは、Kubernetes Service またはイングレス コントローラーを使用してデプロイまたはポッドを公開することを意味します。

ロード バランサーまたはイングレス コントローラーを介してパブリック IP を使用してアプリケーションを公開しても、アプリケーションがインターネット経由でアクセスできるようになったことを意味するわけではありません。 Azure Stack Hub では、ローカル イントラネットでのみ表示されるパブリック IP アドレスを持つことができます。すべてのパブリック IP が本当にインターネットに接続されているわけではありません。

前のブロックでは、アプリケーションへのイングレス トラフィックが考慮されます。 Kubernetes のデプロイを成功させるために考慮する必要があるもう 1 つのトピックは、送信/エグレス トラフィックです。 エグレス トラフィックを必要とするユース ケースをいくつか次に示します。

• DockerHub または Azure Container Registry に格納されているコンテナー イメージの取得
• Helm チャートの取得
• Application Insights データ (またはその他の監視データ) の出力

一部のエンタープライズ環境では、透過的な 使用するか、非透過的な プロキシ サーバー 使用する必要がある場合があります。 これらのサーバーは、クラスターのさまざまなコンポーネントで特定の構成を必要とします。 AKS エンジンのドキュメントには、ネットワーク プロキシに対応する方法に関するさまざまな詳細が含まれています。 詳細については、「AKS エンジンとプロキシ サーバーの」を参照してください。

最後に、クラスター間トラフィックは Azure Stack Hub インスタンス間で流れる必要があります。 サンプル デプロイは、個々の Azure Stack Hub インスタンスで実行されている個々の Kubernetes クラスターで構成されます。 2 つのデータベース間のレプリケーション トラフィックなど、それらの間のトラフィックは "外部トラフィック" です。 2 つの Azure Stack Hub インスタンスで Kubernetes を接続するには、外部トラフィックをサイト間 VPN または Azure Stack Hub パブリック IP アドレスを介してルーティングする必要があります。

クラスター

Kubernetes クラスターは、必ずしもインターネット経由でアクセスできる必要はありません。 関連する部分は、クラスターの運用に使用される Kubernetes API です。たとえば、kubectlを使用します。 Kubernetes API エンドポイントには、クラスターを運用するか、その上にアプリケーションとサービスをデプロイするすべてのユーザーがアクセスできる必要があります。 このトピックでは、後述の「Deployment (CI/CD) に関する考慮事項」 DevOps の観点から詳しく説明します。

クラスター レベルでは、エグレス トラフィックに関するいくつかの考慮事項もあります。

• ノードの更新 (Ubuntu の場合)
• 監視データ (Azure LogAnalytics に送信)
• 送信トラフィックを必要とするその他のエージェント (各デプロイ担当者の環境に固有)

AKS エンジンを使用して Kubernetes クラスターをデプロイする前に、最終的なネットワーク設計を計画します。 専用の仮想ネットワークを作成する代わりに、既存のネットワークにクラスターをデプロイする方が効率的な場合があります。 たとえば、Azure Stack Hub 環境で既に構成されている既存のサイト間 VPN 接続を利用できます。

インフラストラクチャ

インフラストラクチャとは、Azure Stack Hub 管理エンドポイントへのアクセスを指します。 エンドポイントには、テナントと管理ポータル、および Azure Resource Manager の管理者エンドポイントとテナント エンドポイントが含まれます。 これらのエンドポイントは、Azure Stack Hub とそのコア サービスを運用するために必要です。

データとストレージに関する考慮事項

アプリケーションの 2 つのインスタンスが、2 つの Azure Stack Hub インスタンスにまたがって、2 つの個々の Kubernetes クラスターにデプロイされます。 この設計では、それらの間でデータをレプリケートして同期する方法を検討する必要があります。

Azure には、クラウド内の複数のリージョンとゾーンにストレージをレプリケートする機能が組み込まれています。 現在、Azure Stack Hub では、2 つの異なる Azure Stack Hub インスタンス間でストレージをレプリケートするネイティブな方法はありません。2 つの独立したクラウドを形成し、それらをセットとして管理する包括的な方法はありません。 Azure Stack Hub 全体で実行されているアプリケーションの回復性を計画すると、アプリケーションの設計とデプロイにおけるこの独立性を考慮する必要があります。

ほとんどの場合、AKS にデプロイされた回復性と可用性の高いアプリケーションでは、ストレージ レプリケーションは必要ありません。 ただし、アプリケーション設計では、Azure Stack Hub インスタンスごとに独立したストレージを検討する必要があります。 この設計が、Azure Stack Hub にソリューションをデプロイするための懸念事項または道のりである場合は、ストレージの添付ファイルを提供する Microsoft パートナーのソリューションが考えられます。 ストレージの添付ファイルは、複数の Azure Stack Hubs と Azure にまたがるストレージ レプリケーション ソリューションを提供します。 詳細については、パートナー ソリューションのを参照してください。

このアーキテクチャでは、次のレイヤーが考慮されました。

構成

構成には、Azure Stack Hub、AKS エンジン、および Kubernetes クラスター自体の構成が含まれます。 構成は可能な限り自動化し、コードとしてのインフラストラクチャとして Azure DevOps や GitHub などの Git ベースのバージョン管理システムに格納する必要があります。 これらの設定は、複数のデプロイ間で簡単に同期することはできません。 そのため、外部から構成を格納して適用し、DevOps パイプラインを使用することをお勧めします。

アプリケーション

アプリケーションは Git ベースのリポジトリに格納する必要があります。 新しいデプロイ、アプリケーションの変更、ディザスター リカバリーが発生するたびに、Azure Pipelines を使用して簡単にデプロイできます。

データ

データは、ほとんどのアプリケーション設計で最も重要な考慮事項です。 アプリケーション データは、アプリケーションの異なるインスタンス間で同期されている必要があります。 障害が発生した場合、データにはバックアップとディザスター リカバリーの戦略も必要です。

この設計の実現は、テクノロジの選択に大きく依存します。 Azure Stack Hub で高可用性の方法でデータベースを実装するためのソリューションの例を次に示します。

• Azure と Azure Stack Hub に SQL Server 2016 可用性グループをデプロイする
• 高可用性 MongoDB ソリューションを Azure および Azure Stack Hub にデプロイする

複数の場所でデータを操作する場合の考慮事項は、高可用性と回復性の高いソリューションに対するさらに複雑な考慮事項です。 考えてみてください

• Azure Stack Hubs 間の待機時間とネットワーク接続。
• サービスとアクセス許可の ID の可用性。 各 Azure Stack Hub インスタンスは、外部ディレクトリと統合されます。 展開時に、Microsoft Entra ID または Microsoft Entra ID フェデレーションのいずれかを使用することを選択します。 そのため、複数の独立した Azure Stack Hub インスタンスと対話できる 1 つの ID を使用する可能性があります。

ビジネス継続性とディザスター リカバリー

ビジネス継続性とディザスター リカバリー (BCDR) は、Azure Stack Hub と Azure の両方で重要なトピックです。 主な違いは、Azure Stack Hub では、オペレーターが BCDR プロセス全体を管理する必要があるということです。 Azure では、BCDR の一部は Microsoft によって自動的に管理されます。

BCDR は、前のセクションで説明したのと同じ領域に影響 データとストレージに関する考慮事項。

• インフラストラクチャ/構成
• アプリケーションの可用性
• アプリケーション データ

また、前のセクションで説明したように、これらの領域は Azure Stack Hub オペレーターの責任であり、組織によって異なる場合があります。 使用できるツールとプロセスに従って BCDR を計画します。

インフラストラクチャと構成

このセクションでは、物理インフラストラクチャと論理インフラストラクチャと Azure Stack Hub の構成について説明します。 管理者とテナントスペースのアクションについて説明します。

Azure Stack Hub のオペレーター (または管理者) は、Azure Stack Hub インスタンスのメンテナンスを担当します。 ネットワーク、ストレージ、ID、この記事の範囲外のその他のトピックなどのコンポーネントを含めます。 Azure Stack Hub 操作の詳細については、次のリソースを参照してください。

• インフラストラクチャ バックアップ サービスを使用して Azure Stack Hub のデータを復旧
• 管理者ポータルから Azure Stack Hub のバックアップを有効にする
• 致命的なデータ損失からの復旧
• インフラストラクチャ バックアップ サービスのベスト プラクティス

Azure Stack Hub は、Kubernetes アプリケーションをデプロイするプラットフォームとファブリックです。 Kubernetes アプリケーションのアプリケーション所有者は Azure Stack Hub のユーザーになり、ソリューションに必要なアプリケーション インフラストラクチャをデプロイするためのアクセス権が付与されます。 この場合のアプリケーション インフラストラクチャは、AKS エンジンと周囲のサービスを使用してデプロイされた Kubernetes クラスターを意味します。 これらのコンポーネントは Azure Stack Hub にデプロイされ、Azure Stack Hub オファーによって制約されます。 Kubernetes アプリケーション所有者が受け入れるオファーに、ソリューション全体をデプロイするための十分な容量 (Azure Stack Hub クォータで表されます) があることを確認します。 前のセクションで推奨されているように、アプリケーションのデプロイは、コードとしてのインフラストラクチャと Azure DevOps Azure Pipelines などのデプロイ パイプラインを使用して自動化する必要があります。

Azure Stack Hub のオファーとクォータの詳細については、Azure Stack Hub のサービス、プラン、オファー、サブスクリプションの概要

出力を含め、AKS エンジン構成を安全に保存して格納することが重要です。 これらのファイルには、Kubernetes クラスターへのアクセスに使用される機密情報が含まれているため、管理者以外に公開されないように保護する必要があります。

アプリケーションの可用性

アプリケーションは、デプロイされたインスタンスのバックアップに依存しないようにする必要があります。 標準のプラクティスとして、コードとしてのインフラストラクチャ パターンに完全に従ってアプリケーションを再デプロイします。 たとえば、Azure DevOps Azure Pipelines を使用して再デプロイします。 BCDR プロシージャには、アプリケーションを同じまたは別の Kubernetes クラスターに再デプロイする必要があります。

アプリケーション データ

アプリケーション データは、データ損失を最小限に抑えるための重要な部分です。 前のセクションでは、アプリケーションの 2 つ以上のインスタンス間でデータをレプリケートおよび同期する手法について説明しました。 データの格納に使用されるデータベース インフラストラクチャ (MySQL、MongoDB、MSSQL など) に応じて、選択できるデータベースの可用性とバックアップ手法が異なります。

整合性を実現するために推奨される方法は、次のいずれかを使用することです。

• 特定のデータベースのネイティブ バックアップ ソリューション。
• アプリケーションで使用されるデータベースの種類のバックアップと回復を正式にサポートするバックアップ ソリューション。

重要

アプリケーション データが存在するのと同じ Azure Stack Hub インスタンスにバックアップ データを格納しないでください。 Azure Stack Hub インスタンスが完全に停止すると、バックアップも侵害されます。

可用性に関する考慮事項

AKS エンジン経由でデプロイされた Azure Stack Hub 上の Kubernetes は、マネージド サービスではありません。 これは、Azure サービスとしてのインフラストラクチャ (IaaS) を使用した Kubernetes クラスターの自動デプロイと構成です。 そのため、基になるインフラストラクチャと同じ可用性が提供されます。

Azure Stack Hub インフラストラクチャは既に障害に対する回復性があり、可用性セットなどの機能を提供して、複数の 障害ドメインと更新ドメインにコンポーネントを分散します。 ただし、基になるテクノロジ (フェールオーバー クラスタリング) では、ハードウェア障害が発生した場合でも、影響を受けた物理サーバー上の VM に対していくつかのダウンタイムが発生します。

運用環境の Kubernetes クラスターとワークロードを 2 つ (またはそれ以上) のクラスターにデプロイすることをお勧めします。 これらのクラスターは、異なる場所またはデータセンターでホストし、Azure Traffic Manager などのテクノロジを使用して、クラスターの応答時間または地理的な場所に基づいてユーザーをルーティングする必要があります。

1 つの Kubernetes クラスターを持つお客様は、通常、特定のアプリケーションのサービス IP または DNS 名に接続します。 マルチクラスターデプロイでは、各 Kubernetes クラスターのサービス/イングレスを指す Traffic Manager DNS 名に接続する必要があります。

にルーティングする

手記

このパターンは、Azure の (マネージド) AKS クラスターのベスト プラクティスでもあります。

AKS エンジンを介してデプロイされた Kubernetes クラスター自体は、少なくとも 3 つのマスター ノードと 2 つのワーカー ノードで構成されている必要があります。

ID とセキュリティに関する考慮事項

ID とセキュリティは重要なトピックです。 特に、ソリューションが独立した Azure Stack Hub インスタンスにまたがる場合。 Kubernetes と Azure (Azure Stack Hub を含む) の両方に、ロールベースのアクセス制御 (RBAC) の個別のメカニズムがあります。

• Azure RBAC は、新しい Azure リソースを作成する機能を含め、Azure (および Azure Stack Hub) 内のリソースへのアクセスを制御します。 アクセス許可は、ユーザー、グループ、またはサービス プリンシパルに割り当てることができます。 (サービス プリンシパルは、アプリケーションで使用されるセキュリティ ID です)。
• Kubernetes RBAC は、Kubernetes API へのアクセス許可を制御します。 たとえば、ポッドの作成とポッドの一覧表示は、RBAC を介してユーザーに対して承認 (または拒否) できるアクションです。 Kubernetes のアクセス許可をユーザーに割り当てるには、ロールとロール バインドを作成します。

Azure Stack Hub の ID と RBAC

Azure Stack Hub には、2 つの ID プロバイダーの選択肢があります。 使用するプロバイダーは、環境と、接続されている環境または切断された環境で実行されているかどうかによって異なります。

• Microsoft Entra ID - 接続された環境でのみ使用できます。
• 従来の Active Directory フォレストへの Microsoft Entra ID フェデレーション - 接続環境と切断環境の両方で使用できます。

ID プロバイダーは、リソースにアクセスするための認証と承認など、ユーザーとグループを管理します。 サブスクリプション、リソース グループ、VM やロード バランサーなどの個々のリソースなどの Azure Stack Hub リソースへのアクセスを許可できます。 一貫性のあるアクセス モデルを使用するには、すべての Azure Stack Hub に同じグループ (直接または入れ子) を使用することを検討する必要があります。 構成例を次に示します。

この例には、特定の目的のための専用グループが含まれています。 たとえば、特定の Azure Stack Hub インスタンス上の Kubernetes クラスター インフラストラクチャを含むリソース グループに共同作成者のアクセス許可を付与するには (こちら"Seattle K8s Cluster Contributor")。 これらのグループは、各 Azure Stack Hub の "サブグループ" を含む全体グループに入れ子になっています。

これで、サンプル ユーザーは、Kubernetes インフラストラクチャ リソースのセット全体を含む両方のリソース グループに対する "共同作成者" アクセス許可を持つようになります。 インスタンスは同じ ID プロバイダーを共有するため、ユーザーは両方の Azure Stack Hub インスタンス上のリソースにアクセスできます。

重要

これらのアクセス許可は、Azure Stack Hub とその上にデプロイされたリソースの一部にのみ影響します。 このレベルのアクセス権を持つユーザーは多くの害を及ぼす可能性がありますが、Kubernetes デプロイに追加でアクセスしないと、Kubernetes IaaS VM や Kubernetes API にアクセスすることはできません。

Kubernetes ID と RBAC

Kubernetes クラスターでは、既定では、アンダーレイの Azure Stack Hub と同じ ID プロバイダーは使用されません。 Kubernetes クラスター、マスター ノード、ワーカー ノードをホストしている VM は、クラスターのデプロイ時に指定された SSH キーを使用します。 SSH を使用してこれらのノードに接続するには、この SSH キーが必要です。

Kubernetes API (たとえば、kubectlを使用してアクセス) は、既定の "クラスター管理者" サービス アカウントを含むサービス アカウントによっても保護されます。 このサービス アカウントの資格情報は、最初は Kubernetes マスター ノードの .kube/config ファイルに格納されます。

シークレット管理とアプリケーション資格情報

接続文字列やデータベース資格情報などのシークレットを格納するには、次のようないくつかの選択肢があります。

• Azure Key Vault
• Kubernetes シークレット
• HashiCorp Vault (Kubernetes 上で実行) などのサード パーティ製ソリューション

シークレットまたは資格情報は、構成ファイル、アプリケーション コード、またはスクリプト内のプレーンテキストに格納しないでください。 また、バージョン 管理システムには格納しないでください。 代わりに、デプロイの自動化では、必要に応じてシークレットを取得する必要があります。

修正プログラムと更新プログラム

Azure Kubernetes Service の Patch and Update (PNU) プロセスは部分的に自動化されています。 Kubernetes バージョンのアップグレードは手動でトリガーされますが、セキュリティ更新プログラムは自動的に適用されます。 これらの更新プログラムには、OS のセキュリティ修正プログラムやカーネルの更新プログラムを含めることができます。 AKS では、更新プロセスを完了するためにこれらの Linux ノードが自動的に再起動されることはありません。

Azure Stack Hub 上の AKS エンジンを使用してデプロイされた Kubernetes クラスターの PNU プロセスは管理されておらず、クラスター オペレーターの責任です。

AKS エンジンは、次の 2 つの最も重要なタスクに役立ちます。

• 新しい Kubernetes とベース OS イメージ バージョンへのアップグレード
• 基本 OS イメージのみをアップグレード

新しい基本 OS イメージには、最新の OS セキュリティ修正プログラムとカーネル更新プログラムが含まれています。

無人アップグレード メカニズムでは、Azure Stack Hub Marketplace で新しい基本 OS イメージ バージョンを使用できるようになる前にリリースされたセキュリティ更新プログラムが自動的にインストールされます。 自動アップグレードは既定で有効になっており、セキュリティ更新プログラムは自動的にインストールされますが、Kubernetes クラスター ノードは再起動されません。 ノードの再起動は、オープン ソース Kubernetes REブート Daemon (kured))を使用して自動化できます。 Kured は、再起動が必要な Linux ノードを監視し、実行中のポッドとノードの再起動プロセスのスケジュール変更を自動的に処理します。

デプロイ (CI/CD) に関する考慮事項

Azure と Azure Stack Hub では、同じ Azure Resource Manager REST API が公開されます。 これらの API は、他の Azure クラウド (Azure、Azure China 21Vianet、Azure Government) と同様に対処されます。 クラウド間の API バージョンには違いがある可能性があり、Azure Stack Hub ではサービスのサブセットのみが提供されます。 管理エンドポイント URI は、クラウドごと、および Azure Stack Hub のインスタンスごとにも異なります。

前述の微妙な違いを除いて、Azure Resource Manager REST API は、Azure と Azure Stack Hub の両方と対話するための一貫した方法を提供します。 ここでは、他の Azure クラウドと同じツール セットを使用できます。 Azure DevOps、Jenkins などのツール、または PowerShell を使用して、Azure Stack Hub にサービスをデプロイおよび調整できます。

考慮事項

Azure Stack Hub のデプロイに関する主な違いの 1 つは、インターネット アクセシビリティの問題です。 インターネット アクセシビリティにより、CI/CD ジョブ用に Microsoft がホストするビルド エージェントとセルフホステッド ビルド エージェントのどちらを選択するかが決まります。

セルフホステッド エージェントは、Azure Stack Hub の上 (IaaS VM として) または Azure Stack Hub にアクセスできるネットワーク サブネットで実行できます。 相違点の詳細については、「Azure Pipelines エージェント」をご覧ください。

次の図は、セルフホステッド ビルド エージェントまたは Microsoft ホスト型ビルド エージェントが必要かどうかを判断するのに役立ちます。

セルフホステッド ビルド エージェントについて、はいまたはいいえを選択してください

• Azure Stack Hub 管理エンドポイントはインターネット経由でアクセスできますか?
  • はい: Microsoft がホストするエージェントと共に Azure Pipelines を使用して、Azure Stack Hub に接続できます。
  • いいえ: Azure Stack Hub の管理エンドポイントに接続できるセルフホステッド エージェントが必要です。
• Kubernetes クラスターはインターネット経由でアクセスできますか?
  • はい: Microsoft がホストするエージェントで Azure Pipelines を使用して、Kubernetes API エンドポイントと直接対話できます。
  • いいえ: Kubernetes クラスター API エンドポイントに接続できるセルフホステッド エージェントが必要です。

Azure Stack Hub 管理エンドポイントと Kubernetes API にインターネット経由でアクセスできるシナリオでは、デプロイで Microsoft がホストするエージェントを使用できます。 このデプロイにより、アプリケーション アーキテクチャは次のようになります。

Azure Resource Manager エンドポイント、Kubernetes API、またはその両方がインターネット経由で直接アクセスできない場合は、セルフホステッド ビルド エージェントを利用してパイプラインステップを実行できます。 この設計では、必要な接続が少なくなり、Azure Resource Manager エンドポイントと Kubernetes API へのオンプレミスネットワーク接続のみでデプロイできます。

手記

接続が切れた場合はどうなりますか。 Azure Stack Hub または Kubernetes、またはその両方にインターネットに接続する管理エンドポイントがないシナリオでは、デプロイに Azure DevOps を引き続き使用できます。 セルフホステッド エージェント プール (オンプレミスまたは Azure Stack Hub 自体で実行されている DevOps エージェント) または完全にセルフホステッド Azure DevOps Server オンプレミスを使用できます。 セルフホステッド エージェントには、送信 HTTPS (TCP/443) インターネット接続のみが必要です。

このパターンでは、各 Azure Stack Hub インスタンスで Kubernetes クラスター (AKS エンジンでデプロイおよび調整) を使用できます。 これには、フロントエンド、中間層、バックエンド サービス (MongoDB など)、および nginx ベースのイングレス コントローラーで構成されるアプリケーションが含まれます。 K8s クラスターでホストされているデータベースを使用する代わりに、"外部データ ストア" を利用できます。 データベース オプションには、MySQL、SQL Server、または Azure Stack Hub の外部または IaaS でホストされている任意の種類のデータベースが含まれます。 このような構成は、ここではスコープ内にありません。

パートナー ソリューション

Azure Stack Hub の機能を拡張できる Microsoft パートナー ソリューションがあります。 これらのソリューションは、Kubernetes クラスターで実行されているアプリケーションのデプロイに役立ちます。

ストレージとデータのソリューション

データとストレージに関する考慮事項で説明されているように、Azure Stack Hub には現在、複数のインスタンス間でストレージをレプリケートするためのネイティブ ソリューションはありません。 Azure とは異なり、複数のリージョン間でストレージをレプリケートする機能は存在しません。 Azure Stack Hub では、各インスタンスは独自の個別のクラウドです。 ただし、Azure Stack Hubs と Azure 間のストレージ レプリケーションを有効にするソリューションは、Microsoft パートナーから入手できます。

スカリティ

Scality は、2009 年からデジタル ビジネスを強化してきた Web スケールのストレージを提供します。 ソフトウェアで定義されたストレージである Scality RING は、ペタバイト規模で、あらゆる種類のデータ (ファイルとオブジェクト) に対応する無制限の記憶域プールにコモディティ x86 サーバーを変換します。

CLOUDIAN

Cloudian は、大規模なデータ セットを単一の簡単に管理できる環境に統合する、無制限のスケーラブルなストレージを使用してエンタープライズ ストレージを簡素化します。

次の手順

この記事で紹介する概念の詳細については、以下を参照してください。

• Azure Stack Hub における クラウド間スケーリングと geo 分散アプリ パターン。
• Azure Kubernetes Service (AKS) のマイクロサービス アーキテクチャ。

ソリューションの例をテストする準備ができたら、高可用性 Kubernetes クラスターデプロイ ガイドに進みます。 デプロイ ガイドでは、コンポーネントをデプロイしてテストするための詳細な手順を説明します。