[쿠버네티스] Kubernetes Service 종류(ClusterIP, NodePort, LoadBalancer, ExternalName, Headless Service)

 

Kubernetes Service

서비스(Service)의 역할:
쿠버네티스에서는 파드가 생성되고 소멸되기 때문에, 클라이언트(예: 다른 파드나 내부 컴포넌트)가 안정적으로 애플리케이션에 접근할 수 있도록 서비스 객체를 사용합니다. 서비스는 여러 파드의 집합에 대한 단일 접근점을 제공하여 로드 밸런싱 및 장애 복구를 돕습니다.

 

Service 타입

• ClusterIP (기본값):
  클러스터 내부에서만 접근 가능한 가상 IP를 할당합니다. 외부에서 직접 접근은 불가능하며, 내부 서비스 간 통신에 주로 사용됩니다.
• NodePort:
  각 노드의 동일한 포트를 열어 외부에서 접근할 수 있도록 합니다. NodeIP:NodePort를 통해 클러스터 외부에서도 서비스를 호출할 수 있습니다.
• LoadBalancer:
  클라우드 환경에서 주로 사용되며, 클라우드 제공업체의 로드 밸런서를 이용해 외부 트래픽을 Service로 라우팅합니다.
• ExternalName:
  DNS 이름을 사용하여 외부 서비스에 대한 접근을 설정합니다. 클러스터 내부에서 DNS 조회 시 지정한 외부 이름으로 매핑됩니다.
• Headless Service:
  ClusterIP 없이 파드의 직접적인 접근이 필요한 경우 사용합니다. 파드의 DNS 이름을 직접 노출하여, 서비스 디스커버리나 상태 저장 애플리케이션에 유용합니다.

---

ClusterIP (기본형태)

ClusterIP는 클러스터 내부 전용 IP 주소를 서비스에 할당합니다. 이 IP는 클러스터의 내부 네트워크(예를 들어, 같은 쿠버네티스 클러스터 내의 다른 파드)에서만 접근할 수 있습니다.
외부 사용자가 직접 접근할 수 없으므로, 보안과 네트워크 분리를 위한 내부 통신 채널을 제공합니다.

 

장점

• 보안성:
  외부 접근을 차단하므로 클러스터 내부 통신에 대한 보안을 강화할 수 있습니다. 외부에서 접근할 필요가 없는 내부 서비스에 적합합니다.
• DNS 연동:
  쿠버네티스 클러스터 내 DNS 서비스(예: CoreDNS)를 통해 서비스 이름으로 접근할 수 있으므로, 연결 관리가 용이합니다.

 

 

사용 사례

• 마이크로서비스 아키텍처:
  내부의 여러 마이크로서비스가 서로 호출해야 하는 경우, ClusterIP를 사용하여 안정적이고 추상화된 통신 경로를 구성할 수 있습니다.

생성 예시

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  selector:
    app: my-app
  type: ClusterIP
  ports:
    - port: 80         # 서비스가 노출할 포트
      targetPort: 8080 # 백엔드 파드의 포트

---

NodePort

• 외부 접근 제공:
  NodePort는 클러스터 내부의 서비스를 외부로 노출하여, 클러스터 외부의 클라이언트도 서비스에 접근할 수 있게 합니다.
  예를 들어, 인터넷이나 다른 네트워크에서 오는 요청을 처리할 수 있습니다.
• 서비스 생성 시 타입 지정:
  서비스 객체를 생성할 때 type: NodePort로 지정하면, 쿠버네티스는 서비스에 할당된 ClusterIP 외에도 각 노드의 고정 포트를 노출합니다.
  이 포트를 통해 외부 트래픽이 내부 서비스로 라우팅됩니다.

 

 

 

NodePort의 장단점

장점

• 외부 노출의 단순성:
  클라우드 로드 밸런서 없이도 비교적 간단하게 외부 접근을 설정할 수 있습니다.
• 클러스터 IP와 연계:
  내부 서비스는 여전히 ClusterIP로 관리되므로, 내부 통신과 외부 접근 모두를 하나의 서비스 객체로 처리할 수 있습니다.

단점

• 제한된 포트 범위:
  NodePort는 제한된 포트 범위(일반적으로 30000~32767)를 사용하므로, 다수의 서비스를 외부로 노출할 경우 포트 번호 충돌이나 관리의 어려움이 발생할 수 있습니다.
• 보안 및 접근 제어:
  클러스터의 모든 노드에서 해당 포트를 열어두게 되므로, 방화벽 설정이나 네트워크 정책을 통해 외부 접근을 안전하게 제어할 필요가 있습니다.
