Kubernetes QoS

최종 수정일: 7월 30일

네트워크 QoS(Quality of Service) 는 라우터와 스위치에서 오랫동안 광범위하게 사용되어 왔습니다. 주요 목표는 트래픽 전송 우선 순위 조정을 통해 서비스별 bandwidth, jitter, latency 등을 만족시키는 것입니다. 해당 기능은 비즈니스 애플리케이션, 광역 네트워크(WAN), 서비스 프로바이더의 네트워크 성능을 향상시키는 데 필수적이며, 현재는 클라우드 네이티브 환경에서도 점점 더 많이 요구되고 있습니다. 그럼 이러한 QoS의 주요 구성요소가 무엇인지 알아보겠습니다.

QoS 에 관해 모든 것을 설명하기는 어렵고 여기서는 Traffic Policy에 초점을 맞추도록 하겠습니다. Traffic Policy는 입력 포트로 부터의 트래픽이 고객과 IP 네트워크 서비스 공급자 간에 합의된 트래픽 정책을 준수하는지 여부를 체크하기 위해 사용됩니다. 이는 사전 설정된 트래픽 정책에 따라 트래픽을 미터링하고 미터링 결과에 따라 패킷을 마킹 또는 리마킹하는 과정으로 구성됩니다. 경우에 따라서는, 패킷을 드롭 할 필요가 있는 경우도 있습니다.


일반적으로, Traffic Policy는 트래픽의 Committed Information Rate(CIR) 라고 불리는 단일 Rate 또는 CIR 와 Peak Information Rate(PIR)의 2개의 Rate 를 함께 체크합니다. CIR와 PIR를 정책 기반으로 제어하기 위해 Traffic Policy는 Peak Burst Size(PBS), Committed Burst Size(CBS) 및 3가지 보조 파라미터가 사용됩니다. 그리고 많이 사용되는 Traffic Policy 의 종류에는 크게 STRCMTRTCM 이 있습니다. 해당 내용은 링크를 참고 부탁 드립니다.

 

The growing need of QoS in cloud-native environment


모두가 알다시피, 네트워크는 마이크로 서비스 아키텍처의 가장 중요한 컴포넌트 중 하나입니다. 특히 MSA 환경에서의 Deployment 는 다수의 Pod 간의 연결을 통해 구성됩니다. 다만, 마이크로 서비스 베이스의 애플리케이션(또는 각각의 Pod / Container)의 도입에는, 비즈니스상의 관점에서는 다른 특징이 있습니다. 다음 시나리오를 가정해 보겠습니다 :



이 간단한 시나리오에서는 매우 중요한 비즈니스 애플리케이션을 실행하는 Pod 1B가 중요하지 않은 Pod 1C에 의해 간섭을 받고, 서비스가 중단될 수 있습니다. 클러스터 내에서 1,000개의 Pod 가 실행 중일 때 어떤 일이 일어나는지 쉽게 이해할 수 있습니다. 이는 통신과 대역폭 감소로 인한 서비스의 품질 저하라는 중대한 문제 외에도 다양한 MSA 성능 메트릭에 영향을 줄 수 있습니다. (예 : noisy neighbor problem)

 

Highly efficient QoS for cloud-native workloads with CNI


고성능 클라우드 네이티브 환경 제공을 위한 클라우드 네트워킹과 CNI(Container Networking Interface) 를 제공하는 CNI는 이러한 문제를 방지하기 위해 포괄적인 QoS 기능을 제공합니다. LoxiCNI는 하이브리드 모드 아키텍처(S/W 와 DPU/IPU 와 같은 H/W로의 컨테이너 네트워킹 오프로딩을 동시에 지원하는 모드) 에서 동작하는 최초의 CNI 중 하나입니다.


  • eBPF 전용 모드(S/W) - 광범위한 트래픽 프로파일과 정확하고 효율적으로 작동하는 네이티브 eBPF/XDP Traffic Policier를 제공합니다. 통상적으로 Traffic Policier /미터링 기능은 다른 트래픽 프로파일 에서는 정상적으로 동작하지 않습니다(참조).

  • DPU 모드(H/W) - eBPF 엔진 위에 DPU 블록을 사용하여 Traffic Policier 로직을 원활하게 통합 및 오프로드합니다. DPU를 사용하는 가장 큰 장점은 이러한 QoS 정책을 실행하기 위한 서버 CPU 코어 사용률이 0%라는 점입니다.


고급 QoS 기능을 갖춘 LoxiCNI를 통해 Kubernetes 운영자는 정책 기반의 Deployment / Pod 레벨 에서의 네트워크 QoS SLA(Service Level Agreement) 관리를 수행할 수 있습니다. 특히 공유 인터페이스를 기반으로 Pod / Storage 네트워킹을 동시에 활용하는 경우에는 이러한 QoS 관리는 더욱더 중요한 요소가 됩니다.

 


