次の方法で共有

AKS のレガシ Container Networking Interface (CNI)

  • [アーティクル]

Azure Kubernetes Service (AKS) では、Azure CNI オーバーレイと Azure CNI ポッド サブネットがほとんどのシナリオで推奨されますが、Azure CNI ノード サブネットや kubenet などのレガシ ネットワーク モデルも引き続き使用でき、サポートされています。 これらのレガシ モデルでは、ポッドの IP アドレス管理とネットワークに対して異なるアプローチが提供され、それぞれに固有の機能セットと考慮事項があります。 この記事では、それらの役割と、AKS クラスター内でのそれらの効果的な使用方法を理解できるよう、これらのレガシ ネットワーク オプションの概要と、その前提条件、デプロイ パラメーター、重要な特性の詳細について説明します。

前提条件

Azure CNI ノード サブネットと kubenet には、次の前提条件が必要です。

  • AKS クラスターの仮想ネットワークでは、送信インターネット接続を許可する必要があります。

  • AKS クラスターでは、Kubernetes サービスのアドレス範囲、ポッド アドレス範囲、またはクラスターの仮想ネットワーク アドレス範囲に 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、192.0.2.0/24 を使用することはできません。

  • AKS クラスターによって使われるクラスター ID には、少なくとも、仮想ネットワーク内のサブネットに対するネットワーク共同作成者のアクセス許可が必要です。 組み込みのネットワーク共同作成者ロールを使う代わりに、カスタム ロールを定義する場合は、次のアクセス許可が必要です。

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write

  • AKS ノード プールに割り当てられたサブネットを委任されたサブネットにすることはできません。

  • AKS では Network Security Groups (NSG) がそのサブネットに適用されず、そのサブネットに関連付けられている NSG が変更されることもありません。 独自のサブネットを指定し、そのサブネットに関連付けられている NSG を追加する場合は、NSG のセキュリティ規則で、ノードの CIDR 範囲内のトラフィックが許可されていることを確認します。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

Note

kubenet は Windows Server コンテナーには使用できません。 Windows Server ノード プールを使うには、Azure CNI を使う必要があります。

Azure CNI ノード サブネット

Azure Container Networking Interface (CNI) では、すべてのポッドにサブネットから IP アドレスが割り当てられ、すべてのポッドに直接アクセスできます。 AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、事前に計画する必要があります。 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。 ノードごとにそれと同じ数の IP アドレスが、そのノードに対して事前に予約されます。 この方法では詳細な計画が必要であり、多くの場合、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでのクラスターの再構築が必要になります。

Azure CNI ノード サブネットを使うと、各ポッドは IP サブネット内の IP アドレスを受け取り、他のポッドやサービスと直接通信できます。 クラスターは、ユーザーが指定する IP アドレスの範囲まで拡大できます。 ただし、IP アドレスの範囲を事前に計画する必要があり、すべての IP アドレスは、ノードでサポートできるポッドの最大数に基づいて AKS ノードによって消費されます。 Azure CNI では、仮想ノードやネットワーク ポリシー (Azure または Calico) などの高度なネットワーク機能とシナリオがサポートされています。

展開のパラメーター

AKS クラスターを作成するときに、Azure CNI ネットワーク用に以下のパラメーターを構成できます。

仮想ネットワーク:Kubernetes クラスターをデプロイする仮想ネットワーク。 新しい仮想ネットワークを作ることも、既存のものを使うこともできます。 既存の仮想ネットワークを使う場合は、その場所と Azure サブスクリプションが Kubernetes クラスターと同じであることを確認します。 Azure 仮想ネットワークの制限とクォータについては、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

サブネット:クラスターをデプロイする仮想ネットワーク内のサブネット。 クラスター作成プロセスの間に、仮想ネットワークに新しいサブネットを追加できます。 ハイブリッド接続する場合、ご使用の環境のその他の仮想ネットワークのアドレス範囲と重複しないようにする必要があります。

Azure ネットワーク プラグイン: Azure ネットワーク プラグインが使用されている場合、"externalTrafficPolicy=Local" が指定されている内部 LoadBalancer サービスには、AKS クラスターに属さない clusterCIDR の IP を持つ VM からアクセスすることはできません。

