[AEWS] # 2주차 aws 로드밸런서 컨트롤러와 인그레스 트래픽 분석 (4)

25년도 AWS EKS Hands-on Study 스터디 정리 내용입니다.

aws 로드밸런서 컨트롤러 배포 실습

AWS 로드밸런서 컨트롤러는 쿠버네티스에서 AWS의 로드 밸런서를 자동으로 프로비저닝하고 관리하는 컨트롤러이다.

쿠버네티스 클러스터에서 파드로 트래픽을 전달하기 위해 aws 로드밸런서를 자동으로 생성하고 설정하는 역할을 수행한다.

로드밸런서 컨트롤러 배포

kubectl get crd
NAME                                         CREATED AT
cninodes.vpcresources.k8s.aws                2025-02-15T17:37:19Z
eniconfigs.crd.k8s.amazonaws.com             2025-02-15T17:41:54Z
policyendpoints.networking.k8s.aws           2025-02-15T17:37:19Z
securitygrouppolicies.vpcresources.k8s.aws   2025-02-15T17:37:19Z

helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=myeks

kubectl get crd
NAME                                         CREATED AT
cninodes.vpcresources.k8s.aws                2025-02-15T17:37:19Z
eniconfigs.crd.k8s.amazonaws.com             2025-02-15T17:41:54Z
ingressclassparams.elbv2.k8s.aws             2025-02-16T05:56:45Z <- 추가
policyendpoints.networking.k8s.aws           2025-02-15T17:37:19Z
securitygrouppolicies.vpcresources.k8s.aws   2025-02-15T17:37:19Z 
targetgroupbindings.elbv2.k8s.aws            2025-02-16T05:56:45Z <- 추가

aws 로드밸런서 컨트롤러를 배포하면 아래에 인그레스와 타겟 그룹 바인딩이 추가되는 것을 확인할 수 있다.

ingressclassparams.elbv2.k8s.aws는 aws 로드밸런서 컨트롤러가 인그레스 리소스를 처리하는 방식을 설정하여 트래픽을 처리하는 방식을 결정한다.

loadBalancerType을 application 또는 network로 설정하여 ALB나 NLB를 선택할 수 있고, scheme을 internal로 지정하면 내부 네트워크에서만 접근할 수 있도록 설정할 수도 있다. 또한 ip 주소 유형을 지정할 수 있으며 그룹을 활용하여 여러 개의 인그레스 리소스를 동일한 로드밸런서에서 서비스할 수도 있다. 그리고 AWS의 firewall인 WAF를 적용할 수 있도록 wafACL 옵션을 설정할 수 있다.

targetgroupbindings.elbv2.k8s.aws는 aws 타겟 그룹과 쿠버네티스 서비스 간의 연결을 설정하는 리소스이다. ALB 또는 NLB를 사용할 때, 쿠버네티스 서비스가 어떤 타겟 그룹에 바인딩될지를 정의하는 역할을 한다.

일반적으로 aws 로드밸런서 컨트롤러가 자동으로 Target Group을 생성하고 관리하지만, 특정 Target Group을 수동으로 바인딩해야 할 경우 직접 설정할 수 있다. 이 리소스에서는 targetGroupARN을 지정하여 연결할 AWS Target Group을 정의하고 serviceRef를 통해 어떤 쿠버네티스 서비스와 연결할지를 설정할 수 있다.

또한 네트워킹 옵션을 활용해 인그레스 트래픽의 네트워크 규칙을 설정하고 헬스체크를 통해 타겟 그룹과 쿠버네티스의 서비스 상태를 지속적으로 확인할 수 있다.

NLB 기반 로드밸런싱 외부 트래픽 모니터링하기

aws elbv2 describe-load-balancers --query 'LoadBalancers[*].State.Code' --output text
provisioning

kubectl get deploy,pod
NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/deploy-echo   2/2     2            2           69s

NAME                              READY   STATUS    RESTARTS   AGE
pod/deploy-echo-bf9bdb8bc-j8nv2   1/1     Running   0          69s
pod/deploy-echo-bf9bdb8bc-k8rfm   1/1     Running   0          69s

