高可用性 Kubernetes クラスターを Azure Stack Hub で構築する

この記事では、Azure Stack Hub 上で Azure Kubernetes Service (AKS) エンジンを使用して、可用性の高い Kubernetes ベースのインフラストラクチャを設計、運用する方法について説明します。 このソリューションは、厳密な一連の制約があるシナリオに基づいています。 アプリケーションはオンプレミスで実行する必要があり、すべての個人データがパブリック クラウド サービスに届かないようにする必要があります。 監視とその他の非 PII データを Azure に送信し、そこで処理することができます。 パブリック コンテナー レジストリなどの外部サービスにはアクセスできますが、ファイアウォールまたはプロキシ サーバーを通じてフィルター処理される場合があります。

Helm と Let's Encrypt は、各社の商標です。 これらのマークを使用することが、保証を意味するものではありません。

アーキテクチャ

"この記事のすべての図の Visio ファイルをダウンロードします。"

ワークフロー

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

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

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

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

Components

• Azure Stack Hub は Azure の拡張機能であり、データセンター内で Azure サービスを提供することによりオンプレミス環境でワークロードを実行できます。
• Azure Stack のAKS Engineには、Azure Stack Hub でセルフマネージド Kubernetes クラスターをプロビジョニングするのに役立つコマンドライン ツールが用意されています。 Azure Resource Manager を使用して、Azure Stack Hub 内の基本的な IaaS リソースを使用してプロビジョニングされたクラスターを作成、破棄、管理します。
• Virtual Network は、Kubernetes クラスター インフラストラクチャをホストする仮想マシン (VM) 用に、各 Azure Stack Hub インスタンス上にネットワーク インフラストラクチャを提供します。
• Azure Load Balancer は、Kubernetes API エンドポイントと Nginx イングレス コントローラーに使用されます。 ロード バランサーは、特定のサービスを提供するノードと VM に外部 (インターネットなどの) トラフィックをルーティングします。
• Container Registry は、クラスターにデプロイされるプライベート Docker イメージと Helm chart を格納するために使用されます。 AKS エンジンは、Microsoft Entra ID を使用してコンテナー レジストリに対して認証できます。 Kubernetes に Container Registry は必要ありません。 Docker Hub などの他のコンテナー レジストリを使用できます。
• Azure Repos は、コードの管理に使用できるバージョン管理ツールのセットです。 GitHub やその他の Git ベースのリポジトリを使用することもできます。
• Azure Pipelines は、Azure DevOps Services の一部です。 これは、自動化されたビルド、テスト、デプロイを実行します。 Jenkins などのサードパーティ CI/CD ソリューションも使用できます。
• Azure Monitor では、ソリューション内の Azure サービスのプラットフォーム メトリックやアプリケーション テレメトリなど、メトリックとログが収集されて格納されます。 このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。 Azure Monitor は、コントローラー、ノード、コンテナー、コンテナー ログ、コントロール プレーン ノード ログからメトリックを収集するために Kubernetes と統合されます。
• Azure Traffic Manager は、異なる Azure リージョンまたは Azure Stack Hub デプロイにまたがってトラフィックをサービスに最適に配分するために使用できる、DNS ベースのトラフィック ロード バランサーです。 Traffic Manager により、高可用性と応答性も提供されます。 Azure Traffic Manager にエンドポイントとして追加するには、アプリケーション エンドポイントに外部からアクセスできることが必須です。
• Kubernetes イングレス コントローラーにより、Kubernetes クラスター内のサービスへの HTTP(S) ルートが公開されます。 NGINX または任意の適切なイングレス コントローラーを使用できます。
• Helm は、Kubernetes デプロイ用のパッケージ マネージャーです。 これは、Deployments、Services、Secrets などのさまざまな Kubernetes オブジェクトを 1 つの "chart" にバンドルする方法を提供します。chart オブジェクトの発行、デプロイ、バージョン管理、更新を行うことができます。 パッケージ化された Helm chart を格納するためのリポジトリとして Container Registry を使用できます。

代替

Azure Traffic Manager は、2 つのインターネットに到達可能なエンドポイント間でトラフィックを分散するための選択肢の 1 つです。 他の負荷分散ソリューションを使用して、Azure Stack Hub インスタンス間でトラフィックを分散することもできます。 Azure Stack Hub でホストされているアプリケーション エンドポイントをプライベート ネットワーク内のみに制限する必要があるシナリオがある場合があります。 サードパーティの Load Balancer は、同じデータセンターに併置されているか、複数のデータセンターにデプロイされているかに関係なく、ネットワーク内の Azure Stack Hub インスタンス間でトラフィックを負荷分散するために、そのようなシナリオで使用される場合があります。

シナリオの詳細

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

考えられるユース ケース

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

• 場所の機密度。
• アプリケーションとオンプレミス システムの間の待機時間。
• 帯域幅の節約。
• 接続あり。
• 規制または法定要件。

