이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

쿠버네티스 서비스(Service)는 파드 집합에 대한 안정적인 접근 지점을 제공하여 파드 IP의 비영속성 문제를 해결한다고 앞서 설명드렸습니다. 그런데 이 ‘접근 지점’이라는 것이 항상 동일한 방식으로 제공되는 것은 아닙니다. 서비스가 어떤 범위에서, 어떤 방식으로 노출될 것인지에 따라 쿠버네티스는 여러 가지 서비스 타입(Type)을 제공하며, 사용자는 자신의 요구사항에 맞는 타입을 선택하여 서비스를 정의할 수 있습니다.

마치 우리가 특정 장소로 가는 방법을 선택할 때, 내부 도로만 이용할지, 고속도로를 탈지, 아니면 비행기를 이용할지를 결정하는 것과 유사합니다. 각 서비스 타입은 서로 다른 특징과 사용 사례를 가지고 있으므로, 이들을 정확히 이해하는 것은 애플리케이션을 올바르게 노출하고 외부와 통신하는 데 매우 중요합니다.

쿠버네티스 서비스 명세(spec) 내의 type 필드를 통해 원하는 서비스 타입을 지정할 수 있으며, 주로 사용되는 네 가지 주요 서비스 타입은 다음과 같습니다. 이제 각 타입이 어떤 특징을 가지고 있으며 어떤 상황에 적합한지 자세히 살펴보겠습니다.

ClusterIP는 쿠버네티스 서비스의 기본 타입입니다. 만약 서비스 YAML 파일에서 spec.type 필드를 명시적으로 설정하지 않으면, 쿠버네티스는 해당 서비스를 ClusterIP 타입으로 간주합니다.

ClusterIP 타입의 서비스는 이름에서 알 수 있듯이, 오직 클러스터 내부에서만 접근 가능한 고유한 가상 IP 주소(클러스터 IP)를 할당받습니다. 이 클러스터 IP는 서비스가 존재하는 동안에는 변경되지 않는 안정적인 주소이며, 클러스터 내의 다른 파드나 애플리케이션들이 이 IP 주소와 서비스 포트를 사용하여 해당 서비스에 요청을 보낼 수 있습니다.

주요 특징 및 동작 방식:

1. 내부 통신 전용: ClusterIP는 클러스터 외부 네트워크에서는 직접 접근할 수 없습니다. 오로지 클러스터 내부의 다른 파드들 간의 통신, 예를 들어 마이크로서비스 아키텍처에서 프론트엔드 서비스가 백엔드 서비스를 호출하거나, 여러 백엔드 서비스들이 서로 데이터를 주고받는 용도로 사용됩니다.
2. 가상 IP 할당: 서비스가 생성되면, 쿠버네티스 컨트롤 플레인(API 서버)은 미리 정의된 서비스 IP 주소 대역(Service CIDR)에서 사용 가능한 IP 주소를 이 서비스에 할당합니다. 이 IP 주소는 실제 네트워크 인터페이스에 바인딩되는 것이 아니라, 각 노드에서 실행되는 kube-proxy 컴포넌트에 의해 관리되는 가상 IP입니다.
3. kube-proxy의 역할: 각 노드의 kube-proxy는 API 서버를 통해 서비스와 해당 서비스에 연결된 엔드포인트(실제 파드들의 IP와 포트) 정보를 감시합니다. 그리고 ClusterIP로 들어오는 트래픽을 실제 백엔드 파드들 중 하나로 전달(로드 밸런싱)하기 위한 네트워킹 규칙(예: iptables 규칙, IPVS 규칙)을 해당 노드에 설정합니다. 따라서 클러스터 내의 어떤 노드에서든 ClusterIP로 요청을 보내면, kube-proxy에 의해 적절한 백엔드 파드로 라우팅됩니다.
4. DNS 통합: ClusterIP 타입의 서비스가 생성되면, 쿠버네티스 내부 DNS 시스템(예: CoreDNS)은 해당 서비스의 이름으로 DNS A 레코드(또는 SRV 레코드)를 자동으로 생성합니다. 예를 들어, my-service라는 이름의 서비스가 my-namespace 네임스페이스에 생성되었다면, 클러스터 내의 다른 파드들은 my-service.my-namespace.svc.cluster.local (또는 같은 네임스페이스 내에서는 my-service만으로도)이라는 DNS 이름을 사용하여 이 서비스의 클러스터 IP를 조회하고 접근할 수 있습니다. IP 주소를 직접 사용하는 것보다 이 DNS 이름을 사용하는 것이 훨씬 더 권장되는 방식입니다.

