어떻게 선택해야 하나요? API 게이트웨이 대 Ingress 컨트롤러와 서비스 메시

2021년 내내 제공한 Ingress 컨트롤러 및 서비스 메시에 대한 거의 모든 웨비나에서 "이 도구는 API 게이트웨이와 어떻게 다릅니까?" 또는 "Kubernetes에서 API 게이트웨이와 Ingress 컨트롤러(또는 서비스 메시)가 모두 필요한가요?"와 같은 다양한 질문을 들었습니다.

혼란은 두 가지 이유에서 완전히 이해할 수 있습니다.

• Ingress 컨트롤러와 서비스 메시는 다양한 API 게이트웨이 사용 사례를 충족할 수 있습니다.
• 일부 공급업체는 API 게이트웨이 도구를 Ingress 컨트롤러나 서비스 메시를 사용하는 대안으로 포지셔닝하거나 세 가지 기능을 모두 하나의 도구로 통합합니다.

이 블로그에서는 이러한 도구의 차이점과 Kubernetes 특정 API 게이트웨이 사용 사례에 어떤 도구를 사용해야 하는지 살펴보겠습니다. 데모를 포함하여 더 자세히 알아보려면 Kubernetes를 위한 API Gateway 사용 사례 웨비나를 시청하세요.

정의

API 게이트웨이, Ingress 컨트롤러, 서비스 메시는 본질적으로 각각 프록시 유형으로서, 사용자 환경 내부와 주변 환경으로 트래픽을 유도하도록 설계되었습니다.

API 게이트웨이란 무엇입니까?

API 게이트웨이는 클라이언트의 API 요청을 적절한 서비스로 라우팅합니다. 하지만 이 간단한 정의에 대한 큰 오해는 API 게이트웨이가 고유한 기술이라는 생각입니다. 그렇지 않아요. 오히려 "API 게이트웨이"는 다양한 유형의 프록시(가장 일반적인 ADC 또는 부하 분산 장치 및 역방향 프록시, 그리고 점점 더 많은 Ingress 컨트롤러 또는 서비스 메시)를 통해 구현할 수 있는 일련의 사용 사례를 설명합니다.

API 게이트웨이 역할을 하는 도구에 "필수" 기능이 무엇인지에 대해 업계에서는 많은 합의가 이루어지지 않았습니다. 일반적으로 다음과 같은 기능이 필요한 고객을 볼 수 있습니다(사용 사례별로 그룹화):

회복성 사용 사례

• A/B 테스트, 카나리아 배포 및 블루-그린 배포
• 프로토콜 변환(예: JSON과 XML 간)
• 속도 제한
• 서비스 발견

교통 관리 사용 사례

• 방법 기반 라우팅 및 매칭
• 요청/응답 헤더 및 본문 조작
• 7계층에서의 요청 라우팅

보안 사용 사례

• API 스키마 적용
• 클라이언트 인증 및 권한 부여
• 사용자 정의 응답
• 세분화된 액세스 제어
• TLS 종료

이러한 사용 사례는 거의 모두 Kubernetes에서 일반적으로 사용됩니다. 프로토콜 변환과 요청/응답 헤더 및 본문 조작은 일반적으로 Kubernetes 및 마이크로서비스 환경에 적합하지 않은 레거시 API에 연결되어 있기 때문에 덜 일반적입니다.

블로그의 'API 게이트웨이로 NGINX 배포, 1부' 에서 API 게이트웨이 사용 사례에 대해 자세히 알아보세요.

인그레스 컨트롤러란?

Ingress 컨트롤러 (Kubernetes Ingress Controller, 줄여서 KIC라고도 함)는 트래픽을 Kubernetes로 보내고 서비스로 보내고 다시 내보내는(ingress‑egress 또는 north‑south 트래픽이라고 함) 특수화된 레이어 4 및 레이어 7 프록시입니다. Ingress 컨트롤러는 트래픽 관리 외에도 가시성 및 문제 해결, 보안 및 ID, 그리고 가장 고급 API 게이트웨이 사용 사례를 제외한 모든 분야에 사용할 수 있습니다.

Ingress 컨트롤러를 기본 트래픽 관리 이상의 용도로 사용하는 방법에 대해 자세히 알아보려면 Ingress 컨트롤러 선택 가이드, 1부를 참조하세요. 귀하의 요구 사항을 블로그에서 확인하세요 .

서비스 메시란?

