Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ

この記事では、Azure Kubernetes Service (AKS) クラスターをデプロイするための推奨されるベースライン インフラストラクチャ アーキテクチャについて説明します。 これは当社の設計原則を採用しており、 Azure Well-Architected Framework の AKS アーキテクチャのベスト プラクティス に基づいています。 この記事は、ネットワーク、セキュリティ、ID チームなどの複数の異なる学際的なグループがこの汎用インフラストラクチャを展開する際に役立ちます。

このアーキテクチャは、ワークロードに重点を置いていません。 AKS クラスター自体に重点を置きます。 この情報は、ほとんどの AKS クラスターに推奨される最小ベースラインです。 これは、監視を可能にし、複数リージョンの成長をサポートするネットワーク トポロジを提供し、クラスター内トラフィックを保護する Azure サービスと統合されます。

ビジネス要件はターゲット アーキテクチャに影響を及ぼし、アプリケーション コンテキストによって異なる場合があります。 アーキテクチャを、プリプロダクション段階とプロダクション段階の出発点として検討してください。

Kubernetes は、Azure と Microsoft テクノロジを超えて拡張される強力なエコシステムです。 AKS クラスターをデプロイする場合、クラスターの設計と運用方法に関する多数の決定に責任を負います。 AKS クラスターの実行には、Microsoft やKubernetes エコシステムのオープンソース コンポーネントを含むさまざまなベンダーのクローズドソース コンポーネントが混在しています。 ランドスケープは頻繁に変化するため、定期的に決定事項を見直す必要がある場合があります。 Kubernetes を採用することで、ワークロードにはその機能が必要であり、ワークロード チームは継続的に投資する準備ができていることを認識しています。

このアーキテクチャの実装は、 GitHub: AKS ベースライン リファレンス実装で使用できます。 これを代替の出発点として使用し、ニーズに応じてリファレンス アーキテクチャを構成します。

ネットワーク構成

ネットワーク トポロジ
IP アドレスの計画
イングレス リソースのデプロイ

クラスター コンピューティング

ベース クラスターのコンピューティング
コンテナー イメージのリファレンス
ポリシー管理

ID 管理

クラスターの Microsoft Entra ID を統合する
ワークロードの Microsoft Entra ID を統合する

データ フローのセキュリティ保護

ネットワーク フローのセキュリティ保護
シークレット管理の追加

ビジネス継続性

スケーラビリティ
クラスターとノードの可用性
可用性と複数リージョンのサポート

操作

クラスターおよびワークロードの CI/CD パイプライン
クラスターの正常性とメトリック
コスト管理とレポート

ネットワーク トポロジ

このアーキテクチャでは、ハブ アンド スポーク ネットワーク トポロジが使用されます。 仮想ネットワーク ピアリング を介して接続された個別の仮想ネットワークにハブとスポークを展開します。 このトポロジにはいくつかの利点があります。 このトポロジは次の目的で使用します。

• 分離管理を有効にします。 ガバナンスを適用し、最小権限の原則を遵守できます。 また、職務の分離を伴う Azure ランディング ゾーン の概念もサポートします。

• Azure リソースがパブリック インターネットに直接公開されるのを最小限に抑えます。

• 地域ハブ アンド スポーク トポロジを提供します。 将来的にはハブ アンド スポーク ネットワーク トポロジを拡張し、ワークロードの分離を実現できます。

• Web Application Firewall サービスを使用して、すべての Web アプリケーションの HTTP トラフィック フローを検査します。

• 複数のサブスクリプションにまたがるワークロードのサポートを提供します。

• アーキテクチャを拡張可能にします。 新しい機能やワークロードに対応するために、ネットワーク トポロジを再設計する代わりに、新しいスポークを追加できます。

• ファイアウォールやドメイン ネーム システム (DNS) ゾーンなどのリソースをネットワーク間で共有することをサポートします。

• Azure エンタープライズ規模のランディング ゾーンに合わせます。

このアーキテクチャの Visio ファイル をダウンロードします。

詳細については、「Azure のハブスポーク ネットワーク トポロジ」を参照してください。

AKS 上の Windows コンテナーのベースライン参照アーキテクチャに含まれるネットワーク設計の変更の詳細については、「AKS 上の Windows コンテナー」を参照してください。

ハブ仮想ネットワーク

ハブ仮想ネットワークは、接続性と監視の中心点です。 このアーキテクチャでは、ハブには次のものが含まれます。

• 組織全体のファイアウォール ポリシーを適用するために中央 IT チームによって定義されたグローバル ファイアウォール ポリシーを備えた Azure Firewall。
• 仮想マシン (VM) へのリモート アクセス用の Azure Bastion。
• VPN 接続用のゲートウェイ サブネット。
• ネットワーク監視のための Azure Monitor。

ネットワーク内では、アーキテクチャには 3 つのサブネットがあります。

Azure Firewall をホストするサブネット

Azure Firewall はマネージド ファイアウォール サービスです。 Azure Firewall インスタンスは、送信ネットワーク トラフィックを保護します。 このセキュリティ レイヤーがないと、トラフィックが悪意のある非 Microsoft サービスと通信し、機密性の高いワークロード データが流出する可能性があります。 Azure Firewall Manager を使用して、複数の Azure Firewall インスタンスを一元的にデプロイおよび構成し、この ハブ仮想ネットワーク アーキテクチャ タイプの Azure ファイアウォール ポリシーを管理します。

ゲートウェイをホストするサブネット

このサブネットは、VPN ゲートウェイまたは Azure ExpressRoute ゲートウェイのプレースホルダーです。 ゲートウェイでは、オンプレミスのネットワーク内のルーターと仮想ネットワークの間の接続が提供されます。

Azure Bastion をホストするサブネット

このサブネットは Azure Bastion のプレースホルダーです。 Azure Bastion を使用すると、リソースをインターネットに公開することなく、Azure リソースに安全にアクセスできます。 このサブネットは管理と操作専用です。

スポーク仮想ネットワーク

スポーク仮想ネットワークには、AKS クラスターとその他の関連リソースが含まれます。 スポークには次のサブネットがあります。

Azure Application Gateway をホストするサブネット

Application Gateway は、レイヤー 7 で動作する Web トラフィック Load Balancerです。 リファレンス実装では、 Azure Web Application Firewallを有効にする Application Gateway v2 SKU を使用します。 Web Application Firewall は、ボットを含む一般的な Web トラフィック攻撃から受信トラフィックを保護します。 インスタンスには、ユーザー リクエストを受信するパブリック フロントエンド IP 構成があります。 仕様として、Application Gateway には、専用のサブネットが必要です。

イングレス リソースをホストするサブネット

トラフィックをルーティングおよび分散するために、 Traefik は Kubernetes イグレス リソースを実行するイグレス コントローラーです。 このサブネットには、Azure 内部ロード バランサーが存在します。 詳細については、「AKS で内部ロード バランサーを使用する」を参照してください。

クラスター ノードをホストするサブネット

AKS は、別々のノード グループである 2 つのノード プールを維持します。 "システム ノード プール" では、コア クラスター サービスを実行するポッドをホストします。 "ユーザー ノード プール" では、ワークロードとイングレス コントローラーが実行され、ワークロードへのインバウンド通信が有効になります。

Azure プライベート リンク エンドポイントをホストするサブネット

Azure Container Registry と Azure Key Vault のプライベート リンク接続を作成し、ユーザーがスポーク仮想ネットワーク内の プライベート エンドポイント 経由でこれらのサービスにアクセスできるようにします。 プライベート エンドポイントには専用のサブネットは必要ありません。 ハブ仮想ネットワークにプライベート エンドポイントを配置することもできます。 ベースライン実装では、エンドポイントはスポーク仮想ネットワーク内の専用サブネットに展開されます。 このアプローチにより、ピアリングされたネットワーク接続を通過するトラフィックが削減されます。 クラスターに属するリソースを同じ仮想ネットワーク内に保持します。 ネットワーク セキュリティ グループを使用して、サブネット レベルできめ細かいセキュリティ ルールを適用することもできます。

詳細については、「Private Link 配置オプション」を参照してください。

IP アドレスの計画

このアーキテクチャの Visio ファイル をダウンロードします。

この参照アーキテクチャでは、それぞれに IP アドレス空間が必要な複数のネットワーク アプローチを使用します。

• クラスター ノード、プライベート エンドポイント、Application Gateway などのリソースに使用される Azure 仮想ネットワーク。
• クラスターでは、Azure CNI オーバーレイを使用します。このオーバーレイは、別のアドレス空間から Azure 仮想ネットワークそして、ポッドに IP アドレスを割り当てます。

仮想ネットワーク IP のアドレス空間

Azure 仮想ネットワークのアドレス空間は、サブネットを保持するのに十分な大きさにする必要があります。 トラフィックを受信するすべてのエンティティを考慮します。 Kubernetes は、サブネット アドレス空間からこれらのエンティティに IP アドレスを割り当てます。 Azure 仮想ネットワークの IP アドレスを計画するときは、これらの点を考慮してください。

• アップグレード: AKS は定期的にノードを更新し、基盤となる VM のセキュリティ機能やその他のシステム パッチが最新であることを確認します。 アップグレード処理中、ポッドを一時的にホストするノードが AKS によって作成され、その一方でアップグレード ノードが切断およびドレインされます。 その一時ノードには、クラスター サブネットから IP アドレスが割り当てられます。 これらの一時ノードの IP アドレスに十分なアドレス空間があることを確認してください。

  このアーキテクチャでは、ポッドには、ローリング更新中を含め、Azure CNI オーバーレイ ポッドのアドレス空間内から IP アドレスが割り当てられます。 この方法では、他の Kubernetes ネットワーク アプローチと比較して、Azure 仮想ネットワークから使用される IP アドレスの全体的な数が減少します。

• スケーラビリティ: すべてのシステム ノードおよびユーザー ノードのノード数と、それらの最大スケーラビリティの制限について検討します。 400% のスケールアウトが必要な場合を考えてみましょう。 スケールアウトされたすべてのノードには、4 倍の数のアドレスが必要になります。

  このアーキテクチャでは Azure CNI オーバーレイが使用されるため、ポッドのスケーラビリティは仮想ネットワークのアドレス空間に影響しません。

• プライベート リンク: プライベート リンク経由で他の Azure サービスとの通信に必要なアドレスを考慮に入れます。 このアーキテクチャには、Container Registry と Key Vault へのリンクに割り当てられた 2 つのアドレスがあります。

• 予約済み IP アドレス: Azureは、その用途のために特定のアドレスを予約します。 それらを割り当てることはできません。

上記の一覧は完全ではありません。 設計に使用可能な IP アドレスの数に影響する他のリソースがある場合は、それらのアドレスに対応します。

このアーキテクチャは、単一のワークロード用に設計されています。 運用 AKS クラスターでは、システム ノード プールをユーザー ノード プールから常に分離します。 クラスターで複数のワークロードを実行しているときは、ユーザー ノード プールを互いに分離することができます。 そうすると、サイズが小さいサブネットが増えます。 また、イングレス リソースはより複雑になることがあり、その結果、追加の IP アドレスを必要とする複数のイングレス コントローラーが必要になる場合があります。

ポッド IP アドレス空間

Azure CNI オーバーレイは、仮想ネットワークで使用するアドレス空間とは別の専用アドレス空間を使用して、ポッドに IP アドレスを割り当てます。 仮想ネットワークまたはピアリングされた仮想ネットワークと重複しない IP アドレス空間を使用します。 ただし、複数の AKS クラスターを作成する場合は、各クラスターで同じポッド アドレス空間を安全に使用できます。