사용 사례:

• 클러스터 내부에서 실행되는 마이크로서비스 간의 통신 (예: 웹 티어에서 API 티어로, API 티어에서 데이터베이스 티어로 호출)
• 내부적으로만 사용되는 관리 도구나 대시보드 노출
• 스테이트풀셋과 함께 사용되는 헤드리스 서비스(Headless Service, clusterIP: None으로 설정)의 기반 (이 경우, 서비스 IP는 없지만 각 파드에 대한 DNS 레코드가 생성됨)

ClusterIP는 쿠버네티스 서비스의 가장 기본적인 형태이며, 대부분의 내부 통신 요구사항을 만족시키는 핵심적인 구성 요소입니다.

ClusterIP 타입의 서비스는 클러스터 내부에서만 접근 가능하므로, 만약 클러스터 외부의 클라이언트(예: 개발자의 로컬 머신, 외부 시스템)가 이 서비스에 접근해야 한다면 다른 방법이 필요합니다. 이때 사용할 수 있는 옵션 중 하나가 바로 NodePort 타입의 서비스입니다.

NodePort 타입의 서비스는 ClusterIP 타입의 모든 기능을 포함하면서, 추가적으로 클러스터 내의 모든 워커 노드의 특정 고정 포트(NodePort)를 통해 외부에서 서비스에 접근할 수 있도록 경로를 열어줍니다. 즉, 외부 클라이언트는 <어떤 노드의 IP 주소>:<NodePort> 형태로 서비스에 접속할 수 있게 됩니다.

주요 특징 및 동작 방식:

1. ClusterIP 자동 생성: NodePort 타입으로 서비스를 생성하면, 쿠버네티스는 먼저 해당 서비스에 대한 ClusterIP를 자동으로 할당합니다. (즉, NodePort 서비스는 내부적으로 ClusterIP 서비스를 확장한 형태입니다.)
2. 모든 노드에 포트 개방: 그 다음, 쿠버네티스는 클러스터 내의 모든 워커 노드(그리고 때로는 마스터 노드에도)에 특정 포트 번호(이것이 바로 NodePort입니다)를 할당하고, 이 포트로 들어오는 외부 트래픽을 해당 서비스의 ClusterIP와 서비스 포트로 전달하도록 kube-proxy에 의해 네트워킹 규칙을 설정합니다.
3. NodePort 범위: 사용자가 NodePort를 직접 지정할 수도 있지만, 보통은 쿠버네티스가 미리 정해진 범위(기본값: 30000-32767) 내에서 사용 가능한 포트를 자동으로 할당합니다. 이 범위는 클러스터 구성 시 변경할 수 있습니다.
4. 외부 접근 경로: 외부 클라이언트는 클러스터 내 어떤 노드의 IP 주소를 사용하든 (예: <NodeIP1>:<NodePort>, <NodeIP2>:<NodePort> 등), 동일한 NodePort 번호를 통해 해당 서비스에 접근할 수 있습니다. 요청을 받은 노드는 해당 트래픽을 서비스의 ClusterIP로 전달하고, 이는 다시 적절한 백엔드 파드로 로드 밸런싱됩니다.

사용 사례:

• 개발 또는 테스트 목적으로 클러스터 외부에서 애플리케이션에 빠르게 접근해야 할 때 (예: 로컬 머신에서 테스트)
• 외부 로드 밸런서가 아직 준비되지 않았거나 사용할 수 없는 환경에서 서비스를 임시로 노출해야 할 때
• 클라우드 환경이 아닌 온프레미스 환경에서 외부 로드 밸런서 없이 서비스를 노출하고자 할 때 (이 경우, 외부에서 노드 IP로 직접 접근 가능해야 함)
• 상태를 가진 애플리케이션(예: 특정 게임 서버)의 각 인스턴스에 직접 고정 포트로 접근해야 하는 특수한 경우 (일반적이지는 않음)

고려 사항:

• NodePort는 각 노드의 IP를 직접 사용하므로, 만약 특정 노드에 장애가 발생하면 해당 노드 IP를 통한 접근은 실패할 수 있습니다. 따라서 고가용성을 위해서는 NodePort 앞에 별도의 외부 로드 밸런서를 구성하는 것이 일반적입니다.
• 노드에 직접 포트를 열기 때문에 보안상 취약점이 될 수 있습니다. 방화벽 규칙 등을 통해 필요한 접근만 허용하도록 주의해야 합니다.
• 사용 가능한 포트 범위가 제한적입니다.

