[IT-정보] 인그레스 개념과 동작 원리 핵심 가이드 – 실무 데이터 파이프라인 운영자를 위한 쿠버네티스 입문서

인그레스 관련 쿠버네티스 구조를 설명하는 대표 이미지

왜 지금 인그레스(Ingress)를 제대로 알아야 할까요

데이터 파이프라인을 운영하다 보면 여러 개의 서비스가 동시에 돌아가는 환경을 마주하게 돼요. 처음에는 간단하게 NodePortLoadBalancer를 사용해서 서비스를 외부로 노출하는 것으로 충분하다고 느꼈을 거예요. 하지만 서비스 개수가 늘어날수록 클라우드 비용은 기하급수적으로 상승하고, 외부에서 접속할 때 사용하는 주소는 관리하기 힘들 정도로 복잡해지는 문제를 겪게 됩니다.

예를 들어, 메타베이스(Metabase) 대시보드와 스파크(Spark) UI, 그리고 데이터 수집 API를 각각 별도의 로드밸런서로 노출하고 있다고 상상해 보세요. 클라우드 제공업체에 지불해야 하는 비용은 서비스 개수만큼 배로 늘어나고, 보안 그룹이나 방화벽 규칙을 관리하는 작업은 점점 더 고통스러워질 거예요. 이런 상황에서 등장하는 해결책이 바로 인그레스(Ingress)입니다.

인그레스는 단순히 외부 트래픽을 전달하는 통로를 넘어, 하나의 외부 IP 주소만 사용하여 수많은 서비스로 트래픽을 똑똑하게 분배해 주는 스마트한 관문 역할을 수행해요. 이 개념을 제대로 이해하고 활용하면 클러스터의 네트워크 구조를 단순화할 수 있고, 운영 비용을 획기적으로 절감할 수 있습니다.

이 글에서는 데이터 엔지니어가 실무에서 바로 적용할 수 있도록 인그레스의 핵심 개념부터 동작 원리, 그리고 실제 설정 방법까지 차근차근 설명해 드릴게요. 글을 모두 읽고 나면 다음과 같은 내용을 확실히 알게 될 거예요.

  • 인그레스가 기존 서비스 노출 방식과 어떻게 다른지
  • 인그레스 컨트롤러와 리소스의 상관관계
  • 경로(Path)와 호스트(Host) 기반의 라우팅 구현 방법
  • 실무에서 자주 발생하는 설정 오류와 해결책

인그레스 설정을 위한 사전 지식과 준비물

인그레스를 본격적으로 다루기 전에 반드시 짚고 넘어가야 할 기초 지식들이 있어요. 인그레스는 단독으로 작동하는 것이 아니라, 쿠버네티스의 다른 구성 요소들과 긴밀하게 협력하기 때문이에요. 먼저 Service 객체에 대한 이해가 선행되어야 합니다. 인그레스는 트래픽을 어디로 보낼지 결정할 때 결국 서비스의 이름을 참조하게 되거든요.

또한, 인그레스는 7계층(L7, Application Layer)에서 동작한다는 점을 기억해야 해요. 이는 HTTP 헤더, URL 경로, 호스트 이름 등을 분석해서 트래픽을 제어할 수 있다는 뜻이에요. 만약 단순한 TCP/UDP 트래픽 제어가 목적이라면 인그레스보다는 다른 방식이 더 적합할 수 있습니다. 따라서 자신의 데이터 파이프라인이 어떤 프로토콜을 사용하는지 먼저 확인하는 과정이 필요해요.

💡 알아두기
인그레스는 ‘규칙’을 정의하는 리소스일 뿐이며, 실제 그 규칙을 실행하여 트래픽을 전달하는 엔진은 인그레스 컨트롤러(Ingress Controller)라는 별도의 구성 요소가 담당한다는 사실을 잊지 마세요.

서비스 노출 방식을 선택할 때는 비용, 관리의 편의성, 그리고 보안 요구사항을 기준으로 결정해야 합니다. 아래 표를 통해 각 방식의 특징을 비교해 드릴게요.

