30장. MetalLB로 로드 밸런싱

30.1. MetalLB 및 MetalLB Operator 정보

클러스터 관리자는 MetalLB Operator를 클러스터에 추가하여 LoadBalancer 유형의 서비스가 클러스터에 추가되면 MetalLB에서 서비스의 외부 IP 주소를 추가할 수 있습니다. 외부 IP 주소가 클러스터의 호스트 네트워크에 추가됩니다.

30.1.1. MetalLB 사용 시기

MetalLB를 사용하는 것은 베어 메탈 클러스터 또는 베어 메탈과 같은 인프라가 있는 경우 중요하며, 외부 IP 주소를 통해 애플리케이션에 내결함성 액세스를 원할 때 중요합니다.

외부 IP 주소의 네트워크 트래픽이 클라이언트에서 클러스터의 호스트 네트워크로 라우팅되도록 네트워킹 인프라를 구성해야 합니다.

MetalLB Operator를 사용하여 MetalLB를 배포한 후 LoadBalancer 유형의 서비스를 추가하면 MetalLB에서 플랫폼 네이티브 로드 밸런서를 제공합니다.

layer2 모드에서 작동하는 MetalLB는 IP 페일오버와 유사한 메커니즘을 사용하여 장애 조치를 지원합니다. 그러나 VRRP(가상 라우터 중복 프로토콜) 및 keepalived를 사용하는 대신 MetalLB는 gossip 기반 프로토콜을 활용하여 노드 오류 인스턴스를 식별합니다. 장애 조치가 감지되면 다른 노드에서 리더 노드의 역할을 가정하고 이러한 변경 사항을 브로드캐스트하도록 적절한 ARP 메시지가 발송됩니다.

계층3 또는 BGP(Border Gateway Protocol) 모드에서 작동하는 MetalLB는 장애 탐지를 네트워크에 위임합니다. OpenShift Container Platform 노드에서 연결을 설정한 BGP 라우터 또는 라우터는 노드 오류를 확인하고 해당 노드에 대한 경로를 종료합니다.

Pod 및 서비스의 고가용성을 보장하는 데 IP 페일오버 대신 MetalLB를 사용하는 것이 좋습니다.

30.1.2. MetalLB Operator 사용자 정의 리소스

MetalLB Operator는 다음 사용자 정의 리소스의 자체 네임스페이스를 모니터링합니다.

MetalLB: 클러스터에 MetalLB 사용자 정의 리소스를 추가하면 MetalLB Operator에서 클러스터에 MetalLB를 배포합니다. Operator는 사용자 정의 리소스의 단일 인스턴스만 지원합니다. 인스턴스가 삭제되면 Operator는 클러스터에서 MetalLB를 제거합니다.
IPAddressPool: MetalLB에는 LoadBalancer 유형의 서비스를 추가할 때 서비스에 할당할 수 있는 하나 이상의 IP 주소 풀이 필요합니다. IPAddressPool 에는 IP 주소 목록이 포함되어 있습니다. 목록은 1.1.1.1-1.1.1.1, CIDR 표기법에 지정된 범위, 하이픈으로 구분된 시작 및 끝 주소로 지정된 범위 또는 세 가지 조합을 사용하여 설정된 단일 IP 주소일 수 있습니다. IPAddressPool 에는 이름이 필요합니다. 이 문서에서는 doc-example,doc-example -reserved, doc- example-ipv6 등의 이름을 사용합니다. MetalLB 컨트롤러는 IPAddressPool 의 주소 풀에서 IP 주소를 할당합니다. L2Advertisement 및 BGPAdvertisement 사용자 정의 리소스를 사용하면 지정된 풀에서 지정된 IP를 알릴 수 있습니다. IPAddressPool 의 IP 주소를 IPAddressPool 의 spec.serviceAllocation 사양을 사용하여 서비스 및 네임스페이스에 할당할 수 있습니다.
참고
단일 IPAddressPool 은 L2 광고 및 BGP 광고에서 참조할 수 있습니다.
BGPPeer: BGP 피어 사용자 지정 리소스는 MetalLB가 통신할 BGP 라우터, 라우터의 AS 번호, MetalLB의 AS 번호, 경로 광고에 대한 사용자 지정을 식별합니다. MetalLB는 서비스 로드 밸런서 IP 주소의 경로를 하나 이상의 BGP 피어에 알립니다.
BFDProfile: BFD 프로필 사용자 정의 리소스는 BGP 피어에 대해 BFD(BFD)를 구성합니다. BFD는 BGP만으로 제공하는 것보다 빠른 경로 실패 탐지 기능을 제공합니다.
L2Advertisement: L2Advertisement 사용자 정의 리소스는 L2 프로토콜을 사용하여 IPAddressPool 에서 들어오는 IP를 알립니다.
BGPAdvertisement: BGPAdvertisement 사용자 정의 리소스는 BGP 프로토콜을 사용하여 IPAddressPool 에서 들어오는 IP를 알립니다.

