Why Is APISIX Ingress Controller Better than NGINX Ingress Controller?

Ingress는 Kubernetes에서 서비스를 노출시키며, 트래픽 라우팅은 Ingress 리소스에 구성된 규칙에 의해 제어됩니다. Ingress를 사용하려면 Ingress 컨트롤러도 필요합니다.

이 글에서는 두 가지 인기 있는 Ingress 컨트롤러를 비교하여 독자들이 Ingress 컨트롤러를 선택하는 데 도움을 드리고자 합니다.

• Ingress-NGINX는 Kubernetes 커뮤니티에서 구현된 Ingress 컨트롤러로, 커뮤니티에서 널리 사용됩니다.
• APISIX Ingress 컨트롤러는 ASF (Apache Software Foundation)의 오픈소스 프로젝트인 Apache APISIX를 데이터 플레인으로 사용합니다.

Ingress NGINX vs. APISIX Ingress

기능 비교

아래 표는 Ingress NGINX와 APISIX Ingress의 기본 기능을 비교한 것으로, 프로토콜, 업스트림 프로브/복원력, 로드 밸런서 전략, 인증, Kubernetes 통합 등을 포함합니다. 이 표는 learnk8s.io에서 추출되었습니다.

차이점

아래 그림에서 볼 수 있듯이, APISIX Ingress는 Ingress NGINX보다 더 많은 내장 기능과 특징을 가지고 있습니다. 이는 프로토콜 지원, 헬스 체크 및 서킷 브레이커, 인증, Kubernetes 통합 등을 포함합니다.

서비스 디스커버리

마이크로서비스 아키텍처에서 애플리케이션은 많은 마이크로서비스로 나뉩니다. 마이크로서비스가 실패하거나 서비스가 확장 또는 축소될 때마다 호출자는 가능한 한 빨리 알림을 받아야 호출 실패를 방지할 수 있습니다. 따라서 서비스 등록 및 서비스 디스커버리 메커니즘은 마이크로서비스 아키텍처에서 매우 중요하며, 일반적으로 서비스 레지스트리에 의해 유지됩니다.

프로토콜 지원

두 Ingress 모두 HTTP/HTTPS 프로토콜을 지원하지만, APISIX는 더 많은 프로토콜을 지원합니다. TCP 트래픽을 암호화하기 위해 TLS를 지원하며, MQTT, Dubbo, kafka 프록시도 지원합니다.

업스트림 프로브/복원력

헬스 체크

노드가 실패하거나 마이그레이션되면 노드를 사용할 수 없게 되는 것은 불가피합니다. 이러한 사용 불가능한 노드에 많은 요청이 접근하면 트래픽 손실과 비즈니스 중단이 발생할 수 있습니다. 따라서 프로브를 사용하여 노드에 대한 헬스 체크를 수행하고 요청을 건강한 노드로 전달하여 트래픽 손실을 줄이는 것이 필요합니다.

Ingress NGINX에서는 아직 헬스 체크 기능을 지원하지 않지만, APISIX Ingress는 이 기능을 제공합니다:

• 액티브 체크: 백엔드의 Pod가 건강한지 확인하기 위해 프로브를 사용합니다. 노드에 보낸 N개의 연속적인 프로브가 실패하면 노드는 비건강 상태로 표시됩니다. 로드 밸런서는 비건강 노드를 무시하여 요청을 받지 못하게 합니다. 액티브 헬스 체크를 활성화하면 비건강 Pod를 효과적으로 비활성화하여 트래픽 손실을 방지할 수 있습니다.
• 패시브 체크: 패시브 헬스 체크는 추가 프로브를 시작할 필요가 없습니다. 노드에 보낸 각 요청이 프로브 역할을 합니다. 건강한 노드에 보낸 N개의 연속적인 요청이 실패하면 노드는 비건강 상태로 표시됩니다. 노드 상태를 미리 감지할 수 없기 때문에 일정량의 실패 요청이 발생할 수 있습니다. 이 상황은 롤링 업데이트 중에 상대적으로 흔하며, 서비스 다운그레이드를 사용하여 실패 요청의 양을 줄일 수 있습니다.

APISIX Ingress에서 httpbin 서비스에 대한 헬스 체크를 구성하는 예시:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

서킷 브레이커

게이트웨이는 요청의 진입점이며, 백엔드 서비스에 대한 호출을 시작합니다. 트래픽이 급증하고 부하가 심할 때 백엔드 서비스는 타임아웃이나 예외로 인해 호출에 실패할 수 있습니다. 실패가 발생하면 요청이 게이트웨이에 쌓일 수 없으며, 빠르게 반환해야 합니다. 이를 위해 게이트웨이에서 서킷 브레이커가 필요합니다.

