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

משותף רגיל

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

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

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

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

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

כדי לקבל את ההרשאות שדרושות ליצירת עומסי עבודה עם שמירת מצב, צריך להיות לכם תפקידים ספציפיים. התפקידים שאתם צריכים תלויים בסוג האשכול שבו אתם עובדים: אשכול שיתופי בהיקף הארגון או אשכול רגיל בהיקף הפרויקט. למידע נוסף, קראו את המאמר הגדרות של אשכול Kubernetes.

תפקידים משותפים באשכול

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

תפקידים רגילים באשכול

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

הכנת הסביבה

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

• מאתרים את שם אשכול Kubernetes או שואלים חבר בקבוצת האדמינים של הפלטפורמה מה שם האשכול.

• נכנסים לחשבון ויוצרים את קובץ ה-kubeconfig לאשכול Kubernetes.

• משתמשים בנתיב kubeconfig של אשכול Kubernetes כדי להחליף את KUBERNETES_CLUSTER_KUBECONFIG בהוראות האלה.

יצירת משאב StatefulSet

יוצרים אובייקט StatefulSet על ידי כתיבת מניפסט StatefulSet והפעלת הפקודה kubectl apply ליצירת המשאב. כדי לספק ללקוחות דרך יציבה לשליחת בקשות ל-pods של משאב StatefulSet, צריך גם ליצור אובייקט Service.

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

כדי ליצור משאב StatefulSet ומשאב Service, מריצים את הפקודה:

kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

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

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

• ‫NAMESPACE: מרחב השמות שבו יופעלו עומסי העבודה של הקונטיינרים. במקרה של אשכולות משותפים, צריך להשתמש במרחב שמות של פרויקט. במקרים של אשכולות רגילים, אפשר להשתמש בכל מרחב שמות.

• ‫SERVICE_NAME: השם של אובייקט Service. מוודאים שאובייקט StatefulSet מגדיר את אובייקט Service גם ב-serviceName שלו.

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

• ‫APP_LABEL_NAME: בורר התוויות שקובע אילו פודים שייכים לאובייקט StatefulSet.

• ‫STATEFULSET_NAME: השם של אובייקט StatefulSet.

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

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

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

• ‫CONTAINER_STORAGE_VOLUME_PATH: הנתיב בתוך הקונטיינר שבו מותקן נפח אחסון.

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

לדוגמה, אובייקט StatefulSet הבא ואובייקט Service התואם יוצרים עומסי עבודה של קונטיינרים עם שמירת מצב:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

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

בדוגמה הזו:

• נוצר אובייקט Service בשם nginx, שמוצג בשדה metadata: name. האובייקט Service מכוון לאפליקציה בשם nginx, שמצוינת על ידי labels.app: nginx ו-selector.app: nginx. האובייקט Service חושף את יציאה 80 ונותן לה את השם web. אובייקט Service הזה שולט בדומיין של הרשת ומנתב את תנועת האינטרנט לאפליקציה שמופעלת בתוך קונטיינר, שנפרסה על ידי אובייקט StatefulSet.
• נוצר StatefulSet בשם web עם שלושה אובייקטים משוכפלים של Pod, כפי שמוגדר בשדה replicas: 3.
• התבנית Pod, שמוגדרת על ידי הקטע .spec.template, מציינת שהאובייקטים Pod שלה מסומנים בתווית app: nginx.
• המפרט Pod, שמוגדר בקטע .template.spec, מציין שהפודים של StatefulSet מריצים קונטיינר אחד, nginx, שמריץ את התמונה nginx בגרסה 1.23.
• Pod המפרט משתמש ביציאת האינטרנט שנפתחה על ידי האובייקט Service.
• בקטע .template.spec.volumeMounts מצוין השדה mountPath, שנקרא www. ‫mountPath הוא הנתיב בקונטיינר שבו מותקן נפח אחסון.
• ‫StatefulSet מספק שלושה אובייקטים של PersistentVolumeClaim, בשמות web-www-0, web-www-1 ו-web-www-2, עם נפח אחסון מוקצה של 1GB לכל אחד.

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

בקשה לאחסון מתמיד במשאב StatefulSet

אפשר להקצות נפח אחסון מתמיד באופן דינמי, כך שהנפחים הבסיסיים נוצרים לפי דרישה. אפליקציות יכולות לבקש אחסון מתמיד באמצעות אובייקט PersistentVolumeClaim.

בדרך כלל, צריך ליצור PersistentVolumeClaim אובייקטים בנוסף ליצירת האובייקט Pod. עם זאת, אובייקטים מסוג StatefulSet כוללים מערך volumeClaimTemplates שיוצר את האובייקטים PersistentVolumeClaim. כל עותק StatefulSet מקבל אובייקט PersistentVolumeClaim משלו.

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

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

• בדיקת עומסי עבודה עם שמירת מצב
• עדכון עומסי עבודה עם שמירת מצב
• ניהול מאגרי צמתים