인그레스 운영, 왜 지금 고민해야 할까요?
서비스 규모가 커지면서 쿠버네티스 클러스터 내부의 서비스 개수도 급격히 늘어나기 시작했어요. 처음에는 단순히 NodePort나 LoadBalancer 타입으로 외부 트래픽을 받아보았지만, 어느 순간부터 예상치 못한 문제에 직면하게 되었어요. 서비스 하나를 띄울 때마다 클라우드 제공업체의 로드밸런서를 매번 생성하니 비용은 눈덩이처럼 불어나고, 관리해야 할 설정값은 너무나 복잡해졌기 때문이에요.
특히 백엔드 개발자로서 가장 당혹스러운 순간은 트래픽 경로가 꼬였을 때예요. 특정 도메인으로 들어온 요청을 어떤 서비스로 보내야 할지, SSL 인증서는 어디서 처리해야 할지 고민하다 보면 결국 인프라 설정 때문에 개발 흐름이 끊기곤 해요. 인그레스(Ingress)는 바로 이런 문제를 해결하기 위해 등장한 아주 똑똑한 해결책이에요.
단순히 외부 연결 통로를 만드는 것을 넘어, L7 계층에서 요청을 세밀하게 제어하고 비용 효율성을 극대화하는 것이 이번 운영 사례의 핵심이에요. 이 글에서는 실제 운영 환경에서 인그레스를 도입하며 겪었던 시행착오와, 어떻게 하면 더 안정적인 트래픽 라우팅 체계를 구축할 수 있는지 실무적인 관점에서 정리해 보려고 해요.
인그레스는 쿠버네티스 클러스터 외부에서 내부 서비스로 HTTP/HTTPS 경로를 노출하는 API 오브젝트예요. 로드밸런서의 역할을 소프트웨어적으로 구현하여 효율성을 높여줘요.
이번 글에서는 다음과 같은 내용들을 구체적으로 다뤄요.
- 인그레스 도입 전의 네트워크 구성 문제점과 비용 이슈
- 실제 환경에서 사용하기 좋은 인그레스 컨트롤러 비교와 선택 기준
- 경로(Path) 및 호스트(Host) 기반 라우팅의 단계별 설정 방법
- SSL/TLS 인증서 자동화와 트러블슈팅 경험
- 실무에서 자주 발생하는 오류와 해결책
인그레스 도입 전, 반드시 체크해야 할 사항들
인그레스를 무작정 설치한다고 해서 모든 문제가 해결되는 것은 아니에요. 오히려 잘못된 설계는 트래픽 병목 현상을 일으키거나 보안 취약점을 만들 수 있어요. 인그레스를 도입하기 전에 우리 서비스의 트래픽 특성과 현재 네트워크 구조가 어떤 상태인지 냉정하게 파악하는 과정이 반드시 필요해요.
네트워크 타입별 비교와 선택 기준
가장 먼저 결정해야 할 것은 현재 사용 중인 서비스 노출 방식 중 무엇을 인그레스로 대체할 것인가 하는 점이에요. 아래 표를 통해 각 방식의 차이점을 명확히 비교해 보세요.
| 구분 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 작동 계층 | L4 (Transport) | L4 (Transport) | L7 (Application) |
| 비용 효율성 | 매우 높음 | 낮음 (개당 비용 발생) | 매우 높음 (공유 가능) |
| 라우팅 기능 | 단순 포트 기반 | 단순 IP 기반 | URL/도메인 기반 세밀한 제어 |
| SSL 관리 | 애플리케이션에서 직접 관리 | 클라우드 LB에서 처리 | 인그레스에서 통합 관리 |
표에서 볼 수 있듯이, 서비스 개수가 적을 때는 LoadBalancer 방식이 간편할 수 있지만, 마이크로서비스 아키텍처(MSA)로 넘어가면 인그레스는 선택이 아닌 필수예요. 특히 도메인별로 다른 서비스를 연결하거나 하나의 IP로 여러 서비스를 운영해야 한다면 더욱 그래요.
인그레스 도입을 위한 사전 체크리스트
실무에 적용하기 전에 다음 세 가지 질문에 스스로 답해 보세요. 이 질문들에 명확한 답을 내릴 수 있어야 실패 없는 도입이 가능해요.
- 우리 서비스의 트래픽 양은 어느 정도인가요? 트래픽이 너무 많다면 인그레스 컨트롤러 자체가 병목 지점이 될 수 있어요. 이럴 때는 컨트롤러의 리소스(CPU, Memory)를 충분히 할당하거나 여러 대의 컨트롤러를 운영하는 전략이 필요해요.
- 어떤 라우팅 규칙이 필요한가요? 단순한 경로 매칭만 필요한지, 아니면 헤더(Header)나 쿠키(Cookie) 값에 따른 정교한 라우팅이 필요한지에 따라 컨트롤러 선택이 달라져요.
- 인증서 관리는 어떻게 할 계획인가요? SSL 인증서를 수동으로 업데이트할 것인지, Cert-manager 같은 도구를 사용해 자동화할 것인지 미리 결정해야 해요.
인그레스 컨트롤러는 모든 외부 트래픽이 통과하는 단일 진입점이에요. 따라서 컨트롤러의 설정 오류나 장애는 전체 서비스의 가용성에 직접적인 영향을 미친다는 사실을 잊지 마세요.
실전 인그레스 구축 및 운영 프로세스
이제 본격적으로 실제 환경에서 인그레스를 어떻게 구성하고 운영하는지 단계별로 살펴볼게요. 저는 가장 대중적이면서도 강력한 기능을 제공하는 Nginx Ingress Controller를 기준으로 설명해 드릴게요.
STEP 1. 인그레스 컨트롤러 선택과 설치
먼저 어떤 컨트롤러를 쓸지 정해야 해요. Nginx는 가장 많은 레퍼런스를 보유하고 있어 문제 해결이 쉽고, Kong은 API 게이트웨이 기능이 강력하며, Traefik은 클라우드 네이티브한 설정이 매력적이에요. 저희 팀은 커뮤니티 지원이 가장 활발한 Nginx를 선택했어요.
설치는 Helm을 이용하는 것이 가장 깔끔해요. 명령 한 줄로 복잡한 설정들을 한 번에 끝낼 수 있거든요. 아래는 설치를 위한 기본적인 흐름이에요.
- Helm 레포지토리 추가: `helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx`
- 설정 파일(values.yaml) 준비: 리소스 제한(Limits)과 서비스 타입 등을 정의해요.
- 설치 실행: `helm install my-ingress ingress-nginx/ingress-nginx -f values.yaml`
설치가 끝나면 반드시 Pod의 상태와 Service의 External IP를 확인해야 해요. 이 IP가 우리가 앞으로 사용할 서비스의 대문이 될 거예요.
STEP 2. 경로(Path) 기반 라우팅 구성하기
인그레스의 가장 큰 장점은 하나의 도메인 아래에서 경로에 따라 다른 서비스를 연결할 수 있다는 점이에요. 예를 들어, `example.com/api`로 들어오는 요청은 백엔드 서비스로, `example.com/web`은 프론트엔드 서비스로 보내는 식이죠.
이를 위해 아래와 같은 인그레스 설정 파일을 작성하게 돼요.
# 인그레스 설정 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: service-routing
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /web
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
여기서 주의할 점은 rewrite-target 어노테이션이에요. 백엔드 서비스가 `/api`라는 경로를 직접 인식하지 못할 경우, 인그레스 단계에서 경로를 깎아주는 작업이 꼭 필요하거든요. 이 설정을 빼먹으면 백엔드에서 404 오류가 쏟아지는 경험을 하게 될 거예요.
STEP 3. 도메인(Host) 기반 라우팅 및 멀티 테넌시
경로뿐만 아니라 아예 다른 도메인을 사용하는 경우도 많아요. `api.example.com`과 `dashboard.example.com`을 분리하고 싶을 때, 인그레스는 아주 효율적으로 동작해요. 이 방식은 각 팀이 서로 다른 도메인을 사용하면서도 하나의 로드밸런서 인프라를 공유할 수 있게 해주어 비용을 획기적으로 줄여줘요.
설정 시에는 host 필드에 각 도메인을 명시하기만 하면 돼요. 이렇게 하면 인그레스 컨트롤러가 들어오는 HTTP 요청의 ‘Host’ 헤더를 읽어서 어떤 규칙을 적용할지 즉시 판단해요. 매우 빠르고 효율적인 방식이죠.
STEP 4. SSL/TLS 인증서 적용과 보안 강화
실무에서 가장 신경 쓰이는 부분은 역시 보안이에요. 모든 트래픽은 HTTPS로 암호화되어야 하죠. 매번 인증서를 수동으로 발급받고 Secret을 생성하는 건 너무나 번거로운 일이에요. 그래서 저희는 Cert-manager를 도입했어요.
Cert-manager를 설치하면 Let’s Encrypt와 같은 무료 인증서 발급 기관과 연동하여, 인증서 만료 전에 자동으로 갱신까지 처리해 줘요. 인그레스 설정에 tls 섹션만 추가하면 인그레스 컨트롤러가 알아서 인증서를 가져와 적용해요. 개발자는 이제 인증서 만료 때문에 새벽에 깨어날 걱정을 하지 않아도 돼요.
STEP 5. 실전 운영 시나리오: 트래픽 제어
단순한 라우팅을 넘어, 실제 서비스 운영 중에는 트래픽을 조절해야 하는 상황이 반드시 와요. 특정 서비스에 트래픽이 몰려 전체 시스템이 마비되는 것을 방지하기 위해 인그레스 어노테이션을 활용한 Rate Limiting(속도 제한)을 설정해 보세요.
예를 들어, 특정 API 경로에 대해 초당 요청 횟수를 제한하도록 설정하면, 악의적인 공격이나 비정상적인 트래픽으로부터 우리 백엔드 서비스를 안전하게 보호할 수 있어요. 또한, client-max-body-size 설정을 통해 대용량 파일 업로드 제한도 인그레스 단에서 깔끔하게 관리할 수 있어요.
인그레스 설정이 변경되면 컨트롤러가 이를 감지하고 설정을 재로드(Reload)해요. 설정이 너무 자주 바뀌면 컨트롤러에 부하가 갈 수 있으니, 변경 사항은 신중하게 검토한 뒤 적용하는 습관을 갖는 게 좋아요.
자주 하는 실수와 해결법 + FAQ
인그레스를 운영하다 보면 이론과 실전이 다르다는 것을 뼈저리게 느끼게 돼요. 제가 직접 겪으며 정리한 대표적인 실수들과 해결 방법을 알려드릴게요.
자주 하는 실수와 해결법
❌ 404 Not Found 에러가 계속 발생해요
왜 발생하는가: 인그레스의 path 설정과 실제 서비스가 기대하는 경로가 일치하지 않거나, rewrite-target 설정이 누락되었을 확률이 높아요.
✅ 해결법: 인그레스의 경로 규칙을 다시 확인하고, 백엔드 서비스의 로그를 통해 요청이 실제로 어떤 경로로 들어오고 있는지 반드시 확인해 보세요.
❌ 502 Bad Gateway 오류가 떠요
왜 발생하는가: 인그레스 컨트롤러가 요청을 전달할 대상 서비스(Service)나 포드(Pod)를 찾지 못할 때 발생해요. 서비스의 셀렉터(Selector)가 잘못되었거나, 포드가 준비(Ready) 상태가 아닐 수 있어요.
✅ 해결법: kubectl get endpoints 명령어로 서비스에 연결된 엔드포인트가 실제로 존재하는지 확인해 보세요.
❌ SSL 인증서 적용 후 브라우저에서 경고가 떠요
왜 발생하는가: 인증서 Secret이 제대로 생성되지 않았거나, 인그레스 설정의 tls.secretName이 실제 Secret 이름과 다를 때 발생해요.
✅ 해결법: kubectl get secret으로 인증서가 있는지 확인하고, 인그레스 YAML 파일의 이름과 일치하는지 대조해 보세요.
❌ 클라이언트 IP가 로드밸런서 IP로만 찍혀요
왜 발생하는가: 클라우드 로드밸런서가 클라이언트의 원본 IP를 헤더에 담아 전달하지 않거나, 인그레스 설정에서 이를 허용하지 않았기 때문이에요.
✅ 해결법: 인그레스 어노테이션에 use-forwarded-headers: "true" 설정을 추가하고, 클라우드 LB의 설정을 확인해 보세요.
❌ 설정을 바꿨는데 반영이 너무 느려요
왜 발생하는가: 인그레스 컨트롤러의 동기화 주기가 있거나, 설정값이 너무 많아 재로드 과정에서 시간이 소요되는 경우예요.
✅ 해결법: 컨트롤러의 로그를 살펴보고, 설정 변경이 반영되는 데 걸리는 시간을 모니터링하여 리소스 부족 여부를 판단해 보세요.
자주 묻는 질문
Q. 인그레스와 API 게이트웨이의 차이가 무엇인가요?
인그레스는 쿠버네티스 표준 오브젝트로서 기본적인 HTTP 라우팅에 집중해요. 반면 API 게이트웨이는 인증, 인가, 복잡한 트래픽 제어, 사용자별 할당량 관리 등 훨씬 더 고도화된 기능을 제공하는 전문 도구라고 이해하시면 돼요. 단순한 라우팅이 목적이라면 인그레스만으로도 충분해요.
Q. 하나의 인그레스 컨트롤러로 여러 개의 인그레스 오브젝트를 관리할 수 있나요?
네, 당연히 가능해요! 하나의 컨트롤러(엔드포인트)가 여러 개의 인그레스 규칙을 읽어서 처리하는 구조예요. 다만, 하나의 규칙이 잘못되어 컨트롤러 전체에 부하를 주지 않도록 주의해야 해요.
Q. 인그레스를 사용하면 비용이 정말로 절감되나요?
네, 맞아요. 클라우드 환경에서 서비스마다 LoadBalancer 타입을 쓰면 서비스 개수만큼 비용이 청구되지만, 인그레스는 하나의 LoadBalancer IP를 공유하며 내부적으로 경로를 나누기 때문에 비용 효율이 매우 높아요.
Q. SSL 인증서를 수동으로 등록하는 게 나을까요, 자동화하는 게 나을까요?
무조건 자동화를 추천해요. 수동 관리는 인증서 만료 시점을 놓칠 위험이 너무 커요. Cert-manager를 활용한 자동화 시스템을 구축해 두는 것이 운영 안정성 측면에서 훨씬 유리해요.
성공적인 인그레스 운영을 위한 마무리
지금까지 인그레스 운영 사례를 통해 실제 서비스에 적용하는 방법과 주의해야 할 점들을 살펴보았어요. 인그레스는 단순히 트래픽을 넘겨주는 통로가 아니라, 우리 서비스의 관문이자 보안의 최전선이라는 사실을 꼭 기억해 주세요. 처음에는 설정 하나하나가 어렵게 느껴지겠지만, 한 번 체계를 잡아두면 운영 효율성이 비약적으로 상승하는 것을 경험하실 수 있을 거예요.
- 비용 최적화: 서비스마다 로드밸런서를 만들지 말고 인그레스로 통합하세요.
- 경로 설계: rewrite-target 어노테이션을 활용해 백엔드 경로 불일치를 해결하세요.
- 보안 자동화: Cert-manager를 사용하여 SSL 인증서 관리를 자동화하세요.
- 트래픽 제어: Rate Limiting 어노테이션으로 서비스 안정성을 확보하세요.
- 문제 해결: 502/404 에러 발생 시 엔드포인트와 경로 규칙을 최우선으로 점검하세요.
이제 여러분의 차례예요. 오늘 배운 내용을 바탕으로 현재 운영 중인 클러스터의 네트워크 구조를 다시 한번 점검해 보세요. 만약 아직도 서비스마다 개별 로드밸런서를 쓰고 있다면, 이번 주에는 인그레스 컨트롤러를 하나 설치해서 작은 서비스부터 테스트해 보는 건 어떨까요?
실습 환경에서 직접 적용해 보시다가 잘 안 풀리는 부분이 있다면, 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하며 해결 방법을 찾아가 봐요! 여러분의 성공적인 쿠버네티스 운영을 응원해요.
관련해서 더 깊이 있는 내용이 궁금하시다면 아래 글들도 함께 읽어보시는 것을 추천드려요.
🔗 쿠버네티스 인그레스 기본 개념 정리하기
🔗 쿠버네티스 클러스터 구축 입문 가이드
