개발 창고/Server

쿠버네티스 인그레스(Ingress): 완벽 가이드 (NGINX 예제 포함)

Royzero 2025. 9. 23. 23:17
반응형

설명: 쿠버네티스 인그레스(Ingress)의 개념, 작동 방식, 그리고 NGINX 인그레스 컨트롤러를 사용한 실용적인 예제를 통해 외부 트래픽을 클러스터 내부 서비스로 라우팅하는 방법을 심층적으로 알아봅니다. 실무자를 위한 핵심 가이드입니다.

 

TL;DR: 쿠버네티스 인그레스(Ingress)는 클러스터 외부의 HTTP 및 HTTPS 트래픽을 클러스터 내부 서비스(Service)로 연결하는 규칙의 집합을 정의하는 API 객체입니다. 인그레스는 L7 로드 밸런서 역할을 수행하며, URL 경로 및 호스트 이름 기반 라우팅, SSL/TLS 종료, 가상 호스팅 등의 고급 기능을 제공합니다. 인그레스 리소스가 실제로 동작하려면 NGINX, Istio, Traefik과 같은 인그레스 컨트롤러가 반드시 필요합니다. 이는 외부 트래픽 관리의 복잡성을 크게 줄여주고 단일 IP 주소로 여러 서비스를 노출할 수 있게 해주는 효율적인 방법입니다.

1. 쿠버네티스 인그레스(Ingress)란 무엇인가?

쿠버네티스 환경에서 컨테이너화된 애플리케이션을 운영할 때, 외부 사용자가 이 애플리케이션에 접근하게 만드는 방법은 매우 중요합니다. 쿠버네티스는 NodePort, LoadBalancer, 그리고 Ingress라는 세 가지 주요 방법을 제공합니다. 이 중 인그레스(Ingress)는 클러스터 외부에서 내부 서비스로 들어오는 HTTP(S) 트래픽을 관리하기 위한 가장 강력하고 유연한 솔루션입니다.

인그레스는 그 자체로 트래픽을 처리하는 구성 요소가 아니라, 어떤 트래픽이 어떤 서비스로 전달되어야 하는지에 대한 라우팅 규칙(Routing Rule)의 집합입니다. 이 규칙을 실제로 읽고 처리하여 트래픽을 포워딩하는 역할을 하는 것이 바로 인그레스 컨트롤러(Ingress Controller)입니다.

주요 기능은 다음과 같습니다.

  • 호스트 및 경로 기반 라우팅: example.com/api는 api-service로, store.example.com은 store-service로 전달하는 등 URL 기반의 정교한 라우팅이 가능합니다.
  • SSL/TLS 종료: 인그레스에서 직접 SSL/TLS 인증서를 처리하여, 클러스터 내부 서비스들은 암호화 부담 없이 HTTP로 통신할 수 있습니다.
  • 로드 밸런싱: 여러 파드(Pod)에 걸쳐 있는 서비스로 트래픽을 분산합니다.
  • 가상 호스팅: 단일 IP 주소를 사용하여 여러 도메인 이름을 호스팅할 수 있습니다.

networking.k8s.io/v1 API 버전은 쿠버네티스 v1.19부터 안정(Stable) 버전으로 제공되고 있으며, 이전의 베타 버전(extensions/v1beta1, networking.k8s.io/v1beta1)은 쿠버네티스 v1.22에서 공식적으로 제거되었습니다.

 

Why it matters: NodePort나 LoadBalancer 서비스 타입은 L4(TCP/UDP) 수준에서 작동하며, 서비스를 노출할 때마다 별도의 포트나 외부 IP가 필요해 비용과 관리 복잡성이 증가할 수 있습니다. 인그레스는 L7(HTTP/S) 수준에서 작동하여 단일 진입점(Entrypoint)과 IP 주소로 수많은 서비스를 효율적으로 관리할 수 있게 해줍니다.

2. 인그레스 컨트롤러(Ingress Controller)의 역할

앞서 언급했듯이, 인그레스 리소스는 규칙의 명세일 뿐입니다. 이 규칙을 실제로 구현하고 트래픽을 라우팅하는 소프트웨어가 인그레스 컨트롤러입니다. 인그레스 컨트롤러는 일반적으로 클러스터 내에서 파드 형태로 실행되는 리버스 프록시 서버(예: NGINX, HAProxy)입니다.

