סקירה כללית על נקודות קצה יוצאות

במאמר הזה מוסבר על נקודות קצה יוצאות ב-Cloud DNS. אפשר לצרף נקודות קצה יוצאות לאזורי העברה או למדיניות שרתים כדי לאפשר העברה ישירה של שאילתות DNS מרשתות VPC למפענחי DNS חיצוניים ומקומיים באמצעות כתובות IP פרטיות. שימוש בנקודות קצה יוצאות מאפשר שליטה מדויקת בתעבורת הנתונים היוצאת של DNS, ומשפר את היכולת לבטל את החסימה של תרחישי שימוש של פענוח DNS בסביבה היברידית ובסביבה מרובת-עננים.

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

היכולות של נקודות קצה יוצאות

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

אשכולות GKE יורשים באופן אוטומטי נקודות קצה יוצאות כששולחים שאילתות ליעדים חיצוניים באמצעות רשת ה-VPC המארחת. אם רשת ה-VPC המארחת מורשית למדיניות שרת או לאזור העברה גלובלי רגיל של Cloud DNS שמוגדרים עם נקודות קצה יוצאות, Pods שמשתמשים בפענוח DNS של VPC מנתבים באופן אוטומטי שאילתות יוצאות דרך נקודות קצה יוצאות אזוריות, בלי צורך בשינויים ברמת האשכול או באזורי העברה אזוריים.

כדי לקבל מידע נוסף על העברת הגדרת העברת DNS קיימת ל-Cloud DNS לנקודות קצה יוצאות, ראו איך מעבירים הגדרה קיימת של העברת DNS לנקודות קצה יוצאות.

ארכיטקטורה של נקודות קצה יוצאות וניתוב שאילתות

נקודת קצה יוצאת נוצרת ברשת VPC ספציפית (באמצעות רשת משנה רגילה באזור היעד של כתובת ה-IP הפנימית של נקודת הקצה), ומשתמשת ברשת משנה של שרת proxy בלבד באזור של אותה רשת בשביל כתובת ה-IP של המקור.

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

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

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

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

גם אם נקודת הקצה עם הדירוג הגבוה ביותר נמצאת באזור אחר, Cloud DNS ממשיך לנתב את השאילתות לנקודת הקצה הזו. לדוגמה, אם נקודת קצה באזור א' לא זמינה, התנועה מנותבת אוטומטית לנקודת קצה תקינה באזור ב'. כשהתקינות של נקודת הקצה באזור א' תחזור, אלגוריתם הדירוג יזהה את השיפור בביצועים ויתחיל להעדיף אותה שוב בשאילתות הבאות.

בכל פרויקט יכולות להיות עד 10 נקודות קצה יוצאות לכל אזור, ועד 100 נקודות קצה יוצאות שמצורפות לאזור העברה או למדיניות שרת.

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

