コンテナー ネットワークの概念
適用対象: AKS on Azure Stack HCI 22H2、AKS on Windows Server
アプリケーションのコンポーネントは、連携して各自のタスクをコンテナーベースのマイクロサービス アプローチで処理する必要があります。 Kubernetes を使用すると、アプリケーション通信を可能にするリソースを利用でき、内部または外部でアプリケーションに接続して公開することができます。 アプリケーションの負荷を分散させて、高可用性アプリケーションを構築することができます。
複雑なアプリケーションでは、SSL/TLS 終端または複数のコンポーネントのルーティングのためのイングレス トラフィックの構成が必要な場合があります。 セキュリティのために、ポッドとノードに対するネットワーク トラフィックまたはポッドとノード間でのネットワーク トラフィックのフロー制限が必要な場合もあります。
この記事では、Arc で有効になっている AKS のアプリケーションにネットワークを提供する主要な概念について説明します。
- Kubernetes サービス
- イングレス コントローラー
- ネットワーク ポリシー
Kubernetes サービス
アプリケーション ワークロードのネットワーク構成を簡素化するため、Kubernetes では、サービスを使用して、一連のポッドを論理的にグループ化してネットワーク接続を行います。 次の種類のサービスを使用できます。
クラスター IP: Kubernetes クラスター内で使用する内部 IP アドレスを作成します。 クラスター内で他のワークロードをサポートする内部専用アプリケーションにクラスター IP を使用します。
NodePort: 基になるノードにポート マッピングを作成します。これにより、アプリケーションにノードの IP アドレスとポートを使用して直接アクセスできます。
LoadBalancer: Azure ロード バランサー リソースを作成し、外部 IP アドレスを構成し、要求されたポッドをロード バランサー バックエンド プールに接続します。 顧客のトラフィックによるアプリケーションへのアクセスを許可するために、目的のポート上に負荷分散規則が作成されます。
受信トラフィックの他の制御とルーティングには、イングレス コントローラーを使用できます。
注意
ネットワークを別のターゲット クラスターと共有するターゲット クラスターをデプロイすると、ロード バランサーの IP アドレスが競合する可能性があります。
これは、同じAksHciClusterNetworkオブジェクトを共有するターゲットクラスタに、異なるポートを使用する2つのワークロードを配置した場合に発生する可能性があります。 IP アドレスとポートマッピングが HA Proxy 内で割り当てられる方法が原因で、これにより IP アドレスの割り当てが重複する可能性があります。 この場合、ワークロードを再デプロイするまで、一方または両方のワークロードでランダムなネットワーク接続の問題が発生する可能性があります。 ワークロードを再デプロイするときは、各ワークロードが個別のサービス IP アドレスを受信する同じポートを使用するか、異なる AksHciClusterNetwork オブジェクトを使用するターゲット クラスターにワークロードを再デプロイできます。
ExternalName: アプリケーションへのアクセスを容易にするために、特定の DNS エントリを作成します。 ロード バランサーとサービスの IP アドレスは、ネットワークの全体的な設定に応じて内部または外部のアドレスにすることができ、動的に割り当てることができます。 または、使用する既存の静的 IP アドレスを指定することもできます。 既存の静的 IP アドレスは、多くの場合、DNS エントリに関連付けられています。 内部ロード バランサーにはプライベート IP アドレスのみが割り当てられるため、インターネットからそれらにアクセスすることはできません。
Azure Stack HCI 上の Kubernetes ネットワーキングの基礎
アプリケーションへのアクセスまたはアプリケーション コンポーネントの相互通信を可能にするため、Kubernetes には、仮想ネットワークに対する抽象化レイヤーが提供されています。 仮想ネットワークに接続された Kubernetes ノードは、ポッドに対して受信接続と送信接続を実行できます。 これらのネットワーク機能を提供するために、各ノードで kube-proxy コンポーネントが実行しています。
Kubernetes では、 サービス はポッドを論理的にグループ化して次のことを可能にします。
- 単一の IP アドレスまたは DNS 名と特定のポートを使用して直接アクセスします。
- 同じサービスまたはアプリケーションをホストしている複数のポッド間で ロード バランサー を使用してトラフィックを分散します。
また、Azure Stack HCI プラットフォームでは、「基となる」ネットワークを高可用性の方法で提供することで、AKS on Azure Stack HCI クラスターの仮想ネットワークを簡素化することもできます。
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 Stack HCI の高可用性仮想マシンとして作成されます。詳細については、「ノード ネットワークの概念」を参照してください。
- Kubernetes サービス: Kubernetes では、 サービス はポッド IP アドレスを論理的にグループ化して、特定のポート上の単一の IP アドレスまたは DNS 名を介して直接アクセスできるようにします。 ロード バランサーを使用してトラフィックを分散させることもできます。 基礎となるネットワーク モデルに関係なく、常に静的 IP アドレスが Kubernetes サービスに割り当てられます。
- HAProxy ロード バランサー: HAProxy は、受信要求を複数のエンドポイントに分散する TCP/HTTP ロード バランサーおよびプロキシ サーバーです。 AKS on Azure Stack HCI デプロイ内のすべてのワークロード クラスターには、HAProxy ロード バランサーがデプロイされ、特殊化された仮想マシンとして構成されています。
- Microsoft オンプレミス クラウド サービス: これは、オンプレミスの Azure Stack HCI クラスターまたは Windows Server クラスターで Kubernetes をホストする仮想化環境の作成と管理を可能にする Azure Stack HCI クラウド プロバイダーです。 ネットワーク モデルとそれに続く Azure Stack HCI または Windows Server クラスターによって、Microsoft オンプレミス クラウド サービスで使用される IP アドレスの割り当て方法が決まります。 Microsoft のオンプレミス クラウド サービスによって実装されるネットワークの概念の詳細については、「ノード ネットワークの概念」を参照してください。
Kubernetes ネットワーク
AKS on Azure Stack HCI では、次のネットワーク モデルのいずれかを使用するクラスターをデプロイできます。
- Flannel Overlay ネットワーク - クラスターのデプロイ時に、通常はネットワーク リソースが作成され、構成されます。
- プロジェクト Calico ネットワーク - このモデルは、ネットワーク ポリシーやフロー制御などの追加のネットワーク機能を提供します。
どちらのネットワーク実装でも、オーバーレイ ネットワーク構成モデルを使用します。これにより、データ センター ネットワークの他の部分から切断された IP アドレスの割り当てが可能になります。
オーバーレイ ネットワークの詳細については、「Windows 用の Kubernetes オーバーレイ ネットワークの概要」を参照してください。
Calico ネットワーク プラグインとポリシーの詳細については、「Calico ネットワーク ポリシーの概要」を参照してください。
ネットワーク モデルの比較
Flannel
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 を有効にするには、PowerShell コマンドの パラメーターをNew-AksHciCluster使用-primaryNetworkPluginし、値として を指定flannelします。 この値は、クラスターをデプロイした後は変更できず、Windows と Linux の両方のクラスター ノードに適用されます。
次に例を示します。
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
次のステップ
この記事では、Azure Stack HCI の AKS ノード内のコンテナーのネットワークの概念について説明します。 Azure Stack HCI の AKS の概念の詳細については、次の記事を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示