APISIX Ingress Controller가 Service Discovery와 통합

Jintao Zhang

Jintao Zhang

January 13, 2023

Products

클라우드 네이티브 애플리케이션에서 서비스 디스커버리가 필요한가요?

배경

마이크로서비스 아키텍처는 현재 가장 인기 있는 애플리케이션 아키텍처 중 하나입니다. 애플리케이션의 크기가 커짐에 따라 애플리케이션 관리가 더 어려워집니다. 마이크로서비스 아키텍처는 애플리케이션을 여러 개의 작은 서비스 컴포넌트로 분할하여 이 문제를 해결하려고 합니다. 이러한 컴포넌트들은 특정 비즈니스 로직과 기능을 완료하기 위해 협력합니다.

이러한 컴포넌트들은 잘 협력하기 위해 동적으로 통신해야 합니다. 일반적으로 서비스 디스커버리 도구를 도입해야 합니다. 우리는 이전에 마이크로서비스에서의 서비스 디스커버리를 소개하는 글을 작성했습니다: 마이크로서비스에서의 서비스 디스커버리란 무엇인가 - API7.ai.

서비스 디스커버리를 도입함으로써, 컴포넌트들은 동적으로 얻을 수 있습니다. 다른 컴포넌트의 이름만 주의하면 되며, 배포 위치나 배포 IP와 같은 다른 정보에 주의할 필요가 없습니다.

쿠버네티스에서의 서비스 디스커버리

쿠버네티스 환경에서, 파드는 가장 작은 배포 가능한 단위입니다.

그리고 쿠버네티스에서는 파드의 IP가 지속적이지 않고 자주 변경되기 때문에 컴포넌트들이 서로 통신하기가 더 어렵습니다.

따라서 쿠버네티스에 애플리케이션을 배포할 때 이러한 동적 환경에 적응하는 것이 더 중요합니다.

쿠버네티스는 이러한 요구 사항을 고려하여 자체 DNS 기반 서비스 디스커버리 메커니즘을 제공합니다.

쿠버네티스는 서비스라는 개념을 제공하며, 이는 리버스 프록시와 유사합니다. 클라이언트는 서비스만 사용하면 되며, 뒤에 캡슐화된 파드들을 알 필요가 없습니다.

각 서비스에는 지속적인 ClusterIP가 할당됩니다. 따라서 파드 IP가 변경되더라도 다른 컴포넌트들은 서비스의 고정된 ClusterIP를 통해 여전히 협력할 수 있습니다.

동시에, 쿠버네티스의 서비스는 클러스터 내의 DNS에 A/AAAA 레코드를 자동으로 업데이트합니다.

레코드는 다음과 같이 보입니다:

my-svc.my-namespace.svc.cluster-domain.example

클라이언트는 네임스페이스 간 또는 동일한 네임스페이스 내에서 해석할 수 있어 컴포넌트 간의 서비스 디스커버리를 크게 용이하게 합니다.

그러나 쿠버네티스가 아닌 전통적인 마이크로서비스 아키텍처에서는 일반적으로 서비스 디스커버리 도구를 사용하여 서비스 간의 협력을 달성합니다. 쿠버네티스 환경에서 DNS 기반 서비스 디스커버리 메커니즘에 완전히 적응하려면 일정한 변환/마이그레이션 비용이 필요합니다.

따라서 더 낮은 변환 비용을 원한다면 원래의 서비스 디스커버리 메커니즘을 유지해야 합니다.

이러한 전제 하에, 쿠버네티스로 새로 마이그레이션된 서비스를 노출하는 가장 좋은 방법은 무엇일까요?

APISIX Ingress가 서비스 디스커버리와 어떻게 작동하나요?

