[EKS] ALB Ingress Controller 필요성

개요

EKS 환경에서 ALB Ingress Controller를 삭제를 진행하였음에도 서비스가 여전히 동작한다. 그렇다면 굳이 ALB Ingress Controller가 필요하지 않을 것이라 생각하겠지만, 운영중인 EKS 환경이 만약 Ingress rule기반으로 네트워킹 구성이 되어 있다면 ALB Ingress Controller는 반드시 필요한 존재이다.

 

그렇다면, EKS 환경에서 ALB Ingress Controller의 존재의의는 무엇이며 왜 Ingress Controller가 필요한지 알아보자.

 

리마인드

Ingress는 클러스터 외부에서 내부 서비스로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음이다. HTTP(S) 등 네트워크 L7에 대한 설정을 담당하는 리소스이며 기본적인 역할은 외부 HTTP 호출에 대한 트래픽을 처리한다.

Ingress의 기능에서는 아래 3가지 요소를 포함한다.

1. Ingress API Object
2. L7 Load Balancer 혹은 Reverse Proxy: 백엔드 서비스로 트래픽을 라우팅
3. Ingress Controller: Ingress의 규칙을 읽고 외부의 트래픽을 Service로 전달하는 주체

 

---

ALB Ingress Controller 동작 방식

① ALB Ingress Controller는 API서버로부터 전달받는 실시간 Ingress 관련 이벤트를 감시하며 Ingress 리소스가 AWS 자원 생성에 충족하는 요건을 갖춘다면  AWS 인프라 내 자원을 생성한다.

② ALB는 Ingress 레벨에서 생성되며(1 ingress = 1 ALB), 외부 통신용(Internet-facing) 혹은 내부 통신용(Internal)으로 설정될 수 있으며, 또한 특정 서브넷에 지정할 수 있다.

③ Target Group은 Ingress 리소스에서 정의되는 쿠버네티스 서비스 단위로 구성이 된다.

④ Listener 항목은 Ingress annotaion 바탕으로 포트가 할당이 된다. 만약 ingress에 별도의 포트가 지정되지 않았다면 기본적으로 (80/443)가 사용된다.

⑤ Rule 항목 역시 Ingress 내용 바탕으로 구성이 되며, 어느 Kubernetes 서비스에 트래픽이 라우팅될지 명시해준다.

---

ALB Ingress Controller 역할

 

• ALB-Ingress-Controller는 AWS 인프라와 쿠버네티스 클러스터간 중개 역할을 수행한다.
• ALB Ingress Controller는 쿠버네티스 API Server로부터 실시간으로 Ingress의 이벤트 변화를 감지하며, 쿠버네티스 클러스터에서 일어나는 실시간 변화를 AWS 인프라에 반영한다.

※ 만약, ALB-Ingress-Controller가 존재하지 않는다면, 쿠버네티스 Ingress 자원과 연관된 변화(추가/삭제/수정)가 AWS ELB 관련 리소스에 반영되지 않는다. (AWS ↔ K8S 중개인이 없기 때문에)

 

---

참조

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/how-it-works/