NGINX Gateway Fabric: 조건에 따른 라우팅

NGINX Gateway Fabric 을 사용하면 경로, 메소드, 헤더, 쿼리 매개변수 등의 요청 조건을 사용하여 애플리케이션에 라우팅할 수 있습니다. 이번 포스트에서는 다양한 NGINX Gateway Fabric의 라우팅 방식 중 경로별, 헤더별로 HTTPRoute를 배포하는 방법에 대해 설명합니다.

아래는 이번 포스트에서 사용할 규칙의 트래픽 흐름입니다.

목차

1. NGINX Gateway Fabric이란?
2. NGINX Gateway Fabric 라우팅을 위한 Pod 배포
3. Gateway 리소스 배포
4. HTTPRoute 리소스 배포

4-1. 경로별 라우팅
4-2. 헤더별 라우팅
5. NGINX Gateway Fabric 결론

1. NGINX Gateway Fabric이란?

NGINX Gateway Fabric은 NGINX를 데이터 플레인으로 사용하여 Gateway API를 구현하는 오픈 소스 프로젝트입니다.

이 프로젝트의 목표는 Kubernetes에서 실행되는 애플리케이션에 대한 HTTP 또는 TCP/UDP 로드 밸런서, 리버스 프록시 또는 API Gateway를 구성하기 위해 Gateway, GatewayClass, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute, 및 UDPRoute와 같은 핵심 Gateway API를 구현하는 것입니다.

NGINX Gateway를 설치하는 방법은 아래 포스트를 참조하세요.

이 포스트에서는 NGINX Gateway Fabric을 NodePort 타입으로 배포했습니다.

2. NGINX Gateway Fabric 라우팅을 위한 Pod 배포

라우팅을 위한 pod를 배포합니다.

coffee:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee-v1
  namespace: cafe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: coffee-v1
  template:
    metadata:
      labels:
        app: coffee-v1
    spec:
      containers:
      - name: coffee-v1
        image: nginxdemos/nginx-hello:plain-text
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-v1-svc
  namespace: cafe
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: coffee-v1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee-v2
  namespace: cafe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: coffee-v2
  template:
    metadata:
      labels:
        app: coffee-v2
    spec:
      containers:
      - name: coffee-v2
        image: nginxdemos/nginx-hello:plain-text
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-v2-svc
  namespace: cafe
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: coffee-v2

tea:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
  namespace: cafe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: nginxdemos/nginx-hello:plain-text
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  namespace: cafe
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: tea

main:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: main
  namespace: cafe
spec:
  selector:
    matchLabels:
      app: main
  template:
    metadata:
      labels:
        app: main
    spec:
      containers:
      - name: main
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: main
  namespace: cafe
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: main

3. Gateway 리소스 배포

외부 트래픽을 받기 위한 Gateway 리소스를 배포합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe-gw
  namespace: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

위 구성은 80포트에서 단일 수신을 정의합니다.

4. HTTPRoute 리소스 배포

HTTPRoute 리소스는 Gateway에서 API 객체로의 HTTP 라우팅 동작을 지정합니다.

4-1. 경로별 라우팅

http://cafe.example.com로 요청을 했을 때 main pod로 라우팅하기 위한 HTTPRoute 리소스를 배포합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe
  namespace: cafe
spec:
  parentRefs:
  - name: cafe-gw
  hostnames:
  - cafe.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: main
      port: 80

curl 명령을 사용하여 http://cafe.example.com 으로 요청합니다.

# curl http://cafe.example.com:30205

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

루트(/) 경로에서 main pod가 응답하는 것을 확인할 수 있습니다.

http://cafe.example.com/tea로 요청을 했을 때 tea pod로 라우팅하기 위한 HTTPRoute 리소스를 배포합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: tea
  namespace: cafe
spec:
  parentRefs:
  - name: cafe-gw
  hostnames:
  - cafe.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
      method: GET
    backendRefs:
    - name: tea-svc
      port: 80

curl 명령을 사용하여 http://cafe.example.com:30205/tea로 요청합니다.

# curl http://cafe.example.com:30205/tea

Server address: 10.244.2.23:8080
Server name: tea-6fbfdcb95d-5qh92
Date: 10/Jan/2025:05:09:10 +0000
URI: /tea
Request ID: c7923081c0deffcdf7623f8e6ed59c54

정상적으로 경로별 라우팅이 되는 것을 확인할 수 있습니다.

4-2. 헤더별 라우팅

http://cafe.example.com/coffee로 요청을 했을 때 헤더에 따른 coffee pod로 라우팅하기 위한 HTTPRoute 리소스를 배포합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
  namespace: cafe
spec:
  parentRefs:
  - name: cafe-gw
    sectionName: http
  hostnames:
  - cafe.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-v1-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
      headers:
      - name: version
        value: v2
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-v2-svc
      port: 80

위와 같이 구성했을 때, 헤더가 없으면 coffee-v1 pod로, 헤더에 “version: v2″가 포함되어 있으면 coffee-v2 pod로 라우팅하게 됩니다.

curl 명령을 사용하여 http://cafe.example.com:30205/coffee로 요청합니다.

# curl cafe.example.com:30205/coffee

Server address: 10.244.1.159:8080
Server name: coffee-v1-767764946-l88gz
Date: 10/Jan/2025:05:22:47 +0000
URI: /coffee
Request ID: c17c0367b90a246d9efdd71ba83cc052

헤더에 “version: v2″를 추가하여 요청합니다.

# curl -H "version: v2" cafe.example.com:30205/coffee

Server address: 10.244.1.158:8080
Server name: coffee-v2-677787799d-cjzpq
Date: 10/Jan/2025:05:23:55 +0000
URI: /coffee
Request ID: e300e9cc7152ab1e7c234b9027bd1bf5

5. NGINX Gateway Fabric 결론

위와 같이 NGINX Gateway Fabric을 사용하여 간단한 구성으로 경로별과 헤더 별로 라우팅을 구현할 수 있습니다.

NGINX Gateway Fabric을 사용하면 경로, 헤더 조건 뿐만 아니라 다양한 요청 조건을 사용하여 애플리케이션에 라우팅할 수 있습니다.

이 외에도 NGINX Gateway Fabric을 사용하여 HTTP redirect 및 rewrite, HTTPS termination, backend 트래픽 보안 등 다양한 traffic management를 사용할 수 있습니다.

NGINX Gateway Fabric의 상업용 버전을 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 논의하십시오.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required