calico에 대한 소개 (2)

1편에 이어 calico에 대한 설명을 이어 나가보겠습니다.

 

 

 

 

각 node들은 자신들만의 pod 네트웍 대역을 가지고 있으며, 이 pod들을 통신시켜주기 위해 노력하여야 합니다.

본격적으로 pod 통신이 어떻게 되는지에 대해 알아보겠습니다.

 

 

우선 네트웍 쟁이 입장으로 2가지 상황을 만들어 보겠습니다.

 

1. tor들이 pod의 네트웍을 모르는 경우

- 기본적으로 node들 끼리는 bird를 이용하여 bgp를 맺음

- 그렇기 때문에 node들은 특정 pod의 네트웍이 어느 node 에 있는지 정보를 알 수 없음

- pod의 ip가 날것으로 스위치에 들어오게 되면, 스위치는 해당 대역이 자신의 라우팅테이블에 없기 때문에 패킷을 포워딩 할 수 없음

- 현재 스위치는 node들의 ip들만 정상적으로 포워딩 할 수 있음

- pod 네트웍 ip로 패킷이 올라오면 통신이 되지 않기에, node ip를 가지고 스위치까지 올라와야 하는 상황 발생

- 이렇게 하기 위해 overlay network 사용 (node ip로 헤더를 인캡)

 

 

2. tor들이 pod의 네트웍을 아는 경우

- tor의 라우팅테이블에 pod의 네트웍 전부가 있는 상황

- tor에 pod 네트웍 ip로 패킷이 올라와도 정상적으로 포워딩이 가능한 상황

- overlay 기술을 사용하지 않아도 정상적으로 통신 가능

 

 

calico에서 사용 가능한 overlay 기술로는 2가지가 있습니다. 

- IP in IP

- Vxlan

 

 

 

 

다름으로 routing method를 알아보겠습니다.

overlay가 아닌 것(1가지) + overlay인 것(2가지), 총 3가지 방법을 선택할 수 있겠습니다.

 

하나씩 정리 해 보겠습니다.

 

 

1. Native

- 패킷의 인캡슐레이션 없는 날것의 원본 패킷을 전송

- 헤더의 인캡/디캡이 없기때문에 가장 성능이 좋음

- trouble shooting이 조금 더 쉬움 (단일 인터페이스, 헤더 인캡 없기에)

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

- 하지만 node끼리는 bird를 이용해서 경로를 주고받더라도, 상위 물리 스위치가 pod의 경로를 알지 못하면 통신이 이루어 질 수 없음

- tor까지 bgp neighbor를 맺어 pod의 network를 알게 되면 통신이 가능해짐

 

 

2. IP in IP

- calico default값

- ip 헤더 위에 ip를 한번 더 덧씌우는 인캡슐레이션 기법

- pod 에서 올라온 ip 헤더(inner) 위에 node ip 헤더(outer)를 더함 

- Azure 에서는 IPIP를 차단해서 사용할 수 없음

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

 

3. Vxlan

- MAC-in-UDP

- IPIP보다 오버헤드가 조금 더 큼

- calico에서 bgp 와 함께 쓸 수 없음

- Azure에서는 사용 가능

 

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

 

 

운영자는 어떠한 routing method를 사용할 지 선택할 수 있으며, native와 overlay를 복합적으로 사용하는 Cross-subnet 방식을 사용할 수 도 있습니다.

 

 

 

 

 

다름으로는 bgp 네트웍 설계 방안에 대해 적어보겠습니다.

 

 

 

1. Full-mesh

- default로 모든 node가 full mesh로 neighbor를 맺음 (ibgp)

- node의 갯수가 몇개 되지 않을 경우는 문제가 없으나, node가 많아지면 부하가 발생하게 됨

(bgp의 neighbor가 많아지면 문제가 될 소지가 있음. 실제로 본인은 router급 layer 3 switch로 mpbgp evpn 환경을 운영하면서 underlay & overlay 모두 bgp를 사용한 경우가 있는데, spine의 neighbor가 100개~150개 이상 넘어가면서 neighbor가 끊어졌다 붙었다 하는 flap이 발생한 적이 있음. 네트웍 망 전체가 흔들리는 문제가 발생했었으며, CoPP를 조절하면서 TS 하기는 했는데... 끔찍한 경험이었음..)

출처 : https://www.tigera.io/blog/configuring-route-reflectors-in-calico/

 

 

2. Route reflectors

- ibgp의 특성으로, ibgp로 광고받은 대역을 다른 ibgp로 전달하지 않음 (스플릿 호라이즌)

- bgp rr은 이러한 제약을 해결하는 방법 중 하나임

- rr이 되면, ibgp로 광고받은 대역을 다른 ibgp로 전달이 가능

