האצת טעינת מודלים ב-GKE באמצעות Run:ai Model Streamer

במאמר הזה נסביר איך להאיץ את הטעינה של משקלי מודלים גדולים של AI מ-Cloud Storage באמצעות Run:ai Model Streamer עם שרת ההסקה vLLM ב-Google Kubernetes Engine ‏ (GKE).

הפתרון שמתואר במסמך הזה מבוסס על ההנחה שכבר טענתם את מודל ה-AI והמשקלים שלו בפורמט safetensors בקטגוריה של Cloud Storage.

אם מוסיפים את הדגל --load-format=runai_streamer לפריסת vLLM, אפשר להשתמש ב-Run:ai Model Streamer כדי לשפר את היעילות של הורדת המודל לעומסי העבודה של ה-AI ב-GKE.

המסמך הזה מיועד למשתמשים הבאים:

  • מהנדסי למידת מכונה (ML) שצריכים לטעון מודלים גדולים של AI מאחסון אובייקטים לצמתי GPU/TPU במהירות האפשרית.
  • אדמינים ומפעילים של פלטפורמות שמבצעים אוטומציה ואופטימיזציה של תשתית להפעלת מודלים ב-GKE.
  • ארכיטקטים של ענן שבודקים כלים מיוחדים לטעינת נתונים עבור עומסי עבודה של AI/ML.

מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שמוזכרים ב Cloud de Confiance by S3NS תוכן זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.

סקירה כללית

הפתרון שמתואר במסמך הזה משתמש בשלושה רכיבי ליבה – Run:ai Model Streamer,‏ vLLM ופורמט הקובץ safetensors – כדי להאיץ את תהליך הטעינה של משקלי המודל מ-Cloud Storage לצמתים של GPU או TPU.

‫Run:ai Model Streamer

‫Run:ai Model Streamer הוא SDK של Python בקוד פתוח שמאיץ את הטעינה של מודלים גדולים של AI למאיצים. הוא מעביר במשולב את משקלי המודל ישירות מהאחסון, כמו קטגוריות של Cloud Storage, לזיכרון של ה-GPU או ה-TPU. המודל streamer מתאים במיוחד לגישה לקבצים מסוג safetensors שנמצאים ב-Cloud Storage.

safetensors

‫safetensors הוא פורמט קובץ לאחסון טנסורים, מבני הנתונים המרכזיים במודלים של AI, באופן שמשפר את האבטחה והמהירות. ‫safetensors מיועד להיות חלופה לפורמט pickle של Python, והוא מאפשר זמני טעינה מהירים באמצעות גישה של zero-copy. הגישה הזו מאפשרת לגשת לטנסורים ישירות מהמקור בלי לטעון קודם את כל הקובץ לזיכרון המקומי.

vLLM

‫vLLM היא ספרייה בקוד פתוח להסקת מסקנות (inference) ולפרסום של מודלים גדולים של שפה (LLM). זהו שרת הסקה עם ביצועים גבוהים שעבר אופטימיזציה לטעינה מהירה של מודלים גדולים של AI. במסמך הזה, vLLM הוא מנוע הליבה שמריץ את מודל ה-AI ב-GKE ומטפל בבקשות הסקה נכנסות. כדי להשתמש בתמיכה המובנית באימות של Run:ai Model Streamer ב-Cloud Storage, צריך להשתמש ב-vLLM בגרסה 0.11.1 ואילך עבור GPU, ובגרסה 0.18.0 ואילך עבור TPU.

איך Run:ai Model Streamer מאיץ את טעינת המודל

כשמפעילים אפליקציית AI שמבוססת על LLM לצורך הסקת מסקנות, לרוב יש עיכוב משמעותי עד שהמודל מוכן לשימוש. העיכוב הזה, שנקרא הפעלה קרה, קורה כי צריך להוריד את כל קובץ המודל בגודל כמה גיגה-בייט ממיקום אחסון, כמו קטגוריה של Cloud Storage, לדיסק המקומי של המחשב. הקובץ נטען לזיכרון של המאיץ. במהלך תקופת הטעינה הזו, המאיץ היקר לא פעיל, וזה לא יעיל ויקר.

