서비스 검색 정보

이 문서에서는 Google Kubernetes Engine (GKE)의 서비스 검색이 애플리케이션 관리를 간소화하는 방법과 Cloud DNS 범위, 멀티 클러스터 서비스 (MCS), 서비스 디렉터리를 사용하여 단일 클러스터를 넘어 서비스 검색을 확장하는 방법을 설명합니다.

이 문서는 GKE 사용자, 개발자, 관리자 및 설계자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

이 문서를 읽기 전에 다음 개념을 이해해야 합니다.

개요

서비스 검색은 서비스와 애플리케이션이 IP 주소나 엔드포인트 구성을 하드코딩하지 않고도 서로 동적으로 찾고 통신할 수 있는 메커니즘입니다. 서비스 검색을 사용하면 포드 일정이 변경되거나 새 포드가 추가되더라도 애플리케이션이 항상 최신 포드 IP 주소에 액세스할 수 있습니다. GKE는 kube-dns, 맞춤 kube-dns 배포, Cloud DNS 등 서비스 검색을 구현하는 여러 방법을 제공합니다. NodeLocal DNSCache를 사용하여 DNS 성능을 추가로 최적화할 수 있습니다.

서비스 검색의 이점

서비스 검색은 다음과 같은 이점을 제공합니다.

  • 간소화된 애플리케이션 관리: 서비스 검색을 통해 애플리케이션 구성에 IP 주소를 하드코딩할 필요가 없습니다. 애플리케이션은 올바른 포드 IP 주소로 자동 변환되는 논리적 서비스 이름을 사용하여 통신합니다. 이 접근 방식은 특히 확장 또는 재예약으로 인해 포드 IP 주소가 변경될 수 있는 동적 환경에서 구성을 간소화합니다.
  • 간소화된 확장 및 복원력: 서비스 검색은 서비스 소비자를 자주 변경되는 포드 IP 주소에서 분리하여 확장을 간소화합니다. 애플리케이션이 확장되거나 포드가 실패하여 교체되는 동안 Kubernetes는 특정 서비스의 트래픽을 수신할 수 있는 포드를 자동으로 업데이트합니다. 서비스 검색을 사용하면 안정적인 서비스 이름에 대한 요청이 정상 포드로만 전달되므로 수동 개입이나 클라이언트 재구성 없이도 애플리케이션을 확장하거나 장애로부터 복구할 수 있습니다.
  • 고가용성: GKE는 서비스 검색과 함께 부하 분산을 사용하여 부하가 많은 경우에도 애플리케이션의 고가용성을 보장하고 응답성을 개선합니다.

서비스 검색을 사용한 부하 분산

GKE는 다양한 수준의 부하 분산을 서비스 검색과 결합하여 애플리케이션의 고가용성을 보장합니다.

  • 내부 서비스: 클러스터 내에서만 액세스할 수 있는 서비스의 경우 GKE의 데이터 플레인 (kube-proxy 또는 Cilium)이 부하 분산기 역할을 합니다. 정상적인 여러 포드에 수신 트래픽을 균등하게 분산하여 과부하를 방지하고 고가용성을 보장합니다.
  • 외부 서비스: 클러스터 외부에서 액세스할 수 있어야 하는 서비스의 경우 GKE가 Google Cloud 부하 분산기를 프로비저닝합니다. 이러한 부하 분산기에는 공용 인터넷 액세스를 위한 외부 Google Cloud 부하 분산기와 가상 프라이빗 클라우드 네트워크 내 액세스를 위한 내부 Google Cloud 부하 분산기가 포함됩니다. 이러한 부하 분산기는 클러스터의 노드 간에 트래픽을 분산합니다. 그러면 각 노드의 데이터 영역에서 트래픽을 적절한 포드로 추가 라우팅합니다.

내부 및 외부 시나리오 모두에서 서비스 검색은 각 서비스에 사용할 수 있는 포드 목록을 지속적으로 업데이트합니다. 이 지속적인 업데이트를 통해 데이터 플레인 (내부 서비스용)과 Google Cloud 부하 분산기 (외부 서비스용)가 모두 정상 인스턴스로만 트래픽을 전달할 수 있습니다.

서비스 검색 사용 사례

