AKS での Windows コンテナーの実行

この記事は、AKS クラスターを運用環境にデプロイする際に推奨される構成の詳細なレビューを提供する「AKS ベースライン アーキテクチャ」の拡張版となることを目的としています。 この記事では、Windows コンテナーの AKS へのデプロイに関連するガイダンスを提供することに焦点を当てます。 そのため、この記事では Windows の AKS へのデプロイに固有の構成に焦点を当てます。AKS ベースラインのドキュメントで既に説明されている構成については、そちらをご覧ください。

この参照アーキテクチャに関連する参照実装 (デプロイ コードのサンプルを含む) を確認するには、AKS Windows ベースライン GitHub プロジェクトをご覧ください。

ネットワーク設計

このアーキテクチャで使用するネットワーク デザインは、AKS ベースライン アーキテクチャで使用される設計に基づいているため、すべてのコア コンポーネントはその設計と同じです。ただし、次の変更を除きます。

• Windows ベースのワークロードをサポートするために、Active Directory ドメイン コントローラーが追加されました。
• このアーキテクチャのイングレス ソリューションでは、AKS ベースライン アーキテクチャで使用される Azure App Gateway ではなく、Azure Front Door (AFD) と Microsoft Entra アプリケーション プロキシ を使用します。

イングレス設計

コンポーネント:

• Azure Front Door と WAF: AFD は、AKS クラスターでホストされるアプリのパブリックに公開されているイングレス ポイントです。 AFD Premium では Private Link を使用できるため、この設計で使用されます。Private Link では、内部アプリ トラフィックがプライベート ネットワーク内にロックされるため、最高レベルのセキュリティが提供されます。 Web Application Firewall (WAF) は、Web アプリの一般的な悪用や脆弱性から保護します。
• Microsoft Entra アプリケーション プロキシ: このコンポーネントは、AKS によって管理される内部ロード バランサーの前の 2 番目のイングレス ポイントとして機能します。 これでは、ユーザーの事前認証に対して Microsoft Entra ID が有効になっており、条件付きアクセス ポリシーを使用して、未承認の IP 範囲 (アプリケーション プロキシは、発信元クライアント IP を確認し、条件付きアクセス ポリシーと比較します) とユーザーがサイトにアクセスするのを防ぎます。 これは、WAF をサポートする Azure サービスを使用しているときに Kerberos 認証要求をルーティングする唯一の方法です。 アプリケーション プロキシによって保護されているアプリへのシングル サインオン アクセスを提供する方法の詳細については、「アプリケーション プロキシを使ったアプリへのシングル サインオン (SSO) の Kerberos の制約付き委任」をご覧ください
• 内部ロード バランサー: AKS によって管理されます。 このロード バランサーでは、プライベートな静的 IP アドレスを使用してイングレス コントローラーが公開されます。 受信 HTTP 要求を受信する単一のコンタクト ポイントとして機能します。
• このアーキテクチャでは、クラスター内イングレス コントローラー (Nginx など) は使用されません。

この設計を実装するには、そのサービスでアプリが発行されたときに作成されるアプリケーション プロキシ URL を使用するように AFD を構成する必要があります。 この構成により、受信トラフィックがプロキシにルーティングされ、事前認証を実行できます。

ネットワーク トポロジ

次の図は、このアーキテクチャで使用されるハブスポーク ネットワーク設計を示しています。

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

ノード プール トポロジ

このアーキテクチャでは、Linux を実行するシステム ノード プール、Linux を実行するユーザー ノード プール、Windows を実行するユーザー ノード プールの 3 つのノード プールを使用します。 Windows と Linux のユーザー ノード プールはワークロードで使用され、システム ノード プールはシステムレベルのすべての構成 (CoreDNS など) で使用されます。

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

1. クライアントは HTTPS リクエストをドメイン名 bicycle.contoso.com に送信します。 その名前は、Azure Front Door のパブリック IP アドレスの DNS A レコードに関連付けられます。 このトラフィックは、クライアント ブラウザーとゲートウェイとの間のトラフィックを検査または変更できないようにするために暗号化されます。
2. Azure Front Door には統合された Web アプリケーション ファイアウォール (WAF) があり、bicycle.contoso.com の TLS ハンドシェイクをネゴシエートして、安全な暗号のみを許可します。 Azure Front Door ゲートウェイは、WAF 検査規則を処理し、構成されたバックエンドにトラフィックを転送するルーティング規則を実行するために必要であるため、TLS の終端ポイントです。 TLS 証明書は Azure Key Vault に格納されます。
3. AFD は、ユーザー要求を Azure アプリケーション プロキシにルーティングします。 AFD は、HTTPS トラフィックだけを許可するように構成されています。 事前認証が有効になっている場合、ユーザーは Microsoft Entra ID を使用して認証する必要があります。
4. アプリ プロキシは、AKS ロード バランサーを介して、バックエンド アプリ コンテナーにユーザーをルーティングします。

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

