עומסי עבודה של קונטיינרים ב-GDC

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

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

אפליקציות Kubernetes לסביבה מנותקת

‫GKE on GDC הוא שירות Kubernetes מנוהל שמשלב כברירת מחדל תכונות רבות של GKE ביקום GDC שלכם. השירות הזה מבטל את הצורך להתקין, לשדרג, לשלב ולהפעיל Kubernetes בקוד פתוח באופן עצמאי. אתם יכולים להפעיל ולתחזק את הפצת Kubernetes שסופקה באמצעות KRM API רגיל, כמו כל מוצר אחר של Kubernetes שהוא דקלרטיבי ואידמפוטנטי. באופן דומה, אפשר להשתמש ב-GKE on GDC דרך מסוף GDC, ה-gdcloud CLI ו-Terraform. מידע נוסף על אשכולות Kubernetes ב-GDC זמין במאמר סקירה כללית על אשכולות Kubernetes. מידע נוסף על מושגי מפתח ב-Kubernetes זמין במאמר תחילת הלימוד על Kubernetes במסמכי GKE.

מצב עומס העבודה של הקונטיינר

קונטיינרים ב-GDC נפרסים באשכולות Kubernetes באופן הבא:

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

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

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

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

מערכת Kubernetes משתמשת במשאב Deployment כדי לפרוס אפליקציות ללא מצב (stateless) בתור קבוצות Pod אחידות ולא ייחודיות. פריסות מנהלות את המצב הרצוי של האפליקציה, למשל:

  • מספר ה-Pods להרצת האפליקציה.
  • הגרסה של קובץ האימג' של הקונטיינר להרצה.
  • התוויות של ה-Pods.

אפשר לשנות את המצב הרצוי באופן דינמי באמצעות עדכונים למפרט של DeploymentהמשאבPod.

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

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

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

‫Kubernetes משתמש במשאב StatefulSet כדי לפרוס אפליקציות עם מצב. אי אפשר להחליף בין פודים במשאבי StatefulSet: לכל פוד יש מזהה ייחודי שנשמר לא משנה איפה הוא מתוזמן.

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

אחסון מתמיד לקונטיינרים

‫GDC מספק אחסון בלוקים מתמשך באמצעות אובייקטים של PersistentVolumeClaim (PVC). ‫PVC היא בקשה לאחסון שאליה מתייחס אובייקט Pod. ‫Pod הוא קבוצה של מאגר אחד או יותר, עם אחסון משותף ומשאבי רשת. ל-PVC יש מחזור חיים עצמאי מזה של ה-Pod, ולכן הוא יכול להתקיים מעבר ל-Pod יחיד.

אתם יכולים להקצות באופן דינמי אחסון מתמיד לעומסי עבודה עם שמירת מצב, כך שהנפחים הבסיסיים נוצרים לפי דרישה. ב-GDC, מגדירים הקצאת הרשאות דינמית על ידי יצירת האובייקט StorageClass שהותקן מראש standard-rwo. האובייקט standard-rwo הוא סוג אחסון של בלוקים ReadWriteOnce (RWO) שמאפשר גישה לנפח רק לצומת אחד בכל פעם.

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

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