Technical Service Center

Mark Church가 진행하였던 Kubernetes and the Future of Application Networking 대한 NGINX Sprint 2.0 기조 연설에서 

“API gateway, Load Balancer, 그리고 Service Mesh는 계속해서 더 유사하게 보일 뿐만 아니라 유사한 기능까지 제공할 것” 이라고 말했습니다. 

이 내용에 대해 전적으로 동의를 표하며 더 나아가 어디에서(그리고 어떻게)사용할 것인지, 작업 유형에 맞는 적합한 도구를 찾아야 된다고 덧붙입니다. 예를들면, 공격용 칼과 버터 나이프는 모두 절단이라는 기능으로 사용되지만, 아침 토스트에는 누구든 전자(공격용 칼)을 사용하지 않을 것입니다

그래서 어떤 솔루션이이 자신에게 적합한지 어떻게 결정하는가? 

간단히 설명하자면, 만약 사용자가 Kubernetes 내부에 API gateway 기능이 필요하다면 보통 YAML과 같은 native Kubernetes config 툴을 사용하여 환경을 설정하는 것이 가장 좋은 선택입니다. 

전형적으로 Ingress Controller 또는 Service Mesh가 사용됩니다. 

그러나 “나의 API gateway 도구에는 나의 Ingress Controller (또는 Service Mesh)보다 훨씬 더 많은 기능을 보유하고 있습니다. 

놓치고 있지 않습니까? 아닙니다! 

더 많은 기능이 더 나은 도구가 될 수 없습니다. 특히, 도구 복잡성이 킬러가 될 수 있는 Kubernetes 환경 내에서는요.

대부분의 Kubernetes 사용자들은 Kubernetes-native 방식으로 설정할 수 있는 방법을 선호합니다. 

그 이유는 개발 환경 또는 GitOps 환경에서의 변화를 방지하기 때문입니다. YAML의 친화적인 툴은 세가지의 주요 이점을 제공합니다.

1. North-South API Gateway Use Cases: Use an Ingress Controller

Ingress Controller는 API gateway의 많은 사용 사례를 활용하는 잠재적인 가능성을 가지고 있습니다. 

Ingress Controller에 정의된 설명 뿐만 아니라, 우리는 조직에서 Ingress Controller를 구현할 수 있는 것을 가장 중요하게 생각합니다.

샘플 시나리오#1 : Method-Level 라우팅

당신은 API 요청 안 POST Method를 거부를 Ingress controller을 사용하여 Method-level matching과 라우팅을 구현하려고 합니다. 

일부 공격자들은 API 정의를 준수하지 않은 요청 유형을 전송하여 API에서 취약성을 찾습니다. 

예를 들어, GET요청만 허용하도록 정의된 API에서 POST 요청을 전송합니다. 

Web application firewall(WAF)는 이러한 종류의 공격을 탐지할 수 없으며, 공격에 대한 요청 문자열과 본문만 검사하게 되어, 

Ingress 계층에서 API gateway를 사용하여 잘못된 요청을 차단하는 것이 가장 좋습니다. 

 예를 들어, 새로운 API /coffee/{coffee-store}/brand 가 클러스터에 추가되었다고 가정을 합시다.
첫번째 단계는 upstream field에 API를 추가하고 NGINX Ingress Controller를 사용하여 API를 노출하는 것입니다.

apiVersion: k8s.NGINX.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  tls:
    secret: cafe-secret
  upstreams:
  -name: tea
    service: tea-svc
    port: 80
  -name: coffee
    service: coffee-svc 
    port: 80

 Method-level matching을 활성화하려면, routes field에 /coffee/{coffee-store}/brand path를 추가하고 $request_method 변수를 사용하여 GET요청과 POST 요청을 구별하는 두가지의 조건을 추가해야 합니다. 

HTTP GET 방법을 사용하는 모든 트래픽은 자동적으로 커피 서비스에 전달되게 됩니다. 

POST method를 사용하는 모든 트래픽은 “Your are rejected!”라는 메시지가 있는 오류페이지로 연결되게 됩니다. 

그렇게 당신은 원치 않는 POST 트래픽으로부터 새로운 API를 보호하게 됩니다.

routes:
  - path: /coffee/{coffee-store}/brand
    matches:
    - conditions:
      - variable: $request_method
        value: POST
        action:
          return:
            code: 403
            type: text/plain
            body: "You are rejected!"
    - conditions:
      - variable: $request_method
        value: GET
        action:
          pass: coffee
  - path: /tea
    action:
      pass:tea

 Method level routing and matching with error pages 사용하는 방법에 대한 자세한 내용은 NGINX Ingress Controller 문서를 참조하십시오. 