MetalLB 사용자 정의 리소스를 클러스터에 추가하고 Operator가 MetalLB를 배포하면 컨트롤러 및 speaker MetalLB 소프트웨어 구성 요소가 실행되기 시작합니다.

MetalLB는 모든 관련 사용자 정의 리소스의 유효성을 검사합니다.

30.1.3. MetalLB 소프트웨어 구성 요소

MetalLB Operator를 설치하면 metallb-operator-controller-manager 배포가 Pod를 시작합니다. Pod는 Operator의 구현입니다. Pod는 모든 관련 리소스에 대한 변경 사항을 모니터링합니다.

Operator에서 MetalLB 인스턴스를 시작하면 controller 배포 및 speaker 데몬 세트를 시작합니다.

참고

MetalLB 사용자 정의 리소스에서 배포 사양을 구성하여 컨트롤러 및 발표자 Pod가 클러스터에서 배포 및 실행되는 방법을 관리할 수 있습니다. 이러한 배포 사양에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오.

controller

Operator는 배포 및 단일 Pod를 시작합니다. LoadBalancer 유형의 서비스를 추가하면 Kubernetes는 controller를 사용하여 주소 풀에서 IP 주소를 할당합니다. 서비스 실패의 경우 컨트롤러 Pod 로그에 다음 항목이 있는지 확인합니다.

출력 예

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller

발표자

Operator는 발표자 Pod의 데몬 세트를 시작합니다. 기본적으로 Pod는 클러스터의 각 노드에서 시작됩니다. MetalLB를 시작할 때 MetalLB 사용자 정의 리소스에 노드 선택기를 지정하여 Pod를 특정 노드로 제한할 수 있습니다. 컨트롤러가 서비스에 IP 주소를 할당하고 서비스를 계속 사용할 수 없는 경우 speaker Pod 로그를 읽습니다. speaker pod를 사용할 수 없는 경우 oc describe pod -n 명령을 실행합니다.

계층 2 모드의 경우 컨트롤러에서 서비스에 IP 주소를 할당한 후 speaker Pod는 알고리즘을 사용하여 로드 밸런서 IP 주소를 알릴 speaker Pod를 결정합니다. 알고리즘은 노드 이름과 로드 밸런서 IP 주소를 해시하는 것입니다. 자세한 내용은 "MetalLB 및 외부 트래픽 정책"을 참조하십시오. speaker는 ARP(Address Resolution Protocol)를 사용하여 IPv4 주소를 알리고 NDP(neighbor Discovery Protocol)를 사용하여 IPv6 주소를 알립니다.

BGP(Border Gateway Protocol) 모드의 경우 컨트롤러가 서비스에 IP 주소를 할당한 후 각 speaker pod는 BGP 피어를 사용하여 로드 밸런서 IP 주소를 알립니다. BGP 피어를 사용하여 BGP 세션을 시작하는 노드를 구성할 수 있습니다.