במקום תהליך ההורדה ואז הטעינה, מודל הסטרימינג מעביר את המודל בסטרימינג ישירות מ-Cloud Storage לזיכרון של ה-GPU או ה-TPU. הסטרימר משתמש בקצה עורפי (backend) עם ביצועים גבוהים כדי לקרוא במקביל כמה חלקים של המודל, שנקראים טנסורים. קריאת טנסורים במקביל מהירה משמעותית מטעינת הקובץ באופן רציף.

סקירה כללית של הארכיטקטורה

הכלי Run:ai Model Streamer משתלב עם vLLM ב-GKE כדי להאיץ את טעינת המודל על ידי סטרימינג של משקלי המודל ישירות מ-Cloud Storage לזיכרון המאיץ, תוך דילוג על הדיסק המקומי.

התרשים הבא מציג את הארכיטקטורה הזו:

ארכיטקטורה של Run:ai Model Streamer שבה נטען משקלי מודל מ-Cloud Storage אל vLLM ב-GKE.
ארכיטקטורה של Run:ai Model Streamer עם vLLM ו-Cloud Storage.

הארכיטקטורה הזו כוללת את הרכיבים הבאים ואת תהליך העבודה הבא:

  • קטגוריה של Cloud Storage: מאחסנת את המשקלים של מודל ה-AI בפורמט safetensors.
  • GKE Pod עם יחידות GPU או TPU: מריץ את שרת ההיקש של vLLM.
  • שרת היקשים vLLM: מוגדר עם הדגל --load-format=runai_streamer, שמאפשר את הפונקציונליות של סטרימינג המודל.
  • ‫Run:ai Model Streamer: כש-vLLM מתחיל, הכלי Model Streamer קורא את משקלי המודל מנתיב gs:// שצוין בקטגוריה של Cloud Storage. במקום להוריד קבצים לדיסק, המערכת משדרת נתוני טנסור ישירות לזיכרון המאיץ של ה-Pod ב-GKE, שם הם זמינים באופן מיידי ל-vLLM לצורך הסקת מסקנות.
  • ‫Cloud Storage Rapid Cache (אופציונלי): אם האפשרות הזו מופעלת, Rapid Cache שומר במטמון את נתוני הקטגוריה באותו אזור כמו הצמתים של GKE, וכך מאיץ עוד יותר את הגישה לנתונים עבור הסטרימר.

יתרונות

  • קיצור זמני ההפעלה במצב התחלתי (cold start): מודל הסטרימינג מקצר משמעותית את הזמן שנדרש להפעלת המודלים. הוא טוען את משקלי המודל עד פי שישה יותר מהר בהשוואה לשיטות רגילות. מידע נוסף זמין במאמר השוואת ביצועים של Run:ai Model Streamer
  • שיפור השימוש במאיצים: על ידי צמצום העיכובים בטעינת המודל, מאיצים כמו יחידות GPU ו-TPU יכולים להקדיש יותר זמן למשימות הסקת מסקנות בפועל, ולשפר את היעילות הכוללת ואת יכולת העיבוד.
  • תהליך עבודה יעיל: הפתרון שמתואר במסמך הזה משתלב עם GKE, ומאפשר לשרתי הסקה כמו vLLM או SGLang לגשת ישירות למודלים בדליים של Cloud Storage.

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

חשוב לוודא שאתם עומדים בדרישות המוקדמות הבאות.

