인그레스(Ingress): 외부 트래픽을 서버로 길 안내하기
클러스터 외부에서 들어오는 HTTP/HTTPS 트래픽을 도메인 규칙에 따라 알맞은 서비스로 분배하는 인그레스를 알아봅니다.
지난 시간에 배운 'LoadBalancer' 타입의 서비스(Service)를 사용하면 외부 트래픽을 무사히 파드로 연결할 수 있습니다. 하지만 서비스가 수십, 수백 개로 늘어나면 어떻게 될까요? 서비스마다 비싼 클라우드 로드밸런서를 개별적으로 생성하게 되어 비용 폭탄을 맞게 됩니다. 게다가 "example.com/api"는 API 서비스로, "example.com/web"은 웹 서비스로 라우팅하는 스마트한 기능도 지원하지 않죠. 바로 이때 필요한 것이 클러스터의 똑똑한 교통경찰, 인그레스(Ingress)입니다.
클라우드 로드밸런서 비용의 함정
쿠버네티스 환경에서 외부 사용자가 우리 웹서비스에 접속할 수 있도록 길을 열어주는 가장 기초적인 방법은 `LoadBalancer` 타입의 서비스를 생성하는 것입니다.
하지만 대규모 마이크로서비스 아키텍처(MSA)에서는 회원가입 서비스, 결제 서비스, 리뷰 서비스 등 목적에 따라 서비스가 잘게 쪼개져 있습니다. 이 각각의 서비스마다 `LoadBalancer`를 생성한다면 클라우드 벤더(AWS, GCP 등)는 서비스 개수만큼 로드밸런서를 새롭게 프로비저닝합니다. 로드밸런서는 한 달에 수만 원씩 비용이 청구되는 비싼 인프라 자원입니다. 서비스가 50개라면 로드밸런서 비용으로만 엄청난 지출이 발생하게 됩니다.
또한, `LoadBalancer` 서비스 계층인 L4(전송 계층)에서는 HTTP 도메인이나 URL 경로(Path)를 분석하여 트래픽을 쪼개줄 수 있는 기능이 빈약합니다. URL에 따른 유연한 분배가 불가능하다는 것이죠.
하나의 진입점으로 모든 것을 해결하다
이런 비효율을 해결하기 위해 쿠버네티스는 인그레스(Ingress)를 도입했습니다.
인그레스는 클러스터 외부에서 들어오는 HTTP 및 HTTPS 트래픽을 클러스터 내부의 알맞은 서비스들로 전달하는 규칙(Routing Rule)의 모음입니다. 쉽게 말해 단 하나의 강력한 로드밸런서를 앞단에 세우고, 이 로드밸런서가 트래픽의 도메인 이름과 경로를 꼼꼼히 검사하여 알아서 각 서비스로 길 안내를 해주는 방식입니다.
LoadBalancer 서비스 vs 인그레스(Ingress)
| 항목 | LoadBalancer Service | Ingress |
|---|---|---|
| 동작 계층 | L4 (IP, 포트 기반) | L7 (HTTP/HTTPS 도메인 및 경로 기반) |
| 외부 진입점 개수 | 각 서비스마다 개별 IP 부여 | 단일 진입점(IP)으로 여러 서비스 통합 |
| 비용 효율성 | 서비스가 늘어날수록 급증 | 하나의 로드밸런서로 처리하여 저렴함 |
| SSL 인증서 적용 | 각 서비스마다 개별 처리 필요 | 인그레스단에서 통합 관리(TLS Termination) 용이 |
인그레스의 똑똑한 라우팅 규칙
인그레스를 구성하면 하나의 도메인 이름(`www.my-shop.com`) 아래에 여러 개의 마이크로서비스를 우아하게 연결할 수 있습니다. HTTP 요청의 URL 경로(Path)를 분석하여 마치 교통경찰처럼 트래픽의 방향을 지정해 줍니다.
경로(Path) 기반 라우팅
예를 들어 쇼핑몰을 운영한다고 할 때, 인그레스 설정(YAML)에 다음과 같은 규칙을 정의할 수 있습니다.
- 사용자가 `my-shop.com/api` 로 접속하면 -> `api-service`로 전달
- 사용자가 `my-shop.com/payment` 로 접속하면 -> `payment-service`로 전달
- 그 외 `my-shop.com/` 의 모든 일반 접속은 -> `frontend-service`로 전달
사용자는 단순히 하나의 쇼핑몰 도메인에 접속하는 것처럼 느끼지만, 뒤에서는 인그레스가 각각의 특화된 마이크로서비스로 트래픽을 정교하게 쪼개주는 것입니다.
인그레스 라우팅 매니페스트 (YAML)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: shop-ingress
spec:
rules:
- host: my-shop.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80인그레스와 인그레스 컨트롤러의 관계
쿠버네티스를 처음 접하는 분들이 가장 많이 헷갈리는 부분이 인그레스와 인그레스 컨트롤러(Ingress Controller)의 차이입니다.
우리가 위에서 살펴본 `Ingress` YAML 파일은 단지 "이렇게 길 안내를 해달라"고 적어둔 이정표(규칙서)에 불과합니다. 실제로 이 이정표를 읽고 앞장서서 교통정리를 수행하는 경찰관 역할은 '인그레스 컨트롤러'가 담당합니다.
쿠버네티스 클러스터를 설치한다고 해서 기본적으로 인그레스 컨트롤러가 포함되어 있지는 않습니다. 사용자가 Nginx Ingress Controller, ALB Ingress Controller, Traefik 등 다양한 컨트롤러 중에서 마음에 드는 것을 선택하여 별도로 설치해야 비로소 인그레스 규칙들이 제대로 작동하기 시작합니다.
인그레스 시스템의 핵심 요소
- 인그레스 (Ingress)
- 어떤 도메인과 경로를 어떤 서비스로 보낼지 정의한 규칙 (설계도)
- 인그레스 컨트롤러 (Ingress Controller)
- 규칙을 읽고 실제로 외부 트래픽을 받아 라우팅을 수행하는 실체 (엔진)
개념 퀴즈
퀴즈 답을 맞춰야 학습 완료가 됩니다.다음 중 인그레스(Ingress)를 도입하는 가장 주요한 목적은 무엇인가요?
3줄 요약
- 1모든 서비스마다 로드밸런서를 생성하면 비용이 급증하므로, 이를 하나로 통합해주는 인그레스(Ingress)가 필요합니다.
- 2인그레스는 도메인 이름(Host)과 URL 경로(Path)를 분석하여 알맞은 서비스로 트래픽을 라우팅(L7)합니다.
- 3인그레스 규칙을 실제로 실행하고 트래픽을 분산하려면 Nginx 등과 같은 '인그레스 컨트롤러'를 반드시 설치해야 합니다.