인그레스 운영 사례: 왜 NodePort와 LoadBalancer만으로는 부족할까요
마이크로서비스 아키텍처(MSA)를 운영하다 보면 어느 순간 머리가 아파지는 시점이 찾아와요. 처음에는 서비스가 두세 개뿐이라 NodePort를 사용해서 간단히 외부로 노출해도 문제가 없었지요. 하지만 서비스가 열 개, 스무 개로 늘어나기 시작하면 상황은 완전히 달라져요. 매번 새로운 포트 번호를 관리해야 하고, 클라이언트에게 수많은 포트 주소를 알려주는 것도 불가능에 가까워지거든요.
그렇다고 모든 서비스마다 LoadBalancer 타입을 사용하자니 클라우드 비용이 무섭게 치솟아요. 서비스 하나당 하나의 로드밸런서가 생성된다면, 서비스 개수가 늘어날수록 매달 청구되는 비용도 정비례해서 늘어나기 때문이에요. 결국 개발팀은 “어떻게 하면 적은 비용으로, 깔끔한 URL 구조를 유지하며 서비스를 노출할 수 있을까?”라는 고민에 빠지게 돼요.
이런 문제를 해결하기 위해 등장한 것이 바로 인그레스(Ingress)예요. 인그레스는 단순히 트래픽을 전달하는 통로를 넘어, HTTP/HTTPS 프로토콜의 L7 계층에서 경로(Path)나 호스트(Host)를 기준으로 트래픽을 똑똑하게 분산해 주는 역할을 수행해요. 실제 운영 환경에서 인그레스를 어떻게 도입했고, 어떤 과정을 거쳐 최적화했는지 그 생생한 경험을 공유해 드릴게요.
이 글을 통해 여러분은 다음 내용들을 확실히 알아갈 수 있어요.
- 기존 네트워크 방식과 인그레스의 결정적인 차이점
- 실제 환경에서 인그레스 컨트롤러를 선택하고 구성하는 방법
- SSL/TLS 인증서 적용과 경로 기반 라우팅 설정 실무
- 운영 중 반드시 마주하게 되는 트러블슈팅 사례
사전 준비: 인그레스 도입 전 반드시 체크해야 할 핵심 요소
인그레스를 무턱대고 설치한다고 해서 모든 문제가 해결되는 것은 아니에요. 우리 서비스의 트래픽 특성과 현재 클러스터의 구조를 먼저 파악해야 해요. 특히 L7 계층의 제어가 필요한지를 판단하는 것이 가장 우선순위예요. 단순히 포트만 열어주면 되는 상황인지, 아니면 URL 경로에 따라 다른 서비스로 보내줘야 하는 상황인지를 명확히 해야 하거든요.
인그레스를 도입하기 전에 가장 먼저 비교해 봐야 할 것은 현재 사용 중인 노출 방식이에요. 아래 표를 통해 각각의 특징을 비교해 보며 우리 팀에 어떤 방식이 적합할지 판단해 보세요.
| 구분 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 계층 | L4 (Transport) | L4 (Transport) | L7 (Application) |
| 비용 효율성 | 매우 높음 | 낮음 (서비스별 과금) | 매우 높음 (통합 관리) |
| 기능성 | 단순 포트 전달 | 외부 IP 제공 | 경로/호스트 기반 라우팅 |
| 관리 복잡도 | 매우 높음 (포트 관리) | 중간 | 낮음 (중앙 집중형) |
또한, 인그레스는 그 자체로 동작하는 엔진이 아니라 인그레스 컨트롤러(Ingress Controller)라는 실제 실행 주체가 필요하다는 점을 잊지 마세요. 인그레스 리소스(Resource)는 “이런 규칙으로 트래픽을 보내줘”라는 설정 파일일 뿐이고, 이 파일을 읽어서 실제로 트래픽을 처리하는 것은 컨트롤러의 몫이에요. 보통 NGINX, Traefik, Kong 같은 오픈소스 컨트롤러를 주로 사용해요.
인그레스 컨트롤러를 설치할 때는 클라우드 환경의 로드밸런서와 어떻게 연동될지도 함께 고려해야 해요. 예를 들어, AWS 환경이라면 ELB(Elastic Load Balancer)가 인그레스 컨트롤러의 서비스(Service)와 연결되어 외부 트래픽을 받아오는 구조가 일반적이에요.
준비 과정에서 마지막으로 확인해야 할 체크리스트를 정리해 드릴게요. 이 조건들이 충족되었을 때 비로소 본격적인 설정을 시작할 수 있어요.
- 도메인을 관리할 수 있는 DNS 환경이 준비되어 있는가?
- SSL 인증서를 발급받거나 관리할 수 있는 도구(예: Cert-manager)가 있는가?
- 클러스터 내에 트래픽을 처리할 충분한 리소스(CPU, Memory)가 확보되었는가?
- 애플리케이션들이 내부 통신을 위해 적절한 Service 객체를 가지고 있는가?
핵심 본문: 인그레스 구축부터 최적화까지의 실전 단계
실제 운영 환경에서 인그레스를 구축했던 경험을 바탕으로, 단계별 실행 과정을 아주 구체적으로 나누어 설명해 드릴게요. 이론적인 내용보다는 실제 어떤 순서로 명령어를 입력하고 설정을 바꾸었는지에 초점을 맞췄어요.
STEP 1. 서비스 요구사항 분석 및 트래픽 패턴 파악하기
가장 먼저 해야 할 일은 현재 운영 중인 서비스들의 URL 구조를 설계하는 일이에요. 무턱대고 설정부터 하면 나중에 경로가 꼬여서 서비스 전체가 중단되는 사고가 발생할 수 있거든요. 저희 팀은 다음과 같은 요구사항을 먼저 정리했어요.
- 메인 웹 서비스:
example.com/ - API 서버:
example.com/api/v1/ - 정적 파일 저장소:
example.com/static/
이렇게 경로(Path)를 기준으로 나눌 것인지, 아니면 api.example.com처럼 서브도메인(Host)으로 나눌 것인지를 결정해야 해요. 서브도메인 방식은 관리가 직관적이지만 DNS 설정이 늘어난다는 점을 고려해야 하고, 경로 기반 방식은 하나의 도메인으로 모든 것을 처리할 수 있어 관리가 편하지만 URL 경로 처리에 신경을 많이 써야 해요.
STEP 2. 인그레스 컨트롤러 설치 및 기초 구성
저희는 가장 범용성이 높고 커뮤니티가 활발한 NGINX Ingress Controller를 선택했어요. Helm이라는 패키지 매니저를 사용하면 설치 과정이 매우 간편해져요. 설치 명령어를 실행하면 클러스터 내에 컨트롤러를 위한 네임스페이스가 생성되고, 외부 트래픽을 받아올 수 있는 로드밸런서 서비스가 자동으로 구성돼요.
설치가 완료된 후에는 반드시 컨트롤러가 정상적으로 동작하는지 확인해야 해요. kubectl get pods -n ingress-nginx 명령어를 통해 Pod들이 Running 상태인지 확인하고, 할당된 외부 IP가 정상적으로 나오는지 체크하는 과정이 꼭 필요해요. 이때 할당된 IP는 클라우드 업체에서 제공하는 로드밸런서의 IP와 연결되어 있답니다.
STEP 3. 인그레스 리소스(Resource) 작성 및 경로 라우팅 적용
이제 본격적으로 트래픽을 어디로 보낼지 정의하는 YAML 파일을 작성할 차례예요. 아래는 저희가 실제로 적용했던 설정 예시예요. 이 설정을 통해 사용자가 특정 경로로 접속했을 때 해당 서비스로 연결되도록 만들 수 있어요.
YAML 파일에서
pathType: Prefix를 사용하면 해당 경로로 시작하는 모든 요청을 포함한다는 뜻이에요. Exact는 정확히 일치하는 경로만 허용하니 주의가 필요해요.실제 작성할 때는 다음과 같은 구조를 갖춰야 해요. 우선 apiVersion과 kind를 정확히 기재하고, rules 섹션 아래에 호스트 이름과 경로를 나열해요. 각 경로에 대응하는 backend에는 연결할 Service의 이름과 포트 번호를 적어주면 돼요. 이 작업이 끝나고 kubectl apply -f로 적용하면 즉시 트래픽 분산이 시작돼요.
STEP 4. 보안 강화를 위한 SSL/TLS 인증서 자동화
운영 환경에서 HTTPS 적용은 이제 선택이 아닌 필수예요. 하지만 매번 인증서를 수동으로 발급받고 Secret 객체로 만들어 넣어주는 작업은 너무 번거롭고 실수할 가능성도 커요. 그래서 저희는 Cert-manager를 도입했어요. Cert-manager를 설치하면 Let’s Encrypt와 같은 무료 인증기관으로부터 인증서를 자동으로 발급받고, 만료되기 전에 알아서 갱신까지 해줘요.
인그레스 설정 파일에 tls: 섹션을 추가하고, 미리 생성된 Secret 이름을 지정하기만 하면 돼요. 이렇게 하면 클라이언트가 HTTPS로 접속했을 때 인그레스 컨트롤러가 자동으로 인증서를 제시하며 암호화된 통신을 시작하게 돼요. 보안과 관리 편의성을 동시에 잡는 아주 핵심적인 단계라고 할 수 있어요.
STEP 5. 어노테이션(Annotation)을 활용한 고급 기능 설정
기본적인 라우팅이 끝났다면, 이제 실제 서비스 운영에 필요한 미세한 조정(Tuning)이 필요해요. 인그레스는 Annotation이라는 메타데이터를 통해 매우 강력한 기능들을 제공해요. 저희는 서비스 운영 중 다음과 같은 설정들을 자주 활용했어요.
- 업로드 용량 제한:
nginx.ingress.kubernetes.io/proxy-body-size설정을 통해 큰 파일을 업로드할 때 발생하는 413 Payload Too Large 에러를 방지했어요. - 타임아웃 설정: 긴 시간이 걸리는 API 요청이 끊기지 않도록
proxy-read-timeout값을 조절했어요. - CORS 설정: 프론트엔드와 백엔드가 다른 도메인을 사용할 때 발생하는 보안 문제를 해결하기 위해 CORS 관련 어노테이션을 적용했어요.
이러한 설정들은 서비스의 안정성과 직결되므로, 도입 초기부터 서비스의 특성에 맞춰 꼼꼼하게 검토해야 해요. 잘못된 설정 하나가 전체 서비스의 응답 속도를 늦추거나 에러를 유발할 수 있다는 점을 항상 명심해야 합니다.
STEP 6. 모니터링 및 검증 절차 수행
모든 설정이 끝났다면 마지막으로 검증 단계가 남았어요. 설정이 완벽하다고 생각해도 실제 트래픽이 들어오면 예상치 못한 문제가 터질 수 있거든요. 저희는 다음과 같은 세 가지 검증 과정을 거쳤어요.
- 단위 테스트:
curl명령어를 사용하여 각 경로별로 기대하는 응답이 오는지 확인해요. - 부하 테스트:
Locust나k6같은 도구를 사용해 인그레스가 트래픽 급증 시에도 잘 버티는지 테스트해요. - 로그 분석: 인그레스 컨트롤러의 액세스 로그(Access Log)를 실시간으로 모니터링하며 4xx나 5xx 에러가 발생하는 구간이 없는지 살펴봐요.
이 과정을 거치고 나면 비로소 안심하고 실서비스에 인그레스를 적용할 준비가 된 거예요.
자주 하는 실수와 해결법 + FAQ
인그레스를 운영하다 보면 정말 다양한 에러를 마주하게 돼요. 제가 현장에서 직접 겪었던 사례들을 바탕으로, 실수하기 쉬운 포인트들을 정리해 드릴게요. 이 내용만 미리 숙지해도 장애 시간을 절반 이상 줄일 수 있어요.
자주 하는 실수와 해결법
❌ 실수 1: Service 포트 번호 불일치
왜 발생하는가: 인그레스 설정 파일의 service.port.number를 실제 Service 객체에 정의된 포트가 아닌, Pod의 컨테이너 포트로 적는 경우가 많아요.
✅ 해결법: 인그레스는 Pod가 아니라 Service를 바라보고 트래픽을 전달한다는 점을 명심하세요. 반드시 Service의 port 값을 적어야 해요.
❌ 실수 2: Path 매칭 규칙 오류
왜 발생하는가: pathType: Exact를 사용하면서 뒤에 슬래시(/) 유무를 신경 쓰지 않아 404 에러가 발생해요.
✅ 해결법: 일반적인 API 서비스라면 Prefix 방식을 사용하는 것이 훨씬 안전하고 유연해요.
❌ 실수 3: TLS Secret 이름 오타
왜 발생하는가: 인증서를 담고 있는 Secret의 이름을 잘못 입력하면 HTTPS 접속 시 ‘연결할 수 없음’ 에러가 떠요.
✅ 해결법: kubectl get secret 명령어로 정확한 이름을 확인한 뒤 설정 파일에 복사해서 붙여넣으세요.
❌ 실수 4: Ingress Controller 미설치
왜 발생하는가: 인그레스 리소스만 생성하고, 실제로 이를 처리할 엔진(Controller)을 설치하지 않는 경우예요.
✅ 해결법: 리소스를 만들기 전에 반드시 컨트롤러가 클러스터 내에서 정상적으로 구동 중인지 확인하세요.
❌ 실수 5: 과도한 어노테이션 남발
왜 발생하는가: 너무 많은 어노테이션을 넣으면 설정이 꼬이거나 예상치 못한 동작을 할 수 있어요.
✅ 해결법: 꼭 필요한 기능만 최소한으로 적용하고, 변경 시에는 반드시 테스트 환경에서 먼저 검증하세요.
자주 묻는 질문
Q. 인그레스 하나로 여러 개의 도메인을 운영할 수 있나요?
네, 당연히 가능해요! 인그레스 리소스의 host 필드에 서로 다른 도메인 이름을 적어주면, 하나의 인그레스 컨트롤러가 여러 도메인의 트래픽을 각각의 서비스로 분산해 줄 수 있어요.
Q. API 서버의 요청 용량이 너무 커서 에러가 나는데 어떻게 하나요?
대부분 NGINX의 기본 업로드 제한 때문이에요. 어노테이션에 nginx.ingress.kubernetes.io/proxy-body-size를 추가하고 원하는 용량(예: 50m)을 지정해 주면 해결돼요.
Q. 인증서 갱신을 자동으로 할 수 있는 방법이 있나요?
가장 추천하는 방법은 Cert-manager를 사용하는 것이에요. Let’s Encrypt와 연동하면 인증서 발급부터 갱신까지 모든 과정을 자동화할 수 있어서 매우 편리해요.
Q. 인그레스 컨트롤러를 교체하고 싶은데 서비스 중단이 발생하나요?
컨트롤러를 교체하는 과정은 매우 신중해야 해요. 보통은 새로운 컨트롤러를 먼저 띄우고, DNS를 점진적으로 변경하거나 로드밸런서를 교체하는 방식을 사용해야 서비스 중단을 최소화할 수 있어요.
Q. 404 Not Found 에러가 뜨는데 어디를 먼저 봐야 할까요?
먼저 인그레스 리소스의 path 설정과 실제 요청하는 URL이 일치하는지 확인하세요. 그다음 인그레스 컨트롤러의 로그를 살펴보면 어떤 규칙에 걸리지 않았는지 정확히 알 수 있어요.
인그레스 운영을 마치며: 안정적인 서비스를 위한 다음 단계
지금까지 인그레스 운영 사례를 통해 실제 도입 과정과 설정 방법, 그리고 주의할 점들을 자세히 살펴봤어요. 인그레스는 단순히 트래픽을 전달하는 도구를 넘어, 클라우드 비용을 절감하고 서비스 구조를 깔끔하게 유지해 주는 아주 강력한 도구예요. 처음에는 설정할 것이 많아 복잡하게 느껴질 수 있지만, 한 번 제대로 구축해 놓으면 운영의 난이도가 확연히 낮아지는 것을 경험하실 수 있을 거예요.
- 인그레스는 L7 계층에서 경로 및 호스트 기반 라우팅을 수행해요.
- 반드시 인그레스 컨트롤러(NGINX 등)가 먼저 설치되어 있어야 해요.
- 비용 절감을 위해 모든 서비스에 LoadBalancer를 쓰는 대신 인그레스를 활용하세요.
- SSL/TLS 관리는 Cert-manager를 통해 자동화하는 것이 가장 효율적이에요.
- 어노테이션을 활용해 업로드 용량, 타임아웃 등 세부 설정을 최적화하세요.
- 설정 변경 후에는 반드시 컨트롤러 로그와 단위 테스트를 통해 검증하세요.
인그레스 구축을 완료했다면, 이제 다음 단계로 나아갈 차례예요. 단순히 트래픽을 보내는 것을 넘어, 운영의 안정성을 한 단계 더 높여보세요.
- 오늘 할 일: 현재 운영 중인 서비스들의 URL 구조를 다시 한번 정리해 보세요.
- 이번 주 할 일: 테스트 환경에서 Cert-manager를 설치하고 인증서 자동 발급을 시도해 보세요.
- 실행 직전 할 일: 인그레스 컨트롤러의 로그를 확인하는 명령어를 익혀두고, 장애 발생 시 바로 대응할 준비를 하세요.
실습 환경에서 직접 인그레스를 구성해 보시다가 막히는 부분이나 궁금한 점이 생기면 언제든 댓글로 질문을 남겨 주세요. 여러분의 성공적인 쿠버네티스 운영을 진심으로 응원해요!
함께 읽으면 좋은 글: 쿠버네티스 인그레스 기본 개념 정리, 클러스터 구축 입문 가이드
