쿠버네티스 Ingress Controller란?｜Ingress와 Controller 역할·구현체 비교

Ingress Controller 구현체

Ingress는 외부에서 유입되는 HTTP/HTTPS 요청을 어떤 Service로 전달할지 정의하는 라우팅 규칙입니다. 앞서 설명드린 것처럼 Ingress 리소스 자체는 실제 네트워크 패킷을 전달하거나 사용자 요청을 처리하는 엔진 역할을 수행하지 않습니다.

따라서 Ingress의 성능과 안정성은 어떤 Ingress Controller 구현체를 선택하느냐에 따라 크게 달라질 수 있습니다. 인프라 환경, 트래픽 규모, 운영 정책, 확장성, 보안 요구사항, 비용 등을 종합적으로 고려하여 서비스에 적합한 구현체를 선택하는 것이 안정적인 Kubernetes 운영의 핵심입니다.

"구현체"는 정확히 무엇을 의미할까?

Kubernetes를 처음 접하는 분들에게는 Ingress Controller의 구현체라는 표현이 다소 어렵게 느껴질 수 있습니다.

쉽게 말하면 Ingress는 다음과 같은 내용을 정의하는 설계도입니다.

- 어떤 Host로 들어온 요청인지
- 어떤 Path로 접근했는지
- 어떤 Service로 전달할 것인지
- 어떤 TLS 인증서를 사용할 것인지

예를 들어 다음과 같은 라우팅 규칙을 정의할 수 있습니다.

example.com/api
   ↓
   api-service

example.com/web
   ↓
     web-service

그러나 Ingress 리소스는 이 규칙을 Kubernetes API에 저장할 뿐, 클라이언트의 연결을 직접 수신하거나 요청을 Service로 전달하지는 않습니다. 즉, Ingress는 다음과 같은 역할만 수행합니다.

외부 요청을 어떤 기준으로 어디에 전달할 것인가?


반대로 다음과 같은 역할은 수행하지 않습니다.

클라이언트 연결 수신
TLS 종료
HTTP 요청 분석
백엔드 선택
트래픽 프록시
로드밸런싱

 

이러한 실제 트래픽 처리 기능을 담당하는 것이 Ingress Controller와 그 구현체입니다.

기존 인프라 환경에서는 WebtoB, NGINX, Apache HTTP Server, IIS와 같은 웹서버 또는 리버스 프록시가 설정과 실행 엔진의 역할을 함께 수행하는 경우가 많습니다.

예를 들어 NGINX에서는 관리자가 다음과 같은 설정을 작성합니다.

location /api {
    proxy_pass http://api-server;
}

그리고 NGINX 프로세스가 이 설정을 읽어 실제 요청을 처리합니다

NGINX 설정 -> NGINX 프로세스 -> 실제 요청 처리

즉, 기존 웹서버 환경에서는 라우팅 규칙과 트래픽 처리 엔진이 하나의 제품 안에 함께 존재합니다.

하지만 Kubernetes의 Ingress는 그렇지 않습니다.

Ingress -> 라우팅 규칙만 정의

Ingress 리소스만 생성한다고 해서 외부 요청이 자동으로 Service에 전달되는 것은 아닙니다. 해당 규칙을 해석하고 실제 네트워크 엔진에 반영할 Ingress Controller 구현체가 반드시 필요합니다.

이 부분이 기존 웹서버 환경에 익숙한 인프라 운영자들이 가장 많이 혼동하는 지점입니다.


Ingress Controller 구현체의 역할

Ingress Controller는 Kubernetes API를 지속적으로 감시하면서 Ingress 리소스의 생성, 변경, 삭제를 확인합니다.

그리고 Ingress에 정의된 라우팅 규칙을 자신이 사용하는 프록시 또는 로드밸런서가 이해할 수 있는 설정으로 변환합니다.

대표적인 구현체 또는 구현 방식은 여러가지가 있습니다

- NGINX 기반 Ingress Controller
- Traefik
- HAProxy 기반 Ingress Controller
- Envoy 기반 구현체
- Kong
- Cilium
- CSP Load Balancer Controller

같은 Ingress YAML을 사용하더라도 어떤 구현체를 선택하느냐에 따라 실제 트래픽 처리 방식은 달라질 수 있습니다.

