GKE Inference Gateway를 v1alpha2에서 v1로 마이그레이션

이 페이지에서는 GKE Inference Gateway 설정을 프리뷰 v1alpha2 API에서 정식 버전 v1 API로 마이그레이션하는 방법을 설명합니다.

이 문서는 GKE Inference Gateway의 v1alpha2 버전을 사용하고 최신 기능을 사용하기 위해 v1 버전으로 업그레이드하려는 플랫폼 관리자 및 네트워킹 전문가를 대상으로 합니다.

마이그레이션을 시작하기 전에 GKE Inference Gateway의 개념과 배포를 숙지해야 합니다. GKE Inference Gateway 배포를 검토하는 것이 좋습니다.

시작하기 전에

마이그레이션을 시작하기 전에 이 가이드를 따라야 하는지 확인합니다.

기존 v1alpha2 API 확인

v1alpha2 GKE Inference Gateway API를 사용 중인지 확인하려면 다음 명령어를 실행합니다.

kubectl get inferencepools.inference.networking.x-k8s.io --all-namespaces
kubectl get inferencemodels.inference.networking.x-k8s.io --all-namespaces

이 명령어의 출력에 따라 마이그레이션이 필요한지 결정됩니다.

  • 명령어 중 하나라도 하나 이상의 InferencePool 또는 InferenceModel 리소스를 반환하면 v1alpha2 API를 사용 중이므로 이 가이드를 따라야 합니다.
  • 두 명령어 모두 No resources found를 반환하면 v1alpha2 API를 사용하지 않는 것입니다. v1 GKE Inference Gateway를 새로 설치하면 됩니다.

마이그레이션 경로

v1alpha2에서 v1로 마이그레이션하는 경로는 두 가지가 있습니다.

  • 간단한 마이그레이션 (다운타임 포함): 이 경로는 더 빠르고 간단하지만 짧은 다운타임이 발생합니다. 제로 다운타임 마이그레이션이 필요하지 않은 경우 권장되는 경로입니다.
  • 제로 다운타임 마이그레이션: 이 경로는 서비스 중단을 감당할 수 없는 사용자를 위한 것입니다. v1alpha2v1 스택을 나란히 실행하고 트래픽을 점진적으로 이동하는 방식입니다.

간단한 마이그레이션 (다운타임 포함)

이 섹션에서는 다운타임이 있는 간단한 마이그레이션을 실행하는 방법을 설명합니다.

  1. 기존 v1alpha2 리소스 삭제: v1alpha2 리소스를 삭제하려면 다음 옵션 중 하나를 선택합니다.

    옵션 1: Helm을 사용하여 제거

    helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
    

    옵션 2: 리소스 수동 삭제

    Helm을 사용하지 않는 경우 v1alpha2 배포와 연결된 모든 리소스를 수동으로 삭제합니다.

    • v1alpha2 InferencePool을 가리키는 backendRef를 삭제하도록 HTTPRoute를 업데이트하거나 삭제합니다.
    • v1alpha2 InferencePool, 이를 가리키는 InferenceModel 리소스, 상응하는 엔드포인트 선택기 (EPP) 배포 및 서비스를 삭제합니다.

    모든 v1alpha2 커스텀 리소스가 삭제되면 클러스터에서 커스텀 리소스 정의 (CRD)를 삭제합니다.

    kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
    
  2. v1 리소스 설치: 이전 리소스를 정리한 후 v1 GKE Inference Gateway를 설치합니다. 이 프로세스에는 다음이 포함됩니다.

    1. v1 커스텀 리소스 정의 (CRD)를 설치합니다.
    2. v1 InferencePool 및 상응하는 InferenceObjective 리소스를 만듭니다. InferenceObjective 리소스는 여전히 v1alpha2 API에 정의되어 있습니다.
    3. 트래픽을 새 v1 InferencePool로 전달하는 새 HTTPRoute를 만듭니다.
  3. 배포 확인: 몇 분 후에 새 v1 스택이 트래픽을 올바르게 처리하는지 확인합니다.

    1. 게이트웨이 상태가 PROGRAMMED인지 확인합니다.

      kubectl get gateway -o wide
      

      다음과 같이 출력되어야 합니다.

      NAME                CLASS                            ADDRESS        PROGRAMMED   AGE
      inference-gateway   gke-l7-regional-external-managed   <IP_ADDRESS>   True         10m
      
    2. 요청을 전송하여 엔드포인트를 확인합니다.

      IP=$(kubectl get gateway/inference-gateway -o jsonpath='{.status.addresses[0].value}')
      PORT=80
      curl -i ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -d '{"model": "<var>YOUR_MODEL</var>","prompt": "<var>YOUR_PROMPT</var>","max_tokens": 100,"temperature": 0}'
      
    3. 200 응답 코드가 포함된 성공적인 응답을 수신해야 합니다.