다음은 서비스 검색의 일반적인 사용 사례입니다.

  • 마이크로서비스 아키텍처: 마이크로서비스 아키텍처에서 애플리케이션은 상호작용해야 하는 작고 독립적인 서비스로 구성되는 경우가 많습니다. 서비스 검색을 사용하면 클러스터가 확장되는 동안에도 이러한 애플리케이션이 서로를 찾아 정보를 교환할 수 있습니다.
  • 무중단 배포를 사용 설정하고 복원력 개선: 서비스 검색을 사용하면 관리형 출시 및 카나리아 배포를 비롯한 애플리케이션의 무중단 업데이트가 용이해집니다. 새 서비스 버전의 검색을 자동화하고 트래픽을 새 버전으로 전환하여 배포 중 다운타임을 줄이고 사용자의 원활한 전환을 보장합니다. 서비스 검색은 복원력도 향상합니다. GKE에서 포드가 실패하면 새 포드가 배포되고 서비스 검색이 새 포드를 등록하고 트래픽을 새 포드로 리디렉션하여 애플리케이션 다운타임을 최소화합니다.

서비스 검색 작동 방식

GKE에서 애플리케이션은 서로를 찾아 통신해야 하는 여러 포드로 구성되는 경우가 많습니다. 서비스 검색은 도메인 이름 시스템 (DNS)을 사용하여 이 기능을 제공합니다. 인터넷에서 DNS를 사용하여 웹사이트를 찾는 것과 마찬가지로 GKE 클러스터의 포드는 DNS를 사용하여 서비스 이름을 통해 서비스를 찾고 연결합니다. 이 방법을 사용하면 클러스터에서 실행되는 위치와 관계없이 포드가 효과적으로 상호작용할 수 있으며, 애플리케이션이 불안정한 IP 주소 대신 일관된 서비스 이름을 사용하여 통신할 수 있습니다.

포드가 DNS 변환을 실행하는 방법

GKE 클러스터의 포드는 자동으로 생성된 DNS 레코드와 로컬 DNS 구성을 조합하여 서비스 및 기타 포드의 DNS 이름을 확인합니다.

서비스 DNS 이름

Kubernetes 서비스를 만들면 GKE가 DNS 이름을 자동으로 할당합니다. 이 이름은 예측 가능한 형식을 따르며 클러스터의 모든 포드가 서비스를 액세스하는 데 사용할 수 있습니다.

<service-name>.<namespace>.svc.cluster.local

기본 클러스터 도메인은 cluster.local이지만 클러스터를 만들 때 도메인을 맞춤설정할 수 있습니다. 예를 들어 기본 네임스페이스에서 my-web-app라는 서비스의 DNS 이름은 my-web-app.default.svc.cluster.local입니다.

/etc/resolv.conf의 역할

이러한 DNS 이름을 확인하기 위해 포드는 /etc/resolv.conf 파일을 사용합니다. 이 구성 파일은 포드에 DNS 쿼리를 전송할 네임서버를 알려줍니다. 이 파일에 나열된 네임서버의 IP 주소는 GKE 클러스터에서 사용 설정된 특정 DNS 기능에 따라 달라집니다. 다음 표에는 구성에 따라 포드에서 사용하는 네임서버 IP가 나와 있습니다.

GKE용 Cloud DNS NodeLocal DNSCache `/etc/resolv.conf` 네임서버 값
사용 설정됨 사용 설정됨 `169.254.20.10`
사용 설정됨 사용 중지됨 `169.254.169.254`
사용 중지됨 사용 설정됨 `kube-dns` 서비스 IP 주소
사용 중지됨 사용 중지됨 `kube-dns` 서비스 IP 주소

이 구성은 포드의 DNS 쿼리가 올바른 구성요소로 전달되도록 하는 데 도움이 됩니다.

  • NodeLocal DNSCache: 노드에서 빠른 로컬 조회를 제공합니다.
  • 메타데이터 서버 IP (169.254.169.254): NodeLocal DNSCache 없이 GKE용 Cloud DNS가 사용 설정된 경우에 사용됩니다. DNS 쿼리는 이 IP 주소로 전달되며, Cloud DNS는 이를 사용하여 DNS 요청을 가로채고 처리합니다.
  • kube-dns 서비스 IP 주소: GKE용 Cloud DNS가 사용 중지된 경우 표준 클러스터 내 확인에 사용됩니다.

GKE의 DNS 아키텍처

