GKE에서 GatewayAPI 사용하기

안녕하세요. 이번 블로그에서는 여러분들과 함께 GKE에서 Gateway API에 대해서 알아보고 간단하게 배포해 보려 합니다.

그런데 그전에 먼저 GatewayAPI가 뭔지 알아야 겠네요. GatewayAPI가 뭘까요? API Gateway는 들어본거 같은데, 그거랑 비슷한거 아니야? 하실 수 있지만, 오히려 기존의 Kuberntest의 Ingress랑 비슷한 개념입니다.

GKE의 공식문서에서는 GatewayAPI를 다음과 같이 표현하고 있습니다.

Gateway API는 서비스 네트워킹을 위한 오픈소스 표준입니다. GatewayAPI는 다음과 같은 방법으로 인그레스 리소스를 발전시키고 개선합니다.

• 역할 중심: 게이트웨이는 클러스터 운영자, 개발자, 인프라 제공업체에 해당하는 API 리소스로 구성됩니다. 그 결과 클러스터 운영자가 팀간 조정이 없는 여러 개발자팀에서 공유 인프라를 사용하는 방법을 정의할 수 있습니다.
• 이동성: Gateway API는 여러 구현이 포함된 오픈소스 표준입니다. 이 API는 해당 환경 및 구현의 기본 기능을 지원하기 위해 유연성 및 확장성을 아직 갖고 있는 이동성이 뛰어난 코어 API(인그레스)를 촉진하는 유연한 규정 준수 개념을 사용하여 설계되었습니다. 그 결과 구현 및 환경 간에 개념 및 핵심 리소스의 일관성을 높이고 복잡성은 줄이면서 사용자 친숙성을 늘릴 수 있습니다.
• 표현성: Gateway API 리소스는 헤더 기반 일치, 트래픽 가중, 커스텀 주석을 통해 인그레스에서만 가능한 기타 기능을 위한 기본 제공 기능을 제공합니다.

출처 : 게이트웨이 | Google Kubernetes Engine(GKE)

그러나 이 문서만 가지고는 내용을 충분히 이해하기 어렵습니다. 제가 느낀 바로는 ingress와 비슷하지만, ingress는 LB를 생성하면서 URL 라우팅을 작성해야 하는 반면, GatewayAPI는 LB 리소스와 URL 라우팅을 분리하여 개발자가 인프라 담당자에게 의존하지 않고 라우팅을 수행할 수 있는 장점이 있습니다.

더 자세한 내용은 아래의 예제를 통해 확인할 수 있습니다.

Ingress.yaml 예제

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

그러나 Gateway API는 다릅니다.

GatewayAPI 및 HTTProute 예제

gatewayapi.yaml

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-http
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80

httproute.yaml

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080

이렇게 두 개의 파일을 작성합니다. 이 후, 개발자는 URL을 추가하거나, 필요에 따라 수정이 필요하면 인프라 엔지니어와 상의 없이 httproute.yaml 파일만 수정하여 배포할 수 있습니다.
간단한 구성도는 아래와 같습니다.

– Ingress 구성도

– GatewayAPI 구성도

이제 차이가 느껴지시나요? httproute.yaml 파일만 수정하면 되므로 관리와 운영이 더 간편해질 것입니다.

GatewayAPI에 대한 자세한 설명은 이 링크를 참고하세요.

여기서는 GKE 배포가 주된 내용이 아니니 링크만 드리고 넘어가겠습니다. GKE 는 노드 구성이 필요없는 autopilot 모드를 제공하고있습니다. 해당 모드로 생성하는 것을 추천드립니다.

클러스터가 배포되면 별도의 설치 없이 GKE gatewayClass를 확인할 수 있습니다.

kubectl get gatewayclass

이제 GatewayAPI를 배포해보겠습니다. 외부에서 접근 가능한 GatewayAPI를 만들기 위해 아래와 같이 gateway.yaml 파일을 만듭니다.

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80

• gatewayClassName: gke-l7-global-external-managed : 이 게이트웨이에 GatewayClass를 지정합니다. 이 게이트웨이 클래스는 전역 외부 애플리케이션 부하 분산기를 사용합니다.
• protocol : http : 게이트웨이가 http, 80 포트를 수신합니다.

배포하려면 다음을 실행합니다.
kubectl create -f gateway.yaml.

배포가 되었는지 확인합니다.
kubectl get gateway

gateway.yaml에 대한 자세한 설명은 아래 링크를 참고해주세요.

먼저 Nginx를 배포한 후 Apache를 배포하여 httproute만으로 URL 라우팅이 이루어지는 것을 살펴보겠습니다.