NodePort는 서비스를 외부로 노출하는 비교적 간단한 방법이지만, 프로덕션 환경에서는 보통 더 강력하고 유연한 LoadBalancer 타입이나 인그레스(Ingress)를 사용하는 것이 권장됩니다.

클라우드 환경(예: AWS, GCP, Azure)에서 쿠버네티스 클러스터를 운영하고 있다면, 서비스를 외부 인터넷에 안정적으로 노출하는 가장 일반적이고 권장되는 방법은 LoadBalancer 타입의 서비스를 사용하는 것입니다.

LoadBalancer 타입의 서비스는 NodePort 타입의 기능을 포함하면서, 추가적으로 클라우드 제공업체가 제공하는 외부 로드 밸런서(External Load Balancer)를 자동으로 프로비저닝하고 이 로드 밸런서를 통해 서비스에 접근할 수 있도록 구성합니다. 클라우드 로드 밸런서는 고유한 공인 IP 주소를 가지며, 외부 인터넷으로부터 들어오는 트래픽을 서비스의 NodePort(또는 다른 내부 경로)를 통해 클러스터 내의 워커 노드들로 분산시켜 줍니다.

주요 특징 및 동작 방식:

1. NodePort 및 ClusterIP 자동 생성: LoadBalancer 타입으로 서비스를 생성하면, 쿠버네티스는 먼저 해당 서비스에 대한 ClusterIP와 NodePort를 자동으로 생성하고 구성합니다. (즉, LoadBalancer 서비스는 내부적으로 NodePort 서비스를 확장한 형태입니다.)
2. 클라우드 로드밸런서 프로비저닝: 쿠버네티스 클러스터가 클라우드 제공업체의 환경에서 실행 중이고, 해당 클라우드 제공업체의 컨트롤러 매니저(cloud controller manager)가 올바르게 구성되어 있다면, 서비스 생성 요청을 감지하고 클라우드 플랫폼에 외부 로드 밸런서 생성을 요청합니다.
3. 외부 IP 주소 할당: 클라우드 로드 밸런서가 성공적으로 생성되면, 고유한 공인 IP 주소(External IP)가 할당됩니다. 이 IP 주소는 서비스의 status.loadBalancer.ingress 필드에 기록되며, kubectl get service <서비스이름> 명령을 통해 확인할 수 있습니다.
4. 트래픽 라우팅: 외부 클라이언트는 이 할당된 외부 IP 주소를 사용하여 서비스에 접근합니다. 클라우드 로드 밸런서는 수신된 트래픽을 클러스터 내 워커 노드들의 해당 서비스 NodePort로 전달하고, 이는 다시 서비스의 ClusterIP를 거쳐 최종적으로 백엔드 파드들로 로드 밸런싱됩니다.

사용 사례:

• 클라우드 환경(AWS, GCP, Azure, DigitalOcean 등)에서 실행되는 쿠버네티스 애플리케이션을 외부 인터넷에 안정적으로 노출하고 싶을 때 가장 표준적인 방법입니다.
• 외부 사용자에게 고가용성과 확장성을 갖춘 단일 진입점(entry point)을 제공하고자 할 때 사용합니다.

로컬 환경 또는 온프레미스 환경에서의 LoadBalancer 타입:

만약 클라우드 환경이 아닌 로컬 개발 환경(Minikube, kind 등)이나 직접 구축한 온프레미스 쿠버네티스 클러스터에서 LoadBalancer 타입의 서비스를 생성하면, 기본적으로는 외부 로드 밸런서가 자동으로 프로비저닝되지 않으므로 EXTERNAL-IP가 <pending> 상태로 남아있게 됩니다.

이러한 환경에서 LoadBalancer 타입의 서비스를 실제로 동작시키기 위해서는 MetalLB와 같은 베어메탈 로드 밸런서 구현체를 클러스터에 설치해야 합니다. MetalLB는 미리 정의된 IP 주소 풀에서 외부 IP를 할당하고, ARP(Address Resolution Protocol)나 BGP(Border Gateway Protocol)를 사용하여 해당 IP로의 트래픽을 클러스터 노드로 라우팅하는 역할을 합니다. 이를 통해 온프레미스 환경에서도 클라우드와 유사한 LoadBalancer 서비스 경험을 얻을 수 있습니다. (Minikube의 경우 minikube tunnel 명령을 통해 임시로 LoadBalancer 서비스를 테스트할 수도 있습니다.)

LoadBalancer 타입은 서비스를 외부에 노출하는 가장 강력하고 편리한 방법 중 하나이지만, 클라우드 제공업체의 로드 밸런서 사용에 따른 비용이 발생할 수 있다는 점을 고려해야 합니다.