인그레스 컨트롤러는 쿠버네티스 API 서버를 주시(Watch)하다가 인그레스, 서비스, 엔드포인트(Endpoint) 리소스에 변경이 생기면, 이를 동적으로 자신의 프록시 설정에 반영하고 리로드합니다.

다양한 인그레스 컨트롤러: 쿠버네티스 프로젝트는 공식적으로 GCE와 NGINX 컨트롤러를 지원 및 유지보수합니다. 그 외에도 널리 사용되는 서드파티 컨트롤러는 다음과 같습니다.

  • ingress-nginx: 커뮤니티에서 가장 널리 사용되는 컨트롤러 중 하나입니다.
  • Traefik: 설정이 간편하고 동적 구성에 강점이 있습니다.
  • Kong: API 게이트웨이 기능을 통합한 강력한 컨트롤러입니다.
  • Istio Ingress Gateway: 서비스 메쉬인 Istio의 일부로, 더 복잡한 트래픽 관리 및 보안 기능을 제공합니다.
  • 클라우드 제공사 컨트롤러: AWS(ALB Ingress Controller), Azure(Application Gateway Ingress Controller) 등 각 클라우드 환경에 최적화된 컨트롤러도 있습니다.

Why it matters: 어떤 인그레스 컨트롤러를 선택하느냐에 따라 사용할 수 있는 기능(예: 인증, 속도 제한 등)과 성능이 달라집니다. 따라서 프로젝트의 요구사항과 운영 환경에 맞는 컨트롤러를 신중하게 선택하는 것이 중요합니다.

3. NGINX 인그레스 컨트롤러를 이용한 실습

개념을 이해하는 가장 좋은 방법은 직접 구성해보는 것입니다. 가장 대중적인 ingress-nginx 컨트롤러를 사용하여 외부 요청을 두 개의 다른 내부 서비스로 라우팅하는 예제를 살펴보겠습니다.

3.1. NGINX 인그레스 컨트롤러 설치

먼저, 클러스터에 ingress-nginx 컨트롤러를 배포해야 합니다. 보통 공식 YAML 파일을 직접 적용하는 방식을 사용합니다.

Bash
 
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.6/deploy/static/provider/cloud/deploy.yaml

(참고: 2025-09-23 기준, v1.9.6이 최신 버전 중 하나입니다. 사용 시점의 최신 버전을 확인하는 것이 좋습니다.)

설치가 완료되면 ingress-nginx 네임스페이스에 컨트롤러 파드와 LoadBalancer 타입의 서비스가 생성된 것을 확인할 수 있습니다. 이 서비스의 외부 IP 주소(EXTERNAL-IP)가 모든 트래픽의 진입점이 됩니다.

Bash
 
kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

3.2. 샘플 애플리케이션 및 서비스 배포

라우팅을 테스트하기 위해 두 개의 간단한 웹 애플리케이션(apple-app, banana-app)과 각각을 노출하는 ClusterIP 타입의 서비스를 배포합니다.

YAML
 
# sample-apps.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apple-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: apple
  template:
    metadata:
      labels:
        app: apple
    spec:
      containers:
      - name: apple-container
        image: hashicorp/http-echo
        args:
        - "-text=This is the APPLE service"
---
apiVersion: v1
kind: Service
metadata:
  name: apple-service
spec:
  selector:
    app: apple
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5678 # http-echo's default port
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: banana-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: banana
  template:
    metadata:
      labels:
        app: banana
    spec:
      containers:
      - name: banana-container
        image: hashicorp/http-echo
        args:
        - "-text=This is the BANANA service"
---
apiVersion: v1
kind: Service
metadata:
  name: banana-service
spec:
  selector:
    app: banana
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5678

kubectl apply -f sample-apps.yaml 명령어로 위 리소스를 생성합니다.

3.3. 인그레스 리소스 생성 (경로 기반 라우팅)

이제 인그레스 리소스를 정의하여 /apple 경로로 들어오는 요청은 apple-service로, /banana 경로로 들어오는 요청은 banana-service로 라우팅하도록 규칙을 만듭니다.

YAML
 
# path-based-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /apple
        pathType: Prefix
        backend:
          service:
            name: apple-service
            port:
              number: 80
      - path: /banana
        pathType: Prefix
        backend:
          service:
            name: banana-service
            port:
              number: 80
  • ingressClassName: nginx: 이 인그레스 규칙을 nginx 인그레스 컨트롤러가 처리하도록 지정합니다.
  • annotations: 컨트롤러의 동작을 세부적으로 조정하는 데 사용됩니다. rewrite-target: /은 /apple 요청을 백엔드 서비스의 /로 전달해줍니다.