로드 밸런서 IP 주소에 대한 요청은 IP 주소를 알려주는 speaker가 있는 노드로 라우팅됩니다. 노드가 패킷을 수신하면 서비스 프록시가 패킷을 서비스의 엔드포인트로 라우팅합니다. 최적의 경우 엔드포인트가 동일한 노드에 있거나 다른 노드에 있을 수 있습니다. 서비스 프록시는 연결이 설정될 때마다 엔드포인트를 선택합니다.

30.1.4. MetalLB 및 외부 트래픽 정책

계층 2 모드에서는 클러스터의 한 노드에서 서비스 IP 주소에 대한 모든 트래픽을 수신합니다. BGP 모드를 사용하면 호스트 네트워크의 라우터가 새 클라이언트 연결을 위해 클러스터의 노드 중 하나에 대한 연결을 엽니다. 노드가 입력된 후 클러스터에서 트래픽을 처리하는 방법은 외부 트래픽 정책의 영향을 받습니다.

cluster

spec.externalTrafficPolicy의 기본값입니다.

cluster 트래픽 정책을 사용하면 노드가 트래픽을 수신한 후 서비스 프록시에서 서비스의 모든 pod에 트래픽을 배포합니다. 이 정책은 pod에서 균일한 트래픽 배포를 제공하지만 클라이언트 IP 주소가 지워지고 클라이언트 대신 노드에서 트래픽이 시작된 pod의 애플리케이션에 표시될 수 있습니다.

로컬

local 트래픽 정책에서는 노드가 트래픽을 수신한 후 서비스 프록시에서 동일한 노드의 pod에만 트래픽을 보냅니다. 예를 들어 A 노드의 speaker Pod에서 외부 서비스 IP를 알릴 경우 모든 트래픽이 노드 A로 전송됩니다. 트래픽이 노드 A에 진입하면 서비스 프록시는 A 노드에도 있는 서비스의 Pod에만 트래픽을 전송합니다. 추가 노드에 있는 서비스의 Pod는 A 노드에서 트래픽을 받지 않습니다. 추가 노드의 서비스에 대한 Pod는 장애 조치가 필요한 경우 복제본 역할을 합니다.

이 정책은 클라이언트 IP 주소에 영향을 미치지 않습니다. 애플리케이션 pod는 들어오는 연결에서 클라이언트 IP 주소를 확인할 수 있습니다.

참고

다음 정보는 BGP 모드에서 외부 트래픽 정책을 구성할 때 중요합니다.

MetalLB는 모든 적격 노드의 로드 밸런서 IP 주소를 알리지만, 서비스를 로드 밸런싱하는 노드 수는 라우터 용량으로 제한하여 ECMP(Equentity) 경로를 설정할 수 있습니다. IP를 알리는 노드 수가 라우터의 ECMP 그룹 제한보다 크면 라우터에서 IP를 알리는 노드보다 적은 노드를 사용합니다.

예를 들어 외부 트래픽 정책이 로컬 로 설정되어 있고 라우터에 ECMP 그룹 제한이 16으로 설정되어 있고 LoadBalancer 서비스를 구현하는 Pod가 30개의 노드에 배포된 경우 14개의 노드에 배포된 Pod가 트래픽을 수신하지 않습니다. 이 경우 서비스의 외부 트래픽 정책을 cluster 로 설정하는 것이 좋습니다.

30.1.5. 계층 2 모드의 MetalLB 개념

계층 2 모드에서 하나의 노드의 speaker pod는 서비스의 외부 IP 주소를 호스트 네트워크에 알립니다. 네트워크 화면에서 볼 때 노드에는 네트워크 인터페이스에 할당된 여러 IP 주소가 있는 것으로 보입니다.

참고

