AKS のネットワーク トポロジと接続性に関する考慮事項

設計上の考慮事項

Azure Kubernetes Service (AKS) には、コンテナー ネットワーク用の 3 つの異なるネットワーク モデル (Kubenet、CNI オーバーレイ、CNI) が用意されています。 これらの各モデルには独自の機能と利点があり、AKS でのコンテナー ネットワークに柔軟性とスケーラビリティの選択肢が提供されます。

Kubenet

Kubenet は、IP アドレス空間を節約し、シンプルな構成を提供する、基本的なネットワーク ソリューションです。 ノード数が 400 未満の小規模な AKS クラスターで、ユーザー定義のルートを手動で管理および保守すれば十分な場合に最適です。 これは、クラスターの外部からポッドに到達するために内部または外部のロード バランサーで十分なシナリオに適しています。

Azure CNI

Azure CNI は、高度なネットワーク用に設計されたネットワーク モデルです。 ポッドに対して完全な仮想ネットワーク接続を提供し、ポッドからポッドへの接続とポッドから VM への接続を可能にします。 仮想ノードなどの高度な AKS 機能が必要なシナリオに最適です。 十分な IP アドレス空間が使用可能で、外部リソースがポッドに直接到達する必要があるシナリオに適しています。 Azure CNI では、AKS ネットワーク ポリシーもサポートされています。

Azure CNI オーバーレイ

Azure CNI オーバーレイは、IP アドレスの不足に対処し、ネットワーク構成を簡素化するように設計されています。 これは、ノードあたり最大 1000 個のノードと 250 個のポッドにスケールアップすれば十分であり、ポッド接続に追加のホップが許容されるシナリオに適しています。 Azure CNI オーバーレイでは、AKS エグレス要件を満たすこともできます。

ネットワーク モデルごとの推奨されるユース ケースの概要については、「AKS のネットワーク モデルを比較する」を参照してください。

さらに、AKS クラスターを設計するときは、スケーリングをサポートするために、仮想ネットワーク サブネットの IP アドレス指定とサイズを慎重に計画することが重要です。 仮想ノードは、クラスターの迅速なスケーリングに使用できますが、いくつかの既知の制限があります。

AKS クラスターでは Basic および Standard の Azure Load Balancer SKU がサポートされており、サービスはパブリック ロード バランサーまたは内部ロード バランサーで公開できます。 AKS は、クラスターで実行されているポッドに CoreDNS を使用して名前解決を提供します。送信 (エグレス) ネットワーク トラフィックは、Azure Firewall またはネットワーク仮想アプライアンス クラスターを介して送信できます。

既定では、AKS クラスター内のすべてのポッドは制限なしにトラフィックを送受信できます。 ただし、Kubernetes ネットワーク ポリシーを使用して、セキュリティを向上させ、AKS クラスター内のポッド間のネットワーク トラフィックをフィルター処理することができます。 AKS では、Azure ネットワーク ポリシーと Calico という 2 つのネットワーク ポリシー モデルを使用できます。

最後の点として、AKS により、クラスターがデプロイされているサブネット上にネットワーク セキュリティ グループ (NSG) が設定されます。 この NSG は手動で編集しないことをお勧めしますが、AKS にデプロイされたサービスがそれに影響を与えることがあります。

全体的には、適切なネットワーク モデルを選択し、ネットワーク リソースを慎重に計画すれば、AKS クラスターのパフォーマンス、セキュリティ、コストを最適化するのに役立ちます。

プライベート クラスター

AKS クラスター IP の可視性は、パブリックまたはプライベートにすることができます。 プライベート クラスターでは、プライベート IP アドレス経由で Kubernetes API が公開されますが、パブリック IP アドレス経由では公開されません。 このプライベート IP アドレスは、AKS 仮想ネットワークでプライベート エンドポイントを介して表されます。 Kubernetes API には、その IP アドレスを使用するのではなく、その完全修飾ドメイン名 (FQDN) によってアクセスする必要があります。 Kubernetes API FQDN からその IP アドレスへの解決は、通常、Azure プライベート DNS ゾーンによって実行されます。 この DNS ゾーンは、Azure によって AKS ノード リソース グループに作成することも、既存の DNS ゾーンを指定することもできます。

