https://metallb.universe.tf/concepts/layer2/
metalLB 공식 문서를 읽고 정리한 내용입니다.
Metal...LB..?
layer 2모드에서는 서비스 IP에 대한 모드는 트래픽이 하나에 노드로 가게 된다. 그 후, kube-proxy에 의해 트래픽들이 서비스 파드로 분산되게 된다.
따라서 layer 2모드에서는 load balaner이라고 보기는 어렵지만, failover 기능이 구현되어 있기 때문에 리더인 노드에 특정한 이유로 장애가 날지라도 다른 노드로 자동으로 리더 역할이 넘어가게 된다.
memberlist에 의해 장애노드가 감지 되고, 새로운 노드는 장애 노드로부터 IP를 가져오게 된다.
layer 2 mode의 한계
layer 2 모드에서는 2가지의 주요한 한계가 있습니다.
- single-node bottlenecking
- potentially slow failover
위에서 언급했듯이 layer 2 모드의 단일 리더 노드는 서비스 IP에 대한 모든 트래픽을 처리합니다. 따라서 모든 서비스 인그레스의 대역폭은 단일 노드의 대역폭으로 제한됩니다. 이는 ARP와 NDP를 사용하여 트래픽을 제어하는 경우의 근본적인 제한입니다.
현재 구현에서, 노드간의 failover는 클라이언트로 부터의 cooperation에 따라 달라집니다. failover가 발생할 때, MetalLB는 클라이언트에게 서비스 IP와 연결된 MAC주소가 변경되었다고 수 많은 gratuitous layer 2 패킷을 전송합니다.
대부분의 운영체제는 gratuitous 패킷을 정확히 처리하고 주변의 캐시를 즉시 업데이트 합니다. 이 상황에서 failover는 몇 초내에 발생합니다. 그치만, 몇몇 시스템은 gratuitous 처리가 전부 구현되어 있지 않거나 캐시 업데이트에 지연이 있는 buggy 구현시스템을 가지고 있습니다.
모든 주요 OS (windows, Mac, Linux) 상용 버전은 layer 2 failover가 구현되어 있어, 이러한 상황은 예전 버전이나 혹은 주요하지 않은 OS에서 발생됩니다.
buggy 클라이언트에서의 계획된 failover 영향을 최소화하기 위해, 이전 리더는 리더 이전 이후 몇 분동안 리더를 유지해야 하며 캐시가 새로고침 되기 전까지 이전 클라이언트에서 트래픽이 계속해서 전송될 수 있도록 해야합니다.
예상치 못한 failover 동안에 서비스 IP는 buggy 클라이언트가 전체 캐시를 업데이트 하기 전까지 접근할 수 없을 것 입니다.
Keepalived와의 비교
layer 2 모드는 Keepalived와 유사한 점이 많아 Keeaplived에 익숙하다면 꽤 친숙하게 느껴질 것 입니다. 그치만 몇 가지 차이도 있습니다. keepalived에 익숙하다면 읽지 않으셔도 좋습니다.
Keepalived는 Virtual Router Redundancy Protocol (VRRP)를 사용합니다. Keepalived 인스턴스는 리더를 선출하고 리더가 사라질 때 알리기 위해 지속적으로 VRRP 메시지를 각각 주고 받습니다.
반면, MetalLB는 클러스터 내의 노드가 더 이상 접근이 불가하고 해당 노드의 서비스 IP를 다른 곳으로 이동해야하는 경우를 meberlist를 사용하여 파악합니다.
Keepalived와 MetalLB는 클라이언트 입장에서 보면 같습니다. failover가 발생할 때, 서비스 IP 주소는 한 노드에서 다른 노드로 전환된 것 처럼 보이고, 남은 시간동안 노드가 하나 이상의 IP를 가진 것 처럼 보입니다.
VRRP를 사용하지 않기 때문에, MetalbLB VRRP의 일부 위험에 영향을 받지 않습니다. 예를 들어, 네트워크 당 255의 로드밸런서 VRRP 제한이 MetalLB에는 없습니다. 네트워크에서 사용할 수 있는 많은 load-balanced IP들을 원하는 만큼 가질 수 있습니다. MetalLB는 또한 VRRP보다 구성이 덜 필요합니다. 예를 들어 가상 라우터 ID가 없습니다.
반면, MetalLB는 클러스터 구성원 정보를 위해 구성원 목록에 의존하기 때문에 타사 VRRP 인식 라우터 및 인프라와 상호 운용할 수 없습니다. 이것은 의도한 대로 작동합니다: MetalLB는 Kubernetes 클러스터 내에서 로드 밸런싱 및 failover를 제공하도록 특별히 설계되었으며, 이러한 시나리오에서는 타사 LB 소프트웨어와의 상호 운용성이 범위를 벗어납니다.