בוחרים פרויקט או יוצרים פרויקט חדש ומפעילים את ה-APIs

  • In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • Verify that billing is enabled for your Cloud de Confiance project.

  • Enable the Kubernetes Engine, Cloud Storage, Compute Engine, IAM APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

    • הגדרת Cloud Shell

    במסמך הזה נעשה שימוש ב-Google Cloud CLI ובפקודות kubectl כדי ליצור ולנהל את המשאבים שנדרשים לפתרון הזה. כדי להריץ את הפקודות האלה ב-Cloud Shell, לוחצים על Activate Cloud Shell (הפעלת Cloud Shell) בחלק העליון של Cloud de Confiance המסוף.

    במסוף Cloud de Confiance , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    לחלופין, אפשר להתקין ולהפעיל את ה-CLI של gcloud בסביבת המעטפת המקומית כדי להריץ את הפקודות. אם רוצים להשתמש במסוף shell מקומי, מריצים את הפקודה gcloud auth login כדי לבצע אימות באמצעות Cloud de Confiance by S3NS.

    מתן תפקידים ב-IAM

    מוודאים שלחשבון Cloud de Confiance שלכם יש את תפקידי ה-IAM הבאים בפרויקט, כדי שתוכלו ליצור אשכול GKE ולנהל את Cloud Storage:

    • roles/container.admin
    • roles/storage.admin

    כדי להעניק את התפקידים האלה, מריצים את הפקודות הבאות:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/container.admin"
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/storage.admin"

    מחליפים את PROJECT_ID במזהה הפרויקט.

    הכנת הסביבה

    בקטע הזה מוסבר איך להגדיר את אשכול GKE ולהגדיר הרשאות גישה למודל ב-Cloud Storage.

    יצירת אשכול GKE

    אפשר להשתמש ב-Run:ai Model Streamer גם עם אשכולות GKE Autopilot וגם עם אשכולות Standard. בוחרים את מצב האשכול שהכי מתאים לצרכים שלכם.

    1. מגדירים משתנים לשם הפרויקט והאשכול:

      export PROJECT_ID=PROJECT_ID
export CLUSTER_NAME=CLUSTER_NAME

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS . כדי למצוא את מזהה הפרויקט, מריצים את הפקודה gcloud config get-value project.
      • ‫CLUSTER_NAME: השם של האשכול. לדוגמה, run-ai-test.

    2. יוצרים אשכול במצב Autopilot או אשכול רגיל:

      טייס אוטומטי

      כדי ליצור אשכול GKE Autopilot:

      1. מגדירים את האזור של האשכול:

        export REGION=REGION

        מחליפים את REGION באזור שבו רוצים ליצור את האשכול. כדי להשיג ביצועים אופטימליים, צריך להשתמש באותו אזור כמו בקטגוריה של Cloud Storage.

      2. יוצרים את האשכול:

        gcloud container clusters create-auto $CLUSTER_NAME \
    --project=$PROJECT_ID \
    --location=$REGION

      ב-Autopilot, הקצאת הצמתים מתבצעת באופן אוטומטי על סמך דרישות העומס. כשפורסים את שרת vLLM בשלב מאוחר יותר, Autopilot יקצה את צמתי ה-GPU או ה-TPU אם נדרש. מידע נוסף זמין במאמר בנושא יצירה אוטומטית של מאגרי צמתים.

      רגילה

      כדי ליצור אשכול GKE Standard:

      1. מגדירים את האזור של האשכול:

        export ZONE=ZONE

        מחליפים את ZONE באזור שבו רוצים ליצור את האשכול. כדי להשיג ביצועים אופטימליים, מומלץ להשתמש באזור שנמצא באותו אזור כמו קטגוריית Cloud Storage.

      2. יוצרים את האשכול:

        gcloud container clusters create $CLUSTER_NAME \
    --project=$PROJECT_ID \
    --zone=$ZONE \
    --workload-pool=$PROJECT_ID.s3ns.svc.id.goog \
    --num-nodes=1

    יצירת מאגר צמתים

    אם יצרתם אשכול Standard, אתם צריכים ליצור מאגר צמתים עם GPU או TPU. ב-Autopilot, הקצאת הצמתים מתבצעת באופן אוטומטי על סמך דרישות העומס. יוצרים מאגר צמתים על סמך המאיץ שרוצים להשתמש בו:

    *   {GPU}

    Create a node pool with one G2 machine (NVIDIA L4 GPU):

    ```sh
    gcloud container node-pools create g2-gpu-pool \
        --cluster=$CLUSTER_NAME \
        --zone=$ZONE \
        --machine-type=g2-standard-16 \
        --num-nodes=1 \
        --accelerator=type=nvidia-l4
    ```