GKE는 주로 DNS를 사용하여 서비스 검색을 위한 유연한 아키텍처를 제공합니다. 다음 구성요소는 클러스터 내에서 DNS 쿼리를 해결하기 위해 함께 작동합니다.

  • kube-dns: GKE Standard 클러스터의 기본 인클러스터 DNS 제공업체입니다. kube-system 네임스페이스에서 포드의 관리형 배포로 실행되며 Kubernetes API에서 새 서비스를 모니터링하여 필요한 DNS 레코드를 만듭니다.
  • Cloud DNS: Google Cloud의 완전 관리형 DNS 서비스입니다. kube-dns의 확장 가능하고 안정적인 대안을 제공하며 GKE Autopilot 클러스터의 기본 DNS 제공업체입니다.
  • NodeLocal DNSCache: DNS 조회 성능을 개선하는 GKE 부가기능입니다. 클러스터의 각 노드에서 DNS 캐시를 실행하며 kube-dns 또는 Cloud DNS와 함께 작동하여 DNS 쿼리를 로컬로 처리하므로 지연 시간과 클러스터의 중앙 DNS 제공업체에 대한 부하가 줄어듭니다. GKE Autopilot 클러스터의 경우 NodeLocal DNSCache가 기본적으로 사용 설정되며 재정의할 수 없습니다.
  • 맞춤 kube-dns 배포: kube-dns의 자체 인스턴스를 배포하고 관리할 수 있는 배포로, kube-dns 구성 및 리소스를 더 세부적으로 제어할 수 있습니다.

DNS 제공업체 선택

다음 표에는 GKE에서 사용할 수 있는 DNS 제공업체와 각 제공업체의 기능, 각 제공업체를 선택해야 하는 경우가 요약되어 있습니다.

제공업체 기능 선택해야 하는 경우
`kube-dns` 서비스 및 포드의 클러스터 내 DNS 확인 표준 네트워킹이 필요한 모든 클러스터 새 버전의 `kube-dns` 는 소규모 및 대규모 클러스터 모두에 적합합니다.
Cloud DNS 고급 DNS 기능 (비공개 영역, 트래픽 스티어링, 전역 부하 분산) 및 기타 Google Cloud 서비스와의 통합 서비스를 외부에 노출하거나, 멀티 클러스터 환경을 사용하거나, DNS 쿼리 비율 (QPS)이 높은 클러스터에 적합합니다.
맞춤 `kube-dns` 배포 구성, 리소스 할당, 대체 DNS 제공업체 사용 가능성에 대한 추가 제어 대규모 클러스터 또는 더 적극적인 확장이나 리소스 할당에 대한 세부적인 제어가 필요한 특정 DNS 요구사항

단일 클러스터 외부 서비스 검색

다음 방법을 사용하여 단일 GKE 클러스터를 넘어 서비스 검색을 확장할 수 있습니다.

Cloud DNS 범위

클러스터 DNS에 Cloud DNS를 사용하는 클러스터는 다음 세 가지 범위 중 하나로 작동할 수 있습니다.

  • 클러스터 범위: Cloud DNS의 기본 동작입니다. 이 모드에서 Cloud DNS는 클러스터 내에 있는 리소스에 대해서만 DNS 변환을 제공하여 kube-dns와 동일하게 작동합니다. DNS 레코드는 클러스터 내에서만 확인할 수 있으며 표준 Kubernetes 서비스 스키마인 <svc>.<ns>.svc.cluster.local를 따릅니다.
  • 추가 VPC 범위: 이 선택적 기능은 Cloud VPN 또는 Cloud Interconnect를 사용하여 연결하는 Compute Engine VM 또는 온프레미스 클라이언트와 같은 동일한 VPC 네트워크 내의 다른 리소스에서 헤드리스 서비스를 해결할 수 있도록 클러스터 범위를 확장합니다.
  • VPC 범위: 이 구성에서는 클러스터 서비스의 DNS 레코드를 전체 VPC 네트워크 내에서 확인할 수 있습니다. 이 접근 방식을 사용하면 동일한 VPC에 있거나 Cloud VPN 또는 Cloud Interconnect를 통해 VPC에 연결된 클라이언트가 서비스 이름을 직접 확인할 수 있습니다.

VPC 범위 DNS에 대한 자세한 내용은 GKE에 Cloud DNS 사용을 참고하세요.

멀티 클러스터 서비스

멀티 클러스터 서비스 (MCS)를 사용하면 여러 GKE 클러스터 간에 서비스 검색 및 트래픽 관리가 가능합니다. MCS를 사용하면 통합 서비스 환경을 유지하면서 클러스터에 걸쳐 있는 애플리케이션을 빌드할 수 있습니다.

MCS는 DNS 기반 서비스 검색을 활용하여 클러스터 간에 서비스를 연결합니다. MCS 인스턴스를 만들면 <svc>.<ns>.svc.clusterset.local 형식의 DNS 레코드가 생성됩니다. 이러한 레코드는 각 참여 클러스터에 있는 서비스 엔드포인트의 IP 주소로 확인됩니다.