노출 방식 주요 특징 장점 단점
NodePort 모든 노드의 특정 포트를 개방 설정이 매우 간단함 포트 관리의 어려움, 보안 취약
LoadBalancer 클라우드 제공자의 LB 생성 안정적이고 관리가 쉬움 서비스마다 비용 발생 (고비용)
Ingress L7 계층 기반의 경로 라우팅 비용 절감, 도메인 기반 제어 컨트롤러 별도 설치 필요

결론적으로, 운영해야 할 서비스가 많아지고 도메인 기반의 체계적인 관리가 필요하다면 인그레스를 도입하는 것이 가장 현명한 선택이에요. 본격적인 실습에 들어가기 전에, 사용할 인그레스 컨트롤러(예: Nginx Ingress Controller)가 클러스터에 설치되어 있는지 확인해 보세요.

인그레스 핵심 구성 요소와 단계별 설정 가이드

인그레스 시스템을 구축하고 운영하기 위해서는 단순히 YAML 파일 하나를 작성하는 것 이상의 과정이 필요해요. 전체적인 흐름을 이해하기 위해 크게 5가지 단계로 나누어 살펴보겠습니다. 각 단계는 실제 인프라 구축 과정과 유사하게 구성되어 있어요.

STEP 1. 인그레스 컨트롤러(Ingress Controller) 설치하기

인그레스 리소스는 일종의 ‘설계도’일 뿐이에요. 이 설계도를 보고 실제로 트래픽을 길을 찾아주는 ‘일꾼’이 필요한데, 그것이 바로 인그레스 컨트롤러입니다. 가장 대중적으로 사용되는 것은 Nginx Ingress Controller예요. 이를 설치하기 위해서는 보통 Helm(헬름)이라는 패키지 매니저를 사용합니다.

설치 명령어는 보통 다음과 같은 흐름으로 진행돼요. 먼저 헬름 저장소를 추가하고, 컨트롤러를 설치합니다. 이 과정은 네트워크 환경에 따라 약 2~5분 정도 소요되며, 설치가 완료되면 클러스터 외부에 공인 IP를 가진 서비스가 하나 생성되는 것을 확인할 수 있어요. 이 IP가 바로 외부 사용자가 우리 클러스터로 들어오는 유일한 입구가 됩니다.

STEP 2. 인그레스 리소스(Ingress Resource) 정의하기

컨트롤러가 준비되었다면, 이제 우리가 원하는 라우팅 규칙을 담은 리소스를 작성해야 해요. 인그레스 리소스는 YAML 형식으로 작성하며, apiVersion: networking.k8s.io/v1을 사용합니다. 리소스에는 어떤 호스트(Host)로 들어오는지, 어떤 경로(Path)로 들어오는지, 그리고 그 트래픽을 어떤 서비스(Service)의 포트로 보낼지가 명시되어야 합니다.

예를 들어, 사용자가 api.example.com으로 접속했을 때 data-api-service로 연결하고 싶다면, 해당 호스트와 경로를 정확히 매핑해 주어야 해요. 이때 주의할 점은 리소스의 metadata.name이 중복되지 않도록 관리하는 것입니다.

STEP 3. 경로 기반(Path-based) 라우팅 구현하기

경로 기반 라우팅은 하나의 도메인 뒤에 붙는 경로에 따라 서로 다른 서비스로 연결하는 방식이에요. 데이터 엔지니어링 환경에서는 매우 유용하게 쓰이죠. 예를 들어, example.com/metrics로 접속하면 프로메테우스(Prometheus) 대시보드로, example.com/logs로 접속하면 로그 분석 서비스로 보내는 식입니다.

이 설정을 할 때는 경로의 일치 방식(ImplementationSpecific, Prefix, Exact)을 신중하게 결정해야 해요. Prefix 방식을 사용하면 지정한 경로로 시작하는 모든 하위 경로를 포함하므로 가장 일반적으로 사용됩니다. 만약 정확히 그 경로만 허용하고 싶다면 Exact 방식을 선택하세요. 잘못된 경로 설정은 404 에러의 주된 원인이 됩니다.

STEP 4. 호스트 기반(Host-based) 라우팅 설정하기

