94. 인그레스 (Ingress) - 단일 외부 진입점과 L7 라우팅 게이트웨이

⚠️ 이 문서는 마이크로서비스(MSA) 환경에서 50개의 API 서비스(주문, 결제 등)를 밖으로 노출하기 위해 무식하게 비싼 AWS 로드밸런서(LoadBalancer) 기계를 50대나 사야 했던 피눈물 나는 비용 낭비를 종식하기 위해 탄생한, **클러스터 앞단에 정문(LoadBalancer)을 딱 1개만 두고, 그 내부에서 똑똑한 가상 라우터(Nginx 등)가 사용자가 친 URL 경로(예: /order, /pay)나 도메인 이름에 따라 트래픽을 각 서비스로 쪼개어 배달해 주는 L7(응용 계층) 통합 게이트웨이인 '인그레스(Ingress)'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 그 자체로는 서비스(Service) 타겟이 아니라, 쿠버네티스의 여러 서비스(ClusterIP들)를 밖에서 찌를 수 있게 하나로 모아주는 거대한 **'라우팅 규칙(이정표)의 집합소'**이자 스위치 보드다.
  2. 가치: LoadBalancer 타입 서비스 50개를 만들면 AWS에 월 수백만 원의 유지비가 깨진다. Ingress를 쓰면 싸구려 AWS 로드밸런서 1대만 달아놓고 그 뒤에서 수백 개의 서비스를 공짜로 URL 별로 쪼개주어 클라우드 인프라 비용을 극적으로 1/50로 깎아버린다.
  3. 기술 체계: 단순히 Ingress 규칙(yaml)만 적는다고 돌아가지 않으며, 그 텍스트 규칙을 읽고 실제로 트래픽을 나눠주는 엔진인 **인그레스 컨트롤러(Ingress Controller, 주로 Nginx Ingress)**를 반드시 클러스터에 띄워 놔야 찰떡처럼 작동한다.

Ⅰ. LoadBalancer의 파산 딜레마와 L4의 무식함

로드밸런서를 서비스마다 사면 회사는 망한다. 게다가 멍청하기까지 하다.

  1. 비용의 폭주 (1 Service = 1 LB):
    • 쇼핑몰 백엔드를 MSA로 쪼갰더니 파드 그룹이 10개가 나왔다. (주문, 결제, 회원, 장바구니 등)
    • 이 10개를 모바일 앱(외부)과 연동하려고 전부 type: LoadBalancer 서비스로 배포했다. AWS에 비싼 로드밸런서(ELB) 기계가 실제로 10대가 생성되고 IP가 10개가 나와버렸다.
  2. L4 장비의 한계 (경로 라우팅 불가):
    • 이 싸구려 L4 로드밸런서는 오직 'IP 주소'와 '포트 번호(80)'만 보고 짐을 던진다.
    • 고객이 www.shop.com/order 라고 치든 www.shop.com/pay 라고 치든, L4 로드밸런서는 그 주소 뒤에 붙은 단어(/order)를 읽을 줄 아는 지능(L7 계층 이해력)이 없다.

📢 섹션 요약 비유: 쇼핑몰 입점 상가 10곳 사장님이 밖에서 손님을 바로 받겠다며, 각자 자기 매장 전용 에스컬레이터와 출입문(LoadBalancer)을 10개나 뚫어달라고 진상을 부려 건축비가 탕진된 상황입니다. 설상가상으로 그 문 앞의 무식한 경호원(L4 장비)은 손님이 "결제 매장 가려는데요?"라고 말해도(URL), 그걸 못 알아듣고 아무 문으로나 손님을 쑤셔 넣는 바보 같은 짓을 하고 있습니다.

Ⅱ. 똑똑한 L7 로비 안내데스크: Ingress의 등장