헬스 체크 기능과 마찬가지로, Ingress NGINX에서는 서비스 서킷 브레이커 기능을 지원하지 않습니다. APISIX Ingress에서는 api-breaker 플러그인이 이를 구현하는 데 도움을 줍니다.

APISIX Ingress에서 서킷 브레이커 구성 예시:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

더 많은 플러그인 및 인증 방법 지원

Ingress NGINX는 주로 Annotations와 ConfigMap을 사용하여 구성하며, 지원되는 플러그인이 상대적으로 제한적입니다. JWT, HAMC 또는 기타 인증 방법을 사용하려면 직접 통합해야 합니다.

APISIX Ingress는 APISIX에서 기본적으로 80개 이상의 플러그인을 지원하며, JWT, HAMC, wolf-rbac 등 다양한 인증 방법을 지원합니다. 이러한 플러그인은 대부분의 사용 시나리오를 커버하는 다양한 기능을 제공합니다.

APISIX 경로에서 HMAC 인증 예시:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Ingress NGINX와 APISIX Ingress의 확장성

Ingress 컨트롤러의 기본 기능이 기업 사용자의 요구를 충족시키지 못할 때, 확장을 통해 사용자 정의할 수 있습니다. 다음으로 Ingress NGINX와 APISIX Ingress가 기능을 확장하는 방법을 설명하겠습니다.

Ingress NGINX의 기능 확장 방법

Ingress NGINX는 Lua 프로그램을 내장하여만 확장할 수 있습니다.

Ingress NGINX 플러그인 개발 예시:

1. Lua 프로그램 example-plugin 작성
2. 플러그인을 ingress-nginx pod의 /etc/nginx/lua/plugins/<your plugin name> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin에 설치
3. ConfigMap에서 example-plugin을 활성화하고, Ingress NGINX 설치 시 이 ConfigMap 객체를 참조

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

APISIX Ingress의 기능 확장 방법

APISIX Ingress는 다양한 방법으로 기능을 확장할 수 있으며, 기업 사용자는 자신의 필요에 따라 자유롭게 방법을 선택할 수 있습니다. APISIX는 다음을 지원합니다:

• Lua를 통한 플러그인 개발: 간단하고 성능 손실이 거의 없음
• 플러그인-러너를 통한 개발: JAVA/Python/Go와 같은 프로그래밍 언어를 지원하여 사용자가 새로운 언어를 배우지 않고도 플러그인을 사용자 정의할 수 있음
• WASM을 통한 플러그인: WASM을 빌드할 수 있는 모든 언어를 사용하여 플러그인 개발 가능

또한, 서버리스 플러그인을 통해 Lua 코드를 직접 작성하여 비즈니스 요구를 빠르게 충족할 수 있습니다.

APISIX Ingress가 CustomResourceDefinition (CRD)를 지원하는 이유는 무엇인가요?

현재 APISIX Ingress는 Ingress, CRD, Gateway API 세 가지 선언적 구성을 지원합니다. 여기서는 주로 Ingress와 CRD를 비교하겠습니다. 그리고 Gateway API는 이후에 설명하겠습니다.

Ingress는 Ingress NGINX에서 마이그레이션하는 기업 사용자에게 적합하며, 마이그레이션 비용이 낮습니다. 그러나 약한 의미론적 능력, 표준 사양 부족 등의 단점도 있습니다. 또한, Ingress는 주석을 통해서만 확장할 수 있지만, 주석은 복잡한 시나리오를 지원할 수 없습니다. 반면, CRD는 다음과 같은 장점이 있습니다:

• 데이터 플레인의 설계 의미론에 더 부합하여 사용하기 쉬움
• 구성의 재사용성으로 중복 감소
• 기능 및 확장성 향상
• APISIX의 데이터 플레인은 활발한 커뮤니티를 가지고 있으며, 빠른 업데이트와 릴리스를 통해 CRD가 데이터 플레인의 더 많은 기능을 쉽게 지원할 수 있음

Ingress NGINX의 고통 포인트: 핫 리로딩 미지원

정적 구성으로 인한 문제

Ingress NGINX는 주로 NGINX 구성 파일을 기반으로 구현됩니다. NGINX와 Lua를 사용하여 기능 확장을 달성하지만, 이는 정적 구성 파일의 문제를 부분적으로만 해결합니다. 라우팅 및 리로딩 기능에서 부족함을 보입니다. 예를 들어, 규칙을 추가하거나 수정할 때 NGINX 구성을 리로드해야 합니다. 라우팅 규칙과 인증서가 점점 많아질수록 로드 작업은 몇 초에서 십여 초 이상 걸릴 수 있습니다. NGINX의 모든 리로드는 로드 밸런싱 상태를 재설정하여 온라인 트래픽에 부정적인 영향을 미치고, 짧은 중단을 일으키며, 응답 지연을 증가시키고, 로드 밸런싱 품질을 저하시킵니다.