제로 다운타임 마이그레이션

이 마이그레이션 경로는 서비스 중단을 감당할 수 없는 사용자를 위해 설계되었습니다. 다음 다이어그램은 GKE Inference Gateway가 여러 생성형 AI 모델을 서빙하는 방법을 보여줍니다. 이는 제로 다운타임 마이그레이션 전략의 핵심 측면입니다.

모델 이름과 우선순위에 따라 요청을 다른 모델로 라우팅
그림: 모델 이름 및 우선순위에 따라 다양한 생성형 AI 모델로 요청을 라우팅하는 GKE Inference Gateway

kubectl로 API 버전 구분

제로 다운타임 마이그레이션 중에 v1alpha2v1 CRD가 모두 클러스터에 설치됩니다. 이로 인해 kubectl을 사용하여 InferencePool 리소스를 쿼리할 때 모호성이 발생할 수 있습니다. 올바른 버전과 상호작용하려면 전체 리소스 이름을 사용해야 합니다.

  • v1alpha2의 경우:

    kubectl get inferencepools.inference.networking.x-k8s.io
    
  • v1의 경우:

    kubectl get inferencepools.inference.networking.k8s.io
    

v1 API는 v1 리소스를 구체적으로 쿼리하는 데 사용할 수 있는 편리한 닉네임인 infpool도 제공합니다.

kubectl get infpool

1단계: v1 나란히 배포

이 단계에서는 기존 v1alpha2 스택과 함께 새 v1 InferencePool 스택을 배포하여 안전하고 점진적인 마이그레이션을 지원합니다.

이 단계의 모든 단계를 완료하면 다음 다이어그램과 같은 인프라가 생성됩니다.

모델 이름과 우선순위에 따라 요청을 다른 모델로 라우팅
그림: 모델 이름 및 우선순위에 따라 다양한 생성형 AI 모델로 요청을 라우팅하는 GKE Inference Gateway
  1. GKE 클러스터에 필요한 커스텀 리소스 정의 (CRD)를 설치합니다.

    • GKE 버전이 1.34.0-gke.1626000 이전인 경우 다음 명령어를 실행하여 v1 InferencePool 및 알파 InferenceObjective CRD를 모두 설치합니다.
    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/manifests.yaml
    
    • GKE 버전이 1.34.0-gke.1626000 이상인 경우 다음 명령어를 실행하여 알파 InferenceObjective CRD만 설치합니다.
    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml
    
  2. v1 InferencePool을 설치합니다.

    Helm을 사용하여 vllm-llama3-8b-instruct-ga와 같은 고유한 출시 이름으로 새 v1 InferencePool을 설치합니다. InferencePoolinferencePool.modelServers.matchLabels.app을 사용하여 알파 InferencePool과 동일한 모델 서버 포드를 타겟팅해야 합니다.

    InferencePool을 설치하려면 다음 명령어를 사용합니다.

    helm install vllm-llama3-8b-instruct-ga \
    --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_DEPLOYMENT_LABEL \
    --set provider.name=gke \
    --version RELEASE \
    oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool
    

    다음을 바꿉니다.

    • MODEL_SERVER_DEPLOYMENT_LABEL: 기존 모델 서버 포드에서 사용하는 라벨 (예: vllm-llama3-8b-instruct-preview)
    • RELEASE: 설치할 v1 Gateway API Inference Extension Helm 차트의 버전
  3. v1alpha2 InferenceObjective 리소스를 만듭니다.

    Gateway API Inference Extension의 v1.0 출시로 마이그레이션하는 과정에서 알파 InferenceModel API에서 새 InferenceObjective API로도 마이그레이션해야 합니다.

    1. 다음 YAML을 적용하여 InferenceObjective 리소스를 만듭니다.

      kubectl apply -f - <<EOF
      ---
      apiVersion: inference.networking.x-k8s.io/v1alpha2
      kind: InferenceObjective
      metadata:
        name: food-review
      spec:
        priority: 2
        poolRef:
          group: inference.networking.k8s.io
          name: vllm-llama3-8b-instruct-ga
      ---
      apiVersion: inference.networking.x-k8s.io/v1alpha2
      kind: InferenceObjective
      metadata:
        name: base-model
      spec:
        priority: 2
        poolRef:
          group: inference.networking.k8s.io
          name: vllm-llama3-8b-instruct-ga
      ---
      EOF
      

