ב-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 יש רמה גבוהה יחסית של ניידות:
בשתי הפלטפורמות משתמשים בקובצי אימג' סטנדרטיים של קונטיינרים כפריטי מידע שנוצרו בתהליך הפיתוח (artifacts) לפריסה. אתם יכולים להשתמש באותו קובץ אימג' לאפליקציה שלכם בכל אחת מהפלטפורמות בלי לבצע שינויים, וכך להעביר עומסי עבודה בצורה חלקה בין GKE לבין Cloud Run. אם קובצי האימג' של קונטיינרים מאוחסנים ב-Artifact Registry, לא צריך לעדכן את הגדרות האינטגרציה הרציפה כדי לבצע מיגרציה בין 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. אתם יכולים ליצור התאמות אישיות מתקדמות של הגדרות הצמתים, מדיניות רשת ב-Kubernetes, הגדרות האבטחה ותוספים. |
שליטה מוגבלת בתשתית הבסיסית. אתם יכולים להגדיר דברים כמו משתני סביבה, בו-זמניות וחיבורי רשת, אבל אתם לא יכולים להתאים אישית את התשתית או הסביבה הבסיסיות. מתאים במיוחד לפשטות ולמהירות. |
| סוגי אפליקציות | הוא תומך באפליקציות ללא מצב (stateless) ובאפליקציות עם מצב (stateful), והוא אידיאלי לאפליקציות מורכבות עם צרכים ספציפיים במשאבים. | האפשרות הזו מתאימה לשירותים בלי שמירת מצב, לשירותים שמבוססים על בקשות או על אירועים, לשירותי אינטרנט ולפונקציות. |
| מודל התמחור | תשלום לפי אשכול לשעה, בלי קשר למצב הפעולה (Standard או Autopilot), לגודל האשכול או לטופולוגיה. | תשלום לפי שימוש, מעוגל כלפי מעלה ל-100 אלפיות השנייה הקרובות. |
תרחיש שימוש
נניח שאתם אדמינים של פלטפורמה בחברה קמעונאית שבונה פלטפורמת מסחר אלקטרוני גדולה. יש לכם את עומסי העבודה הבאים שפועלים בקונטיינרים לפריסה:
אתר ואפליקציה לנייד בקצה הקדמי: אפליקציית אינטרנט חסרת מצב שמטפלת בגלישה במוצרים, בחיפוש ובתהליך התשלום.
ניהול מלאי מוצרים: שירות עם שמירת מצב שמנהל את הזמינות של המוצרים ואת העדכונים שלהם.
מנוע המלצות: מיקרו-שירות מורכב שמייצר המלצות מותאמות אישית למוצרים לכל משתמש.
משימות עיבוד באצווה: כולל משימות תקופתיות כמו עדכון קטלוגים של מוצרים וניתוח התנהגות המשתמשים.
עומסי העבודה האלה מייצגים שילוב של שירותים בלי שמירת מצב ושירותים עם שמירת מצב, ולכן החלטתם להשתמש גם ב-GKE וגם ב-Cloud Run כדי להשיג ביצועים אופטימליים. הנה דרך אחת שבה אפשר ליישם גישה היברידית לעומסי העבודה.
אחרי שקראתם את הקריטריונים להתאמה של עומסי עבודה ב-Cloud Run, החלטתם להשתמש ב-Cloud Run עבור האתר, האפליקציה לנייד ומשימות העיבוד באצווה. לפריסת השירותים האלה ב-Cloud Run יש את היתרונות הבאים:
התאמה אוטומטית לעומס (automatic scaling) כשנפח התנועה עולה, וטיפול במשימות אצווה גדולות בלי התערבות ידנית.
יעילות בעלויות עם מודל של תשלום לפי שימוש. התשלום מתבצע רק כשמשתמשים גולשים או משלמים, וכשמשאבים נמצאים בשימוש במהלך הפעלה של משימות באצ' (batch).
פריסות מהירות יותר כי העדכונים זמינים באופן מיידי, מה שמשפר את חוויית המשתמש.
שילוב קל עם שירותים אחרים של Google Cloud . לדוגמה, לעיבוד מבוסס-אירועים, אתם יכולים להשתמש בפונקציות Cloud Run כדי להפעיל משימות עיבוד באצווה ב-Cloud Run, וכך לאפשר תהליכי עבודה חלקים.
ניהול מלאי מוצרים הוא שירות עם מצב (stateful) שדורש שליטה פרטנית ופתרונות אחסון מותאמים אישית. אתם מחליטים להשתמש ב-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, אתם יכולים לשלוח בקשה לרשת ענן וירטואלי פרטי (VPC) באמצעות Direct VPC egress. כדי לגשת לשירותי Kubernetes באשכול GKE, שירות Cloud Run צריך להיות מחובר לרשת ה-VPC של האשכול, ושירות Kubernetes צריך להשתמש במאזן עומסי רשת פנימי מסוג passthrough.
כדי להעביר תנועה בין Cloud Run ל-GKE, אפשר לחשוף נקודות קצה חיצוניות מאחורי Global external Application Load Balancer. כשמטמיעים את איזון העומסים הזה מול שירותים בשני זמני הריצה, אפשר לפרוס את אותה אפליקציה גם ב-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.