서비스 메시는 Kubernetes 서비스 간 트래픽( 서비스 간 또는 동서 트래픽이라고 함)을 처리하며 일반적으로 종단 간 암호화(E2EE)를 달성하는 데 사용됩니다. 서비스 메시 도입은 규모는 작지만 고급 배포를 시작하거나 E2EE에 대한 요구 사항이 있는 조직이 늘어나면서 증가하고 있습니다. 서비스 메시는 앱에 매우 가까운 분산형(경량) API 게이트웨이로 사용할 수 있으며, 서비스 메시 사이드카를 통해 데이터 플레인 수준에서 사용이 가능합니다.

블로그의 서비스 메시 선택 방법에서 서비스 메시에 대해 자세히 알아보고 언제 서비스 메시를 사용할 준비가 되는지 알아보세요.

Kubernetes 환경을 위한 Kubernetes 네이티브 도구 사용

NGINX Sprint 2.0 에서 Kubernetes와 애플리케이션 네트워킹의 미래에 대한 기조연설을 한 Mark Church의 말처럼 "API 게이트웨이, 로드 밸런서, 서비스 메시는 서로 점점 더 유사해지고 유사한 기능을 제공할 것입니다." 우리는 이 진술에 전적으로 동의하며, 어디에서(그리고 어떻게) 사용할지에 따라 작업에 적합한 도구를 선택하는 것이 중요하다고 덧붙입니다. 결국, 마체테와 버터 나이프는 둘 다 자르는 데 사용되지만, 아침에 토스트를 굽는 데 마체테를 사용할 가능성은 거의 없습니다.

그러면 어떤 도구가 자신에게 맞는지 어떻게 결정하시나요? 간단하게 설명드리자면, Kubernetes 내에서 API 게이트웨이 기능이 필요한 경우 일반적으로 YAML과 같은 기본 Kubernetes 구성 도구를 사용하여 구성할 수 있는 도구를 선택하는 것이 가장 좋습니다. 일반적으로 이는 Ingress 컨트롤러나 서비스 메시입니다. 하지만 "내 API 게이트웨이 도구는 Ingress 컨트롤러(또는 서비스 메시)보다 기능이 훨씬 더 많아요. 제가 놓치고 있는 게 아닌가요?"라고 말씀하시는 게 들립니다. 아니요! 더 많은 기능이 더 나은 도구를 의미하는 것은 아닙니다. 특히 도구의 복잡성이 심각한 문제가 될 수 있는 Kubernetes 내에서는 더욱 그렇습니다.

메모: Kubernetes 네이티브 ( Knative 와 다름)는 Kubernetes를 위해 설계 및 제작된 도구를 말합니다. 일반적으로 Kubernetes CLI와 함께 작동하며 Helm을 사용하여 설치할 수 있으며 Kubernetes 기능과 통합됩니다.

대부분의 Kubernetes 사용자는 Kubernetes 기본 방식으로 구성할 수 있는 도구를 선호합니다. 이를 통해 개발이나 GitOps 환경이 변경되지 않기 때문입니다. YAML 친화적 도구는 세 가지 주요 이점을 제공합니다.

• YAML은 Kubernetes 팀에 익숙한 언어이므로 API 게이트웨이 기능을 위해 기존 Kubernetes 도구를 사용하는 경우 학습 곡선이 작거나 전혀 없습니다. 이를 통해 팀은 가끔만 사용하는 새로운 도구를 구성하는 방법을 배울 필요 없이 기존 기술 세트 내에서 작업할 수 있습니다.
• 다른 Kubernetes 도구와 같은 방식으로 YAML 친화적 도구를 자동화할 수 있습니다. 워크플로에 깔끔하게 들어맞는 것은 팀원들에게 인기가 많아서 팀원들이 이를 사용할 확률이 높아집니다.
• Ingress 컨트롤러, 서비스 메시 또는 둘 다를 사용하여 Kubernetes 트래픽 관리 도구 스택을 축소할 수 있습니다. 결국, 모든 추가 홉은 중요하며 불필요한 지연이나 단일 장애 지점을 추가할 이유가 없습니다. 물론, 쿠버네티스에 배포된 기술의 수를 줄이는 것은 예산과 전반적인 보안에도 좋습니다.

북-남 API 게이트웨이 사용 사례: Ingress 컨트롤러 사용

Ingress 컨트롤러는 다양한 API 게이트웨이 사용 사례를 구현할 수 있는 잠재력을 가지고 있습니다. 정의 에 설명된 것 외에도 조직에서는 다음을 구현할 수 있는 Ingress 컨트롤러를 가장 중요하게 여깁니다.