Ingress Controller의 동작 구조를 가장 쉽게 이해하기 위해, 대표적으로 많이 사용되는 NGINX Ingress Controller를 기준으로 살펴보겠습니다.

NGINX Ingress Controller를 처음 접하면 이름 그대로 하나의 Controller가 모든 기능을 처리한다고 생각하기 쉽습니다. 하지만 실제 동작을 정확히 이해하려면 먼저 Control Plane과 Data Plane을 구분해서 바라봐야 합니다.

Control Plane
Kubernetes의 Ingress 규칙을 감시하고 해석
NGINX가 사용할 설정을 생성하고 반영

Data Plane
→ 외부에서 들어오는 실제 HTTP/HTTPS 요청을 처리
→ TLS 종료, 라우팅, 로드밸런싱 수행

Controller에 장애가 발생하면 새로운 Ingress 규칙이나 Service 변경 사항이 NGINX 설정에 반영되지 않을 수 있습니다. 그러나 기존 NGINX 프로세스와 설정이 정상적으로 유지되고 있다면, 기존 경로의 트래픽은 계속 처리될 수 있습니다.

반대로 NGINX와 같은 Data Plane에 장애가 발생하면 Controller가 정상적으로 Kubernetes API를 감시하고 있더라도 실제 사용자 요청은 처리되지 않습니다.

 

대중적인 Ingress Controller 구현체

Ingress Controller에는 다양한 구현체가 존재하지만, 일반적인 웹 서비스 환경에서는 NGINX, Traefik, HAProxy 계열이 대표적으로 사용됩니다.

이들은 모두 HTTP/HTTPS 요청을 수신하고, Host와 Path를 기준으로 적절한 백엔드에 전달하는 리버스 프록시 기반의 Data Plane을 제공합니다. 따라서 주요 목적이 다음과 같다면 전통적인 리버스 프록시 계열의 구현체만으로도 충분한 경우가 많습니다.

그러나 실제 운영 환경에서 중요한 것은 단순히 “NGINX와 Traefik 중 무엇이 더 좋은가?”를 결정하는 것이 아닙니다.

더 중요한 질문은 다음과 같습니다.

 

외부에서 유입된 트래픽을 어떤 경로와 구조를 통해 안정적으로 최종 Endpoint까지 전달할 것인가?

 

Ingress Controller는 그 경로를 구성하는 하나의 컴포넌트일 뿐입니다. 실제 요청은 외부 Load Balancer, Node 네트워크, Ingress Controller, Service, EndpointSlice, Pod를 거쳐 최종 애플리케이션에 도달합니다.

제품 비교보다 먼저 트래픽 경로를 설계해야 한다

Ingress Controller의 제품별 기능을 비교하는 것도 중요하지만, 인프라 관점에서는 다음과 같은 항목을 먼저 검토해야 합니다.

 

 

외부 트래픽은 어디로 진입하는가?

온프레미스 환경인지, 퍼블릭 클라우드 환경인지에 따라 진입 구조가 달라집니다.

클라우드 환경에서는 일반적으로 관리형 Load Balancer가 클러스터의 Ingress Controller로 트래픽을 전달합니다.

반면 온프레미스 환경에서는 L4 Load Balancer, MetalLB, NodePort 또는 별도의 네트워크 장비를 통해 트래픽이 유입될 수 있습니다.

같은 NGINX Ingress Controller를 사용하더라도 외부 진입 구조에 따라 네트워크 홉, 장애 지점, Source IP 보존 방식, 운영 난이도가 달라질 수 있습니다.

Ingress Controller를 선택할 때 가장 중요한 것은 어떤 제품이 가장 유명한가가 아닙니다. NGINX, Traefik, HAProxy 모두 일반적인 HTTP/HTTPS 라우팅과 TLS 종료를 충분히 수행할 수 있으며, 실제 운영 안정성은 구현체의 이름보다 전체 트래픽 경로를 어떻게 설계하고 운영하느냐에 더 크게 좌우됩니다.

결국 Ingress Controller는 외부 트래픽을 애플리케이션으로 전달하기 위한 하나의 수단입니다.