Apr 2, 2026

Kubernetes Ingress 가이드: 외부 요청이 Service까지 들어오는 흐름

쿠버네티스에서 앱을 외부에 공개하려고 하면 Service까진 이해가 되는데, 그다음 Ingress에서 다시 헷갈리는 경우가 많습니다. Service도 네트워크 리소스인데 왜 Ingress가 또 필요한지 바로 감이 안 오기 때문입니다.

Ingress는 외부에서 들어오는 HTTP 요청을 어떤 Service로 보낼지 정하는 라우팅 규칙입니다. 즉, Service가 Pod 앞단의 연결 단위라면, Ingress는 여러 Service 앞단의 웹 진입점에 가깝습니다.

이 글에서는 아래 내용을 정리합니다.

Ingress가 무엇인지
Service와 어떤 차이가 있는지
host, path 기반 라우팅을 어떻게 이해하면 좋은지

핵심은 Ingress는 Pod에 직접 붙는 리소스가 아니라, 외부 HTTP 트래픽을 Service로 분배하는 규칙 계층이라는 점입니다.

Kubernetes Ingress란 무엇인가

Ingress는 외부에서 들어오는 HTTP 또는 HTTPS 요청을, 조건에 따라 내부 Service로 보내는 규칙을 정의합니다.

예를 들어 아래 같은 요구를 표현할 수 있습니다.

api.example.com 은 api-service 로 보낸다
example.com/admin 은 admin-service 로 보낸다
TLS 인증서를 붙여 HTTPS로 노출한다

즉, Ingress는 여러 웹 경로와 도메인을 Service에 연결하는 라우터처럼 생각하면 이해가 쉽습니다.

Ingress 와 Service 는 어떻게 다를까

둘 다 네트워크와 관련돼 있지만 역할은 다릅니다.

Service: 특정 Pod 집합으로 안정적으로 연결
Ingress: 외부 요청을 어떤 Service로 보낼지 결정

흐름으로 보면 보통 이렇게 됩니다.

Client -> Ingress -> Service -> Pod

그래서 Ingress만 있고 Service가 없는 구조는 보통 자연스럽지 않습니다. Ingress는 대개 Service를 대상으로 삼습니다.

Ingress Controller 가 왜 필요한가

초보자가 자주 놓치는 핵심입니다. Ingress 리소스만 만든다고 바로 트래픽이 흐르지는 않습니다. 실제로 그 규칙을 읽고 동작하는 Ingress Controller가 클러스터 안에 있어야 합니다.

대표적으로 많이 보는 것은:

NGINX Ingress Controller
Traefik
클라우드 제공 ALB/GLB 기반 컨트롤러

즉, Ingress는 “규칙”, Controller는 “그 규칙을 실제로 실행하는 구성 요소”라고 보면 됩니다.

가장 기본적인 Ingress 예시

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

이 설정은 example.com/으로 들어오는 요청을 web-service:80으로 보내겠다는 뜻입니다.

중요한 점은 Ingress가 Pod를 직접 알지 않는다는 것입니다. Ingress는 Service를 보고, Service가 다시 Pod를 봅니다.

host 와 path 라우팅은 어떻게 이해하면 좋을까

Ingress의 장점은 하나의 진입점에서 여러 서비스를 나눌 수 있다는 점입니다.

예를 들어:

api.example.com -> api-service
admin.example.com -> admin-service
example.com/docs -> docs-service

이렇게 도메인이나 경로에 따라 내부 Service를 나눠 연결할 수 있습니다. 그래서 마이크로서비스 구조나 웹/관리자/API 분리가 있을 때 특히 자주 등장합니다.

TLS 는 어디서 붙을까

Ingress는 HTTPS 종료 지점으로도 자주 쓰입니다. 인증서를 Ingress 레벨에 붙여서 외부에서는 HTTPS로 받고, 내부 Service로는 HTTP로 전달하는 구조도 흔합니다.

즉, Ingress는 단순 라우팅뿐 아니라:

TLS termination
host/path rule 관리
여러 Service의 단일 진입점 구성

같은 역할도 함께 담당합니다.

Ingress 없이도 외부 공개가 가능한가

가능합니다. 예를 들어 Service type: LoadBalancer만으로도 외부 노출은 할 수 있습니다.

다만 Ingress를 쓰면:

여러 서비스를 하나의 진입점으로 묶기 쉽고
도메인/경로 라우팅이 가능하고
TLS 구성이 더 일관되며
웹 트래픽 구조를 정리하기 쉽습니다

그래서 HTTP 기반 서비스가 여러 개일수록 Ingress의 가치가 커집니다.

자주 하는 오해

1. Ingress가 있으면 바로 외부 접속이 된다

Ingress Controller가 없거나, 외부 로드밸런서 구성이 안 되어 있으면 규칙만 존재하고 실제 진입점은 동작하지 않을 수 있습니다.

2. Ingress가 Pod로 직접 트래픽을 보낸다

대개는 Service를 경유합니다.

3. 모든 프로토콜에 Ingress를 쓰면 된다

Ingress는 주로 HTTP/HTTPS 라우팅에 적합합니다. TCP/UDP는 다른 구성이 필요할 수 있습니다.

처음 공부할 때 추천하는 실습

web-service 와 api-service 두 개 만들기
path 기반으로 / 와 /api 를 각각 다르게 라우팅하기
host 기반으로 web.local 과 api.local 나누기
Ingress를 지운 뒤 Service만으로 외부 노출 구조와 비교해 보기

이렇게 비교해 보면 Ingress가 “Service의 대체재”가 아니라, 여러 Service를 외부 웹 요청 기준으로 정리해 주는 상위 진입점이라는 점이 잘 보입니다.

FAQ

Q. Ingress와 LoadBalancer 중 무엇을 써야 하나요?

둘 중 하나만 고르는 관계는 아닙니다. 많은 환경에서 Ingress Controller 자체가 외부 LoadBalancer 뒤에 놓입니다.

Q. Ingress가 있는데 404가 나와요. 어디부터 봐야 하나요?

host, path rule, ingress class, backend Service 이름과 포트를 먼저 확인하는 편이 좋습니다.

Q. Service만 있으면 Ingress는 없어도 되나요?

단일 서비스의 간단한 외부 노출은 가능하지만, 여러 웹 서비스나 도메인/경로 라우팅이 필요하면 Ingress가 훨씬 자연스럽습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.