• 인증 및 권한 부여 오프로드
• 권한 기반 라우팅
• 7계층 라우팅 및 매칭(HTTP, HTTP/S, 헤더, 쿠키, 메서드)
• 프로토콜 호환성(HTTP, HTTP/2, WebSocket, gRPC)
• 속도 제한

샘플 시나리오: 메서드 수준 라우팅

Ingress 컨트롤러를 사용하여 API 요청에서 POST 메서드를 거부하고 메서드 수준 매칭 및 라우팅을 구현하려고 합니다.

일부 공격자는 API 정의를 준수하지 않는 요청 유형을 보내어 API의 취약점을 찾습니다. 예를 들어, GET 요청만 허용하도록 정의된 API에 POST 요청을 보내는 것입니다. 웹 애플리케이션 방화벽(WAF)은 이런 종류의 공격을 감지할 수 없습니다. 공격을 위해 요청 문자열과 본문만 검사하기 때문에 Ingress 계층에서 API 게이트웨이를 사용하여 잘못된 요청을 차단하는 것이 가장 좋습니다.

예를 들어, 새로운 API /coffee/{coffee-store}/brand가 클러스터에 추가되었다고 가정해 보겠습니다. 첫 번째 단계는 NGINX Ingress Controller를 사용하여 API를 공개하는 것입니다. API를 upstreams 필드에 추가하기만 하면 됩니다.

api 버전: k8s.nginx.org/v1kind: VirtualServer
메타데이터:
이름: cafe
스펙:
호스트: cafe.example.com
tls:
비밀: cafe-secret
업스트림:
-이름: tea
서비스: tea-svc
포트: 80
-name: 커피
서비스: 커피-서비스
포트: 80

메서드 수준 매칭을 활성화하려면 routes 필드에 /coffee/{coffee-store}/brand 경로를 추가하고 GET 및 POST 요청을 구분하기 위해 $request_method 변수를 사용하는 두 개의 조건을 추가합니다. HTTP GET 방식을 사용하는 모든 트래픽은 자동으로 커피 서비스로 전달됩니다. POST 방식을 사용하는 트래픽은 " 거부 되었습니다 !"라는 메시지가 있는 오류 페이지로 이동됩니다. 이렇게 하면 원치 않는 POST 트래픽으로부터 새 API를 보호할 수 있습니다.

경로: - 경로: /coffee/{coffee-store}/brand
일치:
- 조건:
- 변수: $request_method
값: POST
액션:
리턴:
코드: 403
유형: text/plain
본문: "거부되었습니다!"
- 조건:
- 변수: $request_method
값: GET
액션:
패스: 커피
- 경로: /tea
액션:
패스:차

메서드 수준 라우팅과 오류 페이지와의 매칭을 사용하는 방법에 대한 자세한 내용은 NGINX Ingress Controller 문서를 확인하세요. API 게이트웨이 기능을 위해 Ingress 컨트롤러를 사용하는 보안 관련 예를 보려면 블로그의 Okta와 NGINX Ingress 컨트롤러를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현을 읽어보세요.

동서 API 게이트웨이 사용 사례: 서비스 메시 사용

대부분의 API 게이트웨이 사용 사례에서는 서비스 메시가 필요하지 않으며, 처음에는 도움이 되지도 않습니다. 원하는 대부분의 작업은 Ingress 계층에서 수행할 수 있고 수행해야 하기 때문입니다. 하지만 아키텍처의 복잡성이 커질수록 서비스 메시를 사용하면 더 큰 가치를 얻을 가능성이 높습니다. 우리가 가장 유용하다고 생각하는 사용 사례는 E2EE 및 트래픽 분할 과 관련된 것입니다. 여기에는 A/B 테스트, 카나리아 배포, 블루-그린 배포가 포함됩니다.

샘플 시나리오: 카나리아 배치

HTTP/S 기준에 따른 조건부 라우팅을 사용하여 서비스 간에 카나리아 배포를 설정하려고 합니다.

장점은 프로덕션 트래픽에 영향을 주지 않고 새로운 기능이나 버전과 같은 API 변경 사항을 점진적으로 출시할 수 있다는 것입니다.