AKS ベースラインの記事に記載されているすべてのガイダンスがここに適用されますが、Windows ワークロードに関する追加の推奨事項があります。Windows Server の自動更新を活用するために、Azure Firewall ルールセットで必要な FQDN をブロックしないでください。

IP アドレス計画

Linux ノード プールを使用する AKS クラスターとは異なり、Windows ノード プールを持つ AKS クラスターには Azure CNI が必要です。 Azure CNI を使用すると、Azure Virtual Network からポッドに IP アドレスを割り当てることができるようになります。 その後、このポッドは他のデバイスと同様に Azure Virtual Network での通信が可能になります。 別のポッドに接続することも、ExpressRoute または VPN を使用してピアリングされたネットワークまたはオンプレミスのネットワークに接続することも、Private Link を使用して別の Azure サービスに接続することもできます。

IP アドレスの計画に関連しており、AKS ベースライン アーキテクチャに関する記事で提供されているすべてのガイダンスがここで適用されます。追加の推奨事項として、ドメイン コントローラー用の専用サブネットのプロビジョニングをご検討ください。 Windows ノード プールに関しては、別のサブネットを使用して他のノード プールから論理的に分離することをお勧めします。

ノード プールのアップグレード

Windows をアップグレードするプロセスは、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」のドキュメントで提供されているガイダンスから変更はありませんが、アップグレードの頻度を計画するために、スケジュールに関する次の違いを考慮する必要があります。

Microsoft は、毎月ノードに新しい Windows Server イメージ (最新のパッチを含む) を提供しており、自動修正プログラムや更新プログラムは実行しません。 そのため、このスケジュールに従ってノードを手動またはプログラムで更新する必要があります。 GitHub Actions を使用して、スケジュールに従って実行される cron ジョブを作成すると、毎月のアップグレードをプログラムでスケジュールできます。 上記のリンク先のドキュメントに記載されているガイダンスには Linux ノード プロセスが反映されていますが、YAML ファイルを更新して、2 週間ではなく毎月実行するように cron スケジュールを設定できます。 また、最新の Windows Server イメージにアップグレードするために、YAML ファイルの "runs-on" パラメーターを "windows-latest" に変更する必要もあります。

追加のガイダンスについては、ワーカー ノードへのパッチ適用と更新に関する AKS オペレーターのガイドをご覧ください。

コンピューティングに関する考慮事項

Windows サーバーベースのイメージに関連付けられているイメージ サイズが大きいほど、ノード プールに適切なサイズの OS ディスクをデプロイする必要があります。 Windows を含むすべてのノードでエフェメラル OS ディスクを使用することをお勧めします。そのため、デプロイを計画するときに従う必要があるサイズ要件を必ず理解するようにしてください。

ID 管理

Windows コンテナーをドメインに参加させることはできないため、Active Directory の認証と承認が必要な場合は、グループ管理サービス アカウント (gMSA) を使用できます。 gMSA を使用するには、Windows ノードを実行している AKS クラスターで gMSA プロファイルを有効にする必要があります。 アーキテクチャの完全なレビューとプロファイルの有効化に関するガイドについては、gMSA AKS のドキュメントをご覧ください。

ノードとポッドのスケーリング

クラスター オートスケーラーのガイダンスは、Windows コンテナーでは変更されません。 ガイダンスについては、「クラスター オートスケーラー」のドキュメントをご覧ください。

ベースライン クラスターのドキュメントでは、ポッドのスケーリングに使用できる手動および自動スケーリングのアプローチについて説明します。 どちらの方法も、Windows コンテナーを実行しているクラスターで使用できます。その記事で提供されているガイダンスは、一般にここでも適用されます。

