תכנון העברת אשכול לתכונות מומלצות

סקירה כללית

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

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

לכל תחום תכונות יש את האפשרויות הבאות:

תחום התכונה	האפשרויות המומלצות	אפשרויות מקוריות
ממשק רשת של קונטיינר (CNI)	Dataplane V2 (enableDataplaneV2: true)	Dataplane V1 (Calico) (enableDataplaneV2: false)
מאזן עומסים	‫ManualLB (פועל עם סוכני F5 Big IP) (loadBalancer.kind: "ManualLB") ‫MetalLB (loadBalancer.kind: "MetalLB")	‫F5 Big IP משולב^1 (loadBalancer.kind: "F5BigIP") Seesaw (loadBalancer.kind: "Seesaw")
מישור הבקרה של אשכול האדמין	קלאסטר אדמין עם זמינות גבוהה (HA) (adminMaster.replicas: 3)	קלאסטר אדמין ללא זמינות גבוהה (adminMaster.replicas: 1)
מישור הבקרה של אשכול משתמשים	Controlplane V2 (enableControlplaneV2: true)	אשכול משתמשים של Kubeception (enableControlplaneV2: false)

‫^{1 Integrated F5 BIG-IP מתייחס ל-loadBalancer.kind: "F5BigIP" ולהגדרות קשורות בקטע loadBalancer.f5BigIP בקובץ ההגדרות של האשכול.}

בטבלאות הבאות מוצגת מטריצת התמיכה בתכונות האלה באשכולות של אדמינים ומשתמשים:

סוג האשכול	תכונה מיושנת	הוספה לאשכול חדש	אפשרות לשדרוג האשכול	מעבר לתכונה חדשה
גרסה 1.32 ואילך
אדמין	Non-HA	לא	לא	לא רלוונטי
	Seesaw	לא	לא	לא רלוונטי
	שילוב של F5 Big IP	לא	לא	לא רלוונטי
משתמש	Kubeception	לא	לא	לא רלוונטי
	Seesaw	לא	לא	לא רלוונטי
	שילוב של F5 Big IP	לא	לא	לא רלוונטי
	Dataplane V1	לא	לא	לא רלוונטי
גרסאות 1.30 ו-1.31
אדמין	Non-HA	לא	כן	כן
	Seesaw	לא	כן	כן
	שילוב של F5 Big IP	לא	כן	כן
משתמש	Kubeception	לא	כן	כן
	Seesaw	לא	כן	כן
	שילוב של F5 Big IP	לא	כן	כן
	Dataplane V1	לא	כן	כן
גרסה 1.29
אדמין	Non-HA	לא	כן	כן (תצוגה מקדימה)
	Seesaw	לא	כן	כן
	שילוב של F5 Big IP	כן	כן	כן (תצוגה מקדימה)
משתמש	Kubeception	כן	כן	כן (תצוגה מקדימה)
	Seesaw	כן	כן	כן
	שילוב של F5 Big IP	כן	כן	כן (תצוגה מקדימה)
	Dataplane V1	כן	כן	לא
גרסה 1.28
אדמין	Non-HA	לא	כן	לא
	Seesaw	לא	כן	כן
	שילוב של F5 Big IP	כן	כן	לא
משתמש	Kubeception	כן	כן	לא
	Seesaw	כן	כן	כן
	שילוב של F5 Big IP	כן	כן	לא
	Dataplane V1	כן	כן	לא

נקודות עיקריות:

• החל מגרסה 1.30, כל פתרונות ההעברה זמינים להעברת אשכולות לחלופות המומלצות שלהם.

• כשיוצרים אשכולות חדשים, אלה הגרסאות שבהן אסור להשתמש בתכונות המקוריות:

  • קלאסטרים של אדמינים:

    • מישור בקרה ללא זמינות גבוהה: 1.28 ואילך
    • איזון עומסים של Seesaw: ‏ 1.28 ומעלה
    • שילוב עם F5 Big IP: גרסה 1.30 ואילך

  • אשכולות משתמשים:

    • ‫Kubeception: גרסה 1.30 ואילך
    • ‫Seesaw: גרסה 1.30 ואילך
    • שילוב עם F5 Big IP: גרסה 1.30 ואילך
    • ‫Dataplane V1: גרסה 1.30 ואילך

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

העברת אשכולות משתמשים ל-Dataplane V2

אפשר לבחור Container Network Interface ‏ (CNI) שמציע תכונות של רשתות קונטיינרים, כמו Calico או Dataplane V2. ‫Dataplane V2, ההטמעה של CNI ב-Google, מבוססת על Cilium ומשמשת גם ב-Google Kubernetes Engine ‏ (GKE) וגם ב-Google Distributed Cloud.

