마이크로서비스 및 분산 애플리케이션이 시작된 이래로 Kubernetes는 컨테이너화된 애플리케이션을 배포, 관리 및 확장하기 위한 강력한 플랫폼을 제공하면서 최고의 자리를 차지했습니다. Kubernetes의 핵심에는 클러스터 내 컨테이너, 포드 및 서비스 간의 원활한 통신을 보장하는 정교한 연결 웹인 Kubernetes 클러스터 네트워킹이 있습니다.
간단히 말해서 Kubernetes는 기본 인프라를 추상화하여 개발자가 원하는 애플리케이션 상태를 정의하는 데 집중할 수 있도록 합니다. 클러스터 네트워킹은 이러한 추상화를 용이하게 하는 백본으로, 컨테이너가 상주하는 노드에 관계없이 컨테이너가 서로 통신할 수 있도록 보장합니다.
클러스터 네트워킹에는 포드 간, 포드 간 서비스, 서비스 추상화, 네트워크 정책 등이 포함되지만 최신 네트워킹 및 서비스 오케스트레이션에서 클러스터 네트워킹은 단지 통신에만 국한되지 않습니다. 오히려 탄력성 네트워킹, 향상된 확장성, 안정성 및 관찰 가능성과 함께 통합된 네트워크 통신 및 네트워크 정책이 어느 정도 기본적인 기대 사항이 되었습니다. 기존 클러스터 네트워킹 솔루션은 상당한 주목을 받았지만 다른 과제도 제시했습니다. 클러스터 전체 네트워킹 솔루션은 데이터 전송의 기본 측면을 처리하여 네트워킹 문제에 대한 가볍고 효율적인 솔루션을 제공해야 합니다. 여기에는 대용량 네트워크 트래픽을 처리하면서 복잡성과 성능 오버헤드를 더 추가할 수 있는 네트워크 정책 시행이 포함됩니다. 금융 거래 플랫폼이나 실시간 시스템과 같이 대기 시간이 짧은 통신이 중요한 애플리케이션에서 프록시 기반 아키텍처는 성능 오버헤드를 추가할 수 있습니다. 서비스와 최종 사용자가 성장하는 확장성, 리소스가 제한된 환경에서 기존 인프라와의 통합 용이성과 같은 기타 과제도 있습니다.
LoxiLB 클러스터 네트워킹
LoxiLB 클러스터 네트워킹은 Linux 커널의 혁신적인 기술인 eBPF를 사용하여 네트워크 최적화 및 관리에 대한 간소화된 접근 방식을 제공하여 환경을 재구성하는 것을 목표로 합니다. 프록시(예: Kubernetes의 kube-proxy)가 네트워크 트래픽 처리에 사용되고 네트워크 병목 현상으로 작용할 수 있는 기존의 클러스터 전체 네트워킹 솔루션과 달리 LoxiLB 클러스터 네트워크는 간단하고 간단한 솔루션을 제공할 수 있습니다. LoxiLB 클러스터 네트워킹은 로드 밸런싱, 서비스 검색, 보안, 엔드포인트 상태 모니터링과 같은 기능을 제공하며 Linux 커널에서 작동하는 eBPF 기반 데이터 경로 코어 엔진으로 인해 훨씬 빠르고 효율적으로 수행되며 네트워크 정책 적용, 추적 및 모니터링에 중점을 둡니다. 네트워크 연결 추적 및 서비스 간 데이터의 효율적인 전송.
LoxiLB의 클라우드 네이티브 특성을 통해 Kubernetes와 같은 클라우드 네이티브 환경에서 컨테이너로 실행될 수 있습니다. 또한 경량 설계로 인해 LoxiLB 클러스터 네트워킹은 단순성, 효율성 및 낮은 대기 시간 통신이 가장 중요한 특정 시나리오에 매우 적합합니다.
LoxiLB 클러스터 네트워킹이 이러한 과제를 해결하기 위해 모든 조건을 어떻게 충족하는지 논의해 보겠습니다.
확장성: LoxiLB는 최적화된 패킷 처리로 대량의 연결을 처리할 수 있어 높은 확장성을 위한 기반을 제공합니다. 또한 LoxiLB는 로드 밸런싱 및 트래픽 관리 기능을 제공하여 네트워크 트래픽을 효율적으로 배포할 수 있습니다.
트래픽 관리: LoxiLB는 로드 밸런싱, 트래픽 라우팅 및 형성과 같은 기능을 포함하는 풍부한 트래픽 관리 기능을 제공합니다.
관찰 가능성: LoxiLB에는 eBPF를 사용하는 자체 내장 conntrack 기능이 있습니다. LoxiLB는 eBPF 기술을 활용하여 기타 상세한 네트워크 측정항목도 수집하므로 네트워크 트래픽에 대한 더 깊은 가시성을 제공합니다.
보안: LoxiLB는 eBPF 기반 코어 엔진을 사용하여 세분화된 네트워크 보안 정책을 시행하여 네트워크 공격을 방지하고 워크로드 애플리케이션을 보호합니다. 그 외에도 LoxiLB는 방화벽, 트래픽 형성 및 IPSec를 통한 보안 서비스 통신을 포함하는 포괄적인 보안 프레임워크를 제공합니다.
API 지원: LoxiLB는 네트워킹 및 세분화된 보안 규칙을 관리하기 위한 REST API 세트를 통해 프로그래밍 방식의 제어를 제공합니다.
LoxiLB 클러스터 네트워킹 아키텍처를 자세히 살펴보고 이것이 네트워크 트래픽을 처리하고 최적의 성능을 보장하는 방식을 어떻게 혁신하고 있는지 살펴보겠습니다.
다이어그램의 왼쪽을 살펴보겠습니다. Kubernetes 클러스터에 들어갈 때 패킷의 트래픽 흐름을 발견하면 일련의 iptables 규칙 체인을 통과해야 합니다. 서비스를 모니터링하고 이를 iptables 또는 IPVS 유형 규칙으로 변환하는 클러스터의 각 노드에서 실행되는 Kubernetes의 사실상 네트워킹 에이전트인 Kube-proxy. 기능이나 트래픽 양이 적은 클러스터에 대해 이야기한다면 kube-proxy는 괜찮지만 확장성이나 대용량 트래픽의 경우 병목 현상이 발생합니다. 이것이 우리가 이 문제를 해결하고 보안, 관찰 가능성 및 투명성과 같은 다른 기능을 갖춘 서비스 간 통신을 위한 엔드투엔드 고속 차선 솔루션을 제공하려는 동기를 부여한 이유입니다.
LoxiLB 클러스터 네트워킹 솔루션은 IPVS 모드에서 Flannel 및 kube-proxy와 함께 작동합니다. 모든 IPVS 규칙을 단순화하고 이를 커널 내 eBPF 데이터 경로에 주입합니다. 트래픽은 인터페이스에 도달하고 eBPF에 의해 처리된 후 Linux 네트워킹의 모든 계층을 우회하여 포드 또는 다른 노드로 직접 전송됩니다. 이러한 방식으로 외부, NodePort 또는 ClusterIP 등 모든 서비스를 LoxiLB를 통해 관리할 수 있습니다.
LoxiLB 클러스터 네트워킹은 기존 클러스터 네트워킹과 어떻게 다른가요?
다른 클러스터 전체 네트워킹 솔루션과 마찬가지로 LoxiLB는 트래픽을 관리하고 네트워크 및 애플리케이션의 성능을 최적화하는 도구입니다. 그러나 기술, 디자인 원칙 및 기능면에서 다릅니다. 이 블로그의 시작 부분에서 논의한 바와 같이 기존 클러스터 네트워크 솔루션은 다양한 기능 세트를 제공하지만 문제를 해결하기보다는 다른 전쟁터를 초래할 수 있는 몇 가지 문제를 야기합니다. LoxiLB 클러스터 네트워킹 솔루션은 eBPF를 사용하여 네트워킹 데이터 경로 계층을 커널 계층에 직접 구현하여 이러한 문제를 해결합니다. 복잡한 애플리케이션 수준 검사가 없고, 많은 네트워킹 계층이 없으며, 대기 시간이 짧은 서비스 간 통신으로 빠르고 안정적으로 제공하기 위한 사이드카 없는 설계가 선호되는 경량 솔루션에 대한 옵션을 사용자에게 제공합니다.
시작하는 방법
플란넬 및 ipvs-proxy 모드로 실행되는 4노드 K3s 클러스터를 설정하겠습니다.
테스트 설정:
1xMaster 4 vCPU, 4GB RAM
3xWorker 4 vCPU, 4GB RAM
1x클라이언트 4 vCPU, 4GB RAM
마스터 노드 구성
$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik \
--disable servicelb \
--disable-cloud-controller \
--kube-proxy-arg proxy-mode=ipvs \
--flannel-iface=eth1 \
--disable-network-policy \
--node-ip=${MASTER_IP} \
--node-external-ip=${MASTER_IP} \
--bind-address=${MASTER_IP}" sh -작업자 노드 구성
$ curl -sfL https://get.k3s.io | K3S_URL="https://${MASTER_IP}:6443"\
K3S_TOKEN="${NODE_TOKEN}" \
INSTALL_K3S_EXEC="--node-ip=${WORKER_ADDR} \
--node-external-ip=${WORKER_IP} \
--kube-proxy-arg proxy-mode=ipvs \
--flannel-iface=eth1" sh -
kube-loxilb 설치
$ sudo kubectl apply -f https://raw.githubusercontent.com/loxilb-io/kube-loxilb/main/manifest/service-proxy/kube-loxilb.yml
serviceaccount/kube-loxilb created
clusterrole.rbac.authorization.k8s.io/kube-loxilb created
clusterrolebinding.rbac.authorization.k8s.io/kube-loxilb created
deployment.apps/kube-loxilb createdLoxiLB 설치
$ sudo kubectl apply -f https://raw.githubusercontent.com/loxilb-io/kube-loxilb/main/manifest/service-proxy/loxilb-service-proxy.yml
serviceaccount/loxilb-lb created
clusterrole.rbac.authorization.k8s.io/loxilb-lb created
daemonset.apps/loxilb-lb created
service/loxilb-lb-service created상태 확인
$ sudo kubectl get all -n kube-system
NAME READY STATUS RESTARTS AGE
pod/local-path-provisioner-84db5d44d9-zv4x5 1/1 Running 0 29h
pod/coredns-6799fbcd5-qq9dv 1/1 Running 0 29h
pod/metrics-server-67c658944b-sm9wv 1/1 Running 0 29h
pod/kube-loxilb-5fb5566999-vv7sm 1/1 Running 0 5m28s
pod/loxilb-lb-7rqnd 1/1 Running 0 3m44s
pod/loxilb-lb-zvj7j 1/1 Running 0 3m44s
pod/loxilb-lb-sj7z9 1/1 Running 0 3m44s
pod/loxilb-lb-wx2c7 1/1 Running 0 3m44s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 29h
service/metrics-server ClusterIP 10.43.241.152 <none> 443/TCP 29h
service/loxilb-lb-service ClusterIP None <none> 11111/TCP,179/TCP,50051/TCP 3m44s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/loxilb-lb 4 4 4 4 4 <none> 3m44s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/local-path-provisioner 1/1 1 1 29h
deployment.apps/coredns 1/1 1 1 29h
deployment.apps/metrics-server 1/1 1 1 29h
deployment.apps/kube-loxilb 1/1 1 1 5m28s
NAME DESIRED CURRENT READY AGE
replicaset.apps/local-path-provisioner-84db5d44d9 1 1 1 29h
replicaset.apps/coredns-6799fbcd5 1 1 1 29h
replicaset.apps/metrics-server-67c658944b 1 1 1 29h
replicaset.apps/kube-loxilb-5fb5566999 1 1 1 5m28s외부 서비스 만들기
$ sudo kubectl create -f iperf-service.yml
service/iperf-service created
pod/iperf1 created
$ sudo kubectl get pods
NAME READY STATUS RESTARTS AGE
iperf1 1/1 Running 0 26s
$ sudo kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 29h
iperf-service LoadBalancer 10.43.37.218 llb-192.168.80.20 55001:30336/TCP 68s성능 비교
우리는 플란넬과 Cilium이 포함된 MetalLB라는 두 가지 인기 있는 솔루션을 사용하여 구현을 벤치마킹했습니다. 처리량 비교 차트를 살펴보겠습니다.
iperf 서비스를 생성하고 클러스터 외부의 별도 VM에서 iperf 클라이언트를 사용했습니다. 클라이언트에서 시작된 트래픽 흐름은 로드 밸런서에 도달하고 NodePort로 이동한 다음 워크로드로 리디렉션됩니다. 이제 서비스를 호스팅하는 클러스터 노드와 선택한 워크로드가 예약된 위치(동일 노드 또는 다른 노드)에 따라 달라집니다. 서비스와 워크로드가 동일한 노드에서 호스팅되면 처리량은 자연스럽게 높아집니다. 그러나 두 경우 모두 처리량의 경우 LoxiLB가 더 나은 성능을 보였습니다.
그런 다음 RabbitMQ 부하 테스트를 통해 이러한 솔루션을 벤치마킹했습니다. 결과는 다음과 같습니다.
RabbitMQ TPS
RabbitMQ 중앙값 지연 시간
각 테스트는 각각 10개의 생산자 및 소비자 스레드를 사용하여 최소 100초 동안 실행되었습니다. 다양한 변형을 사용한 모든 테스트에서 LoxiLB는 모든 매개변수에서 우위를 점했습니다.
미래의 일
현재 LoxiLB 클러스터 네트워킹은 TCP/IP, UDP, SCTP, PFCP, NGAP 등과 같은 프로토콜을 지원합니다. 앞으로 갈 길이 멀습니다. 향후에는 범위를 넓히기 위해 L7 프로토콜에 대한 지원이 추가될 예정입니다.
결론
기존 솔루션과 최신 솔루션 사이의 선택은 애플리케이션이나 시스템의 특정 요구 사항에 따라 달라진다는 점에 유의하는 것이 중요합니다. Kubernetes 생태계가 계속 발전함에 따라 복잡한 클러스터 네트워킹을 탐색하는 데 사용되는 전략과 기술도 발전할 것입니다. eBPF 기반 네트워킹 솔루션, 향상된 멀티 클러스터 통신, 향상된 서비스 메시와 같은 혁신 통합은 Kubernetes 네트워킹의 미래를 형성하고 있습니다. 많은 솔루션이 특정 사용 사례에 필수적일 수 있는 보다 풍부한 애플리케이션 계층 기능 세트를 제공하는 반면 LoxiLB는 단순성, 성능 및 효율성 측면에서 이점을 제공합니다. 로드 밸런싱을 간소화하고 내결함성을 강화하며 전반적인 네트워크 성능을 개선함으로써 LoxiLB는 현대 IT 설계자의 툴킷에 귀중한 추가 기능임이 입증되었습니다. 따라서 배포 아키텍처에 따라 어떤 것을 선호하는지는 사용자에게 달려 있습니다.