[Kubernetes] 쿠버네티스 CNI 플러그인에서 Overlay를 사용하는 이유

개요

쿠버네티스는 컨테이너라는 가상환경에서 애플리케이션을 효율적으로 관리하고 배포하기 위한 플랫폼입니다. 

그러나 수많은 파드들의 복잡한 네트워크를 관리하는 방법이 필요했습니다. 심지어 여러 노드에 파드들이 분산되어 있기도하고 노드가 대규모로 존재한다면 더욱 복잡하겠죠. 이러한 문제를 해결할 방법이 필요했습니다.

 

Overlay란?

오버레이는 물리적인 네트워크 위에 가상 네트워크 계층을 추가로 구축하여 여러 노드 간의 통신을 가능하게 만드는 기술입니다. 실제로 복잡할 수 있는 엔드 포인트 간의 네트워크 구조를 추상화하여 네트워크 통신 경로를 단순화하는 것이 목적입니다.

 

 

출저: https://www.iamachs.com/p/kubernetes-networking/part-1-demystifying-kubernetes-networking/

위의 사진을 보면 피지컬 네트워크가 존재하고 가상의 오버레이 네트워크가 존재합니다. 피지컬 네트워크는 node1(192.168.0.141), node2(192.168.0.142)이런식으로 사설 아이피를 가지고 있다고 가정합니다.

만약에 node1에 있는 pod1(10.0.1.10)가 node2에 있는 pod4(10.0.4.10)와 통신하고 싶으면 어떻게 할까요?

일단 물리적 네트워크(라우터, 스위치)는 노드의IP만 인식할 수 있으며 파드IP 대역을 직접 라우팅할 수 없습니다.

10.0.1.10 -> 10.0.4.10으로 통신이 물리 네트워크에서 차단됩니다.

 

그런데 이 물리적 네트워크 문제를 해결해줄 방법이 바로 오버레이 네트워크입니다. 예를들어 Geneve 프로토콜 방식으로 통신한다고 가정한다면 아래와 같은 과정을 통해 다른 노드에 있는 파드들끼리의 통신이 가능해집니다.

캡슐화 (Encapsulation)
Pod1 (10.0.1.10) → Pod4 (10.0.4.10)으로 전송하려는 데이터
가상 네트워크 식별자(VNI)와 메타데이터를 포함한 Geneve 헤더를 추가합니다.
외부 UDP 헤더에 목적지 노드(Node4)의 IP와 포트(6081)를 명시합니다.

전송 (Transmission)
캡슐화된 패킷은 물리 네트워크를 통해 Node4의 IP로 전달됩니다.
물리 네트워크는 Geneve 패킷을 일반 IP/UDP 패킷으로 취급하여 라우팅합니다.

디캡슐화 (Decapsulation)
Node4는 Geneve 헤더를 제거하고, 원본 패킷(10.0.4.10)을 해당 파드로 전달합니다.

 

한마디로 오버레이 네트워크는 복잡한 쿠버네티스 네트워크 환경에서 물리 네트워크를 추상화하여, 서로 다른 노드에 있는 pod가 마치 동일한 네트워크에 있는 것처럼 통신할 수 있게합니다. 

 

오버레이 프로토콜 : VXLAN vs GENEVE

VXLAN vs GENEVE

오버레이 프로토콜 종류는 더 많지만 대표적으로 VXLAN, GENEVE 두가지를 비교해보겠습니다.

VXLAN은 쉽게 설명하자면 헤더가 고정되어 있기 때문에 유연한 설정이 불가합니다. 예를들어 쿠버네티스에서 실시간 서비스(화상 회의, VoIP를 이용한 전화) 등을 제공한다면 QOS를 보장해야합니다. 이럴때 트래픽의 종류에 따라 다른 bandwidth를 사용해야 하는데 VXLAN을 사용하면 트래픽에 대한 정보를 헤더에 포함할 수 없기 때문에 이러한 트래픽 분리가 되지 않습니다.

예를들면

 

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: limit-bandwidth
spec:
  selector: app=video-streaming
  types:
  - Egress
  egress:
  - action: Allow
    limit:
      rate: 100Mbps  # 최대 대역폭 제한

 

 

