コンテナー ネットワークの概念

適用対象: AKS on Azure Stack HCI 22H2、Windows Server 上の AKS

アプリケーションのコンポーネントは、連携して各自のタスクをコンテナーベースのマイクロサービス アプローチで処理する必要があります。 Kubernetes を使用すると、アプリケーション通信を可能にするリソースを利用でき、内部または外部でアプリケーションに接続して公開することができます。 アプリケーションの負荷を分散させて、高可用性アプリケーションを構築することができます。

より複雑なアプリケーションでは、SSL/TLS 終端または複数のコンポーネントのルーティングにイングレス トラフィックの構成が必要になる場合があります。 セキュリティのために、ポッドとノード間のネットワーク トラフィックのフローを制限する必要がある場合もあります。

この記事では、Arc で有効になっている AKS のアプリケーションにネットワークを提供する主要な概念について説明します。

• Kubernetes サービス
• イングレス コントローラー
• ネットワーク ポリシー

Kubernetes サービス

アプリケーション ワークロードのネットワーク構成を簡素化するため、Kubernetes では、サービスを使用して、一連のポッドを論理的にグループ化してネットワーク接続を行います。 次の種類のサービスを使用できます。

クラスター IP: Kubernetes クラスター内で使用する内部 IP アドレスを作成します。 クラスター内で他のワークロードをサポートする内部専用アプリケーションにクラスター IP を使用します。

NodePort: 基になるノードにポート マッピングを作成します。これにより、アプリケーションはノードの IP アドレスとポートを使用して直接アクセスできます。

LoadBalancer: Azure ロード バランサー リソースを作成し、外部 IP アドレスを構成し、要求されたポッドをロード バランサー バックエンド プールに接続します。 顧客のトラフィックによるアプリケーションへのアクセスを許可するために、目的のポート上に負荷分散規則が作成されます。

受信トラフィックの他の制御とルーティングには、イングレス コントローラーを使用できます。

Note

ネットワークを別のターゲット クラスターと共有するターゲット クラスターをデプロイすると、ロード バランサーの IP アドレスが競合する可能性があります。 これは、同じAksHciClusterNetworkオブジェクトを共有するターゲットクラスタに、異なるポートを使用する2つのワークロードを配置した場合に発生する可能性があります。 IP アドレスとポートマッピングが HA Proxy 内で割り当てられる方法が原因で、これにより IP アドレスの割り当てが重複する可能性があります。 この場合、ワークロードを再デプロイするまで、一方または両方のワークロードでランダムなネットワーク接続の問題が発生する可能性があります。 ワークロードを再デプロイする場合は、各ワークロードが個別のサービス IP アドレスを受信する同じポートを使用するか、異なる AksHciClusterNetwork オブジェクトを使用するターゲット クラスターにワークロードを再デプロイすることができます。

ExternalName: アプリケーションへのアクセスを容易にするために、特定の DNS エントリを作成します。 ロード バランサーとサービスの IP アドレスは、ネットワークの全体的な設定に応じて内部または外部のアドレスにすることができ、動的に割り当てることができます。 または、使用する既存の静的 IP アドレスを指定することもできます。 既存の静的 IP アドレスは、多くの場合、DNS エントリに関連付けられています。 内部ロード バランサーにはプライベート IP アドレスのみが割り当てられるため、インターネットからそれらにアクセスすることはできません。

Azure Local での Kubernetes ネットワークの基本

アプリケーションへのアクセスまたはアプリケーション コンポーネントの相互通信を可能にするため、Kubernetes には、仮想ネットワークに対する抽象化レイヤーが提供されています。 仮想ネットワークに接続された Kubernetes ノードは、ポッドに対して受信接続と送信接続を実行できます。 これらのネットワーク機能を提供するために、各ノードで kube-proxy コンポーネントが実行しています。

Kubernetes では、 サービス はポッドを論理的にグループ化して次のことを可能にします。

• 単一の IP アドレスまたは DNS 名と特定のポートを使用して直接アクセスします。
• 同じサービスまたはアプリケーションをホストしている複数のポッド間で ロード バランサー を使用してトラフィックを分散します。

Azure Local プラットフォームは、高可用性の方法で "アンダーレイ" ネットワークを提供することで、Azure Local クラスター上の AKS の仮想ネットワークを簡素化するのにも役立ちます。 AKS クラスターを作成するときに、基になる HAProxy ロード バランサー リソースも作成して構成します。 Kubernetes クラスターにアプリケーションをデプロイすると、ポッドと Kubernetes サービスに対して IP アドレスがこのロード バランサーのエンドポイントとして構成されます。

IP アドレス リソース

アプリケーション ワークロードのネットワーク構成を簡略化するために、AKS Arc はデプロイ内の次のオブジェクトに IP アドレスを割り当てます。

