ネットワーク アプリケーション シナリオ
Kubernetes クラスターを用意したので、まずそれについて考えてみましょう。コンテナー ネットワークでは、クラスターが通常どおり実行できるようにするだけでなく、Kubernetes のインストール後に Pending CoreDNS を実行することもできます (鶏の精神を揺るがす -_-)。他にはどのような利用シーンがあるのでしょうか？
ここでは、7 つの主な使用シナリオを図でまとめました。これは、ほとんどの運用および保守担当者のネットワーク ニーズもカバーするはずです。
固定IP。既存の仮想化/ベアメタルビジネス/単一アプリケーションをコンテナ環境に移行した後、サービス間の呼び出しはドメイン名ではなくIP経由で行われますが、このとき、CNIプラグインには固定IPの機能が必要です。ポッド/デプロイメント/ステートフルセット。
ネットワークの分離。コンテナー グループは、異なるテナントまたは異なるアプリケーション間で相互に呼び出したり通信したりできません。
マルチクラスターネットワーク相互接続。異なる Kubernetes クラスター間のマイクロサービスが相互に呼び出しを行うシナリオでは、マルチクラスター ネットワークの相互接続が必要です。このシナリオは通常、異なるマイクロサービス インスタンスの相互呼び出しのニーズを満たすために、IP 到達可能性とサービスの相互運用性に分割されます。
アウトバウンド制限。コンテナクラスタ外のデータベース/ミドルウェアの場合、特定の属性を制御できるコンテナアプリケーションのみがアクセスでき、その他の接続要求は拒否されます。
入場制限。クラスター外のアプリケーションによる特定のコンテナー アプリケーションへのアクセスを制限します。
帯域幅の制限。コンテナ アプリケーション間のネットワーク アクセスは、帯域幅によって制限されます。
出口ゲートウェイへのアクセス。クラスター外部の特定のアプリケーションにアクセスするコンテナーの場合、統合された出力アクセスの監査およびセキュリティ要件を満たすために、それらに対して SNAT を実行するように出力ゲートウェイを設定します。要件とアプリケーションのシナリオを整理した後、さまざまな CNI プラグインを通じて上記の問題点を解決する方法を見てみましょう。
ネットワーク プラグイン機能の実装
固定 IP
基本的に、主流の CNI プラグインは独自の IPAM メカニズムを持ち、すべて固定 IP と IP プールの割り当てをサポートしており、各 CNI プラグインはアノテーション メソッドを使用して固定 IP を指定します。ポッドの場合は固定 IP を割り当て、デプロイメントの場合は IP プールを使用して割り当てます。ステートフル Statefulset の場合、IP プールを使用した割り当て後、ポッドの IP はプールの割り当て順序に従って記憶され、ポッドの再起動後も同じ IP を確実に取得できるようになります。
Calico
"cni.projectcalico.org/ipaddrs"： "[" 192.168.0.1 "]"
Kube-ovn
ovn.kubernetes.io/ip_address：192.168.100.100
ovn.kubernetes.io/IP_POOL：192.168.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192.192
.
Antrea
Antrea IPAM はブリッジ モードでのみ使用できるため、Multus の支援により、NodeIPAM を使用してプライマリ ネットワーク カードを割り当て、Antrea IPAM を使用してセカンダリ ネットワーク カードに VLAN タイプのネットワーク アドレスを割り当てることができます。
ipam.antrea.io/ippools: 'pod-ip-pool1'
ipam.antrea.io/pod-ips: '<ip-in-pod-ip-pool1>'
1
Cilium
Not Yet!
マルチクラスター ネットワーク相互接続 マルチ
クラスター ネットワーク相互接続では、複数の既存のクラスターがあり、異なるクラスターで異なるマイクロサービスが実行されていると仮定します。クラスター 1 の App01 はクラスター 2 の App02 と通信する必要があります。は IP 経由でクラスター外の VM 登録センターに登録されるため、App01 と App02 は IP 経由でのみ通信できます。このシナリオでは、マルチクラスター Pod を相互接続する必要があります。
Calico BGP をネイティブにサポートするCalico
のような CNI プラグインでは、これを簡単に実現できます。2 つのクラスターが BGP を通じてネイバーを確立し、それぞれのルートを相互にアナウンスする限り、動的ルーティングを確立できます。複数のクラスターがある場合は、BGP RR を使用して問題を解決することもできます。ただし、このソリューションは、物理ネットワーク環境との連携と共同デバッグが必要であり、ネットワーク担当者とコンテナの運用保守担当者が協力してマルチクラスタ ネットワークを構築する必要があるため、最も理想的なソリューションではない可能性があります。後の運用、保守、管理はあまり便利ではなく、機敏ではありません。
Calico VxLAN モードについてはどうですか?
VxLAN に関しては、Kube-OVN、Antrea、および Cilium と組み合わせることができます。4 つの CNI はすべてオーバーレイ ネットワーク モデルをサポートし、コンテナ ネットワーク通信を開くための VxLAN/GENEVE 形式のトンネル ネットワークの確立をサポートします。これにより、運用および保守担当者に高度な柔軟性が与えられます。コンテナ クラスターの運用および保守担当者は、コンテナ ネットワークのチューニング、IPAM の割り当て、ネットワークの監視と可観測性、およびネットワーク ポリシーの調整を担当しますが、ネットワーク担当者は物理ネットワークを事前に計画するだけで済みます。コンテナ クラスタ内のノード間のネットワーク通信を確保するには、大規模なネットワーク セグメントで十分です。
では、オーバーレイネットワークのマルチクラスタ相互接続を実現するにはどうすればよいでしょうか?
Submariner
CNCF には、Submariner と呼ばれるサンドボックス プロジェクトがあり、異なるクラスターに異なるゲートウェイ ノードを確立し、トンネルを開くことでマルチクラスター通信を実現します。公式のアーキテクチャ図から説明します。
簡単に言うと、Submariner はクラスター メタデータ仲介サービス (ブローカー) を使用して、さまざまなクラスターの情報 (Pod/サービス CIDR) をマスターし、Pod トラフィックをノードからゲートウェイ ノード (ゲートウェイ エンジン) に転送します。 )、ゲートウェイ ノードがトンネルを開いて別のクラスターに送信します。このプロセスは、異なるホスト上のコンテナ間で VxLAN ネットワーク通信を使用するという概念と一致しています。クラスター接続も非常に簡単で、いずれかのクラスターに Broker をデプロイし、kubeconfig または context を通じて個別に登録します。
Cilium
Cilium Cluster Mesh は Submariner に似ており、トンネルまたは NativeRoute を介したクラスター相互接続を実現できます。
Cilium は、マルチクラスター ネットワーク接続を開くのも非常に簡単です。
KubeOVN
Kube-OVN は、ルーティング リレー OVN-IC Docker コンテナーを実行し、異なる Pod ネットワークを接続する 2 つのクラスターのゲートウェイ ノードとして機能する OVNIC コンポーネントも提供します。クラスターが接続されました。
マルチクラスターのサービス
相互アクセス ポッド IP の相互接続に加えて、マルチクラスター ネットワークではクラスター間のサービス相互アクセスも考慮できます。これは、Submariner、Cilium、および Antrea によって実現できます。Submariner と Antrea は両方とも、Kubernetes コミュニティの MultiCluster Service を使用し、それを独自のコンポーネントと組み合わせて、マルチクラスター サービス アクセスを実現します。MultiCluster Service は ServiceExport と ServiceImport の CRD を使用します。ServiceExport は公開する必要があるサービスをエクスポートし、ServiceImport を通じてこのサービスを別のクラスターにインポートします。
Submariner は
Submariner の実装を例に挙げています。ks1 と ks2 という 2 つのクラスターがあります。ks1 にはテスト名前空間にサービス nginx があります。このとき、nginx サービスは ServiceExport を通じてエクスポートされます。Submariner は nginx.test.svc.cluster を検出します。 .local サービスを nginx.test.svc.clusterset.local として使用すると、両方のクラスターの coredns が、clusterset.local の新しいスタブ ドメインを作成し、cluster.set に一致するすべてのリクエストをサブマリーナーのサービス検出コンポーネントに送信します。同時に ServiceImport が ks2 クラスターにインポートされ、nginx.test.svc.clusterset.local を通じて ks2 クラスターの Pod を ks1 クラスターの nginx Service に解決できます。両方のクラスターに同じ名前の nginx サービスがある場合、サブマリーナーはローカル アクセスを優先できます。ローカル サービス エンドポイントに障害が発生した場合、他のクラスターの nginx サービスにアクセスできます。デュアルアクティブ サービスの構築を開始できますか? (笑) 。
Antrea
Antrea も同様の方法で実装されています。また、ServiceExport と ServiceImport を組み合わせて ResourceExport と ResourceImport にカプセル化し、マルチクラスター サービスを構築します。各クラスターでは、ノードがゲートウェイとして選択され、ゲートウェイを通じて異なるクラスター トンネルが開かれますマルチクラスターサービスへのアクセスを実現します。
Cilium
Cilium は MultiService の概念を使用せず、グローバル サービスの概念を通じてマルチクラスター アクセス サービス アクセスを構築します。
Kubernetes クラスターを作成して KubeSphere をインストールし、Kubernetes でのさまざまな CNI 機能のアプリケーションを体験します。結局のところ、ページフレンドリーなコンテナ管理プラットフォームを好まないオペレーターがいるでしょうか?
