Kubernetes では、Kubernetes クラスターのネットワークを管理するために Container Networking Interface (CNI) プラグインが使用されます。 CNI には、ポッドへの IP アドレスの割り当て、ポッド間のネットワーク ルーティング、Kubernetes Service ルーティングなどの役割があります。
AKS には、ネットワーク要件に応じてクラスターで使用できる複数の CNI プラグインが用意されています。
AKS のネットワーク モデル
AKS クラスターに対する CNI プラグインの選択は、ニーズに最も適したネットワーク モデルによって大きく異なります。 各モデルには、AKS クラスターを計画する際に考慮する必要がある長所と短所があります。
AKS uses two main networking models: overlay network and flat network.
どちらのネットワーク モデルでも、複数の CNI プラグイン オプションがサポートされています。 モデル間の主な違いは、ポッドの IP アドレスの割り当て方法と、トラフィックがクラスターから出る方法です。
Overlay networks
オーバーレイ ネットワークは、Kubernetes で使用される最も一般的なネットワーク モデルです。 オーバーレイ ネットワークでは、ポッドには、AKS ノードがデプロイされている Azure VNet サブネットから論理的に分離されたプライベート CIDR から IP アドレスが付与されます。 これにより、フラット ネットワーク モデルよりもシンプルになり、多くの場合、スケーラビリティが向上します。
オーバーレイ ネットワークでは、ポッドは互いに直接通信できます。 クラスターから出るトラフィックでは、ノードの IP アドレスへの送信元ネットワーク アドレス変換 (SNAT) が行われ、受信ポッドの IP トラフィックは、ロード バランサーなどの何らかのサービスを介してルーティングされます。 これは、ポッドの IP アドレスがノードの IP アドレスの背後に "隠れている" ことを意味します。 この方法では、クラスターに必要な VNet IP アドレスの数が減ります。
Azure Kubernetes Service では、オーバーレイ ネットワーク用の次の CNI プラグインが提供されます。
- Azure CNI オーバーレイ。ほとんどのシナリオで推奨される CNI プラグインです。
Flat networks
オーバーレイ ネットワークとは異なり、AKS のフラット ネットワーク モデルでは、AKS ノードと同じ Azure VNet のサブネットからポッドに IP アドレスが割り当てられます。 つまり、クラスターから出るトラフィックは SNAT されず、ポッドの IP アドレスはターゲットに直接公開されます。 これは、ポッドの IP アドレスを外部サービスに公開する必要がある場合など、一部のシナリオで役立ちます。
Azure Kubernetes Service には、フラット ネットワーク用の 2 つの CNI プラグインが用意されています。 この記事では、各プラグイン オプションの詳細については説明しません。 詳細については、リンクされたドキュメントを参照してください。
- Azure CNI ポッド サブネット。フラット ネットワーク シナリオに推奨される CNI プラグインです。
- Azure CNI ノード サブネット。レガシ フラット ネットワーク モデルの CNI では通常、クラスターのマネージド VNet が "必要" な場合にのみ使用することが推奨されます。
CNI の選択
CNI を選択するときに、考慮すべき要因がいくつかあります。 各ネットワーク モデルには長所と短所があり、クラスターに最適な選択は特定の要件によって異なります。
ネットワーク オプションの選択
AKS の 2 つの主要なネットワーク モデルは、オーバーレイ ネットワークとフラット ネットワークです。
Overlay networks:
- ポッドに対して論理的に分離された CIDR 範囲を使用して、VNet IP アドレス空間を節約します。
- 最大のクラスター スケールのサポート。
- シンプルな IP アドレス管理。
Flat networks:
- ポッドでは完全な VNet 接続が取得され、接続されているネットワークからプライベート IP アドレスを介して直接アクセスできます。
- 断片化されていない大きな VNet IP アドレス空間が必要です。
ユース ケースの比較
ネットワーク モデルを選択するときは、各 CNI プラグインのユース ケースと、使用されるネットワーク モデルの種類を考慮してください。
CNI plugin | Networking model | ユース ケースの特徴 |
---|---|---|
Azure CNI オーバーレイ | Overlay | - VNET IP 保護に最適 - API Server でサポートされる最大ノード数 + 250 ポッド/ノード - よりシンプルな構成 - 外部ポッドの直接 IP アクセスなし |
Azure CNI ポッド サブネット | Flat | - 外部ポッドの直接アクセス - Modes for efficient VNet IP usage or large cluster scale support(Preview) |
Kubenet (Legacy) | Overlay | - IP 保護が優先される - 制限付きスケール - 手動ルート管理 |
Azure CNI ノード サブネット (レガシ) | Flat | - 外部ポッドの直接アクセス - よりシンプルな構成 - 制限付きスケール - VNet IP の非効率的な使用 |
Feature comparison
各 CNI プラグインの機能を比較することもできます。 次の表は、各 CNI プラグインでサポートされる機能を大まかに比較したものです。
Feature | Azure CNI オーバーレイ | Azure CNI ポッド サブネット | Azure CNI ノード サブネット (レガシ) | Kubenet |
---|---|---|---|---|
既存または新しい VNet にクラスターをデプロイする | Supported | Supported | Supported | サポート対象 - 手動 UDR |
ポッドと VM の接続。同じまたはピアリングされた VNet 内の VM の場合 | Pod initiated | Both ways | Both ways | Pod initiated |
VPN/Express Route 経由のオンプレミス アクセス | Pod initiated | Both ways | Both ways | Pod initiated |
サービス エンドポイントへのアクセス | Supported | Supported | Supported | Supported |
ロード バランサーを使用してサービスを公開する | Supported | Supported | Supported | Supported |
App Gateway イングレス コントローラーを使用してサービスを公開する | Supported | Supported | Supported | Supported |
App Gateway for Containers を使用してサービスを公開する | Supported | Supported | Supported | Not Supported |
Windows ノード プール | Supported | Supported | Supported | Not supported |
既定の Azure DNS およびプライベート ゾーン | Supported | Supported | Supported | Supported |
複数のクラスター間での VNet サブネットの共有 | Supported | Supported | Supported | Not supported |
ネットワーク モデル間のサポート範囲
使用する CNI に応じて、クラスター仮想ネットワーク リソースは次のいずれかの方法でデプロイできます。
- Azure プラットフォームは、AKS クラスターを作成したときに自動的に仮想ネットワーク リソースを作成して構成することができます。 Azure CNI オーバーレイ、Azure CNI ノード サブネット、Kubenet と同様。
- 仮想ネットワーク リソースを手動で作成して構成し、AKS クラスターを作成するときにそれらのリソースにアタッチすることができます。
サービス エンドポイントや UDR のような機能はサポートされていますが、AKS のサポート ポリシーでは、どのような変更を行うことができるかが定義されます。 For example:
- AKS クラスターの仮想ネットワーク リソースを手動で作成する場合は、独自の UDR またはサービス エンドポイントを構成するときにサポートされます。
- Azure プラットフォームで AKS クラスター用の仮想ネットワーク リソースを自動的に作成する場合、それらの AKS 管理対象リソースを手動で変更して独自の UDR またはサービスエンドポイントを構成することはできません。
Prerequisites
AKS のネットワーク構成を計画するときに、留意すべきいくつかの要件と考慮事項があります。
- AKS クラスターの仮想ネットワークでは、送信インターネット接続を許可する必要があります。
- AKS クラスターでは、Kubernetes サービスのアドレス範囲、ポッド アドレス範囲、またはクラスターの仮想ネットワーク アドレス範囲に
169.254.0.0/16
、172.30.0.0/16
、172.31.0.0/16
、192.0.2.0/24
を使用することはできません。 - In BYO VNet scenarios, the cluster identity used by the AKS cluster must have at least Network Contributor permissions on the subnet within your virtual network. If you wish to define a custom role instead of using the built-in Network Contributor role, the following permissions are required:
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Authorization/roleAssignments/write
-
Microsoft.Network/virtualNetworks/subnets/read
(独自のサブネットとCIDRを定義する場合にのみ必要)
- The subnet assigned to the AKS node pool can't be a delegated subnet.
- AKS では Network Security Groups (NSG) がそのサブネットに適用されず、そのサブネットに関連付けられている NSG が変更されることもありません。 独自のサブネットを指定し、そのサブネットに関連付けられている NSG を追加する場合は、NSG のセキュリティ規則で、ノードの CIDR 範囲内のトラフィックが許可されていることを確認する必要があります。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。
Next Steps
Azure Kubernetes Service