이 문서에서는 베어메탈용 Anthos 클러스터에서 경계 게이트웨이 프로토콜(BGP)을 사용해서 번들 부하 분산기를 설정하고 사용하는 방법을 설명합니다. 이 부하 분산 모드에서는 클러스터에 대해 외부 경계 게이트웨이 프로토콜(eBGP)을 통한 ServiceType LoadBalancer 가상 IP 주소(VIP) 알림을 지원합니다. 이 시나리오에서 클러스터 네트워크는 피어링을 통해 다른 자율 시스템, 외부 네트워크와 상호 연결되는 자율 시스템입니다.
BGP 기능이 포함된 번들 부하 분산기가 모든 클러스터 유형에 적용되지만 관리자 클러스터는 이 기능에 속하는 제어 영역 부하 분산만 지원합니다.
BGP 기능과 함께 번들 부하 분산기를 사용하면 다음과 같은 이점이 있습니다.
- N-방향의 활성/활성 부하 분산 기능을 사용하여 더 빠른 장애 조치와 사용 가능한 대역폭에 대한 더 효율적인 활용률을 제공합니다.
- eBGP와 호환되는 타사의 top-of-rack(ToR) 스위치 및 라우터와 함께 작동하는 레이어 3 프로토콜을 지원합니다.
- 고급 소프트웨어 정의 네트워킹(SDN) 스택을 실행하는 데이터 센터가 클러스터에 레이어 3 경계를 푸시하도록 지원합니다.
BGP를 사용하는 번들 부하 분산의 작동 방법
다음 섹션에서는 BGP를 사용하는 번들 부하 분산기의 작동 방법을 빠르게 살펴봅니다.
BGP 피어링
BGP 기능이 포함된 번들 부하 분산기가 인프라에 대해 여러 BGP 연결을 시작합니다. BGP의 기술 요구사항은 다음과 같습니다.
- 피어링 세션은 제어 영역 VIP 및 서비스 VIP에 대해 별개입니다.
- 제어 영역 피어링 세션은 제어 영역 노드의 IP 주소로부터 시작됩니다.
- 서비스 피어링 세션은
AnthosNetworkGateway커스텀 리소스에서 지정하는 유동 IP 주소로부터 시작됩니다. - Anthos Network Gateway 컨트롤러는 유동 IP 주소를 관리합니다.
- 번들 BGP 기반 부하 분산은 eBGP 피어링만 지원합니다.
- 멀티홉 피어링은 기본적으로 지원됩니다.
- BGP 세션의 MD5 비밀번호는 지원되지 않습니다.
- IPv6 기반 피어링 세션은 지원되지 않습니다.
- 모든 피어에 공지되는 경로는 네트워크 전체에 재배포되며, 클러스터 어디에서든 연결될 수 있습니다.
- 피어링 세션에 대해서는 수신 모드로 BGP
ADD-PATH기능을 사용하는 것이 가장 좋습니다. - 각 피어에서 여러 경로를 공지하면 활성/활성 부하 분산이 사용됩니다.
- 부하 분산기 노드 집합 간에 여러 경로를 사용해서 트래픽을 분산시킬 수 있도록 네트워크에 대해 동일 비용 다중 경로 라우팅(ECMP)을 사용 설정해야 합니다.
제어 영역 부하 분산
클러스터에서 각 제어 영역 노드는 인프라에서 하나 이상의 피어로 BGP 세션을 설정합니다. 각 제어 영역 노드에 피어를 하나 이상 두어야 합니다. 클러스터 구성 파일에서 어떤 외부 피어에 어떤 제어 영역 노드를 연결할지 구성할 수 있습니다.
다음 다이어그램은 제어 영역 피어링 예시를 보여줍니다. 이 클러스터에는 한 서브넷과 다른 서브넷에 2개의 제어 영역 노드가 있습니다. 각 서브넷에 외부 피어(TOR)가 있고 해당 TOR과의 베어메탈용 Anthos 클러스터 제어 영역 노드 피어가 있습니다.
서비스 부하 분산
제어 영역 피어링에 대해 각 제어 영역 노드에서 시작된 피어링 세션 외에도 추가 피어링 세션이 LoadBalancer 서비스에 대해 시작됩니다. 이러한 피어링 세션은 클러스터 노드 IP에서 직접 시작되지 않으며, 대신 유동 IP를 사용합니다.
externalTrafficPolicy=Local 네트워크 정책이 있는 서비스는 지원되지 않습니다.
유동 IP 주소
서비스 부하 분산을 위해서는 BGP 피어링에 사용하기 위해 클러스터 노드 서브넷에서 유동 IP 주소를 예약해야 합니다. 클러스터에 최소 하나 이상의 유동 IP 주소가 필요하지만 BGP 세션의 고가용성을 보장하기 위해 2개 이상의 주소를 예약하는 것이 좋습니다. 유동 IP 주소는 클러스터 구성 파일에 포함될 수 있는 AnthosNetworkGateway 커스텀 리소스(CR)에 지정됩니다.
유동 IP 주소를 사용하면 노드에 대한 BGP 스피커 IP 주소 매핑을 염려할 필요가 없습니다. Anthos Network Gateway 컨트롤러가 노드에 AnthosNetworkGateway 지정을 처리하고 유동 IP 주소를 관리합니다. 노드가 작동 중지되면 외부 피어에 피어링할 결정적 IP 주소가 지정되도록 Anthos Network Gateway 컨트롤러가 유동 IP 주소를 다시 할당합니다.
외부 피어
BGPLoadBalancer 커스텀 리소스에서 유동 IP 주소를 사용하여 세션을 피어링하는 데 사용되는 외부 피어를 지정하고, 클러스터 구성 파일에 추가합니다. 외부 피어는 클러스터 구성 파일의 loadBalancer.controlPlaneBGP 섹션에서 제어 영역 피어링에 대해 지정한 것과 동일할 수 있으며, 아니면 다른 피어를 지정할 수 있습니다.
Anthos Network Gateway 컨트롤러는 예약된 유동 IP 주소 집합으로부터 각 외부 피어에 2개의 세션을 설정하려고 시도합니다. BGP 세션에 대해 고가용성을 보장하기 위해 최소 2개 이상의 외부 피어를 지정하는 것이 좋습니다. 서비스 부하 분산기에 지정된 각 외부 피어는 AnthosNetworkGateway 커스텀 리소스에 지정된 모든 유동 IP 주소와 피어링하도록 구성되어야 합니다.
부하 분산기 노드
클러스터의 노드 하위 집합이 부하 분산에 사용됩니다. 즉, 수신되는 부하 분산 트래픽을 허용할 수 있도록 노드에 공지됩니다.
이 노드 집합은 기본적으로 제어 영역 노드 풀로 지정되지만, 클러스터 구성 파일의 loadBalancer 섹션에 다른 노드 풀을 지정할 수 있습니다. 노드 풀을 지정하면 제어 영역 노드 풀 대신 부하 분산기 노드에 사용됩니다.
BGP 스피커로 작동하는 유동 IP 주소는 부하 분산기 노드에서 실행되거나 실행되지 않을 수 있습니다. 유동 IP 주소가 동일한 서브넷의 노드에 할당되고, 부하 분산기 노드인지 여부에 관계없이 피어링이 여기에서 시작됩니다. 하지만 BGP를 통해 공지되는 다음 홉은 항상 부하 분산기 노드입니다.
예시 피어링 토폴로지
다음 다이어그램은 BGP 피어링을 사용하는 서비스 부하 분산 예시를 보여줍니다. 해당 서브넷에서 노드에 할당되는 2개의 유동 IP 주소가 있습니다. 2개의 외부 피어가 정의됩니다. 각 유동 IP 주소에 둘 다 외부 피어가 포함됩니다.
BGP 부하 분산기 설정
다음 섹션에서는 BGP와 함께 번들 부하 분산기를 사용하도록 클러스터 및 외부 네트워크를 구성하는 방법을 설명합니다.
외부 인프라와 통합 계획
BGP와 함께 부하 분산기를 사용하려면 외부 인프라를 설정해야 합니다.
제어 영역 통신을 설정하기 위해 클러스터에서 각 제어 영역 노드와 피어링되도록 외부 인프라를 구성해야 합니다. 이러한 피어링 세션은 Kubernetes 제어 영역 VIP를 공지하기 위해 사용됩니다.
제어 영역 통신을 위해 예약된 유동 IP 주소 집합과 피어링되도록 외부 인프라를 구성해야 합니다. 유동 IP 주소는 서비스 VIP에 대한 BGP 피어링을 위해 사용됩니다. BGP 세션의 고가용성을 보장하기 위해 2개의 유동 IP 주소와 2개의 피어를 사용하는 것이 좋습니다. 유동 IP 예약 프로세스는 BGP를 사용한 번들 부하 분산을 위한 클러스터 구성에 설명되어 있습니다.
인프라를 구성했으면 BGP 피어링 정보를 클러스터 구성 파일에 추가합니다. 생성된 클러스터는 외부 인프라와 피어링 세션을 시작할 수 있습니다.
BGP를 사용한 번들 부하 분산을 위한 클러스터 구성
클러스터를 만들 때 클러스터 구성 파일에서 BGP를 사용하여 번들 부하 분산을 사용 설정하고 구성합니다.
baremetal.cluster.gke.io/enable-anthos-network-gateway주석을 클러스터 구성 파일에 추가하고 이를true로 설정합니다.이 주석은 Anthos Network Gateway 컨트롤러를 사용 설정합니다.
apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: bm namespace: cluster-bm # This annotation is required for BGP load balancer annotations: baremetal.cluster.gke.io/enable-anthos-network-gateway: "true" spec: ...클러스터 구성 파일의
loadBalancer섹션에서mode를bundled로 설정하고 값이bgp인type필드를 추가합니다.이러한 필드 값은 BGP 기반의 번들 부하 분산을 사용 설정합니다.
... loadBalancer: mode: bundled # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2. type: bgp ...제어 영역에 대해 BGP 피어링 정보를 지정하기 위해
loadBalancer섹션에 다음 필드를 추가합니다.... # AS number for the cluster localASN: CLUSTER_ASN # List of BGP peers used for the control plane peering sessions. bgpPeers: - ip: PEER_IP asn: PEER_ASN # optional; if not specified, all CP nodes connect to all peers. controlPlaneNodes: # optional - CP_NODE_IP ...다음을 바꿉니다.
CLUSTER_ASN: 생성되는 클러스터의 자율 시스템 번호입니다.PEER_IP: 외부 피어 기기의 IP 주소입니다.PEER_ASN: 외부 피어 기기를 포함하는 네트워크의 자율 시스템 번호입니다.CP_NODE_IP: (선택사항) 외부 피어에 연결되는 제어 영역 노드의 IP 주소입니다. 제어 영역 노드를 지정하지 않으면 모든 제어 영역 노드가 외부 피어에 연결할 수 있습니다. IP 주소를 하나 이상 지정하면 지정된 노드만 피어링 세션에 참가합니다.
여러 외부 피어를 지정할 수 있으며
bgpPeers에 매핑 목록이 사용됩니다. BGP 세션의 고가용성을 위해 최소한 2개 이상의 외부 피어를 지정하는 것이 좋습니다. 여러 피어가 포함된 예시는 예시 구성을 참조하세요.제어 영역에 대한 이 BGP 피어링 구성은 클러스터를 생성한 후 업데이트할 수 없습니다.
loadBalancer.ports,loadBalancer.vips,loadBalancer.addressPools필드를 설정합니다(기본값 표시됨).... loadBalancer: ... # Other existing load balancer options remain the same ports: controlPlaneLBPort: 443 # When type=bgp, the VIPs are advertised over BGP vips: controlPlaneVIP: 10.0.0.8 ingressVIP: 10.0.0.1 addressPools: - name: pool1 addresses: - 10.0.0.1-10.0.0.4 ...데이터 영역 부하 분산을 위해 사용할 클러스터 노드를 지정합니다.
이 단계는 선택사항입니다.
nodePoolSpec섹션을 주석 처리 삭제하지 않으면 데이터 영역 부하 분산에 대해 제어 영역 노드가 사용됩니다.... # Node pool used for load balancing data plane (nodes where incoming traffic # arrives. If not specified, this defaults to the control plane node pool. # nodePoolSpec: # nodes: # - address: <Machine 1 IP> ...AnthosNetworkGateway커스텀 리소스를 구성하여 유동 IP 주소를 예약합니다.유동 IP 주소는 데이터 영역 부하 분산을 위한 피어링 세션에 사용됩니다.
... --- apiVersion: networking.gke.io/v1alpha1 kind: AnthosNetworkGateway metadata: name: default namespace: CLUSTER_NAMESPACE spec: floatingIPs: - FLOATING_IP ...다음을 바꿉니다.
CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. 기본적으로 Anthos clusters on bare metal에 대한 클러스터 네임스페이스는cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을test로 지정한 경우 네임스페이스는cluster-test가 됩니다.FLOATING_IP: 클러스터의 서브넷 중 하나에서 가져온 IP 주소입니다. 적어도 하나 이상의 IP 주소를 지정해야 하지만 2개 이상 지정하는 것이 좋습니다.
AnthosNetworkGateway커스텀 리소스 사양에 대한 예시는 예시 구성을 참조하세요.BGPLoadBalancer커스텀 리소스를 구성하여 데이터 영역에 대해 BGP 피어링 정보를 지정합니다.... --- apiVersion: networking.gke.io/v1alpha1 kind: BGPLoadBalancer metadata: name: bgplb namespace: CLUSTER_NAMESPACE spec: localASN: CLUSTER_ASN peers: - peerIP: PEER_IP peerASN: PEER_ASN ...다음을 바꿉니다.
CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. 기본적으로 Anthos clusters on bare metal에 대한 클러스터 네임스페이스는cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을test로 지정한 경우 네임스페이스는cluster-test가 됩니다.CLUSTER_ASN: 생성되는 클러스터의 자율 시스템 번호입니다.PEER_IP: 외부 피어 기기의 IP 주소입니다. 외부 피어를 최소 한 개 이상 지정해야 하지만 피어를 최소 두 개 이상 지정하는 것이 좋습니다. 제어 영역에 지정된 것과 동일한 피어를 사용할 수 있습니다.PEER_ASN: 외부 피어 기기를 포함하는 네트워크의 자율 시스템 번호입니다.
여러 외부 피어를 지정할 수 있으며
peers에 매핑 쌍 목록이 사용됩니다. BGP 세션의 고가용성을 위해 최소한 2개 이상의 외부 피어를 지정하는 것이 좋습니다. 여러 피어가 포함된 예시는 예시 구성을 참조하세요.클러스터를 만들기 위해
bmctl cluster create를 실행하면 실행 전 검사가 실행됩니다. 다른 검사들 중에서 실행 전 검사는 제어 영역에 대해 BGP 피어링 구성을 검증하고 클러스터를 생성하기 전 관리자 워크스테이션에 직접 문제를 보고합니다.
BGP ADD-PATH로 세션별 여러 다음 홉 공지
RFC 7911에 지정된 대로 피어링 세션에 대해 BGP ADD-PATH 기능을 사용하는 것이 좋습니다.
기본적으로 BGP 프로토콜은 단일 프리픽스에 대해 단일 다음 홉만 피어에 공지하도록 허용합니다. BGP ADD-PATH는 동일한 프리픽스에 대해 여러 개의 다음 홉 공지를 사용 설정합니다. BGP 기반 번들 부하 분산에 ADD-PATH를 사용할 경우 클러스터가 여러 클러스터 노드를 부하 분산기 서비스(프리픽스)에 대한 프런트엔드 노드(다음 홉)로 공지할 수 있습니다. 트래픽이 여러 경로에 분산될 수 있도록 네트워크에서 ECMP를 사용 설정합니다. 여러 클러스터 노드를 다음 홉으로 공지하여 트래픽을 분산할 수 있으면 부하 분산에 대한 데이터 영역 용량의 크기 조절이 향상됩니다.
top-of-rack(ToR) 스위치 또는 라우터와 같은 외부 피어 기기에서 BGP ADD-PATH가 지원될 경우 수신 확장만 켜도 충분합니다.
BGP를 사용하는 번들 부하 분산은 ADD-PATH 기능 없이 작동하지만 피어링 세션별로 단일 부하 분산 노드 공지에 대한 제한은 부하 분산기 데이터 영역 용량을 제한합니다. ADD-PATH가 없으면 베어메탈용 Anthos 클러스터는 부하 분산기 노드 풀에서 공지할 노드를 선택하고 여러 노드 간에 여러 VIP에 대해 다음 홉을 확산시키려고 시도합니다.
BGP 피어링을 부하 분산기 노드로 제한
이 기능의 미리보기 버전에서 Anthos clusters on bare metal은 유동 IP 주소와 동일한 서브넷의 모든 노드에서 유동 IP 주소를 자동으로 할당합니다. BGP 세션은 부하 분산기 노드에 도착하지 않더라도 해당 IP 주소로부터 시작됩니다. 데이터 영역(LB 노드 풀)에서 제어 영역(BGP)이 분리되었기 때문에 이 동작은 기본적으로 지원됩니다.
BGP 피어링에 사용될 수 있는 노드 집합을 제한하려면 부하 분산 노드에만 사용되도록 서브넷을 하나 지정할 수 있습니다. 즉, 해당 서브넷의 모든 노드가 부하 분산기 노드 풀에 포함되도록 구성할 수 있습니다. 그런 후 BGP 피어링에 사용되는 유동 IP 주소를 구성할 때 이 동일 서브넷에서 가져오도록 보장합니다. 베어메탈용 Anthos 클러스터는 유동 IP 주소 할당 및 BGP 피어링이 부하 분산기 노드에서만 발생하도록 보장합니다.
구성 예시
다음 섹션에서는 다른 옵션 또는 동작에 대해 BGP 기반 부하 분산을 구성하는 방법을 보여줍니다.
모든 노드에 동일한 피어가 사용되도록 구성
다음 다이어그램에 표시된 것처럼 이 구성을 사용하면 외부 피어 집합(10.8.0.10 및 10.8.0.11)이 모든 노드에서 연결되도록 설정됩니다.
데이터 영역 노드에 할당된 제어 영역 노드(10.0.1.10, 10.0.1.11, 10.0.2.10) 및 유동 IP 주소(10.0.1.100 및 10.0.2.100)가 모두 피어에 연결됩니다.
loadBalancer 서비스 피어링에 예약된 유동 IP 주소(10.0.1.100 또는 10.0.2.100)에서 동일한 외부 피어에 연결할 수 있습니다. 유동 IP 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.
다음 클러스터 구성 샘플에 표시된 것처럼 controlPlaneNodes를 지정하지 않고 제어 영역 노드 bgpPeers에 대해 피어를 구성합니다.
피어에 노드가 지정되지 않았으면 모든 제어 노드가 모든 피어에 연결됩니다.
AnthosNetworkGateway 커스텀 리소스에서 서비스 부하 분산 피어링 세션에 사용할 유동 IP 주소를 지정합니다. BGPLoadBalancer 리소스에서 해당 외부 피어를 지정합니다.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
bgpPeers:
- ip: 10.8.0.10
asn: 65002
- ip: 10.8.0.11
asn: 65002
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
name: bgplb
namespace: cluster-bm
spec:
localASN: 65001
peers:
- peerIP: 10.8.0.10
peerASN: 65002
- peerIP: 10.8.0.11
peerASN: 65002
특정 외부 피어와 피어링하도록 특정 제어 영역 노드 구성
다음 다이어그램에 표시된 것처럼 이 구성을 사용하면 2개의 제어 영역 노드(10.0.1.10 및 10.0.1.11)가 하나의 외부 피어(10.0.1.254)와 피어링됩니다. 세 번째 제어 영역 노드(10.0.2.10)는 다른 외부 피어(10.0.2.254)와 피어링됩니다. 이 구성은 모든 노드를 모든 피어에 연결하려고 하지 않을 때 유용합니다. 예를 들어 제어 영역 노드가 해당 top-of-rack(ToR) 스위치와만 피어링되도록 해야 할 수 있습니다.
동일한 외부 피어 모두 서비스 부하 분산 피어링 세션에 예약된 유동 IP 주소(10.0.1.100 또는 10.0.2.100)에서 연결될 수 있습니다. 유동 IP 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.
다음 클러스터 구성 샘플에 표시된 것처럼 bgpPeers 섹션에서 피어에 대해 controlPlaneNodes 필드에 IP 주소를 지정하여 지정된 피어에 연결할 수 있는 제어 영역 노드를 제한합니다.
AnthosNetworkGateway 커스텀 리소스에서 서비스 부하 분산 피어링 세션에 사용할 유동 IP 주소를 지정합니다. BGPLoadBalancer 리소스에서 해당 외부 피어를 지정합니다.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
bgpPeers:
- ip: 10.0.1.254
asn: 65002
controlPlaneNodes:
- 10.0.1.10
- 10.0.1.11
- ip: 10.0.2.254
asn: 65002
controlPlaneNodes:
- 10.0.2.10
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
name: bgplb
namespace: cluster-bm
spec:
localASN: 65001
peers:
- peerIP: 10.0.1.254
peerASN: 65002
- peerIP: 10.0.2.254
peerASN: 65002
제어 영역 및 데이터 영역을 개별적으로 구성
다음 다이어그램에 표시된 것처럼 이 구성을 사용하면 2개의 제어 영역(10.0.1.10 및 10.0.1.11)이 하나의 외부 피어(10.0.1.254)와 연결되고 세 번째 제어 영역 노드(10.0.2.10)가 또 다른 외부 피어(10.0.2.254)와 피어링됩니다.
서비스 부하 분산 피어링 세션용으로 예약된 유동 IP 주소(10.0.3.100 또는 10.0.3.101)로 세 번째 외부 피어(10.0.3.254)에 연결할 수 있습니다. 유동 IP 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.
다음 클러스터 구성 샘플에 표시된 것처럼 bgpPeers 섹션에서 피어에 대해 controlPlaneNodes 필드에 IP 주소를 지정하여 지정된 피어에 연결할 수 있는 제어 영역 노드를 제한합니다.
AnthosNetworkGateway 커스텀 리소스에서 서비스 부하 분산 피어링 세션에 사용할 유동 IP 주소를 지정합니다. BGPLoadBalancer 리소스에서 해당 외부 피어를 지정합니다.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
bgpPeers:
- ip: 10.0.1.254
asn: 65002
controlPlaneNodes:
- 10.0.1.10
- 10.0.1.11
- ip: 10.0.2.254
asn: 65002
controlPlaneNodes:
- 10.0.2.11
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.3.100
- 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
name: bgplb
namespace: cluster-bm
spec:
bgp:
localASN: 65001
peers:
- peerIP: 10.0.3.254
peerASN: 65002
BGP 기반 부하 분산 구성 수정
BGP로 번들 부하 분산을 사용하도록 구성된 클러스터를 만든 후 일부 구성 설정을 업데이트할 수 있지만 일부는 클러스터 생성 후 업데이트되지 않습니다.
제어 영역
제어 영역 부하 분산 구성에 대한 수정은 미리보기 기간 동안 지원되지 않습니다.
서비스
AnthosNetworkGateway CR 및 BGPLoadBalancer CR을 수정하여 클러스터를 만든 후 BGP 피어링 구성을 수정할 수 있습니다. 이러한 CR에서 피어링 정보에 대한 수정 사항은 대상 클러스터에서 부하 분산 솔루션을 구성하는 데 반영됩니다.
관리자 클러스터에서만 클러스터 네임스페이스에서 소스 리소스를 업데이트합니다. 대상(사용자) 클러스터에서 리소스에 대한 수정 사항은 덮어쓰여집니다.
문제 해결
다음 섹션에서는 BGP를 사용하는 번들 부하 분산에 대한 문제 해결 정보에 액세스하는 방법을 설명합니다.
제어 영역 BGP 세션
제어 영역 BGP 피어링 구성은 클러스터 생성 중 실행 전 검사로 검증됩니다. 실행 전 검사는 다음을 시도합니다.
- 각 피어와 BGP 연결을 설정합니다.
- 제어 영역 VIP를 공지합니다.
- VIP를 사용하여 제어 영역 노드에 연결할 수 있는지 확인합니다.
클러스터 만들기로 실행 전 검사에 실패하면 실행 전 검사 로그에서 오류를 확인합니다. 날짜 기록이 포함된 실행 전 검사 로그 파일은 baremetal/bmctl-workspace/CLUSTER_NAME/log 디렉터리에 있습니다.
런타임에 제어 영역 BGP 스피커는 각 제어 영역 노드에서 정적 포드로 실행되고 이벤트 정보를 로그에 기록합니다. 이러한 정적 Pod에는 해당 이름에 'bgpadvertiser'가 포함되므로 다음 kubectl get pods 명령어를 사용하여 BGP 스피커 Pod의 상태를 확인합니다.
kubectl -n kube-system get pods | grep bgpadvertiser
Pod가 올바르게 작동하면 응답이 다음과 같이 표시됩니다.
bgpadvertiser-node-01 1/1 Running 1 167m
bgpadvertiser-node-02 1/1 Running 1 165m
bgpadvertiser-node-03 1/1 Running 1 163m
다음 명령어를 사용하여 bgpadvertiser-node-01 Pod에 대해 로그를 확인합니다.
kubectl -n kube-system logs bgpadvertiser-node-01
서비스 BGP 세션
BGPSession 리소스는 현재 BGP 세션에 대한 정보를 제공합니다. 세션 정보를 가져오려면 먼저 현재 세션을 가져온 후 세션 중 하나에 대해 BGPSession 리소스를 검색합니다.
다음 kubectl get 명령어를 사용하여 현재 세션을 나열합니다.
kubectl -n kube-system get bgpsessions
이 명령어는 다음 예시와 비슷한 세션 목록을 반환합니다.
NAME AGE
10.0.1.254-node-01 170m
10.0.1.254-node-05 170m
10.0.3.254-node-01 170m
10.0.3.254-node-05 170m
다음 kubectl describe 명령어를 사용하여 10.0.1.254-node-01 BGP 세션에 대해 BGPSession 리소스를 가져옵니다.
kubectl -n kube-system describe bgpsession 10.0.1.254-node-01
반환된 BGPSession 리소스는 다음 예시와 비슷하게 표시됩니다.
Name: 10.0.1.254-node-01
Namespace: kube-system
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1alpha1
Kind: BGPSession
Metadata:
(omitted)
Spec:
Floating IP: 10.0.1.178
Local ASN: 65500
Local IP: 10.0.1.178
Node Name: node-01
Peer ASN: 65000
Peer IP: 10.0.1.254
Status:
Advertised Routes:
10.0.4.1/32
Last Report Time: 2021-06-14T22:09:36Z
State: Established
kubectl get 명령어를 사용하여 BGPAdvertisedRoute 리소스를 가져옵니다.
kubectl -n kube-system get bgpadvertisedroutes
다음 예시와 비슷하게 보이는 응답에 현재 공지 중인 경로가 표시됩니다.
NAME AGE
bgplb-default-load-balancer-example 5d5h
bgplb-gke-system-istio-ingress 6d
kubectl describe를 사용하여 각 경로가 공지하는 다음 홉에 대한 세부정보를 확인합니다.
수동 BGP 확인
이 섹션에는 BGP 구성을 수동으로 확인하는 방법이 포함되어 있습니다. 이 절차에서는 네트워크팀과 BGP 구성을 추가로 디버깅할 수 있도록 장기 실행 BGP 연결을 설정합니다. 클러스터를 만들기 전에 이 절차를 사용하여 구성을 확인하거나 BGP 관련 실행 전 검사가 실패하면 이 절차를 사용합니다.
실행 전 검사는 다음 BGP 확인 태스크를 자동화합니다.
- 피어와의 BGP 연결을 설정하세요.
- 제어 영역 VIP를 공지합니다.
- 다른 모든 클러스터 노드에서 VIP로 전송된 트래픽이 현재 부하 분산기 노드에 도달하는지 확인합니다.
이러한 태스크는 각 제어 영역 노드의 BGP 피어마다 실행됩니다. 클러스터를 만들 때 이러한 검사를 통과하는 것이 중요합니다. 하지만 실행 전 검사는 장기 실행 연결을 만들지 않으므로 실패를 디버깅하기가 어렵습니다.
다음 섹션에서는 BGP 연결을 설정하고 단일 클러스터 머신에서 피어 하나로의 경로를 공지하는 방법을 설명합니다. 여러 머신과 여러 피어를 테스트하려면 다른 머신과 피어의 조합을 사용하여 안내를 다시 반복합니다.
BGP 연결은 제어 영역 노드에서 설정되므로 계획된 제어 영역 노드 중 하나에서 이 절차를 테스트해야 합니다.
BGP 테스트 프로그램 바이너리 가져오기
관리자 워크스테이션에서 이 섹션의 단계를 실행합니다. 이러한 단계에서는 BGP 연결을 테스트하는 데 사용되는 bgpadvertiser 프로그램을 가져와 테스트하려는 제어 영역 노드에 복사합니다.
ansible-runner Docker 이미지를 가져옵니다.
레지스트리 미러를 사용하지 않는 경우
레지스트리 미러를 사용하지 않는 경우 다음 명령어를 실행하여 ansible-runner Docker 이미지를 가져옵니다.
gcloud auth login gcloud auth configure-docker docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13레지스트리 미러를 사용하는 경우
레지스트리 미러를 사용하는 경우 다음 명령어를 실행하여 ansible-runner Docker 이미지를 가져옵니다.
docker login REGISTRY_HOST docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13REGISTRY_HOST를 레지스트리 미러 서버의 이름으로 바꿉니다.
bgpadvertiser바이너리 추출레지스트리 미러를 사용하지 않는 경우
bgpadvertiser바이너리를 추출하려면 다음 명령어를 실행합니다.docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .레지스트리 미러를 사용하는 경우
bgpadvertiser바이너리를 추출하려면 다음 명령어를 실행합니다.docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .bgpadvertiser바이너리를 테스트할 제어 영역 노드에 복사하려면 다음 명령어를 실행합니다.scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/다음을 바꿉니다.
USERNAME: 제어 영역 노드에 액세스하는 데 사용하는 사용자 이름CP_NODE_IP: 제어 영역 노드의 IP 주소
BGP 연결 설정
제어 영역 노드에서 이 섹션의 단계를 실행합니다.
/tmp/bgpadvertiser.conf의 노드에 다음과 같은 구성 파일을 만듭니다.localIP: NODE_IP localASN: CLUSTER_ASN peers: - peerIP: PEER_IP peerASN: PEER_ASN다음을 바꿉니다.
NODE_IP: 현재 있는 제어 영역 노드의 IP 주소CLUSTER_ASN: 클러스터에서 사용되는 자율 시스템 번호PEER_IP: 테스트할 외부 피어 중 하나의 IP 주소PEER_ASN: 외부 피어 기기를 포함하는 네트워크의 자율 시스템 번호입니다.
bgpadvertiser데몬을 실행하고 다음 명령어에서 제어 영역 VIP로 바꿉니다./tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIPCONTROL_PLANE_VIP를 제어 영역 VIP에 사용할 IP 주소로 바꿉니다. 이 명령어는 BGP 광고주가 이 주소를 피어에 공지하도록 합니다.프로그램 출력을 봅니다.
이 시점에서
bgpadvertiser데몬이 시작되고 피어에 연결하려고 시도하며 VIP를 공지합니다. BGP 연결이 설정되면 프로그램에서BGP_FSM_ESTABLISHED가 포함된 메시지를 주기적으로 출력합니다(다음 샘플 출력 참조).{"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"} {"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"} I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started. I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080". INFO[0000] Add a peer configuration for:21.0.101.80 Topic=Peer {"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"} DEBU[0000] IdleHoldTimer expired Duration=0 Key=21.0.101.80 Topic=Peer I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80} DEBU[0000] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired DEBU[0000] create Destination Nlri=10.0.0.1/32 Topic=Table {"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}} I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 } I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving... DEBU[0005] try to connect Key=21.0.101.80 Topic=Peer DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received INFO[0005] Peer Up Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated DEBU[0005] sent update Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]" DEBU[0006] received update Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]" DEBU[0006] create Destination Nlri=10.0.0.1/32 Topic=Table DEBU[0035] sent Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}" DEBU[0065] sent Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
이러한 메시지가 표시되지 않으면 구성 파일의 BGP 구성 매개변수를 다시 확인하고 네트워크 관리자에게 문의하여 확인합니다. 이제 BGP 연결이 설정되었습니다. 네트워크 관리자에게 문의하여 네트워크 측에서 설정된 연결과 공지된 경로가 표시되는지 확인할 수 있습니다.
트래픽 테스트
네트워크에서 트래픽을 VIP에 전달할 수 있는지 테스트하려면 bgpadvertiser를 실행하는 제어 영역 노드에 VIP를 추가해야 합니다. bgpadvertiser를 계속 실행할 수 있도록 다른 터미널에서 다음 명령어를 실행합니다.
제어 영역 노드에 VIP를 추가합니다.
ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME다음을 바꿉니다.
CONTROL_PLANE_VIP:bgpadvertiser의 VIP--advertise-ip인수INTF_NAME: 노드의 Kubernetes 인터페이스. 즉,loadBalancer.bgpPeers.controlPlaneNodes의 베어메탈용 Anthos 클러스터 구성에 입력한 IP 주소가 있는 인터페이스입니다.
다른 노드에서 VIP를 핑합니다.
ping CONTROL_PLANE_VIP핑이 실패하면 네트워크 기기의 BGP 구성에 문제가 있을 수 있습니다. 네트워크 관리자와 협력하여 구성을 확인하고 문제를 해결합니다.
삭제
BGP가 작동하는지 수동으로 확인한 후 다음 단계를 수행하여 노드를 재설정해야 합니다. 노드를 올바르게 재설정하지 않으면 수동 설정이 실행 전 검사나 후속 클러스터 만들기를 방해할 수 있습니다.
트래픽 테스트에 추가한 경우 제어 영역 노드에서 VIP를 삭제합니다.
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME제어 영역 노드의
bgpadvertiser터미널에서Ctrl+C를 눌러 bgpadvertiser를 중지합니다.실행 중인
bgpadvertiser프로세스가 없는지 확인합니다.ps -ef | grep bgpadvertiser실행 중인 프로세스가 있으면
kill명령어를 사용하여 중지합니다.