호스트 기반 라우팅은 도메인 주소 자체를 구분하는 방식이에요. app1.example.comapp2.example.com을 서로 다른 서비스로 연결할 수 있습니다. 이는 마치 하나의 아파트 단지(클러스터)에 여러 개의 독립된 집(서비스)이 있는 것과 같죠. 각 집은 서로 다른 문(도메인)을 통해 손님을 맞이하게 됩니다.

이 방식을 사용하려면 DNS 설정이 선행되어야 해요. 사용자가 입력하는 도메인이 클러스터의 인그레스 컨트롤러 IP를 가리키도록 A 레코드를 등록해야 합니다. 실무에서는 이 단계에서 도메인 관리 시스템(Route53 등)과 쿠버네티스 환경을 연동하는 작업이 매우 중요하게 다뤄집니다.

STEP 5. TLS/SSL 인증서 적용하여 보안 강화하기

데이터 파이프라인을 다루는 환경에서 보안은 타협할 수 없는 요소예요. 모든 트래픽을 HTTPS로 암호화하기 위해 인그레스에 TLS 설정을 추가해야 합니다. 이를 위해 쿠버네티스 내부에 Secret 객체로 인증서(Certificate)와 키(Key)를 저장해 두어야 해요.

인그레스 리소스의 spec.tls 섹션에 해당 시크릿 이름을 명시하면, 인그레스 컨트롤러가 자동으로 SSL 핸드셰이크를 처리합니다. 이렇게 하면 개별 서비스들이 직접 인증서를 관리할 필요가 없어지므로 운영 부담이 획기적으로 줄어들어요.

💡 알아두기
실무에서는 Cert-manager라는 도구를 함께 사용하는 경우가 많아요. 이를 활용하면 Let’s Encrypt 같은 공인 인증서를 자동으로 발급받고 갱신할 수 있어 인증서 만료 사고를 미연에 방지할 수 있습니다.

이 모든 과정이 완료되면, 여러분은 단 하나의 IP를 통해 안전하고 효율적으로 수많은 데이터 도구들을 외부로 노출할 수 있게 됩니다. 아래는 실제 적용할 수 있는 통합 시나리오 예시입니다.

  • 시나리오: 데이터 플랫폼 운영
  • 도메인: platform.data-company.com
  • 경로 설정: /api $\rightarrow$ API 서비스, /ui $\rightarrow$ 웹 대시보드 서비스
  • 보안: TLS 인증서를 통한 HTTPS 강제 적용

자주 하는 실수와 해결법 및 FAQ

인그레스를 처음 설정하다 보면 예상치 못한 에러 때문에 당황하는 경우가 많아요. 특히 네트워크 레이어에서 발생하는 문제는 원인을 찾기가 쉽지 않죠. 실무에서 가장 빈번하게 발생하는 실수들을 정리해 보았습니다.

자주 하는 실수와 해결법

실수: 인그레스 리소스를 만들었지만 접속이 안 돼요
왜 발생하는가: 인그레스 컨트롤러가 클러스터에 설치되어 있지 않거나, 컨트롤러가 리소스를 감시(Watch)하지 못하는 상태일 때 발생해요.
해결법: kubectl get pods -A 명령어로 인그레스 컨트롤러 포드가 정상적으로 running 상태인지 먼저 확인해 보세요.

실수: 404 Not Found 에러가 계속 떠요
왜 발생하는가: 인그레스에 정의한 경로(Path)와 실제 서비스로 요청하는 경로가 일치하지 않거나, 서비스 이름이 틀렸을 때 발생합니다.
해결법: 인그레스 YAML의 spec.rules.http.paths.backend.service.name이 실제 서비스 이름과 정확히 일치하는지 다시 한번 확인하세요.

실수: SSL 인증서를 적용했는데 브라우저에서 경고가 떠요
왜 발생하는가: TLS Secret이 올바르게 생성되지 않았거나, 인증서의 도메인 이름이 접속하려는 도메인과 다를 때 발생합니다.
해결법: kubectl get secret으로 인증서 시크릿을 확인하고, 인증서가 해당 도메인을 지원하는지 검증하세요.

