KANS3 - Kong API Gateway 버전 업그레이드 전략

    Study   container Kubernetes netrwork service ipvs loadbalancer kans3  Comments

버전 업그레이드를 해야하는 이유와 규칙

Google Cloud에서 운영중인 데이터 서비스용 K8s는 외부에서는 데이터를 전송 받고, 내부로는 데이터 관련 내부 서비스를 운영하고 있습니다. 앞선 포스트에서 기재한것처럼 저는 K8s에서 Kong API Gateway와 GKE Ingresss 오브젝트를 통해 Google Cloud의 Application Load Balancer를 생성/컨트롤 하며 사용중인데요.

OSS 기반의 어플리케이션을 운영하다보면 기능의 부재, 버그등의 문제로 버전 업그레이드가 필요한 경우가 발생하게 됩니다. 내부 서비스는 내부 구성원 서비스다보니 명확하게 사용하는 시간대가 정해져있어 문제가 없지만, 외부 서비스의 경우 24/7/365로 쉬지않고 운영하게 됩니다. 더군다나 ISMS-P 인증등 인증 요건에 패치관리 부분을 통해 가능한 최신 버전을 사용해야 하는 부분도 있습니다.

이러한 현실이 있다보니 제가 관리하는 시스템들에 대해서는 분기별로 OS/Application 패치 작업을 진행하는데요. 여기에 사용중인 API Gateway인 Kong도 버전 업그레이드를 하게 됩니다. 패치 시즌이 다가오면 나름의 긴장을하며 작업을 하지만, 버전 관리에 대해서 규칙을 세워놓고 운영하고 있습니다.

  1. 운영환경은 최신 메이저 버전의 2개 낮은 버전으로 배포/운영한다.
  2. 개발환경은 최신 메이저 버전의 1개 낮은 버전으로 배포/운영한다.

이렇게 하면 분기별로 버전 업그레이드 하는데 안정성을 어느정도는 확인이 되기 때문에 버전 업그레이드로 인한 버그 등 문제 발생 여지를 조금이라도 줄이는도움이 됩니다.

이제 이 이야기와 Service의 LoadBalancer가 어떠한 관계성이 있는지 이야기 해보겠습니다.

이전 포스트에서 저희는 Google Cloud의 Application Load Balancer를 GKE내부의 Ingress API를 사용하여 구성, 운영하고 있습니다.

Kong API Gateway를 운영하는데 있어 버전업그레이드시 Ingress와 연계되는 BackendConfig 오브젝트에 연결된 서비스를 교체하게 되면 생각보다 트래픽이 단절되는 시간이 발생하게 됩니다. 그렇기에 단절되는 시간을 최소화하는 방식으로 버전 업그레이드를 진행하게 되는데요.

그 방식은 Service 오브젝트에 지정하는 Selector의 Target을 변경함으로써 최소한의 트래픽 손실을 가져가게 됩니다. 오래 전 테스트시 Ping 1~2개 정도 빠지는 수준에서 빠르게 전환이 되었기에 해당 방식을 사용하고 있습니다.

Kong 버전 업그레이드를 진행하는 방식을 소개 합니다.

Kong API Gateway 버전 업그레이드 진행 순서

  1. Kong DB 백업 및 신규 DB로의 Restore

Kong에는 DB Less 모드가 있지만, 안정적인 운영을 위해서 PostgreSQL을 연동해서 사용하고 있습니다. 그렇다보니 신규 버전으로 올라갈때마다 DB도 신규 버전에 맞게 마이그레이션을 진행해야 합니다.

그렇기에 가능한 운영중인 버전에 대해 영향이 없도록 다음과 같이 작업합니다.

  • Old Version용 DB 백업
  • New Version용 DB에 복구
  • 신규 DB를 대상으로 migration 작업 진행
  1. 신규 버전 Kong 관련 리소스 배포

저는 일전에 kans 스터디에 참가해서 마지막 과제로 이러한 글을 작성했었는데요.

실제로 이러한 작업으로 대다수의 오브젝트는 그래도 사용하기 때문에, 신규 버전을 위해 2가지 오브젝트를 구성하고 배포합니다.

오브젝트

  • Deployment
  • HPA
  1. Service의 Selector 항목의 target을 신규 버전으로 변경
# K8s에 배포된 기존 Service
apiVersion: v1
kind: Service
metadata:
  namespace: kong
  name: kong-admin
spec:
  ports:
    - name: admin
      port: 8000
  selector:
    app: kong-{old version}-admin
  type: ClusterIP

# 신규 버전용 Service
apiVersion: v1
kind: Service
metadata:
  namespace: kong
  name: kong-admin
spec:
  ports:
    - name: admin
      port: 8000
  selector:
    app: kong-{new version}-admin # Selector 대상만 교체하여 신규 버전으로 변경
  type: ClusterIP
  1. 신규 Kong POD의 로그에서 트래픽이 정상 인입되는지 확인

이렇게 4단계로 진행하게 되는데요. 위에서 기재했던 것처럼 GKE내부에서의 전환이다보니 트래픽의 손실을 최소화 하면서 Kong Gateway의 신규 버전으로 변경할수 있었습니다. 마지막으로, 제가 하는 방식이 좋은 방식은 아닐수 있지만, 많은 도움이 되었으면 합니다.

ysyukrData Engineer

계속해서 공부하고, 나누려고 합니다.