NGINX 리로드를 유발하는 상황

• 새로운 Ingress 리소스 생성
• 기존 Ingress에 TLS 섹션 추가
• Ingress 주석 변경 (예: 로드 밸런싱 주석은 리로드 필요 없음)
• Ingress에 경로 추가 또는 삭제
• Ingress, Service, Secret 리소스 삭제
• Secret 업데이트

위에 나열된 상황은 Ingress 컨트롤러의 대부분의 사용 시나리오를 포함합니다. 애플리케이션이 자주 배포되는 클러스터 환경에서는 Ingress 및 Secret과 같은 리소스의 작업(생성, 업데이트, 삭제 등)이 지속적으로 트리거되어 NGINX 리로드 횟수가 급격히 증가하며, 이는 프로덕션 환경에 큰 영향을 미칩니다.

Ingress NGINX의 아키텍처는 NGINX 구성을 먼저 생성하고 리로드하여 구성 업데이트를 완료해야 한다는 점을 결정합니다. 아키텍처를 조정하지 않고는 리로딩 문제를 해결할 수 없습니다. 이 문제를 해결하기 위해 APISIX Ingress는 라우팅 구현에서 NGINX 구성에 더 이상 의존하지 않고 순수 메모리 아키텍처로 변경했습니다. 핫 리로딩을 통해 동적 라우팅을 실현하며, NGINX를 재시작할 필요가 없습니다.

Gateway API

Kubernetes Gateway API의 장점

Kubernetes Gateway API는 Ingress보다 더 많은 기능을 제공하며, Kubernetes 서비스 네트워킹을 발전시키기 위해 표현적이고 확장 가능하며 역할 지향적인 인터페이스로 설계되었습니다. Gateway API는 다음과 같은 특징을 가지고 있습니다:

• 역할 지향적: Gateway는 API 리소스로 구성됩니다. 다른 API 리소스는 Kubernetes 네트워크 리소스를 사용하고 구성하는 데 있어 다른 역할을 나타냅니다.

• 강력한 표현력: Gateway API는 헤더 기반 매칭, 트래픽 가중치 등 Ingress에서는 사용자 정의 비표준 주석을 통해서만 가능했던 핵심 기능을 지원합니다.

• 확장 가능: Gateway API는 다양한 API 계층에서 리소스를 연결할 수 있도록 합니다. 이를 통해 API 구조 내에서 세밀한 사용자 정의가 가능합니다.

Gateway API 지원 상태

Kubernetes Gateway API는 Kubernetes 서비스 메시를 확장하기 위한 표준입니다. Gateway 리소스는 Kubernetes API로 사용되어 게이트웨이의 생명 주기를 관리할 수 있으며, 매우 강력합니다. Istio, Kong, Traefik 등 많은 Ingress 컨트롤러가 이를 적극적으로 지원합니다. 불행히도, Ingress NGXIN은 아직 Gateway API를 지원할 계획이 없습니다 (Gateway API 구현 상태), 반면 APISIX Ingress는 이미 Gateway API의 대부분 기능을 지원합니다: HTTPRoute, TCPRoute, TLSRoute, UDPRoute 등.

요약

APISIX Ingress와 Ingress NGINX를 철저히 비교한 후, 두 오픈소스 소프트웨어가 모두 훌륭하며 두 가지의 핵심 기능이 유사하다는 결론을 내릴 수 있습니다. 그러나 마이크로서비스 아키텍처에서 APISIX Ingress는 헬스 체크 및 서킷 브레이커를 제공하여 서비스 거버넌스 및 서비스 디스커버리 지원에서 더 많은 장점을 보입니다.

Ingress NGINX는 단순성과 사용 편의성이 특징이며, 기능 확장의 어려움과 같은 몇 가지 명백한 단점이 있습니다. 후발 주자인 APISIX Ingress는 NGINX의 핫 리로딩 문제를 해결하고 더 나은 확장성과 기능을 제공합니다. 예를 들어, Gateway API 및 CRD를 지원하여 Ingress 컨트롤러의 프로젝트 개발 측면에서 능력을 풍부하게 합니다.

요약하면, 더 풍부한 기능과 더 나은 확장성을 가진 Ingress 컨트롤러를 선택하려면 APISIX Ingress를 강력히 추천합니다. Ingress 컨트롤러에 처음 접하고 많은 기능 요구가 없다면, Ingress NGINX도 단순성 때문에 좋은 선택입니다.