EKS Ingress Controller (Application LoadBalancer) 유형

Intro

 

AWS의 EKS에서는 Ingress Controller를 Helm or Manifest를 이용해서 Application LoadBalancer or Networ LoadBalancer를 만들 수 있게 해 준다. 만드는 방법은 링크를 참고하면 된다. Ingress Controller를 만들면, 우리가 만든 서비스랑 연결을 해줘야 라우팅이 가능해진다. 여기서 문서를 살펴보니, alb.ingress.kubernetes.io/target-type 라는 타입을 명시할 수가 있는데, 이걸로 네트워크 최적화가 가능했다. 한 번 살펴보자.

 

target-type

 

앞에서 언급한 alb.ingress.kubernetes.io/target-type은 2가지 타입이 instance, ip 타입이 존재한다. 하나씩 알아보자.

 

1. instance

 

instance 타입은 타겟 그룹에 instance(노드)를 등록하고, Service의 NodePort를 활용해서 요청이 전달된다. 플로우는 아래와 같다.

 

1. Ingress Controller (ALB)

2. 타겟 그룹에는 인스턴스가 등록되고, Service의 NodePort가 포트로 등록됨

3. 실행되고 있는 파드

 

플로우를 그려보면 아래와 같다. 

 

 

2. ip

 

ip 타입은 타깃 그룹에 파드를 직접 등록한다. 따라서 instance타입과 다르게 노드를 거치지 않고, 파드로 직접 전달된다. 플로우는 아래와 같다.

 

1. Ingress Controller (ALB)

2. 타겟 그룹에 등록된 파드

 

플로우를 그려보면 아래와 같다.

 

 

결론

 

alb.ingress.kubernetes.io/target-type 설정을 통해서 요청이 도달하는 과정을 줄일 수 있다. 생각해야 할 점은 만약 Session을 사용하고 있다면, ALB의 sticky sessions 설정을 켜는 것도 고려해야 한다.

 

문서를 살펴보면 EKS + fargate 구성을 사용하고 있다면, alb.ingress.kubernetes.io/target-type은 ip 유형만 지원한다.

현재 서비스에서 fargate를 사용하고 있음에도 불구하고, Service를 사용해서 라우팅하고 있는데 Service를 삭제하고 ingress yaml을 수정해야겠다!