各ノードにはポッドの /24 アドレス空間が割り当てられるため、クラスター内のノードの数に必要な数の /24 ブロックを許可するには、ポッドのアドレス空間が十分なサイズであることを確認します。 アップグレードまたはスケールアウト操作中に作成された一時ノードは必ず含めます。 たとえば、CIDR 範囲に /16 アドレス空間を使用する場合、クラスターは最大約 250 ノードまで拡張できます。

各ノードは最大 250 個のポッドをサポートしており、この制限にはアップグレード中に一時的に作成されるすべてのポッドが含まれます。

詳細については、「Azure CNI オーバーレイの IP アドレス計画に関するガイダンス」を参照してください。

その他の IP アドレス空間に関する考慮事項

このアーキテクチャのすべてのネットワークの考慮事項については、「AKS ベースライン ネットワーク トポロジ」を参照してください。 AKS クラスターの IP アドレスの計画の詳細については、「クラスターの IP アドレス指定を計画する」を参照してください。

AKS 上の Windows コンテナーのベースライン参照アーキテクチャに含まれる IP アドレス計画の考慮事項の詳細については、「AKS 上の Windows コンテナー」を参照してください。

アドオンとプレビュー機能

Kubernetes と AKS は継続的に進化しており、オンプレミス環境向けのソフトウェアよりもリリース サイクルが速くなっています。 このベースライン アーキテクチャは、選択した AKS プレビュー機能と AKS アドオンに依存します。 両者の違いは次のとおりです。

• AKS チームは、プレビュー機能を 出荷済みで改善中 であると説明しています。これは、プレビュー機能の多くが、一般提供 (GA) フェーズに移行する前に数か月間だけその状態を維持するためです。

• AKS アドオンと拡張機能 は、サポートされている追加の機能を提供します。 AKS はインストール、構成、ライフサイクルを管理します。

このベースライン アーキテクチャには、プレビュー機能やアドオンがすべて含まれているわけではありません。 代わりに、汎用クラスターに大きな価値を追加するものだけが含まれます。 これらの機能がプレビューから外れると、このベースライン アーキテクチャもそれに応じて修正されます。 他にも、実稼働前のクラスターで評価したいプレビュー機能や AKS アドオンがいくつかあります。 これらの機能により、セキュリティ、管理性、その他の要件が向上します。 Microsoft 以外のアドオンの場合は、利用可能なバージョンを追跡し、クラスターの Kubernetes バージョンをアップグレードした後に更新プログラムをインストールするなど、インストールと保守を行う必要があります。

コンテナー イメージのリファレンス

ワークロードに加えて、クラスターには、イングレス コントローラーなどの他のイメージがいくつか含まれる場合があります。 これらのイメージの一部が、パブリック レジストリに存在することがあります。 イメージをクラスターにプルするときは、次の点を考慮してください。

• イメージをプルするにはクラスターを認証します。

• パブリック イメージを使用している場合は、サービス レベル目標 (SLO) に適合するパブリック イメージをコンテナー レジストリにインポートします。 そうしないと、イメージが予期しない可用性の問題にさらされる可能性があります。 必要なときに画像が利用できない場合、運用上の問題が発生する可能性があります。 パブリック レジストリの代わりに、Azure Container Registry などのプライベート コンテナー レジストリを使用する利点は次のとおりです。

  • イメージへの未承認のアクセスをブロックできます。
  • 公開されている依存関係はありません。
  • イメージ プル ログにアクセスして、アクティビティを監視し、接続の問題をトリアージできます。
  • 統合されたコンテナ スキャンとイメージ コンプライアンスを活用できます。

• 承認済みレジストリからイメージをプルします。 この制限は、Azure Policy によって適用できます。 このリファレンス実装では、クラスターはデプロイされる Container Registry インスタンスからのみイメージをプルします。

ベース クラスターのコンピューティングの構成

AKS では、各ノード プールはそれぞれ 1 つの仮想マシン スケール セットに対応付けられます。 ノードは各ノード プール内の VM です。 コストを最小限に抑えるには、より小さい VM サイズをシステム ノード プールに使用することを検討してください。 このリファレンス実装では、3 つの DS2_v2 ノードを持つシステム ノード プールをデプロイします。 そのサイズは、システム ポッドの予想される負荷を満たすのに十分です。 オペレーティング システム ディスクは 512 GB です。

ユーザー ノード プールについて、次にいくつかの考慮事項を示します。

• ノード上に設定したポッドの最大数をパックするには、より大きいノード サイズを選択します。 大規模なノードは、監視やログ記録など、すべてのノードで実行されるサービスのフットプリントを最小限に抑えます。

• 特定のワークロード要件がある場合は、適切な VM タイプを選択します。 たとえば、一部のワークロードにはメモリ最適化された製品が必要になる場合があり、他のワークロードには GPU アクセラレーションされた製品が必要になる場合があります。 詳細については、Azure の仮想マシンのサイズに関するページをご覧ください。

• 少なくとも 2 つのノードをデプロイします。 こうして、ワークロードは 2 つのレプリカを持つ高可用性パターンを持つことになります。 AKS を使用すると、クラスターを再作成することなく、ノード数を変更できます。

• 設計チームによって決定された要件に基づいて、ワークロードの実際のノード サイズを計画します。 ビジネス要件に基づいて、このアーキテクチャでは運用ワークロードに DS4_v2 を使用します。 コストを削減するには、サイズを最小レコメンデーションである DS3_v2 に下げることができます。

• クラスターの容量を計画するときは、ワークロードが各ノードの最大 80% を消費すると想定します。 残りの 20% は AKS サービス用に予約されています。

• 容量計画に基づいて、ノードあたりの最大ポッド数を設定します。 容量のベースラインを確立しようとしている場合は、値 30 から始めます。 ワークロードの要件、ノード サイズ、IP の制約に基づいてこの値を調整します。

オペレーティング システムを選択する

ほとんどの AKS クラスターでは、ノード プールのオペレーティング システムとして Linux が使用されます。 このリファレンス実装では、Azure 用にチューニングされた軽量で堅牢な Linux ディストリビューションである Azure Linux を使用します。 必要に応じて、または、Azure Linux で満たされない要件がある場合に Ubuntu などの別の Linux ディストリビューションを使用します。

AKS では、Windows Server オペレーティング システムを実行するノード プールもサポートされています。 Windows を実行するクラスターの一部の側面には、特別な要件があります。 Windows ノード プールのアーキテクチャの詳細については、「AKS で Windows コンテナを実行する」を参照してください。

テクノロジの組み合わせで構成されるワークロードがある場合は、異なるノード プールで異なるオペレーティング システムを使用できます。 ただし、ワークロードに異なるオペレーティング システムが必要ない場合は、すべてのワークロードのノード プールに 1 つのオペレーティング システムを使用することが推奨されます。

クラスターの Microsoft Entra ID を統合する

クラスターとの間のアクセスをセキュリティで保護することが重要です。 セキュリティの選択を行うときは、クラスターの観点から考えてください。

• "インサイドアウト アクセス"。 ネットワーク インフラストラクチャ、Container Registry、Key Vault などの Azure コンポーネントへの AKS アクセスを検討してください。 クラスターがアクセスを許可されるリソースのみを承認します。
• "アウトサイドイン アクセス"。 Kubernetes クラスターへの ID アクセスを提供します。 Kubernetes API サーバーおよび Azure Resource Manager へのアクセスが許可されている外部エンティティのみを承認します。

Azure への AKS アクセス

Microsoft Entra ID を使用して Azure への AKS アクセスを管理する方法は 2 つあります。1 つは "サービス プリンシパル" を使用する方法、もう 1 つは "Azure リソース用マネージド ID" を使用する方法です。

Azure への AKS アクセスを管理する 2 つの方法のうち、マネージド ID をお勧めします。 サービス プリンシパルを使用する場合は、手動またはプログラムによってシークレットを管理およびローテーションする必要があります。 マネージド ID を使用すると、Microsoft Entra ID によって認証が管理または実行され、シークレットのローテーションがタイムリーに処理されます。

クラスターが Microsoft Entra ID を通じて外部の Azure リソースと対話できるように、 マネージド ID を有効にして使用することをお勧めします。 Microsoft Entra ID 統合をすぐに使用しない場合でも、後で組み込むことができます。

デフォルトでは、クラスターによって使用される主要な ID は 2 つあります。 クラスター ID と kubelet IDです。 AKS コントロール プレーン コンポーネントは、 クラスター ID を使用して、イグレス Load Balancerや AKS 管理パブリック IP などのクラスター リソースを管理します。 kubelet アイデンティティ は Container Registry で認証します。 一部のアドオンでは、マネージド ID を使用した認証もサポートされています。

クラスターがコンテナー レジストリからイメージをプルする必要がある場合は、マネージド ID を使用する必要があります。 この操作を行うには、クラスターでレジストリの資格情報を取得する必要があります。 マネージド ID を使用しない場合は、その情報を Kubernetes シークレット オブジェクトの形式で保存し、 imagePullSecrets を使用してシークレットを取得することができます。 セキュリティ上の複雑さのため、このアプローチはお勧めしません。 秘密を事前に知っておく必要があるだけでなく、その秘密を DevOps パイプライン内に保存する必要もあります。 このアプローチを推奨しないもう 1 つの理由は、シークレットのローテーションを管理するための運用上のオーバーヘッドです。 代わりに、クラスターの kubelet マネージド ID への AcrPull アクセスをレジストリに許可します。 このアプローチは懸念に対処します。

このアーキテクチャでは、クラスターは Microsoft Entra ID によって保護された Azure リソースにアクセスし、マネージド ID をサポートする操作を実行します。 クラスターが実行する操作に応じて、Azure ロールベースのアクセス制御 (Azure RBAC) とアクセス許可をクラスターのマネージド ID に割り当てます。 クラスターは Microsoft Entra ID に対して自身を認証し、割り当てられたロールに基づいてアクセスが許可または拒否されます。 このリファレンス実装から、Azure 組み込みロールがクラスターに割り当てられている例をいくつか示します。

• ネットワーク貢献者の役割. スポーク仮想ネットワークを制御するクラスターの機能を管理します。 このロールの割り当てにより、AKS クラスターのシステム割り当て ID は、内部イグレス コントローラー サービスの専用サブネットで動作できるようになります。

• モニタリング メトリック パブリッシャー ロール. クラスターがメトリックを Azure Monitor に送信する機能を管理します。

• AcrPull ロール. 指定された Azure Container Registry インスタンスからイメージをプルするクラスターの機能を管理します。

クラスターへのアクセス

また Microsoft Entra の統合により、アウトサイドイン アクセスのセキュリティも簡素化されます。 たとえば、kubectl を使用するといいでしょう。 最初のステップとして、 az aks get-credentials コマンドを実行してクラスターの資格情報を取得できます。 Microsoft Entra ID は、クラスター資格情報を取得することが許可されている Azure ロールに対して ID を認証します。 詳細については、「利用可能なクラスター ロールのアクセス許可」を参照してください。

AKS は、Microsoft Entra ID を使用して Kubernetes アクセスを 2 つの方法でサポートします。 1 つ目は、ネイティブ Kubernetes RBAC システムと統合された ID プロバイダーとして Microsoft Entra ID を使用することです。 もう 1 つの方法では、ネイティブの Azure RBAC を使用してクラスター アクセスを制御します。 次のセクションでは、両方のアプローチについて詳しく説明します。

Kubernetes RBAC を Microsoft Entra ID に関連付ける

Kubernetes は以下を通じて RBAC をサポートします。

• クラスター全体の権限に対して Role または ClusterRole オブジェクトを使用して定義する権限のセット。

• アクションを実行する権限を持つユーザーとグループを割り当てるバインディング。 RoleBinding または ClusterRoleBinding オブジェクトを使用してバインディングを定義します。