• 직접 노출된 노드 IP:
  외부 사용자가 노드의 IP 주소와 NodePort를 통해 서비스에 접근할 수 있으므로, 노드의 IP 정보가 노출되는 단점이 있습니다.

사용 사례

• 개발 및 테스트 환경:
  외부 트래픽이 적거나 개발 환경에서 간단하게 서비스를 테스트하고자 할 때 NodePort를 사용합니다.
• 소규모 또는 단순한 외부 서비스 제공:
  복잡한 로드밸런서를 구성하기 어려운 소규모 환경이나 간단한 외부 애플리케이션 노출에 적합합니다.
• 클러스터 외부와의 통신:
  예를 들어, 외부 API 게이트웨이나, 외부 애플리케이션이 클러스터 내부의 서비스를 직접 호출해야 하는 경우 NodePort 방식을 사용할 수 있습니다.

 

생성 예시

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  selector:
    app: my-app
  type: NodePort
  ports:
    - port: 80           # 내부 ClusterIP의 포트
      targetPort: 8080   # 백엔드 파드의 포트
      nodePort: 31000    # 각 노드에서 열릴 포트 (옵션: 생략 시 자동 할당)

 

---

LoadBalancer

LoadBalancer는 별도의 외부 로드 밸런서를 제공하는 클라우드(AWS, Azure, GCP 등) 환경을 고려하여, 해당 로드밸런서를 클러스터의 서비스로 프로비저닝할 수 있는 LoadBalancer 유형도 제공한다.

 

위의 NodePort방식은 노드가 사라졌을 때 자동으로 다른 노드를 통해 접근이 불가능하다는 단점이 있다. 예를 들어, 3개의 노드가 있다면 3개 중에 아무 노드로 접근해도 NodePort로 연결할 수 있지만 어떤 노드가 살아있는 지는 알 수가 없다.

 

자동으로 살아있는 노드에 접근하기 위해 모든 노드를 바라보는 Load Balancer가 필요하다. 브라우저는 NodePort에 직접 요청을 보내는 것이 아니라 Load Balancer에 요청하고 Load Balancer가 알아서 살아있는 노드에 접근하면 Node Port의 단점을 없앨 수 있다.

 

장점

• 외부 접근의 용이성:
  클라우드 기반 로드밸런서를 통해 외부 사용자들이 서비스에 쉽게 접근할 수 있습니다. 별도의 복잡한 네트워크 설정 없이도 외부 IP를 할당받아 트래픽을 직접 받을 수 있습니다.
• 자동 관리:
  쿠버네티스와 클라우드 제공자가 연동되어 로드밸런서의 생성, 유지, 그리고 업데이트가 자동으로 이루어집니다. 이는 운영 부담을 크게 줄여줍니다.
• 확장성:
  클라우드 로드밸런서는 트래픽 부하에 따라 자동 확장 기능이나 여러 분산된 엔드포인트로 트래픽을 분산하는 기능을 제공하여 높은 가용성과 성능을 보장합니다.

 

사용 사례

• 프로덕션 환경:
  인터넷 사용자를 대상으로 하는 웹 서비스나 API 서버에서 외부에 서비스를 노출할 때 주로 사용됩니다.
• 클라우드 네이티브 애플리케이션:
  AWS, GCP, Azure와 같이 로드밸런서 서비스를 제공하는 클라우드 환경에서 자동 프로비저닝 및 관리를 통해 효율적인 외부 접근을 구현할 수 있습니다.

 

생성 예시

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  selector:
    app: my-app
  type: LoadBalancer
  ports:
    - port: 80         # 클라이언트가 접근할 포트
      targetPort: 8080 # 내부 파드의 포트

 

 

---

ExternalName

• DNS 이름 매핑:
  ExternalName 서비스는 서비스 객체를 생성할 때 spec.externalName 필드에 외부 도메인 이름을 지정합니다.
  클러스터 내부에서는 이 서비스의 DNS 이름(예: my-service.namespace.svc.cluster.local)이 실제로는 externalName에 지정된 도메인으로 CNAME 레코드에 의해 매핑됩니다.
• 프록시 역할 없음:
  다른 서비스 타입(NodePort, ClusterIP, LoadBalancer)과 달리 ExternalName은 클러스터 내부의 네트워크로 요청을 전달하는 역할을 하지 않습니다.
  대신, 클러스터 내의 클라이언트가 ExternalName 서비스의 이름을 조회할 때, DNS 서버는 해당 이름을 외부의 실제 도메인 이름으로 반환합니다.

 

 