지금까지 설명한 ClusterIP, NodePort, LoadBalancer 타입의 서비스들은 모두 쿠버네티스 클러스터 내부의 파드들을 대상으로 하는 서비스였습니다. 하지만 때로는 클러스터 외부에 존재하는 기존 서비스 (예: 외부 데이터베이스, 외부 API, 다른 클라우드 서비스 등)를 마치 클러스터 내부의 서비스처럼 동일한 방식으로 참조하고 싶을 때가 있습니다. 이때 유용하게 사용될 수 있는 특별한 서비스 타입이 바로 ExternalName입니다.

ExternalName 타입의 서비스는 앞선 세 가지 타입과는 동작 방식이 매우 다릅니다. 이 타입은 실제로 프록시 역할을 하거나 로드 밸런싱을 수행하지 않습니다. 대신, 서비스의 DNS 이름을 **외부 서비스의 DNS 이름(CNAME 레코드와 유사하게)**으로 단순히 매핑(alias)해주는 역할만 합니다.

주요 특징 및 동작 방식:

1. 셀렉터 없음, 포트 정의 없음: ExternalName 타입의 서비스는 특정 파드를 선택하기 위한 selector를 사용하지 않으며, 서비스 포트(ports 필드)도 정의하지 않습니다. 오직 spec.externalName 필드에 매핑할 외부 서비스의 실제 DNS 이름을 지정합니다.
2. CNAME 매핑: 클러스터 내부 DNS 시스템(예: CoreDNS)은 ExternalName 타입의 서비스 이름(예: my-external-db.my-namespace.svc.cluster.local)에 대한 DNS 요청을 받으면, spec.externalName에 정의된 외부 DNS 이름(예: prod-rds-instance.abcdef123456.us-west-2.rds.amazonaws.com)을 가리키는 CNAME 레코드를 반환합니다. (정확히는, 내부 DNS는 CNAME을 반환하고, 실제 외부 DNS 이름에 대한 A 레코드 조회는 클라이언트의 DNS 리졸버가 이어서 수행하게 됩니다.)
3. 클라이언트의 직접 통신: 결과적으로, 클러스터 내의 파드가 ExternalName 서비스의 DNS 이름을 사용하여 접속을 시도하면, 실제로는 spec.externalName에 지정된 외부 서비스의 IP 주소로 직접 통신하게 됩니다. 쿠버네티스 서비스는 이 과정에서 어떠한 트래픽 중개도 하지 않습니다.

사용 사례:

• 클러스터 외부에서 운영 중인 레거시 시스템이나 관리형 데이터베이스(예: AWS RDS, Google Cloud SQL)를 쿠버네티스 내부 애플리케이션들이 일관된 서비스 이름으로 참조하고 싶을 때 사용합니다.
• 애플리케이션 코드 변경 없이, 외부 서비스의 실제 주소가 변경되더라도 ExternalName 서비스의 externalName 필드만 수정하여 유연하게 대응하고 싶을 때 유용합니다. (애플리케이션은 항상 내부 서비스 이름만 사용)
• 개발 환경에서는 클러스터 내부의 목(mock) 서비스를 사용하고, 프로덕션 환경에서는 실제 외부 서비스를 사용하도록 환경별로 ExternalName 서비스의 대상을 다르게 설정하여 애플리케이션 구성을 관리할 수 있습니다.

고려 사항:

• ExternalName 서비스는 실제 트래픽 라우팅이나 로드 밸런싱 기능을 제공하지 않으므로, 이러한 기능은 외부 서비스 자체에서 제공되거나 별도로 구성되어야 합니다.
• ExternalName에 지정된 외부 DNS 이름이 유효하고 접근 가능한지 확인해야 합니다.

ExternalName은 클러스터 내부와 외부 서비스 간의 경계를 부드럽게 연결하고, 애플리케이션이 외부 의존성을 일관된 방식으로 관리할 수 있도록 돕는 유용한 도구입니다.

지금까지 살펴본 네 가지 서비스 타입 – ClusterIP, NodePort, LoadBalancer, ExternalName – 은 각각 고유한 목적과 특징을 가지고 있으며, 쿠버네티스에서 애플리케이션을 다양한 방식으로 노출하고 연결하는 데 핵심적인 역할을 합니다. 어떤 서비스 타입을 선택할지는 애플리케이션의 접근성 요구사항, 실행 환경(클라우드, 온프레미스), 보안 고려사항, 그리고 운영 편의성 등을 종합적으로 고려하여 결정해야 합니다.