AWS Load Balancer Controller가 EKS 리소스를 감시해 ALB, NLB, TargetGroupBinding을 만드는 흐름을 개념적으로 정리합니다.
이 글은 EKS에서 AWS Load Balancer Controller를 사용할 때 Ingress, Service, IngressClass, loadBalancerClass, TargetGroupBinding이 어떻게 연결되는지 설명합니다.
AWS Load Balancer Controller란 무엇인가
AWS Load Balancer Controller는 Kubernetes 리소스를 보고 AWS Load Balancer 리소스를 생성하고 관리하는 컨트롤러입니다. 사용자가 AWS 콘솔에서 ALB나 NLB를 직접 만드는 방식이 아니라, Kubernetes에 선언한 상태를 AWS 리소스로 맞추는 방식입니다.
대표적으로 `Ingress`는 ALB 생성 흐름과 연결되고, `Service type: LoadBalancer`는 NLB 생성 흐름과 연결됩니다. Controller는 Kubernetes API를 감시하다가 필요한 AWS 리소스를 만들고, 변경 사항이 생기면 다시 맞춥니다.
핵심은 Controller가 “Kubernetes 리소스와 AWS Load Balancer 사이의 번역기” 역할을 한다는 점입니다.
EKS에서 LB Controller를 사용할 수 있는 이유
Kubernetes Controller는 API Server에 저장된 리소스 상태를 계속 관찰합니다. AWS Load Balancer Controller도 같은 방식으로 `Ingress`, `Service`, `TargetGroupBinding` 같은 리소스를 감시합니다.
Controller Pod는 EKS 안에서 실행되지만, ALB, NLB, Target Group, Listener 같은 AWS 리소스를 만들려면 AWS API 호출 권한이 필요합니다. 그래서 IRSA 또는 EKS Pod Identity 같은 방식으로 Controller에 IAM 권한을 부여합니다.
이 구조 덕분에 사용자는 Kubernetes YAML을 적용하고, Controller는 그 YAML을 보고 AWS 네트워크 리소스를 생성하는 방식으로 운영할 수 있습니다.
NLB는 언제 생성되는가
NLB는 주로 `Service` 리소스에서 생성됩니다. `type: LoadBalancer`를 사용하고 `spec.loadBalancerClass: service.k8s.aws/nlb`를 지정하면 AWS Load Balancer Controller가 해당 Service를 NLB 대상으로 처리합니다.
NLB는 L4 계층에서 TCP, UDP, TLS 트래픽을 처리하는 데 적합합니다. HTTP 경로 기반 라우팅보다 네트워크 계층의 빠른 전달과 고정적인 연결 처리가 필요할 때 자주 사용합니다.
과거 방식에서는 annotation으로 NLB 생성을 지정하는 예시도 많지만, 새 구성에서는 `loadBalancerClass`를 함께 이해하는 것이 좋습니다.
NLB 생성 시 EKS 안에 생기는 리소스
NLB를 만들 때 사용자가 직접 생성하는 핵심 리소스는 `Service`입니다. 이 Service가 어떤 Pod로 트래픽을 보낼지는 selector와 EndpointSlice를 통해 연결됩니다.
AWS Load Balancer Controller는 Service를 처리하는 과정에서 `TargetGroupBinding`을 사용할 수 있습니다. TargetGroupBinding은 Kubernetes Service와 AWS Target Group을 연결하는 CRD입니다.
트러블슈팅할 때는 Service만 보면 부족합니다. Service, EndpointSlice, TargetGroupBinding, Event, Controller 로그를 같이 봐야 실제로 어떤 단계에서 막혔는지 알 수 있습니다.
ALB는 언제 생성되는가
ALB는 주로 `Ingress` 리소스에서 생성됩니다. `ingressClassName: alb`를 지정하거나 관련 IngressClass를 구성하면 AWS Load Balancer Controller가 해당 Ingress를 처리합니다.
ALB는 L7 계층에서 HTTP/HTTPS 요청을 처리합니다. Host 기반 라우팅, Path 기반 라우팅, TLS 종료, Listener Rule 같은 웹 트래픽 제어가 필요할 때 적합합니다.
Ingress annotation을 사용하면 internet-facing 또는 internal scheme, target type, health check path, certificate, listener port 같은 세부 동작을 설정할 수 있습니다.
ALB 생성 시 EKS 안에 생기는 리소스
ALB 흐름에서 사용자가 주로 작성하는 리소스는 `Ingress`, `Service`, `Deployment`입니다. Ingress는 외부 요청 규칙을 정의하고, Service는 Pod 집합의 접근 지점을 제공합니다.
추가로 `IngressClass`와 `IngressClassParams`를 사용할 수 있습니다. IngressClass는 어떤 Controller가 Ingress를 처리할지 지정하고, IngressClassParams는 ALB 관련 기본 설정을 묶는 데 사용할 수 있습니다.
Controller는 이 정보를 기반으로 AWS에 ALB, Listener, Listener Rule, Target Group을 생성합니다. EKS 안에서는 관련 Event와 TargetGroupBinding 상태를 확인할 수 있습니다.
TargetGroupBinding이 중요한 이유
TargetGroupBinding은 Kubernetes Service와 AWS Target Group을 연결하는 리소스입니다. 쉽게 말해 “이 Service의 대상 Pod 또는 Node를 이 Target Group에 등록하라”는 연결 정보입니다.
AWS Load Balancer Controller는 Ingress, Service, Gateway 흐름을 처리할 때 TargetGroupBinding을 내부적으로 사용할 수 있습니다. 공식 문서에서도 TargetGroupBinding은 controller에 의해 자동 생성될 수 있다고 설명합니다.
또한 이미 존재하는 AWS Target Group을 Kubernetes Service와 연결하고 싶을 때 TargetGroupBinding을 직접 작성하는 방식도 가능합니다.
IngressClass, loadBalancerClass, GatewayClass 차이
`IngressClass`는 어떤 Controller가 Ingress를 처리할지 나타냅니다. ALB Ingress를 만들 때 `ingressClassName: alb`를 쓰는 이유가 여기에 있습니다.
`loadBalancerClass`는 Service type LoadBalancer를 어떤 Controller가 처리할지 나타냅니다. AWS Load Balancer Controller에서 NLB를 처리할 때 `service.k8s.aws/nlb` 값을 사용할 수 있습니다.
`GatewayClass`는 Gateway API에서 어떤 구현체가 Gateway를 처리할지 나타냅니다. 사용자가 말한 `lb choice`는 공식 리소스명으로 확인되지는 않으며, 문맥상 `loadBalancerClass` 또는 `IngressClass`를 의미한 것으로 보는 것이 맞습니다.
| 리소스 | 적용 대상 | 의미 |
|---|---|---|
| IngressClass | Ingress | Ingress 처리 Controller 선택 |
| loadBalancerClass | Service type LoadBalancer | LoadBalancer Service 처리 Controller 선택 |
| GatewayClass | Gateway API | Gateway 구현체 선택 |
Instance Target과 IP Target 차이
Target Group에는 대상 등록 방식이 있습니다. `instance` 모드는 Worker Node를 Target으로 등록하고 NodePort를 통해 Pod로 전달합니다.
`ip` 모드는 Pod IP를 Target Group에 직접 등록합니다. 이 방식은 Pod로 더 직접적인 경로를 만들 수 있지만, VPC CNI와 Pod IP 접근 가능성을 고려해야 합니다.
ALB와 NLB 모두 어떤 target type을 사용할지에 따라 보안 그룹, health check, 트래픽 경로, 장애 분석 방식이 달라질 수 있습니다.
대표 YAML 예시
아래 예시는 실제 환경 값이 아닌 더미 예시입니다. 실제 도메인, 계정 ID, Target Group ARN, 인증서 ARN, subnet ID는 블로그에 노출하지 않는 것이 안전합니다.
apiVersion: v1
kind: Service
metadata:
name: app-nlb
namespace: demo-namespace
spec:
type: LoadBalancer
loadBalancerClass: service.k8s.aws/nlb
selector:
app: demo-app
ports:
- port: 80
targetPort: 8080
protocol: TCP
---
# ALB 생성 예시: Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-alb
namespace: demo-namespace
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80
---
# IngressClass 예시
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
spec:
controller: ingress.k8s.aws/alb
---
# TargetGroupBinding 예시
apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
name: app-tgb
namespace: demo-namespace
spec:
serviceRef:
name: app-service
port: 80
targetGroupARN: arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/example-tg/exampleid
targetType: ip
YAML을 볼 때는 어떤 리소스가 AWS Load Balancer 생성을 트리거하는지 먼저 보면 됩니다. ALB는 Ingress 중심, NLB는 Service 중심, TargetGroupBinding은 Service와 Target Group 연결 중심입니다.
트러블슈팅 시 봐야 할 것
문제가 생기면 Kubernetes 리소스와 AWS 리소스를 함께 봐야 합니다. Controller는 두 세계를 연결하므로 한쪽만 보면 원인을 놓치기 쉽습니다.
2. Controller 로그 확인
3. Ingress 또는 Service Event 확인
4. TargetGroupBinding 생성 여부와 상태 확인
5. EndpointSlice에 대상 Pod가 있는지 확인
6. AWS Target Group Health Check 확인
7. Subnet tag와 Security Group rule 확인
8. IAM 권한과 IRSA 또는 Pod Identity 확인
9. annotation 오타 확인
10. ingressClassName 또는 loadBalancerClass 확인
특히 Target Group Health Check가 실패하면 Load Balancer는 생성되어 있어도 실제 트래픽은 Pod로 전달되지 않을 수 있습니다. 그래서 “LB가 생성됐는가”와 “Target이 healthy인가”를 분리해서 확인해야 합니다.
최신 동작은 How it works, TargetGroupBinding, IngressClass, NLB Service 문서를 기준으로 확인하는 것이 좋습니다.
SUMMARY
FAQ
Ingress를 만들면 항상 ALB가 생성되나요?
아닙니다. `ingressClassName`, IngressClass, Controller 설정이 AWS Load Balancer Controller와 맞아야 합니다.
Service type LoadBalancer는 항상 NLB인가요?
AWS Load Balancer Controller 기준에서는 `loadBalancerClass: service.k8s.aws/nlb` 또는 관련 설정으로 NLB 생성을 지정할 수 있습니다.
TargetGroupBinding은 직접 만들어야 하나요?
일반적인 Ingress나 Service 흐름에서는 Controller가 자동으로 만들 수 있습니다. 기존 Target Group을 직접 연결할 때는 사용자가 작성할 수도 있습니다.
AWS Load Balancer Controller를 이해하려면 ALB와 NLB만 보면 부족합니다. Kubernetes 안의 Ingress, Service, IngressClass, loadBalancerClass, TargetGroupBinding이 AWS의 Load Balancer, Listener, Target Group과 어떻게 연결되는지를 함께 봐야 합니다. 문제가 생겼을 때도 Controller 로그와 Kubernetes Event, AWS Target Health를 같이 확인해야 빠르게 원인을 찾을 수 있습니다.
'AWS Guides' 카테고리의 다른 글
| 도메인과 서브도메인 차이 이해하기: AWS와 애플리케이션에서 트래픽을 나누는 방식 (0) | 2026.08.31 |
|---|---|
| AWS TGW + Network Firewall Inspection VPC 라우팅 설계: subnet 분리와 local route 변경이 필요한 이유 (0) | 2026.08.31 |
| AWS IAM AssumeRole 이해하기: IAM 권한 없이도 동일 계정 Role 전환이 가능한 이유 (0) | 2026.08.30 |
| IAM PassRole과 AssumeRole 차이: AWS 권한 위임과 역할 수임이 보안상 위험한 이유 (0) | 2026.08.13 |
| AWS 서브넷 라우팅 변경 기준: /32 우회가 안 되는 이유와 서브넷 단위 트래픽 전환 설계 (0) | 2026.08.09 |
