少し前まで、私は MetalLB のルーティングを設定するという非常に珍しいタスクに直面していました。 すべてうまくいくでしょう、なぜなら... 通常、MetalLB には追加のアクションは必要ありませんが、この場合、非常に単純なネットワーク構成を持つかなり大規模なクラスターがあります。

この記事では、クラスターの外部ネットワークに対してソースベースおよびポリシーベースのルーティングを構成する方法を説明します。

すでにある程度の経験があると思うので、MetalLB のインストールと構成については詳しく説明しません。 いきなり本題、つまりルーティングの設定に進むことをお勧めします。 したがって、次の XNUMX つのケースがあります。

ケース 1: 設定が不要な場合

簡単なケースを見てみましょう。

MetalLB によって発行されたアドレスがノードのアドレスと同じサブネット内にある場合、追加のルーティング構成は必要ありません。

たとえば、サブネットがあるとします。 192.168.1.0/24、ルーターがあります 192.168.1.1、ノードはアドレスを受け取ります。 192.168.1.10-30次に、MetalLB の場合は範囲​​を調整できます。 192.168.1.100-120 追加の構成を行わなくても動作することを確認してください。

何故ですか？ ノードにはすでにルートが構成されているため、次のようになります。

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

また、同じ範囲のアドレスは追加のアクションなしで再利用されます。

ケース 2: 追加のカスタマイズが必要な場合

ノードに IP アドレスが設定されていない場合、または MetalLB がアドレスを発行するサブネットへのルートがない場合は、必ず追加のルートを設定する必要があります。

もう少し詳しく説明します。 MetalLB がアドレスを出力するときは常に、次のような単純な割り当てと比較できます。

ip addr add 10.9.8.7/32 dev lo

注意を払う：

• a) アドレスにはプレフィックスが割り当てられます /32 つまり、ルートはそのサブネットに自動的に追加されません (これは単なるアドレスです)。
• b) アドレスは任意のノード インターフェイス (ループバックなど) に付加されます。 ここで、Linux ネットワーク スタックの機能について言及する価値があります。 どのインターフェイスにアドレスを追加しても、カーネルは常に arp リクエストを処理し、それらのいずれかに arp レスポンスを送信します。この動作は正しいと考えられており、さらに、Kubernetes などの動的環境で非常に広く使用されています。

この動作は、たとえば strict arp を有効にすることでカスタマイズできます。

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

この場合、arp 応答は、インターフェイスに特定の IP アドレスが明示的に含まれている場合にのみ送信されます。 MetalLB を使用する予定があり、kube-proxy が IPVS モードで実行されている場合は、この設定が必要です。

ただし、MetalLB は arp リクエストの処理にカーネルを使用せず、ユーザー空間でそれ自体を実行するため、このオプションは MetalLB の動作には影響しません。

私たちの仕事に戻りましょう。 発行されたアドレスのルートがノードに存在しない場合は、事前にすべてのノードにルートを追加します。

ip route add 10.9.8.0/24 dev eth1

ケース 3: ソースベースのルーティングが必要な場合

デフォルトで構成されているゲートウェイではなく、別のゲートウェイ経由でパケットを受信する場合は、ソースベースのルーティングを構成する必要があるため、応答パケットも同じゲートウェイを通過する必要があります。

たとえば、同じサブネットがあるとします。 192.168.1.0/24 ノード専用ですが、MetalLB を使用して外部アドレスを発行したいと考えています。 サブネットから複数のアドレスがあると仮定します。 1.2.3.0/24 VLAN 100 にあり、それらを使用して外部から Kubernetes サービスにアクセスしたいと考えています。

お問い合わせの際 1.2.3.4 とは異なるサブネットからリクエストを行うことになります 1.2.3.0/24 そして答えを待ちます。 MetalLB が発行したアドレスの現在マスターであるノード 1.2.3.4、ルーターからパケットを受信します 1.2.3.1しかし、彼にとっての答えは必然的に同じルートをたどる必要があります。 1.2.3.1.

このノードにはすでにデフォルト ゲートウェイが設定されているため、 192.168.1.1、その場合、デフォルトでは、応答は彼に送信され、彼には送信されません。 1.2.3.1、それを通じて荷物を受け取りました。

この状況にどう対処すればよいでしょうか?

この場合、追加の構成を行わずに外部アドレスを提供できるようにすべてのノードを準備する必要があります。 つまり、上記の例では、事前にノード上に VLAN インターフェイスを作成する必要があります。

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

次に、ルートを追加します。

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ルートは別のルーティング テーブルに追加されることに注意してください。 100 ゲートウェイ経由で応答パケットを送信するために必要なルートは XNUMX つだけ含まれます。 1.2.3.1、インターフェイスの後ろにあります eth0.100.

次に、簡単なルールを追加する必要があります。

ip rule add from 1.2.3.0/24 lookup 100

これは明示的に次のように述べています: パケットの送信元アドレスが 1.2.3.0/24、その場合はルーティング テーブルを使用する必要があります 100。 その中で私たちはすでに彼を送り出すルートを説明しました 1.2.3.1

ケース 4: ポリシーベースのルーティングが必要な場合

ネットワーク トポロジは前の例と同じですが、外部プール アドレスにもアクセスできるようにしたいとします。 1.2.3.0/24 ポッドから:

特徴的なのは、次のアドレスにアクセスすると、 1.2.3.0/24、応答パケットはノードに到達し、送信元アドレスが範囲内にあります。 1.2.3.0/24 素直に送られてくるよ eth0.100ただし、Kubernetes が元のリクエストを生成した最初のポッドにリダイレクトするようにしたいと考えています。

この問題の解決は難しいことが判明しましたが、ポリシーベースのルーティングのおかげで可能になりました。

プロセスをよりよく理解するために、netfilter のブロック図を次に示します。

まず、前の例と同様に、追加のルーティング テーブルを作成しましょう。

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

次に、iptables にいくつかのルールを追加しましょう。

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

これらのルールは、インターフェイスへの受信接続をマークします。 eth0.100、すべてのパケットにタグを付ける 0x100、同じ接続内の応答も同じタグでマークされます。

これで、ルーティング ルールを追加できます。

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

つまり、送信元アドレスを持つすべてのパケット 1.2.3.0/24 そしてタグ付け 0x100 テーブルを使用してルーティングする必要があります 100.

したがって、別のインターフェイスで受信された他のパケットはこのルールの対象ではないため、標準の Kubernetes ツールを使用してルーティングできます。

もう XNUMX つ、Linux にはいわゆるリバース パス フィルタがあり、これがすべてを台無しにしてしまいます。これは簡単なチェックを実行します。すべての受信パケットに対して、パケットのソース アドレスを送信者アドレスで変更し、次のことをチェックします。パケットは受信したのと同じインターフェイスを介して送信できますが、そうでない場合はフィルタリングされます。

問題は、この場合は正しく機能しないことですが、無効にすることはできます。

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

最初のコマンドは rp_filter のグローバル動作を制御することに注意してください。これが無効になっていない場合、XNUMX 番目のコマンドは効果がありません。 ただし、残りのインターフェイスは rp_filter が有効になったままになります。

フィルターの操作を完全に制限しないようにするために、netfilter の rp_filter 実装を使用できます。 rpfilter を iptables モジュールとして使用すると、次のような非常に柔軟なルールを構成できます。

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

インターフェイスで rp_filter を有効にする eth0.100 を除くすべてのアドレス 1.2.3.0/24.

出所： habr.com