Azure Kubernetes Service (AKS) CNI ネットワークの概要
Kubernetes では、Kubernetes クラスターのネットワークを管理するために Container Networking Interface (CNI) プラグインが使用されます。 CNI には、ポッドへの IP アドレスの割り当て、ポッド間のネットワーク ルーティング、Kubernetes Service ルーティングなどの役割があります。
AKS には、ネットワーク要件に応じてクラスターで使用できる複数の CNI プラグインが用意されています。
AKS のネットワーク モデル
AKS クラスターに対する CNI プラグインの選択は、ニーズに最も適したネットワーク モデルによって大きく異なります。 各モデルには、AKS クラスターを計画する際に考慮する必要がある長所と短所があります。
AKS では、オーバーレイ ネットワークとフラット ネットワークという 2 つの主要なネットワーク モデルが使用されます。
どちらのネットワーク モデルでも、複数の CNI プラグイン オプションがサポートされています。 モデル間の主な違いは、ポッドの IP アドレスの割り当て方法と、トラフィックがクラスターから出る方法です。
オーバーレイ ネットワーク
オーバーレイ ネットワークは、Kubernetes で使用される最も一般的なネットワーク モデルです。 オーバーレイ ネットワークでは、ポッドには、AKS ノードがデプロイされている Azure VNet サブネットから論理的に分離されたプライベート CIDR から IP アドレスが付与されます。 これにより、フラット ネットワーク モデルよりもシンプルになり、多くの場合、スケーラビリティが向上します。
オーバーレイ ネットワークでは、ポッドは互いに直接通信できます。 クラスターから出るトラフィックでは、ノードの IP アドレスへの送信元ネットワーク アドレス変換 (SNAT) が行われ、受信ポッドの IP トラフィックは、ロード バランサーなどの何らかのサービスを介してルーティングされます。 これは、ポッドの IP アドレスがノードの IP アドレスの背後に "隠れている" ことを意味します。 この方法では、クラスターに必要な VNet IP アドレスの数が減ります。
Azure Kubernetes Service では、オーバーレイ ネットワーク用の次の CNI プラグインが提供されます。
- Azure CNI オーバーレイ。ほとんどのシナリオで推奨される CNI プラグインです。
- kubenet。レガシ オーバーレイ モデルの CNI です。
フラット ネットワーク
オーバーレイ ネットワークとは異なり、AKS のフラット ネットワーク モデルでは、AKS ノードと同じ Azure VNet のサブネットからポッドに IP アドレスが割り当てられます。 つまり、クラスターから出るトラフィックは SNAT されず、ポッドの IP アドレスはターゲットに直接公開されます。 これは、ポッドの IP アドレスを外部サービスに公開する必要がある場合など、一部のシナリオで役立ちます。
Azure Kubernetes Service には、フラット ネットワーク用の 2 つの CNI プラグインが用意されています。 この記事では、各プラグイン オプションの詳細については説明しません。 詳細については、リンクされたドキュメントを参照してください。
- Azure CNI ポッド サブネット。フラット ネットワーク シナリオに推奨される CNI プラグインです。
- Azure CNI ノード サブネット。レガシ フラット ネットワーク モデルの CNI では通常、クラスターのマネージド VNet が "必要" な場合にのみ使用することが推奨されます。
CNI の選択
CNI を選択するときに、考慮すべき要因がいくつかあります。 各ネットワーク モデルには長所と短所があり、クラスターに最適な選択は特定の要件によって異なります。
ネットワーク オプションの選択
AKS の 2 つの主要なネットワーク モデルは、オーバーレイ ネットワークとフラット ネットワークです。
オーバーレイ ネットワーク:
- ポッドに対して論理的に分離された CIDR 範囲を使用して、VNet IP アドレス空間を節約します。
- 最大のクラスター スケールのサポート。
- シンプルな IP アドレス管理。
フラット ネットワーク:
- ポッドでは完全な VNet 接続が取得され、接続されているネットワークからプライベート IP アドレスを介して直接アクセスできます。
- 断片化されていない大きな VNet IP アドレス空間が必要です。
ユース ケースの比較
ネットワーク モデルを選択するときは、各 CNI プラグインのユース ケースと、使用されるネットワーク モデルの種類を考慮してください。
| CNI プラグイン | ネットワーク モデル | ユース ケースの特徴 |
|---|---|---|
| Azure CNI オーバーレイ | オーバーレイ | - VNET IP 保護に最適 - API Server でサポートされる最大ノード数 + 250 ポッド/ノード - よりシンプルな構成 - 外部ポッドの直接 IP アクセスなし |
| Azure CNI ポッド サブネット | フラット | - 外部ポッドの直接アクセス - 効率的な VNet IP の使用 "または" 大規模なクラスター スケールのサポートのためのモード (プレビュー) |
| Kubenet (レガシ) | オーバーレイ | - IP 保護が優先される - 制限付きスケール - 手動ルート管理 |
| Azure CNI ノード サブネット (レガシ) | フラット | - 外部ポッドの直接アクセス - よりシンプルな構成 - 制限付きスケール - VNet IP の非効率的な使用 |
機能の比較
各 CNI プラグインの機能を比較することもできます。 次の表は、各 CNI プラグインでサポートされる機能を大まかに比較したものです。
| 機能 | Azure CNI オーバーレイ | Azure CNI ポッド サブネット | Azure CNI ノード サブネット (レガシ) | Kubenet |
|---|---|---|---|---|
| 既存または新しい VNet にクラスターをデプロイする | サポートされています | サポート対象 | サポートされています | サポート対象 - 手動 UDR |
| ポッドと VM の接続。同じまたはピアリングされた VNet 内の VM の場合 | ポッド開始 | 両方 | 両方 | ポッド開始 |
| VPN/Express Route 経由のオンプレミス アクセス | ポッド開始 | 両方 | 両方 | ポッド開始 |
| サービス エンドポイントへのアクセス | サポートされています | サポート対象 | サポート対象 | サポートされています |
| ロード バランサーを使用してサービスを公開する | サポートされています | サポート対象 | サポート対象 | サポートされています |
| App Gateway を使用してサービスを公開する | 以下は現在サポートされていません | サポートされています | サポート対象 | サポートされています |
| イングレス コントローラーを使用してサービスを公開する | サポートされています | サポート対象 | サポート対象 | サポートされています |
| Windows ノード プール | サポートされています | サポート対象 | サポート対象 | サポートされていません |
| 既定の Azure DNS およびプライベート ゾーン | サポートされています | サポート対象 | サポート対象 | サポートされています |
| 複数のクラスター間での VNet サブネットの共有 | サポートされています | サポート対象 | サポート対象 | サポートされていません |
ネットワーク モデル間のサポート範囲
使用する CNI に応じて、クラスター仮想ネットワーク リソースは次のいずれかの方法でデプロイできます。
- Azure プラットフォームは、AKS クラスターを作成したときに自動的に仮想ネットワーク リソースを作成して構成することができます。 Azure CNI オーバーレイ、Azure CNI ノード サブネット、Kubenet と同様。
- 仮想ネットワーク リソースを手動で作成して構成し、AKS クラスターを作成するときにそれらのリソースにアタッチすることができます。
サービス エンドポイントや UDR のような機能はサポートされていますが、AKS のサポート ポリシーでは、どのような変更を行うことができるかが定義されます。 次に例を示します。
- AKS クラスターの仮想ネットワーク リソースを手動で作成する場合は、独自の UDR またはサービス エンドポイントを構成するときにサポートされます。
- Azure プラットフォームで AKS クラスター用の仮想ネットワーク リソースを自動的に作成する場合、それらの AKS 管理対象リソースを手動で変更して独自の UDR またはサービスエンドポイントを構成することはできません。
前提条件
AKS のネットワーク構成を計画するときに、留意すべきいくつかの要件と考慮事項があります。
- AKS クラスターの仮想ネットワークでは、送信インターネット接続を許可する必要があります。
- AKS クラスターでは、Kubernetes サービスのアドレス範囲、ポッド アドレス範囲、またはクラスターの仮想ネットワーク アドレス範囲に
169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、192.0.2.0/24を使用することはできません。 - BYO VNet シナリオでは、AKS クラスターで使用されるクラスター ID には、少なくとも、ご利用の仮想ネットワーク内のサブネットに対するネットワーク共同作成者のアクセス許可が必要です。 組み込みのネットワークの共同作成者ロールを使用する代わりに、カスタム ロールを定義する場合は、次のアクセス許可が必要です。
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(独自のサブネットとCIDRを定義する場合にのみ必要)
- AKS ノード プールに割り当てられたサブネットを委任されたサブネットにすることはできません。
- AKS では Network Security Groups (NSG) がそのサブネットに適用されず、そのサブネットに関連付けられている NSG が変更されることもありません。 独自のサブネットを指定し、そのサブネットに関連付けられている NSG を追加する場合は、NSG のセキュリティ規則で、ノードの CIDR 範囲内のトラフィックが許可されていることを確認する必要があります。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。
次のステップ
Azure Kubernetes Service