Azure を Azure Stack Hub と組み合わせると、これらの問題のほとんどに対処できます。 この記事では、Azure Stack Hub で可用性の高い Kubernetes を適切に設計するのに役立つ幅広いオプション、決定事項、考慮事項について説明します。

ここで説明するシナリオは、非常に制限の厳しい規制された環境において重要なワークロードを使用する組織では一般的です。 これは、財務、防衛、政府などのドメインに適用されます。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

デザイン

このソリューションでは、この記事の以降のセクションで詳しく説明されている、いくつかの高レベルの推奨事項が組み込まれています。

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

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

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

スケーラビリティは、一貫性があり信頼性とパフォーマンスの高いアプリケーションへのアクセスを提供するのに役立ちます。

サンプル シナリオでは、アプリケーション スタックの 3 つレイヤーでスケーラビリティを実装します。 レイヤーの概要を以下に示します。

アーキテクチャ レベル	影響	方法はありますか。
Application	Application	ポッド、レプリカ、コンテナー インスタンスの数に基づく水平スケーリング。*
クラスター	Kubernetes クラスター	ノードの数 (1 から 50 の間)、VM SKU のサイズ、AKS エンジンの手動 scale コマンドを使用、ノード プール。
インフラストラクチャ	Azure Stack Hub	Azure Stack Hub デプロイ内のノード数、容量、スケール ユニット数。

* "Kubernetes の HorizontalPodAutoscaler を使用。これは、コンテナー インスタンス (CPU やメモリ) のサイズ設定による、自動化されたメトリックベースのスケーリングまたは垂直スケーリングを提供します。"

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

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

• Azure Stack Hub のためのキャパシティ プランニングの概要
• Azure Stack Hub にスケール ユニット ノードを追加する

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

Kubernetes クラスター自体は、コンピューティング、ストレージ、ネットワーク リソースなどの Azure と Azure Stack Hub IaaS のコンポーネントで構成され、それらの上に構築されています。 Kubernetes ソリューションは、コントロール プレーン ノードとワーカー ノードで構成され、Azure と Azure Stack Hub に VM としてデプロイされます。

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

最初のデプロイ用の VM サイズを選択するときは、次の事を考慮してください。

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

• スケーラビリティ。 クラスターのスケーラビリティを実現するには、コントロール プレーンとワーカー ノードの数をスケールインおよびスケールアウトするか、ノード プールを追加します。 (現在、Azure Stack Hub にノード プールを追加することはできません)。コンテナーの分析情報 (Azure Monitor と Log Analytics) を使用して収集されたパフォーマンス データに基づいてクラスターをスケーリングできます。

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

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

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

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

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

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

別の方法として、コンテナー インスタンスを垂直方向にスケーリングすることもできます。 この種のスケーリングを実現するには、特定のデプロイで要求され使用可能な CPU とメモリの量を変更します。 詳細については、「コンテナーのリソースの管理」を参照してください。

ネットワークと接続性

ネットワークと接続性は、前に説明した 3 つのレイヤーにも影響します。 次の表に、レイヤーとそれらに含まれるサービスを示します。

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

Application

アプリケーション レイヤーでは、最も重要な考慮事項は、アプリケーションをインターネットに公開するかどうかと、インターネットからアクセス可能であるかどうかです。 Kubernetes の観点から見ると、インターネット アクセスには、Kubernetes サービスまたはイングレス コントローラーを使用してデプロイまたはポッドを公開する必要があります。

アプリケーションは、インターネットからアクセス可能にすることなく、ロード バランサーまたはイングレス コントローラーを介してパブリック IP で公開できます。 Azure Stack Hub には、ローカル イントラネットからのみ見えるパブリック IP アドレスを設定できます。 すべてのパブリック IP が実際にインターネットに接続されるわけではありません。

アプリケーションへのイングレス トラフィックに加えて、送信 (エグレス) トラフィックも考慮する必要があります。 エグレス トラフィックを必要とするいくつかのユース ケースを次に示します。

• Docker Hub または Container Registry に納されているコンテナー イメージのプル
• Helm chart の取得
• Application Insights データまたはその他の監視データの出力
• 外部アプリケーションへの接続

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

最後に、クラスター間のトラフィックが、Azure Stack Hub インスタンス間を流れる必要があります。 ここで説明しているソリューションは、個々の Azure Stack Hub インスタンスで実行される個々の Kubernetes クラスターで構成されます。 2 つのデータベース間のレプリケーション トラフィックなど、これらの間のトラフィックは、外部トラフィックと見なされます。 外部トラフィックは、サイト間 VPN または Azure Stack Hub のパブリック IP アドレスを介してルーティングされる必要があります。 サイト間 VPN では、データ転送のセキュリティが強化されることから、推奨されています。

クラスター

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

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

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

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

インフラストラクチャ

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

データとストレージ

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

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

ほとんどの場合、AKS にデプロイされた回復力のある高可用性アプリケーションにはストレージのレプリケーションは必要ありません。 ただし、アプリケーションの設計では、Azure Stack Hub インスタンスごとに個別のストレージを考慮する必要があります。 この設計に懸念がある場合は、Microsoft パートナーにより提供されるストレージ添付ソリューションを検討してください。 ストレージの添付により、複数の Azure Stack Hub インスタンスと Azure をまたがるストレージ レプリケーション ソリューションが実現します。 詳細については、この記事の「パートナー ソリューション」セクションを参照してください。

