העברה של GKE Inference Gateway מגרסה v1alpha2 לגרסה v1

בדף הזה מוסבר איך להעביר את ההגדרה של GKE Inference Gateway מגרסת הטרום-השקה של v1alpha2 API לגרסה הזמינה לכולם של v1 API.

המסמך הזה מיועד לאדמינים של פלטפורמות ולמומחי רשתות שמשתמשים בגרסה v1alpha2 של GKE Inference Gateway ורוצים לשדרג לגרסה 1 כדי להשתמש בתכונות העדכניות ביותר.

לפני שמתחילים בהעברה, חשוב להכיר את המושגים ואת הפריסה של GKE Inference Gateway. מומלץ לקרוא את המאמר פריסת GKE Inference Gateway.

לפני שמתחילים

לפני שמתחילים בהעברה, צריך לקבוע אם צריך לפעול לפי המדריך הזה.

בדיקה אם קיימים ממשקי API בגרסה v1alpha2

כדי לבדוק אם אתם משתמשים ב-API של v1alpha2 GKE Inference Gateway, מריצים את הפקודות הבאות:

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, אתם לא משתמשים ב-API‏ v1alpha2. אפשר להמשיך בהתקנה חדשה של v1 GKE Inference Gateway.

נתיבי העברה

יש שתי דרכים להעברה מ-v1alpha2 ל-v1:

  • העברה פשוטה (עם זמן השבתה): הדרך הזו מהירה ופשוטה יותר, אבל היא גורמת לזמן השבתה קצר. זהו הנתיב המומלץ אם אתם לא צריכים לבצע העברה ללא השבתה.
  • העברה ללא השבתה: האפשרות הזו מתאימה למשתמשים שלא יכולים להרשות לעצמם הפסקה בשירות. התהליך כולל הפעלה של שני סטאקים, v1alpha2 ו-v1, זה לצד זה, והעברה הדרגתית של התנועה.

העברה פשוטה (עם זמן השבתה)

בקטע הזה מוסבר איך לבצע העברה פשוטה עם זמן השבתה.

  1. מחיקת v1alpha2 משאבים קיימים: כדי למחוק את v1alpha2 המשאבים, בוחרים באחת מהאפשרויות הבאות:

    אפשרות 1: הסרה באמצעות Helm

    helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
    

    אפשרות 2: מחיקת משאבים באופן ידני

    אם אתם לא משתמשים ב-Helm, אתם צריכים למחוק באופן ידני את כל המשאבים שמשויכים לפריסת v1alpha2:

    • מעדכנים או מוחקים את HTTPRoute כדי להסיר את backendRef שמפנה אל v1alpha2 InferencePool.
    • מוחקים את v1alpha2 InferencePool, את כל משאבי InferenceModel שמפנים אליו, ואת הפריסה והשירות התואמים של Endpoint Picker (EPP).

    אחרי שמוחקים את כל המשאבים המותאמים אישית v1alpha2, מסירים את Custom Resource Definitions (הגדרות של משאבים מותאמים אישית, CRD) מהאשכול:

    kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
    
  2. התקנת משאבים בגרסה 1: אחרי שמנקים את המשאבים הישנים, מתקינים את v1 GKE Inference Gateway. התהליך הזה כולל את השלבים הבאים:

    1. מתקינים את v1הגדרות המשאבים המותאמות אישית (CRD) החדשות.
    2. יוצרים v1 InferencePool חדש ומשאבי InferenceObjective תואמים. המשאב InferenceObjective עדיין מוגדר ב-API‏ v1alpha2.
    3. יוצרים HTTPRoute חדש שמפנה תנועה אל v1 החדש InferencePool.
  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 גנרטיבי, שהוא היבט מרכזי באסטרטגיית מעבר ללא השבתה.

ניתוב בקשות למודלים שונים על סמך שם המודל והעדיפות
איור: GKE Inference Gateway מעביר בקשות ניתוב למודלים שונים של AI גנרטיבי על סמך שם המודל והעדיפות

הבחנה בין גרסאות API באמצעות kubectl

במהלך ההעברה ללא השבתה, שני ה-CRD‏ v1alpha2 ו-v1 מותקנים באשכול. זה יכול ליצור אי-בהירות כשמשתמשים ב-kubectl כדי לשלוח שאילתות לגבי משאבי InferencePool. כדי לוודא שאתם משתמשים בגרסה הנכונה, אתם צריכים להשתמש בשם המשאב המלא:

  • עבור v1alpha2:

    kubectl get inferencepools.inference.networking.x-k8s.io
    
  • עבור v1:

    kubectl get inferencepools.inference.networking.k8s.io
    

ב-API של v1 יש גם שם מקוצר ונוח, infpool, שבו אפשר להשתמש כדי לשלוח שאילתות למשאבים של v1 באופן ספציפי:

kubectl get infpool

שלב 1: פריסה של גרסה 1 לצד גרסה 2

בשלב הזה, פורסים את מחסנית v1 InferencePool החדשה לצד מחסנית v1alpha2 הקיימת, וכך מתאפשרת העברה בטוחה והדרגתית.

אחרי שתסיימו את כל השלבים, תהיה לכם התשתית שמוצגת בתרשים הבא:

ניתוב בקשות למודלים שונים על סמך שם המודל והעדיפות
איור: GKE Inference Gateway מעביר בקשות ניתוב למודלים שונים של AI גנרטיבי על סמך שם המודל והעדיפות
  1. מתקינים את ההגדרות הנדרשות של משאבים מותאמים אישית (CRD) באשכול GKE:

    • בגרסאות GKE קודמות לגרסה 1.34.0-gke.1626000, מריצים את הפקודה הבאה כדי להתקין את ה-CRD של גרסה v1‏ InferencePool ואת ה-CRD של גרסת אלפא InferenceObjective:
    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 ואילך, מתקינים רק את ה-CRD של אלפא InferenceObjective באמצעות הפקודה הבאה:
    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 כדי להתקין v1 InferencePool חדש עם שם גרסה ייחודי, כמו vllm-llama3-8b-instruct-ga. ה-InferencePool צריך לטרגט לאותם פודים של שרת המודל כמו ה-InferencePool של גרסת האלפא, באמצעות inferencePool.modelServers.matchLabels.app.

    כדי להתקין את 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: הגרסה של תרשים ה-Helm של v1 Gateway API Inference Extension שרוצים להתקין
  3. יצירת משאבים מסוג v1alpha2 InferenceObjective.

    במסגרת המעבר לגרסה 1.0 של Gateway API Inference Extension, צריך גם לעבור מ-API אלפא InferenceModel ל-API החדש InferenceObjective.

    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: העברת התנועה

אחרי ששתי החבילות יפעלו, תוכלו להתחיל להעביר תנועה מ-v1alpha2 אל v1 על ידי עדכון HTTPRoute כדי לפצל את התנועה. בדוגמה הזו מוצגת חלוקה של 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

    עכשיו, אחרי שביצעתם מיגרציה ל-API‏ v1 InferencePool, אפשר למחוק את ה-CRD הישנים. בודקים אם יש ממשקי API קיימים בגרסה v1alpha2 כדי לוודא שאין יותר משאבי 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
    

    אחרי השלמת כל השלבים, התשתית שלכם אמורה להיראות כמו בדיאגרמה הבאה:

    ניתוב בקשות למודלים שונים על סמך שם המודל והעדיפות
    איור: GKE Inference Gateway מעביר בקשות ניתוב למודלים שונים של AI גנרטיבי על סמך שם המודל והעדיפות

המאמרים הבאים