infra

로컬 쿠버네티스 실습 ③: Ingress로 외부 접근과 라우팅 흐름 이해하기

mirabo01 2026. 2. 15. 09:56

로컬 쿠버네티스 실습 ③ Ingress로 외부 접근 구조 만들기

앞선 실습에서는
Deployment, Service, ConfigMap, 리소스 설정까지 적용해
운영에 가까운 내부 구조를 만들었다.

이번 단계에서는 그 서비스에
외부에서 접근할 수 있는 진입점을 붙여본다.
즉, Ingress를 통해 요청이 어떻게 들어오는지를 직접 확인하는 것이 목표다.

왜 Service만으로는 부족할까

이전 실습에서도 Service를 통해 Pod 접근은 가능했다.
하지만 구조적으로 한계가 있다.

  • 서비스마다 포트를 따로 열어야 한다
  • 도메인 기반 분기가 어렵다
  • HTTPS 처리를 Service 단에서 하기 까다롭다

운영 환경에서는 보통
Ingress 하나를 공통 진입점으로 두고,
그 뒤에서 여러 Service로 트래픽을 나눈다.

Ingress는 “외부 요청을 내부 서비스로 연결하는 관문”이다.

Ingress 구조를 먼저 그려보자

Ingress를 이해할 때는
리소스 정의보다 흐름을 먼저 보는 게 좋다.

요청 흐름은 다음과 같다.

  1. 외부 요청 (도메인 또는 URL)
  2. Ingress Controller
  3. Ingress 규칙 확인
  4. Service로 전달
  5. Pod로 전달

여기서 핵심은
Ingress 리소스와 Ingress Controller는 다르다는 점이다.

로컬 환경에서 Ingress를 쓰기 위한 전제

Ingress는 정의만 만든다고 바로 동작하지 않는다.
반드시 Ingress Controller가 필요하다.

로컬 환경에서는 보통 다음 조합을 쓴다.

  • minikube + nginx ingress addon
  • kind + ingress-nginx

이번 실습의 목적은
“어떤 컨트롤러를 쓰느냐”가 아니라
Ingress가 어떻게 동작하는지를 이해하는 것이다.

1. Ingress Controller가 있는지 확인

먼저 클러스터에 Ingress Controller가 떠 있는지 확인한다.

kubectl get pod -n ingress-nginx

Pod가 보인다면
Ingress 요청을 처리할 준비는 끝난 상태다.

실무에서도 Ingress가 안 될 때
가장 먼저 확인하는 포인트가 바로 이 부분이다.

2. Ingress 리소스는 무엇을 정의할까

Ingress 리소스는 생각보다 단순하다.

  • 어떤 도메인/경로로 들어온 요청을
  • 어떤 Service로 보낼지

즉, 라우팅 규칙 모음이다.

Ingress는 Pod를 직접 바라보지 않는다.
항상 Service 단위로만 연결한다는 점을 기억해야 한다.

3. 도메인 기반 접근을 로컬에서 흉내 내기

운영 환경에서는 실제 도메인을 쓰지만,
로컬에서는 보통 다음 방식으로 테스트한다.

  • /etc/hosts 파일에 도메인 매핑
  • Ingress 주소를 로컬 IP로 연결

이 과정을 거치면
브라우저나 curl에서 도메인 기반 접근이 가능해진다.

이 실습의 목적은
DNS 설정이 아니라 Ingress 흐름 체감이다.

4. Ingress를 통해 요청 보내보기

Ingress까지 연결되면
이제 요청 흐름은 다음처럼 바뀐다.

  • 직접 Service 접근 ❌
  • Ingress → Service → Pod ⭕
curl http://example.local

이 한 번의 요청으로 다음을 확인할 수 있다.

  • Ingress가 요청을 받는지
  • 규칙에 맞는 Service로 전달되는지
  • Pod 로그가 정상적으로 찍히는지
kubectl logs <pod-name>

Service를 거칠 때와
Ingress를 거칠 때 로그 흐름은 동일하다.
달라지는 건 진입 지점뿐이다.

5. 경로 기반 라우팅도 한 번 더 확인해보자

Ingress의 장점 중 하나는
URL 경로 기반 분기다.

예를 들어,

  • /api → backend 서비스
  • /admin → admin 서비스

같은 구조를 만들 수 있다.

이 구조를 직접 만들어보면,
“왜 Service 위에 Ingress를 두는지”가 명확해진다.

6. Ingress 실습에서 자주 막히는 지점

로컬 실습에서 특히 자주 겪는 문제는 다음이다.

  • Ingress 리소스는 있는데 접속이 안 됨
    → Ingress Controller 없음
  • Service는 정상인데 Ingress만 안 됨
    → 규칙 host/path 불일치
  • 브라우저에서는 안 되고 curl만 됨
    → hosts 설정 문제

이런 문제는 대부분
Ingress → Service → Pod 흐름을 나눠서 확인하면 해결된다.

Service와 Ingress 역할 다시 정리

실습을 한 번 거치고 나면
두 리소스의 역할이 꽤 분명해진다.

  • Service
    • Pod 집합에 대한 접근 지점
    • 내부 통신의 기준
  • Ingress
    • 외부 요청의 진입점
    • 라우팅과 TLS 담당

Ingress는 Service를 대체하지 않는다.
항상 Service 위에서만 동작한다.

정리하며

이번 글에서는
로컬 쿠버네티스 실습 환경에 Ingress를 추가해 외부 접근 구조를 만들어봤다.

  • Ingress는 규칙이고, 실제 동작은 Controller가 한다
  • 외부 요청은 Ingress → Service → Pod 흐름으로 전달된다
  • 도메인/경로 기반 라우팅의 역할이 분명해진다

이 실습까지 마치면,
쿠버네티스에서 애플리케이션이 외부와 만나는 전체 흐름을
처음부터 끝까지 한 번 직접 경험한 셈이다.

다음 글에서는
이 실습들을 바탕으로,
“쿠버네티스를 언제 도입하는 게 맞는지”,
그리고 도입 전 반드시 고민해야 할 포인트들을 정리해볼 예정이다.