このアーキテクチャでは、次の要素が考慮されます。

構成

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

Application

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

Data

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

複数の場所にまたがるデータを操作する場合、可用性と回復性の高いソリューションの実装はさらに複雑になります。 以下を検討してください。

• Azure Stack Hub インスタンス間の待機時間とネットワーク接続。
• サービスとアクセス許可のための ID の可用性。 各 Azure Stack Hub インスタンスは、外部ディレクトリと統合されます。 デプロイ時に、Microsoft Entra ID または Active Directory フェデレーション サービス (AD FS) のどちらを使用するかを選択します。 そのため、複数の独立した 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 の運用の具体的な詳細については、次のリソースを参照してください。

• Infrastructure Backup サービスを使用した 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 Pipelines のようなデプロイ パイプラインを使用してアプリケーションのデプロイを自動化してください。

Azure Stack Hub のオファーとクォータの詳細については、「Azure Stack Hub サービス、プラン、オファー、サブスクリプションの概要」を参照してください。

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

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

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

アプリケーション データ

アプリケーション データは BCDR の重要なコンポーネントです。 前のセクションでは、アプリケーションの 2 つ以上のインスタンス間でデータをレプリケートおよび同期する方法について説明しています。 データの格納に使用されるデータベース インフラストラクチャ (MySQL、MongoDB、SQL Server など) に応じて、さまざまなデータベースの可用性とバックアップの手法を使用できます。

整合性を実現するために、次のいずれかのソリューションを使用することをお勧めします。

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

可用性

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

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

運用環境の Kubernetes クラスターに加えて、ワークロードを 2 つ以上のクラスターにデプロイすることをお勧めします。 これらのクラスターを別の場所またはデータセンターにホストして、Traffic Manager などのテクノロジを使用して、クラスターの応答時間または地理に基づいてユーザーをルーティングしてください。

1 つだけの Kubernetes クラスターを持つお客様は、通常、特定のアプリケーションのサービス IP または DNS 名に接続します。 複数クラスターのデプロイでは、各 Kubernetes クラスター上のサービスとイングレスを指す、Traffic Manager DNS 名に接続するようにしましょう。

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

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

ソリューションが独立した Azure Stack Hub インスタンスにまたがる場合、セキュリティと ID は特に重要です。 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 では、ID プロバイダーに 2 つの選択肢が用意されています。 使用するプロバイダーは、環境と、接続されている、または切断されている環境のどちらで実行するかによって決まります。

• Microsoft Entra ID は接続された環境でのみ使用できます。
• AD FS から従来の Active Directory フォレストは、接続されている、または切断されている環境で使用できます。

ID プロバイダーにより、ユーザーとグループが管理されます。これには、リソースにアクセスするための認証と認可が含まれます。 サブスクリプション、リソース グループ、VM やロード バランサーなどの個々のリソースなどの Azure Stack Hub リソースへのアクセスを許可することができます。 一貫性を保つには、すべての Azure Stack Hub インスタンスに対して、直接または入れ子になった同じグループを使用することを検討してください。 構成の例には、 などがあります。

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

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

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 上で実行)

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

パッチとアップグレード

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

AKS エンジンを介して Azure Stack Hub 上にデプロイされた Kubernetes クラスターのパッチとアップグレードのプロセスは管理されていません。 これはクラスター オペレーターの責任です。

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

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

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

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

デプロイ (CI/CD)

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

上記の微妙な違いを除けば、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 ホステッド エージェントを使用できます。 このデプロイにより、次のようなアプリケーション アーキテクチャになります。

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

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

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

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

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

前述のように、Azure とは異なり、Azure Stack Hub には現在、複数のインスタンス間でストレージをレプリケートするためのネイティブ ソリューションがありません。 Azure Stack Hub では、各インスタンスは独自の個別クラウドです。 ただし、Azure Stack Hub と Azure 間でのストレージ レプリケーションを可能にする Microsoft パートナーのソリューションを利用できます。

• Scality は、Web スケールのストレージを提供します。 Scality RING のソフトウェアによるストレージは、商用 x86 サーバーを、ペタバイト規模のあらゆる種類のデータ用の無制限のストレージ プールに変換します。
• Cloudian は、巨大なデータ セットを 1 つの環境に統合する無制限のスケーラブル ストレージを提供します。

次のステップ

• Azure Stack Hub の概要
• Azure Repos の概要
• Azure Pipelines の概要
• Azure Monitor の概要
• Azure Stack Hub でのクラウド間スケーリング
• Azure Stack Hub の地理的に分散されたアプリ パターン
• トレーニング: Azure Stack Hub

関連リソース

• Azure Kubernetes Service (AKS) 上のマイクロサービス アーキテクチャ
• 高可用性 Kubernetes クラスターのデプロイ ガイド