מידע על StatefulSets ב-GKE

בדף הזה מוסבר על השימוש באובייקטים מסוג StatefulSet ב-Google Kubernetes Engine ‏ (GKE). אפשר גם לקרוא על פריסת אפליקציה עם שמירת מצב.

מידע על StatefulSets

‫StatefulSets מייצג קבוצה של Pods עם זהויות ייחודיות וקבועות, ושמות מארחים יציבים ש-GKE מתחזק בלי קשר למקום שבו הם מתוזמנים. מידע המצב ונתונים עמידים אחרים של כל פוד StatefulSet נשמרים בנפחים מתמשכים שמשויכים לכל פוד ב-StatefulSet. אפשר להפעיל מחדש את ה-Pods של StatefulSet בכל שלב.

עבור אפליקציות בלי שמירת מצב, משתמשים ב-Deployments.

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

תכנון הרשת עבור StatefulSets

‫StatefulSets מספקות אחסון מתמיד בצורה של PersistentVolume וזהות רשת ייחודית (שם מארח). בטבלה הבאה מפורטים האזהרות שחשוב שמפעילי אפליקציות יכירו כשמגדירים StatefulSet:

הערה לגבי רשתות תיאור שיטה מומלצת
שירותי GKE במקום כתובות IP קבועות

למרות שלשכפול Pod יש אינדקס סידורי ייחודי, הוא תומך בכרכים לכל שכפול ובזהות רשת (שם מארח), כתובות ה-IP שמוקצות לשכפול יכולות להשתנות אם GKE מתזמן מחדש או מסיר Pod.

כדי לצמצם בעיות ברשת, הארכיטקטורה צריכה להשתמש במשאבי Kubernetes Service. מידע נוסף זמין במאמר בנושא סוגים של שירותי Kubernetes.
Headless Services

כשמאתחלים StatefulSet, הוא משויך לשירות תואם ללא כתובת IP.

מוודאים שהשם `metadata.name` בשירות זהה לשדה serviceName ב-StatefulSet. כך אפשר לפנות לכל Pod באפליקציה שלכם בכתובת רשת ייחודית ומוגדרת היטב. בנוסף, שירות ללא ראש מספק רשומת IP מרובה לכל עותק משוכפל ב-StatefulSet, וכך מאפשר גילוי מלא של עמיתים.
חיפוש עמיתים

אפליקציות עם שמירת מצב צריכות מספר מינימלי (קוורום) של רפליקות כדי לפעול עם זמינות מלאה.

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

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

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

  • בדיקות תקינות (Liveness probes): אפשר להשתמש בבדיקות תקינות כדי לציין אם קונטיינר תקין. לדוגמה, עותק משוכפל של מסד נתונים יכול להשתמש בבדיקת פעילות כדי לציין ש-GKE צריך להפעיל מחדש את העותק המשוכפל, למשל במצב של חסימה הדדית
  • בדיקות מוכנות: אפשר להשתמש בבדיקות מוכנות כדי להסיר באופן זמני עותק משוכפל מהצגת תנועה. לדוגמה, אם יש לכם עותק משוכפל של מסד נתונים שצריך לבצע גיבוי, אתם יכולים להשתמש בבדיקת מוכנות כדי להפסיק באופן זמני את קבלת הבקשות.
  • בדיקות מוכנות להפעלה: אפשר להשתמש בבדיקות מוכנות להפעלה כדי להשהות את בדיקות התקינות עד להשלמת אתחולים ארוכים. לדוגמה, אם יש לכם העתק של מסד נתונים, אתם יכולים להשתמש בבדיקת הפעלה כדי להמתין לאתחול של נתונים מאוחסנים מהדיסק.

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

עבודה עם StatefulSets

כדי ללמוד איך לפרוס StatefulSets באשכול GKE ואיך ליצור איתם אינטראקציה, אפשר לעיין במסמכי התיעוד של Kubernetes בנושא StatefulSet basics.

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