Kubernetes - 서비스 port 와 ingress

쿠버네티스에서 애플리케이션을 운영하면 끊임없이 변화하는 pod의 IP 주소를 지정하여 트래픽을 라우팅하기가 어렵습니다. 불안정한 pod IP 주소를 직접 사용하는 대신, 쿠버네티스는 서비스 라는 추상화된 개념을 제공하는데요,
이를 통해 애플리케이션에 대한 안정적인 네트워크 접근 지점을 제공하여 pod IP 주소 변경에 영향을 받지 않고 외부/내부 클라이언트가 애플리케이션에 안정적으로 접근할 수 있게 됩니다.

 

그 외에 서비스는 아래 기능을 가집니다.

• 수평 스케일링: 파드의 수를 늘리는 수평 스케일링을 수행하여 로드 밸런싱 역할을 할 수 있습니다.
• 서비스 디스커버리: 애플리케이션 내의 여러 서비스가 서로 통신해야 하는 경우, 각 서비스의 IP 주소를 하드코딩하는 것은 매우 비효율적인데요, 서비스 디스커버리를 통해 내부 DNS 를 사용하여 서로를 동적으로 찾고 연결할 수 있습니다.

쿠버네티스는 다양한 타입의 서비스를 제공합니다. (ClusterIP, NodePort, LoadBalancer)

1. ClusterIP

정의

• Kubernetes에서 기본으로 제공되는 서비스 타입.
• 클러스터 내부에서만 접근 가능한 IP를 할당.
• 외부에서는 직접 접근 불가, 클러스터 내부 통신용.

특징

특징	설명
접근 범위	클러스터 내부
IP	내부 전용 IP 할당
외부 노출	불가
용도	Pod 간 통신, 내부 API 서비스

예시 YAML

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports: # 서비스가 외부나 클러스터에 노출할 포트들
    - port: 80
      targetPort: 8080

• type: ClusterIP → 클러스터 내부에서만 접근 가능.
• selector: app: my-app → 이 레이블이 붙은 Pod를 찾아서 연결.
• ports → 외부(클러스터 내부) 요청 포트 80 → Pod 내부 8080 포트 매핑.
• 외부에서는 접근 불가, 내부 Pod끼리 통신할 때 사용.

사용 사례

• 백엔드 서비스끼리 통신할 때.
• 데이터베이스, 내부 API, 캐시 서버 등 외부 노출이 필요 없는 경우.

---

2. NodePort

정의

• 클러스터 외부에서 노드의 특정 포트(고정 포트)를 통해 서비스에 접근 가능.
• 클러스터의 모든 노드(IP)에서 동일한 포트(30000~32767 범위)가 열림.
• 노드가 사라졌을때 자동으로 다른노드를 통해 접근이 불가능하므로, 자동으로 다른노드에 접근을 하려면 별도의 Loadbalancer가 필요 

특징

특징	설명
접근 범위	클러스터 외부 가능
포트	NodePort 지정 (기본: 30000~32767)
외부 접근	NodeIP:NodePort
장점	외부에서 바로 접근 가능
단점	직접  NodeIP와 port를 알아야 함

예시 YAML

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports: # 서비스가 외부나 클러스터에 노출할 포트들
    - port: 80 # Service 내부 포트 (클러스터 내부에서 다른 Pod나 Service가 접근할 때 사용)
      targetPort: 8080 # Pod 컨테이너 포트
      nodePort: 30080 # 외부 접근 포트

• type: NodePort → 각 노드의 특정 포트로 서비스 노출.

