Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

סקירה כללית על קבוצות של נקודות קצה ברשת בלי שרת (serverless)

קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה בקצה העורפי של מאזן עומסים. קבוצת נקודות קצה של רשת (NEG) ללא שרת היא קצה עורפי שמפנה אל משאב של Cloud Run,‏ App Engine,‏ Cloud Run Functions או API Gateway.

קבוצת נקודות קצה בלי שרת (serverless) יכולה לייצג את אחד מהדברים הבאים:

משאב של Cloud Run או קבוצת משאבים.
פונקציית Cloud Run או קבוצת פונקציות (לשעבר פונקציות Cloud Run דור שני).
פונקציית Cloud Run (דור ראשון) או קבוצת פונקציות
אפליקציה בסביבה רגילה של App Engine או בסביבה גמישה של App Engine, שירות ספציפי באפליקציה, גרסה ספציפית של אפליקציה או קבוצת שירותים.
API Gateway שמאפשר גישה לשירותים באמצעות API בארכיטקטורת REST עקבי בכל השירותים, ללא קשר לאופן השימוש בשירות. היכולת הזו נמצאת בגרסת טרום-השקה.

מאזני עומסים נתמכים

בטבלה הבאה מפורטים המוצרים ללא שרתים שנתמכים על ידי כל מאזן עומסים של אפליקציות. אין תמיכה ב-NEGs ללא שרתים במאזני עומסי רשת לשרתי proxy ובמאזני עומסי רשת להעברת סיגנל ללא שינוי.

סוג ה-NEG ללא שרת	מאזני עומסים של אפליקציות (ALB)
סוג ה-NEG ללא שרת	אזורי פנימי	פנימי בין-אזורי	גלובלי חיצוני	קלאסי	אזורי חיצוני
Cloud Run תמיכה ב-Cloud Run ובפונקציות Cloud Run (דור שני)
App Engine
Cloud Functions תמיכה בפונקציות Cloud Run (דור ראשון), שנקראו בעבר Cloud Functions דור ראשון

תרחישים לדוגמה

כשמאזן העומסים מופעל לאפליקציות בלי שרתים, אפשר:

מגדירים את האפליקציה ללא שרת כך שתפעל מכתובת IP ייעודית מסוג IPv4 שלא משותפת עם שירותים אחרים.
מיפוי של כתובת URL יחידה לכמה פונקציות או שירותים ללא שרתים שפועלים באותו דומיין. להסבר, ראו הסתרת כתובות URL.
שיתוף מרחב כתובות URL עם פלטפורמות מחשוב אחרות Google Cloud . באמצעות כמה שירותים לקצה העורפי, מאזן עומסים יחיד יכול לשלוח תנועה לכמה סוגים של קצה עורפי. מאזן העומסים בוחר את שירות הקצה העורפי הנכון על סמך המארח או הנתיב של כתובת ה-URL של הבקשה.
אפשר לעשות שימוש חוזר באישורי SSL ובמפתחות פרטיים שבהם אתם משתמשים ב-Compute Engine, ב-Google Kubernetes Engine וב-Cloud Storage. שימוש חוזר באותם אישורים מבטל את הצורך בניהול אישורים נפרדים לאפליקציות ללא שרת.

מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ומאזן עומסים קלאסי של אפליקציות (ALB)

הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות (ALB) מאפשרת לאפליקציות שלכם בלי שרתים להשתלב עם שירותי ענן קיימים. אתם יכולים:

הגנה על השירות באמצעות Google Cloud Armor, מוצר אבטחה של חומת אש ליישומי אינטרנט (WAF) והגנה מפני DDoS בקצה הרשת, שזמין לכל השירותים שאליהם ניגשים דרך מאזן עומסים חיצוני של אפליקציות. יש מגבלות שקשורות ליכולת הזו, במיוחד ב-Cloud Run וב-App Engine.
כדי לייעל את ההעברה של השירות שלכם, אתם יכולים להשתמש ב-Cloud CDN. שירות Cloud CDN שומר תוכן במטמון קרוב למשתמשים. ‫Cloud CDN מספק יכולות כמו ביטול תוקף של מטמון וכתובות URL חתומות של Cloud CDN.
שימוש בתשתית Edge של Google כדי לסיים את חיבורי ה-HTTP(S) של המשתמש קרוב יותר למשתמש, וכך להקטין את זמן האחזור.

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

שילוב של מאזן עומסים חיצוני של אפליקציות (ALB) עם API Gateway מאפשר לקצה העורפי שלכם ללא שרת (serverless) ליהנות מכל התכונות שמסופקות על ידי Cloud Load Balancing. מידע נוסף זמין במאמר בנושא מאזן עומסים חיצוני של אפליקציות ל-API Gateway. כדי להגדיר מאזן עומסים חיצוני של אפליקציות (ALB) לניתוב תעבורה אל API Gateway, אפשר לעיין במאמר תחילת העבודה עם מאזן עומסים חיצוני של אפליקציות (ALB) עבור API Gateway. היכולת הזו נמצאת בגרסת טרום-השקה.

מאזן עומסים חיצוני אזורי של אפליקציות (ALB)

שימוש במאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאפשר להריץ עומסי עבודה עם דרישות רגולטוריות או דרישות תאימות בבק-אנד של Cloud Run או של פונקציות Cloud Run (דור שני). לדוגמה, אם אתם רוצים שהגדרות הרישות וסיומי תעבורת הנתונים של האפליקציה שלכם יהיו באזור ספציפי, מאזן עומסים חיצוני של אפליקציות (ALB) באזור מסוים הוא לרוב האפשרות המועדפת כדי לעמוד בדרישות של אמצעי הבקרה המשפטיים הנדרשים.

במאמר הגדרה של מאזן עומסים חיצוני אזורי של אפליקציות באמצעות Cloud Run מוסבר איך להגדיר מאזן עומסים חיצוני אזורי של אפליקציות עם קצה עורפי של שרתים וירטואליים.

מאזן עומסים פנימי אזורי של אפליקציות (ALB) ומאזן עומסים פנימי חוצה-אזורים של אפליקציות (ALB)

כשמאזן עומסים של אפליקציות (ALB) פנימי מוגדר עם עורפי קצה של Cloud Run או של פונקציות Cloud Run (דור שני), אפשר לבצע את הפעולות הבאות:

הפעלת תכונות מתקדמות לניהול תנועה כמו הזרקת תקלות, שכתוב של כותרות, הפניות אוטומטיות, חלוקת תנועה ועוד, בשירותי Cloud Run ופונקציות Cloud Run (דור שני).
העברה חלקה של שירותים מדור קודם מ-Compute Engine,‏ GKE או משרתים מקומיים אל Cloud Run ואל פונקציות Cloud Run (דור שני), כדי לנצל את היתרונות של פיצול תעבורה לפי משקל, ולהעביר את התעבורה בהדרגה אל Cloud Run ללא השבתה.
הגנה על שירותי Cloud Run ופונקציות Cloud Run (דור שני) באמצעות VPC Service Controls.
הגדרת נקודת כניסה פנימית יחידה לאכיפת מדיניות בשירותים שפועלים ב-Cloud Run, בפונקציות Cloud Run (דור שני), ב-Compute Engine וב-GKE.

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

בהמשך הדף מוסבר איך להשתמש ב-NEGs בלי שרת (serverless) עם מאזני עומסים של אפליקציות (ALB). מידע נוסף על סוגים אחרים של NEGs זמין במאמר סקירה כללית על קבוצות של נקודות קצה ברשת.

סוגי נקודות קצה

ל-NEGs ללא שרתים אין נקודות קצה ברשת, כמו יציאות או כתובות IP. הם יכולים להפנות רק למשאב קיים של Cloud Run,‏ App Engine,‏ API Gateway או Cloud Run Functions שנמצא באותו אזור כמו ה-NEG.

