이제 베어메탈용 Anthos 클러스터는 베어메탈용 Google Distributed Cloud(소프트웨어 전용)입니다. 자세한 내용은 제품 개요를 참조하세요.

BGP를 사용한 번들 부하 분산기 구성

이 문서에서는 Google Distributed Cloud용 경계 게이트웨이 프로토콜(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 주소로부터 시작됩니다.
서비스 피어링 세션은 NetworkGatewayGroup 커스텀 리소스에서 지정하는 유동 IP 주소로부터 시작됩니다.
GDC용 Network Gateway 컨트롤러는 유동 IP 주소를 관리합니다.
번들 BGP 기반 부하 분산은 eBGP 피어링만 지원합니다.
멀티홉 피어링은 기본적으로 지원됩니다.
BGP 세션의 MD5 비밀번호는 지원되지 않습니다.
IPv6 기반 피어링 세션은 지원되지 않습니다.
모든 피어에 공지되는 경로는 네트워크 전체에 재배포되며, 클러스터 어디에서든 연결될 수 있습니다.
피어링 세션에 대해서는 수신 모드로 BGP ADD-PATH 기능을 사용하는 것이 좋습니다.
각 피어에서 여러 경로를 공지하면 활성/활성 부하 분산이 사용됩니다.
부하 분산기 노드 집합 간에 여러 경로를 사용해서 트래픽을 분산시킬 수 있도록 네트워크에 대해 동일 비용 다중 경로 라우팅(ECMP)을 사용 설정해야 합니다.

제어 영역 부하 분산

클러스터에서 각 제어 영역 노드는 인프라에서 하나 이상의 피어로 BGP 세션을 설정합니다. 각 제어 영역 노드에 피어를 하나 이상 두어야 합니다. 클러스터 구성 파일에서 어떤 외부 피어에 어떤 제어 영역 노드를 연결할지 구성할 수 있습니다.

다음 다이어그램은 제어 영역 피어링 예시를 보여줍니다. 이 클러스터에는 한 서브넷과 다른 서브넷에 2개의 제어 영역 노드가 있습니다. 각 서브넷에 외부 피어(TOR)가 있고 해당 TOR과의 Google Distributed Cloud 제어 영역 노드 피어가 있습니다.

BGP 피어링을 사용하는 서비스 부하 분산

서비스 부하 분산

제어 영역 피어링에 대해 각 제어 영역 노드에서 시작된 피어링 세션 외에도 추가 피어링 세션이 LoadBalancer 서비스에 대해 시작됩니다. 이러한 피어링 세션은 클러스터 노드 IP 주소에서 직접 시작되지 않으며, 대신 유동 IP 주소를 사용합니다.

externalTrafficPolicy=Local 네트워크 정책이 있는 서비스는 지원됩니다. 하지만 externalTrafficPolicy=Local 설정은 워크로드에 따라 달라지며, 서비스를 지원하는 포드가 노드에서 완전히 추가되거나 삭제될 때마다 경로가 업데이트되도록 합니다. 이 경로 업데이트 동작으로 인해 동일 비용 다중 경로(ECMP) 라우팅이 트래픽 흐름을 변경하여 트래픽이 중단될 수 있습니다.

유동 IP 주소

서비스 부하 분산을 위해서는 BGP 피어링에 사용하기 위해 클러스터 노드 서브넷에서 유동 IP 주소를 예약해야 합니다. 클러스터에 최소 하나 이상의 유동 IP 주소가 필요하지만 BGP 세션의 고가용성을 보장하기 위해 2개 이상의 주소를 예약하는 것이 좋습니다. 유동 IP 주소는 클러스터 구성 파일에 포함될 수 있는 NetworkGatewayGroup 커스텀 리소스(CR)에 지정됩니다.

유동 IP 주소를 사용하면 노드에 대한 BGP 스피커 IP 주소 매핑을 염려할 필요가 없습니다. GDC용 Network Gateway 컨트롤러가 노드에 NetworkGatewayGroup 지정을 처리하고 유동 IP 주소를 관리합니다. 노드가 작동 중지되면 외부 피어에 피어링할 결정적 IP 주소가 지정되도록 GDC용 Network Gateway 컨트롤러가 유동 IP 주소를 다시 할당합니다.

외부 피어

데이터 영역 부하 분산의 경우 클러스터 구성 파일의 loadBalancer.controlPlaneBGP 섹션에서 제어 영역 피어링에 지정된 것과 동일한 외부 피어를 사용할 수 있습니다. 또는 다른 BGP 피어를 지정할 수 있습니다.

데이터 영역 피어링에 다른 BGP 피어를 지정하려면 클러스터 구성 파일에 BGPLoadBalancer 및 BGPPeer 리소스 사양을 추가합니다. 이러한 커스텀 리소스를 지정하지 않으면 제어 영역 피어가 데이터 영역에 자동으로 사용됩니다.

BGPPeer 커스텀 리소스에서 유동 IP 주소를 사용하여 세션을 피어링하는 데 사용되는 외부 피어를 지정하고, 클러스터 구성 파일에 추가합니다. BGPPeer 리소스에는 해당하는 BGPLoadBalancer 커스텀 리소스로 식별할 수 있는 라벨이 포함되어 있습니다. BGPLoadBalancer 커스텀 리소스의 peerSelector 필드에 일치하는 라벨을 지정하여 사용할 BGPPeer를 선택합니다.

GDC용 Network Gateway 컨트롤러는 예약된 유동 IP 주소 집합으로부터 각 외부 피어에 세션(구성 가능한 세션 수)을 설정하려고 시도합니다. BGP 세션에 대해 고가용성을 보장하기 위해 최소 2개 이상의 외부 피어를 지정하는 것이 좋습니다. 서비스 부하 분산기에 지정된 각 외부 피어는 NetworkGatewayGroup 커스텀 리소스에 지정된 모든 유동 IP 주소와 피어링하도록 구성되어야 합니다.

부하 분산기 노드

클러스터의 노드 하위 집합이 부하 분산에 사용됩니다. 즉, 수신되는 부하 분산 트래픽을 허용할 수 있도록 노드에 공지됩니다. 이 노드 집합은 기본적으로 제어 영역 노드 풀로 지정되지만, 클러스터 구성 파일의 loadBalancer 섹션에 다른 노드 풀을 지정할 수 있습니다. 노드 풀을 지정하면 제어 영역 노드 풀 대신 부하 분산기 노드에 사용됩니다.

BGP 스피커로 작동하는 유동 IP 주소는 부하 분산기 노드에서 실행되거나 실행되지 않을 수 있습니다. 유동 IP 주소가 동일한 서브넷의 노드에 할당되고, 부하 분산기 노드인지 여부에 관계없이 피어링이 여기에서 시작됩니다. 하지만 BGP를 통해 공지되는 다음 홉은 항상 부하 분산기 노드입니다.

예시 피어링 토폴로지

다음 다이어그램은 BGP 피어링을 사용하는 서비스 부하 분산 예시를 보여줍니다. 해당 서브넷에서 노드에 할당되는 2개의 유동 IP 주소가 있습니다. 2개의 외부 피어가 정의됩니다. 각 유동 IP 주소에 둘 다 외부 피어가 포함됩니다.

BGP 피어링을 사용하는 서비스 부하 분산

BGP 부하 분산기 설정

다음 섹션에서는 BGP와 함께 번들 부하 분산기를 사용하도록 클러스터 및 외부 네트워크를 구성하는 방법을 설명합니다.

외부 인프라와 통합 계획

번들 부하 분산기를 BGP와 함께 사용하려면 외부 인프라를 설정해야 합니다.

제어 영역 통신을 설정하기 위해 클러스터에서 각 제어 영역 노드와 피어링되도록 외부 인프라를 구성해야 합니다. 이러한 피어링 세션은 Kubernetes 제어 영역 VIP를 공지하기 위해 사용됩니다.
제어 영역 통신을 위해 예약된 유동 IP 주소 집합과 피어링되도록 외부 인프라를 구성해야 합니다. 유동 IP 주소는 서비스 VIP에 대한 BGP 피어링을 위해 사용됩니다. BGP 세션의 고가용성을 보장하기 위해 2개의 유동 IP 주소와 2개의 피어를 사용하는 것이 좋습니다. 유동 IP 예약 프로세스는 BGP를 사용한 번들 부하 분산을 위한 클러스터 구성에 설명되어 있습니다.

인프라를 구성했으면 BGP 피어링 정보를 클러스터 구성 파일에 추가합니다. 생성된 클러스터는 외부 인프라와 피어링 세션을 시작할 수 있습니다.

BGP를 사용한 번들 부하 분산을 위한 클러스터 구성

클러스터를 만들 때 클러스터 구성 파일에서 BGP를 사용하여 번들 부하 분산을 사용 설정하고 구성합니다. 클러스터 구성 파일에서 고급 네트워킹을 사용 설정하고 loadBalancer 섹션을 업데이트합니다. 또한 다음 세 가지 커스텀 리소스의 사양을 추가합니다.

NetworkGatewayGroup: 서비스 BGP 피어링 세션에 사용되는 유동 IP 주소를 지정합니다.
BGPLoadBalancer: BGP 부하 분산에 사용되는 피어를 라벨 선택기로 지정합니다.
BGPPeer: 선택 목적의 라벨을 포함한 BGP 피어링 세션의 개별 피어를 지정합니다.

다음 안내에서는 클러스터와 3가지 커스텀 리소스를 구성하여 BGP를 사용한 번들 부하 분산을 설정하는 방법을 설명합니다.

clusterNetwork 섹션의 클러스터 구성 파일에 advancedNetworking 필드를 추가하고 이를 true로 설정합니다.

이 필드는 특히 네트워크 게이트웨이 그룹 리소스와 같은 고급 네트워킹 기능을 사용 설정합니다.
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: CLUSTER_NAMESPACE
spec:
...
  clusterNetwork:
    advancedNetworking: true
```
CLUSTER_NAMESPACE를 클러스터의 네임스페이스로 바꿉니다. 기본적으로 Google Distributed Cloud의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다.
클러스터 구성 파일의 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개 이상의 외부 피어를 지정하는 것이 좋습니다. 여러 피어가 포함된 예시는 예시 구성을 참조하세요.

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>
...
```
NetworkGatewayGroup 커스텀 리소스를 구성하여 유동 IP 주소를 예약합니다.

유동 IP 주소는 데이터 영역 부하 분산을 위한 피어링 세션에 사용됩니다.
```
...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
  nodeSelector:    # optional
  - NODE_SELECTOR
...
```
다음을 바꿉니다.
- CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. 기본적으로 Google Distributed Cloud의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다.
- FLOATING_IP: 클러스터의 서브넷 중 하나에서 가져온 IP 주소입니다. 적어도 하나 이상의 IP 주소를 지정해야 하지만 2개 이상 지정하는 것이 좋습니다.
- NODE_SELECTOR: (선택사항) top-of-rack(ToR) 스위치와 같은 외부 피어로 피어링 세션을 인스턴스화하기 위한 노드를 식별하는 라벨 선택기입니다. 필요하지 않으면 이 필드를 삭제합니다.
NetworkGatewayGroup 커스텀 리소스 이름이 default이고 클러스터 네임스페이스를 사용하는지 확인합니다. NetworkGatewayGroup 커스텀 리소스 사양에 대한 예시는 예시 구성을 참조하세요.
(선택사항) BGPLoadBalancer 커스텀 리소스를 구성하여 데이터 영역 부하 분산에 사용할 피어를 지정합니다.
```
...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...
```
다음을 바꿉니다.
- CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. 기본적으로 Google Distributed Cloud의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다.
- PEER_LABEL: 부하 분산에 사용할 피어를 식별하는 데 사용되는 라벨입니다. 일치하는 라벨이 있는 모든 BGPPeer 커스텀 리소스는 각 피어의 세부정보를 지정합니다.
BGPLoadBalancer 커스텀 리소스 이름이 default이고 클러스터 네임스페이스를 사용하는지 확인합니다. BGPLoadBalancer 커스텀 리소스를 지정하지 않으면 제어 영역 피어가 데이터 영역 부하 분산에 자동으로 사용됩니다. 포괄적인 예시는 구성 예시를 참조하세요.
(선택사항) BGPPeer 커스텀 리소스를 한 개 이상 구성하여 데이터 영역의 외부 피어를 지정합니다.
```
...
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: BGP_PEER_NAME
  namespace: CLUSTER_NAMESPACE
  labels:
    PEER_LABEL: "true"
spec:
  localASN: CLUSTER_ASN
  peerASN: PEER_ASN
  peerIP: PEER_IP
  sessions: SESSION_QTY
  selectors:   # Optional
    gatewayRefs:
    - GATEWAY_REF
  ...
```
다음을 바꿉니다.
- BGP_PEER_NAME: 피어 이름입니다.
- CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. 기본적으로 Google Distributed Cloud의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다.
- PEER_LABEL: 부하 분산에 사용할 피어를 식별하는 데 사용되는 라벨입니다. 이 라벨은 BGPLoadBalancer 커스텀 리소스에 지정된 라벨과 일치해야 합니다.
- CLUSTER_ASN: 생성되는 클러스터의 자율 시스템 번호입니다.
- PEER_IP: 외부 피어 기기의 IP 주소입니다. 외부 피어를 최소 하나 이상 지정하는 것이 좋지만 적어도 하나는 반드시 지정해야 합니다.
- PEER_ASN: 외부 피어 기기를 포함하는 네트워크의 자율 시스템 번호입니다.
- SESSION_QTY: 이 피어에 설정할 세션 수입니다. 노드 중 하나가 다운될 경우 피어에 대한 연결을 유지하려면 세션을 2개 이상 설정하는 것이 좋습니다.
- GATEWAY_REF: (선택사항) 피어링에 사용할 NetworkGatewayGroup 리소스 이름입니다. 설정하지 않은 상태로 두면 일부 또는 모든 게이트웨이 리소스가 사용될 수 있습니다. 이 설정을 NetworkGatewayGroups 리소스의 nodeSelector 필드와 함께 사용하여 ToR 스위치와 같은 특정 외부 피어와 피어링에 사용할 노드를 선택합니다. 필요 시 여러 개의 NetworkGatewayGroups를 줄당 하나의 게이트웨이 형식으로 선택하려면 여러 개의 항목이 필요합니다.
추가 BGPPeer 커스텀 리소스를 만들어 외부 피어를 여러 개 지정할 수 있습니다. BGP 세션의 고가용성을 위해 2개 이상의 외부 피어(2개의 커스텀 리소스)를 지정하는 것이 좋습니다. BGPPeer 커스텀 리소스를 지정하지 않으면 제어 영역 피어가 데이터 영역 부하 분산에 자동으로 사용됩니다.
클러스터를 만들기 위해 bmctl cluster create를 실행하면 실행 전 검사가 실행됩니다. 다른 검사들 중에서 실행 전 검사는 제어 영역에 대해 BGP 피어링 구성을 검증하고 클러스터를 생성하기 전 관리자 워크스테이션에 직접 문제를 보고합니다.

성공하면 추가된 BGP 부하 분산 리소스(NetworkGatewayGroup, BGPLoadBalancer, BGPPeer)가 사용자 클러스터 네임스페이스의 관리자 클러스터로 이동합니다. 이러한 리소스에 대한 후속 업데이트를 수행할 때 관리 클러스터 kubeconfig 파일을 사용합니다. 그러면 관리자 클러스터에서 사용자 클러스터에 대한 변경사항을 조정합니다. 사용자 클러스터에서 이러한 리소스를 직접 수정하는 경우 관리자 클러스터가 후속 조정의 변경사항을 덮어씁니다.

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가 없으면 Google Distributed Cloud는 부하 분산기 노드 풀에서 공지할 노드를 선택하고 여러 노드 간에 여러 VIP의 다음 홉을 확산시키려고 시도합니다.

BGP 피어링을 부하 분산기 노드로 제한

Google Distributed Cloud는 유동 IP 주소와 동일한 서브넷의 모든 노드에서 유동 IP 주소를 자동으로 할당합니다. BGP 세션은 부하 분산기 노드에 도착하지 않더라도 해당 IP 주소로부터 시작됩니다. 제어 영역(BGP)이 데이터 영역(LB 노드 풀)에서 분리되었으므로 이 동작은 정상 동작입니다.

BGP 피어링에 사용될 수 있는 노드 집합을 제한하려면 부하 분산 노드에만 사용되도록 서브넷을 하나 지정할 수 있습니다. 즉, 해당 서브넷의 모든 노드가 부하 분산기 노드 풀에 포함되도록 구성할 수 있습니다. 그런 후 BGP 피어링에 사용되는 유동 IP 주소를 구성할 때 이 동일 서브넷에서 가져오도록 보장합니다. Google Distributed Cloud는 유동 IP 주소 할당 및 BGP 피어링이 부하 분산기 노드에서만 발생하도록 보장합니다.

이중 스택 네트워킹을 사용하여 BGP 부하 분산 설정

BGP 기반 번들 부하 분산기는 Google Distributed Cloud 출시 버전 1.14.0부터 IPv6를 지원합니다. IPv6 지원이 도입됨에 따라 이중 스택 네트워킹으로 구성된 클러스터에서 IPv6 및 이중 스택 LoadBalancer 서비스를 구성할 수 있습니다. 이 섹션에서는 BGP를 사용한 이중 스택, 번들 부하 분산을 구성하는 데 필요한 변경사항을 설명합니다.

이중 스택 LoadBalancer 서비스를 사용 설정하려면 다음과 같은 구성 변경이 필요합니다.

기본 클러스터를 이중 스택 네트워킹용으로 구성해야 합니다.
- spec.clusterNetwork.services.cidrBlocks 아래의 클러스터 구성 파일에 IPv4 및 IPv6 서비스 CIDR을 모두 지정합니다.
- 포드에 IPv4 및 IPv6 CIDR 범위를 지정하는 데 적합한 ClusterCIDRConfig 리소스를 정의합니다.
이중 스택 네트워킹을 위한 클러스터 구성에 대한 자세한 내용은 IPv4/IPv6 이중 스택 네트워킹을 참조하세요.
spec.loadBalancer.addressPools 아래의 클러스터 구성 파일에 IPv6 주소 풀을 지정합니다. MetalLB에서 IP 주소를 이중 스택 서비스에 할당하려면 IPv4 및 IPv6 형식 주소가 모두 포함된 주소 풀이 하나 이상 있어야 합니다.

다음 예시 구성은 BGP를 사용하는 이중 스택 번들 부하 분산에 필요한 변경사항을 설명합니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  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

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

BGP를 사용하는 이중 스택, 번들 부하 분산에 대한 제한사항

BGP로 이중 스택, 번들 부하 분산을 사용하도록 클러스터를 구성할 때는 다음 제한사항에 유의하세요.

IPv6 제어 영역 부하 분산은 지원되지 않습니다.
IPv6 BGP 세션은 지원되지 않지만 IPv6 경로는 Multiprotocol BGP를 사용하여 IPv4 세션을 통해 공지할 수 있습니다.

구성 예시

다음 섹션에서는 다른 옵션 또는 동작에 대해 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 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.

모든 노드가 동일한 피어를 사용하는 BGP 부하 분산

다음 클러스터 구성 샘플에 표시된 것처럼 controlPlaneNodes를 지정하지 않고 제어 영역 노드 bgpPeers에 대해 피어를 구성합니다. 피어에 노드가 지정되지 않았으면 모든 제어 노드가 모든 피어에 연결됩니다.

NetworkGatewayGroup 커스텀 리소스에서 서비스 부하 분산 피어링 세션에 사용할 유동 IP 주소를 지정합니다. 이 예시에서는 BGPLoadBalancer가 지정되지 않았으므로 제어 영역 피어가 데이터 영역 BGP 세션에 자동으로 사용됩니다.

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/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

특정 외부 피어와 피어링하도록 특정 제어 영역 노드 구성

다음 다이어그램에 표시된 것처럼 이 구성을 사용하면 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 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.

피어에 대해 제어 영역 노드의 명시적 매핑을 사용하는 BGP 부하 분산

다음 클러스터 구성 샘플에 표시된 것처럼 bgpPeers 섹션에서 피어에 대해 controlPlaneNodes 필드에 IP 주소를 지정하여 지정된 피어에 연결할 수 있는 제어 영역 노드를 제한합니다.

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/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

제어 영역 및 데이터 영역을 개별적으로 구성

다음 다이어그램에 표시된 것처럼 이 구성을 사용하면 2개의 제어 영역(10.0.1.10 및 10.0.1.11)이 하나의 외부 피어(10.0.1.254)와 연결되고 세 번째 제어 영역 노드(10.0.2.11)가 또 다른 외부 피어(10.0.2.254)와 피어링됩니다.

서비스 부하 분산 피어링 세션용으로 예약된 유동 IP 주소(10.0.3.100 또는 10.0.3.101)로 세 번째 외부 피어(10.0.3.254)에 연결할 수 있습니다. 유동 IP 주소는 동일한 서브넷에 있는 노드에 할당될 수 있습니다.

제어 영역 및 데이터 영역에 대해 개별 구성을 사용하는 BGP 부하 분산

NetworkGatewayGroup 커스텀 리소스에서 서비스 부하 분산 피어링 세션에 사용할 유동 IP 주소를 지정합니다.

데이터 영역 부하 분산을 구성하려면 다음 안내를 따르세요.

BGPPeer 리소스에서 데이터 영역의 외부 피어를 지정하고 피어 선택에 사용할 라벨을 추가합니다(예: cluster.baremetal.gke.io/default-peer: "true").
BGPLoadBalancer 리소스의 peerSelector 필드에 일치하는 라벨을 지정합니다.

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/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

BGP 기반 부하 분산 구성 수정

BGP로 번들 부하 분산을 사용하도록 구성된 클러스터를 만든 후 일부 구성 설정을 업데이트할 수 있지만 일부는 클러스터 생성 후 업데이트되지 않습니다.

BGP 관련 리소스(NetworkGatewayGroup, BGPLoadBalancer, BGPPeer)를 나중에 업데이트할 때 관리자 클러스터 kubeconfig 파일을 사용합니다. 그런 다음 관리자 클러스터는 사용자 클러스터에 대한 변경사항을 조정합니다. 사용자 클러스터에서 이러한 리소스를 직접 수정하는 경우 관리자 클러스터가 후속 조정의 변경사항을 덮어씁니다.

제어 영역

제어 영역 BGP 피어링 정보는 Cluster 리소스에서 업데이트할 수 있습니다. 제어 영역 부하 분산 섹션에 지정된 피어를 추가하거나 삭제할 수 있습니다.

다음 섹션에서는 제어 영역 BGP 피어링 정보를 업데이트하기 위한 권장사항을 간략하게 설명합니다.

업데이트하기 전에 피어 상태 확인

피어를 잘못 구성할 위험을 최소화하려면 변경하기 전에 제어 영역 BGP 피어링 세션이 예상되는 상태에 있는지 확인하세요. 예를 들어 모든 BGP 피어링 세션이 현재 작동한다고 예상되면 모든 bgp-advertiser 포드가 세션이 작동함을 나타내는 ready을 보고하는지 확인합니다. 현재 상태가 예상과 일치하지 않는 경우 피어 구성을 업데이트하기 전에 문제를 해결합니다.

제어 영역 BGP 세션 세부정보 가져오기에 대한 자세한 내용은 제어 영역 BGP 세션을 참조하세요.

통제된 방식의 피어 업데이트

가능한 경우 피어를 한 번에 하나만 업데이트하여 가능한 문제를 격리합니다.

단일 피어를 추가하거나 업데이트합니다.
구성이 조정될 때까지 기다립니다.
클러스터가 새 피어 또는 업데이트된 피어에 연결할 수 있는지 확인합니다.
이전 피어 또는 불필요한 피어를 삭제합니다.

서비스

주소 풀과 부하 분산기 노드 설정을 업데이트하려면 Cluster 리소스에서 nodePoolSpec을 수정합니다.

클러스터를 만든 후 BGP 피어링 구성을 수정하려면 NetworkGatewayGroup 및 BGPLoadBalancer 커스텀 리소스를 수정합니다. 이러한 커스텀 리소스에서 피어링 정보에 대한 수정 사항은 대상 클러스터에서 부하 분산 솔루션을 구성하는 데 반영됩니다.

관리 클러스터에서만 클러스터 네임스페이스에서 소스 리소스를 업데이트합니다. 대상(사용자) 클러스터에서 리소스에 대한 수정 사항은 덮어쓰여집니다.

문제 해결

다음 섹션에서는 BGP를 사용하는 번들 부하 분산에 대한 문제 해결 정보에 액세스하는 방법을 설명합니다.

제어 영역 BGP 세션

제어 영역 BGP 피어링 구성은 클러스터 생성 중 실행 전 검사로 검증됩니다. 실행 전 검사는 다음을 시도합니다.

각 피어와 BGP 연결을 설정합니다.
제어 영역 VIP를 공지합니다.
VIP를 사용하여 제어 영역 노드에 연결할 수 있는지 확인합니다.

클러스터 만들기로 실행 전 검사에 실패하면 실행 전 검사 로그에서 오류를 확인합니다. 날짜 기록이 포함된 실행 전 검사 로그 파일은 baremetal/bmctl-workspace/CLUSTER_NAME/log 디렉터리에 있습니다.

런타임에 제어 영역 BGP 스피커는 각 제어 영역 노드에서 정적 포드로 실행되고 이벤트 정보를 로그에 기록합니다. 이러한 정적 포드에는 해당 이름에 'bgpadvertiser'가 포함되므로 다음 kubectl get pods 명령어를 사용하여 BGP 스피커 포드의 상태를 확인합니다.

kubectl -n kube-system get pods | grep bgpadvertiser

포드가 올바르게 작동하면 응답이 다음과 같이 표시됩니다.

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 포드에 대해 로그를 확인합니다.

kubectl -n kube-system logs bgpadvertiser-node-01

서비스 BGP 세션

BGPSession 리소스는 현재 BGP 세션에 대한 정보를 제공합니다. 세션 정보를 가져오려면 먼저 현재 세션을 가져온 후 세션 중 하나에 대해 BGPSession 리소스를 검색합니다.

다음 kubectl get 명령어를 사용하여 현재 세션을 나열합니다.

kubectl -n kube-system get bgpsessions

이 명령어는 다음 예시와 비슷한 세션 목록을 반환합니다.

NAME                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

다음 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/v1
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                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

kubectl describe를 사용하여 각 경로가 공지하는 다음 홉에 대한 세부정보를 확인합니다.

자체 관리형 클러스터의 제어 영역 VIP에 대한 액세스 복구

관리자, 하이브리드 또는 독립형 클러스터에서 제어 영역 VIP에 대한 액세스 권한을 다시 얻으려면 클러스터에서 BGP 구성을 업데이트해야 합니다. 다음 명령어 샘플과 같이 SSH를 사용하여 노드에 연결한 다음 kubectl을 사용하여 수정할 클러스터 리소스를 엽니다.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

다음을 바꿉니다.

IDENTITY_FILE: 공개 키 인증을 위한 ID 키가 포함된 SSH ID 파일의 이름입니다.
CLUSTER_NODE_IP: 클러스터 노드의 IP 주소입니다.
CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.
CLUSTER_NAME: 클러스터의 이름입니다.

클러스터 객체에서 BGP 피어링 구성을 수정합니다. 새 클러스터 구성을 저장한 후 bgpadvertiser 포드의 상태를 모니터링합니다. 구성이 작동하면 포드가 다시 시작되며, 피어에 연결되면 정상 상태가 됩니다.

수동 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.13
```
REGISTRY_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_VIP
```
CONTROL_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의 Google Distributed Cloud 구성에 입력한 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 명령어를 사용하여 중지합니다.