Kubernetes には、cluster-admin、edit、view などの組み込みロールがいくつか用意されています。 これらのロールを Microsoft Entra ユーザーおよびグループにバインドし、エンタープライズ ディレクトリを使用してアクセスを管理します。 詳細については、 Microsoft Entra 統合での Kubernetes RBAC の使用に関するページを参照してください。

Microsoft Entra アクセス レビュー には、クラスターおよび名前空間アクセス用の Microsoft Entra グループを含めるようにしてください。

Kubernetes 認可に Azure RBAC を使用する

Kubernetes ネイティブ RBAC、 ClusterRoleBindings と RoleBindings を使用して統合 Microsoft Entra 認証による承認を行う代わりに、Azure RBAC と Azure ロールの割り当てを使用することをお勧めします。 このアプローチでは、クラスター上で認証チェックが強制されます。 これらのロールは、管理グループ、サブスクリプション、またはリソース グループのスコープで割り当てることもできます。 スコープ内のすべてのクラスターは、Kubernetes クラスター上のオブジェクトにアクセスする権限を持つユーザーに関する一貫したロール割り当てセットを継承します。

詳細については、「Kubernetes 承認のための Azure RBAC」を参照してください。

ローカル アカウント

AKS では、ネイティブの Kubernetes ユーザー認証がサポートされています。 この方法を使用してクラスターへのユーザー アクセスを提供することはお勧めしません。 この方法は証明書ベースであり、主要な ID プロバイダーの外部で実行されるため、集中的なユーザー アクセス制御とガバナンスが困難になります。 常に Microsoft Entra ID を使用してクラスターへのアクセスを管理し、ローカル アカウント アクセスを明示的に無効にするようにクラスターを構成します。

このリファレンス実装では、システムがクラスターを展開するときに、ローカル クラスター アカウント アクセスが明示的に無効になります。

ワークロードの Microsoft Entra ID を統合する

クラスター全体で Azure システム割り当てマネージド ID を使用する場合と同様に、マネージド ID をポッド レベルで割り当てることができます。 ワークロード ID により、ホストされたワークロードは Microsoft Entra ID を通じてリソースにアクセスできるようになります。 たとえば、ワークロードで Azure Storage にファイルを保存するとします。 これらのファイルにアクセスする必要がある場合、ポッドは Azure マネージド ID としてリソースに対して自身を認証します。

このリファレンス実装では、 AKS 上の Microsoft Entra Workload ID がポッドのマネージド ID を提供します。 このアプローチは、Kubernetes ネイティブ機能と統合され、外部 ID プロバイダーと連携します。 Microsoft Entra ワークロード ID フェデレーションについて詳しくは、「ワークロード ID フェデレーション」をご覧ください。

ネットワーク モデルを選択する

AKS は、kubenet、CNI、Azure CNI オーバーレイなどの複数のネットワーク モデルをサポートしています。 CNI モデルは、より高度なモデルであり、高パフォーマンスです。 ポッド間を通信する場合、CNI のパフォーマンスは、仮想ネットワークの VM のパフォーマンスと類似します。 CNI では、Azure ネットワーク ポリシーを使用できるため、セキュリティ制御も強化されます。 CNI ベースのネットワーク モデルをお勧めします。

非オーバーレイの CNI モデルでは、すべてのポッドがサブネットのアドレス空間から IP アドレスを取得します。 それらの IP アドレスを使用して、同じネットワーク内のリソース (またはピアリングされたリソース) からポッドに直接アクセスできます。 そのトラフィックをルーティングするためにネットワーク アドレス変換 (NAT) は必要ありません。

この参照実装では、ノードに対して、ノード プール サブネットから IP アドレスのみを割り当てる Azure CNI オーバーレイを使用し、ポッド IP に対しては、高度に最適化されたオーバーレイ レイヤーを使用します。 Azure CNI オーバーレイは、他の多くの方法よりも使用する仮想ネットワーク IP アドレスが少ないため、IP アドレスが制限されたデプロイに推奨されます。

モデルの詳細については、「使用する Container Networking Interface ネットワーク モデルの選択」および「kubenet と Azure Container Networking Interface ネットワーク モデルの比較」を参照してください。

イングレス リソースのデプロイ

Kubernetes イグレス リソースは、クラスターへの着信トラフィックのルーティングと配信を処理します。 イグレス リソースには 2 つの部分があります。

• AKS によって管理される内部Load Balancer。 ロード バランサは、プライベート静的 IP アドレスを通じてイグレス コントローラを公開します。 それは受信フローを受信する単一のコンタクト ポイントとして機能します。

  このアーキテクチャでは、Azure Load Balancer を使用します。 Load Balancer は、イグレス リソース専用のサブネット内のクラスター外部にあります。 Application Gateway からトラフィックを受信し、その通信はトランスポート層セキュリティ (TLS) を介して行われます。 受信トラフィックの TLS 暗号化の詳細については、 イグレス トラフィック フローを参照してください。

• 入力コントローラ。 この例では Traefik を使用します。 それはクラスター内のユーザー ノード プールで実行されます。 内部ロード バランサーからのトラフィックを受信し、TLS を終了して、HTTP 経由でワークロード ポッドに転送します。

イグレス コントローラーはクラスターの重要なコンポーネントです。 このコンポーネントを構成するときは、次の点を考慮してください。

• 設計上の決定の一環として、イグレス コントローラーを特定の操作範囲に制限します。 たとえば、コントローラーと特定のワークロードを実行するポッドとのやり取りのみを許可することができます。

• 負荷を分散し、ノードに障害が発生した場合でもビジネスの継続性を確保するために、同じノードにレプリカを配置することは避けてください。 この目的には podAntiAffinity を使用します。

• nodeSelectors を使用することによって、ポッドがユーザー ノード プールでのみスケジューリングされるように制限します。 この設定により、ワークロードとシステム ポッドが分離されます。

• 特定のエンティティがイグレス コントローラーにトラフィックを送信できるようにするポートとプロトコルを開きます。 このアーキテクチャでは、Traefik は Application Gateway からのトラフィックのみを受信します。

• 指定された間隔でポッドの健全性を監視する readinessProbe および livenessProbe 設定を構成します。 イグレス コントローラーは、ポッドの健全性を示す信号を送信する必要があります。

• イングレス コントローラーについて、特定のリソースへのアクセスと、特定のアクションを実行する機能を制限することを検討してください。 この制限は、Kubernetes RBAC 権限を通じて実装できます。 たとえば、このアーキテクチャでは、Kubernetes ClusterRole オブジェクトのルールを使用して、Traefik にサービスとエンドポイントを監視、取得、一覧表示する権限が付与されます。

ベースライン参照アーキテクチャにおける AKS 上の Windows コンテナーのイグレス設計の詳細については、「AKS 上の Windows コンテナー」を参照してください。

ルーター設定

イングレス コントローラーによって、ルートを使用してトラフィックの送信先が決定されます。 ルートによって、トラフィックを受信する送信元ポートと、宛先ポートとプロトコルに関する情報が指定されます。

このアーキテクチャからの例をこちらに示します。

Traefik では、Kubernetes プロバイダーを使用してルートが構成されます。 annotations、 tls、 entrypoints オプションは、ルートが HTTPS 経由で提供されることを示します。 middlewares オプションは、Application Gateway サブネットからのトラフィックのみが許可されることを指定します。 クライアントが受け入れた場合、応答には gzip エンコードが使用されます。 Traefik は TLS 終端を実行するため、バックエンド サービスとの通信は HTTP 経由で行われます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

ネットワーク フローのセキュリティ保護

このアーキテクチャでは、ネットワーク フローには以下が含まれます。

• クライアントからクラスター内で実行されるワークロードへのイグレス トラフィック。

• クラスター内のポッドまたはノードから外部サービスへの エグレス トラフィック。

• ポッド間のポッド間トラフィック。 このトラフィックには、イングレス コントローラーとワークロードとの間の通信が含まれます。 ワークロードがクラスターにデプロイされた複数のアプリケーションで構成されている場合、それらのアプリケーション間の通信もこのカテゴリに分類されます。

• クライアントと Kubernetes API サーバー間の 管理トラフィック。

このアーキテクチャの Visio ファイル をダウンロードします。

このアーキテクチャには、すべての種類のトラフィックをセキュリティで保護するための複数のセキュリティ層があります。

イングレス トラフィック フロー

このアーキテクチャでは、クライアントからの TLS で暗号化された要求のみが受け入れられます。 TLS v1.2 は、許可される最小バージョンであり、制限された暗号セットを使用しています。 Server Name Indication (SNI) の厳密なマッチングが有効になっています。 エンドツーエンド TLS は、次の図に示すように、2 つの異なる TLS 証明書を使用して Application Gateway を通じて設定されます。

このアーキテクチャの Visio ファイル をダウンロードします。

1. クライアントからドメイン名 (bicycle.contoso.com) に HTTPS 要求が送信されます。 その名前は、Application Gateway のパブリック IP アドレスの DNS A レコードに関連付けられています。 このトラフィックは暗号化されており、クライアント ブラウザーとゲートウェイ間のトラフィックが検査または変更されないようにします。

2. Application Gateway には統合された Web Application Firewall があり、 bicycle.contoso.comの TLS ハンドシェイクをネゴシエートして、安全な暗号のみを許可します。 Application Gateway は TLS 終端ポイントであり、Application Gateway の Web Application Firewall はプレーンテキスト応答を検査する必要があるため重要です。 Key Vault には TLS 証明書が保存されます。 クラスターは、Application Gateway と統合されたユーザー割り当てのマネージド ID を使用してこれにアクセスします。 詳細については、「Key Vault 証明書での SSL 終了」を参照してください。

   Application Gateway は、Web Application Firewall検査ルールを処理し、構成されたバックエンドにトラフィックを転送するルーティング ルールを実行します。

3. トラフィックが Application Gateway からバックエンドに移動すると、内部Load Balancerに転送されるときに、 *.aks-ingress.contoso.comのワイルドカードである別の TLS 証明書を使用して再度暗号化されます。 この再暗号化により、セキュリティ保護されていないトラフィックがクラスター サブネットに流入することがなくなります。

4. イングレス コントローラーでは、ロード バランサーを介して暗号化されたトラフィックを受信します。 コントローラーは、*.aks-ingress.contoso.com のもう 1 つの TLS 終端ポイントであり、HTTP 経由でワークロード ポッドにトラフィックを転送します。 証明書は Key Vault に保存され、Container Storage Interface (CSI) ドライバーによってクラスターにマウントされます。 詳細については、「シークレット管理の追加」を参照してください。

ワークロード ポッドを通過するすべてのホップでエンドツーエンドの TLS トラフィックを実装できます。 ポッド間トラフィックのセキュリティ保護を決定する際には、パフォーマンス、レイテンシ、運用上の影響を必ず測定してください。 ほとんどのシングルテナント クラスターでは、適切なコントロール プレーン RBAC と成熟したソフトウェア開発ライフサイクル プラクティスがあれば、イグレス コントローラーまで TLS 暗号化し、Web Application Firewallで保護するだけで十分です。 このアプローチにより、ワークロード管理のオーバーヘッドと、ネットワーク パフォーマンスの低下によるオーバーヘッドが最小限に抑えられます。 ワークロードとコンプライアンス要件によって、 TLS 終端 を実行する場所が決まります。

エグレス トラフィック フロー