2단계: 트래픽 이동

두 스택이 모두 실행되면 트래픽을 분할하도록 HTTPRoute를 업데이트하여 v1alpha2에서 v1 로 트래픽을 이동할 수 있습니다. 이 예에서는 50:50 분할을 보여줍니다.

  1. 트래픽 분할을 위해 HTTPRoute를 업데이트합니다.

    트래픽 분할을 위해 HTTPRoute를 업데이트하려면 다음 명령어를 실행합니다.

    kubectl apply -f - <<EOF
    ---
    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: llm-route
    spec:
      parentRefs:
      - group: gateway.networking.k8s.io
        kind: Gateway
        name: inference-gateway
      rules:
      - backendRefs:
        - group: inference.networking.x-k8s.io
          kind: InferencePool
          name: vllm-llama3-8b-instruct-preview
          weight: 50
        - group: inference.networking.k8s.io
          kind: InferencePool
          name: vllm-llama3-8b-instruct-ga
          weight: 50
    ---
    EOF
    
  2. 확인 및 모니터링합니다.

    변경사항을 적용한 후 새 v1 스택의 성능과 안정성을 모니터링합니다. inference-gateway 게이트웨이의 PROGRAMMED 상태가 TRUE인지 확인합니다.

3단계: 마무리 및 정리

v1 InferencePool이 안정적인지 확인한 후 모든 트래픽을 이 풀로 전달하고 이전 v1alpha2 리소스를 사용 중단할 수 있습니다.

  1. 트래픽의 100% 를 v1 InferencePool로 이동합니다.

    트래픽의 100%를 v1 InferencePool로 이동하려면 다음 명령어를 실행합니다.

    kubectl apply -f - <<EOF
    ---
    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: llm-route
    spec:
      parentRefs:
      - group: gateway.networking.k8s.io
        kind: Gateway
        name: inference-gateway
      rules:
      - backendRefs:
        - group: inference.networking.k8s.io
          kind: InferencePool
          name: vllm-llama3-8b-instruct-ga
          weight: 100
    ---
    EOF
    
  2. 최종 확인을 실행합니다.

    모든 트래픽을 v1 스택으로 전달한 후 예상대로 모든 트래픽을 처리하는지 확인합니다.

    1. 게이트웨이 상태가 PROGRAMMED인지 확인합니다.

      kubectl get gateway -o wide
      

      다음과 같이 출력되어야 합니다.

      NAME                CLASS                              ADDRESS           PROGRAMMED   AGE
      inference-gateway   gke-l7-regional-external-managed   <IP_ADDRESS>   True                     10m
      
    2. 요청을 전송하여 엔드포인트를 확인합니다.

      IP=$(kubectl get gateway/inference-gateway -o jsonpath='{.status.addresses[0].value}')
      PORT=80
      curl -i ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -d '{
      "model": "YOUR_MODEL",
      "prompt": "YOUR_PROMPT",
      "max_tokens": 100,
      "temperature": 0
      }'
      
    3. 200 응답 코드가 포함된 성공적인 응답을 수신해야 합니다.

  3. v1alpha2 리소스를 정리합니다.

    v1 스택이 완전히 작동하는지 확인한 후 이전 v1alpha2 리소스를 안전하게 삭제합니다.

  4. 남은 v1alpha2 리소스를 확인합니다.

    이제 v1 InferencePool API로 마이그레이션했으므로 이전 CRD를 삭제해도 됩니다. 기존 v1alpha2 API를 확인하여 더 이상 사용 중인 v1alpha2 리소스가 없는지 확인합니다. 여전히 남아 있는 리소스가 있으면 해당 리소스에 대한 마이그레이션 프로세스를 계속할 수 있습니다.

  5. v1alpha2 CRD를 삭제합니다.

    모든 v1alpha2 커스텀 리소스가 삭제되면 클러스터에서 커스텀 리소스 정의 (CRD)를 삭제합니다.

    kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
    

    모든 단계를 완료하면 인프라가 다음 다이어그램과 유사해야 합니다.

    모델 이름과 우선순위에 따라 요청을 다른 모델로 라우팅
    그림: 모델 이름 및 우선순위에 따라 다양한 생성형 AI 모델로 요청을 라우팅하는 GKE Inference Gateway

다음 단계