*   {TPU}

    Create a node pool with TPU v7x nodes:

    ```sh
    gcloud container node-pools create tpu7x-pool \
        --cluster=$CLUSTER_NAME \
        --zone=$ZONE \
        --machine-type=tpu7x-standard-4t \
        --num-nodes=1
    ```

    הגדרת איחוד זהויות של עומסי עבודה ל-GKE

    מגדירים את איחוד זהויות של עומסי עבודה ל-GKE כדי לאפשר לעומסי העבודה ב-GKE לגשת באופן מאובטח למודל בקטגוריה של Cloud Storage.

    1. מגדירים משתנים לחשבון השירות ולמרחב השמות של Kubernetes:

      export KSA_NAME=KSA_NAME
export NAMESPACE=NAMESPACE

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫NAMESPACE: מרחב השמות שבו רוצים שעומסי העבודה יפעלו. חשוב להקפיד להשתמש באותו מרחב שמות כדי ליצור את כל המשאבים במסמך הזה.
      • ‫KSA_NAME: השם של חשבון השירות ב-Kubernetes שה-Pod יכול להשתמש בו כדי לבצע אימות ל-API. Cloud de Confiance by S3NS

    2. יוצרים מרחב שמות של Kubernetes:

      kubectl create namespace $NAMESPACE

    3. יוצרים חשבון שירות ב-Kubernetes‏ (KSA):

      kubectl create serviceaccount $KSA_NAME \
    --namespace=$NAMESPACE

    4. נותנים ל-KSA את ההרשאות הנדרשות:

      1. מגדירים את משתני הסביבה:

        export BUCKET_NAME=BUCKET_NAME
