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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • standard-rwo: סוג אחסון הבלוקים ReadWriteOnce (RWO). אפשר לגשת לנפח רק מצומת אחת בכל פעם. בסוג האחסון הזה יש הבטחה ומגבלה של 3 פעולות קלט/פלט לשנייה (IOPS) לכל GiB.

  • ‫system-performance-rwo: סוג האחסון ReadWriteOnce לביצועים גבוהים של אחסון בלוקים. סוג האחסון הזה הוא גרסה עם ביצועים טובים יותר של אחסון RWO, והוא כולל הבטחה ומגבלה של 30 IOPS לכל GiB.

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

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