장점

• 간단한 외부 서비스 참조:
  클러스터 내부에서 외부 리소스를 사용할 때, 복잡한 설정 없이 단순히 서비스 이름을 통해 해당 리소스를 참조할 수 있습니다.
• 설정의 일관성:
  클러스터 내에서 사용하는 다른 서비스와 동일한 방식으로 외부 서비스를 호출할 수 있으므로, 코드나 구성의 일관성을 유지할 수 있습니다.
• 프로토콜 독립성:
  DNS 기반이기 때문에 HTTP, MySQL 등 어떤 프로토콜을 사용할 때도 동작할 수 있습니다.

 

 

사용 사례

• 외부 데이터베이스 연결:
  클러스터 내부 애플리케이션이 외부에 존재하는 데이터베이스에 접근해야 할 때, ExternalName 서비스를 사용하여 데이터베이스의 도메인 이름을 매핑할 수 있습니다.
• 클러스터 외부 API 호출:
  외부 API를 호출할 때도 내부에서 서비스 이름을 사용하면, 도메인 네임 변경이나 다른 네트워크 이슈에 유연하게 대응할 수 있습니다.
• 하이브리드 클라우드 구성:
  일부 컴포넌트가 클러스터 외부에 존재하는 경우, ExternalName을 통해 내부에서 해당 리소스를 쉽게 접근할 수 있습니다.

 

 

생성 예시

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName
  externalName: api.external-example.com

 

 

---

Headless Service

쿠버네티스의 Headless Service는 일반적인 서비스와 달리 클러스터IP를 할당하지 않는 서비스 유형입니다. 즉, 클러스터 내부의 가상 IP가 없는 대신, DNS 조회 시 백엔드 파드들의 개별 IP 주소나 SRV 레코드를 반환하게 되어 클라이언트가 각 파드에 직접 연결할 수 있도록 해줍니다.

• 가상 IP 미할당:
  일반적인 ClusterIP 서비스는 단일 가상 IP를 할당받아 클러스터 내부에서 요청을 받아 로드 밸런싱을 수행합니다.
  반면, Headless Service는 spec.clusterIP 필드를 None으로 설정하여 가상 IP를 사용하지 않습니다.
• 직접 DNS 기반 연결:
  DNS 조회 시, Headless Service는 백엔드 파드들의 실제 IP 주소(또는 SRV 레코드)를 반환합니다.
  이를 통해 클라이언트는 서비스 이름으로 조회한 결과를 기반으로 직접 파드와 통신할 수 있습니다.

 

장점

• 직접적인 파드 접근:
  클라이언트가 백엔드 파드의 IP 주소를 직접 받아올 수 있어,
  StatefulSet이나 분산 시스템에서 고유한 네트워크 식별을 쉽게 구현할 수 있습니다.
• 유연한 네트워킹 구성:
  커스텀 로드 밸런싱 또는 서비스 디스커버리를 클라이언트 측에서 구현할 수 있어,
  보다 세밀한 네트워크 제어가 가능합니다.

 

 

사용 사례

• Stateful 애플리케이션:
  데이터베이스(예: Cassandra, Zookeeper), 메시지 큐 등과 같이 파드 간에 고유한 식별이 필요한 경우
  Headless Service를 사용하여 각 파드에 개별로 접근할 수 있습니다.
  이를 통해 클러스터 내 파드의 정적인 네트워킹 구성이 가능해집니다.
• 서비스 디스커버리:
  클라이언트 애플리케이션이 각 파드의 IP 주소를 직접 알고 싶을 때 유용합니다.
  예를 들어, 분산 시스템에서는 각 노드의 정보가 필요할 경우 Headless Service를 활용하여
  DNS 조회로 모든 백엔드 엔드포인트의 리스트를 받아올 수 있습니다.
• 커스텀 로드 밸런싱:
  기본적인 로드 밸런싱 대신, 애플리케이션이나 클라이언트 측에서 사용자 정의 방식으로
  로드 밸런싱을 구현하고자 할 때 Headless Service를 이용할 수 있습니다.

 

생성 예시

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None      # 가상 IP를 생성하지 않음
  selector:
    app: my-app
  ports:
    - port: 80         # 클라이언트가 접근할 포트
      targetPort: 8080 # 백엔드 파드의 포트

 

 

---

참고:

https://bumday.tistory.com/165