Azure Kubernetes Service (AKS) でのアプリケーションに対するネットワークの概念
アプリケーション開発に対するコンテナー ベースのマイクロサービス アプローチでは、アプリケーション コンポーネントが連携してそれぞれのタスクを処理します。 Kubernetes は、この連携を可能にするさまざまなリソースを提供します。
- アプリケーションへの接続と内部または外部への公開を実行できます。
- アプリケーションを負荷分散することにより、可用性の高いアプリケーションを構築することができます。
- ポッドとノードへの、またはポッドとノード間のネットワーク トラフィックのフローを制限して、セキュリティを強化できます。
- さらに複雑なアプリケーションの場合は、SSL/TLS 終端または複数のコンポーネントのルーティングのためのイングレス トラフィックを構成できます。
この記事では、AKS 内でアプリケーションにネットワークを提供する主要な概念について説明します。
Kubernetes でのネットワークの基本
Kubernetes では、アプリケーションまたはそのコンポーネントの内部およびそれらの間でのアクセスを管理するために、仮想ネットワーク レイヤーが使われます。
Kubernetes ノードと仮想ネットワーク: Kubernetes ノードは仮想ネットワークに接続されます。 このセットアップにより、ポッド (Kubernetes でのデプロイの基本単位) はインバウンドとアウトバウンド両方の接続が可能になります。
kube-proxy コンポーネント: kube-proxy は各ノードで実行され、必要なネットワーク機能を提供します。
Kubernetes の特定の機能について:
- ロード バランサー: ロード バランサーを使うと、さまざまなリソース間にネットワーク トラフィックを均等に分散できます。
- イングレス コントローラー: これにより、アプリケーション トラフィックの転送に不可欠なレイヤー 7 ルーティングが容易になります。
- エグレス トラフィック制御: Kubernetes を使うと、クラスター ノードからのアウトバウンド トラフィックを管理および制御できます。
- ネットワーク ポリシー: これらのポリシーを使って、ポッド内のネットワーク トラフィックのセキュリティ対策とフィルター処理を実現できます。
Azure プラットフォームのコンテキストでは:
- Azure によって、AKS (Azure Kubernetes Service) クラスターの仮想ネットワークが効率化されます。
- Azure で Kubernetes のロード バランサーを作成すると、対応する Azure ロード バランサー リソースが同時に設定されます。
- ポッドへのネットワーク ポートを開くと、必要なネットワーク セキュリティ グループ規則が Azure によって自動的に構成されます。
- 新しいイングレス ルートが確立されると、Azure は HTTP アプリケーション ルーティング用に外部 DNS 構成を管理することもできます。
Azure 仮想ネットワーク
AKS では、次のネットワーク モデルのいずれかを使うクラスターをデプロイできます。
Kubenet ネットワーク
ネットワーク リソースは通常、AKS クラスターのデプロイ時に作成され、構成されます。
Azure Container Networking Interface (CNI) ネットワーク
AKS クラスターは、既存の仮想ネットワーク リソースと構成に接続されます。
Kubenet (基本) ネットワーク
kubenet ネットワーク オプションは、AKS クラスターを作成するための既定の構成です。 kubenet を使用する場合:
- ノードでは Azure 仮想ネットワークのサブネットから IP アドレスを受け取ります。
- ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。
- その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。
- トラフィックの発信元 IP アドレスは、ノードのプライマリ IP アドレスに変換されます。
ノードでは、kubenet Kubernetes プラグインを使用します。 Azure プラットフォームで仮想ネットワークを作成および構成させることができます。または、既存の仮想ネットワーク サブネットに AKS クラスターをデプロイするように選択できます。
ルーティング可能な IP アドレスを受け取るのはノードのみです。 ポッドでは NAT を使用して、AKS クラスター外の他のリソースと通信します。 この方法により、ポッドで使用するためにネットワーク空間で予約する必要がある IP アドレスの数が少なくなります。
Note
kubenet は、仮想ネットワークとサブネットを作成するための AKS クラスターの既定のネットワーク オプションですが、運用環境のデプロイにはお勧めしません。 ほとんどの運用環境のデプロイでは、優れたスケーラビリティとパフォーマンス特性を持つ Azure CNI ネットワークを計画して使用する必要があります。
詳細については、AKS クラスター用の kubenet ネットワークの構成に関するページを参照してください。
Azure CNI (高度) ネットワーク
Azure CNI を使用して、すべてのポッドでサブネットから IP アドレスを取得します。ポッドには直接アクセスできます。 これらの IP アドレスは、事前に計画し、ネットワーク空間全体で一意にする必要があります。 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。 ノードごとにそれと同じ数の IP アドレスが、事前に予約されます。 このアプローチでは、アプリケーションの需要が増えると、IP アドレスが不足したり、さらに大きなサブネットでのクラスターの再構築が必要になったりする可能性があるため、適切に計画することが重要です。 これらの計画の課題を回避するには、動的 IP 割り当てと拡張サブネットのサポートのための Azure CNI ネットワーク機能を有効にできます。
Note
Kubernetes の制限により、リソース グループ名、仮想ネットワーク名、およびサブネット名は 63 文字以下にする必要があります。
kubenet とは異なり、同じ仮想ネットワーク内のエンドポイントへのトラフィックは、ノードのプライマリ IP に変換 (NAT) されません。 仮想ネットワーク内のトラフィックの発信元アドレスは、ポッド IP です。 仮想ネットワークの外部にあるトラフィックは、ノードのプライマリ IP に引き続き NAT 処理されます。
ノードでは、Azure CNI Kubernetes プラグインを使用します。
詳細については、AKS クラスター用の Azure CNI の構成に関するページを参照してください。
Azure CNI オーバーレイ ネットワーク
Azure CNI オーバーレイは、Azure CNI の進化を表し、仮想ネットワーク IP のポッドへの割り当てに起因するスケーラビリティと計画の課題に対処します。 Azure CNI オーバーレイは、プライベート CIDR IP をポッドに割り当てます。 プライベート IP は仮想ネットワークから切り離されていて、複数のクラスター間で再利用できます。 Azure CNI オーバーレイは、Kubenet クラスターで適用される 400 ノードの制限を超えてスケーリングできます。 Azure CNI オーバーレイは、ほとんどのクラスターに推奨されるオプションです。
Azure CNI Powered by Cilium
Azure CNI Powered by Cilium では、Cilium を使用して、高パフォーマンスのネットワーク、監視、およびネットワーク ポリシーの適用が提供されます。 スケーラブルな IP アドレス管理 (IPAM) のために Azure CNI オーバーレイとネイティブに統合します。
さらに、Cilium では、別のネットワーク ポリシー エンジンを必要とせずに、既定でネットワーク ポリシーが適用されます。 eBPF プログラムといっそう効率的な API オブジェクト構造を使うと、Azure ネットワーク ポリシー マネージャーの 250 ノード/20K ポッドの制限を超えて、Azure CNI Powered by Cilium をスケーリングできます。
Azure CNI Powered by Cilium は、ネットワーク ポリシーの適用を必要とするクラスターに推奨されるオプションです。
独自のCNI を使用する
Bring Your Own CNI 機能を使って、Microsoft 以外の CNI を AKS にインストールできます。
ネットワーク モデルを比較する
kubenet と Azure CNIは、両方とも AKS クラスターのネットワーク接続を提供します。 ただし、それぞれに長所と短所があります。 大まかに言えば、次の考慮事項が適用されます。
kubenet
- IP アドレス空間を節約します。
- クラスターの外部からポッドに到達するには、Kubernetes の内部または外部ロード バランサーを使います。
- ユーザー定義のルート (UDR) は、手動で管理および保守します。
- クラスターあたり最大 400 ノード。
Azure CNI
- ポッドは完全な仮想ネットワーク接続を取得するため、接続されているネットワークからプライベート IP アドレスを介して直接アクセスできます。
- より多くの IP アドレス空間を必要とします。
| ネットワーク モデル | 使用する場合 |
|---|---|
| Kubenet | • IP アドレス空間の会話が優先される。 • シンプルな構成。 • クラスターあたり 400 ノード未満。 • クラスターの外部からポッドに到達するために Kubernetes 内部または外部ロード バランサーで十分である。 • ユーザー定義のルートを手動で管理および保守すれば十分である。 |
| Azure CNI | • ポッドに完全な仮想ネットワーク接続が必要である。 • 高度な AKS 機能 (仮想ノードなど) が必要である。 • 十分な IP アドレス空間を使用できる。 • ポッド間の接続と、ポッドから仮想マシンへの接続が必要である。 • 外部リソースはポッドに直接到達する必要がある。 • AKS ネットワーク ポリシーが必要である。 |
| Azure CNI オーバーレイ | • IP アドレスの不足が懸念される。 • ノードあたり最大 1000 個のノードと 250 個のポッドへのスケールアップで十分である。 • ポッド接続に追加のホップが許容される。 • シンプルなネットワーク構成。 • AKS エグレスの要件を満たすことができる。 |
kubenet と Azure CNI には、次のような動作の違いが存在します。
| 機能 | Kubenet | Azure CNI | Azure CNI オーバーレイ | Azure CNI Powered by Cilium |
|---|---|---|---|---|
| 既存または新規の仮想ネットワークにクラスターをデプロイする | サポートされています - UDR は手動で適用されます | サポートされています | サポート対象 | サポートされています |
| ポッド間接続 | サポートされています | サポート対象 | サポート対象 | サポートされています |
| ポッドと VM の接続。同一仮想ネットワーク内の VM | ポッドによって開始されたときに動作します | 両方の方法で動作します | ポッドによって開始されたときに動作します | ポッドによって開始されたときに動作します |
| ポッドと VM の接続。ピアリングされた仮想ネットワーク内の VM | ポッドによって開始されたときに動作します | 両方の方法で動作します | ポッドによって開始されたときに動作します | ポッドによって開始されたときに動作します |
| VPN または Express Route を使用したオンプレミスへのアクセス | ポッドによって開始されたときに動作します | 両方の方法で動作します | ポッドによって開始されたときに動作します | ポッドによって開始されたときに動作します |
| サービス エンドポイントによって保護されているリソースへのアクセス | サポートされています | サポート対象 | サポートされています | |
| ロード バランサー サービス、App Gateway、またはイングレス コントローラーを使用して、Kubernetes サービスを公開する | サポートされています | サポート対象 | サポートされています | オーバーレイ モードを使用する場合と同じ制限事項 |
| Windows ノード プールのサポート | サポートされていません | サポートされています | サポートされています | Linux でのみ使用でき、Windows では使用できません。 |
| 既定の Azure DNS およびプライベート ゾーン | サポートされています | サポート対象 | サポートされています |
Azure CNI と kubenet の詳細と、最適なオプションの判断に役立つ情報については、「AKS で Azure CNI ネットワークを構成する」および「AKS で kubenet ネットワークを使用する」を参照してください。
ネットワーク モデル間のサポート範囲
kubenet と Azure CNI はいずれも、使用するネットワーク モデルに関係なく次のいずれかの方法でデプロイすることができます。
- Azure プラットフォームは、AKS クラスターを作成したときに自動的に仮想ネットワーク リソースを作成して構成することができます。
- 仮想ネットワーク リソースを手動で作成して構成し、AKS クラスターを作成するときにそれらのリソースにアタッチすることができます。
サービス エンドポイントや UDR のような機能は kubenet と Azure CNI の両方でサポートされていますが、AKS のサポート ポリシーは、どのような変更を行うことができるかを定義します。 次に例を示します。
- AKS クラスターの仮想ネットワーク リソースを手動で作成する場合は、独自の UDR またはサービス エンドポイントを構成するときにサポートされます。
- Azure プラットフォームで AKS クラスター用の仮想ネットワーク リソースを自動的に作成する場合、それらの AKS 管理対象リソースを手動で変更して独自の UDR またはサービスエンドポイントを構成することはできません。
イングレス コントローラー
LoadBalancer 型のサービスを作成すると、基になる Azure ロード バランサー リソースも作成されます。 ロード バランサーは、特定のポートでサービス内のポッドにトラフィックを分散するように構成されます。
LoadBalancer は、レイヤー 4 でのみ動作します。 レイヤー 4 では、サービスは実際のアプリケーションを認識せず、追加のルーティングを考慮することはできません。
"イングレス コントローラー" はレイヤー 7 で動作し、インテリジェントなルールを使用してアプリケーションのトラフィックを分散させることができます。 イングレス コントローラーは通常、受信 URL に基づいて HTTP トラフィックを別のアプリケーションにルーティングします。
イングレス オプションの比較
次の表に、さまざまなイングレス コントローラー オプション間での機能の違いを挙げています。
| 機能 | Application Routing アドオン | Application Gateway for Containers | Azure サービス メッシュ/Istio ベースのサービス メッシュ |
|---|---|---|---|
| イングレス/ゲートウェイ コントローラー | NGINX イングレス コントローラー | Azure Application Gateway for Containers | Istio イングレス ゲートウェイ |
| API | Ingress API | Ingress API と Gateway API | Gateway API |
| ホスティング | クラスター内 | Azure ホステッド | クラスター内 |
| スケーリング | 自動スケール | 自動スケール | 自動スケール |
| 負荷分散 | 内部/外部 | 外部 | 内部/外部 |
| SSL ターミネーション | クラスター内 | 有り: オフロードで E2E SSL | クラスター内 |
| mTLS | 該当なし | バックエンドに対して有り | 該当なし |
| 静的 IP アドレス | 該当なし | FQDN | 該当なし |
| Azure Key Vault に保存済みの SSL 証明書 | はい | はい | 該当なし |
| DNS ゾーン管理のための Azure DNS 統合 | はい | はい | 該当なし |
次の表に、各イングレス コントローラーを使用する場合のさまざまなシナリオを挙げています。
| イングレス オプション | いつ使用するか |
|---|---|
| マネージド NGINX - Application Routing アドオン | • クラスター内にホストされている、カスタマイズ可能でスケーラブルな NGINX イングレス コントローラー。 • 基本的な負荷分散およびルーティング機能。 • 内部/外部ロード バランサー構成。 • 静的 IP アドレス構成。 • 証明書管理用の Azure Key Vault との統合。 • パブリック/プライベート DNS 管理のための Azure DNS ゾーン との統合。 • イングレス API のサポート。 |
| Application Gateway for Containers | • Azure でホストされるイングレス ゲートウェイ。 • コントローラーで管理する柔軟なデプロイ戦略、または独自の Application Gateway for Containers の使用。 • 高度なトラフィック管理機能 (自動再試行、可用性ゾーンの回復性、バックエンド ターゲットに対する相互認証 (mTLS)、トラフィック分割/重み付けラウンド ロビン、自動スケーリングなど)。 • 証明書管理用の Azure Key Vault との統合。 • パブリック/プライベート DNS 管理のための Azure DNS ゾーン との統合。 • Ingress API と Gateway API のサポート。 |
| Istio イングレス ゲートウェイ | • Envoy に基づいて、サービス メッシュに Istio を使用する場合。 • 高度なトラフィック管理機能 (レート制限やサーキット ブレークなど)。 • mTLS のサポート • Gateway API のサポート。 |
イングレス リソースを作成する
アプリケーション ルーティング アドオンは、AKS でイングレス コントローラーを構成するために推奨される方法です。 アプリケーション ルーティング アドオンは、 Azure Kubernetes Service (AKS) 向けのフル マネージド型のイングレス コントローラーで、次の機能を提供します。
Kubernetes NGINX イングレス コントローラーに基づくマネージド NGINX イングレス コントローラーの簡単な構成。
パブリック ゾーンとプライベート ゾーンの管理のための Azure DNS との統合。
Azure Key Vault に格納されている証明書での SSL 終端。
アプリケーション ルーティング アドオンについて詳しくは、「アプリケーション ルーティング アドオンでのマネージド NGINX イングレス」をご覧ください。
クライアント ソース IP の保持
クライアント ソース IP を AKS クラスター内のコンテナーへの要求上で保持するようにイングレス コントローラーを構成します。 イングレス コントローラーによりクライアントの要求が AKS クラスター内のコンテナーにルーティングされるときに、その要求の元のソース IP は、ターゲット コンテナーでは利用できません。 クライアント ソース IP の保持を有効にすると、クライアントに対するソース IP は、X-Forwarded-For 下にある要求ヘッダー内で利用できます。
クライアント ソース IP の保持機能をイングレス コントローラー上で使用している場合は、TLS パススルーを使用できません。 クライアント ソース IP の保持と TLS パススルーは、LoadBalancer 型など、他のサービスによって使用できます。
クライアント ソース IP の保持について詳しくは、「AKS の LoadBalancer Services でのクライアント ソース IP 保持のしくみ」をご覧ください。
送信 (エグレス) トラフィックを制御する
AKS クラスターは仮想ネットワークにデプロイされ、その仮想ネットワーク外のサービスに送信依存関係があります。 これらの送信依存関係は、ほぼ全体が完全修飾ドメイン名 (FQDN) で定義されています。 既定では、AKS クラスターのアウトバウンド (エグレス) インターネット アクセスに制限はなく、実行するノードとサービスは必要に応じて外部リソースにアクセスできます。 必要な場合は、送信トラフィックを制限できます。
詳細については、「AKS でクラスター ノードに対するエグレス トラフィックを制御する」をご覧ください。
ネットワーク セキュリティ グループ
ネットワーク セキュリティ グループは、AKS ノードなどの VM のトラフィックをフィルター処理します。 LoadBalancer などのサービスを作成すると、必要なネットワーク セキュリティ グループ規則が Azure プラットフォームによって自動的に構成されます。
AKS クラスター内のポッドに対するトラフィックをフィルター処理するネットワーク セキュリティ グループ規則を手動で構成する必要はありません。 ユーザーは、Kubernetes サービス マニフェストの一部として必要なポートと転送を定義し、適切なルールの作成または更新は Azure プラットフォームに任せることができます。
ネットワーク ポリシーを使用して、ポッドにトラフィックのフィルター規則を自動的に適用することもできます。
詳しくは、「ネットワーク セキュリティ グループによってネットワーク トラフィックをフィルター処理する方法」をご覧ください。
ネットワーク ポリシー
既定では、AKS クラスター内のすべてのポッドは制限なしにトラフィックを送受信できます。 セキュリティ向上のために、次のような、トラフィック フローを制御する規則を定義してください。
- バックエンド アプリケーションは、必要なフロントエンド サービスにのみ公開される。
- データベース コンポーネントは、そこに接続するアプリケーション層からのみアクセスできる。
ネットワーク ポリシーは、ポッド間のトラフィック フローを制御できる、AKS で使用可能な Kubernetes の機能です。 ユーザーは、割り当てられたラベル、名前空間、トラフィック ポートなどの設定に基づいて、ポッドへのトラフィックを許可または拒否できます。 ネットワーク セキュリティ グループが AKS ノードに適している一方で、ネットワーク ポリシーは、ポッドのトラフィック フローを制御するのにより適した、クラウド ネイティブな方法です。 AKS クラスター内でポッドが動的に作成されたときに、必要なネットワーク ポリシーを自動的に適用できます。
詳細については、「Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用したポッド間のトラフィックの保護」を参照してください。
次のステップ
AKS ネットワークの使用を開始するために、kubenet または Azure CNI を使用して、独自の IP アドレス範囲で AKS クラスターを作成および構成します。
関連付けられているベスト プラクティスについては、AKS でのネットワーク接続とセキュリティに関するベスト プラクティスに関するページを参照してください。
Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。