כשיוצרים NEG ללא שרת, מציינים את שם הדומיין שמוגדר במלואו (FQDN) של משאב Cloud Run,‏ App Engine,‏ API Gateway או Cloud Run Functions. נקודת הקצה היא מסוג SERVERLESS. אין תמיכה בסוגים אחרים של נקודות קצה ב-NEG ללא שרת.

ל-NEG ללא שרתים יכולה להיות רק נקודת קצה אחת. נקודת הקצה מפנה לאפליקציה ללא שרת או להסוואה של כתובת URL. מאזן העומסים משמש כקצה קדמי של אפליקציית המחשוב בלי שרת, ומעביר את תעבורת הנתונים לנקודת הקצה שצוינה. עם זאת, אם שירות ה-Backend מכיל כמה NEGs ללא שרתים באזורים שונים, מאזן העומסים שולח תנועה ל-NEG באזור הקרוב ביותר כדי למזער את זמן האחזור של הבקשה.

רמת הרשת

במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), אפשר להשתמש ב-NEG ללא שרת במאזן עומסים במסלול הרגיל או במסלול הפרימיום של שירותי הרשת. המסלול Premium נדרש רק אם רוצים להגדיר קבוצות של נקודות קצה ברשת (NEG) ללא שרתים בכמה אזורים.

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) הם תמיד במסלול הרגיל.

מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים ומאזני עומסים פנימיים של אפליקציות (ALB) אזוריים הם תמיד ברמת פרימיום.

רכיבים של איזון עומסים

מאזן עומסים שמשתמש בקצה עורפי של NEG מסוג serverless דורש הגדרה מיוחדת רק לשירות הקצה העורפי. ההגדרה של הקצה הקדמי זהה לכל מאזן עומסים אחר שמבוסס על שרת proxy. Google Cloud בנוסף, מאזני עומסים פנימיים של אפליקציות (ALB) דורשים תת-רשת של שרת proxy בלבד כדי להפעיל שרתי proxy של Envoy בשמכם.

הדיאגרמות הבאות מציגות פריסה לדוגמה של NEG בלי שרת (serverless).

חיצונית גלובלית

בתרשים הזה מוצג איך NEG בלי שרת משתלב בארכיטקטורה של מאזן עומסים גלובלי-חיצוני של אפליקציות (ALB).

מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) לאפליקציות ללא שרתים. — מאזן עומסים של אפליקציות (ALB) גלובלי חיצוני לאפליקציות בלי שרת (serverless) (לחצו כדי להגדיל).

חיצוני אזורי

בתרשים הזה מוצג איך NEG בלי שרת משתלב בארכיטקטורה של מאזן עומסים אזורי חיצוני של אפליקציות (ALB).

פנימי אזורי

דיאגרמה זו מציגה כיצד NEG בלי שרת (serverless) משתלב במודל של מאזן עומסים אזורי פנימי של אפליקציות (ALB).

בין אזורים

בתרשים הזה מוצג איך NEG בלי שרת משתלב במודל של מאזן עומסים פנימי של אפליקציות בין אזורים.

מאזן עומסים פנימי חוצה אזורים עם פריסת Cloud Run. — מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים עם פריסה של Cloud Run (לחצו כדי להגדיל).

רכיבים של הקצה הקדמי

לא נדרשת הגדרה מיוחדת של קצה קדמי כדי לאזן עומסים עם קצוות עורפיים של NEG בלי שרת. כללי העברה משמשים לניתוב תעבורה לפי כתובת IP, יציאה ופרוטוקול לשרת proxy של יעד. לאחר מכן, שרת ה-proxy של היעד מנתק את החיבורים מהלקוחות.

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

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

שירות לקצה העורפי

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

ההגבלות הבאות חלות בהתאם לסוג איזון העומסים:

לשירות קצה עורפי גלובלי שמשמש מאזני עומסים גלובליים חיצוניים של אפליקציות יכולים להיות מצורפים כמה NEGs בלי שרתים, אבל רק NEG אחד בלי שרתים לכל אזור.
לשירות לקצה העורפי אזורי שמשמש מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) ומאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) יכול להיות מצורף רק NEG אחד בלי שרת (serverless).
שירות לקצה העורפי גלובלי שמשמש מאזני עומסים פנימיים של אפליקציות בכמה אזורים יכול לכלול רק משאבים של Cloud Run ופונקציות Cloud Run (דור שני).

כל NEG ללא שרת יכול להצביע על אחד מהבאים:

ה-FQDN של משאב יחיד
מסכת כתובות URL שמפנה למספר משאבים שמוצגים באותו דומיין

מסכת URL היא תבנית של סכימת URL שמציינת לשרת העורפי של ה-NEG ללא שרתים איך למפות את בקשת המשתמש לשירות הנכון. מסכות של כתובות URL שימושיות אם אתם משתמשים בדומיין מותאם אישית לאפליקציה בלי שרת (serverless), ויש לכם כמה שירותים שפועלים באותו דומיין. במקום ליצור NEG נפרד ללא שרת לכל משאב, אפשר ליצור את ה-NEG עם מסכת כתובות URL גנרית לדומיין המותאם אישית. מידע נוסף ודוגמאות זמינים במאמר בנושא מסכות של כתובות URL.

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

זיהוי חריגים ב-NEGs ללא שרת

זיהוי חריגים הוא הגדרה אופציונלית שאפשר להפעיל בשירות קצה עורפי גלובלי שמצורפים אליו קבוצות NEGs ללא שרת. ניתוח של זיהוי חריגות זמין רק למאזן עומסים פנימי של אפליקציות (ALB) חוצה אזורים ולמאזן עומסים חיצוני של אפליקציות (ALB) גלובלי, ולא למאזן עומסים קלאסי של אפליקציות (ALB). ניתוח לזיהוי חריגים מזהה קבוצות NEG לא תקינות של שרתים וירטואליים על סמך דפוסי התגובה שלהן ל-HTTP, ומקטין את שיעור השגיאות על ידי ניתוב רוב הבקשות החדשות ממשאבים לא תקינים למשאבים תקינים. כדי להבין איך פועל אלגוריתם זיהוי החריגים ומה המגבלות שלו, אפשר לעיין בדוגמה הבאה.

נניח שיש שירות לקצה העורפי עם שתי קבוצות NEGs בלי שרת (serverless) שמצורפות אליו – אחת באזור REGION_A ואחת באזור REGION_B. אם ה-NEG ללא שרתים שמשמש כבק-אנד למאזן עומסים גלובלי חיצוני של אפליקציות באזור REGION_A לא מגיב, מנגנון זיהוי החריגים מזהה את ה-NEG ללא שרתים כלא תקין. על סמך ניתוח של זיהוי חריגות, חלק מהבקשות החדשות נשלחות ל-NEG ללא שרתים באזור REGION_B.

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

שגיאות 5xx רצופות. קוד סטטוס של HTTP מסדרה 5xx נחשב לשגיאה.
שגיאות שער רצופות. רק קודי סטטוס HTTP‏ 502, 503 ו-504 נחשבים לשגיאה.

שימו לב: גם אחרי שמפעילים את זיהוי החריגים, סביר להניח שחלק מהבקשות יישלחו למשאב הלא תקין, ולכן יוחזרו ללקוחות שגיאות 5XX. הסיבה לכך היא שהתוצאות של האלגוריתם לזיהוי חריגות (הוצאת נקודות קצה ממאגר איזון העומסים והחזרתן למאגר) מבוצעות באופן עצמאי על ידי כל מופע של שרת proxy של מאזן העומסים. ברוב המקרים, יותר ממופע proxy אחד מטפל בתנועה שמתקבלת משירות backend. לכן, יכול להיות שרק חלק משרתי ה-proxy יזהו נקודת קצה לא תקינה ויסלקו אותה, ובזמן הזה שרתי proxy אחרים ימשיכו לשלוח בקשות לאותה נקודת קצה לא תקינה.