• Kubernetes クラスター API サーバー: API サーバーは、Kubernetes API を公開する Kubernetes コントロール プレーンのコンポーネントです。 API サーバーは、Kubernetes コントロール プレーンのフロントエンドです。 API サーバーには、基礎となるネットワーク モデルに関係なく、常に静的 IP アドレスが割り当てられます。
• Kubernetes ノード (仮想マシン): Kubernetes クラスターは、ノードと呼ばれる一連のワーカー マシンで構成され、ノードはコンテナー化されたアプリケーションをホストします。 コントロール プレーン ノードに加えて、各クラスターには少なくとも 1 つのワーカー ノードがあります。 AKS クラスターの場合、Kubernetes ノードは仮想マシンとして構成されます。 これらの仮想マシンは、Azure Local で高可用性仮想マシンとして作成されます。詳細については、「 Node ネットワークの概念を参照してください。
• Kubernetes サービス: Kubernetes では、 Services ポッドの IP アドレスを論理的にグループ化して、特定のポート上の単一の IP アドレスまたは DNS 名を介して直接アクセスできるようにします。 ロード バランサーを使用してトラフィックを分散させることもできます。 基礎となるネットワーク モデルに関係なく、常に静的 IP アドレスが Kubernetes サービスに割り当てられます。
• HAProxy ロード バランサー: HAProxy は、受信要求を複数のエンドポイントに分散する TCP/HTTP ロード バランサーおよびプロキシ サーバーです。 AKS on Azure Local デプロイ内のすべてのワークロード クラスターには、HAProxy ロード バランサーがデプロイされ、特殊な仮想マシンとして構成されています。
• Microsoft オンプレミス クラウド サービス: これは、オンプレミスの Azure ローカル クラスターまたは Windows Server クラスターで Kubernetes をホストする仮想化環境の作成と管理を可能にする Azure ローカル クラウド プロバイダーです。 ネットワーク モデルとそれに続く Azure Local または Windows Server クラスターによって、Microsoft On-Premises Cloud Service で使用される IP アドレスの割り当て方法が決まります。 Microsoft のオンプレミス クラウド サービスによって実装されるネットワークの概念の詳細については、「ノード ネットワークの概念」を参照してください。

Kubernetes ネットワーク

AKS on Azure Local では、次のいずれかのネットワーク モデルを使用するクラスターをデプロイできます。

• Flannel Overlay ネットワーク - クラスターのデプロイ時に、通常はネットワーク リソースが作成され、構成されます。
• プロジェクト Calico ネットワーク - このモデルは、ネットワーク ポリシーやフロー制御などの追加のネットワーク機能を提供します。

どちらのネットワーク実装でも、オーバーレイ ネットワーク構成モデルを使用します。これにより、データ センター ネットワークの他の部分から切断された IP アドレスの割り当てが可能になります。

オーバーレイ ネットワークの詳細については、「Windows 用の Kubernetes オーバーレイ　ネットワークの概要」を参照してください。

Calico ネットワーク プラグインとポリシーの詳細については、「Calico ネットワーク ポリシーの概要」を参照してください。

ネットワーク モデルの比較

Flannel

Note

Flannel CNI は 2023 年 12 月に廃止されました。

Flannel は、コンテナー専用に設計された仮想ネットワーク層です。 Flannel は、ホスト ネットワークをオーバーレイするフラットなネットワークを作成します。 すべてのコンテナー/ポッドには、このオーバーレイ ネットワーク内の 1 つの IP アドレスが割り当てられ、互いの IP アドレスに接続することによって直接通信します。

Calico

Calico は、コンテナー、仮想マシン、およびネイティブのホストベースのワークロードに対応したオープンソースのネットワークおよびネットワーク セキュリティ ソリューションです。 Calico は、Linux eBPF データ プレーン、Linux ネットワーク データ プレーン、Windows HNS データ プレーンなどの複数のデータ プレーンをサポートしています。

機能

機能	Flannel	Calico
ネットワーク ポリシー	いいえ	はい
IPv6	いいえ	はい
使用するレイヤー	L2 (VxLAN)	L2 (VxLAN)
既存または新規の仮想ネットワークにクラスターをデプロイする	はい	はい
Windows 対応	はい	はい
ポッド間接続	はい	はい
ポッド-VM 接続、同じネットワーク内の VM	いいえ	はい
ポッド-VM 接続、異なるネットワーク内の VM	はい	はい
Kubernetes サービス	はい	はい
ロード バランサーを介して公開する	はい	はい
ネットワーク	マルチデーモンを使用する同じクラスター上の多くのネットワーク	同じクラスター上の多くのネットワーク
展開	Linux: DaemonSet	Linux: DaemonSet
	Windows: Service	Windows: Service
コマンド ライン	なし	calicoctl

重要

現時点では、既定では、オーバーレイ ネットワーク モードで Calico を使用することが選択されています。 Flannel を有効にするには、New-AksHciCluster PowerShell コマンドの -primaryNetworkPlugin パラメーターを使用し、値としてflannelを指定します。 この値は、クラスターをデプロイした後は変更できず、Windows と Linux の両方のクラスター ノードに適用されます。

次に例を示します。

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

次のステップ

この記事では、Azure Local 上の AKS ノード内のコンテナーのネットワークの概念について説明します。 AKS on Azure Local の概念の詳細については、次の記事を参照してください。

• AKS ノードのネットワーク概念
• クラスターとワークロード