このアーキテクチャでは、クラスターからのすべてのエグレス トラフィックが Azure Firewall を介して通信することをお勧めします。 または、独自の同様のネットワーク仮想アプライアンスを使用することもできます。 Azure NAT Gateway や HTTP プロキシ などの他の出力オプションは、ネットワーク トラフィックの検査を提供しないため、使用はお勧めしません。 ゼロ トラスト制御とトラフィック検査機能を実現するために、クラスターからのすべてのエグレス トラフィックはファイアウォールを通過します。 この構成は、ユーザー定義ルート (UDR) を使用して実装できます。 ルートのネクスト ホップは、Azure Firewall の プライベート IP アドレス です。 Azure Firewall は、エグレス トラフィックをブロックするか許可するかを決定します。 この決定は、Azure Firewall で定義した特定のルール、または組み込みの脅威インテリジェンス ルールに基づいて行われます。

Azure Firewall の代替として、AKS HTTP プロキシ 機能を使用することもできます。 クラスターから送信されるすべてのトラフィックは、HTTP プロキシの IP アドレスに送信され、そこでトラフィックが転送されるかドロップされます。

どちらの方法でも、AKS に必要な 出力ネットワーク トラフィック ルール を確認してください。

ゼロ トラスト制御の例外は、クラスターが他の Azure リソースと通信する必要がある場合です。 たとえば、クラスターはコンテナー レジストリから更新されたイメージをプルしたり、Key Vault からシークレットをプルしたりする必要がある場合があります。 このようなシナリオでは、 プライベート リンクを使用することをお勧めします。 利点は、特定のサブネットがサービスに直接到達し、クラスターとサービス間のトラフィックがインターネットを経由しないことです。 欠点は、パブリック エンドポイント経由でターゲット サービスを使用する代わりに、プライベート リンク では追加の構成が必要になることです。 また、すべての Azure サービスまたは製品が プライベート リンク をサポートしているわけではありません。 このような場合は、サブネット上の 仮想ネットワーク サービス エンドポイント を有効にしてサービスにアクセスすることを検討してください。

プライベート リンク またはサービス エンドポイントが選択できない場合は、パブリック エンドポイントを介して他のサービスにアクセスし、Azure Firewall ルールとターゲット サービスに組み込まれたファイアウォールを通じてアクセスを制御できます。 このトラフィックはファイアウォールの静的 IP アドレスを通過するため、それらのアドレスをサービスの IP 許可リストに追加できます。 1 つの欠点は、Azure Firewall で特定のサブネットからのトラフィックのみを許可するために、さらに多くのルールが必要になることです。 Azure Firewall を使用してエグレス トラフィック用に複数の IP アドレスを計画している場合は、それらのアドレスを考慮してください。 そうしないと、ポートが枯渇する可能性があります。 複数の IP アドレスの計画の詳細については、「複数の IP アドレスを持つ Azure Firewall を作成する」を参照してください。

AKS ベースライン参照アーキテクチャ上の Windows コンテナーにおける Windows 固有の送信に関する考慮事項については、「AKS 上の Windows コンテナー」を参照してください。

ポッド間トラフィック

既定では、ポッドではクラスター内の他のポッドからのトラフィックを受け入れることができます。 Kubernetes NetworkPolicy を使用して、ポッド間のネットワーク トラフィックを制限します。 ポリシーを慎重に適用しないと、重要なネットワーク フローがブロックされる状況が発生する可能性があります。 イングレス コントローラーとワークロードとの間のトラフィックなど、特定の通信パス "のみ" を必要に応じて許可します。 詳細については、「ネットワーク ポリシー」を参照してください。

後で追加することはできないため、クラスターをプロビジョニングするときにネットワーク ポリシーを有効にします。 NetworkPolicy を実装するテクノロジにはいくつかの選択肢があります。 Azure Container Networking Interface (CNI) を必要とする Azure ネットワーク ポリシーをお勧めします。 詳細については、次の注記を参照してください。 その他のオプションには、よく知られているオープンソース オプションである Calico ネットワーク ポリシーがあります。 クラスター全体のネットワーク ポリシーを管理する必要がある場合は、Calico を検討してください。 Calico は、標準の Azure サポートの対象にはなりません。

詳細については、「Azure ネットワーク ポリシー エンジン間の違い」を参照してください。

管理トラフィック

クラスターの実行の一環として、Kubernetes API サーバーは、クラスターをスケーリングするためのリソースを作成する要求など、クラスターで管理操作を実行するリソースからのトラフィックを受信します。 これらのリソースの例には、DevOps パイプラインのビルド エージェント プール、Azure Bastion サブネット内の Azure Bastion インスタンス、ノード プール自体などがあります。 すべてのIPアドレスからの管理トラフィックを受け入れる代わりに、AKS承認済みIP範囲機能を使用して、承認済みIP範囲からのトラフィックのみをAPIサーバーに許可します。

詳細については、「API サーバー許可 IP 範囲の定義」を参照してください。

別の制御レイヤーを追加するには、複雑さが増しますが、プライベート AKS クラスターをプロビジョニングできます。 プライベート クラスターを使用すると、API サーバーとノード プール間のネットワーク トラフィックがプライベート ネットワークのみに留まり、インターネットに公開されないようにすることができます。 詳細については、「AKS プライベート クラスター」を参照してください。

シークレット管理の追加

シークレットを Key Vault などの管理されたキー ストアに保存します。 利点は、管理されたキーストアがシークレットのローテーションを処理することです。 強力な暗号化とアクセス監査ログを提供します。 また、コアシークレットをデプロイメントパイプラインから除外します。 このアーキテクチャでは、Key Vault ファイアウォールが有効化および構成されており、シークレットと証明書にアクセスする必要がある Azure のリソースから接続するときに プライベート リンク が使用されます。

Key Vault は他の Azure サービスと適切に統合されています。 それらのサービスの組み込み機能を使用して、シークレットにアクセスします。 Application Gateway がイグレス フローの TLS 証明書にアクセスする方法の詳細については、 イグレス トラフィック フロー セクションを参照してください。

Key Vault の Azure RBAC アクセス許可モデルを使用すると、ワークロード ID を Key Vault シークレット ユーザーまたは Key Vault リーダーのロール割り当てに割り当て、シークレットにアクセスできるようになります。 詳細については、「RBAC を使用して Key Vault にアクセスする」を参照してください。

クラスターシークレットにアクセスする

ポッドが特定のストアのシークレットにアクセスできるようにするには、ワークロード ID を使用する必要があります。 取得プロセスを容易にするには、 シークレット ストア CSI ドライバー を使用します。 ポッドにシークレットが必要な場合、ドライバーは指定されたストアに接続し、ボリューム上のシークレットを取得し、そのボリュームをクラスターにマウントします。 その後、ボリューム ファイル システムからポッドにシークレットを取得できます。

CSI ドライバーには、さまざまなマネージド ストアをサポートするプロバイダーが多数存在します。 この実装では、 Key Vault with secrets store CSI ドライバーを使用します。 アドオンは Key Vault から TLS 証明書を取得し、イグレス コントローラーを実行するポッドにドライバーを読み込みます。 この操作はポッドの作成中に行われ、ボリュームには公開キーと秘密キーの両方が保存されます。

ワークロード ストレージ

このアーキテクチャのワークロードはステートレスです。 状態を保存する必要がある場合は、クラスターの外部に保持することをお勧めします。 ワークロードの状態に関するガイダンスは、この記事の範囲外です。

詳細については、AKS でのアプリケーションのストレージ オプションに関するページを参照してください。

ポリシー管理

AKS クラスターを管理する効果的な方法は、ポリシーを通じてガバナンスを実施することです。 Kubernetes は、Open Policy Agent (OPA) Gatekeeper を通じてポリシーを実装します。 AKS の場合は、Azure Policy を通じてポリシーを配信します。 各ポリシーは、そのスコープ内のすべてのクラスターに適用されます。 OPA Gatekeeper はクラスター内のポリシー適用を処理し、すべてのポリシー チェックをログに記録します。 ポリシーの変更はクラスターにすぐに反映されないため、多少の遅延が発生する可能性があります。

AKS クラスターを管理するには、Azure Policy を使用して次の操作を実行できます。

• リソース グループまたはサブスクリプションでの AKS クラスターのデプロイを防止または制限します。 組織に標準を適用します。 たとえば、命名規則に従ったり、タグを指定したりできます。
• Kubernetes の Azure Policy を使用して AKS クラスターをセキュリティで保護します。

ポリシーを設定する場合、ワークロードの要件に基づいて適用します。 次の点を考慮します。

• イニシアチブとも呼ばれるポリシーのコレクションを設定しますか、それとも個別のポリシーを選択しますか? Azure Policy には、基本と制限の 2 つの組み込みイニシアティブが用意されています。 各イニシアティブは、AKS クラスターに適用可能な組み込みポリシーのコレクションです。 イニシアチブを選択し、 ではクラスターと、クラスターと対話する Container Registry、Application Gateway、Key Vault などのリソースに対して他のポリシーを選択することをお勧めします。 組織の要件に基づいてポリシーを選択します。

• アクションを 監査 するか、 拒否 するか? 監査 モードでは、アクションは許可されますが、 非準拠としてフラグが付けられます。 定期的に非準拠状態をチェックし、必要な措置を講じるプロセスを用意します。 拒否 モードでは、アクションはポリシーに違反しているため、ブロックされます。 このモードを選択する場合は、ワークロードが機能するには制限が厳しすぎる可能性があるため、注意してください。

• ワークロードに、仕様上準拠する必要のない領域があるか: Azure Policy には、ポリシーの適用から除外される Kubernetes 名前空間を指定する機能があります。 これらのインスタンスを認識できるように、 監査 モードでポリシーを適用することをお勧めします。

• 組み込みポリシーでカバーされていない要件はありますか? カスタム OPA Gatekeeper ポリシーを適用するカスタムの Azure Policy 定義を作成できます。 カスタム ポリシーをクラスターに直接適用しないでください。 詳細については、「カスタム ポリシー定義の作成と割り当て」を参照してください。

• 組織全体の要件はあるか: ある場合は、それらのポリシーを管理グループ レベルで追加します。 組織に汎用ポリシーがある場合でも、クラスターは独自のワークロード固有のポリシーを割り当てる必要があります。

• Azure ポリシーを特定のスコープに割り当てますか? 本番環境 ポリシーが 本番前環境 に対しても検証されていることを確認します。 そうしないと、本番環境にデプロイするときに、本番前環境では考慮していなかった予期しない追加の制限に遭遇する可能性があります。

このリファレンス実装では、AKS クラスターの作成時に Azure Policy が有効になります。 制限的なイニシアチブは、非コンプライアンスを可視化するために 監査 モードに割り当てられます。

この実装では、組み込みのイニシアチブの一部ではない追加のポリシーも設定されます。 これらのポリシーは、 拒否 モードで設定されます。 たとえば、イメージがデプロイされた Container Registry インスタンスからのみプルされるようにするポリシーが設けられています。 独自のカスタム イニシアティブの作成を検討してください。 また、ワークロードに適用可能なポリシーを 1 つの割り当てに結合してください。

クラスター内から Azure Policy がどのように機能するかを観察するには、 gatekeeper-system 名前空間内のすべてのポッドのポッド ログと、 azure-policy 名前空間の azure-policy-webhook ポッドと kube-system ポッドのログにアクセスできます。

Windows 固有の Azure Policy の考慮事項の詳細については、 AKS 上の Windows コンテナーのポリシー管理 の記事を参照してください。

ノードとポッドのスケーラビリティ

需要の増加に応じて、Kubernetes は水平ポッド自動スケーリングを通じて既存のノードにポッドを追加することでスケールアウトできます。 Kubernetes がこれ以上ポッドをスケジュールできなくなった場合は、AKS クラスターの自動スケーリングを通じてノードの数を増やす必要があります。 完全なスケーリング ソリューションには、クラスター内のポッド レプリカとノード数の両方をスケーリングする方法が必要です。

自動スケーリングまたは手動スケーリングという 2 つの方法があります。