כדי להפחית עוד יותר את שיעורי השגיאות, אפשר להגדיר פרמטרים אגרסיביים יותר לזיהוי חריגים. מומלץ להגדיר ערכים גבוהים יותר לספי התנתקות (outlierDetection.baseEjectionTime). לדוגמה, מהבדיקות שלנו עולה שהגדרת outlierDetection.baseEjectionTime ל-180 שניות עם QPS קבוע של יותר מ-100 מובילה לשיעורי שגיאה שנצפים בפחות מ-5%. מידע נוסף על API לזיהוי חריגים מופיע במאמר outlierDetection במסמכי התיעוד של global backend service API.

השדות הבאים של outlierDetection לא נתמכים כש-NEG ללא שרת מצורף לשירות העורפי:

outlierDetection.enforcingSuccessRate
outlierDetection.successRateMinimumHosts
outlierDetection.successRateRequestVolume
outlierDetection.successRateStdevFactor

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

מסיכות של כתובות URL

קצה עורפי של NEG בלי שרת (serverless) יכול להצביע על משאב יחיד של Cloud Run (או App Engine או פונקציות Cloud Run, אם רלוונטי), או על מסכת כתובות URL שמצביעה על כמה משאבים. מסכת כתובת URL היא תבנית של סכמת כתובת ה-URL. ה-NEG ללא שרתים משתמש בתבנית הזו כדי למפות את הבקשה למשאב המתאים.

מסכות של כתובות URL הן תכונה אופציונלית שמקלה על הגדרת קבוצות של נקודות קצה ברשת (NEG) ללא שרתים, כשהאפליקציה ללא שרתים מורכבת מכמה משאבים של Cloud Run, פונקציות Cloud Run או App Engine. ב-NEGs בלי שרת (serverless) שמשמשים עם מאזני עומסים פנימיים של אפליקציות, אפשר להשתמש רק במסכת כתובת URL שמפנה לשירותים של Cloud Run או לפונקציות Cloud Run (דור שני).

מסכות של כתובות URL שימושיות אם האפליקציה בלי שרת (serverless) ממופה לדומיין מותאם אישית ולא לכתובת ברירת המחדל ש- Google Cloud מספקת. בדומיין מותאם אישית כמו example.com, יכולים להיות כמה משאבים שפרוסים בתתי-דומיינים או בנתיבים שונים באותו דומיין. במקרים כאלה, במקום ליצור בק-אנד (backend) של NEG בלי שרת (serverless) לכל משאב, אפשר ליצור NEG בלי שרת (serverless) עם מסכת URL גנרית לדומיין המותאם אישית (לדוגמה, example.com/<service>). ה-NEG מחלץ את שם השירות מכתובת ה-URL של הבקשה.

באיור הבא מוצג מאזן עומסים של אפליקציות חיצוני עם שירות לקצה העורפי יחיד ו-NEG בלי שרת שמשתמש במסכת כתובת URL כדי למפות בקשות של משתמשים לשירותים שונים.

חלוקת תנועת הנתונים לאפליקציות ללא שרת (serverless). — שימוש במסכת כתובת URL כדי להפיץ תנועה לשירותים שונים (לחצו כדי להגדיל).

מסכות של כתובות URL פועלות בצורה הכי טובה כשמשאבי האפליקציה משתמשים בסכימת כתובות URL צפויה. היתרון בשימוש במסכת כתובת URL במקום במיפוי כתובות URL הוא שלא צריך ליצור קבוצות נפרדות של נקודות קצה ברשת (NEGs) ללא שרתים עבור השירותים login ו-search. בנוסף, לא צריך לשנות את ההגדרות של מאזן העומסים בכל פעם שמוסיפים משאב חדש לאפליקציה.

