יצירת עומסי עבודה ללא שמירת מצב

בדף הזה מוסבר איך ליצור ולנהל עומסי עבודה (workload) חסרי מצב באשכול Kubernetes של מכשיר Google Distributed Cloud ‏(GDC) עם בידוד פיזי. עומסי עבודה בלי שמירת מצב מאפשרים לכם להתאים את פריסת האפליקציה לעומס העבודה, בלי שתצטרכו לנהל אחסון מתמיד באשכול Kubernetes כדי לאחסן נתונים או את ערך דינמי של האפליקציה. בדף הזה מוסבר איך להתחיל כדי שתוכלו לבצע אופטימיזציה יעילה של זמינות האפליקציה ולהתאים אותה.

הדף הזה מיועד למפתחים בקבוצת מפעילים של אפליקציות, שאחראים על יצירת עומסי עבודה של אפליקציות בארגון שלהם.

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

כדי להשלים את המשימות שמתוארות במאמר הזה, צריך לבקש את ההרשאות הנדרשות ולהכין את הסביבה.

שליחת בקשה לתפקידי IAM

כדי ליצור, למחוק, לערוך או להציג עומסי עבודה חסרי סטטוס באשכול Kubernetes, צריך לבקש מאדמין ה-IAM בארגון להעניק לכם את התפקיד אדמין של מרחב שמות (namespace-admin). התפקיד הזה משויך למרחב השמות של הפרויקט.

הכנת הסביבה

כדי להריץ פקודות באשכול Kubernetes בשרת פיזי שהוגדר מראש, צריך לוודא שיש לכם את המשאבים הבאים:

1. מאתרים את שם אשכול Kubernetes או שואלים את מנהל הפלטפורמה מה שם האשכול.

2. אם אין לכם קובץ kubeconfig, אתם צריכים להיכנס וליצור אותו עבור אשכול Kubernetes.

3. משתמשים בנתיב kubeconfig של אשכול Kubernetes כדי להחליף את הערך CLUSTER_KUBECONFIG בהוראות האלה.

יצירת פריסה

כדי ליצור פריסה, כותבים Deployment מניפסט ומריצים את הפקודה kubectl apply כדי ליצור את המשאב. בשיטה הזו, המערכת גם שומרת על העדכונים שבוצעו במשאבים של שידורים חיים בלי למזג את השינויים בחזרה לקובצי המניפסט.

כדי ליצור Deployment מקובץ המניפסט שלו, מריצים את הפקודה:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
EOF

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

• ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של אשכול Kubernetes שבו אתם פורסים עומסי עבודה של קונטיינרים.

• ‫NAMESPACE: מרחב השמות של הפרויקט שבו יפרסו עומסי העבודה של הקונטיינר.

• ‫DEPLOYMENT_NAME: השם של אובייקט Deployment.

• ‫APP_NAME: השם של האפליקציה שרוצים להפעיל בפריסה.

• ‫NUMBER_OF_REPLICAS: מספר האובייקטים המשוכפלים Pod שהפריסה מנהלת.

• ‫CONTAINER_NAME: השם של הקונטיינר.

• ‫CONTAINER_IMAGE: השם של קובץ האימג' בקונטיינר. חובה לכלול את הנתיב של מאגר הקונטיינרים ואת הגרסה של התמונה, כמו REGISTRY_PATH/hello-app:1.0. מידע נוסף על הגדרת הנתיב של מאגר התמונות זמין במאמר סקירה כללית על שירות Harbor המנוהל.

הערה: אפשר גם להשתמש בפקודה kubectl apply -f DIRECTORY כדי ליצור אובייקטים חדשים שמוגדרים על ידי קובצי מניפסט שמאוחסנים בספרייה.

לדוגמה:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1

אם אתם פורסים עומסי עבודה של GPU במאגרי התמונות שלכם, תוכלו לקרוא מידע נוסף במאמר בנושא ניהול עומסי עבודה של GPU במאגרי תמונות.