APISIX Ingress는 쿠버네티스에서 Ingress 컨트롤러의 구현입니다. 데이터 플레인으로 Apache APISIX를 사용하며, Ingress, 사용자 정의 CRD 및 Gateway API를 통해 프록시 규칙을 구성할 수 있습니다. 동시에 서비스 디스커버리 도구와의 통합도 제공하여 등록된 서비스를 쉽게 프록시하고 클라이언트에 노출할 수 있습니다.

이 섹션에서 자세히 설명하겠습니다.

APISIX의 서비스 디스커버리 지원

APISIX는 고성능의 완전 동적 클라우드 네이티브 API 게이트웨이로, 80개 이상의 즉시 사용 가능한 플러그인을 제공하며 대부분의 사용 시나리오를 다룹니다.

그 중 하나의 뛰어난 기능은 서비스 디스커버리 도구와의 통합입니다.

APISIX는 다음과 같은 서비스 디스커버리 도구와 통합할 수 있습니다:

  • Consul
  • DNS
  • Eureka
  • Nacos

APISIX 구성 파일에 다음 구성을 추가하기만 하면 됩니다 (DNS를 예로 들면):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # 실제 DNS 서버 주소를 사용하세요

이렇게 하면 업스트림을 구성할 때 APISIX는 서비스 디스커버리를 통해 실제 업스트림 주소 정보를 동적으로 해석하고 요청을 프록시할 수 있습니다.

APISIX Ingress는 어떻게 하나요?

APISIX Ingress는 데이터 플레인 프록시 컴포넌트로 APISIX를 사용합니다. 처음 서비스 디스커버리를 통합할 때 두 가지 옵션을 고려했습니다.

  • 컨트롤 플레인 통합: Ingress 컨트롤러에서 서비스 디스커버리를 구성하고, 구성을 해석 및 분석하여 APISIX에 전송하여 프록시합니다.
  • 데이터 플레인 통합: APISIX 데이터 플레인에서 서비스 디스커버리를 구성하고, 데이터 플레인이 구성 해석 및 프록시를 수행합니다.

이 두 솔루션은 각각의 장점이 있지만, 구성의 실시간 업데이트와 솔루션의 성숙도를 고려하여 데이터 플레인 통합 솔루션을 선택했습니다.

이 솔루션을 사용할 때 사용자는 더 낮은 비용으로 통합할 수 있으며, 이 솔루션은 많은 생산 검증을 거친 매우 성숙한 솔루션입니다.

APISIX Ingress를 사용하는 방법은 무엇인가요?

먼저, APISIX 구성에 올바른 서비스 디스커버리 구성이 포함되어 있는지 확인하세요. 다음은 DNS를 예로 듭니다:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

ApisixUpstream 리소스를 생성하고, 사용 시나리오에 따라 discovery와 관련된 구성을 수정합니다. 예를 들어, 여기서는 type: dns와 프록시할 serviceName을 설정합니다:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

마지막으로, ApisixRoute 리소스를 생성하고, upstreams가 방금 생성한 ApisixUpstream 리소스를 참조하도록 합니다:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

위의 리소스가 올바르게 생성된 후, DNS에 등록된 httpbin.default.svc.cluster.local을 local.httpbin.org를 통해 접근할 수 있습니다.

클라이언트가 요청을 만드는 방법

이점과 전망

이 통합을 통해 이미 서비스 디스커버리 도구를 사용 중인 애플리케이션의 경우 APISIX Ingress를 통해 클라이언트에 서비스를 노출하는 것이 매우 편리합니다. 이 APISIX Ingress 기능은 대부분의 Ingress 컨트롤러가 제공하지 않는 통합 솔루션을 제공하기 때문에 독특합니다.

읽어주셔서 감사합니다. 우리는 여전히 APISIX Ingress를 구축하여 최고의 사용자 경험을 제공하기 위해 노력하고 있습니다!

API 게이트웨이에 대한 더 많은 정보는 블로그를 방문하거나 문의해 주세요.

Tags:
APISIX Ingress Controller
Kubernetes
Service Discovery