Kubernetes サービスのアドレス範囲: このパラメーターは、Kubernetes によってクラスターの内部サービスに割り当てられる仮想 IP のセットです。 クラスターの作成後は、この範囲を更新することはできません。 次の要件を満たす任意のプライベート アドレス範囲を使用できます。

  • クラスターの仮想ネットワークの IP アドレス範囲に含まれていてはなりません。
  • クラスターの仮想ネットワークがピアリングしている他の仮想ネットワークと重複していてはなりません。
  • オンプレミスのどの IP アドレスとも重複していてはなりません。
  • 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、または 192.0.2.0/24 の範囲内にあってはなりません。

クラスターと同じ仮想ネットワーク内のサービス アドレス範囲を指定することはできますが、お勧めしません。 IP 範囲が重複すると、予期しない動作が発生する可能性があります。 詳細については、FAQ をご覧ください。 Kubernetes サービスについて詳しくは、Kubernetes ドキュメントの「Services」(サービス) をご覧ください。

[Kubernetes DNS service IP address](Kubernetes DNS サービスの IP アドレス): クラスターの DNS サービスの IP アドレス。 [Kubernetes service address range](Kubernetes サービス アドレスの範囲) 内に含まれるアドレスを指定する必要があります。 アドレス範囲内の最初の IP アドレスは使用しないでください。 サブネット範囲の最初のアドレスは、kubernetes.default.svc.cluster.local アドレスに使用されます。

Kubenet

AKS クラスターでは kubenet が使用され、Azure 仮想ネットワークとサブネットが既定で自動的に作成されます。 kubenet を使用すると、ノードでは Azure 仮想ネットワーク サブネットから IP アドレスが取得されます。 ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。 その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。 トラフィックの発信元 IP アドレスは、ノードのプライマリ IP アドレスに NAT 変換されます。 この方法では、ポッドで使用するためにネットワーク空間で予約する必要がある IP アドレスの数が大幅に減ります。

クラスターの作成時、または新しいノード プールを作成するときに、ノードに展開できる最大ポッド数を構成できます。 新しいノード プールを作成するときに maxPods を指定しない場合は、kubenet の既定値 110 を受け取ります。

独自のサブネットでの kubenet ネットワークの概要

