AWS EKS에서 ALB Ingress Controller 활용기

코인원 플랫폼 엔지니어가 EKS 한국 리전 오픈 후 핵심 서비스를 옮기며 Ingress Controller로 NGINX 대신 AWS ALB Ingress Controller를 고른 이유와, 구성 과정에서 만난 이슈·활용 팁을 정리한 글이다. 선택 기준은 실서비스에서 문제없이 도는지, 기존 LB 구성을 그대로 쓸 수 있는지, 구성 가이드와 예제 자료가 충분한지 세 가지였다. ALB의 호스트·경로 기반 라우팅이 결정적이었지만 당시에는 정식 버전이 된 지 얼마 안 돼 프로덕션 안정성을 장담할 수 없었다.

핵심 포인트

Ingress Controller는 API 서버의 ingress 이벤트를 감시하다가 ALB, Target Group, Listener, Rule을 차례로 AWS에 만든다
traffic mode는 NodePort로 받는 instance mode와 컨테이너 포트로 직접 꽂는 IP mode 두 가지이고 annotation으로 명시 지정한다
서비스별 ingress 대신 internal·external 두 개만 만들고 호스트 라우팅을 붙였으며 target-type은 instance로 뒀다
namespace 제약이 있어 ALB로 접근해야 하는 서비스는 namespace마다 ingress를 만들어야 한다
ingress가 늘면 worker node에 임의 security group이 계속 생겨 EC2 인스턴스의 security group 한도에 걸린다
운영 중 Controller에서 에러가 나면서 pod 메모리 사용량이 계속 증가하는 문제를 겪었다

상세 정리

배포 준비: IAM Role에 iam-policy.json을 적용해 EKS worker node에 붙이고 kubernetes RBAC role을 apply한다
설치: helm chart로 kube-system 네임스페이스에 설치하며 awsRegion, awsVpcID, clusterName을 넘긴다
WAF 미사용 시: extraArgs로 feature-gates에 waf=false 옵션을 추가해야 한다
instance mode 동작: 외부 트래픽이 ALB를 거쳐 서비스용으로 열린 NodePort에 도달하므로 애플리케이션 서비스 타입을 NodePort로 지정해야 한다
IP mode 조건: 클러스터 네트워킹 플러그인이 ENI의 보조 IP 주소를 쓸 수 있어야 한다
health check 함정: ALB와 target group은 만들어져도 서비스에 healthcheck-path annotation이 없으면 worker node의 target port가 unhealthy로 남는다
security group 대책: 공통 security group을 만들어 ingress annotation에 지정해 불필요한 생성을 막는다
TLS 지정: ACM을 쓴다면 listen-ports와 certificate-arn, ssl-policy annotation으로 인증서를 붙인다
리다이렉션: actions 계열 annotation에 RedirectConfig를 JSON으로 넣고 host rule의 backend servicePort를 use-annotation으로 둔다
https 강제: 같은 방식으로 ssl-redirect action을 만들어 HTTP_301로 443 포트에 보낸다
선택 근거: AWS 환경에서 security group·health check·인증서 지정 같은 옵션과 로드밸런싱 알고리즘 지정, EKS Fargate mode IP 지원 같은 신규 기능을 함께 얻는다고 본다
유보 사항: third party project에서 정식 버전으로 넘어온 지 얼마 안 된 시점이라 안정성 검증은 직접 감당해야 했다