Ingress + ClusterIp 및 Ingress + NodePort
쿠버네티스 환경에서 애플리케이션을 외부로 노출하는 방법은 다양함.
크게 보면 다음과 같은 방식이 있음.
1. Service 타입을 통해 직접 노출 : NodePort, LoadBalancer, (혹은 클러스터 내부 전용) ClusterIP
2. Ingress를 활용하여 여러 서비스를 단일 진입점(도메인/URL/path 등)으로 외부에 노출
인그레스 컨트롤러가 각 애플리케이션 서비스를 바라볼 때, 그 서비스들을 NodePort 형태로 둘 것인가(=Ingress + NodePort), 아니면 ClusterIP 형태로 둘 것인가(=Ingress + ClusterIP)에 대한 선택이라고 볼 수 있음.
결론을 먼저 말하자면, 대부분의 경우 ‘Ingress + ClusterIP’를 사용하는 것이 더 권장됨.
하지만 어떤 환경이냐, 어떤 인프라를 쓰느냐에 따라 NodePort를 써야 하는 경우도 존재함.
Ingress + ClusterIp 동작 방식
애플리케이션 서비스들은 모두 type: ClusterIP로 설정함.
클러스터 내부 IP로만 접근 가능한 Services 뒤에 Ingress Controller가 위치함.
Ingress Controller(예: NGINX, HAProxy, Traefik 등)는 여러 라우팅 규칙(Host 이름, Path 등)에 맞춰 외부에서 들어온 트래픽을 적절한 ClusterIP 서비스로 라우팅함.
외부 사용자는 Ingress Controller가 노출하는 IP(혹은 LoadBalancer IP/도메인)를 통해 접속함.
Ingress + ClusterIp 장점
1. 서비스 노출의 단일화
NodePort처럼 노드 각각의 포트를 개방할 필요 없이, Ingress Controller가 ‘단일 진입점(Entry Point)’ 역할을 담당함.
도메인/서브도메인/URI 패스 기반 라우팅을 손쉽게 설정하여 여러 서비스를 깔끔하게 노출할 수 있음.
2. 환경간 일관성
로컬 개발 환경부터 스테이징/프로덕션까지, 서비스들은 동일하게 ClusterIP 타입만 쓰면 됨.
실제 외부와의 연결은 인그레스/로드밸런서 구성으로 일관되게 처리할 수 있음.
3. 보안 측면
서비스 자체(파드) 포트가 외부에 직접 노출되지 않으므로, Cluster 내에서만 통신이 이루어짐.
유입 지점(인그레스 컨트롤러) 하나에 집중적으로 인증/인가/SSL 인증서 관리/웹 방화벽 등을 적용하기 쉬워짐.
4. Low-level 네트워킹 분산 없이 간결한 구조
Ingress Controller가 L7 레벨에서 트래픽을 라우팅하므로, NodePort처럼 별도 포트 할당 논리를 크게 신경 쓰지 않아도 됨.
Ingress + ClusterIp 단점
1. 추가 컴포넌트(인그레스 컨트롤러) 필수
ClusterIP만 있으면 외부 접근이 불가능하기 때문에, 반드시 Ingress Controller 혹은 별도의 L4/L7 로드밸런서가 필요함.
2. Ingress Controller 구성/운영의 복잡도
운영 환경에 따라 NGINX, HAProxy, Traefik, Istio Gateway 등 여러 컨트롤러 중 선택해야 함.
TLS 설정·규칙 작성·엔드포인트 모니터링 등 세부 설정이 늘어남.
Ingress + NodePort 동작 방식
애플리케이션 서비스들은 type: NodePort로 설정됨.
인그레스 컨트롤러가 NodePort로 노출된 서비스를 라우팅 대상으로 삼음.
외부에서 Ingress Controller를 통해 들어온 트래픽은 NodePort로 열린 포트(각 노드마다 고정된 포트)로 전달됨.
Ingress + NodePort 장점
1. LoadBalancer 없이도 L7 라우팅 가능
클라우드 LoadBalancer를 제공하지 않는 온프렘(온프레미스) 환경이나, 사설망에서 여러 노드에 직접 접근해야 하는 상황일 때 유용할 수 있음.
예컨대 bare-metal Kubernetes 환경에서 Metallb 등의 L4 로드밸런서를 쓰지 않고, NodePort만으로도 외부에서 접근 가능한 포트를 열어놓은 뒤, Ingress Controller를 통해 7계층 트래픽 라우팅을 해결할 수 있음.
2. IPVS/iptables 기반 직접 라우팅 가능
NodePort는 Kubernetes 서비스 메커니즘(IPVS 혹은 iptables)을 직접 활용하므로, 특정 상황에서 트래픽이 더 직관적으로 흐를 수도 있음.
하지만 이 점은 상황별로 다를 수 있음.
Ingress + NodePort 단점
1. 포트 관리의 복잡성
NodePort는 30000~32767 범위 내에서 포트를 할당해야 함.
노드가 여러 개라면 해당 포트가 모든 노드에 열려야 함.
사용자의 방화벽, 혹은 네트워크 정책에 따라 이 범위를 열어야 할 수도 있음.
2. 불필요한 외부 노출 위험
NodePort로 열려있다는 것은 곧 Node 레벨에서 포트가 열려있다는 뜻임.
방화벽이나 네트워크 정책에서 이를 허용하지 않으면 접근이 제한될 수 있지만, 반대로 필요 이상의 노출이 될 위험도 존재함.
3. 클라우드 환경에서의 비효율
AWS, GCP, Azure 등에서는 대체로 LoadBalancer 타입 서비스를 사용하거나, Ingress + ClusterIP를 사용하는 것이 권장됨.
비용, 관리 효율성 측면에서 NodePort를 굳이 사용할 일은 별로 없음.
Ingress + ClusterIp 및 Ingress + NodePort 선택 기준
1. 클라우드 환경(AWS/GCP/Azure 등)에서 일반적인 웹/HTTP(S) 트래픽을 노출
Ingress + ClusterIP 사용을 권장함.
대부분 클라우드 벤더에서는 LoadBalancer 타입 서비스나 Ingress Controller를 쉽게 구성할 수 있음.
각 서비스는 ClusterIP로만 두고, Ingress/LoadBalancer가 외부와의 연결을 담당하는 편이 가장 표준적이고 안정적임.
2. 온프레미스 / Bare-metal 환경에서 L4 로드밸런서가 없는 경우
Ingress + NodePort도 고려해볼 수 있음.
외부 트래픽이 들어올 경로(파이어월 설정, 포트 열기 등)와 Ingress Controller의 NodePort 사이를 직접 연결해야 함.
이 경우에도 Metallb 등 소프트웨어 로드밸런서(L2/L4 수준)를 구축하여 Ingress + ClusterIP를 쓸 수도 있으니, 환경적으로 가능하다면 그쪽이 더 깔끔함.
3. 인증/인가, TLS 종료, WAF, 모니터링 등 공통 처리
인그레스 컨트롤러 하나를 통한 관리를 선호하고, 파드가 위치한 내부 네트워크를 보호하고자 한다면, ClusterIP + Ingress 조합이 유리함.
4. 포트 제약이 심하거나, 특정 포트를 꼭 사용해야 하는 요구사항
NodePort는 지정 가능한 포트 범위가 한정적이므로, 표준 포트(80, 443 등) 외의 특정 포트를 열어야 하는데 충돌 위험이 있다면 오히려 ClusterIP가 나을 수 있음.
Ingress + ClusterIp 및 Ingress + NodePort 정리
1. 대부분의 클라우드 기반 쿠버네티스 환경에서는 ‘Ingress + ClusterIP’ 조합이 표준임.
서비스들은 모두 ClusterIP 형태로 구성하고, Ingress Controller만 외부와 통신하게 만드는 구조가 관리와 보안 측면에서 가장 이상적임.
필요하다면 Ingress Service 자체는 LoadBalancer 타입으로 선언하여(클라우드 벤더의 LB 사용) 외부 IP를 확보하고, 내부 서비스들은 ClusterIP로 유지하는 패턴이 일반적임.
2. 온프레미스 혹은 별도의 사설망 환경에서 외부에 트래픽을 직접 노출할 수 있는 L4 로드밸런서가 없거나, 다른 네트워크 제약이 있을 때 NodePort를 쓰게 될 수 있음.
이 경우 Ingress Controller가 NodePort로 서비스들을 바라보도록 설정할 수 있으며, 외부 라우팅 환경과 잘 맞춰야 함.
(파이어월, 포트 개방, 라우팅 규칙 등).
하지만 가능하다면 Metallb 같은 소프트웨어 로드밸런서 혹은 하드웨어 L4 LB를 구성해서 ClusterIP와 Ingress를 쓰는 편이 더욱 관리가 편하고 확장성도 좋음.
정리하자면, “Ingress + ClusterIP”가 더 권장됨.
NodePort는 온프렘 환경이나 특수 요구사항이 있을 때 한정적으로 사용함.
이외에는 관리나 보안, 확장성, 유지보수 측면에서 Ingress + ClusterIP가 더 깔끔함.
'Operating System > Kubernetes' 카테고리의 다른 글
[Kubernetes] Jupyterhub 개념 (0) | 2024.12.28 |
---|---|
[Kubernetes] 쿠버네티스에서 서비스 메쉬 개념 (1) | 2024.12.28 |
[Kubernetes] CoreDNS 개념 (0) | 2024.12.27 |
[Kubernetes] NodeSelector 개념 (0) | 2024.12.27 |
[Kubernetes] Ingress Controller (0) | 2024.12.27 |