kubectl get svc,ep,ingressclassparams,targetgroupbindings
NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP                                                                         PORT(S)        AGE
service/kubernetes        ClusterIP      10.100.0.1       <none>                                                                              443/TCP        12h
service/svc-nlb-ip-type   LoadBalancer   10.100.211.196   k8s-default-svcnlbip-23bdb42a5b-60cc42917afec8f6.elb.ap-northeast-2.amazonaws.com   80:30732/TCP   74s

NAME                        ENDPOINTS                             AGE
endpoints/kubernetes        192.168.1.30:443,192.168.2.73:443     12h
endpoints/svc-nlb-ip-type   192.168.2.14:8080,192.168.3.84:8080   74s

NAME                                   GROUP-NAME   SCHEME   IP-ADDRESS-TYPE   AGE
ingressclassparams.elbv2.k8s.aws/alb                                           7m39s

NAME                                                               SERVICE-NAME      SERVICE-PORT   TARGET-TYPE   AGE
targetgroupbinding.elbv2.k8s.aws/k8s-default-svcnlbip-126fcb8e49   svc-nlb-ip-type   80             ip            69s

디플로이먼트를 생성하여 2개의 웹 서버 파드를 실행한다. 서비스를 생성하고 이를 aws 로드밸런서 컨트롤러를 사용해서 NLB에 연결한다.

위 내용은 배포된 파드, 서비스, 타겟 그룹 바인딩에 대한 정보이다.

웹 브라우저에서 새로고침할 때마다 NLB를 통해 요청이 들어오면서 파드가 요청을 처리하는 로그가 출력되는 것을 확인할 수 있다.