‫Dataplane V2 מספק עיצוב אופטימלי וניצול יעיל של משאבים, מה שמוביל לשיפור בביצועי הרשת ולשיפור יכולת ההתאמה, במיוחד עבור אשכולות גדולים או סביבות עם דרישות גבוהות לתנועת נתונים ברשת. מומלץ מאוד להעביר את האשכולות ל-Dataplane V2 כדי ליהנות מהתכונות, מהחידושים ומהיכולות העדכניים ביותר בתחום הרשת.

החל מגרסה 1.30, ‏ Dataplane V2 היא האפשרות היחידה של CNI ליצירת אשכולות חדשים.

המעבר מ-Calico ל-Dataplane V2 דורש תכנון ותיאום, אבל הוא מתוכנן כך שלא תהיה השבתה של עומסי עבודה קיימים. אם תעברו באופן יזום ל-Dataplane V2, תוכלו ליהנות מהיתרונות הבאים:

• ביצועים ויכולת הרחבה משופרים: העיצוב המותאם של Dataplane V2 והשימוש היעיל במשאבים יכולים לשפר את ביצועי הרשת ואת יכולת ההרחבה, במיוחד באשכולות גדולים או בסביבות עם דרישות גבוהות של תנועת רשת. הסיבה לכך היא השימוש ב-EBPF במקום ב-IPTables, שמאפשר להגדיל את הקיבולת של האשכול באמצעות מיפוי BPF.

• ניהול ותמיכה פשוטים יותר: שימוש ב-Dataplane V2 כסטנדרט ב-Google Distributed Cloud וב-GKE יכול לפשט את ניהול האשכולות ואת פתרון הבעיות, כי אפשר להסתמך על קבוצה עקבית של כלים ומסמכים.

• תכונות מתקדמות של רשת: EgressNAT ותכונות מתקדמות אחרות של רשת נתמכות רק ב-Dataplane V2. כל בקשה עתידית בנושא רשת תיושם בשכבת Dataplane V2.

	לפני ההעברה	אחרי המיגרציה
kube-proxy	חובה ופריסה אוטומטית	לא נדרש ולא הופעל
ניתוב	kube-proxy + iptables	eBPF

העברת סוג של מאזן עומסים

סוגי מאזני העומסים המומלצים (loadBalancer.kind) הם "ManualLB" ו-"MetalLB". משתמשים ב-"ManualLB" אם יש לכם מאזן עומסים של צד שלישי, כמו F5 BIG-IP או Citrix. להשתמש ב-"MetalLB" לפתרון איזון העומסים המצורף שלנו באמצעות מאזן העומסים MetalLB.

החל מגרסה 1.30, אלה האפשרויות היחידות ליצירת אשכולות חדשים. לגבי אשכולות קיימים שמשתמשים ב-F5 Big IP המשולב או במאזן העומסים המצורף Seesaw, אנחנו מספקים מדריכים להעברת הגדרות התצורה של "F5BigIP" אל "ManualLB", ולהעברת מאזן העומסים המצורף מ-Seesaw אל MetalLB.

העברת הגדרות של מאזן עומסים F5 BIG-IP

תכנון העברה של אשכולות שמשתמשים ב-F5 Big IP המשולב אל ManualLB. השילוב של F5 Big IP משתמש ב-F5 BIG-IP עם סוכני מאזן עומסים, שכוללים את שני הבקרים הבאים:

• ‫F5 Controller ‏ (pod prefix: load-balancer-f5): מבצע גישור בין שירותי Kubernetes מסוג LoadBalancer לבין פורמט F5 Common Controller Core Library (CCCL) ConfigMap.
• ‫F5 BIG-IP CIS Controller v1.14 ‏ (pod prefix: k8s-bigip-ctlr-deployment): מתרגם ConfigMaps להגדרות של מאזן העומסים F5.

לשילוב המקורי של F5 Big IP יש את המגבלות הבאות:

• הבעה מוגבלת: השילוב של F5 Big IP מגביל את הפוטנציאל המלא של F5 BIG-IP, כי הוא מגביל את ההבעה של Service API. יכול להיות שלא תוכלו להגדיר את בקר BIG-IP בהתאם לצרכים הספציפיים שלכם או להשתמש בתכונות מתקדמות של F5 שעשויות להיות חיוניות לאפליקציה שלכם.
• רכיב מדור קודם: ההטמעה הנוכחית מסתמכת על טכנולוגיות ישנות יותר כמו CCCL ConfigMap API ו-CIS בגרסה 1.x. יכול להיות שהרכיבים האלה מדור קודם לא תואמים לחידושים האחרונים במוצרים של F5, ולכן יכול להיות שתחמיצו הזדמנויות לשיפור הביצועים ולחיזוק האבטחה.