- 특정한 라우터가 rr이 되고, 나머지 node가 rr과 neighbor를 맺게 되면, node 입장에서는 full mesh와 같이 많은 neighbor를 맺지 않고도 다른 node 의 pod 네트웍을 광고 받을 수 있음

- 아래 그림과 같이 특정 노드를 rr로 지정하고, 나머지 node들은 rr과 bgp neighbor를 맺으면 됨

 

출처 : https://www.tigera.io/blog/configuring-route-reflectors-in-calico/

 

 

3. Top of Rack (ToR)

- 위의 rr 구성의 연장선인데, 특정 node를 rr로 지정하는 것이 아니라 ToR(물리 스위치)와 bgp neighbor를 맺는 방법

- node가 아닌 스위치가 bgp rr이 되면서 bgp를 조금 더 안정적으로 운영 가능

 

 

 

 

calico 공식 홈페이지를 참고하면, 위의 내용으로 여러가지의 architecture를 뽑아낼 수 있습니다.

 

fabic이 L2 일 경우에는 물리 스위치에 rr을 구성할 수 없으니 full mesh 구성이나 node에 rr을 구성하는 형태가 나올 수 있을 것이며, fabric이 L3 일 경우에는 다양한 형태의 그림이 나옵니다. 

 

특히 fabic이 L3일 경우는 as number에 대해서도 여러 선택권이 나옵니다...

(데이타센터 bgp를 구성해 보신분들은 아시겠지만, fabric에서 bgp를 구성할 때에 as number를 어떻게 가져갈지에 대한 고민은 필수인데요(확장성까지 충분히 고려해야 되기 때문). 스위치 뿐만 아니라 node들까지 bgp를 구성하게 된다면... as number는 더욱 고민이 되게 됩니다.)

 

 

 

몇 가지 그림들을 가지고 와서 설명을 해 보도록 하겠습니다.

 

 

1. 랙 내 모든 node들이 ToR과 같은 as 일 경우

출처 : https://docs.projectcalico.org/reference/architecture/design/l3-interconnect-fabric

- 하나의 랙에서 하나의 as number를 가지게 되는 경우이며,

- ToR에서 rr을 하고 있어서 랙 내 node들은 ToR과 bgp neighbor를 맺으면 됨

- 랙을 넘어서는 경우는 ebgp이기 때문에 ToR들이 네트워크 대역들을 잘 교환해줌

 

 

2. 랙 내 모든 node들이 각각의 as 를 가지는 경우

출처 : https://docs.projectcalico.org/reference/architecture/design/l3-interconnect-fabric

- 이 경우는 모든 node가 as number가 다른 ebgp 구성이기 때문에 rr이 필요 없음

- rr구성이 없어서 좋은거 아닌가? 라고 생각하기 쉬우나... 앞서 언급한 것처럼 as number 설계를 잘해야 함

- 확장성 있는 인프라를 구성하기 위해 as number를 충~분~히 고민하고 설계해야 함

- 물론 4byte짜리 확장 as number를 사용하면 고민이 생각보다 쉽게 끝날 수도 있음. 아니.. 무조건 선택해야 되는거 아닌가 하는 생각이... (2byte as의 사설 as는 64512~65535 밖에 안되기 때문)

 

 

3. 1번과 2번의 응용 + bgp 튜닝, Downward Default model (Final Model)

출처 : https://docs.projectcalico.org/reference/architecture/design/l3-interconnect-fabric

- 모든 node 들은 같은 as number를 사용 (B1 == B2 == B3 == B4)

- 모든 ToR 들은 같은 as number를 사용 (A1 == A2)

- 모든 Spine 들은 같은 as number를 사용 (Y)

- ToR은 node와 다른 as number를 사용 (ebgp)

- ToR은 Spine과 다른 as number를 사용 (ebgp)

- ebgp 구성이므로 rr 필요없음

- calico rtr는 위(ToR)로 자신의 모든것을 광고하고 ToR로 default routing

- ToR은 위(Spine)로 자신의 모든것을 광고하고 Spine으로 default routing

- Spine은 모든 경로를 알고 있음

- routing table 최적화가 되며, flow 상 이상 없음 (어차피 자기꺼 아니면 위로 올라가야 되니..)

- 다만 없는 endpoint 로의 통신도 Spine까지 패킷이 올라오게 됨

- node의 as number가 같으니 배포가 쉬움

 

 

 

 

정리를 하면서 느낀 건, devops팀과 network팀이 서로 코웍을 잘 해야 bgp 네트워크 최적화가 가능할 것이라는 생각이... 

 

 

 

덧) rr 없이 full mesh로 구성하게 되면, node가 늘어나면서 bird가 종종 뻗습니다..