エンタープライズ規模の実証済みプラクティスに従って、Azure ワークロードの DNS 解決は、ハブ仮想ネットワークまたは Azure Virtual WAN に接続された共有サービス仮想ネットワーク内の、接続サブスクリプションにデプロイされた中央管理 DNS サーバーによって提供されます。 これらのサーバーにより、Azure DNS を使用して Azure 固有の名前とパブリック名 (IP アドレス 168.63.129.16) のほか、企業の DNS サーバーを使用してプライベート名が条件付きで解決されます。 ただし、これらの中央管理 DNS サーバーは、AKS クラスター用に作成された DNS プライベート ゾーンに接続されるまで、AKS API FQDN を解決できません。 ゾーン名の前にランダムな GUID が付加されるため、各 AKS には、一意の DNS プライベート ゾーンが使用されます。 そのため、新しい AKS クラスターごとに、その対応するプライベート DNS ゾーンを、中央 DNS サーバーが配置されている仮想ネットワークに接続する必要があります。

すべての仮想ネットワークで、名前解決にこれらの中央 DNS サーバーを使用するように構成する必要があります。 ただし、中央 DNS サーバーを使用するように AKS 仮想ネットワークが構成されていて、これらの DNS サーバーがプライベート DNS ゾーンにまだ接続されていない場合、AKS ノードで Kubernetes API の FQDN が解決されず、AKS クラスターの作成が失敗します。 クラスターの作成後にのみ、中央の DNS サーバーを使用するように、AKS 仮想ネットワークを構成する必要があります。

クラスターが作成されると、DNS プライベート ゾーンと、中央 DNS サーバーがデプロイされている仮想ネットワークの間に接続が作成されます。 AKS 仮想ネットワークも接続サブスクリプションの中央 DNS サーバーを使用するように構成され、AKS Kubernetes API への管理者アクセスは次のフローに従います。

Note

この記事の画像は、従来のハブ アンド スポーク接続モデルを使用した設計を反映しています。 エンタープライズ規模のランディング ゾーンでは、Virtual WAN 接続モデルを選択できます。このモデルでは、中央 DNS サーバーは、Virtual WAN ハブに接続されている共有サービス仮想ネットワークに配置されます。

1. 管理者が Kubernetes API の FQDN を解決します。 オンプレミスの DNS サーバーでは、権限のあるサーバー (Azure の DNS リゾルバー) に要求が転送されます。 これらのサーバーでは、Azure DNS サーバー (168.63.129.16) に要求が転送されます。これにより、Azure プライベート DNS ゾーンから IP アドレスが取得されます。
2. IP アドレスの解決後、接続モデルに応じて、Kubernetes API へのトラフィックがオンプレミスから Azure の VPN または ExpressRoute ゲートウェイにルーティングされます。
3. プライベート エンドポイントによって、ハブ仮想ネットワークに /32 ルートが導入されます。 VPN および ExpressRoute ゲートウェイは、AKS 仮想ネットワークにデプロイされた Kubernetes API プライベート エンドポイントにトラフィックを直接送信します。

アプリケーション ユーザーからクラスターへのトラフィック

受信 (イングレス) コントローラーを使用して、AKS クラスターで実行されているアプリケーションを公開できます。

• イングレス コントローラーでは、わずかな複雑さの増加を犠牲にして、アプリケーションレベルのルーティングが提供されます。
• イングレス コントローラーには、Web アプリケーション ファイアウォール (WAF) 機能を組み込むことができます。
• イングレス コントローラーは、クラスター外およびクラスター内で実行できます。
  • クラスター外のイングレス コントローラーによって、コンピューティング (HTTP トラフィックのルーティングや TLS 終端など) を、Azure Application Gateway イングレス コントローラー (AGIC) アドオンのような AKS の外部の別のサービスにオフロードします。
  • クラスター内ソリューションでは、コンピューティング (HTTP トラフィックのルーティングや TLS 終端など) に AKS クラスター リソースが使用されます。 クラスター内イングレス コントローラーでは、コストを低く抑えることができますが、慎重なリソース計画とメンテナンスが必要になります。
• 基本の HTTP アプリケーション ルーティング アドオンは簡単に使えますが、「HTTP アプリケーション ルーティング」に記載されているように、いくつかの制限があります。

イングレス コントローラーでは、パブリックまたはプライベート IP アドレスでアプリケーションと API を公開できます。

• 構成をエグレス フィルター処理設計に合わせて、非対称ルーティングを回避する必要があります。 UDR は、非対称ルーティングを (場合によっては) 引き起こすことがありますが、必ずしもそうなるとは限りません。 Application Gateway はトラフィックに対して SNAT を行うことができます。つまり、UDR がインターネット トラフィックに対してのみ設定されている場合、戻りトラフィックは UDR ルートではなく Application Gateway ノードに戻ります。
• TLS 終端が必要な場合は、TLS 証明書の管理を考慮する必要があります。

アプリケーション トラフィックは、オンプレミスまたはパブリック インターネットから送信されてくる可能性があります。 次の図は、オンプレミスとパブリック インターネットの両方からクラスターへのリバースプロキシ接続を行うように Azure Application Gateway が構成されている例を示しています。