계층 2 모드에서 MetalLB는 ARP 및 NDP를 사용합니다. 이러한 프로토콜은 특정 서브넷 내에서 로컬 주소 확인을 구현합니다. 이 컨텍스트에서 클라이언트는 MetalLB가 작동하도록 서비스를 발표하는 노드와 동일한 서브넷에 존재하는 MetalLB에서 할당한 VIP에 연결할 수 있어야 합니다.

speaker pod는 IPv6에 대한 IPv4 서비스 및 NDP 요청에 대한 ARP 요청에 응답합니다.

계층 2 모드에서는 서비스 IP 주소의 모든 트래픽이 하나의 노드를 통해 라우팅됩니다. 트래픽이 노드에 진입하면 CNI 네트워크 공급자의 서비스 프록시에서 서비스의 모든 Pod에 트래픽을 배포합니다.

서비스의 모든 트래픽이 계층 2 모드에서 단일 노드를 통해 시작되기 때문에 MetalLB는 계층 2에 대한 로드 밸런서를 구현하지 않습니다. 대신 MetalLB는 speaker pod를 사용할 수 없게 되는 계층 2에 대한 페일오버 메커니즘을 구현하여 다른 노드의 speaker Pod에서 서비스 IP 주소를 알릴 수 있습니다.

노드를 사용할 수 없게 되면 장애 조치가 자동으로 수행됩니다. 다른 노드의 speaker Pod는 노드를 사용할 수 없음을 감지하고 새 speaker Pod 및 노드가 실패한 노드에서 서비스 IP 주소의 소유권을 가져옵니다.

이전 그림에서는 MetalLB와 관련된 다음 개념을 보여줍니다.

애플리케이션은 172.130.0.0/16 서브넷에 클러스터 IP가 있는 서비스를 통해 사용할 수 있습니다. 이 IP 주소는 클러스터 내부에서 액세스할 수 있습니다. 서비스에는 MetalLB가 서비스에 할당된 외부 IP 주소 192.168.100.200도 있습니다.
노드 1 및 3에는 애플리케이션용 pod가 있습니다.
speaker 데몬 세트는 각 노드에서 Pod를 실행합니다. MetalLB Operator는 이러한 Pod를 시작합니다.
각 speaker pod는 호스트 네트워크 포드입니다. pod의 IP 주소는 호스트 네트워크에 있는 노드의 IP 주소와 동일합니다.
노드 1의 speaker pod는 ARP를 사용하여 서비스의 외부 IP 주소 192.168.100.200을 알립니다. 외부 IP 주소를 발표하는 speaker pod는 서비스의 엔드포인트와 동일한 노드에 있어야 하며 엔드포인트는 Ready 상태에 있어야 합니다.
클라이언트 트래픽은 호스트 네트워크로 라우팅되고 192.168.100.200 IP 주소에 연결됩니다. 트래픽이 노드로 전환되면 서비스 프록시는 서비스에 설정한 외부 트래픽 정책에 따라 동일한 노드 또는 다른 노드의 애플리케이션 pod로 트래픽을 전송합니다.
- 서비스의 외부 트래픽 정책이 cluster 로 설정되면 speaker pod가 실행 중인 노드에서 192.168.100.200 로드 밸런서 IP 주소를 알리는 노드가 선택됩니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다.
- 서비스의 외부 트래픽 정책이 로컬 로 설정되면 192.168.100.200 로드 밸런서 IP 주소를 알리는 노드가 speaker pod가 실행 중인 노드와 서비스 끝점에서 선택됩니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다. 이전 그림에서 노드 1 또는 3은 192.168.100.200 을 알립니다.
노드 1을 사용할 수 없게 되면 외부 IP 주소가 다른 노드로 장애 조치됩니다. 애플리케이션 pod 및 서비스 엔드포인트의 인스턴스가 있는 다른 노드에서 speaker pod는 외부 IP 주소 192.168.100.200을 알리기 시작하고 새 노드는 클라이언트 트래픽을 수신합니다. 다이어그램에서 유일한 후보는 노드 3입니다.

