동일한 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
tldr; 네트워크 간을 교차하려면 라우터가 필요합니다. Kubernetes 노드가 라우터 역할을 하므로 클러스터 내부에서 통신이 작동합니다.
해결책
아마도 가장 쉬운 방법은 클러스터 외부의 호스트가 IP에 도달할 수 있도록 하려면 호스트 서브넷의 일부인 IP를 사용하는 것입니다. 예를 들어 호스트가 서브넷 172.26.10.0/27에 있는 경우 VIP에 172.26.10.24/29(.24 - .31)를 사용합니다.
또 다른 옵션; Kubernetes 노드를 게이트웨이로 사용하여 VIP 네트워크를 찾을 수 있음을 알려주는 Kubernetes 외부 호스트에 정적 경로를 설정합니다. 노드가 172.26.10.1, .2, .3인 경우 k8s 외부의 호스트는 다음과 같은 경로를 갖습니다.172.26.16.0/24 via 172.26.10.1
또 다른 옵션; k8s 외부의 라우터 호스트에 경로를 설정하고 라우터가 VIP 네트워크로 트래픽을 다시 보내도록 합니다(라우터에는 동일한 인터페이스에 구성된 각 서브넷에 대한 IP 주소가 필요할 수 있습니다).
또 다른 옵션; 로드 밸런서 VIP와 동일한 서브넷에 있는 k8s 외부의 각 호스트에 보조 IP를 추가합니다.
또 다른 옵션; k8s 외부 호스트가 k8s 클러스터 내부 네트워크에 대해 배울 수 있도록 RIP 또는 OSPF와 같은 라우팅 프로토콜을 설정합니다(일부 CNI는 BGP가 있는 Calico와 같이 이를 수행함).