自動スケーリングと手動アプローチの両方で、CPU 使用率またはカスタム メトリックを監視してアラートを設定する必要があります。 ポッドのスケーリングでは、アプリケーション オペレーターは Kubernetes API を通じて ReplicaSet を調整することで、ポッドのレプリカの数を増減できます。 クラスターのスケーリングの場合、Kubernetes スケジューラが失敗したときに通知する方法が 1 つあります。 もう 1 つの方法は、時間の経過と共に保留中のポッドを監視することです。 ノード数は、Azure CLI または Azure ポータルを通じて調整できます。

手動メカニズムの一部はオートスケーラーに組み込まれているため、オートスケーリング アプローチをお勧めします。

一般的な方法としては、最小限の数のポッドとノードでパフォーマンス テストを開始することから始めます。 それらの値を使用して、ベースライン予測を確立します。 次に、パフォーマンス メトリックと手動スケーリングを組み合わせてボトルネックを特定し、スケーリングに対するアプリケーションの応答を理解します。 最後に、このデータを使用して自動スケーリングのパラメーターを設定します。 AKS を使用したパフォーマンス チューニング シナリオの詳細については、「パフォーマンス チューニング シナリオ: 分散ビジネス トランザクション」を参照してください。

ポッドの水平オートスケーラー

ポッドの水平オートスケーラー (HPA) は、ポッドの数をスケーリングする Kubernetes リソースです。

HPA リソースでは、最小レプリカ数と最大レプリカ数を設定することをお勧めします。 値は自動スケーリングの境界を制限します。

HPA は、CPU 使用率、メモリ使用量、カスタム メトリックに基づいてスケーリングできます。 デフォルトでは CPU 使用率のみが提供されます。 HorizontalPodAutoscaler 定義は、メトリックの目標値を指定します。 たとえば、仕様では目標の CPU 使用率を設定します。 ポッドの実行中、HPA コントローラーは Kubernetes Metrics API を使用して各ポッドの CPU 使用率を確認します。 その値を目標使用量と比較し、比率を計算します。 次に、この比率を使用して、ポッドが多く割り当てられているか、少なく割り当てられているかどうかが判断されます。 ノードに新しいポッドを割り当てたり、ノードからポッドを削除したりするには、Kubernetes スケジューラが使用されます。

スケーリング操作が完了する前に HPA がチェックする競合状態が発生する可能性があります。 その結果、比率計算は正しくない可能性があります。 詳細については、「スケーリング イベントのクールダウン」を参照してください。

ワークロードがイベント駆動型の場合、人気のあるオープンソース オプションは Kubernetes イベント駆動型自動スケーリング (KEDA) です。 ワークロードが CPU またはメモリにバインドされるのではなく、メッセージ キューなどのイベント ソースによってワークロードが駆動される場合は、KEDA を検討してください。 KEDA は多くのイベント ソースまたはスケーラーをサポートしています。 KEDA スケーラーで KEDA がスケーリングできるイベント ソースのリストを使用します。 リストには、Azure Monitor メトリックに基づいて KEDA ワークロードをスケーリングする便利な方法である Azure Monitor スケーラー が含まれています。

クラスター オートスケーラー

クラスター オートスケーラー は、ノード プール内のノードの数をスケーリングする AKS アドオン コンポーネントです。 クラスターのプロビジョニング中に追加します。 ユーザー ノード プールごとに個別のクラスター オートスケーラーが必要です。

Kubernetes スケジューラはクラスター オートスケーラーをトリガーします。 リソースの制約が原因で Kubernetes スケジューラによるポッドのスケジューリングが失敗すると、オートスケーラーによってノード プールに新しいノードが自動的にプロビジョニングされます。 逆に、クラスター オートスケーラーによって、未使用のノード容量が確認されます。 ノードが想定した容量で実行されていない場合は、ポッドが別のノードに移動され、未使用のノードが削除されます。

オートスケーラーを有効にするときは、最大ノード数と最小ノード数を設定します。 推奨値は、ワークロードのパフォーマンス予測、クラスターに希望する拡張量、コストの影響によって異なります。 最小数は、そのノード プール用に予約されている容量です。 このリファレンス実装では、ワークロードが単純であるため、最小値は 2 に設定されています。

システム ノード プールの場合、推奨される最小値は 3 です。

このベースライン参照アーキテクチャに含まれる Windows 固有のスケーリングの考慮事項については、 AKS 上の Windows コンテナー の記事を参照してください。

ビジネス継続性に関する決定事項

ビジネスの継続性を維持するには、インフラストラクチャとアプリケーションの SLO を定義します。 詳細については、「信頼性目標の定義に関する推奨事項」を参照してください。 最新の オンライン サービスの SLA の記事で、AKS のサービス レベル アグリーメント (SLA) 条件を確認します。

クラスター ノード

ワークロードの最小レベルの可用性を満たすには、ノード プール内に複数のノードが必要です。 ノードに障害が発生した場合、同じノード プールとクラスター内の別のノードがアプリケーションの実行を継続できます。 信頼性のために、システム ノード プールには 3 つのノードを推奨します。 ユーザー ノード プールの場合は、少なくとも 2 つのノードから開始します。 高可用性が必要な場合は、さらに多くのノードをプロビジョニングします。

アプリケーションを、 ユーザー ノード プールと呼ばれる別のノード プールに配置することで、システム サービスから分離します。 このように、Kubernetes サービスは専用ノードで実行され、ワークロードと競合しません。 ノード プールを識別し、ワークロードをスケジュールするには、タグ、ラベル、テイントを使用することをお勧めします。 システム ノード プールが CriticalAddonsOnly taintで汚染されていることを確認します。

タイムリーな更新など、クラスターの定期的なメンテナンスは信頼性にとって非常に重要です。 また、プローブを通じてポッドの健全性を監視することをお勧めします。

ポッドの可用性

ポッド リソース要件を指定する: デプロイメントでポッド リソース要件を指定することをお勧めします。 そうすることで、スケジューラでポッドを適切にスケジューリングできます。 ポッドをスケジュールできない場合、信頼性は大幅に低下します。

ポッド中断予算を設定する: この設定は、更新またはアップグレード イベント中にデプロイメント内のレプリカをいくつ停止できるかを決定します。 詳細については、 ポッド中断バジェットに関するページを参照してください。

ハードウェア障害などの中断に対処するために、デプロイに複数のレプリカを構成します。 更新やアップグレードなどの計画されたイベントの場合、中断予算は、予想されるアプリケーション負荷を処理するために必要な数のポッドレプリカが存在することを保証するのに役立ちます。

ワークロード名前空間にリソース クォータを設定する: 名前空間のリソース クォータは、デプロイメントでポッド要求と制限が適切に設定されることを確認するのに役立ちます。 詳細については、「リソース クォータを適用する」を参照してください。

ポッドのリクエストと制限を設定する: リクエストと制限を設定すると、Kubernetes はポッドに CPU とメモリのリソースを効率的に割り当てることができ、ノード上のコンテナ密度を高めることができます。 リクエストと制限により、ハードウェアの使用効率が向上するため、コストを削減しながら信頼性を高めることもできます。

ワークロードの制限を見積もるために、テストを行い、ベースラインを確立します。 要求と制限に等しい値を使用して開始します。 次に、クラスターの不安定性を引き起こす可能性のあるしきい値を確立するまで、これらの値を徐々に調整します。

デプロイメント マニフェストでリクエストと制限を指定できます。 詳細については、 ポッドの要求と制限の設定に関するページを参照してください。

可用性ゾーンと複数リージョンのサポート

特定の種類の停止から保護するには、リージョンがサポートしている場合は 可用性ゾーン を使用します。 これにより、コントロール プレーン コンポーネントとノード プール内のノードの両方をゾーン間で分散させることができます。 1 つのゾーン全体が使用できない場合でも、リージョン内にある別のゾーンのノードを引き続き使用できます。 各ノード プールは、ノード インスタンスとスケーラビリティを管理する個別の仮想マシン スケール セットにマップされます。 AKS サービスは、スケール セットの操作と構成を管理します。 複数のゾーンを有効にする場合の考慮事項は次のとおりです。

• インフラストラクチャ全体: 可用性ゾーンをサポートするリージョンを選択します。 詳細については、制限に関するページを参照してください。 稼働時間 SLA を確保するには、Standard または Premium レベルを選択する必要があります。 可用性ゾーンを使用すると、稼働時間 SLA が向上します。

• クラスター: 可用性ゾーンは、ノード プールを作成するときにのみ設定できます。 後から変更することはできません。 予想される分散が可能になるように、ノード サイズがすべてのゾーンでサポートされている必要があります。 基になる仮想マシン スケール セットによって、ゾーン間で同じハードウェア構成が実現します。

  複数ゾーンのサポートは、ノード プールだけでなく、コントロール プレーンにも適用されます。 AKS コントロール プレーンは、ノード プールと同様に、要求されたゾーンにまたがります。 クラスターでゾーン サポートを使用しない場合、コントロール プレーン コンポーネントが可用性ゾーン全体に分散されることは保証されません。

• 依存リソース: ゾーンの利点を完全に享受するには、すべてのサービス依存関係もゾーンをサポートする必要があります。 依存するサービスがゾーンをサポートしていない場合、ゾーンの障害によってそのサービスが失敗する可能性があります。

  たとえば、マネージド ディスクは、プロビジョニングされたゾーンで使用できます。 障害が発生した場合、ノードは別のゾーンに移動する可能性がありますが、マネージド ディスクはノードとともにそのゾーンに移動しません。

このアーキテクチャを簡素化するために、AKS は、可用性ゾーン 1、2、3 にまたがるノード プールを持つ単一のリージョンにデプロイされます。 Azure Firewall や Application Gateway などのインフラストラクチャの他のリソースも、複数のゾーンをサポートする同じリージョンにデプロイされます。 Container Registry では geo レプリケーションが有効になっています。

複数のリージョン

可用性ゾーンを有効にしても、万が一リージョン全体に障害が発生した場合には、十分な対応ができません。 より高い可用性を得るには、異なるリージョンで複数の AKS クラスターを実行します。

• 使用可能な場合はペア リージョンを優先します。 ペアのリージョンを使用する利点は、プラットフォームの更新中の信頼性です。 Azure では、ペアのうち 1 つのリージョンのみが一度に更新されるようになっています。 一部の地域にはペアがありません。 リージョンがペアになっていない場合でも、使用する他のリージョンを選択することにより、マルチリージョン ソリューションをデプロイできます。 リージョン障害からの回復を調整するように構成する継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの使用を検討してください。 Flux などの特定の DevOps ツールを使用すると、複数リージョンのデプロイを簡単に行うことができます。

• Azure リソースが geo 冗長性をサポートしている場合は、冗長サービスのセカンダリ インスタンスが存在する場所を指定します。 たとえば、Container Registry の geo レプリケーションを有効にすると、選択した Azure リージョンにイメージが自動的にレプリケートされます。 また、プライマリ リージョンで障害が発生した場合でも、イメージへの継続的なアクセスが提供されます。

• 要件に応じて、ゾーンまたはリージョン間でトラフィックを分散できるトラフィック ルーターを選択します。 このアーキテクチャでは、ゾーン間で非 Web トラフィックを分散できるため、Load Balancerがデプロイされます。 トラフィックを複数のリージョンに分散する必要がある場合は、Azure Front Door を検討してください。 その他のオプションについては、「ロードバランサーの選択」を参照してください。

障害復旧

プライマリ リージョンで障害が発生した場合、理想的には、別のリージョンに新しいインスタンスをすばやく作成できます。 以下に、推奨事項をいくつか示します。

• 複数のリージョンを使用します。 プライマリ リージョンにペア リージョンがある場合、そのペアを使用します。 ない場合、データの保存場所と待機時間の要件に基づいてリージョンを選択します。

