[EKS #2] EKS 아키텍처와 트래픽 흐름

이서진·2026년 9월 22일

aws ecr eks ingress

[Infrastructure]

목록 보기

8/9

1. 목표

앞선 EKS #1에서는 Node → Pod → HPA 관계와 Pod 자동 확장을 살펴봤다.

이번 글에서는 그 Pod가 실제로 올라가 있는 EKS 환경 전체를 직접 그린 아키텍처를 기준으로 살펴본다.

이 글을 읽고 나면 다음을 설명할 수 있다.

Terraform과 EKS가 각각 관리하는 영역
Worker Node를 서로 다른 AZ에 배치하는 이유
Ingress와 AWS Load Balancer Controller, ALB의 관계
사용자 요청이 ALB에서 Pod까지 전달되는 과정
ECR의 이미지가 Pod에서 실행되는 과정
(복습) Deployment, Service, Ingress의 역할

2. 개념

2-1. 전체 구조

이번 실습은 AWS의 EKS 환경에서 EC2 기반 Worker Node를 사용하는 구조로 구성했다.

~~제법 잘그렸지요?😶~~

구성 요소의 역할 :

구성 요소	역할
Terraform	AWS 인프라와 EKS 관련 자원 프로비저닝
VPC	EKS가 동작하는 네트워크 영역
AZ	장애를 분리하는 영역
ALB	외부 요청의 진입점
NAT Gateway	Private Subnet의 외부 통신
EKS	Kubernetes 클러스터
Worker Node	Pod가 실행되는 컴퓨팅 자원
Pod	애플리케이션 실행 단위
Deployment	Pod의 배포와 업데이트 관리
Service	Pod 집합을 네트워크 endpoint로 연결
Ingress	HTTP/HTTPS 라우팅 규칙 정의
AWS Load Balancer Controller	Ingress를 기반으로 ALB 구성
ECR	컨테이너 이미지 저장소
Helm	Kubernetes 리소스 배포 및 관리

2-2. Terraform과 Kubernetes의 관리 영역

이번 아키텍처에서는 인프라와 애플리케이션 리소스를 구분해서 관리한다.

관리 주체	주요 리소스
Terraform	VPC, Subnet, IAM, IRSA, ECR, EKS
Kubernetes	Deployment, Service, Ingress, Pod
AWS Load Balancer Controller	Ingress를 기반으로 구성되는 ALB 관련 설정

Terraform으로 먼저 EKS가 동작할 인프라와 Worker Node를 구성하고, 이후 Kubernetes 리소스를 배포한다.

Terraform
   ↓
VPC / EKS / ECR / IAM
   ↓
Kubernetes
   ↓
Deployment / Service / Ingress
   ↓
Pod

2-3. Region → VPC → AZ → Subnet

AWS 네트워크는 다음과 같은 계층으로 구성된다.

Region
└── VPC
    ├── AZ-1
    │   ├── Public Subnet
    │   └── Private Subnet
    │
    └── AZ-2
        ├── Public Subnet
        └── Private Subnet

이번 구성에서는 Worker Node를 서로 다른 AZ에 배치해서, 고가용성을 확보했다.

(하나의 AZ에 장애가 발생하더라도 다른 AZ에서 실행 중인 Node와 Pod를 통해 서비스 유지)

AZ-1                     AZ-2

Worker Node 1             Worker Node 2
   ├── Pod                 ├── Pod
   └── Pod                 └── Pod

3. 실제 적용 / 동작

3-1. Public Subnet과 Private Subnet

Public Subnet에는 외부 요청을 받는 ALB와 Private Subnet의 외부 통신을 위한 NAT Gateway를 배치한다.

Worker Node는 외부에서 직접 접근할 필요가 없으므로 Private Subnet에 배치한다.

[인바운드]

Internet
   ↓
ALB
   ↓
Private Subnet
   ↓
Worker Node / Pod


[아웃바운드]

Worker Node
   ↓
NAT Gateway
   ↓
Internet Gateway
   ↓
Internet

3-2. Ingress → AWS Load Balancer Controller → ALB

Ingress와 ALB는 다른 구성요소이고,
각각의 Controller가 존재한다.

구성요소	역할
Ingress	HTTP/HTTPS 라우팅 규칙 정의 리소스
Ingress Controller	리소스 감시, Ingress 규칙 실제 환경에 반영
ALB	실제 외부 HTTP/HTTPS 요청 처리, L7 Layer LB
AWS Load Balancer Controller	AWS에서 Ingress Controller 역할 수행, Ingress 설정 기반 ALB 구성(K8s Controller)
Target Group	ALB가 요청을 전달할 대상 관리

예를 들어 Ingress에 다음과 같이 요청 대상을 정의할 수 있다.

/api/users  → user-service
/api/orders → order-service

AWS Load Balancer Controller는 이 Ingress를 확인하고, 정의된 규칙에 따라 ALB의 Listener, Rule, Target Group 등을 구성한다.

Ingress
   ↓
AWS Load Balancer Controller
   ↓
ALB
 ├── Listener
 ├── Rule
 └── Target Group

즉, Ingress가 실제 요청을 전달하는 것이 아니라 Controller가 Ingress 설정을 ALB에 반영하는 구조임을 이해하는 것이 중요하다.

3-3. 실제 트래픽 요청 흐름

ALB가 구성된 이후, 사용자의 요청은 Ingress Resource를 거치지 않고 이미 구성된 ALB로 들어간다.

User / Browser
      ↓
     ALB
      ↓
Target Group
      ↓
    Pod IP

이번 구성처럼 Target Group이 Pod IP를 대상으로 하면, ALB가 Worker Node를 거치지 않고 Pod로 직접 요청을 전달할 수 있다.

AWS Load Balancer Controller는 Kubernetes 리소스의 변경을 감시하고, Pod IP를 ALB Target Group대상으로 등록한다.

Service
   ↓
EndpointSlice
   ↓
Pod IP
   ↓
AWS Load Balancer Controller
   ↓
Target Group

여기서 ClusterIP 자체가 ALB의 대상이 되는 것은 아니다. Service에 연결된 Pod의 endpoint 정보가 EndpointSlice에 기록되고, 이를 기반으로 Pod IP가 관리된다.

반면 Kubernetes에서는 Ingress가 Service를 대상으로 요청 라우팅 규칙을 정의한다.

Ingress
   ↓
Service
   ↓
Pod

따라서 Kubernetes에서 리소스가 연결되는 논리적인 흐름과, 실제 요청이 전달되는 AWS의 네트워크 흐름의 역할이 서로 다르다는 것을 구분해야 한다.

관점	흐름	역할
Kubernetes 논리 관계	Ingress → Service → Pod	Ingress와 Service가 애플리케이션의 라우팅 대상을 정의
AWS 실제 요청	User → ALB → Target Group → Pod IP	ALB와 Target Group이 실제 외부 요청을 처리
ALB 구성 과정	Ingress → AWS LBC → ALB	Controller가 Ingress 설정을 ALB에 반영

3-4. Deployment, Service, Ingress의 관계 (복습)

EKS #1에서 언급했듯, k8s는 각각의 리소스가 담당하는 역할이 다른데 그 역할은 아래와 같다.

리소스	주요 역할	연결되는 대상
Deployment	Pod의 배포, 복제, 업데이트 관리	ReplicaSet → Pod
Service	Pod 집합을 안정적인 네트워크 endpoint로 연결	Pod
Ingress	HTTP/HTTPS 요청의 라우팅 규칙 정의	Service

Deployment는 원하는 Pod 상태를 정의하고, Deployment Controller가 ReplicaSet과 Pod의 상태를 확인하며 유지한다.

Pod가 생성되면 kube-scheduler가 실행할 Worker Node를 선택하고, 해당 Node의 kubelet이 Pod와 Container가 실행되도록 관리한다.

Pod
 ↓
kube-scheduler
 ↓
Worker Node
 ↓
kubelet
 ↓
Container

3-5. Container Image와 Kubernetes 배포 설정

애플리케이션 이미지와 Kubernetes 배포 설정은 서로 다른 경로로 전달된다.

① 애플리케이션 이미지 경로

개발자가 Container Image를 빌드한 후 ECR에 저장 + Worker Node에서 필요 시 해당 이미지 Pull 작업.

Developer
   ↓
Container Image Build
   ↓
ECR
   │
   │ Image Pull
   ↓
Worker Node
   ↓
Pod
   ↓
Container

② Kubernetes 배포 설정 경로

EKS Cluster와 Worker Node가 이미 구성된 상태에서, 개발자 또는 관리자가 Helm을 통해 Kubernetes 리소스를 배포한다.

Developer / Admin
          ↓                    
         Helm ─→ EKS
                  │
                  ├── Deployment → ECR Image 주소정의
                  ├── Service
                  └── Ingress

Deployment에는 실행할 Container Image의 주소가 정의된다.

spec:
  template:
    spec:
      containers:
        - image: <ECR Image 주소>

③ Pod 생성 및 컨테이너 실행

Deployment를 기준으로 Pod 생성, Worker Node 배치
Worker Node는 ECR 이미지가 필요한 경우 ECR 이미지를 Pull, Cantainer 실행

Deployment
    ↓
ReplicaSet
    ↓
Pod
    ↓
kube-scheduler
    ↓
Worker Node
    ↓
ECR에서 Image Pull
    ↓
Container 실행

④ 전체 흐름 :

과정	하는 일
1. Image Build → ECR	애플리케이션 이미지를 만들어 저장
2. Deployment에 ECR 주소 지정	Kubernetes가 어떤 이미지를 사용할지 설정
3. Pod 생성/배치	Kubernetes가 Deployment를 기준으로 Pod를 실행
4. Image Pull	Worker Node가 ECR에서 지정된 이미지를 가져옴
5. Container 실행	가져온 Image로 Container 실행

두 경로는 Deployment의 Image 설정을 통해 연결된다.

3-6. Helm의 역할

Kubernetes 애플리케이션을 배포할 때는 Deployment, Service, Ingress 등 여러 리소스가 필요한데,

Helm을 이용하면

여러 K8s 매니페스트들을 하나의 Chart로 묶어 관리가 가능하다. & EKS가 배포할 수 있다.

예시 :

Helm Chart     
│                                       
├── Deployment               
├── Service                 
└── Ingress

EKS Cluster에 Chart 배포 시 k8s API에 해당 리소스가 적용된다.

[Kubernetes 배포 설정 흐름]

Developer / Admin
       ↓
      Helm
       ↓
      EKS
       ↓
   Deployment
       │
       ├── Service
       └── Ingress

Helm: Kubernetes 리소스의 배포 설정을 묶어 관리하고 EKS에 적용하는 도구

4. 전체 흐름

지금까지의 내용을 하나로 연결하면 다음과 같다.

1. Terraform은 EKS가 동작할 인프라를 구축

[인프라 구성]

Terraform
   ↓
VPC / Subnet / IAM
   ↓
EKS Cluster
   ↓
Worker Node
   └── ECR

2. Ingress를 통해 ALB 구성

[ALB 구성]

Ingress
   ↓
AWS Load Balancer Controller
   ↓
ALB
   ├── Listener
   ├── Rule
   └── Target Group

3. 사용자 요청을 ALB에서 Pod로 전달

[사용자 요청]

User
   ↓
ALB
   ↓
Target Group
   ↓
Pod IP

4. Helm으로 Kubernetes 리소스 배포 및 Pod 실행

[애플리케이션 배포]

Developer
   ├──→ Container Image Build → ECR
   │                              │
   │                              │ Image Pull
   │                              ↓
   │                         Worker Node
   │                              ↓
   │                             Pod
   │                              ↓
   │                          Container
   │
   └──→ Helm → EKS
                  ↓
          Deployment / Service / Ingress

Deployment
↓
ReplicaSet
↓
Pod
↓
kube-scheduler
↓
Worker Node

이 과정을 통해 Terraform으로 인프라를 구성하고, Helm으로 Kubernetes 리소스를 배포한 뒤, Deployment가 Pod를 관리하고, AWS Load Balancer Controller가 구성한 ALB가 Pod IP로 외부 요청을 전달하는 구조가 완성된다.

5. 정리

이번 아키텍처에서 각 구성 요소의 관계를 정리하면 다음과 같다.

구성 요소	핵심 역할
Terraform	AWS 인프라 및 EKS 프로비저닝
AZ	장애 분리 및 가용성 확보
ALB	외부 HTTP/HTTPS 요청 수신
Ingress	라우팅 규칙 정의
AWS Load Balancer Controller	Ingress를 ALB 설정으로 반영
Target Group	ALB가 요청을 전달할 대상 관리
Service	Kubernetes에서 Pod 집합을 연결
Worker Node	Pod 실행
ECR	컨테이너 이미지 저장
Helm	Kubernetes 리소스 배포

핵심 흐름은 세 가지로 나눌 수 있다.

핵심 흐름은 다음과 같이 구분할 수 있다.

[인프라]
Terraform
   ↓
EKS / Worker Node / ECR


[배포]
Helm
   ↓
Deployment / Service / Ingress
   ↓
Pod


[ALB 구성]
Ingress
   ↓
AWS Load Balancer Controller
   ↓
ALB


[사용자 요청]
User
   ↓
ALB
   ↓
Target Group
   ↓
Pod IP


[이미지 실행]
ECR
   ↑
Image Pull
   │
Worker Node
   ↓
Pod
   ↓
Container

AZ 분산은 가용성, Pod 증가는 확장성을 위한 구성이다.
Terraform은 인프라를 프로비저닝하고, Helm은 Kubernetes 리소스를 배포한다. Deployment는 Pod의 실행 상태를 관리하고, Service는 Pod 집합을 연결하며, Ingress는 외부 HTTP/HTTPS 요청의 라우팅 규칙을 정의한다.

그리고 AWS Load Balancer Controller가 Ingress 설정을 실제 ALB 구성으로 연결한다. 현재 구성에서는 ALB의 Target Group이 Pod IP를 대상으로 하므로, 실제 요청은 ALB → Target Group → Pod IP로 전달된다.

참고 자료

AWS EKS: Route application and HTTP traffic with Application Load Balancers

AWS EKS: Load Balancing Best Practices

AWS EKS: AWS Load Balancer Controller

Kubernetes: Deployments

Kubernetes: Services

Kubernetes: EndpointSlices

Kubernetes: Kubernetes Components

Helm: Introduction to Helm

이서진

이전 포스트

[EKS #1] Node, Pod & HPA의 관계와 Auto Scaling

다음 포스트