왜 인그레스(Ingress) 설정에서 자꾸 막히게 될까요?

데이터 파이프라인을 운영하다 보면 에어플로우(Airflow)나 그라파나(Grafana) 같은 도구들을 외부에서 접속할 수 있게 만들어야 하는 순간이 자주 찾아와요. 이때 가장 먼저 손이 가는 것이 바로 인그레스(Ingress) 설정이에요. 하지만 야심 차게 YAML 파일을 작성해서 적용했는데, 정작 브라우저에는 404 Not Found나 503 Service Unavailable 같은 차가운 에러 메시지만 뜨는 경우가 정말 많아요.
분명히 서비스(Service)도 잘 떠 있고, 포드(Pod)도 정상인데 왜 접속이 안 되는 걸까요? 인그레스 컨트롤러가 설치되지 않았거나, 경로(Path) 설정이 미세하게 틀렸거나, 혹은 어노테이션(Annotation) 하나가 빠져서 발생하는 문제일 수도 있어요. 이런 사소한 설정 차이가 전체 데이터 플랫폼의 가용성을 결정짓곤 해요.
이 글은 단순히 이론적인 정의를 늘어놓는 곳이 아니에요. 실제 운영 환경에서 데이터 엔지니어나 데브옵스(DevOps) 엔지니어가 인그레스를 다루며 겪는 실무적인 혼란을 해결하는 데 집중해요. 인그레스의 기본 개념부터 복잡한 라우팅 규칙, 그리고 장애 발생 시 빠르게 원인을 찾아내는 방법까지 단계별로 차근차근 설명해 드릴게요.
이번 글을 통해 다음 내용들을 확실히 가져가실 수 있어요.
- 인그레스와 서비스, 컨트롤러의 명확한 관계 이해
- 경로 및 호스트 기반의 정교한 라우팅 설정법
- SSL/TLS 인증서를 적용하여 보안을 강화하는 방법
- 실무에서 자주 발생하는 에러 유형과 즉각적인 해결책
인그레스를 다루기 전 반드시 챙겨야 할 기초 지식
인그레스를 제대로 사용하려면 먼저 내가 지금 무엇을 만들려고 하는지 명확히 알아야 해요. 많은 분이 서비스(Service)의 로드밸런서(LoadBalancer) 타입과 인그레스의 차이를 헷갈려 하곤 해요. 로드밸런서는 클라우드 제공업체의 로드밸런서를 직접 생성하여 각 서비스마다 개별적인 IP를 할당받는 방식이에요. 반면 인그레스는 하나의 진입점을 만들고, 그 안에서 규칙에 따라 여러 서비스로 트래픽을 분산해 주는 스마트한 게이트웨이 역할을 수행해요.
인그레스 리소스를 생성했다고 해서 바로 마법처럼 작동하는 것은 아니에요. 반드시 그 규칙을 실제로 읽고 트래픽을 전달해 줄 인그레스 컨트롤러(Ingress Controller)가 클러스터 안에 살아 움직이고 있어야 해요. 가장 대중적으로 쓰이는 것은 Nginx 인그레스 컨트롤러예요. 컨트롤러가 없다면 여러분이 작성한 YAML 파일은 그저 클러스터 내의 쓸모없는 텍스트 데이터일 뿐이에요.
인그레스는 ‘규칙(Rule)’이고, 인그레스 컨트롤러는 그 규칙을 실행하는 ‘엔진’이에요. 엔진이 없으면 규칙은 작동하지 않아요!
본격적인 실습에 들어가기 전에, 현재 여러분의 환경이 어떤 방식을 택해야 할지 결정해야 해요. 아래 표를 통해 서비스 타입과 인그레스의 차이점을 비교해 보세요.
| 비교 항목 | NodePort 서비스 | LoadBalancer 서비스 | Ingress (인그레스) |
|---|---|---|---|
| 주요 용도 | 테스트 및 내부 통신 | 단일 서비스 외부 노출 | 다수 서비스 통합 관리 |
| 비용 효율성 | 매우 높음 | 낮음 (서비스당 IP 비용) | 높음 (하나의 IP 공유) |
| 라우팅 기능 | 없음 | 없음 | Path/Host 기반 지원 |
| 설정 난이도 | 매우 쉬움 | 쉬움 | 중간 (컨트롤러 필요) |
만약 여러분이 관리해야 할 서비스가 5개 이상이라면, 각각 로드밸런서를 만드는 것보다 인그레스를 사용하는 것이 비용과 관리 측면에서 훨씬 유리해요. 하지만 인그레스는 컨트롤러라는 추가 계층이 존재하므로, 설정이 복잡해질 수 있다는 점을 기억해 두세요.
실무자를 위한 인그레스 완벽 활용 가이드
이제 실제 인그레스를 어떻게 구성하고 운영하는지 구체적인 단계를 따라가며 살펴볼게요. 데이터 엔지니어의 관점에서 자주 접하는 시나리오를 바탕으로 설명해 드릴게요.
STEP 1. 인그레스 컨트롤러와 리소스의 연결 이해하기
가장 먼저 해야 할 일은 클러스터에 인그레스 컨트롤러가 설치되어 있는지 확인하는 것이에요. kubectl get pods -n ingress-nginx 명령어를 통해 컨트롤러가 정상적으로 실행 중인지 확인해 보세요. 컨트롤러가 실행 중이라면, 이제 우리가 작성한 인그레스 리소스(Ingress Resource)가 이 컨트롤러에 의해 감지되어 실제 Nginx 설정으로 변환되는 과정을 이해해야 해요.
인그레스 리소스는 일종의 ‘지도’와 같아요. “이 주소로 들어오면 저 서비스로 보내줘”라는 지시 사항이죠. 컨트롤러는 이 지도를 실시간으로 읽어서 자신의 설정 파일에 반영하고, 트래픽이 들어올 때마다 지도를 보고 길을 안내해 줘요. 따라서 인그레스 리소스를 수정했다면, 컨트롤러의 로그를 통해 설정이 제대로 반영되었는지 확인하는 습관을 들이는 것이 좋아요.
STEP 2. 경로(Path) 기반의 스마트한 라우팅 구현하기
데이터 플랫폼을 운영하다 보면 하나의 도메인 아래 여러 서비스를 배치해야 할 때가 많아요. 예를 들어, company.com/airflow는 에어플로우로, company.com/grafana는 그라파나로 연결하고 싶을 거예요. 이것이 바로 경로 기반 라우팅이에요.
이때 주의할 점은 경로의 끝처리(Trailing Slash)예요. 어떤 서비스는 /airflow/처럼 끝에 슬래시가 있어야 작동하고, 어떤 서비스는 없어야만 작동해요. 인그레스 설정 시 pathType을 Prefix로 할지 Exact로 할지도 신중하게 결정해야 해요. Prefix는 해당 경로로 시작하는 모든 요청을 포함하고, Exact는 정확히 일치하는 요청만 처리하거든요.
대부분의 경우 경로 하위의 모든 API 호출을 허용하기 위해
pathType: Prefix를 사용하는 것이 정신 건강에 이로워요!STEP 3. 호스트(Host) 기반 라우팅과 SSL/TLS 적용하기
경로 기반 라우팅보다 더 깔끔한 방법은 아예 도메인을 분리하는 것이에요. airflow.company.com과 grafana.company.com처럼 도메인 자체를 나누는 방식이죠. 이렇게 하면 경로 설정에 따른 혼란을 줄일 수 있고, 보안 관리도 훨씬 수월해져요.
특히 데이터 플랫폼은 민감한 정보를 다루기 때문에 HTTPS 적용은 선택이 아닌 필수예요. 인그레스에서는 TLS 설정을 통해 아주 쉽게 SSL을 적용할 수 있어요. 먼저 쿠버네티스 Secret 객체에 인증서와 개인키를 저장한 뒤, 인그레스 설정의 tls 섹션에서 해당 시크릿 이름을 지정해 주기만 하면 돼요. 요즘은 cert-manager를 사용하여 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하는 방식을 표준처럼 사용하고 있어요.
STEP 4. 어노테이션(Annotation)으로 고급 기능 제어하기
인그레스의 진정한 힘은 어노테이션에서 나와요. 어노테이션은 인그레스 리소스에 추가적인 ‘지시 사항’을 전달하는 메타데이터예요. 예를 들어, 데이터 엔지니어가 대용량 로그 파일을 업로드해야 하는 환경이라면, Nginx의 기본 요청 크기 제한(보통 1MB) 때문에 에러가 날 수 있어요. 이때 nginx.ingress.kubernetes.io/proxy-body-size="50m" 같은 어노테이션을 추가하면 제한을 간단히 늘릴 수 있어요.
또한, 특정 경로로 들어온 요청을 다른 경로로 재작성(Rewrite)해야 할 때도 어노테이션이 필요해요. 서비스는 / 경로를 기준으로 작동하는데, 인그레스는 /airflow로 요청을 받는다면, 중간에서 경로를 깎아주는 rewrite-target 설정이 반드시 들어가야 서비스가 정상적으로 응답할 수 있어요.
STEP 5. 실제 운영 시나리오: 데이터 대시보드 구성하기
자, 지금까지 배운 내용을 바탕으로 실제 시나리오를 구성해 볼게요. 여러분은 회사 내부에 Airflow와 Grafana를 운영하고 있고, 이를 외부 엔지니어들에게 제공해야 해요.
설계 시나리오:
- 도메인: data-platform.company.com
- 경로 1: /airflow (Airflow UI 연결)
- 경로 2: /grafana (Grafana 대시보드 연결)
- 보안: Let’s Encrypt를 통한 자동 HTTPS 적용
- 특이사항: Grafana의 경우 정적 파일 로딩을 위해 경로 재작성 필요
이런 설계를 바탕으로 YAML을 작성할 때, 가장 먼저 서비스의 Selector가 포드의 라벨과 정확히 일치하는지, 서비스의 Port가 인그레스에 명시된 포트와 일치하는지를 확인하는 것이 성공적인 구축의 핵심이에요. 이 과정을 하나씩 검증하며 나아간다면, 복잡한 데이터 플랫폼의 진입점도 문제없이 구축할 수 있어요.
자주 하는 실수와 해결법
현장에서 마주치는 가장 흔한 실수들을 정리했어요. 문제가 생겼을 때 이 리스트를 먼저 확인해 보세요.
- ❌ 인그레스 컨트롤러가 아예 작동하지 않아요 → 왜? 인그레스 리소스만 만들고 컨트롤러를 설치하지 않았기 때문이에요.
✅ kubectl get pods -A 명령어로 nginx-ingress 같은 컨트롤러가 떠 있는지 확인하세요. - ❌ 404 Not Found 에러가 계속 떠요 → 왜? 경로(Path) 설정이 잘못되었거나 서비스의 Selector가 틀려서 트래픽을 전달할 목적지를 못 찾은 거예요.
✅ 인그레스의 Path와 서비스의 Selector, 그리고 서비스의 Port를 하나씩 대조해 보세요. - ❌ 503 Service Unavailable 에러가 나요 → 왜? 인그레스는 길을 찾았지만, 정작 연결된 포드(Pod)가 죽어있거나 준비(Ready) 상태가 아니에요.
✅ kubectl get pods로 대상 서비스의 포드가 정상인지 확인하세요. - ❌ HTTPS 접속 시 인증서 에러가 발생해요 → 왜? TLS Secret의 이름이 인그레스 설정과 다르거나, 인증서가 만료되었을 가능성이 높아요.
✅ kubectl get secret로 이름이 정확한지, 인증서가 유효한지 확인하세요. - ❌ 대용량 데이터 업로드 시 에러가 나요 → 왜? Nginx의 기본 요청 제한 용량을 초과했기 때문이에요.
✅ proxy-body-size 어노테이션을 추가해서 제한을 늘려주세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서 서비스의 가장 큰 차이점은 무엇인가요?
가장 큰 차이는 ‘효율성’과 ‘라우팅 기능’이에요. 로드밸런서는 서비스 하나당 하나의 외부 IP를 소모하므로 비용이 많이 들고 경로 기반 분산이 안 되지만, 인그레스는 하나의 IP로 여러 서비스를 경로와 호스트에 따라 나누어 전달할 수 있어 훨씬 경제적이고 똑똑해요.
Q. Nginx 인그레스 컨트롤러는 왜 꼭 써야 하나요?
쿠버네티스 자체에는 트래픽을 해석하고 전달하는 기능이 내장되어 있지 않아요. 인그레스 리소스는 그저 ‘명세서’일 뿐이고, 이 명세서를 읽어서 실제 엔진(Nginx 등)을 가동시켜 트래픽을 흘려보내 줄 주체가 반드시 필요한데, 그 주체가 바로 인그레스 컨트롤러예요.
Q. 404 에러가 날 때 가장 먼저 확인해야 할 것은 무엇인가요?
우선 인그레스의 path 설정과 실제 요청 주소가 일치하는지 보세요. 특히 마지막에 슬래시(/)가 붙어 있는지, 혹은 pathType이 의도대로 설정되었는지를 확인하는 것이 가장 빠른 해결 방법이에요.
Q. SSL 인증서를 수동으로 관리하기 너무 힘든데 방법이 없나요?
cert-manager라는 도구를 사용해 보세요. 쿠버네티스 안에서 Let’s Encrypt 같은 무료 인증서를 자동으로 발급받고, 만료되기 전에 알아서 갱신까지 해주는 아주 강력한 도구예요. 실무에서는 거의 필수적으로 사용해요.
Q. 인그레스 설정이 반영되었는지 어떻게 확신할 수 있나요?
인그레스 컨트롤러의 로그를 보는 것이 가장 확실해요. kubectl logs 명령어를 통해 컨트롤러 포드의 로그를 살펴보면, 새로운 인그레스 리소스가 감지되어 설정이 업데이트되었다는 메시지를 확인할 수 있어요.
인그레스 운영을 위한 최종 점검
인그레스는 설정하기 까다롭지만, 한 번 제대로 구축해두면 데이터 플랫폼의 관문으로서 매우 강력한 역할을 수행해요. 복잡한 라우팅과 보안 문제를 한 곳에서 깔끔하게 해결할 수 있으니까요. 마지막으로 실무에서 놓치기 쉬운 핵심 포인트들을 다시 한번 정리해 드릴게요.
- 인그레스 컨트롤러(엔진)가 반드시 설치되어 있어야 해요.
- 서비스의 Selector와 포트가 인그레스 설정과 일치하는지 확인하세요.
- 경로 기반 라우팅 시 슬래시(/) 유무와 pathType을 주의 깊게 보세요.
- 보안을 위해 SSL/TLS 적용은 필수이며, cert-manager 활용을 추천해요.
- 대용량 데이터 처리가 필요하다면 proxy-body-size 어노테이션을 잊지 마세요.
- 장애 시에는 컨트롤러의 로그를 가장 먼저 확인하는 것이 지름길이에요.
오늘 내용을 바탕으로 지금 바로 여러분의 클러스터에 설정된 인그레스 리소스를 점검해 보는 건 어떨까요? 작은 설정 하나가 서비스의 안정성을 결정지을 수 있어요.
다음 단계로 나아가기
인그레스 설정을 마쳤다면, 이제 다음 단계로 넘어가 실전 감각을 익혀보세요.
- 오늘 할 일: 현재 운영 중인 인그레스의 컨트롤러 로그를 확인하고 404/503 에러 패턴이 없는지 체크하기
- 이번 주 할 일: cert-manager를 설치하여 SSL 인증서 자동화 환경 구축해 보기
- 실행 직전 할 일: 실제 도메인을 연결하기 전, hosts 파일을 수정하여 로컬에서 라우팅 테스트 수행하기
실습 환경에서 인그레스를 적용하다가 막히는 부분이 있다면, 언제든 아래 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나갔으면 좋겠어요!
관련해서 더 깊이 있는 내용이 궁금하다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글도 함께 읽어 보시는 것을 추천해요.