オンプレミスからのトラフィックは、前の図の番号付きの青い吹き出しのフローに従います。

1. クライアントでは、接続サブスクリプションにデプロイされた DNS サーバーまたはオンプレミス DNS サーバーを使用して、アプリケーションに割り当てられた FQDN が解決されます。
2. アプリケーションの FQDN が IP アドレス (アプリケーション ゲートウェイのプライベート IP アドレス) に解決されると、トラフィックは VPN または ExpressRoute ゲートウェイ経由でルーティングされます。
3. ゲートウェイ サブネットのルーティングは、要求を Web アプリケーション ファイアウォールに送信するように構成されます。
4. Web アプリケーション ファイアウォールにより、有効な要求が AKS クラスターで実行されているワークロードに送信されます。

この例の Azure Application Gateway は、AKS クラスターと同じサブスクリプションにデプロイできます。これは、その構成が AKS にデプロイされたワークロードと密接に関連しているため、同じアプリケーション チームによって管理されるからです。 インターネットからのアクセスは、前の図の番号付きの緑色の吹き出しのフローに従います。

1. パブリック インターネットからのクライアントでは、Azure Traffic Manager を使用してアプリケーションの DNS 名が解決されます。 または、Azure Front Door のような他のグローバル負荷分散テクノロジを使用することもできます。
2. アプリケーションのパブリック FQDN は、Traffic Manager によって、クライアントがパブリック インターネット経由でアクセスするアプリケーション ゲートウェイのパブリック IP アドレスに解決されます。
3. アプリケーション ゲートウェイによって、AKS にデプロイされたワークロードがアクセスされます。

Note

これらのフローは、Web アプリケーションにのみ有効です。 非 Web アプリケーションはこの記事の範囲外であり、ハブ仮想ネットワーク内の Azure Firewall、または仮想 WAN 接続モデルを使用している場合はセキュリティで保護された仮想ハブ経由で公開できます。

または、接続サブスクリプション内の Azure Firewall と AKS 仮想ネットワーク内の WAF の両方を走査する Web ベースのアプリケーションのトラフィック フローを作成することもできます。 このアプローチには、Azure Firewall インテリジェンスベースのフィルター処理を使用して、インターネットの既知の悪意のある IP アドレスからのトラフィックを削除するなど、追加の保護を提供する利点があります。 ただし、いくつの欠点もあります。 たとえば、元のクライアント IP アドレスの損失や、アプリケーションを公開するときにファイアウォールとアプリケーション チームの間で追加の調整が必要になります。 これは、Azure Firewall で、宛先ネットワーク アドレス変換 (DNAT) 規則が必要になるためです。

AKS ポッドからバックエンド サービスへのトラフィック

AKS クラスターの内部で実行されているポッドで、Azure Storage、Azure SQL データベース、Azure Cosmos DB NoSQL データベースなどのバックエンド サービスにアクセスする必要がある場合があります。 仮想ネットワーク サービス エンドポイントと Private Link を使用して、これらの Azure マネージド サービスへの接続をセキュリティで保護することができます。

バックエンド トラフィックに Azure プライベート エンドポイントを使用している場合は、Azure プライベート DNS ゾーンを使用して Azure サービスの DNS 解決を実行できます。 環境全体の DNS リゾルバーはハブ仮想ネットワーク (または、Virtual WAN 接続モデルを使用している場合は共有サービス仮想ネットワーク) 内にあるため、これらのプライベート ゾーンは接続サブスクリプションに作成する必要があります。 プライベート サービスの FQDN を解決するために必要な A レコードを作成するには、プライベート DNS ゾーン (接続サブスクリプション内) をプライベート エンドポイント (アプリケーション サブスクリプション内) に関連付けることができます。 この操作では、それらのサブスクリプションで特定の権限が必要です。

A レコードを手動で作成することはできますが、プライベート DNS ゾーンをプライベート エンドポイントに関連付けると、セットアップで誤った構成になる可能性が低くなります。

プライベート エンドポイント経由で公開される AKS ポッドから Azure PaaS サービスへのバックエンド接続は、次のシーケンスに従います。

1. AKS ポッドでは、AKS 仮想ネットワークでカスタム DNS サーバーとして定義されている、接続サブスクリプション内の中央 DNS サーバーを使用して、Azure サービスとしてのプラットフォーム (PaaS) の FQDN が解決されます。
2. 解決された IP は、プライベート エンドポイントのプライベート IP アドレスであり、AKS ポッドから直接アクセスされます。

