6.5. MetalLB Operator
6.5.1. MetalLB 및 MetalLB Operator 정보
클러스터 관리자는 MetalLB Operator를 클러스터에 추가하여 LoadBalancer
유형의 서비스가 클러스터에 추가되면 MetalLB에서 서비스의 외부 IP 주소를 추가할 수 있습니다. 외부 IP 주소가 클러스터의 호스트 네트워크에 추가됩니다.
6.5.1.1. MetalLB 사용 시기
MetalLB를 사용하는 것은 베어 메탈 클러스터 또는 베어 메탈과 같은 인프라가 있는 경우 중요하며, 외부 IP 주소를 통해 애플리케이션에 내결함성 액세스를 원할 때 중요합니다.
외부 IP 주소의 네트워크 트래픽이 클라이언트에서 클러스터의 호스트 네트워크로 라우팅되도록 네트워킹 인프라를 구성해야 합니다.
MetalLB Operator를 사용하여 MetalLB를 배포한 후 LoadBalancer
유형의 서비스를 추가하면 MetalLB에서 플랫폼 네이티브 로드 밸런서를 제공합니다.
외부 트래픽이 MetalLB LoadBalancer
서비스를 통해 OpenShift Container Platform 클러스터에 진입하면 클라이언트에 대한 반환 트래픽에 소스 IP로 로드 밸런서의 외부 IP 주소가 있습니다.
layer2 모드에서 작동하는 MetalLB는 IP 페일오버와 유사한 메커니즘을 사용하여 장애 조치를 지원합니다. 그러나 VRRP(가상 라우터 중복 프로토콜) 및 keepalived를 사용하는 대신 MetalLB는 gossip 기반 프로토콜을 활용하여 노드 오류 인스턴스를 식별합니다. 장애 조치가 감지되면 다른 노드에서 리더 노드의 역할을 가정하고 이러한 변경 사항을 브로드캐스트하도록 적절한 ARP 메시지가 발송됩니다.
계층3 또는 BGP(Border Gateway Protocol) 모드에서 작동하는 MetalLB는 장애 탐지를 네트워크에 위임합니다. OpenShift Container Platform 노드에서 연결을 설정한 BGP 라우터 또는 라우터는 노드 오류를 확인하고 해당 노드에 대한 경로를 종료합니다.
Pod 및 서비스의 고가용성을 보장하는 데 IP 페일오버 대신 MetalLB를 사용하는 것이 좋습니다.
6.5.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,
등의 이름을 사용합니다. MetalLBdoc-example
-reserved,doc-
example-ipv6컨트롤러는
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는 모든 관련 사용자 정의 리소스의 유효성을 검사합니다.
6.5.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
가 있는 노드로 라우팅됩니다. 노드가 패킷을 수신하면 서비스 프록시가 패킷을 서비스의 엔드포인트로 라우팅합니다. 최적의 경우 엔드포인트가 동일한 노드에 있거나 다른 노드에 있을 수 있습니다. 서비스 프록시는 연결이 설정될 때마다 엔드포인트를 선택합니다.
6.5.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
로 설정하는 것이 좋습니다.
6.5.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입니다.
6.5.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가 있는 다른 노드로 새 연결을 시작합니다.
그림 6.1. BGP 모드의 MetalLB 토폴로지 다이어그램
이전 그림에서는 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 없이 이전에 새 연결을 시작할 수 있도록 합니다.
6.5.1.7. 제한 사항
6.5.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®
6.5.1.7.2. 계층 2 모드에 대한 제한 사항
6.5.1.7.2.1. 단일 노드 성능 장애
MetalLB는 단일 노드를 통해 서비스에 대한 모든 트래픽을 라우팅합니다. 이 노드는 병목 현상을 일으키고 성능을 제한할 수 있습니다.
계층 2 모드는 서비스의 수신 대역폭을 단일 노드의 대역폭으로 제한합니다. 이는 ARP 및 NDP를 사용하여 트래픽을 전달하는 기본 제한 사항입니다.
6.5.1.7.2.2. 페일오버 성능 저하
노드 간 페일오버는 클라이언트와의 협업에 따라 달라집니다. 페일오버가 발생하면 MetalLB에서 적절한 ARP 패킷을 전송하여 서비스에 연결된 MAC 주소가 변경되었음을 알립니다.
대부분의 클라이언트 운영 체제는 적절한 ARP 패킷을 올바르게 처리하고 인접 캐시를 즉시 업데이트합니다. 클라이언트에서 캐시를 빠르게 업데이트하면 몇 초 내에 페일오버가 완료됩니다. 일반적으로 클라이언트는 10초 내에 새 노드로 페일오버합니다. 그러나 일부 클라이언트 운영 체제는 적절한 ARP 패킷을 전혀 처리하지 않거나 캐시 업데이트를 지연하는 오래된 구현을 보유하고 있습니다.
Windows, macOS 및 Linux와 같은 일반적인 운영 체제의 최신 버전은 계층 2 페일오버를 올바르게 구현합니다. 오래되고 덜 일반적인 클라이언트 운영 체제를 제외하고는 느린 페일오버 문제가 발생하지 않습니다.
계획된 페일오버가 오래된 클라이언트에 미치는 영향을 최소화하려면 리더십 전환 후 몇 분 동안 이전 노드를 계속 실행하십시오. 이전 노드는 캐시가 새로 고쳐질 때까지 오래된 클라이언트의 트래픽을 계속 전달할 수 있습니다.
계획되지 않은 페일오버가 발생하면 오래된 클라이언트가 캐시 항목을 새로 고칠 때까지 서비스 IP에 연결할 수 없습니다.
6.5.1.7.2.3. 추가 네트워크 및 MetalLB는 동일한 네트워크를 사용할 수 없습니다.
MetalLB 및 소스 Pod에 설정된 추가 네트워크 인터페이스에 동일한 VLAN을 사용하면 연결에 실패할 수 있습니다. 이는 MetalLB IP와 소스 Pod가 모두 동일한 노드에 있는 경우 발생합니다.
연결 실패를 방지하려면 소스 Pod가 있는 것과 다른 서브넷에 MetalLB IP를 배치합니다. 이 구성을 사용하면 소스 Pod의 트래픽이 기본 게이트웨이를 사용할 수 있습니다. 결과적으로 OVN 오버레이 네트워크를 사용하여 트래픽이 효과적으로 대상에 도달하여 연결이 의도한 대로 작동하도록 할 수 있습니다.
6.5.1.7.3. BGP 모드에 대한 제한 사항
6.5.1.7.3.1. 노드 장애로 인해 모든 활성 연결이 중단될 수 있습니다.
MetalLB는 BGP 기반 로드 밸런싱에 공통된 제한을 공유합니다. BGP 세션이 종료되면 노드가 실패하거나 speaker
Pod가 다시 시작되면 세션 종료로 모든 활성 연결이 재설정될 수 있습니다. 최종 사용자는 피어 메시지로 연결 재설정이 발생할
수 있습니다.
종료된 BGP 세션의 결과는 각 라우터 제조업체에 따라 구현됩니다. 그러나 발표자
Pod 수가 변경되어 BGP 세션 수에 영향을 미치고 BGP 피어와의 활성 연결이 끊어질 것으로 예상할 수 있습니다.
서비스 중단 가능성을 방지하거나 줄이기 위해 BGP 피어를 추가할 때 노드 선택기를 지정할 수 있습니다. BGP 세션을 시작하는 노드 수를 제한하면 BGP 세션이 없는 노드에 대한 오류는 서비스 연결에 영향을 미치지 않습니다.
6.5.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의 커뮤니티 지원 구현과 다릅니다.
6.5.1.8. 추가 리소스
6.5.2. MetalLB Operator 설치
클러스터 관리자는 Operator가 클러스터에서 MetalLB 인스턴스의 라이프사이클을 관리할 수 있도록 MetalLB Operator를 추가할 수 있습니다.
MetalLB 및 IP 페일오버가 호환되지 않습니다. 클러스터에 IP 페일오버를 구성한 경우 Operator를 설치하기 전에 IP 페일오버를 제거하는 단계를 수행합니다.
6.5.2.1. 웹 콘솔을 사용하여 OperatorHub에서 MetalLB Operator 설치
클러스터 관리자는 OpenShift Container Platform 웹 콘솔을 사용하여 MetalLB Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
-
OpenShift Container Platform 웹 콘솔에서 Operator
OperatorHub로 이동합니다. 키워드로 필터링 상자에 키워드 를 입력하거나 원하는 Operator를 찾습니다. 예를 들어
metallb
를 입력하여 MetalLB Operator를 찾습니다.인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.
- Operator 설치 페이지에서 기본값을 수락하고 설치를 클릭합니다.
검증
설치에 성공했는지 확인하려면 다음을 수행하십시오.
-
Operator
설치된 Operator 페이지로 이동합니다. -
Operator가
openshift-operators
네임스페이스에 설치되어 있고 해당 상태가Succeeded
인지 확인합니다.
-
Operator
Operator가 성공적으로 설치되지 않은 경우 Operator의 상태를 확인하고 로그를 확인합니다.
-
Operator
설치된 Operator 페이지로 이동하여 Status
열에 오류 또는 실패가 있는지 점검합니다. -
워크로드
Pod 페이지로 이동하여 openshift-operators
프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.
-
Operator
6.5.2.2. CLI를 사용하여 OperatorHub에서 설치
OpenShift Container Platform 웹 콘솔을 사용하는 대신 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다. OpenShift CLI(oc
)를 사용하여 MetalLB Operator를 설치할 수 있습니다.
Operator를 metallb-system
네임스페이스에 설치하는 CLI를 사용하는 것이 좋습니다.
사전 요구 사항
- 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음 명령을 입력하여 MetalLB Operator의 네임스페이스를 생성합니다.
$ cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: metallb-system EOF
네임스페이스에 Operator group CR(사용자 정의 리소스)을 생성합니다.
$ cat << EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator namespace: metallb-system EOF
Operator group이 네임스페이스에 설치되어 있는지 확인합니다.
$ oc get operatorgroup -n metallb-system
출력 예
NAME AGE metallb-operator 14m
서브스크립션
CR을 생성합니다.Subscription
CR을 정의하고 YAML 파일(예:metallb-sub.yaml
)을 저장합니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator-sub namespace: metallb-system spec: channel: stable name: metallb-operator source: redhat-operators 1 sourceNamespace: openshift-marketplace
- 1
redhat-operators
값을 지정해야 합니다.
서브스크립션
CR을 생성하려면 다음 명령을 실행합니다.$ oc create -f metallb-sub.yaml
선택 사항: Prometheus에 BGP 및 BFD 지표가 표시되도록 하려면 다음 명령과 같이 네임스페이스에 레이블을 지정할 수 있습니다.
$ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
검증
확인 단계에서는 MetalLB Operator가 metallb-system
네임스페이스에 설치되어 있다고 가정합니다.
설치 계획이 네임스페이스에 있는지 확인합니다.
$ oc get installplan -n metallb-system
출력 예
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.17.0-nnnnnnnnnnnn Automatic true
참고Operator 설치에는 몇 초가 걸릴 수 있습니다.
Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.
$ oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
출력 예
Name Phase metallb-operator.4.17.0-nnnnnnnnnnnn Succeeded
6.5.2.3. 클러스터에서 MetalLB 시작
Operator를 설치한 후 MetalLB 사용자 정의 리소스의 단일 인스턴스를 구성해야 합니다. 사용자 정의 리소스를 구성한 후 Operator는 클러스터에서 MetalLB를 시작합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - MetalLB Operator를 설치합니다.
프로세스
이 절차에서는 MetalLB Operator가 metallb-system
네임스페이스에 설치되어 있다고 가정합니다. 웹 콘솔을 사용하여 설치한 경우 네임스페이스의 openshift-operators
를 대체합니다.
MetalLB 사용자 지정 리소스의 단일 인스턴스를 생성합니다.
$ cat << EOF | oc apply -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system EOF
검증
MetalLB 컨트롤러 및 MetalLB 발표자의 데몬 세트가 실행 중인지 확인합니다.
컨트롤러의 배포가 실행 중인지 확인합니다.
$ oc get deployment -n metallb-system controller
출력 예
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11m
발표자의 데몬 세트가 실행 중인지 확인합니다.
$ oc get daemonset -n metallb-system speaker
출력 예
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE speaker 6 6 6 6 6 kubernetes.io/os=linux 18m
예제 출력은 6개의 발표자 pod를 나타냅니다. 클러스터의 발표자 Pod 수는 예제 출력과 다를 수 있습니다. 출력에 클러스터의 각 노드에 하나의 pod가 표시되는지 확인합니다.
6.5.2.4. MetalLB의 배포 사양
MetalLB
사용자 정의 리소스를 사용하여 MetalLB의 인스턴스를 시작할 때 MetalLB
사용자 정의 리소스에서 배포 사양을 구성하여 컨트롤러
또는 발표자
Pod가 클러스터에서 배포 및 실행되는 방법을 관리할 수 있습니다. 이러한 배포 사양을 사용하여 다음 작업을 관리합니다.
- MetalLB Pod 배포를 위해 노드를 선택합니다.
- Pod 우선순위 및 Pod 유사성을 사용하여 스케줄링을 관리합니다.
- MetalLB Pod에 대한 CPU 제한을 할당합니다.
- MetalLB Pod에 컨테이너 RuntimeClass를 할당합니다.
- MetalLB Pod에 메타데이터를 할당합니다.
6.5.2.4.1. 발표자 Pod를 특정 노드로 제한
기본적으로 MetalLB Operator를 사용하여 MetalLB를 시작하면 Operator는 클러스터의 각 노드에서 speaker
Pod 인스턴스를 시작합니다. speaker
pod가 있는 노드만 로드 밸런서 IP 주소를 알릴 수 있습니다. 노드 선택기를 사용하여 MetalLB
사용자 정의 리소스를 구성하여 speaker
Pod를 실행하는 노드를 지정할 수 있습니다.
speaker
pod를 특정 노드로 제한하는 가장 일반적인 이유는 특정 네트워크의 네트워크 인터페이스가 있는 노드만 로드 밸런서 IP 주소를 알리는 것입니다. 실행 중인 speaker
pod가 있는 노드만 로드 밸런서 IP 주소의 대상으로 표시됩니다.
speaker
Pod를 특정 노드로 제한하고 서비스의 외부 트래픽 정책에 대해 local
을 지정하는 경우 서비스의 애플리케이션 Pod가 동일한 노드에 배포되었는지 확인해야 합니다.
발표자 Pod를 작업자 노드로 제한하는 구성의 예
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: nodeSelector: 1 node-role.kubernetes.io/worker: "" speakerTolerations: 2 - key: "Example" operator: "Exists" effect: "NoExecute"
spec.nodeSelector
필드를 사용하여 매니페스트를 적용한 후 oc get daemonset -n metallb-system speaker
명령을 사용하여 Operator가 배포한 Pod 수를 확인할 수 있습니다. 마찬가지로 oc get nodes -l node-role.kubernetes.io/worker=
와 같은 명령을 사용하여 레이블과 일치하는 노드를 표시할 수 있습니다.
선택 사항으로 노드에서 유사성 규칙을 사용하여 예약해야 하는 발표자 Pod를 제어하도록 허용할 수 있습니다. 허용 오차 목록을 적용하여 이러한 Pod를 제한할 수도 있습니다. 선호도 규칙, 테인트 및 허용 오차에 대한 자세한 내용은 추가 리소스를 참조하십시오.
6.5.2.4.2. MetalLB 배포에서 Pod 우선순위 및 Pod 유사성 구성
필요한 경우 MetalLB
사용자 정의 리소스를 구성하여 컨트롤러
및 speaker
Pod에 Pod 우선순위 및 Pod 유사성 규칙을 할당할 수 있습니다. Pod 우선순위는 노드에서 Pod의 상대적 중요도를 나타내며 이 우선 순위에 따라 Pod를 예약합니다. 컨트롤러
또는 발표자
Pod에서 높은 우선 순위를 설정하여 노드의 다른 Pod보다 우선 순위를 유지합니다.
Pod 유사성은 Pod 간 관계를 관리합니다. 컨트롤러
또는 발표자
Pod에 Pod 유사성을 할당하여 스케줄러가 Pod 관계 컨텍스트에서 Pod를 배치하는 노드를 제어합니다. 예를 들어 Pod 유사성 규칙을 사용하여 특정 Pod가 동일한 노드 또는 노드에 위치하도록 할 수 있으므로 네트워크 통신을 개선하고 해당 구성 요소 간의 대기 시간을 줄일 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 로그인합니다. - MetalLB Operator가 설치되어 있습니다.
- 클러스터에서 MetalLB Operator를 시작했습니다.
프로세스
우선 순위 수준을 구성하기 위해
my
사용자 정의 리소스를 생성합니다. 이 예제에서는 값이PriorityClass
.yaml과 같은 PriorityClass1000000
인high-priority
라는PriorityClass
를 정의합니다. 이 우선순위 클래스가 할당된 Pod는 우선순위가 낮은 Pod에 비해 예약 중에 더 높은 우선 순위로 간주됩니다.apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000
PriorityClass
사용자 정의 리소스 구성을 적용합니다.$ oc apply -f myPriorityClass.yaml
MetalLB
PodConfig.yamlpriorityClassName
및podAffinity
값을 지정합니다.apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug controllerConfig: priorityClassName: high-priority 1 affinity: podAffinity: 2 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: metallb topologyKey: kubernetes.io/hostname speakerConfig: priorityClassName: high-priority affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: metallb topologyKey: kubernetes.io/hostname
MetalLB
사용자 정의 리소스 구성을 적용합니다.$ oc apply -f MetalLBPodConfig.yaml
검증
metallb-system
네임스페이스에서 Pod에 할당한 우선순위 클래스를 보려면 다음 명령을 실행합니다.$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
출력 예
NAME PRIORITY controller-584f5c8cd8-5zbvg high-priority metallb-operator-controller-manager-9c8d9985-szkqg <none> metallb-operator-webhook-server-c895594d4-shjgx <none> speaker-dddf7 high-priority
스케줄러가 Pod 유사성 규칙에 따라 Pod를 배치했는지 확인하려면 다음 명령을 실행하여 Pod 노드 또는 노드의 메타데이터를 확인합니다.
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
6.5.2.4.3. MetalLB 배포에서 Pod CPU 제한 구성
필요한 경우 MetalLB
사용자 정의 리소스를 구성하여 컨트롤러
및 발표
Pod에 Pod CPU 제한을 할당할 수 있습니다. 컨트롤러
또는 발표자
Pod에 대한 CPU 제한을 정의하면 노드에서 컴퓨팅 리소스를 관리할 수 있습니다. 이렇게 하면 노드의 모든 Pod에 워크로드 및 클러스터 하우스키핑을 관리하는 데 필요한 컴퓨팅 리소스가 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 로그인합니다. - MetalLB Operator가 설치되어 있습니다.
프로세스
CPULimits.yaml
과 같은MetalLB
사용자 정의 리소스 파일을 생성하여컨트롤러
및발표자
Pod의cpu
값을 지정합니다.apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug controllerConfig: resources: limits: cpu: "200m" speakerConfig: resources: limits: cpu: "300m"
MetalLB
사용자 정의 리소스 구성을 적용합니다.$ oc apply -f CPULimits.yaml
검증
Pod의 컴퓨팅 리소스를 보려면 다음 명령을 실행하여 <
pod_name
>을 대상 Pod로 교체합니다.$ oc describe pod <pod_name>
6.5.2.5. 추가 리소스
6.5.2.6. 다음 단계
6.5.3. MetalLB Operator 업그레이드
현재 버전 4.10 또는 이전 버전의 MetalLB Operator가 실행 중인 경우 4.10 이후 버전에 대한 자동 업데이트가 작동하지 않습니다. 4.11 이상인 MetalLB Operator의 모든 버전에서 최신 버전으로 업그레이드하는 것이 성공합니다. 예를 들어 4.12에서 버전 4.13으로 업그레이드하면 원활하게 수행됩니다.
4.10 및 이전 버전의 MetalLB Operator에 대한 업그레이드 절차 요약은 다음과 같습니다.
-
example 4.10과 같이 설치된 MetalLB Operator 버전을 삭제합니다. 네임스페이스 및
metallb
사용자 정의 리소스가 제거되지 않았는지 확인합니다. - CLI를 사용하여 이전 버전의 MetalLB Operator가 설치된 동일한 네임스페이스에 MetalLB Operator 4.17을 설치합니다.
이 절차는 표준 간단한 방법을 따르는 MetalLB Operator의 자동 z-stream 업데이트에는 적용되지 않습니다.
4.10 및 이전 버전에서 MetalLB Operator를 업그레이드하는 자세한 단계는 다음 지침을 참조하십시오. 클러스터 관리자는 OpenShift CLI(oc
) 또는 웹 콘솔을 사용하여 MetalLB Operator를 삭제하여 업그레이드 프로세스를 시작합니다.
6.5.3.1. 웹 콘솔을 사용하여 클러스터에서 MetalLB Operator 삭제
클러스터 관리자는 웹 콘솔을 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터 웹 콘솔에 액세스할 수 있습니다.
프로세스
-
Operator
설치된 Operator 페이지로 이동합니다. - MetalLB Operator를 검색합니다. 그런 다음 해당 Operator를 클릭합니다.
Operator 상세 정보 페이지 오른쪽에 있는 작업 드롭다운 메뉴에서 Operator 제거를 선택합니다.
Operator를 설치 제거하시겠습니까? 대화 상자가 표시됩니다.
설치 제거를 선택하여 Operator, Operator 배포 및 Pod를 제거합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.
참고이 작업은 CRD(사용자 정의 리소스 정의) 및 CR(사용자 정의 리소스)을 포함하여 Operator에서 관리하는 리소스를 제거하지 않습니다. 웹 콘솔에서 활성화된 대시보드 및 탐색 항목과 계속 실행되는 클러스터 외부 리소스는 수동 정리가 필요할 수 있습니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.
6.5.3.2. CLI를 사용하여 클러스터에서 MetalLB Operator 삭제
클러스터 관리자는 CLI를 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. -
oc
명령이 워크스테이션에 설치되어 있습니다.
프로세스
currentCSV
필드에서 구독한 MetalLB Operator의 현재 버전을 확인합니다.$ oc get subscription metallb-operator -n metallb-system -o yaml | grep currentCSV
출력 예
currentCSV: metallb-operator.4.10.0-202207051316
서브스크립션을 삭제합니다.
$ oc delete subscription metallb-operator -n metallb-system
출력 예
subscription.operators.coreos.com "metallb-operator" deleted
이전 단계의
currentCSV
값을 사용하여 대상 네임스페이스에서 Operator의 CSV를 삭제합니다.$ oc delete clusterserviceversion metallb-operator.4.10.0-202207051316 -n metallb-system
출력 예
clusterserviceversion.operators.coreos.com "metallb-operator.4.10.0-202207051316" deleted
6.5.3.3. MetalLB Operator group 편집
MetalLB Operator 버전에서 4.10에서 4.11 이상으로 포함하는 경우 Operator group CR(사용자 정의 리소스)에서 spec.targetNamespaces
를 제거합니다. 웹 콘솔을 사용했는지 또는 CLI를 사용하여 MetalLB Operator를 삭제하는지 여부와 관계없이 사양을 제거해야 합니다.
MetalLB Operator 버전 4.11 이상은 AllNamespaces
설치 모드만 지원하지만 4.10 또는 이전 버전은 OwnNamespace
또는 SingleNamespace
모드를 지원합니다.
사전 요구 사항
-
cluster-admin
권한이 있는 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
다음 명령을 실행하여
metallb-system
네임스페이스에 Operator 그룹을 나열합니다.$ oc get operatorgroup -n metallb-system
출력 예
NAME AGE metallb-system-7jc66 85m
다음 명령을 실행하여
metallb-system
네임스페이스와 연결된 Operator group CR에spec.targetNamespaces
가 있는지 확인합니다.$ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
출력 예
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: annotations: olm.providedAPIs: "" creationTimestamp: "2023-10-25T09:42:49Z" generateName: metallb-system- generation: 1 name: metallb-system-7jc66 namespace: metallb-system resourceVersion: "25027" uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3 spec: targetNamespaces: - metallb-system upgradeStrategy: Default status: lastUpdated: "2023-10-25T09:42:49Z" namespaces: - metallb-system
다음 명령을 실행하여 Operator group을 편집하고
spec
섹션 아래에 있는targetNamespaces
및metallb-system
을 제거합니다.$ oc edit n metallb-system
출력 예
operatorgroup.operators.coreos.com/metallb-system-7jc66 edited
다음 명령을 실행하여
metallb-system
네임스페이스와 연결된 Operator group 사용자 정의 리소스에서spec.targetNamespaces
가 제거되었는지 확인합니다.$ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
출력 예
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: annotations: olm.providedAPIs: "" creationTimestamp: "2023-10-25T09:42:49Z" generateName: metallb-system- generation: 2 name: metallb-system-7jc66 namespace: metallb-system resourceVersion: "61658" uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3 spec: upgradeStrategy: Default status: lastUpdated: "2023-10-25T14:31:30Z" namespaces: - ""
6.5.3.4. MetalLB Operator 업그레이드
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스합니다.
프로세스
metallb-system
네임스페이스가 여전히 있는지 확인합니다.$ oc get namespaces | grep metallb-system
출력 예
metallb-system Active 31m
metallb
사용자 정의 리소스가 여전히 존재하는지 확인합니다.$ oc get metallb -n metallb-system
출력 예
NAME AGE metallb 33m
"CLI를 사용하여 OperatorHub에서 설치"의 지침에 따라 MetalLB Operator의 최신 4.17 버전을 설치합니다.
참고최신 4.17 버전의 MetalLB Operator를 설치할 때 이전에 설치한 동일한 네임스페이스에 Operator를 설치해야 합니다.
Operator의 업그레이드된 버전이 4.17 버전인지 확인합니다.
$ oc get csv -n metallb-system
출력 예
NAME DISPLAY VERSION REPLACES PHASE metallb-operator.4.17.0-202207051316 MetalLB Operator 4.17.0-202207051316 Succeeded