30.1.6. BGP 모드의 MetalLB 개념

BGP 모드에서 기본적으로 각 speaker pod는 서비스의 로드 밸런서 IP 주소를 각 BGP 피어에 알립니다. 또한 선택적 BGP 피어 목록을 추가하여 지정된 풀에서 특정 피어 세트로 제공되는 IP를 알릴 수도 있습니다. BGP 피어는 일반적으로 BGP 프로토콜을 사용하도록 구성된 네트워크 라우터입니다. 라우터가 로드 밸런서 IP 주소에 대한 트래픽을 수신하면 라우터는 IP 주소를 알리는 speaker Pod가 있는 노드 중 하나를 선택합니다. 라우터는 트래픽을 해당 노드로 전송합니다. 트래픽이 노드에 진입하면 CNI 네트워크 플러그인의 서비스 프록시에서 서비스의 모든 Pod에 트래픽을 배포합니다.

클러스터 노드와 동일한 계층 2 네트워크 세그먼트의 직접 연결된 라우터는 BGP 피어로 구성할 수 있습니다. 직접 연결된 라우터가 BGP 피어로 구성되지 않은 경우 로드 밸런서 IP 주소의 패킷이 speaker Pod를 실행하는 BGP 피어와 클러스터 노드 간에 라우팅되도록 네트워크를 구성해야 합니다.

라우터가 로드 밸런서 IP 주소에 대한 새 트래픽을 수신할 때마다 노드에 대한 새 연결을 생성합니다. 각 라우터 제조업체에는 연결을 시작할 노드를 선택하기 위한 구현별 알고리즘이 있습니다. 그러나 알고리즘은 일반적으로 네트워크 로드의 균형을 조정하기 위해 사용 가능한 노드에 트래픽을 배포하도록 설계되었습니다.

노드를 사용할 수 없게 되면 라우터는 로드 밸런서 IP 주소를 알리는 speaker pod가 있는 다른 노드로 새 연결을 시작합니다.

그림 30.1. BGP 모드의 MetalLB 토폴로지 다이어그램

호스트 네트워크 10.0.1.0/24의 speaker Pod는 BGP를 사용하여 로드 밸런서 IP 주소인 203.0.113.200을 라우터에 알립니다.

이전 그림에서는 MetalLB와 관련된 다음 개념을 보여줍니다.