API gateway 기능에 Ingress Controller를 사용하는 보안 관련 예제는 블로그에서 Implementing OpenID Connect Authentication for Kubernetes with Okta and NGINX Ingress Controller를 참조 바랍니다.

( URL : https://www.nginx.com/blog/implementing-openid-connect-authentication-kubernetes-okta-and-nginx-ingress-controller/ ) 

2. East-West API Gateway Use Cases: Use a Service Mesh

대부분의 API gateway 사용사례에서는 Service Mesh가 필요하지 않거나 초기에만 도움이 되었습니다. 

그 이유는 당신이 성취하고 싶은 것의 대부분은 Ingress layer 에서 일어날 수 있고, 그래야 하기 때문입니다. 하지만 아키텍처의 복잡성이 증가할수록 Service Mesh를 사용하여 가치를 얻는 가능성이 더 많습니다. 

우리가 생각하는 가장 유익한 사용사례는 E2EE와 트래픽 분할과 관련 있습니다. A/B testing, canary 배포, 그리고 blue green 배포 같은 것들이 예시입니다. 

샘플 시나리오#2 : Canary 배포

당신은 HTTP/S 표준에 따라 조건부 라우팅을 사용하여 서비스 간에 canary 배포를 설정하려고 합니다. 

장점으로 당신은 대부분의 생산 트래픽에 영향 없이 새로운 기능 또는 새로운 버전 같은 API 변경사항을 점진적으로 롤 아웃 할 수 있습니다.

 ( Roll out: 주기억장치 가운데에서 사용하지 않은 프로그램 또는 우선도가 낮은 프로그램을 보조기억장치로 옮기는 일 ) 

현재 NGINX Ingress Controller는 NGINX Service Mesh에서 관리하는 두 서비스인 Coffee.frontdoor.svc 와 Tea.frontdoor.svc간에 트래픽을 라우팅합니다. 

이러한 서비스는 NGINX Ingress Controller에서 트래픽을 수신하여 Tea.cream1.svc를 포함한 적절한 앱 기능으로 라우팅합니다. 

당신은 새로운 버전의 Tea.cream2.svc를 호출하여 Tea.cream1.svc를 refactor를 결정합니다. 

당신은 당신의 베타 테스터가 새로운 기능에 대한 피드백을 제공하길 원합니다. 

그래서 베타 테스터의 고유 세션 쿠키를 기반으로 canary트래픽 분할을 구성하여 일반 사용자가 Tea.cream1.svc만 경험할 수 있도록 보장합니다.

NGINX Service Mesh를 사용하면 Tea.cream1.svc 와 Tea.cream2.svc를 포함하여 Tea.frontdoor.svc가 제공하는 모든 서비스간에 트래픽 분할을 시작합니다. 

조건부 라우팅을 활성화하려면 당신은 HTTPRouteGroup 리소스(tea-hrg 명칭)를 만들고 이를 트래픽 분할과 연결하세요. 그 결과, 베타 사용자의 요청 (cookie : beta)만 라우팅이 되게 됩니다.

 Tea.frontdoor.svc 에서 Tea.cream2.svc.로 당신의 일반 사용자들은 Tea.frontdoor.svc의 뒤에있는 Version 1 서비스만 계속 경험하게 됩니다.

apiVersion: split.smi-spec.io/v1alpha3
kind: TrafficSplit
metadata:
  name: tea-svc
spec:
  service: tea.1
  backends:
  - service: tea.1
    weight: 0
  - service: tea.2
    weight: 100
  matches:
  - kind: HTTPRouteGroup
    name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
  name: tea-hrg
  namespace: default
spec:
  matches:
  - name: beta-session-cookie
    headers:
    - cookie: "version=beta"

이 예제는 0-100 분할로 canary 배포를 시작합니다.

다시 말하자면 당신의 모든 베타 테스터가 Tea.cream2.svc를 경험 하지만 당신의 베타 테스트 전략에 맞는 비율로 시작할 수 있습니다. 

베타 테스트가 완료되면 간단한 canary 배포(쿠키 라우팅 없이)를 사용하여 Tea.cream2.svc.의 장애 허용력을 테스트할 수 있습니다.

( Resilience(장애허용력): 컴퓨터 시스템이 구성 요소의 오동작과 상관없이 정확하게 동작하는 능력 ) 

NGINX Service Mesh 를 사용한 트래픽 분할에 대한 자세한 내용은 문서를 확인하길 바랍니다. 위의 트래픽 분할 구성은 Root Service 가 백 엔드 서비스의 목록에 포함되어 있기 때문에 참조입니다. 이 구성은 현재 Service Mesh Interface Specification (smi-spec)에서 지원되지 않지만 스펙은 Alpha이며 변경될 수 있습니다.

3. When (and How) to Use an API Gateway Tool for Kubernetes Apps

Kubernetes를 위한 대부분의 API gateway 사용사례는 Ingress Controller 또는 Service Mesh로 처리할수 있어야 하며,
 NGINX Plus와 같은 API gateway 도구가 적합한 몇 가지 특수한 상황이 있습니다. 

비즈니스 요구사항

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

Migrating APIs into Kubernetes Environments

기존 API를 Kubernetes환경으로 마이그레이션 할 때, 해당 API를 Kubernetes 외부에 배포된 API gateway 도구에 발행할 수 있습니다. 이 시나리오에서, API 트래픽은 전형적으로 외부 Load Balancer(클러스터 간 로드 밸런싱을 위한)를 통해 라우팅 된 다음 API gateway 역할을 하도록 지정된 Load Balancer로 라우팅 됩니다. 그리고 나서 Kubernetes 클러스터 내의 Ingress Controller로 이동합니다.

Supporting SOAP APIs in Kubernetes

대부분의 최신 API 는 부분적으로 REST 를 사용하여 만들어지지만, 당신은 아직 구조가 변경되지 않은 SOAP API 를 가지고 있을지 모릅니다. 그 이유로는 RESTful또는gRPC 서비스가 Kubernetes 플랫폼의 장점을 최대한 활용할 수 있기 때문입니다. 

SOAP API 는 Kubernetes 에 권장하지 않지만, 당신은 구조가 변경할 수 있을 때까지 Kubernetes 에 SOAP API 를 배포해야 할 수도 있을 겁니다. 그 이유는 마이크로 서비스 환경에 SOAP API 가 최적화 되어있지 않기 때문입니다. API 는 REST기반 API클라이언트와 통신해야 할 가능성이 높으며, 이 경우에는 SOAP 와 REST 프로토콜 간에 변환하는 방법이 필요합니다. 당신은 Ingress controller 를 사용하여 이 기능을 수행할 수 있지만, 리소스 가 집약적으로 되기 때문에 권장하지 않습니다. 대신, SOAP 와 REST 사이를 변환하기 위해 API gateway 도구를 per-pod 또는 per-service 프록시로 변환하여 배포하는 것을 권장합니다.

API Traffic Management Both Inside and Outside Kubernetes

상대적으로 소수의 고객이 Kubernetes 내부 및 외부 환경을 포괄하는 API관리에 관심이 있습니다. 만약 API관리 전략이 Kubernetes-native 도구보다 우선순위가 높으면, Kubernetes 에 배포된 “Kubernetes-friendly” API gateway 가 올바른 선택이 될 수 있습니다.

 Kubernetes-native 도구와 달리 Kubernetes-friendly 도구는(Kubernetes-accommodative로 명명됨)는 Kubernetes를 위해 설계되지 않았으며 Kubernetes configs를 사용하여 관리할 수 없습니다. 그러나, 그들은 동작이 빠르고 가벼워 대기 시간을 추가하거나 광범위한 해결 방법을 요구하지 않고 Kubernetes에서 수행할 수 있습니다.

NGINX 시작하기

NGINX는 위 내용에 대해, 세 가지 유형의 배포 가능한 솔루션을 제공합니다.

1. NGINX Ingress Controller
고급 트래픽 제어, 모니터링 및 가시성, 인증 및 Single sing-on(SSO)을 처리하는 Kubernetes 용 Ingress controller 기반인 

NGINX Plus

2. NGINX Plus 

고가용성, 활성 상태 확인, DNS 시스템 검색, 세션 지속성 및 RESTful API 와 같은 엔터프라이즈 급 기능을 갖춘 API Gateway,
로드 밸런서, 리버스 프록시, 입니다. 전체 API 수명 주기 솔루션을 위해 NGINX Management Suite와 통합됩니다.

3. NGINX Service Mesh 

Lightweight, turnkey, and developer friendly를 엔터프라이즈의 Sidecar로써 NGINX Plus를 특징으로 하는 Service Mesh.