בקטע הזה מתוארים אמצעי הבקרה שבהם נעשה שימוש בפלטפורמת הפיתוח.
זהות, תפקידים וקבוצות בפלטפורמה
כדי לגשת לשירותים Google Cloud צריך זהויות Google Cloud . בתוכנית ה-blueprint נעשה שימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet ל-GKE כדי למפות את חשבונות השירות של Kubernetes שמשמשים כזהויות של קבוצות Pod לחשבונות שירות שלGoogle Cloud Google Cloudששולטים בגישה לשירותים. כדי להגן מפני הרשאות מורחבות בסביבות שונות, לכל סביבה יש מאגר זהויות נפרד (שנקרא קבוצה של ספקי זהויות מהימנים) לאיחוד זהויות של עומסי עבודה בחשבונות GKE.
פרסונות של פלטפורמות
כשפורסים את התוכנית, נוצרים שלושה סוגים של קבוצות משתמשים: צוות פלטפורמת פיתוח, צוות אפליקציה (צוות אחד לכל אפליקציה) וצוות פעולות אבטחה.
הצוות של פלטפורמת המפתחים אחראי על הפיתוח והניהול של פלטפורמת המפתחים. החברים בצוות הזה הם:
- מפתחים בפלטפורמת הפיתוח: חברי הצוות האלה מרחיבים את התוכנית ומטמיעים אותה במערכות קיימות. הצוות הזה גם יוצר תבניות חדשות של אפליקציות.
- אדמין של פלטפורמת הפיתוח: הצוות הזה אחראי על הפעולות הבאות:
- אישור ליצירת צוותים חדשים בדיירים.
- ביצוע משימות מתוזמנות ולא מתוזמנות שמשפיעות על כמה דיירים, כולל:
- אישור קידום של אפליקציות לסביבה ללא ייצור ולסביבת הייצור.
- תיאום עדכוני התשתית.
- יצירת תוכניות קיבולת ברמת הפלטפורמה.
דייר בפלטפורמת הפיתוח הוא צוות פיתוח תוכנה יחיד והאנשים שאחראים על התפעול של התוכנה הזו. צוות הדייר מורכב משתי קבוצות: מפתחי אפליקציות ומפעילים של אפליקציות. אלה התפקידים של שתי הקבוצות בצוות הדייר:
- מפתחי אפליקציות: הצוות הזה כותב קוד אפליקציה ומבצע בו ניפוי באגים. לפעמים הם נקראים גם מהנדסי תוכנה או מפתחי Full-stack. האחריות שלהם כוללת את הפעולות הבאות:
- ביצוע בדיקות ובקרת איכות ברכיב באפליקציה כשהוא נפרס בסביבת הפיתוח.
- ניהול משאבים בענן בבעלות האפליקציה (כמו מסדי נתונים וקטגוריות אחסון) בסביבת הפיתוח.
- תכנון סכימות של מסדי נתונים או של אחסון לשימוש באפליקציות.
- אופרטורים של אפליקציות או מהנדסי מהימנות אתרים (SRE): הצוות הזה מנהל את המהימנות של אפליקציות שפועלות בסביבות ייצור, ואת ההתקדמות הבטוחה של שינויים שבוצעו על ידי מפתחי אפליקציות לייצור. לפעמים הם נקראים מפעילים של שירותים, מהנדסי מערכות או אדמינים של מערכות. האחריות שלהם כוללת את הפעולות הבאות:
- תכנון הקיבולת הנדרשת ברמת האפליקציה.
- יצירת כללי מדיניות התראות והגדרת יעדים למדידת רמת השירות (SLO) לשירותים.
- אבחון בעיות בשירות באמצעות יומנים ומדדים שספציפיים לאותו אפליקציה.
- מענה להתראות ולדפים, למשל כששירות לא עומד ביעדי ה-SLO שלו.
- עובדים עם קבוצה או כמה קבוצות של מפתחי אפליקציות.
- אישור פריסה של גרסאות חדשות בסביבת הייצור.
- ניהול משאבי ענן בבעלות האפליקציה בסביבות שאינן סביבות ייצור ובסביבות ייצור (לדוגמה, גיבויים ועדכוני סכימה).
מבנה ארגוני של הפלטפורמה
תוכנית הבסיס של האפליקציה הארגונית משתמשת במבנה הארגוני שמופיע בתוכנית הבסיס של הארגון. בתרשים הבא אפשר לראות איך פרויקטים של תוכנית הבסיס של האפליקציה הארגונית משתלבים במבנה של תוכנית הבסיס.
פרויקטים של פלטפורמות
בטבלה הבאה מפורטים הפרויקטים הנוספים, מעבר לאלה שסופקו על ידי תוכנית הבסיס, שתוכנית האפליקציה צריכה כדי לפרוס משאבים, הגדרות ואפליקציות.
| תיקייה | פרויקט | תיאור |
|---|---|---|
|
|
מכיל את צינור עיבוד הנתונים של התשתית מרובת הדיירים לפריסת תשתית הדייר. |
|
מכיל את מפעל האפליקציות , שמשמש ליצירת ארכיטקטורת אפליקציות עם דייר יחיד וצינורות עיבוד נתונים של אינטגרציה רציפה ופריסה רציפה (CI/CD). הפרויקט הזה מכיל גם את סנכרון תצורות שמשמש להגדרת אשכול GKE. |
|
|
מכילה את צינורות ה-CI/CD של האפליקציה, שנמצאים בפרויקטים נפרדים כדי לאפשר הפרדה בין צוותי הפיתוח. יש צינור אחד לכל אפליקציה. |
|
|
|
מכיל את אשכולות GKE לפלטפורמת הפיתוח ואת הלוגיקה שמשמשת לרישום אשכולות לניהול Fleet. |
( |
מכיל שירותי אפליקציות של דייר יחיד, כמו מסדי נתונים או שירותים מנוהלים אחרים שמשמשים צוות אפליקציות. |
ארכיטקטורת אשכולות של פלטפורמה
תוכנית ה-Blueprint פורסת אפליקציות בשלוש סביבות: פיתוח, לא ייצור וייצור. כל סביבה משויכת ל-Fleet. בתוכנית הזו, Fleet הוא פרויקט שכולל אשכול אחד או יותר. עם זאת, אפשר גם לקבץ כמה פרויקטים בצי. Fleet מספק גבול אבטחה לוגי לצורך בקרה אדמיניסטרטיבית. צי מאפשר לקבץ באופן לוגי אשכולות של Kubernetes ולבצע בהם נורמליזציה, ומקל על ניהול התשתית.
בתרשים הבא מוצגים שני אשכולות GKE שנוצרו בכל סביבה כדי לפרוס אפליקציות. שני האשכולות פועלים כאשכולות GKE זהים בשני אזורים שונים, כדי לספק עמידות במספר אזורים. כדי לנצל את היכולות של Fleet, התוכנית משתמשת במושג של זהות באובייקטים, בשירותים ובזהות של מרחב השמות.
בתוכנית האב של אפליקציית הארגון נעשה שימוש באשכולות GKE עם מרחבים פרטיים שמופעלים באמצעות גישה למישור הבקרה של Private Service Connect ומאגרי צמתים פרטיים כדי להסיר משטחי תקיפה פוטנציאליים מהאינטרנט. לא לצמתים של האשכול ולא למישור הבקרה יש נקודת קצה ציבורית. בצמתים של האשכול פועל מערכת הפעלה מותאמת לשימוש עם קונטיינרים כדי להגביל את משטח התקיפה שלהם, ובצמתים של האשכול נעשה שימוש בצמתים מוגנים של GKE כדי להגביל את היכולת של תוקף להתחזות לצומת.
הגישה האדמיניסטרטיבית לאשכולות GKE מופעלת דרך שער Connect. כחלק מפריסת התוכנית, נעשה שימוש במופע אחד של Cloud NAT לכל סביבה כדי לספק ל-Podים ולסנכרון תצורות מנגנון לגישה למשאבים באינטרנט, כמו GitHub. הגישה לאשכולות GKE נשלטת על ידי הרשאת Kubernetes RBAC שמבוססת על קבוצות Google ל-GKE. קבוצות מאפשרות לכם לשלוט בזהויות באמצעות מערכת מרכזית לניהול זהויות שנשלטת על ידי אדמינים של זהויות.
רכיבי פלטפורמת GKE
פלטפורמת הפיתוח משתמשת ב-GKE וברכיבים קשורים כדי לאפשר לכם ליצור, להפיץ ולנהל את מחזור החיים של האפליקציות שלכם.
הרכיבים של GKE שמשמשים לפריסת תוכנית האב הם:
- GKE לניהול קונטיינרים
- Policy Controller לניהול מדיניות ואכיפת מדיניות
הרכיבים הקשורים שמשמשים לפריסת התוכנית הם:
- Cloud Service Mesh לניהול שירותים
- Binary Authorization לאימות קובץ אימג' של קונטיינר
- GKE Gateway controller בשביל בקר שערים מרובי אשכולות לאשכולות GKE
ניהול ה-Fleet בפלטפורמה
Fleets מאפשרים לכם לנהל כמה אשכולות GKE בדרך מאוחדת. ניהול צוותים ב-Fleet מקל על אדמינים של פלטפורמות להקצות ולנהל משאבי תשתית לדיירים בפלטפורמת הפיתוח. לדיירים יש שליטה מוגבלת במשאבים במרחב השמות שלהם, כולל האפליקציות, היומנים והמדדים שלהם.
כדי להקצות קבוצות משנה של משאבים ב-Fleet על בסיס צוות, אדמינים יכולים להשתמש בהיקפי צוות. היקפי צוות מאפשרים להגדיר קבוצות משנה של משאבי Fleet לכל צוות, כאשר כל היקף צוות משויך לאחד או יותר מאשכולות של חברי Fleet.
מרחבי שמות של Fleet מאפשרים לקבוע למי תהיה גישה למרחבי שמות ספציפיים ב-Fleet. האפליקציה משתמשת בשני אשכולות GKE שנפרסים ב-Fleet אחד, עם שלושה היקפי צוות, ולכל היקף יש מרחב שמות אחד של Fleet.
בתרשים הבא מוצגים משאבי הצי וההיקף שמתאימים לאשכולות לדוגמה בסביבה, כפי שהם מיושמים בתוכנית ה-blueprint.
Platform networking
לצורך יצירת רשתות, קלאסטרים של GKE נפרסים ב-VPC משותף שנוצר כחלק מתוכנית הבסיס של הארגון. בסביבות פיתוח, בסביבות שאינן ייצור ובסביבות ייצור, צריך להקצות ל-GKE clusters כמה טווחי כתובות IP. לכל אשכול GKE שמשמש את התוכנית צריך להקצות טווחי כתובות IP נפרדים לצמתים, ל-Pods, לשירותים ולרמת הבקרה. גם מכונות AlloyDB ל-PostgreSQL דורשות טווחי כתובות IP נפרדים.
בטבלה הבאה מתוארים רשתות המשנה של ה-VPC וטווחי כתובות ה-IP שמשמשים בסביבות השונות לפריסת אשכולות התוכנית. בסביבת הפיתוח באזור 2 של אשכול GKE של האפליקציה, תוכנית ה-Blueprint פורסת רק מרחב כתובות IP אחד, למרות שהוקצה מרחב כתובות IP לשני אשכולות GKE של פיתוח.
| משאב | סוג טווח כתובות IP | פיתוח | לא לייצור | ייצור |
|---|---|---|---|---|
אזור 1 של אשכול GKE של האפליקציה |
טווח כתובות ה-IP הראשי |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
טווח כתובות ה-IP של ה-Pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
טווח כתובות ה-IP של השירות |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
טווח כתובות ה-IP של מישור הבקרה של GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
אזור 2 של אשכול GKE של האפליקציה |
טווח כתובות ה-IP הראשי |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
טווח כתובות ה-IP של ה-Pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
טווח כתובות ה-IP של השירות |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
טווח כתובות ה-IP של מישור הבקרה של GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB ל-PostgreSQL |
טווח כתובות ה-IP של מסד הנתונים |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
אם אתם צריכים לתכנן תוכנית משלכם להקצאת כתובות IP, תוכלו לעיין במאמרים ניהול כתובות IP ב-GKE ותכנון כתובות IPv4 ב-GKE.
DNS של הפלטפורמה
תוכנית האב משתמשת ב-Cloud DNS for GKE כדי לספק פענוח DNS לפודים ולשירותי Kubernetes. Cloud DNS for GKE הוא DNS מנוהל שלא דורש ספק DNS שמתארח באשכול.
בתוכנית ה-blueprint, Cloud DNS מוגדר להיקף VPC. היקף VPC מאפשר לשירותים בכל אשכולות GKE בפרויקט לשתף אזור DNS יחיד. תחום DNS יחיד מאפשר לשירותים להיפתר באשכולות, ולמכונות וירטואליות או ל-Pod-ים מחוץ לאשכול לפתור שירותים בתוך האשכול.
חומות אש בפלטפורמה
GKE יוצר באופן אוטומטי כללים של חומת אש כשיוצרים אשכולות GKE, שירותי GKE, חומות אש של GKE Gateway וחומות אש של GKE Ingress שמאפשרים לאשכולות לפעול בסביבות שלכם. העדיפות של כל הכללים של חומת האש שנוצרים באופן אוטומטי היא 1000. הכללים האלה נדרשים כי לתוכנית הבסיסית של הארגון יש כלל ברירת מחדל לחסימת תנועה ב-VPC המשותף.
גישה לפלטפורמות Google Cloud לשירותים
מכיוון שאפליקציות התוכנית משתמשות באשכולות פרטיים, גישה פרטית ל-Google מספקת גישה לשירותים. Google Cloud
זמינות גבוהה של הפלטפורמה
התוכנית נועדה להיות עמידה בפני הפסקות חשמל באזורים ובתחומים. המשאבים שנדרשים להפעלת האפליקציות מפוזרים בשני אזורים. בוחרים את האזורים שרוצים לפרוס בהם את התוכנית. משאבים שלא נמצאים בנתיב הקריטי להצגה ולתגובה לטעינה הם אזוריים בלבד או גלובליים. בטבלה הבאה מתוארים המשאבים והמיקום שבו הם נפרסים.
מיקום |
אזור 1 |
אזור 2 |
עולמי |
|---|---|---|---|
סביבות עם משאבים במיקום הזה |
|
|
|
פרויקטים עם משאבים במיקום הזה |
|
|
|
סוגי המשאבים במיקום הזה |
|
|
|
בטבלה הבאה מפורט סיכום של אופן התגובה של רכיבים שונים להפסקה זמנית בשירות באזור או בתחום (zone), ואיך אפשר לצמצם את ההשפעות האלה.
היקף הכשל |
אפקטים של שירותים חיצוניים |
אפקטים של מסד נתונים | יצירה ופריסה של אפקטים | השפעות של צינורות עיבוד נתונים של Terraform |
|---|---|---|---|---|
אזור באזור 1 |
זמין |
זמין מופע ההמתנה הופך לפעיל עם RPO אפס. |
זמין, יכול להיות שצריך לשנות ידנית. יכול להיות שתצטרכו להפעיל מחדש כל פקודה של |
זמין, יכול להיות שצריך לשנות ידנית. יכול להיות שתצטרכו להפעיל מחדש כל פקודה של |
אזור 2 |
זמין |
זמין |
זמין |
זמין, יכול להיות שצריך לשנות ידנית. יכול להיות שתצטרכו להפעיל מחדש כל פקודה של |
אזור 1 |
זמין |
נדרש שינוי ידני. מפעיל חייב לקדם את האשכול המשני באופן ידני. |
לא זמין. |
לא זמין. |
אזור 2 |
זמין |
זמין |
זמין, יכול להיות שיידרש שינוי ידני הגרסאות יישארו זמינות. יכול להיות שתצטרכו לפרוס גרסאות build חדשות באופן ידני. יכול להיות שגרסאות build קיימות לא יושלמו בהצלחה. |
זמין |
הפסקות שירות אצל ספקי שירותי ענן הן רק מקור אחד לזמן השבתה. זמינות גבוהה תלויה גם בתהליכים ובפעולות שמפחיתים את הסיכוי לטעות. בטבלה הבאה מתוארות כל ההחלטות שהתקבלו בתוכנית הפעולה שקשורות לזמינות גבוהה, והסיבות להחלטות האלה.
| החלטה לגבי תוכנית | השפעה על הזמינות |
|---|---|
ניהול שינויים |
|
שימוש ב-GitOps וב-IaC. |
תומך בביקורת עמיתים על שינויים ובחזרה מהירה להגדרות קודמות. |
קידום שינויים באופן הדרגתי בסביבות שונות. |
מצמצם את ההשפעה של שגיאות תוכנה ושגיאות בהגדרות. |
הקפידו שסביבות שאינן סביבות ייצור יהיו דומות לסביבות הייצור. |
כך אפשר לוודא שההבדלים לא יעכבו את גילוי השגיאה. שתי הסביבות הן בשני אזורים. |
שינוי משאבים משוכפלים באזור אחד בכל פעם בסביבה. |
הבדיקה מבטיחה שבעיות שלא זוהו על ידי קידום הדרגתי ישפיעו רק על מחצית מתשתית זמן הריצה. |
לשנות שירות באזור אחד בכל פעם בסביבה. |
השיטה הזו מבטיחה שבעיות שלא זוהו על ידי העלאה הדרגתית ישפיעו רק על מחצית מהעותקים של השירות. |
תשתית מחשוב משוכפלת |
|
שימוש במישור בקרה של אשכול אזורי. |
מישור הבקרה האזורי זמין במהלך השדרוג ושינוי הגודל. |
יוצרים מאגר צמתים מרובה אזורים. |
מאגר צמתים של אשכול מכיל לפחות שלושה צמתים שמפוזרים על פני שלושה אזורים. |
הגדרת רשת VPC משותפת. |
רשת ה-VPC המשותפת מכסה שני אזורים. כשל אזורי משפיע רק על תנועה ברשת אל משאבים באזור הכושל וממשאבים כאלה. |
שכפול של מאגר תמונות. |
התמונות מאוחסנות ב-Artifact Registry, שמוגדר לשכפול למספר אזורים כדי ששיבוש באזור בענן לא ימנע את הגדלת קנה המידה של האפליקציה באזור שנותר פעיל. |
שירותים משוכפלים |
|
פריסת עותקים של השירות בשני אזורים. |
במקרה של הפסקת שירות אזורית, שירות Kubernetes נשאר זמין בסביבות הייצור והלא-ייצור. |
שימוש בעדכונים מתגלגלים לשינויים בשירות באזור מסוים. |
אפשר לעדכן שירותי Kubernetes באמצעות דפוס פריסה של עדכון בהדרגה (rolling update), שמקטין את הסיכון ואת זמן ההשבתה. |
מגדירים שלוש רפליקות באזור לכל שירות. |
לשירות Kubernetes יש לפחות שלוש רפליקות (pods) כדי לתמוך בעדכונים מדורגים בסביבת הייצור ובסביבה שאינה סביבת ייצור. |
פיזור הפודים של הפריסה על פני אזורים שונים. |
שירותי Kubernetes מפוזרים בין מכונות וירטואליות באזורים שונים באמצעות פסקה של anti-affinity. אפשר להתמודד עם שיבוש בצומת יחיד או עם הפסקה זמנית בשירות של אזור שלם בלי להוסיף תעבורה בין אזורים לשירותים תלויים. |
אחסון משוכפל |
|
פריסה של מופעי מסדי נתונים בכמה אזורים. |
AlloyDB ל-PostgreSQL מציע זמינות גבוהה באזור. הצמתים העודפים של המופע הראשי שלה ממוקמים בשני אזורים שונים באזור. המופע הראשי שומר על זמינות אזורית על ידי הפעלת מעבר אוטומטי לגיבוי לאזור ההמתנה אם מתגלה בעיה באזור הפעיל. אחסון אזורי עוזר לספק עמידות נתונים במקרה של אובדן באזור יחיד. |
שכפול מסדי נתונים באזורים שונים. |
AlloyDB ל-PostgreSQL משתמש בשכפול בין אזורים כדי לספק יכולות של התאוששות מאסון. מסד הנתונים משכפל באופן אסינכרוני את הנתונים של האשכול הראשי לאשכולות משניים שנמצאים בGoogle Cloud אזורים נפרדים. |
פעולות |
|
הקצאת משאבים לאפליקציות בהיקף כפול מהעומס הצפוי. |
אם אשכול אחד נכשל (לדוגמה, בגלל הפסקה זמנית בשירות אזורי), החלק של השירות שפועל באשכול הנותר יכול לספוג את העומס באופן מלא. |
תיקון הצמתים באופן אוטומטי. |
האשכולות מוגדרים עם תיקון אוטומטי של הצמתים. אם בדיקות תקינות רצופות של צומת נכשלות שוב ושוב לאורך תקופה ממושכת, GKE מתחיל תהליך תיקון של הצומת הזה. |
מוודאים שהשדרוגים של מאגר הצמתים מודעים לאפליקציה. |
פריסות מגדירות תקציב להפרעה של פודים עם |
הפעלה מחדש אוטומטית של שירותים שנתקעו. |
הפריסה שמגבה שירות מגדירה בדיקת פעילות, שמזהה תהליכים תקועים ומפעילה אותם מחדש. |
בודקים אוטומטית אם הרפליקות מוכנות. |
פריסת הגיבוי של שירות מגדירה בדיקת מוכנות, שמזהה מתי אפליקציה מוכנה להצגה אחרי ההפעלה. בדיקת מוכנות מייתרת את הצורך בבדיקות ידניות או בהמתנה מתוזמנת במהלך עדכונים מדורגים ושדרוגים של מאגרי צמתים. |
הארכיטקטורה לדוגמה מיועדת לאפליקציות עם דרישות זמינות גבוהה אזוריות ואזוריות. כדי להבטיח זמינות גבוהה, יש עלויות מסוימות (למשל, עלויות של חלקי חילוף במצב המתנה או עלויות של שכפול בין אזורים). בקטע חלופות מפורטות כמה דרכים לצמצום העלויות האלה.
מכסות פלטפורמה, מגבלות ביצועים ומגבלות הרחבה
בפלטפורמת הפיתוח אפשר לשלוט במכסות, בביצועים ובשינוי הגודל של המשאבים. ריכזנו כאן כמה דברים שכדאי לזכור:
- תשתית הבסיס דורשת פרויקטים רבים, וכל דייר נוסף דורש ארבעה פרויקטים. יכול להיות שתצטרכו לבקש מכסה נוספת לפרויקט לפני הפריסה ולפני הוספה של דיירים נוספים.
- לכל פרויקט אפשר ליצור עד 100 משאבי MultiClusterGateway. כל שירות Kubernetes שפונה לאינטרנט בפלטפורמת הפיתוח דורש MultiClusterGateway אחד.
- ב-Cloud Logging יש מגבלה של 100 קטגוריות בפרויקט. הגישה ליומן לכל דייר בתוכנית הבסיסית מסתמכת על קטגוריה לכל דייר.
- כדי ליצור יותר מ-20 דיירים, אפשר לבקש להגדיל את המכסה של הפרויקט למשאבי Scope ו-Scope Namespace. הוראות להצגת מכסות זמינות במאמר הצגה וניהול של מכסות. אפשר להשתמש במסנן כדי למצוא את מכסות
gkehub.googleapis.com/global-per-project-scopesו-gkehub.googleapis.com/global-per-project-scope-namespaces.
המאמרים הבאים
- מידע נוסף על ארכיטקטורת השירות (המסמך הבא בסדרה).