BGP 피어링 구성하기

원문 보기 위키 갱신 2026.10.11

Calico 노드 사이 또는 노드와 네트워크 인프라 사이에 BGP 피어링을 구성해 라우팅 정보를 전파하는 방법을 다룹니다. BGPPeer와 BGPConfiguration 리소스를 사용해 풀 메시, 노드별 피어, ToR 스위치, 라우트 리플렉터 토폴로지를 만들 수 있습니다. 토폴로지를 바꿀 때 생길 수 있는 트래픽 중단을 피하는 절차도 함께 소개합니다.

출처: 문서

본문

큰 그림

Calico 노드 사이에서 BGP(Border Gateway Protocol)를 구성하거나 네트워크 인프라와 피어링해 라우팅 정보를 전파합니다.

가치

Calico 노드는 BGP를 통해 라우팅 정보를 교환해 Calico 네트워킹 워크로드(Kubernetes pod 또는 OpenStack VM)의 도달 가능성을 확보합니다. 온프레미스 배포에서는 이를 통해 워크로드를 나머지 네트워크의 일등 시민으로 만들 수 있습니다. 퍼블릭 클라우드 배포에서는 클러스터 안에서 라우팅 정보를 효율적으로 전파하는 방법이 됩니다.

개념

BGP

BGP는 네트워크 안의 라우터들이 라우팅 정보를 교환하기 위한 표준 프로토콜입니다. BGP를 실행하는 각 라우터는 하나 이상의 BGP 피어, 즉 BGP로 통신하는 다른 라우터를 갖습니다. Calico 네트워킹을 각 노드에 가상 라우터를 제공하는 것으로 생각할 수 있습니다. Calico 노드끼리 피어를 맺게 하거나, 라우트 리플렉터와, 또는 top-of-rack(ToR) 라우터와 피어를 맺게 구성할 수 있습니다.

일반적인 BGP 토폴로지

환경에 따라 BGP 네트워크를 구성하는 방법은 매우 다양합니다. Calico에서 흔히 사용되는 방식은 다음과 같습니다.

풀 메시(Full-mesh)

BGP가 활성화되면 Calico의 기본 동작은 모든 노드가 서로 피어를 맺는 내부 BGP(iBGP) 연결의 풀 메시를 만드는 것입니다. 덕분에 Calico는 퍼블릭 클라우드든 프라이빗 클라우드든 어떤 L2 네트워크 위에서도 동작할 수 있습니다.

참고: 대부분의 퍼블릭 클라우드는 IPIP를 지원합니다. 주목할 만한 예외는 Azure로, IPIP 트래픽을 차단합니다. 따라서 Azure에서 Calico를 오버레이 네트워크로 운영하려면 Calico가 VXLAN을 사용하도록 구성해야 합니다.

풀 메시는 100개 노드 이하 정도의 중소 규모 배포에서는 아주 잘 동작하지만, 그보다 훨씬 큰 규모에서는 효율이 떨어지므로 라우트 리플렉터를 사용하는 것을 권장합니다.

라우트 리플렉터

대규모 내부 BGP(iBGP) 클러스터를 구성하려면 BGP 라우트 리플렉터를 사용해 각 노드의 BGP 피어링 수를 줄일 수 있습니다. 이 모델에서는 일부 노드가 라우트 리플렉터 역할을 하며 서로 간에 풀 메시를 이루도록 구성하고, 나머지 노드는 그 라우트 리플렉터의 일부(보통 이중화를 위해 2개)와만 피어를 맺어 풀 메시 대비 전체 BGP 피어링 연결 수를 줄입니다.

Top of Rack(ToR)

온프레미스 배포에서는 Calico가 물리 네트워크 인프라와 직접 피어를 맺도록 구성할 수 있습니다. 보통은 Calico의 기본 풀 메시 동작을 끄고, 대신 L3 ToR 라우터와 피어를 맺는 방식입니다. 온프레미스 BGP 네트워크를 구성하는 방법은 매우 다양합니다. BGP 구성은 여러분의 선택에 달려 있으며, Calico는 iBGP와 eBGP 구성 모두에서 잘 동작하므로 네트워크 설계에서 Calico를 사실상 다른 라우터처럼 다룰 수 있습니다.

