AEWS 3기 - EKS 네트워킹 (3) TAR, kube-proxy IPVS 모드

이 글은 가시다님과 함께하는 AEWS 3기의 내용을 정리한 것입니다

 

Topology Aware Routing (TAR)

TAR은 지난번 스터디에서 정리한 내용에서 조금 더 설명을 보충해보겠다.

 

TAR은 AZ간 트래픽 패턴을 잡아주는 것으로 특히 비용 절감이나 네트워크 속도 개선등에 쓰일 수 있다.

결론만 말하자면 같은 AZ에 통신을 우선으로 적용해주는 것이다. 이러한 구현은 모두 iptable을 통해서 진행한다.

 

https://aws.amazon.com/ko/blogs/tech/amazon-eks-reduce-cross-az-traffic-costs-with-topology-aware-hints/

Amazon EKS에서 Topology Aware Hint 기능을 활용하여 Cross-AZ 통신 비용 절감하기 | Amazon Web Services

 

해당 블로그 글에도 잘 나와있다. 그림의 상단은 TAR이 적용되지 않은 경우라서, 각 AZ간 통신이 발생하고, 이에 비용도 발생할 수 있다.

하단 그림은 AZ간 통신이 없는 TAR이 적용된 상태이다.

이 기능은 쿠버네티스 1.21부터 등장했고, 1.24부터는 별도의 설정없이도 이 기능을 이용할 수 있게되었다.

 

일단 하단 명령어를 통해서 워커노드의 AZ부터 살펴보았다. 각각 다른 AZ를 가진것을 확인할 수 있다.

kubectl get node --label-columns=topology.kubernetes.io/zone

 

테스트를 위한 deployment,service를 배포하자.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-echo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: websrv
        image: registry.k8s.io/echoserver:1.5
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: svc-webport
      port: 80
      targetPort: 8080
  selector:
    app: deploy-websrv
  type: ClusterIP
EOF

 

접속할 netshoot 클라이언트 파드이다.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: netshoot-pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

 

나의 경우 netshoot 파드가 a AZ에 생성된 것을 확인할 수 있다.

 

아무 설정 없이 일단 100번을 호출해보면 적당히 부하분산되는 것을 확인할 수 있다.

kubectl exec -it netshoot-pod -- zsh -c "for i in {1..100}; do curl -s svc-clusterip | grep Hostname; done | sort | uniq -c | sort -nr"

 

언제 가장 잘 작동하는가?

https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/

Topology Aware Routing

 

공식문서에서는 TAR을 적용하기 좋은 조건에 대해서 설명해준다.

1. 유입 트래픽이 고르게 분산되는 환경인 경우

- 트래픽이 해당 AZ에서 단순하게 움직이는 경우 좋다. 만약 트래픽 대부분이 단일 구역(단일 AZ)에서만 발생하는 경우 권장되지 않는다.

각 AZ별로 동일한 서비스가 있을 때 유리하다는 이야기다.

 

2. 서비스에는 영역당 3개 이상의 엔드포인트가 있는 경우

3개 이상의 AZ를 가지고 있으며, 클러스터에서 9개 이상의 엔드포인트를 가지고 있을때 유리하다.

 

 

IPVS 프록시모드

쿠버네티스에서는 기본적으로 iptable모드를 사용하고 있다. 이는 단순하고 유리하지만 iprule이 많아질 경우 결국은 비효율적이기도하다. IPVS 모드는 이러한 iptable을 효율적으로 관리한다.  iptable의 netfilter를 통해서 처리하면 단순히 iptable을 리소스가 늘어날때마다 무작정 늘리는 방식이기 때문에 그러한 방식에서 탈피할 수 있다. 다만 모든 서비스에서 IPVS가 대체 가능하다고 하기는 어렵다. 아직까지는 iptable을 우선해서 많이 사용하고 있다.

 

아래 도표에서 리소스 생성시 정책 수를 비교해보면 iptable 프록시 모드의 수가 훨씬 많다는 것을 볼 수 있다.

ipvs vs iptables Proxy 모드 사용 시 동일 서비스 리소스 생성 시 정책 수 비교 https://blog.naver.com/yu3papa/223606366440ALT

 

 