• 効率的に複製できる非ステートフル ワークロードを使用します。 クラスターに状態を保存する必要がある場合は (推奨されません)、別のリージョンにデータを頻繁にバックアップするようにしてください。

• SLO を満たすために、別のリージョンへのレプリケーションなどのリカバリ戦略を DevOps パイプラインの一部として統合します。

• 災害復旧をサポートする機能を使用して、各 Azure サービスをプロビジョニングします。 たとえば、このアーキテクチャでは、Container Registry が geo レプリケーションに対して有効になっています。 リージョンに障害が発生した場合でも、複製されたリージョンからイメージをプルできます。

• AKS クラスターやその他の必要なコンポーネントを含むインフラストラクチャをコードとしてデプロイします。 別のリージョンにデプロイする必要がある場合、スクリプトまたはテンプレートを再利用して同じインスタンスを作成できます。

クラスターバックアップ

多くのアーキテクチャでは、Git 操作ベースの クラスター ブートストラップによって新しいクラスターをプロビジョニングし、それを動作状態に戻してから、アプリケーションをデプロイすることができます。 ただし、構成マップ、ジョブ、シークレットなど、ブートストラップ プロセス内でキャプチャできない重要なリソース状態がある場合は、リカバリ戦略を検討してください。 Kubernetes でステートレス ワークロードを実行することをお勧めします。 アーキテクチャにディスクベースの状態が含まれる場合は、そのコンテンツの回復戦略も考慮する必要があります。

クラスター バックアップをリカバリ戦略の一部にする必要がある場合は、クラスター内にビジネス要件に一致するソリューションをインストールする必要があります。 このエージェントは、クラスター リソースの状態を選択した宛先にプッシュし、Azure ディスク ベースの永続ボリューム スナップショットを調整する役割を担います。

VMware Velero は、直接インストールして管理できる一般的な Kubernetes バックアップ ソリューションの例です。 または、 AKS バックアップ拡張機能 を使用して、管理された Velero 実装を提供することもできます。 AKS バックアップ拡張機能では、Kubernetes リソースと永続ボリューム両方のバックアップがサポートされており、スケジュールとバックアップ スコープは、Azure Backup のボールト構成として外部化されています。

リファレンス実装では、管理、監視、購入、セキュリティ保護のための追加の Azure リソースを必要とするバックアップは実装されません。 これらのリソースには、Azure Storage アカウント、Azure Backup コンテナーと構成、 信頼されたアクセス機能 などが含まれる場合があります。 代わりに、ステートレス ワークロードを実行する意図と組み合わせた Git 操作が回復ソリューションとなります。

定義されたリカバリポイント目標とリカバリ時間目標を含むビジネス目標を満たすバックアップ ソリューションを選択して検証します。 チームのランブックでリカバリ プロセスを定義し、すべてのビジネス クリティカルなワークロードに対してそれを実践します。

Kubernetes API サーバー SLA

AKS は無料サービスとして使用できますが、そのレベルでは金銭的に裏付けられた SLA は提供されません。 SLA を得るには、Standard レベルを選ぶ必要があります。 すべての運用クラスターで Standard レベルの採用をお勧めします。 Free レベルは運用開始前のクラスター用に予約し、Premium レベルは ミッション クリティカルなワークロード 専用に予約します。 Azure Availability Zones を使用すると、Kubernetes API サーバーの SLA が高くなります。 ノード プールおよびその他のリソースは、それぞれ独自の SLA の対象となります。 各サービスの特定の SLA の詳細については、「オンライン サービスの SLA」を参照してください。

トレードオフ

複数のゾーンや、特に複数のリージョンにわたってアーキテクチャをデプロイする場合、コストと可用性のトレードオフがあります。 Container Registry の geo レプリケーションなどの一部のレプリケーション機能は、より高価なプレミアム SKU で利用できます。 マルチリージョン展開の場合、トラフィックがリージョン間を移動するときに帯域幅料金が適用されるため、コストも増加します。

また、ゾーンまたはリージョン間のノード通信では、追加のネットワーク遅延が発生することも予想されます。 このアーキテクチャ上の決定がワークロードに与える影響を測定します。

シミュレーションと強制フェールオーバーをテストする

停止をシミュレートした強制フェイルオーバー テストを通じてソリューションの信頼性をテストします。 シミュレーションには、ノードの停止、特定のゾーン内のすべての AKS リソースの停止によるゾーン障害のシミュレート、外部依存関係障害の呼び出しなどが含まれます。 Azure Chaos Studio を使用して、Azure およびクラスターでのさまざまな種類の停止をシミュレートすることもできます。

詳細については、 Chaos Studioを参照してください。

ログとメトリックの監視と収集

コンテナー ワークロードのパフォーマンスを監視するには、イベントをリアルタイムで表示できるため、Azure Monitor container insight を使用することをお勧めします。 実行中のポッドからコンテナー ログをキャプチャし、集計して表示できます。 また、実行中のリソースとワークロードの健全性を監視するために、メモリと CPU の使用状況に関するメトリクス API からの情報も収集します。 コンテナ インサイトを使用して、ポッドのスケーリング時のパフォーマンスを監視することもできます。 収集されたデータの監視、分析、視覚化に不可欠なテレメトリが含まれています。 コンテナ インサイトは傾向を識別し、重大な問題についてプロアクティブに通知を受け取るようにアラートを構成できるようにします。

ContainerLogV2 ログ スキーマ は、合理化されたアプローチで Kubernetes ポッドからコンテナー ログをキャプチャするように設計されています。 ログ エントリは、Azure Log Analytics ワークスペースの ContainerLogV2 テーブルに統合されます。

ポッドでホストされているほとんどのワークロードからは、Prometheus メトリックが出力されます。 コンテナ インサイトは Prometheus と統合できます。 ノードと Kubernetes から収集されたアプリケーションとワークロードのメトリックを表示できます。

Datadog、Grafana、New Relic など、Microsoft 以外のソリューションの中には Kubernetes と統合されるものもあります。 したがって、組織ですでにこれらのソリューションを使用している場合は、それらを活用できます。

AKS を使用すると、Azure はコア Kubernetes サービスの一部を管理します。 Azure は、AKS コントロール プレーン コンポーネントのログを リソース ログとして実装します。 ほとんどのクラスターでは、次のオプションを有効にすることをお勧めします。 これらのオプションはクラスターの問題のトラブルシューティングに役立ち、ログ密度は比較的低くなっています。

• ClusterAutoscaler: ログ記録によりスケーリング操作の監視を獲得します。 詳細については、「クラスター オートスケーラーのログと状態を取得する」を参照してください。
• KubeControllerManager: Kubernetes と Azure コントロール プレーン間の相互作用の監視を獲得します。
• kube-audit-admin: クラスターを変更するアクティビティの監視を獲得します。 kube-audit と kube-audit-admin の両方を有効にする理由はありません。 kube-audit は、非変更 (読み取り) 操作も含む kube-audit-admin のスーパーセットです。
• guard: Microsoft Entra ID および Azure RBAC 監査をキャプチャします。

クラスターまたはワークロードのライフサイクルの初期開発中に、 KubeScheduler や kube-auditなどの他のログ カテゴリを有効にすると役立つ場合があります。 追加されたクラスターの自動スケーリング、ポッドの配置とスケジュール、および同様のデータは、クラスターまたはワークロードの操作に関する問題のトラブルシューティングに役立ちます。 ただし、トラブルシューティングのニーズが終了した後も、拡張トラブルシューティング ログを常時オンにしておくと、Azure Monitor にデータを取り込んで保存するために不必要なコストが発生する可能性があります。

Azure Monitor には、最初に使用する既存のログ クエリのセットが含まれていますが、それらを基盤として使用して独自のクエリを構築することもできます。 ライブラリが拡大するにつれて、1 つ以上の クエリ パック を使用してログ クエリを保存し、再利用できるようになります。 クエリのカスタム ライブラリにより、AKS クラスターの正常性とパフォーマンスの監視が向上します。 SLO の達成をサポートします。

AKS の監視に関するベスト プラクティスの詳細については、「Azure Monitor を使用した AKS の監視」を参照してください。

Windows 固有の監視に関する考慮事項の詳細については、「AKS 上の Windows コンテナー」を参照してください。

ネットワークの測定基準

基本的なクラスターレベルのネットワーク メトリックは、ネイティブの プラットフォームおよび Prometheus メトリックを通じて利用できます。 さらに、AKS network observability を使用して、Prometheus メトリックを使用してノード レベルでネットワーク メトリックを公開できます。 ほとんどのクラスターには、追加のネットワークトラブルシューティング機能を提供し、ノード レベルで予期しないネットワークの使用状況や問題を検出するためのネットワーク監視機能が含まれている必要があります。

このリファレンス実装では、Azure Monitor コンテナーの分析情報が使用されます。この分析情報では、ネットワーク関連のメトリックも収集されます。 参照実装では、Azure Monitor コンテナー分析情報からのメトリックの収集が無効になり、代わりに、 管理された Prometheus の Azure Monitor ワークスペースを使用してネットワーク監視メトリックが収集されます。

伝送制御プロトコル (TCP) またはユーザー データグラム プロトコル (UDP) のパケット損失、遅延、または DNS 負荷の影響を非常に受けやすいワークロードの場合、ポッド レベルのネットワーク メトリックが重要です。 AKS では、 高度なネットワーク可観測性 機能を使用して、そのレベルの詳細を確認できます。 ほとんどのワークロードでは、これほどのネットワークの監視は必要ありません。 ポッドが高度に最適化されたネットワークを必要とする場合を除き、高度なネットワーク可観測性を有効にしないでください。パケット レベルまで感度が低下します。

ログ記録のコスト最適化

参照実装では、基本プランを開始点として使用するように ContainerLogV2 テーブルを構成します。 Microsoft Defender for Containers と、参照実装用に作成されたアラートでは、このテーブルに対してクエリが実行されないため、Basic プランではインジェスト コストが削減されるため、コスト効率が高くなる可能性があります。

ログ ボリュームとクエリの要件が進化したら、ニーズに合わせて最もコスト効率の高いテーブル プランを選択します。 クエリがテーブル データを頻繁にスキャンする読み取り集中型のソリューションになった場合は、既定の Analytics プランの方が適している可能性があります。 Analytics プランでは、クエリの料金が不要になります。クエリ アクティビティがインジェスト コストを上回るシナリオに合わせて最適化されます。 使用パターンを監視し、必要に応じてテーブル プランを調整することで、監視ソリューションのコストと機能のバランスを取ることができます。

詳細については、「Log Analytics ワークスペースのデータ使用量に基づいてテーブル プランを選択する」を参照してください。

自己復旧を有効にする

生存性プローブとreadiness probeを設定してポッドの健全性を監視します。 Kubernetes は応答しないポッドを検出すると、そのポッドを再起動します。 liveness probe では、ポッドが正常であるかどうかが判断されます。 Kubernetes は応答しないポッドを検出すると、そのポッドを再起動します。 readiness probeは、ポッドがリクエストとトラフィックを受信する準備ができているかどうかを判断します。

AKS クラスターの定期的な更新

Kubernetes クラスターの Day 2 運用の一部として、定期的なプラットフォームとオペレーティング システムの更新を実行します。 すべての AKS クラスターで対処する必要がある更新には 3 つのレイヤーがあります。

