개요

전체 구조 그림.
내가 쿠버네티스에 관심을 가지기 시작한 시절에 우리나라에서 샌드박스에 올려낸 프로젝트.^[1]
eBPF를 핵심 엔진으로 Go 언어로 개발됐다.

필요성

기존에 온프레미스 환경에서는 MetalLB가 로드밸런서로서의 선택지로 유효했다만, 사실 엣지 환경에서 gtp, sctp 등의 다양한 프로토콜을 지원하지 않아 어려움이 많았다.
이러한 네트워크 제약을 해결하기 위해 등장했다.
궁극적으로 이 놈이 또 대단한 점은 클라우드, 온프렘, 엣지 상에서도 설치하여 사용할 수 있다는 것.
달리 말하자면 기존의 모든 로드밸런서 구현체들 대신 사용할 수 있는 놈이라는 것이다.

특징 및 기능

문서에서 나오는 각종 특징들을 정리했다.
아직 명확한 이해가 안 돼서 기능들을 보면서 파악해보자.

• ebpf 기반
  • 빠르고, 안정적이다.
• 다양한 프로토콜 지원
  • gtp, sctp, srv6, sepp, dtls 등 이국적인 다양한 프로토콜을 지원한다.
  • 그래서 다양한 환경(특히 엣지)에서 활용가능하다.
• 어디에서든 돌리자
  • 클러스터 내부에서도, 바깥에서도 돌릴 수 있다.
• 대체
  • 위에 말했듯 클라우드 로드밸런서 대체 가능
    • 구체적으로는, 클라우드에서 제공하는 로드밸런서 리소스가 아니라 인스턴스 하나 띄워서 본인들 것을 띄우는 방식..
  • kube-proxy 대체 가능!^[2]
    • 문서를 보니 일단 CNI 중 Flannel, Calico에 대해서, 그것도 ipvs모드로 돌아가는 프록시에 대해서 지원한다고 한다.
    • ipvs 규칙들을 ebpf 내부 코드로 내재화시킨다고 합니다.
  • 인그레스, Gateway API 지원
  • NetworkPolicy는 진행 중
• 텔코 클라우드 지원
  • 텔코가 뭔가 했는데, 통신 회사에 대한 클라우드로서 활용도 할 수 있다고 하나.

전반적인 기능은 이렇게 정리된다.

성능

유연성의 측면에서 이미 넘사벽 급의 툴인데, 성능으로서도 어디에 뒤지지 않는다고 한다.
싱글 노드에서 이뤄진 ipvs, haproxy와의 비교에서 압도적인 성능을 보인다.^[3]
멀티노드 환경에서도 압도적이다..^[4]
사실.. 과거의 경험 상 자신의 것을 홍보하는 테스트는 자신 것 성능은 가장 좋았을 때를 기준으로, 다른 것들은 나빴을 때로 기준으로 한다만..
그럼에도 큰 차이가 나는 것으로 보인다.
arm 환경에서도 좋다고 합니다.^[5]
하도 좋다좋다 이야기만 하는데, 다른 글들을 참고해보는 것도 좋겠다

모듈 구조

loxilb와 관련되는 각종 모듈을 알아보자.

kube-loxilb

로드밸런서 클래스의 인터페이스를 제공하는 실질적인 구현체이다.
kube-system 네임스페이스에 디플로이먼트로 실행되며 각종 오브젝트의 변화를 추적한다.
또한 아래의 loxilb의 오퍼레이터처럼 기능하기에, 이 놈은 클러스터 내부에 둬야 한다.

loxilb

서비스 연결과 로드밸런싱을 수행하는 실질적인 모듈.
클러스터 내부에서는 데몬셋으로 마스터 노드에서 실행되게 돼있다.
kube-apiserver와 ebpf 맵을 연결하는 등의 작업을 수행하는 등의 세부적인 구현이 이뤄져있다.
이 놈은 클러스터 내부에, 외부에 있어도 된다.

loxilb eBPF kernel

커널 우회 기능을 제공하는 eBPF 커널 모듈.
말 그대로 ebpf의 기능을 담고 있다고 보면 되겠다.

goBGP

loxilb의 라우팅 스택을 제공하는 모듈이라는데, 무슨 말인지 잘 모르겠다.

loxicmd

loxilb 설정을 돕는 cli 툴.

eBPF 구조

이들은 어떻게 eBPF를 사용했을까?
이것 또한 문서로 잘 나와있는 편이다.
eBPF에서 각 용어와 개념 이해를 먼저 해야 조금이라도 이해하기 편하다.

loxilb는 두 가지 훅을 사용한다.
하나는 XDP 패킷을 처리하는 xdp 훅, 다른 하나는 TC(Transmission Control, tcp할 때 tc임)층을 처리하는 eBPF 훅이다.
전자는 네트워크 인터페이스 카드로 들어온 패킷에 대해서 작동하고, 후자는 L4 계층 스택에 들어온 패킷이 주 관심사이다.
둘 사이의 패킷 전달 코드는 두 계층의 간극을 은닉하기 위해 가벼운 추상화를 거쳤기에 서로의 최종 훅 포인트를 몰라도 상관없다.

ebpf 층은 L4 작업에 최적화되어 있는데, 여기에서 조금 이슈가 있다.
XDP에서 뽑는 패킷 프레임 형식이 skb(socket buffer, 리눅스 커널의 일반적인 소켓 버퍼)와 다르기 때문에, tcp 체크 과정이나 몇 몇 과정이 기존 리눅스 네트워크 스택보다 조금 더 걸린다.
그래서 xdp 훅이 따로 있어서 L2 단계에서 수행할 수 있는 몇 가지 작업을 수행한다.
가령 미러링 같은 작업을 하는데, 이런 작업은 상위의 ebpf 훅에서 효율적으로 처리하기 어려운 일들을 수행하게 된다.

맵 구조

ebpf 맵에 대한 전체적인 구조를 담고 있는 그림이며, 동시에 패킷 처리 흐름 파이프라인에 대한 간략한 그림.
중간에 tail call이라고 함수가 함수를 부르는 식으로 구성돼있다.
각 계층은 conntrack(커넥션 추적)이나 패킷 포워딩 로직 등으로 기능 별 명확한 분리가 이뤄져있다.
책임 영역 분리와 동시에, ebpf는 코드 사이즈 제한이 있기 때문에 일석이조인 격이다.

아깝게도 각 맵에 대한 세부 설명은 이후에 추가될 것이라고 한다.

관련 문서

참고