실수: 특정 경로로 접속하면 리다이렉트 루프가 발생해요
왜 발생하는가: 인그레스 컨트롤러의 설정과 애플리케이션 내부의 프로토콜 설정이 충돌할 때 발생합니다.
해결법: 인그레스 컨트롤러의 어노테이션(Annotation) 설정을 통해 X-Forwarded-Proto 헤더를 제대로 전달하도록 조정해야 해요.

⚠️ 주의
인그레스의 경로 설정 시 끝에 슬래시(/)를 붙이느냐 마느냐에 따라 동작이 완전히 달라질 수 있어요. 설정 전에 반드시 테스트 환경에서 검증을 거치세요.

자주 묻는 질문

Q. 인그레스와 서비스 로드밸런서의 가장 큰 차이점은 무엇인가요?

가장 큰 차이는 계층(Layer)입니다. 로드밸런서는 주로 L4(전송 계층)에서 IP와 포트를 기준으로 작동하지만, 인그레스는 L7(애플리케이션 계층)에서 HTTP 헤더나 URL 경로를 분석하여 트래픽을 제어할 수 있다는 점이 다릅니다.

Q. 인그레스 컨트롤러는 꼭 Nginx를 써야 하나요?

아니요, 반드시 그럴 필요는 없어요. HAProxy, Traefik, Kong 등 다양한 컨트롤러가 존재합니다. 서비스의 요구사항에 따라 성능이나 기능(예: API 게이트웨이 기능)을 고려하여 선택하시면 됩니다.

Q. 인그레스를 통해 내부 서비스만 노출할 수도 있나요?

네, 가능합니다. 인그레스 자체는 외부 노출을 목적으로 하지만, 클러스터 내부의 특정 네트워크 환경 설정을 통해 특정 대역에서만 접속 가능하도록 제한하거나 인증을 추가할 수 있습니다.

Q. 경로 기반 라우팅 시 순서가 중요한가요?

네, 매우 중요합니다. 일반적으로 더 구체적인 경로(예: /api/v1)가 더 일반적인 경로(예: /api)보다 먼저 정의되거나 우선순위를 갖도록 설정해야 의도치 않은 라우팅을 방지할 수 있습니다.

마치며: 효율적인 클러스터 운영을 위한 첫걸음

지금까지 쿠버네티스 인그레스의 개념부터 실제 구축 과정까지 자세히 살펴보았습니다. 인그레스는 단순히 기술적인 도구를 넘어, 클러스터의 네트워크 비용을 최적화하고 관리의 복잡성을 줄여주는 핵심적인 인프라 요소입니다. 데이터 엔지니어로서 안정적인 데이터 파이프라인을 운영하고자 한다면, 인그레스에 대한 깊은 이해는 선택이 아닌 필수입니다.

✅ 핵심 요약

  • 인그레스는 L7 계층에서 트래픽을 제어하는 스마트한 관문입니다.
  • 실제 동작을 위해서는 반드시 인그레스 컨트롤러가 설치되어 있어야 합니다.
  • 경로(Path)와 호스트(Host) 기반 라우팅으로 비용을 절감할 수 있습니다.
  • 보안을 위해 TLS/SSL 인증서 적용은 필수적입니다.
  • 설정 오류 시 경로 일치 여부와 컨트롤러 상태를 가장 먼저 확인하세요.

오늘 배운 내용을 바탕으로 여러분의 개발 환경이나 테스트 클러스터에 직접 인그레스를 구성해 보세요. 이론으로 읽는 것과 직접 YAML을 작성하며 트래픽이 흐르는 것을 확인하는 것은 큰 차이가 있습니다. 만약 실습 과정에서 막히는 부분이 있다면 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 나가겠습니다.

다음 단계로 나아가고 싶다면, 인그레스 설정을 자동화해 주는 Helm 사용법이나 인증서 자동 관리를 위한 Cert-manager 학습을 추천합니다. 더 깊이 있는 쿠버네티스 네트워크 공부를 원하신다면 이전에 작성한 쿠버네티스 클러스터 구축 입문 가이드 글도 함께 읽어보시면 큰 도움이 될 거예요.

댓글 남기기