問題

問題

同じ IP セグメント 172.26.10.XX を使用して、3 つのマスター ノードと 6 つのワーカー ノードをセットアップしました。

ロード バランサー サービスの場合、構成名前空間の詳細が以下のとおりのロード バランサーに Kube-Vip を使用しています。

Data
====
cidr-private-app:
----
172.26.10.XX/27
range-global:
----
172.26.16.XX-172.26.16.XX
range-public-app:
----
172.26.14.XX-172.26.14.XX

BinaryData

IP 172.26.10.XX でサービス LB を公開しようとすると、問題なく in/out クラスターにアクセスできます。しかし、LB IP 172.26.16.XX および 172.26.14.XX でサービスを公開しようとすると、クラスター ノード内でのみアクセスでき、クラスター外ではアクセスできません。何か問題がありますか? アドバイスをいただければ幸いです。

了解しました:

K8S: v1.27.7+k3s2 KUBE-VIP: 0.6.4 ファイアウォール ルール: Ips セグメント 172.26.10.XX、172.26.16.XX、および 172.26.14.XX を持つサーバー間のすべての通信を許可

すべてのノードを再起動し、ファイアウォールの構成を確認します。

LB が異なる IP セグメントを持つ IP アドレスをサーフィンできることを期待しています。

答え1

問題

172.26.16.0 は 172.26.10.0/27 とは異なるサブネットです。kube-vip が正しいルートを追加するため、クラスター内のホストは 172.26.16.0 サブネットのルーティング情報を持ちます。クラスター外のホストは、特に指示されない限り (何かがルートを更新しているため)、このサブネットがどこにあるかわかりません。ルートがないホストは、通常ネットワーク上のルーターであるデフォルト ルートを使用します。そのルーターが 172.26.16.0 がどこにあるか分からない場合、パケットをドロップするか、ルーティングします。そのデフォルトルート。

ホストが設定されているサブネット内の IP を使用すると、他のホストは同じネットワーク内のホストに情報を送信していることを認識し、ARP を使用して宛先の MAC アドレスを検索し、そのホストにフレームを送信します。

クラスタ内外のノード上のルーティングテーブルを調べることができます。

ip route show table all

要約: ネットワーク間を横断するにはルーターが必要です。Kubernetesノードはルーターとして動作するため、クラスター内から通信が行われます。

解決

おそらく最も簡単な方法は、クラスター外のホストが IP にアクセスできるようにする場合、ホスト サブネットの一部である IP を使用することです。たとえば、ホストがサブネット 172.26.10.0/27 にある場合、VIP には 172.26.10.24/29 (.24 - .31) を使用します。

別のオプションとして、Kubernetes の外部のホストに静的ルートを設定し、Kubernetes ノードをゲートウェイとして使用して VIP ネットワークを見つけられるようにします。ノードが 172.26.10.1、.2、.3 の場合、k8s 外部のホストには次のようなルートがあります。172.26.16.0/24 via 172.26.10.1

別のオプション: k8s が使用する外部のルーター ホストにルートを設定し、ルーターがトラフィックを VIP ネットワークに送り返すようにします (ルーターでは、同じインターフェイスに構成されているサブネットごとに IP アドレスが必要になる可能性があります)

別のオプションとして、ロード バランサー VIP と同じサブネットにある k8s 外部の各ホストにセカンダリ IP を追加します。

別のオプション: RIP や OSPF などのルーティング プロトコルを設定して、k8s 外部のホストが k8s クラスター内のネットワークについて学習できるようにします (一部の CNI は Calico w/ BGP のようにこれを実行します)

関連情報