23장. MetalLB로 로드 밸런싱


23.1. MetalLB 및 MetalLB Operator 정보

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

23.1.1. MetalLB 사용 시기

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

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

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

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

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

MetalLB
클러스터에 MetalLB 사용자 정의 리소스를 추가하면 MetalLB Operator에서 클러스터에 MetalLB를 배포합니다. Operator는 사용자 정의 리소스의 단일 인스턴스만 지원합니다. 인스턴스가 삭제되면 Operator는 클러스터에서 MetalLB를 제거합니다.
AddressPool
MetalLB에는 LoadBalancer 유형의 서비스를 추가할 때 서비스에 할당할 수 있는 하나 이상의 IP 주소 풀이 필요합니다. AddressPool 사용자 정의 리소스를 클러스터에 추가하면 MetalLB Operator에서 풀에서 IP 주소를 할당할 수 있도록 MetalLB를 구성합니다. 주소 풀에는 IP 주소 목록이 포함됩니다. 목록은 범위(예: 1.1.1.1-1.1.1.1)를 사용하여 설정된 단일 IP 주소일 수 있습니다(예: 1.1.1.1-1.1.1.1), CIDR 표기법에 지정된 범위, 하이픈으로 구분된 시작 및 종료 주소로 지정된 범위 또는 세 가지 조합의 조합일 수 있습니다. 주소 풀에는 이름이 필요합니다. 이 문서에서는 doc-example,doc-example -reserved, doc- example-ipv6 등의 이름을 사용합니다. 주소 풀은 MetalLB가 풀에서 IP 주소를 자동으로 할당할 수 있는지 또는 IP 주소를 이름으로 명시적으로 지정하는 서비스에 예약되어 있는지 여부를 지정합니다.

MetalLB 사용자 정의 리소스를 클러스터에 추가하고 Operator에서 MetalLB를 배포하면 MetalLB 소프트웨어 구성 요소, controllerspeaker가 실행됩니다.

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

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

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

controller

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

출력 예

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

speaker

Operator는 클러스터의 각 노드에 대해 하나의 speaker Pod를 사용하여 데몬 세트를 시작합니다. 컨트롤러가 서비스에 IP 주소를 할당하고 서비스를 계속 사용할 수 없는 경우 speaker Pod 로그를 읽습니다. speaker 포드를 사용할 수 없는 경우 oc describe pod -n 명령을 실행합니다.

계층 2 모드의 경우 controller에서 서비스에 IP 주소를 할당한 후 각 speaker pod에서 서비스의 엔드포인트와 동일한 노드에 있는지 확인합니다. 노드 이름 및 서비스 이름을 해시하는 데 필요한 알고리즘은 로드 밸런서 IP 주소를 알릴 단일 speaker pod를 선택하는 데 사용됩니다. speaker는 ARP(Address Resolution Protocol)를 사용하여 IPv4 주소를 알리고 NDP(neighbor Discovery Protocol)를 사용하여 IPv6 주소를 알립니다.

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

23.1.4. 계층 2 모드의 MetalLB 개념

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

참고

계층 2 모드는 ARP 및 NDP에 의존하기 때문에 클라이언트는 MetalLB가 작동하기 위해 서비스를 중단하는 노드와 동일한 서브넷에 있어야 합니다. 또한 서비스에 할당된 IP 주소는 클라이언트가 서비스에 도달하기 위해 사용하는 네트워크의 동일한 서브넷에 있어야 합니다.

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 및 계층 2 모드의 개념 다이어그램

이전 그림에서는 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로 트래픽을 전송합니다.
  • 노드 1을 사용할 수 없게 되면 외부 IP 주소가 다른 노드로 장애 조치됩니다. 애플리케이션 pod 및 서비스 엔드포인트의 인스턴스가 있는 다른 노드에서 speaker pod는 외부 IP 주소 192.168.100.200을 알리기 시작하고 새 노드는 클라이언트 트래픽을 수신합니다. 다이어그램에서 유일한 후보는 노드 3입니다.

23.1.4.1. 계층 2 및 외부 트래픽 정책

계층 2 모드에서는 클러스터의 한 노드에서 서비스 IP 주소에 대한 모든 트래픽을 수신합니다. 노드가 입력된 후 클러스터에서 트래픽을 처리하는 방법은 외부 트래픽 정책의 영향을 받습니다.

cluster

spec.externalTrafficPolicy의 기본값입니다.

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

local

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

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

23.1.5. 제한 사항

23.1.5.1. 레이어 2에만 지원

MetalLB Operator를 사용하여 OpenShift Container Platform 4.9에 MetalLB를 설치하고 구성하면 계층 2 모드로만 지원이 제한됩니다. 오픈 소스 MetalLB 프로젝트는 레이어 2 모드에 대한 로드 밸런싱을 제공하고, BGP(대부분 게이트웨이 프로토콜)를 사용하는 계층 3의 모드에 대해 로드 밸런싱을 제공합니다.

23.1.5.2. 단일 스택 네트워킹 지원

동일한 주소 풀에서 IPv4 주소와 IPv6 주소를 지정할 수 있지만 MetalLB는 로드 밸런서에 하나의 IP 주소만 할당합니다.

MetalLB를 듀얼 스택 네트워킹용으로 구성된 클러스터에 배포하면 MetalLB에서 서비스에 대한 클러스터 IP의 IP 주소 제품군에 따라 로드 밸런서에 하나의 IPv4 또는 IPv6 주소를 할당합니다. 예를 들어 서비스의 클러스터 IP가 IPv4이면 MetalLB에서 로드 밸런서에 IPv4 주소를 할당합니다. MetalLB는 IPv4 및 IPv6 주소를 동시에 할당하지 않습니다.

IPv6는 OVN-Kubernetes 네트워크 공급자를 사용하는 클러스터에서만 지원됩니다.

23.1.5.3. MetalLB의 인프라 고려 사항

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

  • 베어 메탈
  • VMware vSphere

MetalLB Operator 및 MetalLB는 OpenShift SDN 및 OVN-Kubernetes 네트워크 공급자에서 지원됩니다.

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

23.1.5.4.1. 단일 노드 성능 장애

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

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

23.1.5.4.2. 페일오버 성능 저하

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

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

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

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

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

23.1.5.5. IP 페일오버와 호환되지 않음

MetalLB는 IP 페일오버 기능과 호환되지 않습니다. MetalLB Operator를 설치하기 전에 IP 페일오버를 제거합니다.

23.1.6. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.