ב-Cloud DNS אין הבטחה שתעבורת הנתונים תישלח לנקודת הקצה באותו אזור שבו נמצאת ה-VM שממנה היא נשלחה, אבל אתם יכולים להשתמש בכללי מדיניות לניתוב לפי מיקום גיאוגרפי כדי לנתב את תעבורת הנתונים לשרת השמות הקרוב ביותר. למרות ש-Cloud DNS מעדיף לנתב את התנועה לנקודת הקצה (endpoint) של התנועה היוצאת באזור שהכי קרוב לשאילתה המקורית ולשרת השמות המטורגט, האזור של שרת השמות המטורגט והאזור של נקודת הקצה של התנועה היוצאת לא קשורים זה לזה באופן הדוק. בלי קשר למיקום, מערכת Cloud DNS בוחרת את נקודת הקצה שבאופן היסטורי סיפקה את זמן האחזור הנמוך ביותר.

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

  • יצירת אזור עם מדיניות מיקום גיאוגרפי: יוצרים אזור פרטי חדש ב-Cloud DNS בשביל FQDN שבשליטתכם (לדוגמה, onprem-resolvers.example.com) שמורשה לרשת ה-VPC. באזור הזה, יוצרים רשומות A לכתובות ה-IP של שרת ה-DNS המקומי ומחילים מדיניות ניתוב לפי מיקום גיאוגרפי. מגדירים את המדיניות כך שתחזיר כתובות IP של פותרי DNS לשאילתות שמקורן באזור הספציפי הזה. לדוגמה, החזרת כתובות IP של פותרי DNS אירופיים לשאילתות שמקורן באזורים Google Cloud באירופה.
  • שימוש ב-FQDN כיעד להעברה: באזור ההעברה, משתמשים ב-FQDN שיצרתם (onprem-resolvers.example.com) כיעד של שרת ה-DNS.
  • הגדרת נקודות קצה יוצאות: משייכים את נקודות הקצה היוצאות האזוריות (לדוגמה, אחת באזור בארה"ב ואחת באזור באירופה) לאזור ההעברה הזה.

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

  • בחירת נקודת קצה: מערכת Cloud DNS מעריכה את רשימת נקודות הקצה לתעבורה יוצאת שמשויכות לאזור ההעברה, ובוחרת את נקודת הקצה הכי מתאימה (לדוגמה, סביר להניח שתיבחר נקודת קצה באירופה לשאילתה ממכונה וירטואלית באירופה).
  • פענוח היעד: Cloud DNS מפענח את ה-FQDN של היעד (onprem-resolvers.example.com) לאזור שממנו הגיעה השאילתה. לאחר מכן, השאילתה המקורית מועברת על ידי Cloud DNS דרך נקודת הקצה היוצאת שנבחרה לכתובת ה-IP של שרת ה-DNS שפוענחה. מדיניות המיקום הגיאוגרפי מזהה את מקור השאילתה כאזור הזה, ומחזירה את כתובת ה-IP הספציפית שהגדרתם לאזור הזה.

מידע נוסף זמין במדריך העברה יוצאת של DNS ב-Cloud DNS FQDN.

העברה מאזור בלי נקודת קצה מקומית ברשת VPC אחת

רשת VPC היא משאב גלובלי שיכול להכיל רשתות משנה בכמה אזורים. Google Cloud אם מכונה וירטואלית שולחת שאילתה מאזור שבו לא הגדרתם נקודת קצה יוצאת, ההעברה תתבצע בהצלחה. השאילתה תנותב בין אזורים לנקודת הקצה היוצאת הזמינה עם הדירוג הגבוה ביותר, שנמצאת באותה רשת VPC ומוגדרת באזור ההעברה או במדיניות השרת.

העברה מכמה רשתות VPC באותו אזור עם בידוד של כתובת ה-IP של המקור

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

  1. יצירת נקודת קצה יוצאת בכל רשת VPC: מידע נוסף זמין במאמר יצירת נקודת קצה יוצאת.
  2. יצירת מדיניות שרת או אזור העברה בכל רשת VPC: מאשרים את מדיניות השרת או אזור ההעברה רק לרשת ה-VPC הזו, ומשתמשים רק בנקודת הקצה לתעבורה יוצאת של רשת ה-VPC הזו.

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

העברה מאוחדת בין רשתות VPC שונות (Hub-and-Spoke)

אתם יכולים להגדיר מדיניות שרת או אזור העברה כדי להשתמש בנקודת קצה יוצאת ברשת VPC מרכזית אחרת (הרכזת). לא צריך קישוריות רשת בין רשת ה-hub לבין רשת ה-VPC שממנה מגיעה השאילתה (ה-spoke), כי Cloud DNS מטפל בהעברת השאילתה באופן פנימי.

צריך להגדיר את הקישוריות לרשת בין נקודת הקצה של התעבורה היוצאת לבין יעדי ההעברה באזור ההעברה או במדיניות השרת. אפשר ליצור קישוריות באמצעות Cloud Interconnect או Cloud VPN כדי להגיע למחלצים מקומיים. אפשר להשתמש בקישור בין רשתות VPC שכנות כדי להגיע ליעדי העברה ברשת VPC אחרת.

  1. יוצרים נקודת קצה יוצאת ברשת ה-VPC של ה-Hub.
  2. יוצרים מדיניות שרת או אזור העברה ברשת ה-VPC המקושרת, ומגדירים אותה כך שתשתמש בנקודת הקצה היוצאת של רשת ה-Hub.

המכונות הווירטואליות ברשתות ה-VPC המקושרות שולחות שאילתות דרך נקודת הקצה לתעבורה יוצאת ברשת ה-VPC המרכזית. נקודת הקצה מעבירה את השאילתה למפענח המקומי.

תמיכה ב-VPC משותף

נקודות קצה יוצאות תומכות בפריסות של VPC משותף. נקודת הקצה, רשת המשנה הרגילה שלה ורשת המשנה המשויכת אליה לשרת proxy בלבד נוצרות באופן מרכזי בפרויקט המארח. פרויקטים של שירות יכולים לרשת אזורי העברה או כללי מדיניות של שרתים שנוצרו בפרויקט המארח, או ליצור אזורי העברה פרטיים או כללי מדיניות של שרתים משלהם ולקשר אותם בין פרויקטים לנקודת הקצה המרכזית לתעבורה יוצאת בפרויקט המארח (לשם כך נדרשת ההרשאה dns.outboundEndpoints.bindPrivateDNSZone או dns.outboundEndpoints.bindPrivateDNSPolicy בפרויקט המארח).

ניהול משאבי רשת שמשויכים לנקודות קצה יוצאות

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

מחיקה של רשת משנה מסוג proxy-only או רשת VPC כשהן בשימוש על ידי נקודת קצה יוצאת

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

  1. עדכון ההגדרות של Cloud DNS: עורכים את כל אזורי ההעברה או כללי המדיניות של השרת שמשתמשים בנקודת הקצה היוצאת, ומסירים אותה מההגדרות כדי שהיא לא תהיה יותר בשימוש.
  2. מחיקת נקודת הקצה (endpoint) היוצאת: אחרי שנקודת הקצה לא בשימוש, אפשר למחוק אותה. הפעולה הזו משחררת את התלות ברשת המשנה הרגילה וברשת המשנה לשרת proxy בלבד.
  3. מחיקת רשתות המשנה: אחרי שמוודאים שאף משאב אחר לא משתמש בהן, מוחקים את רשתות המשנה הרגילות ואת רשתות המשנה לשרתי proxy בלבד.
  4. מחיקת רשת ה-VPC: אחרי שמסירים את כל יחסי התלות האחרים של ה-VPC, אפשר למחוק את רשת ה-VPC.

שינוי של רשת משנה

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

כדי לשנות רשת משנה שמשמשת נקודת קצה יוצאת:

  1. יצירת תת-רשת לגיבוי: יוצרים תת-רשת חדשה של שרת proxy בלבד באותו אזור ובאותה רשת VPC. בזמן היצירה, צריך להגדיר את התפקיד של רשת המשנה הזו כ-BACKUP.
  2. מפעילים את רשת המשנה החדשה: מעדכנים את התפקיד של רשת המשנה החדשה ל-ACTIVE. כך, רשת המשנה המקורית מוגדרת באופן אוטומטי לתפקיד BACKUP, ומתחיל תהליך של ניקוז החיבורים הפעילים ממנה.
  3. ‫Wait for draining: המתנה עד להשלמת התהליך של סגירת החיבורים.
  4. מחיקת רשת המשנה הישנה: עכשיו אפשר למחוק את רשת המשנה המקורית, אחרי שהיא בתפקיד BACKUP ואין לה חיבורים פעילים.

יכולת חיזוי של כתובת IP ייעודית של מקור לחומות אש מקומיות

אם חומות האש של ה-DNS המקומי דורשות טווח כתובות IP ייעודי וצפוי של מקור, שמבודד לתעבורת DNS, מומלץ להחיל את הארכיטקטורה הבאה:

  • פריסה ברשת VPC ייעודית לתעבורת נתונים יוצאת: יוצרים רשת VPC ייעודית עם תת-רשת רגילה (לכתובת ה-IP של נקודת הקצה לתעבורת נתונים יוצאת) ותת-רשת אזורית של שרתי proxy בלבד, ששמורה באופן בלעדי ל-Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY ו---role=ACTIVE).
  • בידוד רשתות ה-VPC של האפליקציה: אל תגדירו קישור בין רשתות ה-VPC של האפליקציה לבין רשת ה-egress הייעודית הזו, ואל תנתבו את התעבורה ביניהן. ‫Cloud DNS מנתב שאילתות באופן פנימי בתוך התשתית של Google Cloud, ולכן לא נדרש קישוריות רשת ישירה בין רשתות ה-VPC האלה.
  • חיבור רשת ה-VPC הייעודית לתעבורת נתונים יוצאת ליעדי העברה חיצוניים: מגדירים קישוריות רק בין רשת ה-VPC הייעודית לתעבורת נתונים יוצאת לבין שרתי השמות החיצוניים או המקומיים שאליהם רוצים להעביר את הבקשות. כדי ליצור את הנתיב הזה, משתמשים ב:
    • קישור בין רשתות VPC שכנות (peering) לרשת VPC קיימת למעבר: זו הגישה המומלצת והמשתלמת ביותר. אם לארגון שלכם כבר יש רשת VPC מרכזית להעברה עם Cloud Interconnect או Cloud VPN לרשת מקומית, אתם יכולים להגדיר קישור בין רשת ה-VPC הייעודית ל-DNS לבין מרכז ההעברה הזה. הגישה הזו מונעת הקצאה של מעגלים היברידיים מיותרים ומצמצמת את העלויות.
    • קישוריות היברידית ישירה: Dedicated Interconnect,‏ Cross-Cloud Interconnect או Cloud VPN שמסתיים ישירות ברשת ה-VPC הייעודית של DNS.