1. nodePort: 30080 → 클러스터 외부에서 노드IP:30036으로 접근 가능. (http://:30080/)
2. NodePort 서비스 → 요청을 Service 내부 포트 80으로 전달
3. Service → targetPort: 8080으로 요청을 연결된 Pod 컨테이너에 전달
4. Pod 컨테이너에서 애플리케이션 처리 후 응답 반환

사용 사례

• 간단한 테스트 환경에서 외부 접근이 필요할 때.
• 로컬 환경(Minikube)에서 외부 접속.

---

3. LoadBalancer

정의

• 클라우드 환경에서 외부 로드밸런서를 자동 생성.
• NodePort + 클라우드 LB 기능을 합친 형태. (NodePort타입 앞단에 Loadbalancer가 붙어서 살아있는 노드를 체크하여 트래픽을 전달)
• 클라우드 제공사(LBaaS) 지원 필요.(로드밸런서는 따로 물리 장비가 필요하므로)

특징

특징	설명
접근 범위	클러스터 외부 가능
IP	공인 IP 할당 가능
외부 접근	도메인 또는 공인 IP로 가능
장점	외부 접속 간편, 클라우드 LB 사용 가능
단점	클라우드 환경 필요, 비용 발생 가능

예시 YAML

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports: # 서비스가 외부나 클러스터에 노출할 포트들
    - port: 80 # 외부(클러스터 내부든 외부든)에서 이 Service에 접근할 때 사용할 포트
      targetPort: 8080 # Pod 내부 컨테이너가 실제로 듣는 포트

 

1. 클라이언트 → Service 포트 80으로 요청
2. Service → 연결된 Pod의 컨테이너 포트 8080으로 요청 전달
3. Pod 컨테이너에서 처리 후 응답 반환

사용 사례

• 외부 사용자에게 서비스 제공.
• 클라우드 환경에서 서비스 공개.

---

즉 정리하면, Kubernetes에서 Kubernetes에서 서비스를 노출하는 방법은 (Pod에 접근하려면) ClusterIP, NodePort, LoadBalancer 을 이용하는 옵션이 있습니다.

 

하지만 이들은 단순 외부 접근용으로 도메인/경로 기반 라우팅, TLS, 단일 진입점 등을 제공하려면 Ingress 가 필요합니다.

예를 들어 만약에 마이크로서비스 환경에서는 각 서비스들마다 로드밸런서를 정의해야 할텐데, 로드밸런서가 여러 개면 비용이 많이 들기 때문에, 하나의 로드밸런서를 통해 특정 url을 기반으로 다른 성격의 서비스들을 라우팅하고 싶을 떼는 어떻게 해야 할까요? 이럴 때 사용하는 것이 Ingress 입니다.

Ingress

정의

• 클러스터 외부 트래픽을 서비스로 라우팅하는 HTTP/HTTPS 레벨의 진입점.
• 여러 서비스에 대한 경로 기반 라우팅 가능. 즉, 여러 서비스에 대해 하나의 진입점(도메인/URL 기반 라우팅) 제공.
• Ingress Controller 필요 (예: NGINX Ingress, Traefik).

특징

1. 단일 진입점 제공

• 여러 서비스가 있을 때 NodePort나 LoadBalancer를 각각 만들면 IP와 포트가 난잡해짐.
• Ingress를 쓰면 하나의 외부 IP로 도메인/경로 기반 라우팅 가능.
  • 예: example.com/api → api-service, example.com/web → web-service

2. TLS/SSL 통합 관리

• HTTPS 인증서를 Ingress에만 설정하면, 여러 서비스에 쉽게 적용 가능.
• 개별 서비스마다 TLS 설정할 필요 없음.

3. 로드밸런싱

• HTTP 요청 레벨에서 부하 분산 가능.
• 세밀한 라우팅 규칙 적용 가능.

4. 클라우드 종속성 제거

• LoadBalancer를 쓰면 클라우드 제공 서비스에 의존하지만, Ingress는 클러스터 내부에서 HTTP 라우팅 처리 가능.
• 여러 환경에서 일관된 방식으로 외부 접근 제어 가능.

실제로 트래픽을 처리하고 라우팅하는 역할을 인그레스 컨트롤러 가 담당합니다. 이들은 인그레스 리소스를 감시하고, 클러스터 외부 요청의 단일 진입점 역할을 하며, Ingress에 정의된 규칙대로 트래픽을 올바른 서비스로 전달하는 핵심 컴포넌트입니다.

라우팅 규칙

• 호스트 기반 라우팅: 호스트 이름을 기반으로 라우팅. ex) example.com -> web-service, api.example.come -> api-service
• 경로 기반 라우팅: URL 경로를 기반으로 트래픽 라우팅. ex) example.com/web -> web-service, example.com/api -> api-service

예시 YAML

• 호스트 기반

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
  name: host-based-ingress
  spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: www.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
  

- 경로 기반
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

사용 사례

• 여러 서비스를 단일 도메인에서 제공할 때.
• SSL 인증서 적용 및 HTTPS 통신.
• 클라우드와 무관하게 HTTP/HTTPS 라우팅 관리.

---

정리

1. ClusterIP

• 클러스터 내부 IP만 부여 → 외부 접근 불가.
• 내부 Pod 간 통신에만 사용. (외부에서 접근하려면 port-forwarding 이나 )

2. NodePort

• 클러스터 노드의 IP + (30000~32767) 범위 포트로 외부 접근 가능.
• 단점: Node IP를 직접 알아야 함 (고정되지 않음), 여러 서비스가 포트 범위를 공유해야 함 → 충돌/제약 많음.

3. LoadBalancer

• 클라우드 로드밸런서를 자동 생성해서 고정된 공인 IP/DNS 제공.
• 내부적으로는 NodePort를 사용하지만, 클라우드 로드밸런서가 앞단에서 그 복잡성을 가려줌.
• 장점: 외부 접근 가능 (ClusterIP의 한계 극복), 고정된 주소 제공 (NodePort의 한계 극복)
• 서비스마다 별도의 IP/DNS가 생김 → 따라서 외부에서 접근하려면 해당 로드밸런서 주소를 알아야 함.

4. Ingress

• 서비스마다 LB 붙이면 IP/DNS가 여러 개 생겨 관리·비용 부담 → 하나의 Ingress 로 여러 서비스 라우팅할 수 있음
  • Client → LoadBalancer → Ingress Controller → ClusterIP Service → Pod