השינויים אחרי המעבר מ-F5 BIG-IP המשולב אל ManualLB כוללים:

	לפני ההעברה	אחרי המיגרציה
רכיבים של סוכני F5	F5 Controller OSS CIS Controller	F5 Controller (ללא שינוי) בקר OSS CIS (ללא שינוי)
שדרוג גרסת הרכיב F5	כדי לשדרג רכיבי F5, צריך לשדרג את האשכולות. כמו שהוסבר קודם, הגרסאות הזמינות של הרכיבים מוגבלות.	אפשר לשדרג את גרסאות הרכיבים של F5 לפי הצורך.
יצירת שירות	בטיפול על ידי סוכני F5	הטיפול מתבצע על ידי סוכני F5 (ללא שינוי)

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

העברה מ-Seesaw ל-MetalLB

ל-MetalLB יש את היתרונות הבאים בהשוואה ל-Seesaw:

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

	לפני ההעברה	אחרי המיגרציה
צמתים של איזון עומסים	מכונות וירטואליות נוספות של Seesaw (מחוץ לאשכול)	צמתים של איזון עומסים בתוך האשכול עם אפשרויות בחירה ללקוחות
שמירה על כתובת ה-IP של הלקוח	אפשר לעשות את זה דרך externalTrafficPolicy: Local	אפשר להשיג זאת באמצעות מצב DSR של DataplaneV2
יצירת שירות	כתובת IP של שירות שצוינה באופן ידני	כתובת IP של שירות שהוקצתה אוטומטית ממאגר כתובות

העברת אשכולות משתמשים ל-Controlplane V2 ואשכולות אדמין ל-HA

מומלץ להשתמש ב-Controlplane V2 כמישור הבקרה עבור אשכולות משתמשים. ב-Controlplane V2, מישור הבקרה פועל בצומת אחד או יותר באשכול המשתמשים עצמו. במישור הבקרה מדור קודם, שנקרא kubeception, מישור הבקרה של אשכול משתמשים פועל באשכול אדמין. כדי ליצור אשכול אדמין עם זמינות גבוהה (HA), צריך להפעיל את Controlplane V2 באשכולות המשתמשים.

החל מגרסה 1.30, נדרשת הפעלה של Controlplane V2 באשכולות משתמשים חדשים, ואשכולות אדמין חדשים יהיו HA. עדיין יש תמיכה בשדרוגים של אשכולות משתמשים עם מישור בקרה מדור קודם, וגם בשדרוגים של אשכולות אדמין שאינם HA.

העברת אשכולות משתמשים ל-Controlplane V2

בעבר, נעשה שימוש ב-kubeception באשכולות משתמשים. בגרסה 1.13 הושקה Controlplane V2 כתכונת טרום-השקה (Preview), שהפכה לזמינה לכולם (GA) בגרסה 1.14. החל מגרסה 1.15, Controlplane V2 היא אפשרות ברירת המחדל ליצירת אשכולות משתמשים, והיא האפשרות היחידה בגרסה 1.30.

בהשוואה ל-kubeception, היתרונות של Controlplane V2 כוללים:

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

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

• יוצר מישור בקרה חדש באשכול המשתמשים.
• העתקת נתוני etcd ממישור הבקרה הישן.
• מעבירים את הצמתים הקיימים במאגר הצמתים (שנקראים גם צמתים של עובדים) למישור הבקרה החדש.

	לפני ההעברה	אחרי המיגרציה
אובייקטים של צומת Kubernetes ברמת הבקרה	צומת באשכול אדמין	צומת באשכול משתמשים
‫Pods של מישור הבקרה של Kubernetes	פריסות או Statefulsets של אשכול אדמין (מרחב שמות של אשכול משתמש)	Static pods באשכול משתמש (מרחב השמות kube-system)
רכיבי Control Plane אחרים	פריסות או Statefulsets של אשכול אדמין (מרחב שמות של אשכול משתמש)	‫Statefulsets/Deployments באשכול משתמש (מרחב השמות kube-system)
כתובת VIP של מישור הבקרה	שירות מאזן עומסים באשכול אדמין	‫keepalived + haproxy (user cluster static pods)
נתוני etcd	נפח אחסון מתמיד (Persistent Volume) באשכול אדמין	דיסק נתונים
ניהול כתובות IP של מכונות במישור הבקרה	IPAM או DHCP	IPAM
Control Plane Network	VLAN של אשכול אדמין	VLAN של אשכול משתמשים