מגבלות

לנקודות קצה יוצאות יש את המגבלות הבאות:

  • כתובת ה-IP של המקור ושיתוף רשת המשנה מוגבלים למשאבים באותו אזור: נקודות קצה יוצאות מקצות טווחי כתובות IP של מקור מרשת המשנה האזורית של שרתי proxy בלבד ברשת ה-VPC שאליה הן מחוברות. בפריסות רגילות, אפשר לשתף את רשת המשנה הזו עם משאבים אזוריים אחרים, כמו מאזני עומסים של אפליקציות (ALB) אזוריים.

  • אין תמיכה בקישור ישיר בין רשתות שכנות (direct peering) לרשתות משנה של שרתי proxy בלבד: אי אפשר לקשר ישירות בין רשתות שכנות לרשת משנה של שרתי proxy בלבד. צריך ליצור קישוריות רשת לשרתי שמות חיצוניים באמצעות ניתוב VPC רגיל, כמו Cloud Interconnect, ‏ Cloud VPN או VPC Network Peering.

  • תמיכה ב-IPv4 בלבד: כתובת ה-IP של המקור של נקודת קצה יוצאת היא IPv4 בלבד, ואפשר להעביר שאילתות רק ליעדי IPv4 או ליעדי העברה של FQDN באזורי העברה שמפנים לכתובות IPv4.

  • אי אפשר לקשר נקודות קצה יוצאות לרשת בפרויקטים שונים: אי אפשר ליצור נקודת קצה יוצאת בפרויקט שירות שמקושר לרשת VPC משותפת של פרויקט מארח. נקודות הקצה (endpoints) לתעבורה יוצאת חייבות להיות באותו פרויקט שבו נמצאות רשת ה-VPC ורשת המשנה שאליהן הן מחוברות.

  • מוגבל ליעדים פרטיים: נקודות קצה יוצאות תומכות רק בהעברה ליעדים פרטיים (כולל RFC 1918,‏ RFC 6598 וכתובות שאינן RFC 1918 שמנותבות באופן פרטי ומוגדרות באמצעות --private-forward-targets או forwardingPath: "private"), ואי אפשר להשתמש בהן כשרת proxy לתעבורת נתונים יוצאת או כעוגן סטטי של כתובת IP של מקור לתעבורת נתונים של DNS באינטרנט הציבורי. שאילתות ליעדים באינטרנט הציבורי נפתרות ישירות דרך קצה ה-anycast המבוזר של Google, כדי לצמצם את זמן האחזור ולמנוע תלות ב-Cloud NAT.

  • היקף אזורי: נקודות קצה יוצאות הן משאבים אזוריים. אתם צריכים ליצור נקודות קצה בכל אזור שבו אתם מתכוונים להשתמש בהן.

  • מנגנון העברה יחיד בלבד: מנגנון ההעברה (טווח ברירת המחדל 35.199.192.0/19 או נקודות קצה יוצאות) מוגדר ברמת אזור ההעברה או ברמת מדיניות השרת. עם זאת, אי אפשר להשתמש בשתי השיטות בו-זמנית לאותו אזור או לאותה מדיניות.

המאמרים הבאים