애플리케이션은 172.130.0.0/16 서브넷에 IPv4 클러스터 IP가 있는 서비스를 통해 사용할 수 있습니다. 이 IP 주소는 클러스터 내부에서 액세스할 수 있습니다. 서비스에는 MetalLB가 서비스에 할당된 외부 IP 주소인 203.0.113.200 도 있습니다.
노드 2 및 3에는 애플리케이션용 pod가 있습니다.
speaker 데몬 세트는 각 노드에서 Pod를 실행합니다. MetalLB Operator는 이러한 Pod를 시작합니다. speaker Pod를 실행하는 노드를 지정하도록 MetalLB를 구성할 수 있습니다.
각 speaker pod는 호스트 네트워크 포드입니다. pod의 IP 주소는 호스트 네트워크에 있는 노드의 IP 주소와 동일합니다.
각 speaker pod는 모든 BGP 피어로 BGP 세션을 시작하고 로드 밸런서 IP 주소 또는 집계 경로를 BGP 피어에 알립니다. 발표자 Pod는 Autonomous System 65010의 일부임을 알립니다. 다이어그램은 동일한 Autonomous 시스템 내의 BGP 피어로 R1 라우터를 보여줍니다. 그러나 다른 Autonomous Systems에 속하는 피어와 BGP 세션을 시작하도록 MetalLB를 구성할 수 있습니다.
로드 밸런서 IP 주소를 알리는 speaker pod가 있는 모든 노드는 서비스에 대한 트래픽을 수신할 수 있습니다.
- 서비스의 외부 트래픽 정책이 cluster 로 설정된 경우 speaker pod가 실행 중인 모든 노드에서 203.0.113.200 로드 밸런서 IP 주소를 알리고 speaker pod가 있는 모든 노드는 서비스에 대한 트래픽을 수신할 수 있습니다. 외부 트래픽 정책이 cluster로 설정된 경우에만 호스트 접두사는 라우터 피어에 광고됩니다.
- 서비스의 외부 트래픽 정책이 local 로 설정된 경우 speaker pod가 실행 중인 모든 노드가 있고 서비스 끝점이 실행 중인 모든 노드는 203.0.113.200 로드 밸런서 IP 주소를 알릴 수 있습니다. 해당 노드만 서비스에 대한 트래픽을 수신할 수 있습니다. 이전 그래픽에서 노드 2 및 3은 203.0.113.200 을 알립니다.
BGP 피어 사용자 정의 리소스를 추가할 때 노드 선택기를 지정하여 특정 BGP 피어로 BGP 세션을 시작하도록 MetalLB를 구성할 수 있습니다.
BGP를 사용하도록 구성된 R1과 같은 라우터는 BGP 피어로 설정할 수 있습니다.
클라이언트 트래픽은 호스트 네트워크의 노드 중 하나로 라우팅됩니다. 트래픽이 노드로 전환되면 서비스 프록시는 서비스에 설정한 외부 트래픽 정책에 따라 동일한 노드 또는 다른 노드의 애플리케이션 pod로 트래픽을 전송합니다.
노드를 사용할 수 없게 되면 라우터에서 오류를 감지하고 다른 노드와의 새 연결을 시작합니다. BGP 피어에 대해 BFD(Bidirectional Forwarding Detection) 프로필을 사용하도록 MetalLB를 구성할 수 있습니다. BFD는 더 빠른 링크 실패 탐지 기능을 제공하여 라우터가 BFD 없이 이전에 새 연결을 시작할 수 있도록 합니다.

30.1.7. 제한 사항

30.1.7.1. MetalLB의 인프라 고려 사항

MetalLB는 기본적으로 베어 메탈 설치에 유용합니다. 이러한 설치에는 기본 로드 밸런서 기능이 포함되어 있지 않기 때문입니다. 베어 메탈 설치 외에도 일부 인프라에 OpenShift Container Platform을 설치할 때 기본 로드 밸런서 기능이 포함되지 않을 수 있습니다. 예를 들어 다음 인프라는 MetalLB Operator를 추가하는 데 도움이 될 수 있습니다.

베어 메탈
VMware vSphere
IBM Z® 및 IBM® LinuxONE
IBM Z® 및 IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
IBM Power®

30.1.7.2. 계층 2 모드에 대한 제한 사항

30.1.7.2.1. 단일 노드 성능 장애

MetalLB는 단일 노드를 통해 서비스에 대한 모든 트래픽을 라우팅합니다. 이 노드는 병목 현상을 일으키고 성능을 제한할 수 있습니다.

계층 2 모드는 서비스의 수신 대역폭을 단일 노드의 대역폭으로 제한합니다. 이는 ARP 및 NDP를 사용하여 트래픽을 전달하는 기본 제한 사항입니다.

30.1.7.2.2. 페일오버 성능 저하

노드 간 페일오버는 클라이언트와의 협업에 따라 달라집니다. 페일오버가 발생하면 MetalLB에서 적절한 ARP 패킷을 전송하여 서비스에 연결된 MAC 주소가 변경되었음을 알립니다.

대부분의 클라이언트 운영 체제는 적절한 ARP 패킷을 올바르게 처리하고 인접 캐시를 즉시 업데이트합니다. 클라이언트에서 캐시를 빠르게 업데이트하면 몇 초 내에 페일오버가 완료됩니다. 일반적으로 클라이언트는 10초 내에 새 노드로 페일오버합니다. 그러나 일부 클라이언트 운영 체제는 적절한 ARP 패킷을 전혀 처리하지 않거나 캐시 업데이트를 지연하는 오래된 구현을 보유하고 있습니다.