2.3.1 nginx 배포

Nginx 어플리케이션을 배포하려면 nginx.yaml 파일을 작성합니다.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

pod 와 서비스 배포를 확인합니다.

kubectl get pod

kubectl get svc

httproute.yaml 을 작성합니다.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: nginx-route
spec:
  parentRefs:
  - kind: Gateway
    name: external-http
  rules:
  - backendRefs:
    - port: 80
      name: nginx-service

배포하려면 다음을 실행합니다.

kubectl create -f httproute.yaml

이제 브라우저를 열고 GatewayIP로 접근하여 결과를 확인합니다.

예: http://34.117.176.68(IP 확인)

Nginx에 접근하는 것과 동일한 방식으로 간단하게 Apache를 배포하면서 LB 설정 변경 없이 HTTProute 설정만 변경해보겠습니다.

httpd.yaml 파일은 아래와 같이 작성 후 배포합니다.

apiVersion: v1
kind: Service
metadata:
  name: httpd-service
spec:
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
        - name: httpd-container
          image: httpd:latest
          command: ["/bin/bash", "-c"]
          args: ["echo 'Hello, this is /httpd path' > /usr/local/apache2/htdocs/httpd; apachectl -D FOREGROUND"]
          ports:
            - containerPort: 80

기존의 httproute.yaml 파일을 아래와 같이 수정합니다.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: nginx-route
spec:
  parentRefs:
  - kind: Gateway
    name: external-http
  rules:
  - backendRefs:
    - port: 80
        name: nginx-service
  - matches:
     - path:
        value: /httpd
     backendRefs:
     - port: 80
        name: httpd-service

수정한 내용을 배포합니다.

kubectl apply -f httproute.yaml

초록색 글자를 보면, path에 /httpd를 추가하였고, httpd-service 서비스 리소스를 연결하였습니다.
배포 한번 해보고 다시 테스트 결과를 볼까요?

보시는 바와 같이 /httpd 경로로 apache가 배포된 것을 확인 할 수 있습니다.

추후에 다른 리소스가 배포된다면, LB 구성은 건들지 않고 httproute.yaml 만 수정해서 언제든지 배포할 수 있습니다.

인프라엔지니어 눈치를 볼 필요가 없겠죠?

이렇게 GKE에서 GatewayAPI를 배포해 봤습니다. 여기 나온 내용들은 아래 링크에서 더 자세하게 확인 할 수 있습니다.
게이트웨이 배포 | Google Kubernetes Engine(GKE)

물론 가능합니다. 해당 방법에 대한 자세한 설명은 다음 링크를 참고 부탁드립니다.
게이트웨이 보호 | Google Kubernetes Engine(GKE)

네 가능합니다. 해당 방법에 대한 자세한 설명은 다음 링크를 참고 부탁드립니다.
정책을 사용하여 게이트웨이 리소스 구성 | Google Kubernetes Engine(GKE)

이 문서에서는 GKE에서 Gateway API를 사용하는 방법과 간단한 예제를 다루었습니다. 여기서 몇 가지 주요 포인트를 정리하겠습니다.

• 역할 중심 구성: Gateway는 클러스터 운영자, 개발자, 인프라 제공 업체에 해당하는 API 리소스로 구성되어 팀 간 조정 없이 여러 개발자팀에서 공유 인프라를 사용하는 방법을 정의할 수 있습니다.
• 이동성: GatewayAPI는 여러 구현이 포함된 오픈소스 표준으로, 유연성과 확장성을 갖고 있습니다. 기본 기능을 지원하여 구현 및 환경 간에 일관성을 높이고 복잡성을 줄이면서 사용자 친화성을 늘릴 수 있습니다.
• 표현성: GatewayAPI 리소스는 헤더 기반 일치, 트래픽 가중, 커스텀 주석을 통해 인그레스에서만 가능한 기타 기능을 위한 기본 제공 기능을 제공합니다.

• Ingress vs. GatewayAPI: Ingress는 LB 생성과 URL 라우팅을 동시에 작성해야하지만, GatewayAPI는 LB 리소스와 URL 라우팅을 분리하여 개발자가 라우팅을 더 유연하게 조절할 수 있습니다.

• SSL 인증서 연동 및 Cloud Armor와의 연동이 가능하며, 자세한 내용은 다음을 참고하세요.

지금까지 GKE에서 GatewayAPI를 테스트해보았습니다. Ingress에서 분리된 URL 라우팅은 관리와 운영을 더 효율적으로 만들 수 있으며, 앞으로 더 다양한 기능이 추가될 예정입니다.