מידע על StatefulSets ב-GKE

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

מידע על StatefulSets

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

באפליקציות ללא מצב, משתמשים בפריסות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עבודה עם StatefulSets

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

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