Network QoS policy admission control in action


QoS 정책이 실제로 어떻게 기능을 하고 Pod 간 간섭을 최소화 하여 SLV 를 보장하는 지를 검증하기 위해 다음 예제는 iperf1(500Mbps의 대역폭 제한)과 iperf2 / iperf3(무제한)의 3개의 팟을 만들어서, 대역폭이 어떻게 분배 되는지 확인해 보겠습니다.



apiVersion: v1
kind: Pod
metadata:
  name: iperf1
  labels:
    app: iperf
    iqp: 500M
spec:
  containers:
  - image: eyes852/ubuntu-iperf-test:0.5
    command:
      - sleep
      - "3600"
    imagePullPolicy: Always
    name: iperf
    securityContext:
       capabilities:
         add:
           - NET_ADMIN
  restartPolicy: Always
  nodeSelector:
    kubernetes.io/hostname: node3
—
apiVersion: v1
kind: Pod
metadata:
  name: iperf2
  labels:
    app: iperf
spec:
  containers:
  - image: eyes852/ubuntu-iperf-test:0.5
    command:
      - sleep
      - "3600"
    imagePullPolicy: Always
    name: iperf
    securityContext:
       capabilities:
         add:
           - NET_ADMIN
  restartPolicy: Always
  nodeSelector:
    kubernetes.io/hostname: node4
—
apiVersion: v1
kind: Pod
metadata:
  name: iperf3
  labels:
    app: iperf
spec:
  containers:
  - image: eyes852/ubuntu-iperf-test:0.5
    command:
      - sleep
      - "3600"
    imagePullPolicy: Always
    name: iperf
    securityContext:
       capabilities:
         add:
           - NET_ADMIN
  restartPolicy: Always
  nodeSelector:
kubernetes.io/hostname: node5

Step1 : Pod 생성 확인

netlox@nd5:~$ kubectl get pods -owide
NAME          READY   STATUS    RESTARTS    AGE  IP                    NODE    NOMINATED NODE   READINESS GATES
iperf1           1/1          Running    0                   2m     10.177.0.223   node3    <none>                         <none>
iperf2           1/1          Running    0                   2m     10.177.1.142   node4    <none>                         <none>
iperf3           1/1          Running    0                   2m     10.177.2.154   node5    <none>                         <none>

Step2 : iperf3 도구를 활용한 Qos 대역폭 제한이 걸리지 않은 pod 간 최대 사용 가능 전송 대역폭 확인

netlox@nd:~$ kubectl exec -i -t iperf3 -- /bin/bash
root@iperf3:/# iperf -s 

netlox@nd:~$ kubectl exec -i -t iperf2 -- /bin/bash
root@iperf2:/#  iperf -c 10.177.2.154 -t 5
------------------------------------------------------------
Client connecting to 10.177.2.154, TCP port 5001
TCP window size: 2.76 MByte (default)
------------------------------------------------------------
[  3] local 10.177.1.142 port 54910 connected with 10.177.2.154 port 5001
[ ID] Interval       Transfer     Bandwidth
[3]0.0- 5.0 sec9.59 GBytes9.1 Gbits/sec


Step3 : iperf3 도구를 활용한 Qos 대역폭 제한이 걸린 pod 를 통한 최대 사용 가능 전송 대역폭 확인

netlox@nd:~$ kubectl exec -i -t iperf3 -- /bin/bash
root@iperf3:/# iperf -s 


netlox@nd:~$ kubectl exec -i -t iperf1 -- /bin/bash
root@iperf1:/#  iperf -c 10.177.2.154 -t 5
------------------------------------------------------------
Client connecting to 10.177.2.154, TCP port 5001
TCP window size: 2.76 MByte (default)
------------------------------------------------------------
[  3] local 10.177.0.223 port 54910 connected with 10.177.2.154 port 5001
[ ID] Interval       Transfer     Bandwidth
[3]0.0- 5.0 sec9.38 GBytes496 Mbits/sec
 

Conclusion


본 블로그에서는 자사 솔루션인 LoxiCNI 를 사용하여 클라우드 네이티브 환경에서 정책 기반 네트워크 QoS를 쉽고 효과적으로 관리하고 적용할 수 있는 방법을 알아 보았습니다. 이 블로그에서는 Pod/Deployment 레벨의 QoS에 초점을 맞추고 있지만, LoxiCNI는 Kubernetes의 다양한 엔드 투 엔드 네트워크 QoS 요건을 충족하기 위해 마킹/큐잉/스케줄링 등 다양한 QoS 기능을 개발 중에 있습니다. 해당 기능들은 향후 거래, 은행 및 통신사의 클라우드 네이티브 환경에서 매우 중요한 기능이 될 것으로 생각 됩니다.





조회수 63회댓글 0개

최근 게시물

전체 보기