• Kubernetes のバージョン (例: Kubernetes 1.30.3 から 1.30.7、または Kubernetes 1.30.7 から 1.31.1)。Kubernetes API の変更や廃止が伴う場合があります。 このレイヤーでのバージョン変更はクラスター全体に影響します。
• オペレーティング システムの更新と AKS コンポーネントの更新を組み合わせた、各ノード上の仮想ハード ディスク (VHD) イメージ。 これらの更新は、クラスターの Kubernetes バージョンに対してテストされます。 このレイヤーでのバージョン変更はノードプール レベルで適用され、Kubernetes バージョンには影響しません。
• Windows Update や apt などのオペレーティング システム独自のネイティブ更新プロセス。 これらの更新プログラムはオペレーティング システム ベンダーが直接提供しており、クラスターの Kubernetes バージョンに対してテストされていません。 このレイヤーでのバージョン変更は単一のノードに影響し、Kubernetes のバージョンには影響しません。

これらの各レイヤーは独立して制御されます。 ワークロードのクラスターの各レイヤーの処理方法を決定します。 各 AKS クラスター、そのノード プール、またはそのノードが更新される頻度 (ケイデンス) を選択します。 また、更新を適用する曜日または時刻（メンテナンス ウィンドウ）を選択します。 更新を手動でインストールするか、自動的にインストールするか、あるいはまったくインストールしないかを選択します。 クラスター上で実行されるワークロードに安全なデプロイメント プラクティスが必要であるのと同様に、クラスターの更新にも安全なデプロイメント プラクティスが必要です。

パッチ適用とアップグレードに関する包括的な観点については、 AKS の Day-2 運用ガイドの AKS パッチおよびアップグレード ガイダンス を参照してください。 このアーキテクチャに関連するベースラインレコメンデーションについては、次の情報を使用してください。

イミュータブル インフラストラクチャ

AKS クラスターを不変のインフラストラクチャとして運用するワークロードは、クラスターを自動または手動で更新しません。 ノードイメージのアップグレード を none に設定し、 クラスターの自動アップグレード を noneに設定します。 この構成では、すべてのレイヤーでのすべてのアップグレードに対して単独で責任を負います。 必要な更新が利用可能になったら、実稼働前の環境で更新をテストし、新しいクラスターでの互換性を評価する必要があります。 その後、更新された AKS バージョンとノード プール VHD を含む運用レプリカ スタンプをデプロイします。 新しい本番クラスターの準備が整うと、古いクラスターは空になり、最終的には廃止されます。

新しいインフラストラクチャが定期的に導入される不変のインフラストラクチャは、実稼働クラスターにインプレース アップグレード戦略を適用すべきでない唯一の状況です。 他のすべてのクラスターには、インプレース アップグレード戦略が必要です。

一括アップグレード

AKS クラスターを不変のインフラストラクチャとして運用しないワークロードでは、3 つのレイヤーすべてに対応するために、実行中のクラスターを定期的に更新する必要があります。 更新プロセスをワークロードの要件に合わせて調整します。 定期的な更新プロセスを設計する際の出発点として、次のレコメンデーションを使用してください。

• クラスターのアップグレードを制御できるように、AKS の 計画メンテナンス 機能をスケジュールします。 この機能により、本質的にリスクの高い操作である更新を制御された時間に実行して、予期しない障害の影響を軽減できます。
• ローリング アップグレード中にアプリケーションが安定した状態を保つように、 ポッド中断予算 を構成します。 ただし、ほとんどのアップグレードでは各ノードで Cordon and Drain プロセスが必要になるため、ノードのアップグレードがブロックされるほど予算を積極的に設定しないでください。
• Azure リソースのクォータとリソースの可用性を確認します。 インプレース アップグレードでは、古いノードが削除される前に、 サージ ノードと呼ばれる新しいノード インスタンスがデプロイされます。 つまり、新しいノードには Azure のクォータと IP アドレス空間が利用可能である必要があります。 ほとんどのワークロードでは、 サージ値 が 33% であれば適切な開始点となります。
• クラスターに追加したサービス メッシュやセキュリティ エージェントなどのツールとの互換性をテストします。 また、イグレス コントローラー、サービス メッシュ、ワークロード ポッドなどのワークロード コンポーネントをテストします。 実稼働前の環境でテストを実行します。

ノードのインプレースアップグレード

ノード OS イメージのアップグレードには、 NodeImage 自動アップグレード チャネルを使用します。 このチャネルは、ノード レベルの更新を使用して各ノードの VHD を更新するようにクラスターを構成します。 Microsoft は、AKS バージョンに対して更新プログラムをテストします。 Windows ノードの場合、更新は月に 1 回程度行われます。 Linux ノードの場合、これらの更新は週に 1 回程度行われます。

• アップグレードによって AKS または Kubernetes のバージョンが変更されることはないため、Kubernetes API の互換性は問題になりません。
• NodeImage をアップグレード チャネルとして使用すると、計画されたメンテナンス ウィンドウが尊重されます。メンテナンス ウィンドウは、少なくとも週に 1 回設定する必要があります。 使用するノード イメージのオペレーティング システムに関係なく設定して、タイムリーな適用を確実にします。
• これらの更新には、オペレーティング システム レベルのセキュリティ、互換性、機能の更新、オペレーティング システムの構成設定、AKS コンポーネントの更新が含まれます。
• イメージのリリースとそれに含まれるコンポーネントのバージョン番号は、 AKS リリース トラッカーを使用して追跡されます。

クラスターのセキュリティ要件により、より積極的なパッチ適用の頻度が求められ、クラスターが潜在的な中断を許容できる場合は、代わりに SecurityPatch アップグレード チャネルを使用します。 Microsoft もこれらの更新プログラムをテストします。 更新プログラムは、Microsoft が次回の予定されているノード イメージのアップグレードの前にリリースするほど重要であると判断するセキュリティ アップグレードがある場合にのみ公開されます。 SecurityPatch チャネルを使用すると、 NodeImage チャネルが受信した更新も取得されます。 SecurityPatch チャネル オプションでは、メンテナンス ウィンドウが引き続き尊重されるため、予期しないセキュリティ更新をサポートするために、メンテナンス ウィンドウの間隔をより頻繁に (毎日または 1 日おきなど) 設定してください。

インプレース アップグレードを実行するほとんどのクラスターでは、 None および Unmanaged ノード イメージ アップグレード チャネル オプションを避ける必要があります。

クラスターへのインプレース更新

Kubernetes は急速に進化するプラットフォームであり、定期的なアップデートにより重要なセキュリティ修正と新しい機能が追加されます。 Kubernetes のアップデートを常に最新の状態に保つことが重要です。 最新の 2 つのバージョンまたは N-2以内にとどまる必要があります。 新しいバージョンが頻繁にリリースされるため、Kubernetes の最新バージョンにアップグレードすることが重要です。

ほとんどのクラスターは、十分な注意と厳格さをもって、インプレース AKS バージョン更新を実行できるはずです。 インプレース AKS バージョン アップグレードを実行するリスクは、十分な実稼働前テスト、クォータ検証、およびポッド中断予算の構成によってほとんど軽減できます。 ただし、インプレース アップグレードを行うと、予期しない動作が発生する可能性があります。 インプレース アップグレードがワークロードにとってリスクが高すぎると判断された場合は、残りのレコメンデーションに従うのではなく、 AKS クラスターのブルーグリーン デプロイ アプローチを使用することをお勧めします。

Kubernetes クラスターを初めてデプロイするときは、 クラスターの自動アップグレード 機能を使用しないことをお勧めします。 手動アプローチを使用すると、更新プログラムが運用環境に適用される前に、運用前環境で新しい AKS クラスター バージョンをテストする時間ができます。 このアプローチにより、最高レベルの予測可能性と制御も実現されます。 ただし、Kubernetes プラットフォームの新しい更新を注意深く監視し、新しいバージョンがリリースされたらすぐに採用する必要があります。 長期サポート アプローチよりも、「最新の状態を維持する」という考え方を採用する方がよいでしょう。

Azure Event Grid の AKS システム トピックを使用すると、クラスターで新しい AKS バージョンが利用可能になったときに通知を受け取ることができます。 リファレンス実装では、この Event Grid システム トピックをデプロイして、イベント ストリーム通知ソリューションから Microsoft.ContainerService.NewKubernetesVersionAvailable イベントをサブスクライブできるようにします。 特定の互換性の問題、動作の変更、または機能の廃止については、 AKS リリース ノート を確認してください。

最終的には、Kubernetes リリース、AKS リリース、クラスター、そのクラスター レベルのコンポーネント、およびワークロードについて十分な知識が得られ、自動アップグレード機能を検討できるようになるかもしれません。 生産システムの場合、 patch を超えることはほとんどないでしょう。 また、AKS バージョンを自動的にアップグレードする場合は、クラスターのインフラストラクチャ アズ コード (IaC) の AKS バージョン設定も確認して、同期が失われないようにしてください。自動アップグレード操作をサポートするように、 計画メンテナンス ウィンドウを構成します。

セキュリティの監視

アクティブな脅威と潜在的なセキュリティ リスクの両方についてコンテナ インフラストラクチャを監視します。 次にリソースをいくつか示します。

• Microsoft Defender for Containers は、コンテナー イメージに対する Defender for Cloud のレコメンデーションを特定して修正します。
• Defender for Containers は定期的に コンテナ イメージをスキャンして脆弱性を検出します。
• Defender for Containers は、 疑わしいアクティビティに対するリアルタイムのセキュリティ アラートも生成します。
• AKS アプリケーションとクラスターのセキュリティの概念では、コンテナー セキュリティがビルドから AKS で実行されるアプリケーション ワークロードまでのエンドツーエンドのパイプライン全体を保護する方法について詳しく説明しています。

クラスターとワークロードの操作

クラスターとワークロードの運用 (DevOps) に関する考慮事項については、 運用上の卓越性の設計原則 の柱を参照してください。

クラスター ブートストラップ

プロビジョニングを実行すると、クラスターは機能しますが、ワークロードをデプロイする前に、まだいくつかの手順が必要になる場合があります。 クラスターを準備するプロセスはブートストラップと呼ばれます。 ブートストラップは、前提条件となるイメージをクラスター ノードにデプロイし、名前空間を作成し、組織のユース ケースの要件を満たすその他のタスクを実行することから構成されます。

プロビジョニングされたクラスターと適切に構成されたクラスター間のギャップを減らすために、クラスター オペレーターは独自のブートストラップ プロセスがどのようなものであるかを検討する必要があります。 関連する資産を事前に準備する必要があります。 たとえば、アプリケーション ワークロードをデプロイする前に各ノードで Kured を実行することが重要である場合、クラスター オペレーターは、クラスターをプロビジョニングする 前 に、対象の Kured イメージを含む Container Registry インスタンスがすでに存在することを確認する必要があります。

次のいずれかの方法を使用して、ブートストラップ プロセスを構成できます。

• GitOps Flux v2 クラスター拡張機能
• Pipelines
• 例えばFluxやArgo CDを使った自己構成

AKS 用の GitOps Flux v2 クラスター拡張機能を使用する主な利点の 1 つは、プロビジョニングされたクラスターとブートストラップされたクラスターの間に実質的にギャップがないことです。 将来に向けて強固な管理基盤を備えた環境を設定し、IaC 戦略に合わせてブートストラップをリソース テンプレートとして含めることもサポートします。

最後に、拡張機能を使用する場合、ブートストラップ プロセスのどの部分でも kubectl は必要ありません。 緊急の修理状況に備えて、kubectl ベースのアクセスを予約できます。 Azure リソース定義のテンプレートと GitOps 拡張機能によるマニフェストのブートストラップの間で、kubectl を使用せずにすべての通常の構成アクティビティを実行できます。

ワークロードの役割を分離する

チームごと、およびリソースの種類ごとにワークロードを分割して、各部分を個別に管理します。

