서비스 검색

이 문서에는 Kubernetes DNS 기반 서비스 검색을 간략하게 설명하고 Kf와 함께 사용할 수 있는 방법을 설명합니다.

Kf로 Kubernetes 서비스 검색을 사용하는 경우

애플리케이션이 배포되는 위치에 상관없이 일관된 방식으로 지원 서비스를 찾아야 하는 애플리케이션으로 Kubernetes 서비스 검색을 사용할 수 있습니다. 예를 들어 팀은 항상 로컬 SMTP 게이트웨이를 가리키는 구성에서 공통 URI를 사용하여 서비스가 실행된 환경의 코드를 분리하려 합니다.

다음을 통해 서비스 검색에서 애플리케이션팀을 지원할 수 있습니다.

  • 환경별 구성의 양을 줄입니다.
  • 클라이언트 및 서버 애플리케이션을 분리합니다.
  • 애플리케이션이 새로운 환경으로 이동할 수 있도록 허용합니다.

다음과 같은 경우 Kubernetes 서비스 검색을 사용할 수 있습니다.

  • 애플리케이션은 컨테이너의 DNS 구성을 사용하여 호스트를 결정합니다.
  • 애플리케이션은 동일한 Kubernetes 클러스터 또는 네임스페이스에 백업 서비스를 사용하여 배포됩니다.
  • 백업 서비스에는 관련 Kubernetes 서비스가 있습니다. Kf는 각 앱에 이를 만듭니다.
  • Kubernetes NetworkPolicy는 통신해야 하는 애플리케이션과 Kubernetes 서비스 간의 트래픽을 허용합니다. Kf는 각 Kf 공간에서 이러한 정책을 만듭니다.

다음과 같은 경우 Kubernetes 서비스 검색을 사용하면 안 됩니다.

  • 애플리케이션은 여러 클러스터 간에 장애 조치를 수행해야 합니다.
  • 애플리케이션에서 사용하는 DNS 리졸버를 재정의합니다.
  • 애플리케이션에 특정 유형의 부하 분산이 필요합니다.

Kubernetes 서비스 검색 작동 방식

Kubernetes 서비스 검색은 Kubernetes 노드에서 실행되는 컨테이너의 DNS 구성을 수정하여 작동합니다. 애플리케이션이 정규화되지 않은 도메인 이름을 조회하면 로컬 DNS 리졸버가 먼저 로컬 클러스터의 이름을 확인하려고 시도합니다.

여러 부분이 포함되지 않은 도메인은 컨테이너의 네임스페이스에 있는 Kubernetes 서비스 이름에 대해 확인됩니다. 각 Kf 앱은 동일한 이름의 Kubernetes 서비스를 만듭니다. 두 개의 Kf 앱인 ping 및 pong가 동일한 Kf 공간에 배포된 경우 ping은 URL http://pong을 사용하여 트래픽을 다른 서비스에 보낼 수 있습니다.

점 하나가 있는 도메인은 점 뒤에 있는 라벨과 이름이 같은 Kubernetes 네임스페이스의 Kubernetes 서비스에 대해 확인됩니다. 예를 들어 database 네임스페이스에 customers 서비스가 있는 PostgreSQL 데이터베이스가 있는 경우 다른 네임스페이스의 애플리케이션은 postgres://customers.database를 사용하여 이를 확인할 수 있습니다.

Kf로 서비스 검색을 사용하는 방법

Kubernetes DNS 기반 서비스 검색은 모든 Kf 앱에서 사용할 수 있습니다. 각 Kf 앱은 동일한 이름의 Kubernetes 서비스를 만들고 각 Kf 공간은 같은 이름의 Kubernetes 네임스페이스를 만듭니다.

  • protocol://app-name을 사용하여 현재 공간에 있는 Kf 앱을 참조합니다.
  • protocol://app-name.space-name을 사용하여 다른 공간에 있는 Kf 앱을 참조합니다.
  • protocol://app-name:port를 사용하여 커스텀 포트에서 리슨하는 현재 공간에 있는 Kf 앱을 참조합니다.
  • protocol://app-name.space-name:port를 사용하여 커스텀 포트를 리슨하는 다른 공간에 있는 Kf 앱을 참조합니다.

권장사항

DNS 기반 서비스 검색의 대상이 되는 애플리케이션에는 연결을 허용하는 호스트 풀에서 신속하게 추가 및 삭제될 수 있도록 상태 확인이 자주 필요합니다.

DNS 기반 서비스 검색을 사용하는 애플리케이션은 해결된 서비스의 IP 주소가 안정적이지 않을 수 있으므로 이를 캐시하면 안 됩니다.

환경별 서비스가 클러스터 외부에 있는 경우 ExternalName Kubernetes 서비스를 설정하면 Kubernetes DNS를 사용하여 확인할 수 있습니다. 이 Kubernetes 서비스는 동일한 해결 기능을 제공하지만 CNAME 레코드를 반환하여 요청을 외부 기관으로 리디렉션합니다.

Eureka와 비교

Eureka는 Netflix에서 만든 오픈소스 클라이언트 측 부하 분산기입니다. 일반적으로 Spring Cloud Services 서비스 브로커의 일부로 사용됩니다. Eureka는 워크로드가 수시로 중단되어 불안정한 IP 주소로 이어지는 환경에서 실행되는 서비스의 리전 부하 분산기 및 서비스 검색 메커니즘으로 구축되었습니다.

Eureka는 클라이언트/서버 모델로 설계되었습니다. 클라이언트는 연결할 이름을 나타내는 서버에 등록하고 정기적으로 서버 하트비트를 전송합니다. 서버를 사용하면 연결된 모든 클라이언트가 이름을 확인할 수 있습니다.

일반적으로 다음과 같은 이유로 Kubernetes에서 Eureka 대신 Kubernetes DNS를 사용해야 합니다.

  • DNS는 라이브러리가 필요 없는 모든 프로그래밍 언어와 애플리케이션에서 작동합니다.
  • 애플리케이션의 기존 상태 확인을 재사용하면 오류의 조합이 줄어듭니다.
  • Kubernetes는 DNS 서버를 관리하여 종속 항목을 더 적게 사용합니다.
  • Kubernetes DNS는 나머지 Kubernetes와 동일한 정책 및 RBAC 제약조건을 고려합니다.

Eureka 서버를 배포할 때 다음과 같은 이점이 있습니다.

  • Kubernetes 및 VM 기반 애플리케이션에서 서비스 검색이 필요합니다.
  • 클라이언트 기반 부하 분산이 필요합니다.
  • 독립적인 상태 확인이 필요합니다.

다음 단계