IPVS모드란?

IPVS는 커널 영역에 존재하면서 넷필터에서 동작하는 L4 로드밸런서이다. 로드밸런서 이므로 제공하는 알고리즘은 rr(라우드로빈), 최소연결, 목적지 해싱, 출발지 해싱, 최단시간 스케쥴 등 다양한 알고리즘을 제공하고 있다.

- rr (Round Robin)
- wrr (Weighted Round Robin)
- lc (Least Connections)
- wlc (Weighted Least Connections)
- lblc (Locality Based Least Connections)
- lblcr (Locality Based Least Connections with Replication)
- sh (Source Hashing)
- dh (Destination Hashing)
- sed (Shortest Expected Delay)
- nq (Never Queue)

 

아래 공식 가이드에서 조금 더 내용을 확인해 볼 수 있다.

https://docs.aws.amazon.com/eks/latest/best-practices/ipvs.html

 

 

IPVS 적용하기

IPVS는 kube-proxy에서 사용된다. 따라서 EKS kube-proxy addon을 수정하고 재실행해야하는 단점이 있기에 반드시 운영 클러스터 적용에는 신중해야한다.

 

먼저 적용하기 앞서 기본적으로 iptables를 활용하는지 확인해본다. iptables 모드인 것을 볼 수 있다.

kubectl get cm -n kube-system kube-proxy-config -o yaml | egrep 'mode|scheduler'

 

적용하기 위해서는 노드에 ipvsadm ipset이 설치되어야 한다.

sudo dnf install -y ipvsadm ipset -y

 

필요한 IPVS의 부하분산 알고리즘을 각 노드에 적용시킨다.

이 내용은 위에서 설정한 알고리즘에 대한 것으로 본인이 사용할 알고리즘에 대해서 생각해보기 바란다.

sudo sh -c 'cat << EOF > /etc/modules-load.d/ipvs.conf
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_lc
ip_vs_wlc
ip_vs_lblc
ip_vs_lblcr
ip_vs_sh
ip_vs_dh
ip_vs_sed
ip_vs_nq
nf_conntrack
EOF'


sudo modprobe ip_vs
sudo modprobe ip_vs_rr
sudo modprobe ip_vs_wrr
sudo modprobe ip_vs_lc
sudo modprobe ip_vs_wlc
sudo modprobe ip_vs_lblc
sudo modprobe ip_vs_lblcr
sudo modprobe ip_vs_sh
sudo modprobe ip_vs_dh
sudo modprobe ip_vs_sed
sudo modprobe ip_vs_nq
sudo modprobe nf_conntrack

 

lsmod를 통해서 잘 적용되었는지 확인해본다. 각 노드별로 확인해봅니다.

sudo lsmod | grep ^ip_vs

 

eksctl을 통해서 kube-proxy에 해당 내용을 적용시킨다.

aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \
  --configuration-values '{"ipvs": {"scheduler": "rr"}, "mode": "ipvs"}' \
  --resolve-conflicts OVERWRITE

 

콘솔에서도 확인이 가능하다.

 

 

kube-proxy를 재시작한다.

kubectl -n kube-system rollout restart ds kube-proxy

 

적용여부는 mode를 확인한다.

kubectl get cm -n kube-system kube-proxy-config -o yaml | egrep 'mode|scheduler'

 

iptable의 수가 줄어들고, ipvsadm에서 부하분산 정보에서 처리하기 때문에

 

#
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c addr; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo iptables -t nat -S; echo; done

 

 

ipvsadm 명령어를 통해서 라우팅 규칙을 살펴보고 알고리즘을 확인할 수 있다.

sudo ipvsadm -Ln

 

 

 

sudo iptables -t nat -S | wc -l

pod가 없는 상태에서 해보긴 했지만 ipvs 적용전에 96개의 table이 적용후 93개로 축소되었다. 지금은 운영중인 서비스가 극 소수이기때문에 큰 변화는 없지만 서비스가 다양하고 복잡해질수록 빛을 발휘하게 될 것이다.

sudo ipset -L

 

해당 항목에서 IPVS IP set을 관리해서 iptable의 수가 줄게 되는 요인이기도 하다.