kubectl apply -f path-based-ingress.yaml 명령어로 인그레스를 생성합니다.

이제 인그레스 컨트롤러의 외부 IP 주소로 접속을 테스트해봅니다.

Bash
 
# ${EXTERNAL_IP}는 `kubectl get svc -n ingress-nginx`로 확인한 주소
curl http://${EXTERNAL_IP}/apple
# 출력: This is the APPLE service

curl http://${EXTERNAL_IP}/banana
# 출력: This is the BANANA service

Why it matters: 이 예제는 인그레스의 가장 기본적인 활용법을 보여줍니다. 단 하나의 외부 IP 주소와 표준 HTTP 포트(80)를 사용하여, URL 경로에 따라 완전히 다른 두 애플리케이션으로 트래픽을 분기시키는 강력함을 확인할 수 있습니다.

4. 인그레스의 미래: 게이트웨이 API (Gateway API)

인그레스는 매우 유용하지만, 몇 가지 한계점을 가지고 있습니다. 예를 들어, 표준 기능이 제한적이어서 대부분의 고급 기능은 특정 컨트롤러의 annotation에 의존하며, 이는 이식성을 떨어뜨립니다. 또한, 인프라 관리자와 애플리케이션 개발자 간의 역할 분리가 모호합니다.

이러한 문제를 해결하기 위해 게이트웨이 API(Gateway API)가 등장했습니다. 게이트웨이 API는 쿠버네티스 네트워킹의 차세대 표준을 목표로 하며, 다음과 같은 특징을 가집니다.

  • 역할 기반 설계: GatewayClass, Gateway, HTTPRoute 등 역할을 분리한 리소스를 통해 인프라팀과 개발팀의 책임을 명확히 나눕니다.
  • 표현력과 확장성: 트래픽 분할, 헤더 기반 라우팅, TCP/UDP 라우팅 등 더 많은 기능을 표준 사양에 포함합니다.
  • 이식성: 벤더 종속적인 annotation 대신 표준화된 필드를 사용하여 여러 구현체에서 일관된 동작을 보장합니다.

게이트웨이 API는 인그레스를 대체하는 것을 목표로 하는 차세대 기술이며, 많은 인그레스 컨트롤러들이 이미 게이트웨이 API 구현을 지원하고 있습니다.

 

Why it matters: 현재는 인그레스가 널리 쓰이지만, 앞으로의 쿠버네티스 네트워킹 환경은 게이트웨이 API 중심으로 전환될 가능성이 높습니다. 새로운 프로젝트를 시작하거나 복잡한 라우팅 요구사항이 있다면 게이트웨이 API를 고려해볼 가치가 있습니다.

결론

쿠버네티스 인그레스는 외부 트래픽을 클러스터 내부로 효율적으로 라우팅하는 핵심 구성 요소입니다. L7 라우팅, SSL 종료, 가상 호스팅과 같은 기능을 제공하여 복잡한 마이크로서비스 아키텍처의 트래픽 관리를 단순화합니다. NGINX와 같은 인그레스 컨트롤러와 함께 사용할 때 그 강력함이 발휘되며, 단일 IP로 여러 서비스를 관리할 수 있어 비용 효율적입니다. 기술의 발전과 함께 등장한 게이트웨이 API가 인그레스의 자리를 점차 대체할 것으로 보이지만, 현재로서는 인그레스가 여전히 가장 보편적이고 안정적인 솔루션입니다.

 

References:

반응형
저작자표시 비영리 변경금지 (새창열림)

'개발 창고 > Server' 카테고리의 다른 글

docker build 명령어 완벽 가이드: Dockerfile로 이미지 만들기  (3) 2025.09.29
도커(Docker)란 무엇인가: 컨테이너 가상화 기술 완벽 입문  (1) 2025.09.27
쿠버네티스 노드포트(NodePort)란? 개념, 동작 방식 및 사용 사례 완벽 분석  (1) 2025.09.21
쿠버네티스 동적 프로비저닝(Dynamic Provisioning) 쉽게 이해하기  (0) 2025.09.20
쿠버네티스 레이블(Labels) 완벽 가이드: 개념부터 실전 베스트 프랙티스까지  (1) 2025.09.19

'개발 창고/Server'의 다른글

  • 현재글쿠버네티스 인그레스(Ingress): 완벽 가이드 (NGINX 예제 포함)

관련글

티스토리툴바