ポッドのスケーリング操作に関して Linux コンテナーと Windows コンテナーで異なる点は、ほとんどの場合、イメージのサイズです。 Windows コンテナーのイメージ サイズが大きいほど、スケーリング操作が完了するまでの時間が長くなる可能性があるため、スケーリング アプローチに関するいくつかの考慮事項を考慮する必要があります。 このシナリオは、.NET ランタイムのサイズのため、レガシ .NET アプリケーションで一般的です。 スケーリング時間中にイメージのプルダウンにおける遅延を軽減するために、DaemonSet を使用して ACR からイメージをプルダウンし、すべての Windows ノードにキャッシュし、イメージを事前に読み込んでポッドを起動できます。 その時点から、ポッドは、オンラインになる前に、ワークロード用に定義されたアプリ構成プロセスを実行するだけで済みます。

スケーリング操作の実行による時間の影響を理解するためにベンチマーク演習を実行する必要があり、このデータはビジネス要件と比較して検討する必要があります。 ワークロードを自動スケーリングによって可能であるよりも高速にスケーリングする必要がある場合は、次の代替の "ホット スペア" ソリューションを検討することをお勧めします:

最初にベースライン テストを実施して、ピーク時とピーク時以外の読み込み時間で実行する必要があるポッドの数を特定する必要があります。 このベースラインを確立すると、ノード数を計画して、特定の時点で使用可能にする必要があるノードの合計数を考慮できます。 このソリューションでは、クラスターの手動スケーリングを使用し、ノードの初期数を必要なオフピーク数に設定します。 ピーク期間に近づくと、ノードのピーク読み込み時間数に事前にスケーリングする必要があります。 時間が経つに従って、アプリの使用状況やその他のビジネス要件を変更するために、ベースラインを定期的に再確立する必要があります。

監視

Windows を実行しているコンテナーは、Linux コンテナーと同様に、Azure Monitor と Container Insights を使用して監視できます。 そのため、AKS ベースラインに関する記事に記載されているガイダンスは、ほとんどの部分にも当てはまります。 ただし、Windows Server クラスターの Container Insights の監視には、次の制限があります:

• Windows にはメモリ RSS メトリックがありません。 そのため、Windows のノードとコンテナーでは利用できません。 ワーキング セット メトリックは使用できます
• Windows ノードではディスク ストレージ容量の情報を使用できません。

データ収集ルールを使用して Windows Server システムからイベントとパフォーマンス カウンターを収集することで、Container Insights を補完することもできます。

ポリシー管理

AKS ベースラインに関する記事に記載されているすべてのポリシー ガイダンスは、Windows ワークロードに適用されます。 さらに、「Azure Kubernetes Service 用の Azure Policy 組み込み定義」の参照記事に記載されている Windows 固有の次のポリシーを考慮する必要があります:

• Kubernetes クラスターの Windows コンテナーでは CPU とメモリをオーバーコミットすることができない
• Kubernetes クラスターの Windows コンテナーを ContainerAdministrator として実行することはできない
• Kubernetes クラスター Windows コンテナーは、承認されたユーザーとドメイン ユーザー グループでのみ実行する必要がある

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

AKS ベースラインに関する記事で提供されているクラスターのブートストラップ ガイダンスと同様に、クラスター オペレーターは Windows ベースのワークロードに対するブートストラップ アプローチも考慮する必要があります。 AKS ベースラインに関する記事で提供されているのと同じガイダンスは、ここでも適用されます。

コスト管理

AKS ベースラインに関する記事に記載されている、コスト最適化に関するすべてのガイダンスが Windows ワークロードに適用されます。 考慮する必要があるその他のコストに関する考慮事項は、次のとおりです:

• Windows Server のライセンス コストにより、AKS クラスターのノードのコストが増加します。 この要因のコスト最適化に関する推奨事項には、容量の予約や、既存のライセンスの使用 (他のビジネス用途に既にライセンスがある場合) が含まれます。
  • ソフトウェア アシュアランス (SA) に適用される Windows Server ライセンスの割引については、「Windows Server 向け Azure ハイブリッド特典」(AHUB) のドキュメントをご覧ください。
  • 新規および既存のクラスターに特典を適用する手順については、Windows Server コンテナーに関する FAQ をご覧ください。
• Windows コンテナー イメージのサイズでは、複数のイメージに必要なストレージの量、ACR からプルする同時実行ノードの数、geo レプリケーションの要件により、追加の Azure Container Registry (ACR) コストが発生する可能性があります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Isabelle Bersano | クラウド ソリューション アーキテクト
• Akshay Nimbalkar | プリンシパル クラウド ソリューション アーキテクト
• Clayton Siemens | プリンシパル コンテンツ開発者

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• Windows コンテナーの詳細

関連リソース

• AKS クラスターに Windows ノード プールをデプロイする方法の詳細