基本コンポーネントを含む基本的なワークロードから開始し、それを基に構築します。 最初のタスクはネットワークを構成することです。 ハブとスポークの仮想ネットワークと、それらのネットワーク内のサブネットをプロビジョニングします。 たとえば、スポークには、システム ノード プールとユーザー ノード プール、およびイグレス リソース用の個別のサブネットがあります。 Azure Firewall のサブネットをハブにデプロイします。

もう 1 つのタスクは、基本的なワークロードを Microsoft Entra ID と統合することです。

IaC の使用

可能であれば、命令型のアプローチではなく、べき等の宣言型メソッドを選択します。 構成オプションを指定する一連のコマンドを記述するのではなく、リソースとそのプロパティを記述する宣言型の構文を使用します。 Bicep、 Azure Resource Manager テンプレート (ARM テンプレート)、または Terraform を使用できます。

管理ポリシーに従ってリソースをプロビジョニングするようにしてください。 たとえば、VM サイズを選択するときは、コスト制約と可用性ゾーン オプションの範囲内で、アプリケーションの要件に合わせてください。 さらに、Azure Policy を使用して、これらの決定に対して組織のポリシーを適用することもできます。

一連のコマンドを記述する必要がある場合は、 Azure CLIを使用します。 これらのコマンドはさまざまな Azure サービスに対応しており、スクリプトを通じて自動化できます。 Windows と Linux は Azure CLI をサポートしています。 別のクロスプラットフォーム オプションは Azure PowerShell です。 選択は、希望するスキルセットによって異なります。

スクリプトとテンプレート ファイルをソース コントロール システムに保存し、バージョン管理します。

ワークロードの CI/CD

ワークフローとデプロイメントのパイプラインは、アプリケーションを継続的に構築およびデプロイできる必要があります。 更新は安全かつ迅速に展開し、問題が発生した場合にはロールバックする必要があります。

展開戦略には、信頼性が高く自動化された継続的デリバリー パイプラインを含める必要があります。 ワークロード コンテナ イメージの変更をクラスターに自動的にデプロイします。

このアーキテクチャでは、 GitHub Actions がワークフローとデプロイメントを管理します。 その他の一般的なオプションとしては、 Azure DevOps や Jenkinsなどがあります。

クラスターの CI/CD

このアーキテクチャの Visio ファイル をダウンロードします。

Kubectl のような命令型のアプローチを使用するのではなく、クラスターとリポジトリの変更を自動的に同期するツールを使用します。 新しいバージョンのリリースや、本番環境にデプロイする前のそのバージョンの検証などのワークフローを管理するには、GitOps フローを検討してください。

CI/CD フローの重要な部分は、新しくプロビジョニングされたクラスターをブートストラップすることです。 GitOps アプローチは、オペレーターが IaC 戦略の一部としてブートストラップ プロセスを宣言的に定義し、クラスターに自動的に反映される構成を確認できるため便利です。

GitOps を使用する場合は、クラスターにエージェントをデプロイして、プライベート Git リポジトリに格納されている構成とクラスターの状態が確実に連携するようにします。 そのようなエージェントの 1 つが flux です。flux はクラスター内の 1 つ以上のオペレーターを使用して、Kubernetes の内部でデプロイをトリガーします。 Flux により、次のタスクが実行されます。

• 構成されているすべてのリポジトリを監視する。
• 新しい構成の変更を検出する。
• デプロイをトリガーする。
• それらの変更に基づいて、必要な実行中の構成を更新する。

変更の展開方法を管理するポリシーを設定することもできます。

以下は、GitOps と Flux を使用してクラスター構成を自動化する方法を示した例です。

このアーキテクチャの Visio ファイル をダウンロードします。

1. 開発者は、Git リポジトリに格納されている構成の YAML ファイルなどのソース コードに変更をコミットします。 次に変更が Git サーバーにプッシュされます。

2. Flux はワークロードと並行してポッド内で実行されます。 開発者が要求した変更のみが Flux によって適用されるようにするため、Flux から Git リポジトリへのアクセスは読み取り専用です。

3. Flux は構成の変更を認識し、kubectl コマンドを使用してそれらの変更を適用します。

4. 開発者は kubectl を通じて Kubernetes API に直接アクセスすることはできません。

Git サーバーにブランチ ポリシーを設定すると、変更が本番環境に適用される前に、複数の開発者がプル リクエストを通じて変更を承認できるようになります。

GitOps と Flux を手動で構成することもできますが、AKS には GitOps with Flux v2 クラスター拡張機能 を使用することをお勧めします。

ワークロードとクラスターのデプロイ戦略

アーキテクチャ コンポーネント、ワークロード、クラスター構成などの あらゆる 変更を、少なくとも 1 つの運用前 AKS クラスターにデプロイします。 こうすることで、変更がシミュレートされ、本番環境に展開される前に問題を特定できる可能性があります。

次の段階に進む前に、各段階でテストと検証を実行します。 これにより、高度に制御された方法で本番環境に更新をプッシュし、予期しない展開の問題による中断を最小限に抑えることができます。 デプロイメントは、同じ GitHub Actions パイプラインまたは Flux オペレーターを使用して、本番環境と同様のパターンに従う必要があります。

ブルーグリーンデプロイメント、A/B テスト、 カナリアリリースなどの高度なデプロイメント手法では、追加のプロセスと、場合によっては追加のツールが必要になります。 Flagger は、高度な展開シナリオの解決に役立つ人気のオープンソース ソリューションです。

コスト管理

まず、 AKS 向けの Well-Architected フレームワークに記載されているコスト最適化設計チェックリストとレコメンデーションのリストを確認します。 Azure 料金計算ツール を使用して、アーキテクチャで使用するサービスのコストを見積もります。 その他のベストプラクティスについては、 コスト最適化を参照してください。

Kubernetes 固有の構成要素による詳細なクラスター インフラストラクチャ コストの割り当てには、 AKS コスト分析 の使用を検討してください。

Windows 固有のコスト管理の考慮事項については、「AKS 上の Windows コンテナー」を参照してください。

プロビジョニング

• コストがどこから発生するかを理解します。 AKS では、Kubernetes クラスター自体のデプロイ、管理、運用にかかるコストは最小限です。 コストに影響を与えるのは、クラスターによって消費される VM インスタンス、ストレージ、ログ データ、およびネットワーク リソースです。 システム ノード プールには、より安価な VM を選択することを検討してください。 DS2_v2 シリーズは、システム ノード プールの一般的な VM タイプです。

• Dev/Test 環境と運用環境に同じ構成を使用しないでください。 運用環境のワークロードには、高可用性のための追加の要件があり、一般的にはより高価です。 この構成は、Dev/Test 環境では必要ありません。

• 運用ワークロードの稼働時間 SLA を追加します。 ただし、可用性を保証する必要のない Dev/Test または実験的なワークロード向けに設計されたクラスターの場合は、コストを節約できます。 たとえば、SLO で十分です。 また、ワークロードがサポートしている場合は、 スポット VMを実行する専用のスポット ノード プールの使用を検討してください。

  AKS ワークロード アーキテクチャの一部として Azure SQL Database または Azure App Service を含む非運用ワークロードの場合は、Azure Dev/Test サブスクリプション を使用してサービス割引を受ける資格があるかどうかを評価します。

• スケーリングのニーズを満たすために大きすぎるクラスターから始めるのではなく、最小限の数のノードでクラスターをプロビジョニングし、クラスター オートスケーラーが監視してサイズ設定を行えるようにします。

• ポッドのリクエストと制限を設定すると、Kubernetes が高密度のノード リソースを割り当てられるようになり、ハードウェアを最大限に活用できるようになります。

• クラスターで診断を有効にすると、コストが増加する可能性があることを考慮してください。

• ワークロードを長期間にわたって存在させる必要がある場合は、1 年間または 3 年間の Azure 予約仮想マシンインスタンスを契約してノード コストを削減します。 詳細については、「Azure 予約仮想マシンインスタンス によるコストの節約」を参照してください。

• ノード プールを作成するときにタグを使用します。 タグは、発生したコストを追跡するためのカスタム レポートを作成するときに役立ちます。 タグを使用して総経費を追跡し、コストを特定のリソースまたはチームにマッピングできます。 また、チーム間でクラスターを共有する場合は、コンシューマーごとにチャージバック レポートを作成して、共有クラウド サービスの従量制課金コストを特定します。 詳細については、「テイント、ラベル、またはタグをノード プールに指定する」を参照してください。

• ワークロードが複数のリージョンにまたがり、リージョン間でデータを複製する場合は、追加の帯域幅コストが発生する可能性があります。 詳細については、「帯域幅の価格」をご覧ください。

• 組織が特定したコスト制約内に収まるように予算を作成します。 Microsoft Cost Management を通じて予算を作成できます。 また、アラートを作成して、特定のしきい値を超えたときに通知を受け取ることもできます。 詳細については、「テンプレートを使用して予算を作成する」を参照してください。

モニター

クラスター全体と、コンピューティング、ストレージ、帯域幅、ログ、ファイアウォールのコストを監視できます。 Azure には、コストを監視および分析するためのオプションが用意されています。

• Azure Advisor

• Microsoft Cost Management

理想的には、コストをリアルタイムで、または少なくとも定期的に監視します。 そうすれば、コストが計算されている月末までにアクションを起こすことができます。 また、予算内に収まるように、月ごとの傾向を長期にわたって監視します。

データに基づいた意思決定を行うには、どのリソースが最もコストがかかるかを詳細に特定する必要があります。 また、リソース使用量を計算するメーターについても十分に理解しておいてください。 たとえば、メトリックを分析することで、プラットフォームが過剰なサイズであるかどうかを判断できます。 Azure Monitor メトリックに使用量メーターが表示されます。

最適化

Azure Advisor によって提供されるレコメンデーションに基づいて対応します。 その他の最適化方法もあります。

• クラスター オートスケーラーを有効にして、ノード プール内の使用率の低いノードを検出して削除します。

  重要

  コストに影響を与えるために、ノード プールの最小ノード設定や最大ノード設定などのクラスター オートスケーラー設定を積極的に変更すると、逆効果になる可能性があります。 たとえば、 scale-down-unneeded-time が 10 分に設定され、ワー​​クロードの特性に基づいて 5 分ごとに最小ノード設定と最大ノード設定が変更された場合、ノード数は減少しません。 これは、クラスター オートスケーラー設定が更新されるため、各ノードの不要な時間の計算がリセットされるためです。

• ノード プール用には低めの SKU を選択します (ワークロードでサポートされている場合)。

• アプリケーションでバースト スケーリングを必要としない場合は、パフォーマンス メトリックの経時変化を分析することで、クラスターのサイズを適切なサイズに変更することを検討してください。

• ワークロードがサポートしている場合は、ユーザー ノード プールが実行される予定がないときは、 ユーザー ノード プールを 0 ノードにスケールします。 また、クラスターで実行がスケジュールされているワークロードが残っていない場合は、 AKS の開始/停止機能 を使用して、システム ノード プールと AKS コントロール プレーンを含むすべてのコンピューティングをシャットダウンすることを検討してください。

その他のコスト関連情報については、 AKS の価格に関するページを参照してください。

次のステップ

• 高度な AKS マイクロサービス アーキテクチャ
• マルチリージョン クラスターの AKS ベースライン
• PCI-DSS 3.2.1 の AKS 規制クラスター
• AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナー

関連リソース

• GitHub の AKS ロードマップ
• Kubernetes入門
• Kubernetes でのアプリケーションの開発とデプロイ
• AWS の Well-Architected Framework のレビュー
• AKS ランディング ゾーン アクセラレータ
• AKS の 2 日目の運用ガイド
• AKS のマイクロサービス アーキテクチャ
• Azure Firewall を使用して AKS クラスターを保護する
• AKS の Git 操作
• AKS を使用したデータ ストリーミング