NLB=$(kubectl get svc svc-nlb-ip-type -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
curl -s $NLB
for i in {1..100}; do curl -s $NLB | grep Hostname ; done | sort | uniq -c | sort -nr

56 Hostname: deploy-echo-bf9bdb8bc-k8rfm
44 Hostname: deploy-echo-bf9bdb8bc-j8nv2

NLB가 요청을 어떤 파드에 얼만큼 보냈는지를 확인한다.

현재 100개의 HTTP 요청을 NLB를 통해 보냈고 트래픽이 2개의 파드로 분산된 것을 확인하는 과정을 알 수 있다.

만약 파드의 레플리카를 늘리게 되면 부하 분산을 처리 받는 파드가 늘어나게 되어 트래픽을 처리하게 된다.

인그레스를 활용한 게임 파드 배포

ingress-2048는 ALB를 통해 외부 트래픽을 받아 Kubernetes 내부의 서비스로 전달하는 내용을 실습해본다. ALB는 외부에서 접근 가능하고, ALB가 쿠버네티스 노드가 아닌 파드 IP를 직접 Target으로 사용한다.

kubectl get ingress,svc,ep,pod -n game-2048
NAME                                     CLASS   HOSTS   ADDRESS                                                                       PORTS   AGE
ingress.networking.k8s.io/ingress-2048   alb     *       k8s-game2048-ingress2-70d50ce3fd-302175647.ap-northeast-2.elb.amazonaws.com   80      32s

NAME                   TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/service-2048   NodePort   10.100.179.206   <none>        80:32004/TCP   32s

NAME                     ENDPOINTS                           AGE
endpoints/service-2048   192.168.1.205:80,192.168.3.250:80   32s

NAME                                   READY   STATUS    RESTARTS   AGE
pod/deployment-2048-7df5f9886b-f9kkk   1/1     Running   0          32s
pod/deployment-2048-7df5f9886b-zczdc   1/1     Running   0          32s

kubectl describe ingress -n game-2048 ingress-2048
Name:             ingress-2048
Labels:           <none>
Namespace:        game-2048
Address:          k8s-game2048-ingress2-70d50ce3fd-302175647.ap-northeast-2.elb.amazonaws.com
Ingress Class:    alb
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /   service-2048:80 (192.168.3.250:80,192.168.1.205:80)
Annotations:  alb.ingress.kubernetes.io/scheme: internet-facing
              alb.ingress.kubernetes.io/target-type: ip
Events:
  Type    Reason                  Age    From     Message
  ----    ------                  ----   ----     -------
  Normal  SuccessfullyReconciled  3m35s  ingress  Successfully reconciled

kubectl get pod,ingress,svc,ep,endpointslices -n game-2048                                                  Sun Feb 16 15:38:50 2025

NAME                                   READY   STATUS    RESTARTS   AGE
pod/deployment-2048-7df5f9886b-f9kkk   1/1     Running   0          11m
pod/deployment-2048-7df5f9886b-zczdc   1/1     Running   0          11m

NAME                                     CLASS   HOSTS   ADDRESS                                                                       PORTS   A
GE
ingress.networking.k8s.io/ingress-2048   alb     *	 k8s-game2048-ingress2-70d50ce3fd-302175647.ap-northeast-2.elb.amazonaws.com   80      1
1m

NAME                   TYPE	  CLUSTER-IP	   EXTERNAL-IP   PORT(S)        AGE
service/service-2048   NodePort   10.100.179.206   <none>        80:32004/TCP   11m

NAME                     ENDPOINTS                           AGE
endpoints/service-2048   192.168.1.205:80,192.168.3.250:80   11m

NAME                                                ADDRESSTYPE   PORTS   ENDPOINTS                     AGE
endpointslice.discovery.k8s.io/service-2048-4lzmp   IPv4          80	  192.168.3.250,192.168.1.205   11m

리소스맵을 보면 ALB가 HTTP 요청을 받아서 지정된 타겟 그룹으로 전달한다. 생성된 타겟 그룹에는 2개의 ip가 등록돼있는데 이는 쿠버네티스에서 실행 중인 2048 게임의 파드 ip이다.

ALB가 트래픽을 받아 타겟 그룹을 통해 Game 2048 Pod로 전달하는 구조임을 확인할 수 있다.

ALB -> 파드 트래픽 확인

ALB에서 들어오는 트래픽이 ec2에 도착했는지 확인

sudo iptables -v --numeric --table nat --list PREROUTING
Chain PREROUTING (policy ACCEPT 515 packets, 31632 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1281 81886 KUBE-SERVICES  all  --  *      *       0.0.0.0/0            0.0.0.0/0  /* kubernetes service portals */
   22  1748 AWS-CONNMARK-CHAIN-0  all  --  eni+   *       0.0.0.0/0            0.0.0.0/0  /* AWS, outbound connections */
  514 31572 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0  /* AWS, CONNMARK */ CONNMARK restore mask 0x80

ALB에서 들어온 트래픽이 KUBE-SERVICES 체인으로 전달되는 것을 알 수 있다.

AWS-CONNMARK-CHAIN-0: AWS에서 관리하는 연결 추적, 외부 트래픽을 모니터링하는 역할을 수행한다.

KUBE-SERVICES 체인에서 쿠버네티스 서비스로 전달

sudo iptables -t nat -L KUBE-SERVICES -n -v
Chain KUBE-SERVICES (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 KUBE-SVC-TCOU7JCQXEZGVUNU  udp  --  *      *       0.0.0.0/0            10.100.0.10  /* kube-system/kube-dns:dns cluster IP */ udp dpt:53
    0     0 KUBE-SVC-V7WHPSTR7G6YHTBY  tcp  --  *      *       0.0.0.0/0            10.100.179.206  /* game-2048/service-2048 cluster IP */ tcp dpt:80

ALB에서 들어온 HTTP 요청(포트 80)이 game-2048/service-2048으로 전달되는데,

ALB → Ingress → Kubernetes Service (10.100.179.206)로 트래픽이 이동하게된다.

KUBE-SVC-* 체인에서 특정 Pod으로 트래픽 분배

sudo iptables -v --numeric --table nat --list KUBE-SVC-V7WHPSTR7G6YHTBY
Chain KUBE-SVC-V7WHPSTR7G6YHTBY (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 KUBE-SEP-OBK75HIRYFJMGQNA  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* game-2048/service-2048 -> 192.168.1.205:80 */ statistic mode random probability 0.50000000000
    0     0 KUBE-SEP-CG6NLPOJTSMBSPCP  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* game-2048/service-2048 -> 192.168.3.250:80 */

이 체인은 Kubernetes Service(game-2048/service-2048)가 트래픽을 특정 Pod으로 라우팅하는 역할을 하는데, 2개의 KUBE-SEP-* 체인을 사용하여 Pod(192.168.1.205:80, 192.168.3.250:80)으로 트래픽을 전달한다.

statistic mode random probability 0.50000000000 → 두 개의 Pod에 대해 50% 확률로 트래픽을 분배하는 라운드 로빈 방식으로 쿠버네티스 서비스가 두 개의 Pod으로 로드 밸런싱을 수행하고 있는 것을 확인할 수 있다.

KUBE-SEP-* 체인에서 특정 파드로 DNAT 변환

[ec2-user@ip-192-168-1-112 ~]$ sudo iptables -v --numeric --table nat --list KUBE-SEP-OBK75HIRYFJMGQNA
Chain KUBE-SEP-OBK75HIRYFJMGQNA (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 KUBE-MARK-MASQ  all  --  *      *       192.168.1.205        0.0.0.0/0            /* game-2048/service-2048 */
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* game-2048/service-2048 */ tcp to:192.168.1.205:80
[ec2-user@ip-192-168-1-112 ~]$ sudo iptables -v --numeric --table nat --list KUBE-SEP-CG6NLPOJTSMBSPCP
Chain KUBE-SEP-CG6NLPOJTSMBSPCP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 KUBE-MARK-MASQ  all  --  *      *       192.168.3.250        0.0.0.0/0            /* game-2048/service-2048 */
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* game-2048/service-2048 */ tcp to:192.168.3.250:80

각 파드마다 KUBE-SEP-* 체인이 생성되고, 서비스로 들어온 트래픽이 파드(192.168.1.205:80, 192.168.1.250:80)으로 DNAT 변환되는 것을 확인할 수 있다.

파드에서 응답 시 POSTROUTING에서 SNAT 적용

sudo iptables -t nat -L POSTROUTING -n -v
Chain POSTROUTING (policy ACCEPT 7250 packets, 446K bytes)
 pkts bytes target     prot opt in     out     source               destination
12029  742K KUBE-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes postrouting rules */
11239  694K AWS-SNAT-CHAIN-0  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* AWS SNAT CHAIN */

이 체인은 패킷이 노드를 떠나기 전에 마지막으로 거치는 체인으로, 파드가 응답을 보낼 때 NAT(SNAT) 처리가 필요할 경우 거치게 되는데
AWS-SNAT-CHAIN-0이 사용하여 패킷의 출발지 IP를 변경한다.

클러스터 내부 트래픽이면 NAT를 적용하지 않고, 외부 트래픽이면 SNAT 변환 (AWS-SNAT-CHAIN-0)되어 나간다.

ALB에서 파드로 들어오는 트래픽 흐름을 정리하면 아래와 같다.

ALB에서 HTTP 요청 발생 → ec2로 전달
PREROUTING 체인이 ALB에서 온 트래픽을 쿠버네티스 서비스로 라우팅
KUBE-SERVICES 체인에서 요청을 적절한 쿠베 서비스로 보냄
KUBE-SVC-* 체인에서 특정 파드로 트래픽을 분배
KUBE-SEP-* 체인에서 파드로 최종 DNAT(목적지 변경) 수행
파드에서 응답을 보낼 때 POSTROUTING에서 SNAT 처리 후 ALB로 응답 반환

'Infra > AWS' 카테고리의 다른 글

[AEWS] #3주차 EFS, ACM 적용한 ALB Ingress로 kube-ops-view 배포 (2) (0)	2025.02.20
[AEWS] # 3주차 로컬 볼륨 실습 : emptyDir, hostPath, Local Path Provisioner (1) (0)	2025.02.18
[AEWS] # 2주차 eks vpc cni 이해하기 (3) (0)	2025.02.16
[AEWS] # 2주차 eks vpc cni 이해하기 (2) (0)	2025.02.16
[AEWS] # 2주차 eks vpc cni 이해하기 (1) (1)	2025.02.16