MMeshOps
쿠버네티스의 현실: 무작정 도입하기 전 알아야 할 컨테이너 오케스트레이션
8예상 10중급

인그레스(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 ServiceIngress
동작 계층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. 1모든 서비스마다 로드밸런서를 생성하면 비용이 급증하므로, 이를 하나로 통합해주는 인그레스(Ingress)가 필요합니다.
  2. 2인그레스는 도메인 이름(Host)과 URL 경로(Path)를 분석하여 알맞은 서비스로 트래픽을 라우팅(L7)합니다.
  3. 3인그레스 규칙을 실제로 실행하고 트래픽을 분산하려면 Nginx 등과 같은 '인그레스 컨트롤러'를 반드시 설치해야 합니다.