AKS クラスターが Azure Firewall によるエグレス フィルター処理用に構成されている場合でも、AKS ポッドとプライベート エンドポイント間のトラフィックは、既定で、ハブ仮想ネットワーク (または Virtual WAN を使用する場合はセキュリティで保護された仮想ハブ) 内の Azure Firewall を通過しません。 その理由は、プライベート エンドポイントによって、AKS がデプロイされているアプリケーション仮想ネットワークのサブネットに /32 ルートが作成されるためです。

設計の推奨事項

• セキュリティ ポリシーで、プライベート IP アドレス (パブリック IP アドレスではなく) で Kubernetes API を使用することが必須とされている場合は、プライベート AKS クラスターをデプロイします。
  • プライベート クラスターの作成時に、作成プロセスでシステム プライベート DNS ゾーンを使用させるのではなく、カスタム プライベート DNS ゾーンを使用します。
• AKS クラスターに割り当てることができる IP アドレスの範囲が限られている場合を除き、ネットワーク モデルとして Azure Container Networking Interface (CNI) を使用します。
  • CNI を使用した IP アドレス計画に関するドキュメントに従ってください。
  • Windows Server ノード プールと仮想ノードを使用して最終的な制限を確認するには、Windows AKS のサポート FAQ に関する記事を参照してください。
• AKS クラスターで使用する仮想ネットワークを保護するには、一元化されたサブスクリプションで Azure Firewall または WAF を使用する場合を除き、Azure DDoS Protection を使用します。
• Azure Virtual WAN またはハブ アンド スポーク アーキテクチャ、Azure DNS ゾーン、独自の DNS インフラストラクチャによる全体的なネットワーク設定にリンクされた DNS 構成を使用します。
• Private Link を使用してネットワーク接続をセキュリティで保護し、Private Link をサポートする他のマネージド Azure サービス (Azure Storage、Azure Container Registry、Azure SQL Database、Azure Key Vault など) にプライベート IP ベースの接続を使用します。
• イングレス コントローラーを使用して、高度な HTTP ルーティングとセキュリティを提供し、アプリケーションに単一のエンドポイントを提供します。
• イングレスを使用するように構成されている Web アプリケーションは、すべて TLS 暗号化を使用する必要があります。暗号化されていない HTTP を使用したアクセスは許可されません。 エンタープライズ規模のランディング ゾーンの参照の実装に含まれるポリシーで推奨されているポリシーがサブスクリプションに含まれている場合、このポリシーは既に適用されています。
• 必要に応じて、AKS クラスターのコンピューティングおよびストレージのリソースを節約するために、クラスター外のイングレス コントローラーを使用します。
  • Azure Application Gateway イングレス コントローラー (AGIC) アドオンを使用します。これは、ファーストパーティ マネージド Azure サービスです。
  • AGIC では、AKS クラスターごとに専用の Azure Application Gateway をデプロイし、複数の AKS クラスターで同じ Application Gateway を共有しないでください。
  • リソースまたは操作上の制約がない場合、または AGIC が必要な機能を提供していない場合は、NGINX、Traefik、またはその他の Kubernetes でサポートされている任意のソリューションなどのクラスター内イングレス コントローラー ソリューションを使用します。
• インターネットに接続され、セキュリティが重要な内部 Web アプリケーションの場合は、イングレス コントローラーを備えた Web アプリケーション ファイアウォールを使用します。
  • Azure Application Gateway と Azure Front Door にはどちらも、Web ベースのアプリケーションを保護するための Azure Web Application Firewall が統合されています。
• AKS クラスターで生成されるすべての送信インターネット トラフィックの検査がセキュリティ ポリシーで義務付けられている場合は、Azure Firewall、またはマネージド ハブ仮想ネットワークにデプロイされたサードパーティのネットワーク仮想アプライアンス (NVA) を使用して、エグレス ネットワーク トラフィックをセキュリティ保護します。 詳細については、エグレス トラフィックの制限に関するページを参照してください。 AKS の送信の種類 UDR では、ルート テーブルを AKS ノード サブネットに関連付ける必要があります。そのため、現在、Azure Virtual WAN または Azure Route Server でサポートされている動的ルート インジェクションでは使用できません。
• 非プライベート クラスターでは、許可された IP 範囲を使用します。
• Azure Load Balancer の Basic レベルではなく、Standard レベルを使用します。
• Azure で Kubernetes クラスターを設計する場合、重要な考慮事項の 1 つは、特定の要件に適したネットワーク モデルを選択することです。 Azure Kubernetes Service (AKS) には、Kubenet、Azure CNI、Azure CNI オーバーレイという 3 つの異なるネットワーク モデルが用意されています。 情報に基づいた意思決定を行うには、各モデルの機能と特性を理解することが不可欠です。

AKS の 3 つのネットワーク モデル (Kubenet、Azure CNI、Azure CNI オーバーレイ) の機能比較については、「AKS のネットワーク モデルを比較する」を参照してください。