문은 하나만 뚫고, 안에 똑똑한 안내양을 배치해라.

  1. 단일 진입점(Single Point of Entry)의 완성:
    • 아키텍처를 뒤엎는다. 외부와 닿는 진짜 AWS LoadBalancer는 단 1개만 만든다. 그리고 이 1개의 로드밸런서 뒤에 **'인그레스 컨트롤러(Ingress Controller)'**라는 Nginx 웹 서버 파드를 세워둔다.
    • 외부 트래픽은 모두 이 Nginx 파드(안내데스크) 1곳으로 몰려 들어온다.
  2. L7 라우팅 규칙의 적용 (Path & Host Routing):
    • 개발자는 Ingress yaml 파일(이정표)을 작성해 쿠버네티스에 던진다.
      • 룰 1: 호스트가 api.shop.com이고 경로가 /order로 들어오면 $\rightarrow$ 내부 order-clusterip 서비스로 보내라.
      • 룰 2: 호스트가 api.shop.com이고 경로가 /pay로 들어오면 $\rightarrow$ 내부 pay-clusterip 서비스로 보내라.
    • 똑똑한 인그레스 컨트롤러(Nginx)는 L7 계층(HTTP)의 텍스트를 읽을 수 있으므로, 들어온 손님의 URL 주소를 쓱 보고 정확히 목적지인 백엔드 내선 번호(ClusterIP)로 트래픽을 완벽하게 쪼개서 넘겨준다.
  3. SSL/TLS 암호화(HTTPS) 종료 (SSL Termination):
    • 각 10개의 서비스 파드에 일일이 인증서를 달아 HTTPS 암호화를 풀게 하면 CPU가 남아나지 않는다.
    • 인그레스 문지기가 앞에서 HTTPS 암호를 한 번에 다 풀어버리고(Termination), 내부에 있는 파드들에게는 가벼운 평문(HTTP)으로 쏴주는 효율적인 역할까지 전담한다.

📢 섹션 요약 비유: 10개의 출입문을 다 막아버리고, 으리으리한 중앙 정문(단일 LoadBalancer) 딱 1개만 남겼습니다. 정문으로 들어오면 1층 로비에 눈치 빠른 안내데스크 직원(인그레스 컨트롤러)이 앉아있습니다. 손님이 "결제(/pay)하러 왔어요"라고 말하면, 안내 직원이 "아, 결제는 3층 2번 방(ClusterIP)으로 가시면 됩니다!"라며 이정표(Ingress 룰)를 보고 정확하게 엘리베이터에 태워 보내는 초고효율 중앙 안내 시스템입니다.

Ⅲ. Ingress와 Ingress Controller의 이분법 (주의점)

룰(규칙)을 썼다고 해서 룰을 집행할 경찰이 자동으로 생기진 않는다.

  1. Ingress (규칙 명세서):
    • kind: Ingress 로 만드는 쿠버네티스 객체는 단순히 트래픽을 어떻게 쪼갤지 적어놓은 텍스트 종이 쪼가리(규칙 모음)일 뿐이다. 이 종이만 던진다고 라우팅이 되지 않는다.
  2. Ingress Controller (실행 엔진):
    • 이 종이에 적힌 규칙을 읽어 들이고 24시간 내내 그 규칙대로 진짜 트래픽 패킷을 물리적으로 분류해 주는 **웹 서버 엔진(실행자)**이 필요하다.
    • K8s는 이 엔진을 기본으로 제공하지 않는다. 우리가 직접 Nginx, HAProxy, Traefik 등을 기반으로 한 nginx-ingress-controller 파드를 클러스터에 설치해 주어야만 비로소 인그레스 생태계가 작동한다. (최근에는 클라우드 네이티브 환경에 맞춰 더 진보된 API Gateway인 Gateway API 규격으로 세대교체가 일어나고 있다.)

📢 섹션 요약 비유: Ingress 객체는 국회에서 통과시킨 "음주 운전하면 벌금 천만 원"이라는 법률 조문(종이 규칙)에 불과합니다. 이 법률이 있다고 알아서 범죄가 줄어들지 않습니다. 반드시 이 법률 책을 읽고 길거리에서 음주 단속을 물리적으로 수행할 경찰관(Ingress Controller 파드)을 국가가 직접 채용하고 도로에 배치해야만 비로소 교통(트래픽) 통제가 제대로 돌아가는 이치입니다.