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

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

이 문서는 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로 마이그레이션하는 방법에는 두 가지가 있습니다.

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

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

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

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

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

    helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
    

    옵션 2: 리소스 수동 삭제

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

    • HTTPRoute를 업데이트하거나 삭제하여 v1alpha2 InferencePool를 가리키는 backendRef를 삭제합니다.
    • 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 버전 구분

무중단 마이그레이션 중에 v1alpha2 및 v1 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)를 설치합니다.

    • 1.34.0-gke.1626000 이전 GKE 버전의 경우 다음 명령어를 실행하여 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를 설치합니다. InferencePool은 inferencePool.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 추론 확장 프로그램 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. 트래픽을 v1 InferencePool로 100% 이동합니다.

    트래픽을 v1 InferencePool로 100% 전환하려면 다음 명령어를 실행합니다.

    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

다음 단계