토폴로지에 따라 랙(rack) 안에 BGP 라우트 리플렉터를 두는 방법도 고려할 수 있습니다. 다만 이는 각 L2 도메인의 노드 수가 많을 때(100 초과) 보통 필요합니다.

온프레미스 배포 모델을 더 깊이 살펴보려면 Calico over IP Fabrics를 참고하세요.

시작하기 전에

calicoctl이 설치·구성되어 있어야 합니다.

방법

참고: 풀 메시에서 ToR 피어링으로 전환하는 등 Calico의 BGP 토폴로지를 크게 바꾸면 재구성 과정에서 pod 네트워크 연결이 일시적으로 끊길 수 있습니다. 이런 변경은 유지보수 창(maintenance window) 동안에만 수행하는 것을 권장합니다.

글로벌 BGP 피어 구성하기
노드별 BGP 피어 구성하기
노드를 라우트 리플렉터로 동작하게 구성하기
기본 BGP 노드 간 메시 비활성화하기
트래픽 중단 없이 노드 간 메시에서 라우트 리플렉터로 전환하기
노드의 BGP 피어링 상태 확인하기
기본 글로벌 AS 번호 변경하기
특정 노드의 AS 번호 변경하기
특정 BGP 피어의 로컬 AS 번호 설정하기
BGP 필터 구성하기
BGP 필터를 사용하는 BGP 피어 구성하기

글로벌 BGP 피어 구성하기

글로벌 BGP 피어는 클러스터의 모든 노드에 적용됩니다. 배포된 모든 Calico 노드와 피어를 맺을 BGP 스피커가 토폴로지에 포함된 경우 유용합니다.

다음 예제는 모든 Calico 노드가 AS 64567의 192.20.30.40과 피어를 맺도록 구성하는 글로벌 BGP 피어를 만듭니다.

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: my-global-peer
spec:
  peerIP: 192.20.30.40
  asNumber: 64567

노드별 BGP 피어 구성하기

노드별 BGP 피어는 클러스터의 하나 이상의 노드에 적용됩니다. 노드 이름을 정확히 지정하거나 레이블 셀렉터를 사용해 대상 노드를 고를 수 있습니다.

다음 예제는 rack: rack-1 레이블이 붙은 모든 Calico 노드가 AS 64567의 192.20.30.40과 피어를 맺도록 구성하는 BGPPeer를 만듭니다.

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: rack1-tor
spec:
  peerIP: 192.20.30.40
  asNumber: 64567
  nodeSelector: rack == 'rack-1'

노드를 라우트 리플렉터로 동작하게 구성하기

Calico 노드를 라우트 리플렉터로 동작하도록 구성할 수 있습니다. 이를 위해서는 라우트 리플렉터로 만들 각 노드에 클러스터 ID(보통 사용하지 않는 IPv4 주소)가 필요합니다.

클러스터 ID 244.0.0.1로 노드를 라우트 리플렉터로 구성하려면 다음 명령을 실행합니다.

탭: Kubernetes API 데이터스토어

kubectl annotate node my-node projectcalico.org/RouteReflectorClusterID=244.0.0.1

탭: etcd 데이터스토어

calicoctl patch node my-node -p '{"spec": {"bgp": {"routeReflectorClusterID": "244.0.0.1"}}}'

일반적으로 이 노드에 라우트 리플렉터임을 표시하는 레이블을 붙이면 BGPPeer 리소스에서 쉽게 선택할 수 있습니다. kubectl로 다음과 같이 할 수 있습니다:

kubectl label node my-node route-reflector=true

이제 레이블 셀렉터를 사용해 라우트 리플렉터 노드끼리, 그리고 라우트 리플렉터가 아닌 노드와 피어를 맺도록 쉽게 구성할 수 있습니다. 예를 들어:

kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: peer-with-route-reflectors
spec:
  nodeSelector: all()
  peerSelector: route-reflector == 'true'

참고: 노드 스펙에 routeReflectorClusterID를 추가하면 즉시 노드 간 메시에서 제거되어 기존 BGP 세션이 끊어집니다. 이후 BGP 피어링을 추가하면 새 BGP 세션이 올라옵니다. 이 과정이 일어나는 노드에서 실행 중인 워크로드의 데이터 플레인 트래픽이 짧게(약 2초) 끊길 수 있습니다. 이를 피하려면 새 노드를 프로비저닝하거나 kubectl drain을 실행해(이 역시 워크로드를 드레인하는 동안 중단을 유발할 수 있습니다) 해당 노드에 워크로드가 없도록 하세요.