한 클러스터의 클라이언트가 MCS에 액세스하면 요청이 참여 클러스터 중 하나의 사용 가능한 가장 가까운 엔드포인트로 라우팅됩니다. 이 트래픽 분산은 각 노드의 kube-proxy (또는 GKE GKE Dataplane V2의 경우 Cilium)에 의해 관리되므로 클러스터 간의 효율적인 통신과 부하 분산이 보장됩니다.

GKE용 서비스 디렉터리

GKE용 서비스 디렉터리는 Kubernetes 및 비 Kubernetes 배포 전반에서 서비스 검색을 위한 통합 레지스트리를 제공합니다. 서비스 디렉터리를 통해 GKE 및 비GKE 서비스를 모두 단일 레지스트리에 등록할 수 있습니다.

서비스 디렉터리는 다음이 필요한 경우에 특히 유용합니다.

  • Kubernetes 및 비Kubernetes 애플리케이션이 서로를 검색하는 단일 레지스트리
  • 관리형 서비스 검색 도구
  • 다른 클라이언트가 액세스할 수 있는 서비스에 관한 메타데이터를 저장하는 기능
  • 서비스 수준별로 액세스 권한을 설정하는 기능 서비스 디렉터리 서비스는 DNS, HTTP, gRPC를 사용하여 확인할 수 있습니다. 서비스 디렉터리는 Cloud DNS와 통합되며 서비스 디렉터리의 서비스와 일치하는 Cloud DNS 레코드를 채울 수 있습니다.

자세한 내용은 GKE용 서비스 디렉터리 구성을 참고하세요.

DNS 성능 최적화 및 권장사항

특히 대규모 또는 트래픽이 많은 클러스터에서 안정적이고 효율적인 서비스 검색을 보장하려면 다음 권장사항과 최적화 전략을 고려하세요.

NodeLocal DNSCache로 성능 최적화

포드 밀도가 높은 클러스터나 DNS 쿼리 볼륨이 높은 애플리케이션의 경우 NodeLocal DNSCache를 사용 설정하여 DNS 조회 속도를 개선할 수 있습니다. NodeLocal DNSCache는 클러스터의 각 노드에서 DNS 캐시를 실행하는 GKE 부가기능입니다. 포드가 DNS 요청을 수행하면 요청은 동일한 노드에 있는 캐시로 이동합니다. 이 방식을 사용하면 지연 시간과 네트워크 트래픽이 줄어듭니다.

이 기능을 사용 설정하고 구성하는 방법에 대한 자세한 내용은 NodeLocal DNSCache 설정을 참고하세요.

DNS 제공업체 확장

kube-dns를 사용하고 특히 트래픽이 많은 기간에 간헐적인 시간 초과가 발생하는 경우 kube-dns 복제본 수를 확장해야 할 수 있습니다. kube-dns-autoscaler는 클러스터의 노드 및 코어 수를 기반으로 복제본 수를 조정하며, 매개변수를 조정하여 더 빨리 복제본을 배포할 수 있습니다.

자세한 내용은 kube-dns 확장을 참고하세요.

일반 권장사항

  • 적절한 DNS 제공업체 선택: 클러스터의 요구사항에 따라 DNS 제공업체를 선택합니다. Cloud DNS는 QPS가 높은 워크로드, 다중 클러스터 환경, 더 광범위한 VPC 네트워크와의 통합이 필요한 경우에 권장됩니다. 새 버전의 kube-dns는 표준 클러스터 내 서비스 검색 요구사항이 있는 소규모 클러스터부터 대규모 클러스터까지 다양한 클러스터에 적합합니다.
  • kube-dns에 스팟 VM 또는 선점형 VM 사용 방지: 스팟 VM 또는 선점형 VM에서 kube-dns과 같은 중요한 시스템 구성요소를 실행하지 않음으로써 클러스터의 DNS 서비스 안정성을 보장합니다. 예기치 않은 노드 종료는 DNS 변환 문제를 일으킬 수 있습니다.
  • 명확하고 설명적인 서비스 이름 사용: 애플리케이션 구성을 더 쉽게 읽고 유지관리할 수 있도록 서비스에 일관되고 의미 있는 이름 지정 규칙을 채택합니다.
  • 네임스페이스로 구성: Kubernetes 네임스페이스를 사용하여 관련 서비스를 그룹화합니다. 이 접근 방식은 이름 충돌을 방지하고 클러스터 리소스 구성을 개선하는 데 도움이 됩니다.
  • DNS 모니터링 및 검증: DNS 측정항목과 로그를 정기적으로 모니터링하여 애플리케이션에 영향을 미치기 전에 잠재적인 문제를 파악합니다. 포드 내에서 DNS 변환을 주기적으로 테스트하여 서비스 검색이 예상대로 작동하는지 확인합니다.

다음 단계