export PROJECT_ID=PROJECT_ID
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format 'get(projectNumber)')

        מחליפים את מה שכתוב בשדות הבאים:

        • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שמכילה את הקבצים של safetensors.
        • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .

        הערכים PROJECT_NUMBER,‏ PROJECT_ID,‏ NAMESPACE ו-KSA_NAME ישמשו בשלבים הבאים ליצירת מזהה ישות מורשית של איחוד זהויות של עומסי עבודה ל-GKE עבור הפרויקט שלכם.

      2. מקצים את התפקיד roles/storage.bucketViewer ל-KSA כדי לצפות באובייקטים בקטגוריה של Cloud Storage:

        gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
    --member="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.s3ns.svc.id.goog/subject/ns/$NAMESPACE/sa/$KSA_NAME" \
    --role="roles/storage.bucketViewer"

      3. מקצים ל-KSA את התפקיד roles/storage.objectUser כדי לקרוא, לכתוב ולמחוק אובייקטים בקטגוריה של Cloud Storage:

        gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
    --member="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.s3ns.svc.id.goog/subject/ns/$NAMESPACE/sa/$KSA_NAME" \
    --role="roles/storage.objectUser"

    הגדרתם אשכול GKE עם יחידות GPU או TPU והגדרתם איחוד שירותי אימות זהויות של עומסי עבודה ב-GKE, כך שחשבון שירות של Kubernetes מקבל את ההרשאות הנדרשות לגישה למודל ה-AI ב-Cloud Storage. אחרי שהגדרתם את האשכול ואת ההרשאות, אתם מוכנים לפרוס את שרת ההסקה vLLM, שישתמש בחשבון השירות הזה כדי להזרים משקלים של מודלים באמצעות Run:ai Model Streamer.

    פריסת vLLM באמצעות Run:ai Model Streamer

    פורסים Pod שמריץ את השרת שתואם ל-vLLM OpenAI, ומוגדר עם הדגל --load-format=runai_streamer כדי להשתמש ב-Run:ai Model Streamer. גרסת vLLM צריכה להיות 0.11.1 ואילך עבור GPU, ו-0.18.0 ואילך עבור TPU.

    בקבצים הבאים של מניפסטים לדוגמה אפשר לראות איך מגדירים את vLLM עם סטרימינג של מודל מופעל למודל בגודל קטן, כמו gemma-2-9b-it.

    הדגל --model-loader-extra-config={"distributed":true} מאפשר טעינה מבוזרת של משקלי המודל, והוא הגדרה מומלצת לשיפור הביצועים של טעינת המודל מאחסון אובייקטים.

    מידע נוסף זמין במאמרים בנושא מקביליות טנסורית ופרמטרים שניתנים להתאמה.

    1. בוחרים את קובץ המניפסט לדוגמה בהתאם למאיץ שבו רוצים להשתמש:

      GPU

      המניפסט הבא לדוגמה משתמש ב-GPU יחיד מסוג NVIDIA L4. אם אתם משתמשים במודל גדול שדורש כמה מעבדי GPU, צריך להגדיל את הערך של --tensor-parallel-size למספר מעבדי ה-GPU הנדרש.

      שומרים את קובץ המניפסט הבא בשם vllm-deployment.yaml. ה-manifest מיועד לגמישות באשכולות Autopilot ובאשכולות רגילים.

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-streamer-deployment
  namespace: NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-streamer
  template:
    metadata:
      labels:
        app: vllm-streamer
    spec:
      serviceAccountName: KSA_NAME
      containers:
        - name: vllm-container
          image: vllm/vllm-openai:v0.11.1
          command:
            - python3
            - -m
            - vllm.entrypoints.openai.api_server
          args:
            - --model=gs://BUCKET_NAME/PATH_TO_MODEL
            - --load-format=runai_streamer
            - --model-loader-extra-config={"distributed":true}
            - --host=0.0.0.0
            - --port=8000
            - --disable-log-requests
            - --tensor-parallel-size=1
          ports:
            - containerPort: 8000
              name: api
          # startupProbe allows for longer startup times for large models
          startupProbe:
            httpGet:
              path: /health
              port: 8000
            failureThreshold: 60  # 60 * 10s = 10 minutes timeout
            periodSeconds: 10
            initialDelaySeconds: 30
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            failureThreshold: 3
            periodSeconds: 10
          resources:
            limits:
              nvidia.com/gpu: "1"
            requests:
              nvidia.com/gpu: "1"
          volumeMounts:
          - mountPath: /dev/shm
            name: dshm
      nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-l4
      volumes:
      - emptyDir:
          medium: Memory
        name: dshm

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫NAMESPACE: מרחב השמות של Kubernetes.
      • ‫KSA_NAME: השם של חשבון השירות של Kubernetes.
      • ‫BUCKET_NAME: שם הקטגוריה שלכם ב-Cloud Storage.
      • ‫PATH_TO_MODEL: הנתיב לספריית המודלים בתוך הקטגוריה, לדוגמה, models/my-llama.

      TPU

      במניפסט לדוגמה הבא נעשה שימוש בצמתי TPU v7x.

      שומרים את קובץ המניפסט הבא בשם vllm-deployment.yaml.

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-vllm
  namespace: NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tpu-vllm
  template:
    metadata:
      labels:
        app: tpu-vllm
    spec:
      serviceAccountName: KSA_NAME
      containers:
      - name: vllm-container
        image: vllm/vllm-tpu:v0.18.0
        resources:
          limits:
            google.com/tpu: "4"
        command: ["sh", "-c"]
        args:
        - >-
          python3 -m vllm.entrypoints.openai.api_server
          --model=gs://BUCKET_NAME/PATH_TO_MODEL
          --load-format=runai_streamer
          --tensor-parallel-size=8
          --port=8000
        ports:
        - containerPort: 8000
        env:
        - name: VLLM_XLA_CACHE_PATH
          value: "gs://BUCKET_NAME/PATH_TO_CACHE"
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu7x
        cloud.google.com/gke-tpu-topology: 2x2x1

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫NAMESPACE: מרחב השמות של Kubernetes.
      • ‫KSA_NAME: השם של חשבון השירות של Kubernetes.
      • ‫BUCKET_NAME: שם הקטגוריה שלכם ב-Cloud Storage.
      • ‫PATH_TO_MODEL: הנתיב לספריית המודלים בתוך הקטגוריה, לדוגמה, models/my-llama.
      • ‫PATH_TO_CACHE: הנתיב לספריית מטמון ההידור של XLA בתוך הקטגוריה, לדוגמה, models/xla-cache.

    2. מחילים את המניפסט כדי ליצור את הפריסה:

      kubectl create -f vllm-deployment.yaml

    אפשר ליצור עוד מניפסטים של vLLM באמצעות הכלי GKE Inference Quickstart.

    אימות הפריסה

    1. בודקים את הסטטוס של הפריסה:

      kubectl get deployments -n NAMESPACE

    2. אחזור שם ה-Pod:

      kubectl get pods -n NAMESPACE | grep vllm-streamer

      רושמים את שם ה-Pod שמתחיל ב-vllm-streamer-deployment.

    3. כדי לבדוק אם מודל הסטרימינג מוריד את המודל ואת המשקלים, צריך להציג את היומנים של ה-Pod:

      kubectl logs -f POD_NAME -n NAMESPACE

      מחליפים את POD_NAME בשם של ה-Pod מהשלב הקודם. יומני סטרימינג מוצלחים נראים כך:

      [RunAI Streamer] Overall time to stream 15.0 GiB of all files: 13.4s, 1.1 GiB/s

    אופציונלי: שיפור הביצועים באמצעות Rapid Cache

    Cloud Storage Rapid Cache יכול להאיץ עוד יותר את טעינת המודל על ידי שמירת נתונים במטמון קרוב יותר לצמתי GKE. השימוש במטמון מועיל במיוחד כשמרחיבים את מספר הצמתים באותו אזור.

    מפעילים את Rapid Cache לקטגוריה של Cloud Storage באזור ספציפי Cloud de Confiance by S3NS . כדי לשפר את הביצועים, האזור של המטמון צריך להיות זהה לאזור שבו פועלים ה-Pods של ההסקה ב-GKE. הגישה שלכם תלויה בשאלה אם ה-Pods שלכם פועלים באזורים צפויים.

    • באשכולות אזוריים של GKE Standard, אם אתם יודעים באיזה אזור יפעלו ה-Pods, אתם יכולים להפעיל את Rapid Cache באזור הספציפי הזה.

    • באשכולות GKE אזוריים (גם Autopilot וגם Standard), שבהם אפשר לתזמן את ה-Pods בכמה אזורים, יש לכם את האפשרויות הבאות:

      • הפעלת שמירת נתונים במטמון בכל האזורים: הפעלת Rapid Cache בכל אזור באזור של האשכול. כך מובטח שיהיה מטמון זמין, לא משנה איפה ב-GKE מתוזמנים הפודים. שימו לב: אתם מחויבים על כל אזור שבו מופעלת שמירת נתונים במטמון. מידע נוסף על התמחור של Rapid Cache
      • הצבת Pods באזור ספציפי: אפשר להשתמש בכלל nodeSelector או nodeAffinity במניפסט של עומס העבודה כדי להגביל את ה-Pods לאזור יחיד. אחר כך תוכלו להפעיל את Rapid Cache רק באזור הזה. זו גישה חסכונית יותר אם עומס העבודה מאפשר הגבלה לאזור אחד.

    כדי להפעיל את Rapid Cache באזור שבו נמצא אשכול GKE, מריצים את הפקודות הבאות:

    # Enable the cache
gcloud storage buckets anywhere-caches create gs://$BUCKET_NAME $ZONE

# Check the status of the cache
gcloud storage buckets anywhere-caches describe $BUCKET_NAME/$ZONE

    הסרת המשאבים

    כדי להימנע מחיובים בחשבון Cloud de Confiance by S3NS על המשאבים שבהם השתמשתם במסמך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

    כדי למחוק את המשאבים הנפרדים, פועלים לפי השלבים הבאים:

    1. מוחקים את אשכול GKE. הפעולה הזו מסירה את כל הצמתים ועומסי העבודה.

      gcloud container clusters delete CLUSTER_NAME --location=ZONE_OR_REGION

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫CLUSTER_NAME: השם של האשכול.
      • ‫ZONE_OR_REGION: האזור או האזור של האשכול.

    2. כדי להימנע מעלויות שוטפות, צריך להשבית את Rapid Cache אם הפעלתם אותו. מידע נוסף מופיע במאמר השבתת מטמון.

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