מגבלות

ל-NEG ללא שרתים לא יכולות להיות נקודות קצה ברשת, כמו כתובת IP או יציאה.
קבוצות NEGs ללא שרת יכולות להצביע רק על משאבים ללא שרת שנמצאים באותו אזור שבו נוצרה קבוצת ה-NEG.
אם מאזן העומסים משתמש בעורף רשת Serverless NEG, צריך ליצור את רשת Serverless NEG באותו פרויקט שבו נמצאים משאבי Cloud Run,‏ App Engine,‏ API Gateway או Cloud Run functions שאליהם מצביעה רשת ה-NEG. יכול להיות שתראו בקשות שנכשלות אם תחברו שירות שלא נמצא באותו פרויקט כמו ה-NEG ללא שרת.
אלא אם הגדרתם תקינות של שירות Cloud Run או הפעלתם זיהוי חריגות, מאזן עומסים שהוגדר עם NEG ללא שרת לא יכול לזהות אם המשאב הבסיסי פועל כמצופה. המשמעות היא שגם אם המשאב מחזיר שגיאות, מאזן העומסים ממשיך להפנות אליו תנועה. חשוב לבדוק היטב גרסאות חדשות של המשאבים לפני שמנתבים אליהן את תנועת המשתמשים.

כדי להפוך את ההעברה האוטומטית של תעבורת נתונים מ-NEGs ללא שרתים (serverless) לשרתים תקינים לאוטומטית, אפשר להשתמש בשיטות הבאות במאזני עומסים גלובליים ובמאזני עומסים חוצי-אזורים:
- זיהוי חריגים: נתמך במאזני עומסים גלובליים חיצוניים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות בין אזורים, כדי לזהות קבוצות NEG ללא שרתים תקינים על סמך דפוסי תגובות HTTP.
- תקינות השירות ב-Cloud Run: נתמך במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים שהוגדרו עם עורפי NEG ללא שרתים.
Google Cloud console. אפשר ליצור קבוצות NEGs בלי שרתים רק כשיוצרים או עורכים מאזן עומסים באמצעות הדף Load balancing במסוףGoogle Cloud . בדף Network endpoint groups אי אפשר ליצור או לערוך NEGs ללא שרתים, אבל אפשר לראות בו רשימה של כל ה-NEGs ללא שרתים בפרויקט.

מגבלות בשירותים לקצה עורפי

המגבלות הבאות חלות על שירותי קצה עורפיים שיש להם קצה עורפי של NEG ללא שרתים:

לשירות לקצה העורפי גלובלי שמשמש מאזני עומסים גלובליים חיצוניים של אפליקציות יכול להיות רק NEG אחד בלי שרת לכל אזור. כדי לשלב כמה NEGs בלי שרתים (serverless) בשירות לקצה העורפי יחיד, כל ה-NEGs צריכים לייצג פריסות שוות ערך מבחינה פונקציונלית באזורים שונים. לדוגמה, קבוצות ה-NEG יכולות להצביע על אותו משאב של Cloud Run,‏ App Engine או Cloud Run Functions שנפרס באזורים שונים.
לשירות קצה עורפי גלובלי שמשמש מאזני עומסים פנימיים של אפליקציות בין אזורים יכול להיות מצורף רק משאב אחד של Cloud Run או של פונקציות Cloud Run (דור שני).
אפשר לצרף לשירות בק-אנד אזורי רק קבוצת נקודות קצה ללא שרת אחד.
הפניה לשירותים בין פרויקטים בפריסת VPC משותף נתמכת עם הגדרות שמכילות NEG בלי שרת (serverless). כדי להשתמש בתכונה הזו, אתם יוצרים את רכיבי הקצה הקדמי של מאזן העומסים (כתובת IP, כלל העברה, שרת proxy ביעד ומפת URL) בפרויקט שונה מרכיבי הבק-אנד של מאזן העומסים (שירות לקצה העורפי ו-NEG בלי שרת). שימו לב ששירות לקצה העורפי, קבוצות ה-NEG המשויכות ל-serverless והמשאב התומך ב-serverless (פונקציות של Cloud Run,‏ App Engine,‏ API Gateway או Cloud Run) חייבים תמיד להיווצר באותו פרויקט.
ההגדרה של זמן קצוב לתפוגה של שירות קצה עורפי לא חלה על שירותי קצה עורפי עם קצוות עורפיים של NEG בלי שרתים. ניסיון לשנות את המאפיין resource.timeoutSec של שירות הקצה העורפי מוביל לשגיאה הבאה: Timeout sec is not supported for a backend service with Serverless network endpoint groups.‫
בשירותי קצה עורפי עם קצה עורפי של NEG בלי שרת (serverless), ברירת המחדל של הזמן הקצוב לתפוגה היא 60 דקות. אי אפשר להגדיר את הזמן הקצוב לתפוגה. אם האפליקציה שלכם צריכה חיבורים ארוכים, צריך להגדיר את הלקוחות כך שינסו לשלוח מחדש בקשות במקרה של כשל.
כל ה-NEGs בלי שרת (serverless) שמשולבים בשירות לקצה העורפי צריכים להשתמש באותו סוג של בק-אנד. המשמעות היא שאפשר לשלב NEGs בלי שרת ב-Cloud Run רק עם NEGs אחרים בלי שרת ב-Cloud Run, ואפשר לשלב NEGs בלי שרת ב-App Engine רק עם NEGs אחרים בלי שרת ב-App Engine.
אי אפשר לשלב NEGs ללא שרת עם סוגים אחרים של NEGs באותו שירות backend. לדוגמה, אי אפשר לנתב לאשכול GKE ולשירות Cloud Run מאותו שירות לקצה העורפי.
כשמגדירים שירותים לקצה העורפי שמנתבים ל-NEGs ללא שרתים, יש שדות שמוגבלים:
- אי אפשר לציין מצב איזון. כלומר, לערכים RATE,‏ UTILIZATION ו-CONNECTION אין השפעה על חלוקת התנועה של מאזן העומסים.
- אין תמיכה בבדיקות תקינות של קצה עורפי ללא שרת. לכן, אי אפשר להגדיר בדיקות תקינות בשירותי קצה עורפיים שמכילים קצה עורפי של NEG ללא שרת. עם זאת, אפשר להפעיל זיהוי של חריגות כדי לזהות משאבים לא תקינים של שרתים וניתוב בקשות חדשות למשאב תקין של שרתים.
אי אפשר להשתמש בפקודה gcloud compute backend-services edit כדי לשנות שירות לקצה העורפי עם קצה עורפי של NEG בלי שרת (serverless). כפתרון עקיף, אפשר להשתמש בפקודה gcloud compute backend-services update.

חלות מגבלות נוספות בהתאם לסוג מאזן העומסים (LB) ול-backend בלי שרת (serverless).

מגבלות של מאזני עומסים פנימיים אזוריים של אפליקציות ומאזני עומסים חיצוניים אזוריים של אפליקציות

קבוצות אזוריות של נקודות קצה ברשת (NEG) בלי שרת (serverless) שמשמשות עם מאזני עומסים פנימיים אזוריים של אפליקציות או עם מאזני עומסים חיצוניים אזוריים של אפליקציות יכולות להפנות רק למשאבים של Cloud Run או של פונקציות Cloud Run (דור שני).
בפרויקטים שמשתמשים ב-NEGs בלי שרתים, המגבלה היא 5,000 שאילתות לשנייה (QPS) לכל פרויקט לתנועה שנשלחת לכל NEGs בלי שרתים שהוגדרו עם מאזני עומסים חיצוניים אזוריים של אפליקציות או מאזני עומסים פנימיים אזוריים של אפליקציות. המגבלה הזו היא סכום של כל מאזני העומסים החיצוניים האזוריים של אפליקציות ומאזני העומסים הפנימיים האזוריים של אפליקציות בפרויקט. זה לא מגבלה לכל מאזן עומסים.