기본 BGP 노드 간 메시 비활성화하기

기본 노드 간 BGP 메시는 다른 BGP 토폴로지를 쓰기 위해 끌 수 있습니다. 이를 위해 기본 BGP 구성 리소스를 수정합니다.

다음 명령으로 BGP 풀 메시를 비활성화합니다:

calicoctl patch bgpconfiguration default -p '{"spec": {"nodeToNodeMeshEnabled": false}}'

참고: 기본 BGP 구성 리소스가 없다면 먼저 만들어야 합니다. 자세한 내용은 BGP 구성을 참고하세요.

참고: 노드 간 메시를 비활성화하면 BGPPeer 리소스로 대체 BGP 피어링을 구성하기 전까지 pod 네트워킹이 깨집니다. pod 네트워킹이 깨지는 것을 피하려면 메시를 끄기 전에 BGPPeer 리소스를 미리 구성할 수 있습니다.

트래픽 중단 없이 노드 간 메시에서 라우트 리플렉터로 전환하기

노드 간 BGP 메시에서 BGP 라우트 리플렉터로 전환하려면 기존 BGP 세션을 끊고 새로 올려야 합니다. 이로 인해 클러스터 노드에서 실행 중인 워크로드에 짧은(약 2초) 데이터 플레인 네트워크 중단이 발생합니다. 이를 피하려면 노드 간 메시 세션을 끊기 전에 라우트 리플렉터 노드를 프로비저닝하고 그 BGP 세션을 먼저 올려 두면 됩니다.

다음 단계를 따르세요:

라우트 리플렉터로 쓸 새 노드를 프로비저닝합니다. 노드는 스케줄 불가 상태여야 하고 스펙에 routeReflectorClusterID가 있어야 합니다. 이 노드들은 기존 노드 간 BGP 메시에 속하지 않으며, 메시가 비활성화되면 라우트 리플렉터가 됩니다. 이 노드에는 BGP 피어링에서 선택할 수 있도록 route-reflector 같은 레이블도 붙이세요. 대안으로, 기존 노드에서 kubectl drain <NODE>로 워크로드를 드레인해 라우트 리플렉터로 구성할 수도 있지만, 이 경우 드레인되는 동안 해당 노드의 워크로드에 중단이 발생합니다.
레이블 셀렉터를 사용해 라우트 리플렉터 노드끼리, 그리고 라우트 리플렉터가 아닌 노드와 피어를 맺도록 BGPPeer 스펙도 설정합니다.
이 피어링이 수립되기를 기다립니다. 노드에서 sudo calicoctl node status를 실행해 확인할 수 있습니다. 또는 CalicoNodeStatus 리소스를 만들어 노드의 BGP 세션 상태를 얻을 수도 있습니다.
클러스터의 BGP 노드 간 메시를 비활성화합니다.
워크로드를 드레인했거나 노드를 스케줄 불가로 만들었다면 노드를 다시 스케줄 가능으로 표시합니다(예: kubectl uncordon <NODE> 실행).

노드의 BGP 피어링 상태 확인하기

CalicoNodeStatus 리소스를 만들어 노드의 BGP 세션 상태를 모니터링하세요.

또는 해당 노드에서 calicoctl node status 명령을 실행해 BGP 상태를 더 자세히 알아볼 수 있습니다.

참고: 이 명령은 로컬 Calico 에이전트와 통신하므로, 상태를 확인하려는 노드에서 실행해야 합니다.

기본 글로벌 AS 번호 변경하기

기본적으로 모든 Calico 노드는 노드별 AS가 지정되지 않은 한 64512 자율 시스템을 사용합니다. 기본 BGPConfiguration 리소스를 수정하면 모든 노드의 글로벌 기본값을 바꿀 수 있습니다. 다음 예제 명령은 글로벌 기본 AS 번호를 64513으로 설정합니다.

calicoctl patch bgpconfiguration default -p '{"spec": {"asNumber": "64513"}}'

