ארכיטקטורת העזר הזו מספקת פתרון עם זמינות גבוהה ועם יכולת הרחבה, שמשתמש ב-Cloud Service Mesh וב-Envoy gateways כדי לנהל את תעבורת הנתונים ברשת עבור אפליקציות Windows שפועלות ב-Google Kubernetes Engine (GKE). במאמר מוסבר איך לנהל את תעבורת הרשת הזו באמצעות שירות שיכול לנתב תעבורה ל-Pods ולשרת proxy תואם xDS בקוד פתוח. שימוש בארכיטקטורה כזו יכול לעזור להפחית עלויות ולשפר את ניהול הרשת.
המסמך הזה מיועד למומחי Cloud Architect, לאדמינים של רשתות ולמומחי IT שאחראים על עיצוב וניהול של אפליקציות Windows שפועלות ב-GKE.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה לניהול רשתות עבור אפליקציות Windows שפועלות ב-GKE באמצעות Cloud Service Mesh ושערי Envoy:
הארכיטקטורה כוללת את הרכיבים הבאים:
- אשכול GKE אזורי עם מאגרי צמתים של Windows ו-Linux.
- שתי אפליקציות Windows שפועלות בשני תאי GKE Pod נפרדים.
- כל אפליקציה נחשפת על ידי
ClusterIP-סוג Kubernetes Service ועל ידי קבוצה של נקודות קצה ברשת (NEG).
- כל אפליקציה נחשפת על ידי
- Cloud Service Mesh יוצר ומנהל את נתיבי התנועה אל קבוצות ה-NEG לכל פוד של GKE. כל מסלול ממופה ל
scopeספציפי. הערךscopeמזהה באופן ייחודי שער כניסה של Cloud Service Mesh. - מסלולי HTTP שממופים לשירותי ה-Backend של Cloud Service Mesh.
- Envoy Pods של קונטיינרים שפועלים כשער Envoy לאשכול GKE.
- שערי Envoy שפועלים בצמתי Linux. הגדרנו את השערים כך שינתבו את התעבורה לאפליקציות Windows דרך השירותים שתואמים לאפליקציות האלה. Envoy מוגדר להשתמש בפרמטר
scopeכדי לטעון את פרטי ההגדרה של שירותי Cloud Service Mesh הרלוונטיים. - מאזן עומסים פנימי של אפליקציות שמסיים את תנועת ה-SSL ומפנה את כל התנועה החיצונית הנכנסת אל שער Envoy.
המוצרים שהשתמשו בהם
בארכיטקטורת ההפניה הזו נעשה שימוש במוצרים הבאים של Google Cloud ושל צד שלישי:
Google Cloud products
- Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים וניתנים להתאמה.
- Google Kubernetes Engine (GKE): שירות Kubernetes שמאפשר לפרוס ולהפעיל אפליקציות בקונטיינרים בהיקף גדול באמצעות התשתית של Google.
- Cloud Service Mesh: חבילת כלים שבעזרתם תוכלו לנהל ולנטר רשת Service mesh אמינה בתשתית המקומית או ב-Google Cloud.
מוצרים של צד שלישי
- Envoy Gateway: ניהול של Envoy proxy כשער אפליקציות עצמאי או מבוסס Kubernetes.
- Gateway API: פרויקט רשמי של Kubernetes שמתמקד בניתוב L4 ו-L7 ב-Kubernetes.
תרחיש שימוש
תרחיש השימוש העיקרי בארכיטקטורת העזר הזו הוא ניהול תנועת רשת באפליקציות של Windows שפועלות ב-GKE. הארכיטקטורה הזו מספקת את היתרונות הבאים:
ניהול רשת פשוט: Cloud Service Mesh ושערי Envoy מספקים ניהול רשת פשוט באמצעות מישור בקרה מרכזי שמנהל את תעבורת הנתונים ברשת לאפליקציות. האפליקציות האלה יכולות להיות אפליקציות של Linux או של Windows שפועלות ב-GKE או ב-Compute Engine. שימוש בתוכנית הפשוטה הזו לניהול רשתות מצמצם את הצורך בהגדרות ידניות.
מדרגיות וזמינות משופרות: כדי לעמוד בדרישות המשתנות שלכם, אתם יכולים להשתמש ב-Cloud Service Mesh ובשערי Envoy כדי להרחיב את האפליקציות שלכם ב-Linux וב-Windows. אפשר גם להשתמש בשערי Envoy כדי לספק זמינות גבוהה לאפליקציות שלכם באמצעות איזון עומסים של תנועת הגולשים בכמה Pods.
אבטחה משופרת: אפשר להשתמש בשערי Envoy כדי להוסיף תכונות אבטחה לאפליקציות שלכם ב-Linux וב-Windows, כמו סיום SSL, אימות והגבלת קצב.
הפחתת עלויות: גם Cloud Service Mesh וגם שערים של Envoy יכולים לעזור להפחית את העלויות של ניהול תנועת רשת באפליקציות ל-Linux ול-Windows.
שיקולים בתכנון
בקטע הזה מוסבר איך לפתח ארכיטקטורה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, למהימנות, לעלות וליעילות.
אבטחה
- רשת מאובטחת: הארכיטקטורה משתמשת במאזן עומסים פנימי של אפליקציות (ALB) כדי להצפין את התעבורה הנכנסת לקונטיינרים של Windows. הצפנה בזמן העברה עוזרת למנוע דליפת נתונים.
- קונטיינרים של Windows: קונטיינרים של Windows מספקים סביבה מאובטחת ומבודדת לאפליקציות בקונטיינרים.
אמינות
- איזון עומסים: הארכיטקטורה משתמשת בכמה שכבות של Cloud Load Balancing כדי להפיץ את התעבורה בין שערים של Envoy ומאגרי Windows.
- עמידות בפני תקלות: הארכיטקטורה הזו עמידה בפני תקלות ואין בה נקודת כשל בודדת. העיצוב הזה עוזר להבטיח שהשירות תמיד יהיה זמין, גם אם אחד או יותר מהרכיבים ייכשלו.
- התאמה אוטומטית לעומס (autoscaling): הארכיטקטורה משתמשת בהתאמה אוטומטית לעומס כדי לשנות באופן אוטומטי את מספר שערים של Envoy ומאגרי Windows בהתאם לעומס. התכונה 'שינוי גודל אוטומטי' עוזרת לוודא שהשערים והאפליקציות יכולים להתמודד עם עליות חדות בתנועה בלי שיהיו בעיות בביצועים.
- מעקב: הארכיטקטורה משתמשת בGoogle Cloud שירות מנוהל ל-Prometheus וב-Cloud Operations כדי לעקוב אחרי התקינות של שערים של Envoy וקונטיינרים של Windows. הניטור עוזר לזהות בעיות בשלב מוקדם ולמנוע שיבושים באפליקציות.
הוזלת עלויות
- בחירת סוגי המופעים המתאימים לעומסי העבודה: כשבוחרים סוגי מופעים, צריך להתחשב בגורמים הבאים:
- מספר המעבדים הווירטואליים והזיכרון שהאפליקציות שלכם צריכות
- עומס התנועה הצפוי באפליקציות
- הצורך של המשתמשים באפליקציות עם זמינות גבוהה
שימוש בהתאמה אוטומטית לעומס (autoscaling): התאמה אוטומטית לעומס יכולה לעזור לכם לחסוך כסף על ידי התאמה אוטומטית של עומסי העבודה של Windows באופן אנכי ואופקי.
התאמה אנכית לעומס משנה את הבקשות והמגבלות של הקונטיינרים בהתאם לשימוש של הלקוח.
- אפשר להשתמש בVertical Pod Autoscaling כדי להגדיר אוטומציה של שינוי גודל אנכי.
הגדלה אופקית מוסיפה או מסירה פודים של Kubernetes כדי לענות על הביקוש.
- אפשר להשתמש בהתאמה אופקית של קבוצות Pod לעומס כדי להגדיר אוטומציה של שינוי גודל אופקי.
שימוש ב-Cloud Service Mesh ובשערי Envoy: Cloud Service Mesh ושערי Envoy יכולים לעזור לכם לחסוך כסף על ידי ניתוב יעיל של תעבורה לאפליקציות Windows שלכם. שימוש בניתוב יעיל יותר יכול לעזור לצמצם את כמות רוחב הפס שצריך לרכוש. הוא יכול גם לעזור לשפר את הביצועים של האפליקציות האלה.
שימוש ברשתות של ענן וירטואלי פרטי (VPC) משותף: רשתות של ענן וירטואלי פרטי משותף מאפשרות לכם לשתף VPC יחיד בין כמה פרויקטים. שיתוף יכול לעזור לכם לחסוך כסף כי הוא מצמצם את מספר ה-VPC שאתם צריכים ליצור ולנהל.
יעילות תפעולית
- כמה דומיינים עם מאזן עומסים פנימי יחיד: הארכיטקטורה משתמשת במאזני עומסים פנימיים של אפליקציות (ALB) כדי להפחית עומס של תעבורת SSL. כל פרוקסי יעד של HTTPS יכול לתמוך בכמה אישורי SSL (עד למקסימום הנתמך) כדי לנהל כמה אפליקציות עם דומיינים שונים.
- תשתית כקוד (IaC): כדי לנהל את התשתית, אפשר לפרוס את הארכיטקטורה באמצעות IaC. IaC עוזר לוודא שהתשתית שלכם עקבית וניתנת לשחזור.
פריסה
כדי לפרוס את הארכיטקטורה הזו, אפשר לעיין במאמר פריסת אפליקציות ל-Windows שפועלות ב-Kubernetes מנוהל.
המאמרים הבאים
- מידע נוסף על Google Cloud המוצרים שבהם נעשה שימוש במדריך העיצוב הזה:
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: איתן אייבשוץ | יועץ בכיר בנושא פתרונות טכניים
תורמי תוכן אחרים:
- John Laham | Solutions Architect
- Kaslin Fields | אחראית קשרי מפתחים
- מרידי (ראג'ו) מקאראג'ו | מוביל טכני בנושא תמיכה
- Valavan Rajakumar | Key Enterprise Architect
- Victor Moreno | Product Manager, Cloud Networking