얼마 전 나는 MetalLB에 대한 라우팅을 설정하는 매우 특이한 작업에 직면했습니다. 다 괜찮을 텐데 왜냐면... 일반적으로 MetalLB에는 추가 작업이 필요하지 않지만 우리의 경우 매우 간단한 네트워크 구성을 갖춘 상당히 큰 클러스터가 있습니다.

이 문서에서는 클러스터의 외부 네트워크에 대해 소스 기반 및 정책 기반 라우팅을 구성하는 방법을 설명합니다.

여러분이 이미 경험이 있다고 가정하므로 MetalLB 설치 및 구성에 대해 자세히 설명하지 않겠습니다. 바로 요점, 즉 라우팅 설정으로 넘어가는 것이 좋습니다. 따라서 네 가지 경우가 있습니다.

사례 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와 같은 동적 환경에서 상당히 널리 사용됩니다.

예를 들어 엄격한 arp를 활성화하여 이 동작을 사용자 정의할 수 있습니다.

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

이 경우 인터페이스에 특정 IP 주소가 명시적으로 포함되어 있는 경우에만 arp 응답이 전송됩니다. 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 게이트웨이를 통해 응답 패킷을 보내는 데 필요한 두 개의 경로만 포함됩니다. 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 도구를 사용하여 라우팅할 수 있습니다.

한 가지 더 있는데, Linux에는 전체 라즈베리를 손상시키는 소위 역방향 경로 필터가 있는데, 이는 간단한 검사를 수행합니다. 들어오는 모든 패킷에 대해 패킷의 소스 주소를 보낸 사람 주소로 변경하고 여부를 확인합니다. 패킷은 수신된 것과 동일한 인터페이스를 통해 나갈 수 있으며, 그렇지 않은 경우 필터링됩니다.

문제는 우리의 경우 올바르게 작동하지 않지만 비활성화할 수 있다는 것입니다.

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

첫 번째 명령은 rp_filter의 전역 동작을 제어합니다. 비활성화되지 않은 경우 두 번째 명령은 아무런 효과가 없습니다. 그러나 나머지 인터페이스는 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