본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

BGP 피어링 구성

원문 보기 위키 갱신

Calico 노드 사이의 BGP 피어링을 구성하는 단계를 다뤄요. 노드 간 풀 메시가 왜 큰 클러스터에서 부담이 되는지 살펴보고, 라우트 리플렉터를 도입해 피어링 수를 선형으로 줄이는 절차를 익혀요. "Calico the hard way" 시리즈의 일부예요.

출처: 문서

본문

우리는 Calico가 Border Gateway Protocol (BGP)을 통해 라우팅 정보를 전파하도록 구성했어요. 이 확장 가능한 프로토콜은 전 세계 퍼블릭 인터넷의 라우팅을 떠받치고 있죠.

많은 온프레미스 데이터센터에서는 각 서버가 IP 계층(레이어 3)에서 동작하는 top-of-rack (ToR) 라우터에 연결돼요. 그런 상황에서는 ToR이 컨테이너로 가는 경로를 학습하도록, 각 노드를 자신에 대응하는 ToR 라우터와 피어로 맺어야 해요. 그 구성은 이 가이드의 범위를 벗어나요.

이번 실습은 단일 서브넷 안의 AWS VPC에서 실행되기 때문에, 호스트들은 서로 이더넷(레이어 2) 연결을 갖고, 사이에 라우터가 없어요. 따라서 노드끼리 직접 피어를 맺을 수 있어요.

calicoctl이 설치된 클러스터의 노드 하나에서 상태를 확인해요.

sudo calicoctl node status

결과

Calico process is running.

IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+---------------+-------------------+-------+----------+-------------+
| 172.31.40.217 | node-to-node mesh | up    | 17:38:47 | Established |
| 172.31.40.30  | node-to-node mesh | up    | 17:40:09 | Established |
| 172.31.45.29  | node-to-node mesh | up    | 17:40:20 | Established |
| 172.31.37.123 | node-to-node mesh | up    | 17:40:29 | Established |
+---------------+-------------------+-------+----------+-------------+

IPv6 BGP status
No IPv6 peers found.

대안으로 CalicoNodeStatus 리소스를 만들어 노드의 BGP 세션 상태를 얻을 수도 있어요.

네 개의 BGP 세션, 즉 클러스터의 다른 각 노드와의 세션이 보이죠. 작은 클러스터에서는 잘 동작하고 복원력도 높아요. 하지만 BGP 세션의 총 수는 노드 수의 제곱으로 늘어나기 때문에, 큰 클러스터에서는 오버헤드가 상당해져요.

이 실습에서는 고정된 수의 *라우트 리플렉터(route reflectors)*를 구성할 거예요. 라우트 리플렉터는 자신의 경로와 다른 피어에게서 받은 경로를 광고해요. 그러면 노드는 클러스터의 모든 경로를 얻기 위해 라우트 리플렉터와만 피어를 맺으면 돼요. 이 피어링 구성 덕분에 BGP 세션 수는 노드 수에 선형으로 비례해 늘어나요.

노드 고르고 레이블 붙이기

라우트 리플렉터 세 개를 구성할 거예요. 그러면 유지보수를 위해 라우트 리플렉터 노드 하나를 내려도 단일 장애점이 생기지 않아요. 다섯 노드 클러스터에서는 불필요한 BGP 세션이 하나뿐이에요. 리플렉터가 아닌 두 노드는 서로 피어할 필요가 없거든요. 하지만 큰 클러스터에서는 상당한 오버헤드를 줄여 줘요.

노드 세 개를 고르고, 각 노드에 대해 다음을 수행하세요.

노드 YAML을 저장해요.

calicoctl get node <node name> -o yaml --export > node.yaml

YAML을 편집해 다음을 추가해요.

metadata:
  labels:
    calico-route-reflector: ''
spec:
  bgp:
    routeReflectorClusterID: 224.0.0.1

YAML을 다시 적용해요.

calicoctl apply -f node.yaml

피어링 구성하기

리플렉터가 아닌 모든 노드를 모든 라우트 리플렉터와 피어로 구성해요.

calicoctl apply -f - <<EOF
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: peer-to-rrs
spec:
  nodeSelector: "!has(calico-route-reflector)"
  peerSelector: has(calico-route-reflector)
EOF

모든 라우트 리플렉터를 서로 피어로 구성해요.

calicoctl apply -f - <<EOF
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
  name: rrs-to-rrs
spec:
  nodeSelector: has(calico-route-reflector)
  peerSelector: has(calico-route-reflector)
EOF

노드 간 메시를 비활성화해요.

calicoctl create -f - <<EOF
 apiVersion: projectcalico.org/v3
 kind: BGPConfiguration
 metadata:
   name: default
 spec:
   nodeToNodeMeshEnabled: false
   asNumber: 64512
EOF

리플렉터가 아닌 노드에서 이제 피어링이 세 개만 보일 거예요.

sudo calicoctl node status

결과

Calico process is running.

IPv4 BGP status
+---------------+---------------+-------+----------+-------------+
| PEER ADDRESS  |   PEER TYPE   | STATE |  SINCE   |    INFO     |
+---------------+---------------+-------+----------+-------------+
| 172.31.37.123 | node specific | up    | 21:52:57 | Established |
| 172.31.40.217 | node specific | up    | 21:52:57 | Established |
| 172.31.42.47  | node specific | up    | 21:52:57 | Established |
+---------------+---------------+-------+----------+-------------+

IPv6 BGP status
No IPv6 peers found.

대안으로 CalicoNodeStatus 리소스를 만들어 노드의 BGP 세션 상태를 얻을 수도 있어요.

다음

네트워킹 테스트하기

더 알아보기 (Learn more)

핵심은 calico-route-reflector 레이블과 routeReflectorClusterID, 그리고 nodeToNodeMeshEnabled: false 세 가지 조합이에요. 풀 메시는 노드 수의 제곱으로 세션이 늘지만, 리플렉터 도입으로 선형 스케일링으로 바뀌어요. 피어 상태 확인은 calicoctl node status 또는 CalicoNodeStatus 리소스로 할 수 있어요.