Windows, macOS 및 Linux와 같은 일반적인 운영 체제의 최신 버전은 계층 2 페일오버를 올바르게 구현합니다. 오래되고 덜 일반적인 클라이언트 운영 체제를 제외하고는 느린 페일오버 문제가 발생하지 않습니다.

계획된 페일오버가 오래된 클라이언트에 미치는 영향을 최소화하려면 리더십 전환 후 몇 분 동안 이전 노드를 계속 실행하십시오. 이전 노드는 캐시가 새로 고쳐질 때까지 오래된 클라이언트의 트래픽을 계속 전달할 수 있습니다.

계획되지 않은 페일오버가 발생하면 오래된 클라이언트가 캐시 항목을 새로 고칠 때까지 서비스 IP에 연결할 수 없습니다.

30.1.7.2.3. 추가 네트워크 및 MetalLB는 동일한 네트워크를 사용할 수 없습니다.

MetalLB 및 소스 Pod에 설정된 추가 네트워크 인터페이스에 동일한 VLAN을 사용하면 연결에 실패할 수 있습니다. 이는 MetalLB IP와 소스 Pod가 모두 동일한 노드에 있는 경우 발생합니다.

연결 실패를 방지하려면 소스 Pod가 있는 것과 다른 서브넷에 MetalLB IP를 배치합니다. 이 구성을 사용하면 소스 Pod의 트래픽이 기본 게이트웨이를 사용할 수 있습니다. 결과적으로 OVN 오버레이 네트워크를 사용하여 트래픽이 효과적으로 대상에 도달하여 연결이 의도한 대로 작동하도록 할 수 있습니다.

30.1.7.3. BGP 모드에 대한 제한 사항

30.1.7.3.1. 노드 장애로 인해 모든 활성 연결이 중단될 수 있습니다.

MetalLB는 BGP 기반 로드 밸런싱에 공통된 제한을 공유합니다. BGP 세션이 종료되면 노드가 실패하거나 speaker Pod가 다시 시작되면 세션 종료로 모든 활성 연결이 재설정될 수 있습니다. 최종 사용자는 피어 메시지로 연결 재설정이 발생할 수 있습니다.

종료된 BGP 세션의 결과는 각 라우터 제조업체에 따라 구현됩니다. 그러나 발표자 Pod 수가 변경되어 BGP 세션 수에 영향을 미치고 BGP 피어와의 활성 연결이 끊어질 것으로 예상할 수 있습니다.

서비스 중단 가능성을 방지하거나 줄이기 위해 BGP 피어를 추가할 때 노드 선택기를 지정할 수 있습니다. BGP 세션을 시작하는 노드 수를 제한하면 BGP 세션이 없는 노드에 대한 오류는 서비스 연결에 영향을 미치지 않습니다.

30.1.7.3.2. 단일 ASN 및 단일 라우터 ID만 지원

BGP 피어 사용자 지정 리소스를 추가할 때 spec.myASN 필드를 지정하여 MetalLB가 속한 Autonomous System Number(ASN)를 식별합니다. OpenShift Container Platform에서는 MetalLB가 단일 ASN에 속해야 하는 MetalLB와 함께 BGP 구현을 사용합니다. BGP 피어를 추가하고 기존 BGP 피어 사용자 지정 리소스와 spec.myASN 에 대해 다른 값을 지정하려고 하면 오류가 발생합니다.

마찬가지로 BGP 피어 사용자 지정 리소스를 추가하면 spec.routerID 필드는 선택 사항입니다. 이 필드에 값을 지정하는 경우 추가한 다른 모든 BGP 피어 사용자 정의 리소스에 대해 동일한 값을 지정해야 합니다.

단일 ASN 및 단일 라우터 ID를 지원하는 제한은 MetalLB의 커뮤니티 지원 구현과 다릅니다.