מגבלות בשימוש במאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים

קבוצות NEGs ללא שרת שמשמשות עם מאזני עומסים פנימיים של אפליקציות בין אזורים יכולות להפנות רק למשאבי Cloud Run או Cloud Run Functions (דור שני).

מגבלות של מאזני עומסים גלובליים חיצוניים של אפליקציות

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

מגבלות ב-Cloud Run

מאזן עומסים חיצוני של אפליקציות (ALB) עם קבוצות NEGs בלי שרתים לא תומך ב-Knative serving.
מאזני עומסים חיצוניים של אפליקציות לא תומכים באימות בקשות של משתמשי קצה למשאבי Cloud Run. עם זאת, אפשר להשתמש ב-IAP כדי לאמת משתמשים בארגון. אם רוצים להפעיל את IAP, חשוב לזכור ש-IAP ו-Cloud CDN לא תואמים זה לזה. אי אפשר להפעיל אותם באותו שירות לקצה העורפי.
אי אפשר להעביר בבטחה שירותי בק-אנד עם בק-אנד של NEG בלי שרת (serverless) באמצעות שירות Cloud Run למאזן עומסים גלובלי חיצוני של אפליקציות (ALB) באמצעות תכונת ההעברה.

מגבלות ב-App Engine

אי אפשר להשתמש באיזון עומסים במספר אזורים עם App Engine. הסיבה לכך היא ש-App Engine דורש אזור אחד לכל פרויקט.
אם אתם משתמשים ב-IAP, אתם צריכים להשתמש באותו מזהה לקוח OAuth לכל שירותי App Engine שמשויכים למאזן עומסים יחיד.
בנתיב הבקשה מותר להשתמש רק במדיניות IAP אחת. לדוגמה, אם כבר הגדרתם מדיניות IAP בשירות העורפי, אל תגדירו מדיניות IAP נוספת באפליקציית App Engine.
מאזני עומסים גלובליים חיצוניים של אפליקציות עם קצה עורפי של סביבה גמישה של App Engine וקצה עורפי של סביבה סטנדרטית של App Engine לא תומכים בהפניה לשירותים בפרויקטים שונים.

מומלץ להשתמש באמצעי בקרה על תעבורת נכנסת כדי שהאפליקציה תקבל רק בקשות שנשלחות ממאזן העומסים (ומ-VPC אם משתמשים בו). אחרת, המשתמשים יכולים להשתמש בכתובת ה-URL של App Engine של האפליקציה כדי לעקוף את מאזן העומסים, את מדיניות האבטחה של Cloud Armor, את אישורי ה-SSL ואת המפתחות הפרטיים שמועברים דרך מאזן העומסים.

מגבלות ב-API Gateway

מידע נוסף זמין במאמר מגבלות על קבוצות של נקודות קצה ברשת ללא שרתים ועל API Gateway.

מגבלות בתכונות לניהול תנועה

תכונות מתקדמות לניהול תנועה כמו מדיניות מקומית של איזון עומסים וזיקה לסשן (session affinity) לא נתמכות עם קצה עורפי של NEG בלי שרת (serverless).
הגדרה של זיקה לסשן (session affinity) בשירות קצה עורפי עם קצה עורפי של NEG בלי שרת (serverless) לא תפעל. כפתרון עקיף ל-Cloud Run, אפשר להשתמש בתכונה הספציפית שלו session affinity.

תמחור

למידע על תמחור, אפשר לעיין במאמר בנושא תמחור רשת: איזון עומסים ב-Cloud.