참고: 기본 BGP 구성 리소스가 없다면 먼저 만들어야 합니다. 자세한 내용은 BGP 구성을 참고하세요.

특정 노드의 AS 번호 변경하기

calicoctl로 노드 객체를 수정해 특정 노드의 AS를 구성할 수 있습니다. 예를 들어 다음 명령은 node-1 노드를 AS 64514에 속하도록 바꿉니다.

calicoctl patch node node-1 -p '{"spec": {"bgp": {"asNumber": "64514"}}}'

특정 BGP 피어의 로컬 AS 번호 설정하기

calicoctl이나 kubectl로 BGPPeer 리소스를 수정해 개별 BGP 피어에 별도의 로컬 AS 번호를 지정할 수 있습니다. 이는 BGPConfiguration에 정의된 노드 전체 또는 글로벌 AS 번호를 재정의해 피어별로 다른 로컬 ASN을 쓸 수 있게 해 줍니다. localASNumber가 설정되지 않으면 Calico는 노드 전체 또는 글로벌 AS 번호로 폴백합니다.

kubectl patch bgppeer [peer_name] -p '{"spec": {"localASNumber": 64577}}'

BGP 필터 구성하기

BGP 필터는 BGP 피어 사이에서 어떤 라우트를 임포트하고 익스포트할지 제어합니다.

BGP 필터 규칙(importVX, exportVX)은 순서대로 적용되며, 처음 매칭된 규칙의 action을 취합니다. 어떤 규칙도 매칭되지 않으면 기본 action은 Accept입니다.

BGPFilter가 BGP 피어링에서 사용되려면 그 name이 해당 BGPPeer 리소스의 filters에 추가되어야 합니다.

다음 예제는 BGPFilter를 만듭니다.

apiVersion: projectcalico.org/v3
kind: BGPFilter
metadata:
  name: my-filter
spec:
  exportV4:
    - action: Accept
      matchOperator: In
      cidr: 77.0.0.0/16
    - action: Reject
      source: RemotePeers
    - action: Reject
      interface: '*.calico'
  importV4:
    - action: Reject
      matchOperator: NotIn
      cidr: 44.0.0.0/16
  exportV6:
    - action: Reject
      source: RemotePeers
    - action: Reject
      interface: '*.calico'
  importV6:
    - action: Accept
      matchOperator: Equal
      cidr: 5000::0/64
    - action: Reject

BGP 필터를 사용하는 BGP 피어 구성하기

BGP 피어는 BGP 필터를 사용해 서로 간에 임포트하거나 익스포트할 라우트를 제어할 수 있습니다.

다음 예제는 BGPFilter를 만들고 BGPPeer와 연결합니다.

참고: BGPFilter는 BGPPeer에 나열된 순서대로 적용됩니다.

kind: BGPFilter
apiVersion: projectcalico.org/v3
metadata:
  name: first-bgp-filter
spec:
  exportV4:
    - action: Accept
      matchOperator: In
      cidr: 77.0.0.0/16
      source: RemotePeers
  importV4:
    - action: Reject
      matchOperator: NotIn
      cidr: 44.0.0.0/16
  exportV6:
    - action: Reject
      interface: '*.calico'
  importV6:
    - action: Accept
      matchOperator: Equal
      cidr: 5000::0/64
---
kind: BGPFilter
apiVersion: projectcalico.org/v3
metadata:
  name: second-bgp-filter
spec:
  exportV4:
    - action: Accept
      matchOperator: In
      cidr: 77.0.0.0/16
      interface: '*.calico'
  importV4:
    - action: Reject
      matchOperator: NotIn
      cidr: 44.0.0.0/16
  exportV6:
    - action: Reject
      source: RemotePeers
  importV6:
    - action: Reject
---
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: peer-with-filter
spec:
  peerSelector: has(filter-bgp)
  filters:
    - first-bgp-filter
    - second-bgp-filter

추가 리소스

더 알아보기 (Learn more)

BGP 토폴로지를 바꾸기 전에 BGPPeer와 BGPConfiguration 리소스 문서를 먼저 살펴보면 좋습니다. 토폴로지 변경은 가급적 유지보수 창에 진행하고, 필요하면 CalicoNodeStatus로 세션 상태를 확인하세요.