מעבר לאשכול אדמין עם זמינות גבוהה

בעבר, באשכול האדמין אפשר היה להפעיל רק צומת אחד של מישור הבקרה, מה שיצר סיכון מובנה של נקודת כשל יחידה. בנוסף לצומת של מישור הבקרה, באשכולות אדמין שאינם HA יש גם שני צמתים של תוספים. למקבץ אדמין עם זמינות גבוהה יש שלושה צמתים של מישור הבקרה ללא צמתים של תוספים, כך שמספר המכונות הווירטואליות שמקבץ אדמין חדש דורש לא השתנה, אבל הזמינות השתפרה באופן משמעותי. החל מגרסה 1.16, אפשר להשתמש באשכול אדמין עם זמינות גבוהה (HA), שהפך לאפשרות היחידה ליצירת אשכול חדש בגרסה 1.28.

היתרונות של מעבר לאשכול אדמין עם זמינות גבוהה:

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

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

• יצירת מישור בקרה חדש עם זמינות גבוהה.
• שחזור נתוני etcd מהאשכול הקיים שאינו HA.
• מעבירים את אשכולות המשתמשים לאשכול האדמין החדש של HA.

	לפני ההעברה	אחרי המיגרציה
רפליקות של צומת מישור הבקרה	1	3
צמתים של תוספים	2	0
גודל דיסק הנתונים	‫100GB * 1	‫25GB * 3
נתיב דיסקים של נתונים	מוגדר על ידי vCenter.dataDisk בקובץ התצורה של אשכול הניהול	נוצר באופן אוטומטי בספרייה: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
כתובת VIP של מישור הבקרה	הגדרה באמצעות loadBalancer.kind בקובץ התצורה של אשכול האדמין	keepalived + haproxy
הקצאה של כתובות IP לצמתים של מישור הבקרה באשכול אדמין	‫DHCP או סטטי, בהתאם ל-network.ipMode.type	3 כתובות IP סטטיות

העברות של מאזני עומסים ומישורי בקרה

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

אם יש לכם אשכולות משתמשים שמשתמשים ב-CNI ישן, אתם צריכים קודם לבצע מיגרציה ל-DataPlane V2. אחרי כן, אפשר לקבץ את ההעברה של מאזן העומסים ושל מישור הבקרה. קיבוץ ההעברות מספק את היתרונות הבאים:

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

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

1. מעבירים כל אשכול משתמשים לשימוש ב-CNI המומלץ, Dataplane V2.

   1. מבצעים את שינויי ההגדרה ומעדכנים את אשכול המשתמשים כדי להפעיל העברה של אשכול המשתמשים מ-CNI הישן, Calico, אל Dataplane V2.

      הערה: השלב הזה לא נדרש עבור אשכול האדמין. כשמשדרגים את אשכול האדמין לגרסה 1.30, האשכול עובר אוטומטית ל-Dataplane V2.

2. מעבירים כל אשכול משתמשים ממאזן העומסים הישן (LB) ומישור הבקרה הישן (CP) לשימוש במאזן העומסים המומלץ וב-Controlplane V2.

   1. לבצע שינויים בהגדרות כדי להשתמש במאזן העומסים המומלץ (MetalLB או ManualLB).
   2. מבצעים שינויים בהגדרות כדי להפעיל את Controlplane V2.
   3. מעדכנים את אשכול המשתמשים כדי להעביר את מאזן העומסים ואת מישור הבקרה.

3. מעבירים את אשכול האדמין לשימוש במאזן העומסים המומלץ, כדי להפוך את מישור הבקרה לזמין מאוד.

   1. לבצע שינויים בהגדרות כדי להשתמש במאזן העומסים המומלץ (MetalLB או ManualLB).
   2. ביצוע שינויים בהגדרות כדי להעביר את מישור הבקרה של אשכול האדמין מ-Non-HA ל-HA.
   3. מעדכנים את אשכול האדמין כדי להעביר את מאזן העומסים ואת מישור הבקרה.

4. מבצעים שלבי ניקוי אופציונליים, כמו ניקוי של מכונת ה-VM של מישור הבקרה שאינה HA.

התרשים הבא מדגים את שלבי ההעברה:

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

• העברת אשכולות משתמשים לתכונות מומלצות
• העברת אשכול אדמין לתכונות מומלצות