多くの環境では、割り当て済みの IP アドレス範囲を使用して仮想ネットワークとサブネットを定義しています。これらのリソースを使用して複数のサービスとアプリケーションをサポートします。 ネットワーク接続を提供するため、AKS クラスターでは kubenet (基本的なネットワーク) または Azure CNI ("高度なネットワーク) を使用できます。

kubenet では、ノードだけが仮想ネットワーク サブネットの IP アドレスを受け取ります。 ポッドが相互に直接通信することはできません。 代わりに、複数のノードにまたがるポッド間の接続は、ユーザー定義ルーティング (UDR) と IP 転送で処理されます。 既定では、UDR と IP 転送の構成は AKS サービスによって作成および保守されますが、必要に応じてカスタム ルート管理用に独自のルート テーブルを用意することができます。 割り当て済み IP アドレスを受け取ってアプリケーションに対するトラフィックを負荷分散するサービスの背後に、ポッドをデプロイすることもできます。 次の図では、ポッドではなく AKS ノードが仮想ネットワーク サブネットの IP アドレスを受け取る方法を示します。

それぞれ 3 つのポッドを持つ 2 つのノードがオーバーレイ ネットワークで動作していることを示すダイアグラム。クラスター外エンドポイントへのポッド トラフィックは、NAT 経由でルーティングされます。

Azure でサポートされる UDR のルート数は最大 400 なので、AKS クラスターに 400 個より多くのノードを作成することはできません。 AKS 仮想ノードや Azure ネットワーク ポリシーは、kubenet ではサポートされていません。 Calico ネットワーク ポリシーはサポートされています。

kubenet に関する制限と考慮事項

Note

クラスター内の konnectivity などの一部のシステム ポッドでは、オーバーレイ アドレス空間からの IP ではなくホスト ノードの IP アドレスが使用されます。 システム ポッドはノード IP のみを使用し、仮想ネットワークの IP アドレスは使用しません。

IP アドレスの使用可能性と不足

Azure CNI でよくある問題は、割り当てられている IP アドレス範囲が小さすぎて、クラスターをスケーリングまたはアップグレードするときにノードを追加できないことです。 ネットワーク チームが、予想されるアプリケーションの需要をサポートするのに十分な大きさの IP アドレス範囲を発行できないこともあります。 妥協案として、kubenet を使用する AKS クラスターを作成し、既存の仮想ネットワーク サブネットに接続することができます。 この方法では、ノードは定義済みの IP アドレスを受け取ることができ、クラスター内で実行される可能性のある任意のポッド用に多数の IP アドレスを事前に予約する必要はありません。

kubenet では、はるかに小さい IP アドレス範囲を使用し、大きなクラスターやアプリケーションの需要をサポートできます。 たとえば、お使いのサブネットの /27 の IP アドレス範囲で、20 から 25 ノードのクラスターを実行し、スケーリングやアップグレードのための十分な余裕を確保できます。 このクラスター サイズでは、最大で 2,200 ～ 2,750 個のポッドをサポートできます (既定では、ノードあたり最大 110 ポッド)。 AKS において kubenet で構成できるノードあたりの最大ポッド数は 250 です。

次の基本的な計算では、ネットワーク モデルの違いを比較します。

  • kubenet: 単純な /24 の IP アドレス範囲で、クラスター内の最大 251 個のノードをサポートできます。 各 Azure 仮想ネットワーク サブネットでは、最初の 3 つの IP アドレスが管理操作用に予約されます。 このノード数では、最大で 27,610 個のポッドをサポートできます (既定では、ノードあたり最大 110 ポッド)。
  • Azure CNI: その同じ基本的な /24 サブネット範囲では、クラスター内の最大 8 ノードしかサポートできません 既定ではノードあたり最大 30 ポッドなので、このノード数では最大で 240 個のポッドしかサポートできません。

Note

これらの最大値では、アップグレードまたはスケーリング操作は考慮されていません。 実際には、サブネットの IP アドレス範囲でサポートされる最大数のノードを実行することはできません。 スケーリングまたはアップグレード操作に使用できるように、一部の IP アドレスを残しておく必要があります。

仮想ネットワーク ピアリングと ExpressRoute 接続

Azure 仮想ネットワーク ピアリングまたは ExpressRoute 接続を、Azure CNI および kubenet と共に使って、オンプレミス接続を提供できます。 重複および正しくないトラフィック ルーティングが発生しないよう、慎重に IP アドレスを計画してください。 たとえば、多くのオンプレミス ネットワークでは、ExpressRoute 接続経由でアドバタイズされる 10.0.0.0/8 のアドレス範囲が使用されます。 このアドレス範囲外の Azure 仮想ネットワーク サブネット (172.16.0.0/16 など) に、AKS クラスターを作成することをお勧めします。

詳しくは、ネットワーク モデルとそのサポート範囲の比較に関する記事をご覧ください。

Azure CNI ポッド サブネットに関してよくあるご質問

  • クラスター サブネットに VM を展開できますか。

    はい。Azure CNI ノード サブネットの場合、AKS クラスターと同じサブネットに VM をデプロイできます。

  • Azure CNI 対応ポッドで発生したトラフィックに対して、外部システムではどのソース IP が認識されますか。

    AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 ただし、Azure CNI の動的 IP 割り当てについては、接続が同じ仮想ネットワーク内でも、仮想ネットワークをまたいでも、ポッドの IP は常に、ポッドからのトラフィックのソース アドレスになります。 これは、動的 IP 割り当てのための Azure CNI では、Microsoft Azure Container Networking インフラストラクチャが実装され、このインフラストラクチャからはエンドツーエンド エクスペリエンスが与えられるためです。 そのため、従来の Azure CNI でまだ使用されている ip-masq-agent を使用する必要がなくなります。

  • ポッドごとのネットワーク ポリシーを構成できますか。

    はい、Kubernetes ネットワーク ポリシーは AKS で使用できます。 開始するには、AKS でネットワーク ポリシーを使用してポッド間のトラフィックをセキュリティで保護する方法に関する記事を参照してください。

  • ノードに展開できるポッドの最大数は構成できますか。

    既定では、AKS クラスターでは kubenet を使って、仮想ネットワークとサブネットが作成されます。 kubenet を使用すると、ノードでは仮想ネットワーク サブネットから IP アドレスが取得されます。 その後、ノードにネットワーク アドレス変換 (NAT) が構成されて、ポッドはノードの IP の背後に "隠ぺいされた" IP アドレスを受け取ります。 この方法では、ポッド用にネットワーク空間で予約する必要がある IP アドレスの数が減ります。

    Azure Container Networking Interface (CNI) では、すべてのポッドにサブネットから IP アドレスが割り当てられ、すべてのポッドに直接アクセスできます。 AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、事前に計画する必要があります。 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。 ノードごとにそれと同じ数の IP アドレスが、そのノードに対して事前に予約されます。 この方法では詳細な計画が必要であり、多くの場合、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでのクラスターの再構築が必要になります。

  • クラスター サブネットに VM を展開できますか。

    はい。 ただし、動的 IP 割り当てのための Azure CNI については、ポッドのサブネットには VM をデプロイできません。

  • Azure CNI 対応ポッドで発生したトラフィックに対して、外部システムではどのソース IP が認識されますか。

    AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。 AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。

    ただし、動的 IP 割り当てのための Azure CNI については、接続が同じ仮想ネットワーク内にあっても、仮想ネットワークを超えても関係なく、ポッドの IP は常に、ポッドからのトラフィックのソース アドレスになります。 これは、動的 IP 割り当てのための Azure CNI では、Microsoft Azure Container Networking インフラストラクチャが実装され、このインフラストラクチャからはエンドツーエンド エクスペリエンスが与えられるためです。 そのため、従来の Azure CNI でまだ使用されている ip-masq-agent を使用する必要がなくなります。

  • "Kubernetes サービスのアドレス範囲" のクラスター仮想ネットワーク内で別のサブネットを使用できますか。

    お勧めはしませんが、この構成は可能です。 サービスのアドレス範囲は、Kubernetes によってクラスターの内部サービスに割り当てられる仮想 IP (VIP) のセットです。 Azure のネットワークには、Kubernetes クラスターのサービスの IP 範囲の可視性がありません。 クラスターのサービス アドレス範囲を可視化できないと、問題が発生する可能性があります。 後でクラスターの仮想ネットワークにサービスのアドレス範囲と重複する新しいサブネットが作成される可能性があります。 このような重複が発生した場合、Kubernetes は、サブネット内の他のリソースによって既に使用されている IP をサービスに割り当てる可能性があり、予期しない動作やエラーの原因となります。 クラスターの仮想ネットワークの外部のアドレス範囲を使用することで、この重複のリスクを回避できます。 はい。Azure CLI または Resource Manager テンプレートを使用してクラスターをデプロイするときに構成することができます。 「ノードごとの最大ポッド数」を参照してください。

  • "Kubernetes サービスのアドレス範囲" のクラスター仮想ネットワーク内で別のサブネットを使用できますか。

    お勧めはしませんが、この構成は可能です。 サービスのアドレス範囲は、Kubernetes によってクラスターの内部サービスに割り当てられる仮想 IP (VIP) のセットです。 Azure のネットワークには、Kubernetes クラスターのサービスの IP 範囲の可視性がありません。 クラスターのサービス アドレス範囲を可視化できないと、問題が発生する可能性があります。 後でクラスターの仮想ネットワークにサービスのアドレス範囲と重複する新しいサブネットが作成される可能性があります。 このような重複が発生した場合、Kubernetes は、サブネット内の他のリソースによって既に使用されている IP をサービスに割り当てる可能性があり、予期しない動作やエラーの原因となります。 クラスターの仮想ネットワークの外部のアドレス範囲を使用することで、この重複のリスクを回避できます。