현재 NGINX Ingress Controller는 NGINX Service Mesh에서 관리하는 두 서비스 간의 트래픽을 라우팅합니다. Coffee.frontdoor.svc 와 Tea.frontdoor.svc . 이러한 서비스는 NGINX Ingress Controller로부터 트래픽을 수신하여 Tea.cream1.svc 를 비롯한 적절한 앱 기능으로 라우팅합니다. Tea.cream1.svc를 리팩토링하고 새 버전을 Tea.cream2.svc 라고 부르기로 결정했습니다. 베타 테스터가 새로운 기능에 대한 피드백을 제공하길 원하므로 베타 테스터의 고유 세션 쿠키를 기반으로 카나리아 트래픽 분할을 구성하여 일반 사용자는 Tea.cream1.svc 만 경험할 수 있도록 합니다.

NGINX 서비스 메시를 사용하면 Tea.frontdoor.svc 가 프런트엔드를 담당하는 모든 서비스( Tea.cream1.svc 및 Tea.cream2.svc 포함) 간에 트래픽 분할을 생성하는 것으로 시작합니다. 조건부 라우팅을 활성화하려면 HTTPRouteGroup 리소스(이름은 tea-hrg )를 만들고 트래픽 분할과 연결합니다. 그 결과 베타 사용자의 요청(세션 쿠키가 version=beta 로 설정된 요청)만 Tea.frontdoor.svc 에서 Tea.cream2.svc 로 라우팅됩니다. 일반 사용자는 Tea.frontdoor.svc 뒤에 있는 버전 1 서비스만 계속 사용할 수 있습니다.

api 버전: split.smi-spec.io/v1alpha3kind: TrafficSplit
메타데이터:
이름: tea-svc
스펙:
서비스: tea.1
백엔드:
- 서비스: tea.1
가중치: 0
- 서비스: tea.2
무게: 100
일치:
- 종류: HTTPRouteGroup
이름: tea-hrg

api 버전: specs.smi-spec.io/v1alpha3
종류: HTTPRouteGroup
메타데이터:
이름: tea-hrg
네임스페이스: default
스펙:
일치 항목:
- 이름: beta-session-cookie
헤더:
- 쿠키: "version=beta"

이 예제에서는 0-100 분할로 카나리아 배포를 시작합니다. 즉, 모든 베타 테스터가 Tea.cream2.svc를 경험하게 되지만 베타 테스트 전략에 맞는 비율로 시작할 수도 있습니다. 베타 테스트가 완료되면 간단한 카나리아 배포(쿠키 라우팅 없음)를 사용하여 Tea.cream2.svc 의 탄력성을 테스트할 수 있습니다.

NGINX Service Mesh를 사용한 트래픽 분할에 대한 자세한 내용은 문서를 확인하세요. 위의 트래픽 분할 구성은 루트 서비스가 백엔드 서비스로도 나열되어 있으므로 자체 참조입니다. 이 구성은 현재 서비스 메시 인터페이스 사양 ( smi-spec )에서 지원되지 않습니다. 그러나 해당 사양은 현재 알파 단계이며 변경될 수 있습니다.

Kubernetes 앱에 API Gateway 도구를 사용하는 시기(및 방법)

Kubernetes의 대부분 API 게이트웨이 사용 사례는 Ingress 컨트롤러나 서비스 메시로 처리할 수 있지만(처리해야 함) NGINX Plus와 같은 API 게이트웨이 도구가 적합한 몇몇 특수 상황도 있습니다.

비즈니스 요구 사항

여러 팀이나 프로젝트가 Ingress 컨트롤러 세트를 공유하거나 Ingress 컨트롤러를 환경별로 특화할 수 있지만, 기존 Ingress 컨트롤러를 활용하는 대신 Kubernetes 내부에 전용 API 게이트웨이를 배포하는 것을 선택할 수 있는 이유가 있습니다. Kubernetes 내에서 Ingress 컨트롤러와 API 게이트웨이를 모두 사용하면 조직이 비즈니스 요구 사항을 달성하는 데 더 많은 유연성을 제공할 수 있습니다. 일부 시나리오는 다음과 같습니다.

• 귀하의 API 게이트웨이 팀은 Kubernetes에 익숙하지 않으며 YAML을 사용하지 않습니다. 예를 들어, NGINX 구성에 익숙하다면 Kubernetes에서 NGINX Plus를 API 게이트웨이로 배포하면 마찰이 완화되고 학습 곡선도 짧아집니다.
• 플랫폼 운영팀에서는 Ingress 컨트롤러를 앱 트래픽 관리에만 전담하는 것을 선호합니다.
• 클러스터의 서비스 중 하나에만 적용되는 API 게이트웨이 사용 사례가 있습니다. Ingress 컨트롤러를 사용하여 모든 남북 트래픽에 정책을 적용하는 대신 API 게이트웨이를 배포하여 필요한 곳에만 정책을 적용할 수 있습니다.

