Google Cloud מציע שתי פלטפורמות עיקריות להרצת אפליקציות בקונטיינרים: GKE להרצת קונטיינרים באשכולות Kubernetes, ו-Cloud Run להרצת קונטיינרים ישירות בתשתית Google Cloud . אבל מתי כדאי להשתמש באחד מהם? ואפשר להשתמש בשניהם? בדף הזה מוצגות השוואה בין שתי הפלטפורמות והיתרונות שלהן, ועזרה בהחלטה אם אסטרטגיה של פלטפורמה יחידה או אסטרטגיה היברידית מתאימות לכם.
המאמר הזה מיועד לאדמינים של תשתיות ולמפעילים של אפליקציות שמריצים מגוון רחב של עומסי עבודה בקונטיינרים, ורוצים לנצל את היתרונות של Google Kubernetes Engine (GKE) ושל Cloud Run כדי לפרוס אפליקציות בGoogle Cloud פלטפורמה.
לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את הנושאים הבאים:
עומסי עבודה בלי שמירת מצב ועומסי עבודה עם שמירת מצב
למה כדאי להשתמש ב-GKE וב-Cloud Run ביחד?
ל-GKE ול-Cloud Run יש יתרונות שונים להפעלת אפליקציות בקונטיינרים, והם מתאימים לרמות שונות של מורכבות עומסי עבודה. עם זאת, לא צריך לבחור בין שתי הפלטפורמות. אתם יכולים להשתמש בו-זמנית ביתרונות של GKE ושל Cloud Run על ידי העברת עומסי העבודה בין שתי הפלטפורמות לפי הצורך. אסטרטגיה היברידית כזו יכולה לעזור לכם לבצע אופטימיזציה של העלויות, הביצועים והתקורה הניהולית.
הנה כמה יתרונות לשימוש בשני זמני הריצה לפריסת עומסי העבודה:
ל-GKE ול-Cloud Run יש רמת ניידות גבוהה יחסית:
שתי הפלטפורמות משתמשות בקובצי אימג' סטנדרטיים של קונטיינרים כארטיפקטים של פריסה. אתם יכולים להשתמש באותו קובץ אימג' לאפליקציה שלכם בכל אחת מהפלטפורמות בלי לבצע שינויים, וכך להעביר בצורה חלקה עומסי עבודה בין GKE לבין Cloud Run. אם קובצי האימג' בקונטיינר מאוחסנים ב-Artifact Registry, לא צריך לעדכן את הגדרת האינטגרציה הרציפה (CI) כדי לבצע מיגרציה בין GKE לבין Cloud Run.
גם GKE וגם Cloud Run משתמשים במודל API מבוסס-הצהרות. Cloud Run Admin API v1 תוכנן כך שיהיה תואם ל-Kubernetes API. כלומר, אתם יכולים להשתמש במושגים מוכרים של Kubernetes כמו Deployments, Services ו-horizontal Pod autoscalers כדי לנהל את שירות Cloud Run. הדמיון הזה מקל על תרגום ההגדרות בין שתי הפלטפורמות.
המשאבים מיוצגים בקובצי YAML עם אותו מבנה הצהרתי וסטנדרטי, ולכן אפשר להעביר אותם בקלות בין סביבות זמן ריצה. בדוגמה הבאה מוצגת השוואה בין קובצי YAML של פריסת Kubernetes ושירות Cloud Run.
GKE ו-Cloud Run משתלבים בצורה חלקה עם Cloud Logging ו-Cloud Monitoring, ומספקים לכם תצוגה מרכזית במסוף כדי לעקוב אחרי מדדי האפליקציות, ללא קשר לפלטפורמה שלהן. Google Cloud אפשר גם להשתמש במעקב אחר יעדים למדידת רמת השירות (SLO) בשתי הפלטפורמות, ולראות תצוגה מאוחדת של ה-SLO בלוח הבקרה של Cloud Monitoring.
אתם יכולים להטמיע פיתוח רציף (CD) במשאבי GKE או בשירותי Cloud Run באמצעות Cloud Deploy. לחלופין, אם אתם מעדיפים, תוכלו לפרוס את האפליקציה בו-זמנית גם ב-GKE וגם ב-Cloud Run באמצעות פריסה מקבילה.
אתם יכולים להשתמש במאזני עומסים חיצוניים ופנימיים כדי לנהל שירותים ב-GKE וב-Cloud Run, וכך להקל על ניהול מתקדם של תעבורת נתונים. האפשרות הזו כוללת חשיפה של נקודות קצה חיצוניות, כך שאפשר לפרוס ולהפעיל כתובות URL שונות לאותה אפליקציה בשתי הפלטפורמות. אפשר גם לפצל את התעבורה לאותו שירות בין GKE ל-Cloud Run, וכך לאפשר העברה חלקה מפלטפורמה אחת לאחרת.
Google Cloud מספק כלים לאבטחה כדי לשפר את מצב האבטחה כשמשתמשים בשני זמני הריצה. סריקת מערכת הפעלה מאפשרת לסרוק קונטיינרים כדי לזהות נקודות חולשה לפני הפריסה בכל אחת מהפלטפורמות. מדיניות מרכזית של Binary Authorization יכולה לאכוף שילוב עם מישור הבקרה של GKE ו-Cloud Run כדי לאפשר או לחסום פריסה של תמונות על סמך המדיניות שאתם מגדירים. בעזרת VPC Service Controls, צוותי האבטחה יכולים להגדיר אמצעי בקרה מפורטים על גבולות גזרה של משאבי GKE ו-Cloud Run.
השוואה בין GKE ו-Cloud Run
כדי ליהנות מהתכונות הטובות ביותר של GKE ו-Cloud Run, וכדי לדעת מתי להעביר עומסי עבודה ביניהם, חשוב להבין את ההבדלים בין שני השירותים.
| תכונה | GKE | Cloud Run |
|---|---|---|
| פריסה וניהול | ניהול אשכולות Kubernetes, כולל הגדרת צמתים, רשתות, שינוי גודל ושדרוגים. Google Cloud מנהל את התשתית הבסיסית ומספק כלים לפשט את פעולות האשכול, אבל אתם עדיין אחראים להיבטים המרכזיים של Kubernetes. |
הרצת קונטיינרים ישירות על התשתית הניתנת להרחבה של Google Cloud. כל מה שצריך לעשות הוא לספק קוד מקור או קובץ אימג' של קונטיינר, ו-Cloud Run יכול ליצור את הקונטיינר בשבילכם. לא צריך ליצור אשכול, או לספק ולנהל תשתית. |
| שליטה וגמישות | שליטה מלאה באשכול Kubernetes. אתם יכולים ליצור התאמות אישיות מתקדמות של הגדרות הצמתים, מדיניות הרשת, הגדרות האבטחה ותוספים. |
שליטה מוגבלת בתשתית הבסיסית. אתם יכולים להגדיר דברים כמו משתני סביבה, מקביליות וחיבורי רשת, אבל אתם לא יכולים להתאים אישית את התשתית או הסביבה הבסיסיות. הפתרון האידיאלי לפשטות ולמהירות. |
| סוגי אפליקציות | הוא תומך באפליקציות ללא מצב (stateless) ובאפליקציות עם מצב (stateful), והוא אידיאלי לאפליקציות מורכבות עם צרכים ספציפיים של משאבים. | האפשרות הזו מתאימה לשירותים חסרי מצב (stateless), לשירותים מבוססי-בקשות או מבוססי-אירועים, לשירותי אינטרנט ולפונקציות. |
| מודל התמחור | תשלום לפי שעה לכל אשכול, ללא קשר למצב הפעולה (Standard או Autopilot), לגודל או לטופולוגיה של האשכול. | תשלום לפי שימוש, מעוגל כלפי מעלה ל-100 אלפיות השנייה הקרובות. |
תרחיש לדוגמה
נניח שאתם מנהלי פלטפורמה בחברה קמעונאית שבונה פלטפורמת מסחר אלקטרוני גדולה. יש לכם את עומסי העבודה הבאים שפועלים בקונטיינרים לפריסה:
אתר ואפליקציה לנייד בחלק הקדמי: אפליקציית אינטרנט בלי שמירת מצב שמטפלת בגלישה במוצרים, בחיפוש ובתהליך התשלום.
ניהול מלאי מוצרים: שירות עם שמירת מצב שמנהל את הזמינות של המוצרים ואת העדכונים שלהם.
מערכת המלצות: מיקרו-שירות מורכב שיוצר המלצות מותאמות אישית למוצרים לכל משתמש.
משימות עיבוד באצווה: כולל משימות תקופתיות כמו עדכון קטלוגים של מוצרים וניתוח התנהגות משתמשים.
עומסי העבודה האלה מייצגים שילוב של שירותים בלי שמירת מצב ושירותים עם שמירת מצב, ולכן החלטתם להשתמש גם ב-GKE וגם ב-Cloud Run כדי להשיג ביצועים אופטימליים. בהמשך מוסבר על דרך אחת ליישום גישה היברידית לעומסי העבודה.
אחרי שקוראים את הקריטריונים להתאמה של עומסי עבודה (workloads) ב-Cloud Run, מחליטים להשתמש ב-Cloud Run עבור האתר, האפליקציה לנייד ועבודות העיבוד באצווה. לפריסת השירותים האלה ב-Cloud Run יש את היתרונות הבאים:
התאמה אוטומטית לעומס כשמטפלים בעליות חדות בתנועה ובמשימות אצווה גדולות, ללא התערבות ידנית.
עלות-תועלת עם מודל של תשלום לפי שימוש. משלמים רק כשהמשתמשים גולשים או מבצעים צ'ק-אאוט, וכשהמשאבים נמצאים בשימוש במהלך הרצת משימות באצווה.
פריסות מהירות יותר כי העדכונים זמינים באופן מיידי, מה שמשפר את חוויית המשתמש.
שילוב קל עם שירותים אחרים של Google Cloud . לדוגמה, לעיבוד מבוסס-אירועים, אפשר להשתמש בפונקציות Cloud Run כדי להפעיל משימות עיבוד באצווה ב-Cloud Run, וכך לאפשר תהליכי עבודה חלקים.
ניהול מלאי מוצרים הוא שירות מבוסס-מצב שדורש בקרה פרטנית ופתרונות אחסון מותאמים אישית. אתם מחליטים להשתמש ב-GKE כדי לפרוס את השירות הזה, כי הוא מציע אחסון מתמיד ומאפשר לכם לצרף נפחים כדי לשמור על נתוני המוצרים ועל מהימנותם.
מנוע ההמלצות הוא מיקרו-שירות מורכב שמפיק תועלת מ-GKE. באמצעות GKE, אפשר לנהל תלות מורכבת ולשלוט בצורה פרטנית בהקצאה ובשינוי הגודל של המשאבים.
GKE מתאים במיוחד לארכיטקטורות מורכבות של מיקרו-שירותים, לאפליקציות עם מצב, לעומסי עבודה שדורשים תצורות מותאמות אישית של תשתית או רשת, ולתרחישים שבהם נדרשת שליטה מלאה ב-Kubernetes. Cloud Run מתאים במיוחד לאפליקציות מבוססות-אירועים. הוא מתאים במיוחד לשירותי אינטרנט בלי שמירת מצב, לממשקי API, למשימות באצווה ולעומסי עבודה אחרים שמתאימים למודל תמחור של תשלום לפי שימוש.
בדוגמה הקודמת אפשר לראות איך שילוב של GKE ו-Cloud Run יכול לספק פתרון יעיל וגמיש לפלטפורמת המסחר האלקטרוני שלכם. אתם נהנים מהיתרונות של שתי הפלטפורמות: יעילות של סביבה ללא שרת (serverless) לעומסי עבודה (workloads) ללא שמירת מצב, ושליטה ב-Kubernetes למיקרו-שירותים מורכבים ולרכיבים עם שמירת מצב.
כדי לקבל תצוגה מאוחדת של הרכיבים השונים שנפרסו בגישה היברידית ולראות איך הם פועלים יחד כאפליקציה מגובשת, אפשר להשתמש ב-App Hub. מידע נוסף זמין במאמר משאבים נתמכים ב-App Hub.
לתשומת ליבכם
GKE ו-Cloud Run משלימים זה את זה ומספקים מענה לצרכים שונים בסביבה מורכבת של אפליקציות.
ריכזנו כאן כמה נקודות שכדאי לקחת בחשבון כשמאמצים גישה היברידית לפריסת עומסי עבודה:
הפעלת מיקרו-שירותים (microservices) ללא שמירת מצב ב-Cloud Run כדי לחסוך בעלויות ולשפר את יכולת ההתאמה לגדילה.
פריסת אפליקציות מורכבות עם שמירת מצב שדורשות התאמה אישית מעמיקה ב-GKE.
אם אתם משתמשים ברשת פרטית ב- Google Cloud, כדי לגשת למשאבים באשכול GKE משירות Cloud Run, אתם יכולים לשלוח בקשה לרשת Virtual Private Cloud (VPC) באמצעות יציאה ישירה מ-VPC. כדי לגשת לשירותי Kubernetes באשכול GKE, שירות Cloud Run צריך להיות מחובר לרשת ה-VPC של האשכול, ושירות Kubernetes צריך להשתמש במאזן עומסי רשת פנימי מסוג passthrough.
כדי להעביר תנועה בין Cloud Run ל-GKE, אפשר לחשוף נקודות קצה חיצוניות מאחורי מאזן עומסים גלובלי חיצוני של אפליקציות. כשמטמיעים את איזון העומסים הזה מול שירותים בשני זמני הריצה, אפשר לפרוס את אותה אפליקציה גם ב-Cloud Run וגם ב-GKE, וכך להעביר בהדרגה את תעבורת הנתונים מפלטפורמה אחת לשנייה.
כדי לחשוף שירותים של Cloud Run בענן וירטואלי פרטי (VPC) מאחורי כתובות IP פרטיות, צריך להשתמש במאזן עומסים פנימי.
חשוב לזכור: אם עומסי העבודה שלכם כבר נמצאים ב-Cloud Run, תמיד תוכלו להעביר אותם ל-GKE לפי הצורך.
מתי לא כדאי להשתמש ב-GKE וב-Cloud Run ביחד
GKE ו-Cloud Run מציעים גישה משכנעת להרבה עומסי עבודה בקונטיינרים, אבל יש מצבים שבהם שימוש משולב בהם לא מתאים. ריכזנו כאן כמה דוגמאות למקרים שבהם כדאי לוותר על גישה היברידית:
מיקרו-שירותים עם צימוד הדוק: אם המיקרו-שירותים שלכם תלויים מאוד זה בזה ודורשים תקשורת תכופה עם זמן אחזור נמוך, ניהול שלהם בפלטפורמות נפרדות עלול להיות מורכב. קריאות תכופות לרשת בין פלטפורמות עלולות להוסיף תקורה וצווארי בקבוק פוטנציאליים, ולהשפיע על הביצועים.
אפליקציות מדור קודם עם תלות בהתאמה אישית: אם האפליקציה מסתמכת על ספריות, מסגרות או הגדרות ספציפיות שלא נתמכות ב-Cloud Run, יכול להיות ששימוש בשירות הזה לחלקים מהאפליקציה ידרוש שינוי משמעותי בקוד או פתרונות עקיפים. זה עלול לבטל את היתרונות של בלי שרת (serverless) וליצור תקורה של תחזוקה ספציפית לפלטפורמה.
מגבלות תקציב עם עומסי עבודה צפויים: אם עומס העבודה שלכם דורש כמות משאבים קבועה ואתם מוגבלים בתקציב, יכול להיות שהמודל של GKE לתשלום לפי צומת יהיה חסכוני יותר מהחיוב לפי שימוש ב-Cloud Run. אם יש לכם עומסי עבודה צפויים, יכול להיות שלא תנצלו את היתרונות של התאמה אוטומטית לעומס ב-Cloud Run, ולכן העלות הקבועה של GKE תהיה אטרקטיבית יותר.
הגישה הטובה ביותר תלויה בסופו של דבר בצרכים ובסדרי העדיפויות הספציפיים שלכם. לפני שמחליטים על ארכיטקטורה היברידית של GKE ו-Cloud Run, חשוב להעריך בקפידה את הדרישות של האפליקציה, את מגבלות המשאבים ואת המומחיות של הצוות.
המאמרים הבאים
במאמר מעבר מ-Cloud Run ל-GKE מוסבר איך להמיר את שירות Cloud Run לפריסת Kubernetes.
אורזים את פריסת Kubernetes בקונטיינר שתואם ל-Cloud Run לפי ההוראות במאמר העברה מ-Kubernetes ל-Cloud Run.