위의 상황은 video-streaming 태그를 가지고 있는 app은 실시간 트래픽이기 때문에 전체 대역폭의 큰부분을 사용하도록 설정할 수 있습니다. 예를들면 일반 트래픽은 30%, 실시간 트래픽은 70%의 대역폭을 분배합니다.

 

이러한 기능을 사용하려면 헤더가 유연해야합니다. GENEVE는 유연한 헤더구조를 제공하기 때문에 위와 같은 기능을 구현할 수 있습니다.

마치 VXLAN 프로토콜은 우리가 배송받을 때 송장에  요청사항을 적을 수 없는 것이고 없는 것이고, GENEVE는 기사님에게 "부재시 문앞에 보관해주세요" 라고 적을 수 있는 것과 같다고 생각하면 쉽습니다. 다만 GENEVE를 사용하면 확장성은 좋겠지만 

 

그렇다고 전부 GENEVE를 사용하는건 아니고 쿠버네티스의 CNI 플러그인에 따라 사용하는 오버레이 프로토콜이 다를 수 있습니다. 쉬운 설명을 위해서 GENEVE와 VXLAL을 비교 설명했지만 각 플러그인에 따라서 구현되는 방식이 전혀 다를 수 있습니다.

CNI 플러그인

쿠버네티스에서는 기본적으로 kubenet 기능으로 네트워크를 제공합니다. 하지만 이는 제한적입니다. kubenet 그 자체로는 노드1 podA와 노드3 PodB의 통신이 안되기 때문 3rd party plugin으로서 플러그인을 사용해야합니다.

🔎 Calico

출저 : https://platform9.com/blog/kubernetes-networking-achieving-high-performance-with-calico/

Calico CNI 플러그인은 L3 수준에서 BGP를 통해 노드간의 라우팅을 수행합니다. 오버레이 모드로는 VXLAN 또는 IP in IP를 지원하지만오버레이 모드를 사용하지 않고도 운영할 수 있어서 직접적인 라우팅을 통해 성능을 극대화할 수 있습니다.

다만 BGP 설정과 같은 추가적인 네트워크 지식이 필요합니다. 그러나 대규모 환경에서 유연성과 성능 덕분에 엔터프라이즈 수준의 기업에서 많이 선호하는 편입니다.

 

👕 Flannel

Flannel 플러그인은 L2 수준에서 오버레이를 구현하며 주로 VXLAN 프로토콜을 사용하여 패킷을 캡슐화합니다. 각 노드에 flannelid 라는 에이전트를실행하여 서브넷을 할당하고, 네트워크 구성은 쿠버네티스의 etcd를 통해 관리합니다.

Flannel은 설치와 설정이 간단해서 빠르게 배포할 수 있다는 장점이 있습니다. 하지만 Calico 처럼 복잡한 네트워크 보안정책을 설계하는 것은 어렵습니다. 복잡한 요구사항이 필요 없다면 Flannel을 사용하는 것이 좋습니다.

 

 

다양한 CNI 플러그인 비교

 

위에서 설명드린 Calico, Flannel는 자주 사용하는 대표적인 CNI 플러그인이며 이외에 다른 CNI 플러그인들의 성능 비교입니다. 

 

결론 및 정리

쿠버네티스에서는 기본적으로 kubenet 기능을 제공하지만 다른 노드에 존재하는 파드들끼리 통신하는 것에 한계가 있어서 CNI 플러그인을 사용해야합니다. CNI 플러그인은 오버레이 네트워크 또는 BGP 프로토콜 등 다양한 방식으로 구현됩니다. 오버레이 프로토콜은 대표적으로 VXLAN, GENEVE가 있으며 물리 네트워크를 추상화하여 다른 노드에 있는 Pod와 통신이 가능하게 만듭니다.

 

CNI 플러그인 또한 다양한 종류가 있으며 Calico CNI 플러그인은 대규모 인프라 환경에서 네트워크 정책을 정교하게 설계할 때 좋고,

Flannel은 짧은 러닝커브로 빠르게 인프라를 구축할 때 유용합니다.

 

**참고자료**

https://www.iamachs.com/p/kubernetes-networking/part-1-demystifying-kubernetes-networking/

https://peterica.tistory.com/284

https://ikcoo.tistory.com/101

https://github.com/flannel-io/flannel