API를 Kubernetes 환경으로 마이그레이션

기존 API를 Kubernetes 환경으로 마이그레이션할 때 Kubernetes 외부에 배포된 API 게이트웨이 도구에 해당 API를 게시할 수 있습니다. 이 시나리오에서 API 트래픽은 일반적으로 외부 로드 밸런서(클러스터 간 로드 밸런싱을 위한)를 거쳐 라우팅된 다음, API 게이트웨이 역할을 하도록 구성된 로드 밸런서로, 마지막으로 Kubernetes 클러스터 내의 Ingress 컨트롤러로 라우팅됩니다.

Kubernetes에서 SOAP API 지원

대부분의 최신 API는 REST를 사용하여 생성됩니다. RESTful 또는 gRPC 서비스와 API는 Kubernetes 플랫폼을 최대한 활용할 수 있기 때문입니다. 하지만 아직 재구성되지 않은 SOAP API가 있을 수 있습니다. SOAP API는 마이크로서비스에 최적화되지 않았기 때문에 Kubernetes에 권장되지 않지만, 재구성할 때까지 Kubernetes에 SOAP API를 배포해야 할 수도 있습니다. API는 REST 기반 API 클라이언트와 통신해야 할 가능성이 높으며, 이 경우 SOAP와 REST 프로토콜 간에 변환할 수 있는 방법이 필요합니다. Ingress 컨트롤러로 이 기능을 수행할 수는 있지만 리소스를 매우 많이 사용하므로 권장하지 않습니다. 대신, SOAP와 REST 간 변환을 위해 API 게이트웨이 도구를 Pod별 또는 서비스별 프록시로 배포하는 것이 좋습니다.

Kubernetes 내부 및 외부의 API 트래픽 관리

상대적으로 소수의 고객이 Kubernetes 환경 내부 및 외부에서 API를 관리하는 데 관심이 있습니다. API 관리 전략이 Kubernetes 기반 도구 선택보다 우선순위가 높은 경우 Kubernetes에 배포된 "Kubernetes 친화적" API 게이트웨이(API 관리 솔루션과 통합 가능)가 올바른 선택일 수 있습니다.

메모: Kubernetes 네이티브 도구와 달리 Kubernetes 친화적 도구(때로는 Kubernetes-accommodative 라고도 함)는 Kubernetes용으로 설계되지 않았으며 Kubernetes 구성을 사용하여 관리할 수 없습니다. 그러나 민첩하고 가벼워서 상당한 지연 시간을 추가하거나 광범위한 해결 방법을 요구하지 않고 Kubernetes에서 수행할 수 있습니다.

NGINX 시작하기

NGINX는 세 가지 유형의 배포 시나리오 모두에 대한 옵션을 제공합니다.

Kubernetes 네이티브 도구:

• NGINX Ingress Controller – Kubernetes 용 NGINX Plus 기반 Ingress 컨트롤러로 고급 트래픽 제어 및 셰이핑, 모니터링 및 가시성, 인증 및 SSO(Single Sign-On)를 처리합니다.
• NGINX 서비스 메시 – NGINX Plus를 엔터프라이즈 사이드카로 제공하는 가볍고 턴키 방식의 개발자 친화적인 서비스 메시입니다.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 무료 30일 체험판을 요청하고, 항상 무료인 NGINX Service Mesh를 다운로드하여 시작하세요.

Kubernetes 환경 내부 또는 외부에서 Kubernetes 친화적인 API 게이트웨이의 경우:

• NGINX Plus – 고가용성, 활성 상태 검사, DNS 시스템 검색, 세션 지속성 및 RESTful API와 같은 엔터프라이즈급 기능을 갖춘 올인원 로드 밸런서, 역방향 프록시, 웹 서버 및 API 게이트웨이. 전체 API 라이프사이클 솔루션을 위해 NGINX Controller [현재 F5 NGINX Management Suite ] 와 통합됩니다.

NGINX Plus를 API 게이트웨이로 사용하는 방법에 대해 자세히 알아보려면 무료 30일 평가판을 요청하고 NGINX를 API 게이트웨이로 배포하는 방법을 참조하세요.