מידע על זיהוי שירותים

במסמך הזה מוסבר איך גילוי שירותים ב-Google Kubernetes Engine ‏ (GKE) מפשט את ניהול האפליקציות, ואיך אפשר להרחיב את גילוי השירותים מעבר לאשכול יחיד באמצעות היקפי Cloud DNS, שירותים מרובי אשכולות (MCS) ו-Service Directory.

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

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

סקירה כללית

זיהוי שירותים הוא מנגנון שמאפשר לשירותים ולאפליקציות למצוא זה את זה ולתקשר ביניהם באופן דינמי, בלי לקודד כתובות IP או הגדרות של נקודות קצה. גילוי שירותים עוזר לוודא שלאפליקציות תמיד תהיה גישה לכתובות IP עדכניות של קבוצות Pod, גם כשמבצעים תזמון מחדש של קבוצות Pod או כשמוסיפים קבוצות Pod חדשות. ‫GKE מציע כמה דרכים להטמעת גילוי שירותים, כולל kube-dns, פריסות מותאמות אישית של kube-dns ו-Cloud DNS. אפשר לבצע אופטימיזציה נוספת של ביצועי ה-DNS באמצעות NodeLocal DNSCache.

היתרונות של זיהוי שירותים

היתרונות של גילוי שירותים:

  • ניהול פשוט של אפליקציות: זיהוי שירותים מבטל את הצורך בהוספת כתובות IP בהגדרות האפליקציה. האפליקציות מתקשרות באמצעות שמות לוגיים של שירותים, שמפוענחים אוטומטית לכתובות ה-IP הנכונות של ה-Pod. הגישה הזו מפשטת את ההגדרה, במיוחד בסביבות דינמיות שבהן כתובות ה-IP של ה-Pod עשויות להשתנות בגלל שינוי גודל או תזמון מחדש.
  • הגדלת קיבולת וחוסן פשוטים יותר: זיהוי שירותים מפשט את הגדלת הקיבולת על ידי הפרדה בין צרכני השירות לבין כתובות ה-IP של ה-Pod, שמשתנות לעיתים קרובות. בזמן שהאפליקציה מתרחבת, או אם קבוצות Pod נכשלות ומוחלפות, מערכת Kubernetes מעדכנת אוטומטית אילו קבוצות Pod זמינות לקבלת תנועה בשביל שירות נתון. גילוי שירותים עוזר לוודא שהבקשות לשם השירות היציב מופנות רק ל-Pods תקינים, וכך האפליקציה יכולה להתרחב או להתאושש מכשלים בלי התערבות ידנית או הגדרה מחדש של הלקוח.
  • זמינות גבוהה: GKE משתמש במאזן עומסים בשילוב עם גילוי שירותים כדי להבטיח זמינות גבוהה ולשפר את מהירות התגובה של האפליקציות, גם בעומסים כבדים.

איזון עומסים באמצעות גילוי שירותים

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

  • שירותים פנימיים: בשירותים שאפשר לגשת אליהם רק בתוך האשכול, מישור הנתונים של GKE (kube-proxy או Cilium) פועל כמאזן עומסים. הוא מפזר את התנועה הנכנסת באופן שווה בין כמה Pods תקינים, וכך מונע עומס יתר ועוזר להבטיח זמינות גבוהה.
  • שירותים חיצוניים: כדי ששירותים יהיו נגישים מחוץ לאשכול, GKE מספק מאזני עומסים מסוג Google Cloud Load Balancers. מאזני העומסים האלה כוללים Google Cloud מאזני עומסים חיצוניים לגישה לאינטרנט הציבורי ו Google Cloud מאזני עומסים פנימיים לגישה בתוך רשת הענן הווירטואלי הפרטי. מאזני העומסים האלה מפזרים את התנועה בין הצמתים באשכול. מישור הנתונים בכל צומת מנתב את התנועה הלאה אל ה-Pods המתאימים.

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

תרחישי שימוש בחיפוש שירותים

אלה כמה תרחישי שימוש נפוצים לגילוי שירותים:

  • ארכיטקטורת מיקרו-שירותים: בארכיטקטורת מיקרו-שירותים, אפליקציות מורכבות לרוב משירותים קטנים ועצמאיים רבים שצריכים ליצור אינטראקציה. גילוי שירותים מאפשר לאפליקציות האלה למצוא אחת את השנייה ולהחליף מידע, גם בזמן שהאשכול מתרחב.
  • הפעלה של פריסות ללא השבתה ושיפור העמידות: גילוי שירותים מאפשר עדכונים של אפליקציות ללא השבתה, כולל השקות מבוקרות ופריסות קנרית. הוא מאפשר לגלות באופן אוטומטי גרסאות חדשות של שירותים ולהעביר אליהן את התנועה, וכך עוזר לצמצם את זמן ההשבתה במהלך הפריסה ולהבטיח מעבר חלק למשתמשים. זיהוי שירותים גם משפר את העמידות. כש-Pod נכשל ב-GKE, נפרס Pod חדש, והתכונה 'גילוי שירותים' רושמת את ה-Pod החדש ומפנה אליו את התנועה, מה שעוזר לצמצם את זמן ההשבתה של האפליקציה.

איך עובד זיהוי שירותים

ב-GKE, אפליקציות מורכבות לרוב מכמה Pods שצריכים למצוא אחד את השני ולתקשר ביניהם. זיהוי שירותים מספק את היכולת הזו באמצעות מערכת שמות הדומיין (DNS). בדומה לשימוש ב-DNS כדי למצוא אתרים באינטרנט, רכיבי Pod באשכול GKE משתמשים ב-DNS כדי לאתר שירותים ולהתחבר אליהם באמצעות שמות השירותים שלהם. הגישה הזו מאפשרת ל-Pods ליצור אינטראקציה יעילה, בלי קשר למיקום שבו הם פועלים באשכול, ומאפשרת לאפליקציות לתקשר באמצעות שמות שירות עקביים ולא באמצעות כתובות IP לא יציבות.

איך מתבצע פענוח DNS ב-Pods

תאי Pod באשכול GKE מפענחים שמות DNS של שירותים ותאי Pod אחרים באמצעות שילוב של רשומות DNS שנוצרות באופן אוטומטי והגדרת ה-DNS המקומית שלהם.

שמות DNS של שירותים

כשיוצרים שירות Kubernetes, ‏ GKE מקצה לו באופן אוטומטי שם DNS. השם הזה מופיע בפורמט צפוי, וכל Pod באשכול יכול להשתמש בו כדי לגשת לשירות:

<service-name>.<namespace>.svc.cluster.local

דומיין האשכול שמוגדר כברירת מחדל הוא cluster.local, אבל אפשר להתאים אישית את הדומיין כשיוצרים את האשכול. לדוגמה, לשירות שנקרא my-web-app במרחב השמות שמוגדר כברירת מחדל יהיה שם ה-DNS‏ my-web-app.default.svc.cluster.local.

התפקיד של /etc/resolv.conf

כדי לפתור את שמות ה-DNS האלה, רכיבי ה-Pod מסתמכים על קובץ /etc/resolv.conf שלהם. קובץ התצורה הזה מציין ל-Pod לאיזה שרת שמות לשלוח את שאילתות ה-DNS. כתובת ה-IP של שרת השמות שמופיעה בקובץ הזה תלויה בתכונות ה-DNS הספציפיות שמופעלות באשכול GKE. בטבלה הבאה מפורטות כתובות ה-IP של שרתי השמות שבהן נעשה שימוש ב-Pod, בהתאם להגדרה שלכם:

‫Cloud DNS ל-GKE NodeLocal DNSCache ערך שרת השמות של ‎`/etc/resolv.conf` ‎
מופעל מופעל ‪`169.254.20.10`
מופעל מושבת ‪`169.254.169.254`
מושבת מופעל כתובת ה-IP של שירות kube-dns
מושבת מושבת כתובת ה-IP של שירות kube-dns

ההגדרה הזו עוזרת לוודא ששאילתות DNS מה-Pod מופנות לרכיב הנכון:

  • ‫NodeLocal DNSCache: מספק חיפושים מהירים ומקומיים בצומת.
  • כתובת ה-IP של שרת המטא-נתונים (169.254.169.254): משמשת כשהאפשרות Cloud DNS for GKE מופעלת בלי NodeLocal DNSCache. שאילתות DNS מופנות לכתובת ה-IP הזו, שמשמשת את Cloud DNS ליירוט ולטיפול בבקשות DNS.
  • kube-dns כתובת ה-IP של השירות: משמשת לפתרון בעיות רגיל בתוך האשכול כש-Cloud DNS ל-GKE מושבת.

ארכיטקטורת DNS ב-GKE

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

  • ‫kube-dns: ספק ה-DNS שמוגדר כברירת מחדל באשכולות GKE Standard. הוא פועל כפריסת Pods מנוהלת במרחב השמות kube-system ועוקב אחרי Kubernetes API כדי ליצור את רשומות ה-DNS הנדרשות לשירותים חדשים.
  • ‫Cloud DNS:שירות DNS מנוהל באופן מלא. Google Cloudהוא מציע חלופה אמינה וניתנת להרחבה ל-kube-dns, והוא ספק ה-DNS שמוגדר כברירת מחדל באשכולות GKE Autopilot.
  • ‫NodeLocal DNSCache: תוסף ל-GKE שמשפר את הביצועים של חיפוש DNS. התוסף מפעיל מטמון DNS בכל צומת באשכול, ועובד עם kube-dns או עם Cloud DNS כדי להציג שאילתות DNS באופן מקומי. כך הוא מצמצם את זמן האחזור ואת העומס על ספק ה-DNS המרכזי של האשכול. באשכולות GKE Autopilot, ‏ NodeLocal DNSCache מופעל כברירת מחדל ואי אפשר לשנות את ההגדרה הזו.
  • פריסה מותאמת אישית של kube-dns: פריסה שמאפשרת לפרוס ולנהל את המופע של kube-dns, ומספקת יותר שליטה בהגדרות ובמשאבים של kube-dns.

בחירת ספק DNS

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

ספק תכונות מתי כדאי לבחור
‫`kube-dns` פענוח DNS בתוך האשכול לשירותים ולקבוצות Pod. כל האשכולות עם צרכים סטנדרטיים של רשת. הגרסה החדשה של ‫`kube-dns` מתאימה לאשכולות קטנים וגדולים.
Cloud DNS תכונות מתקדמות של DNS (אזורים פרטיים, ניהול תעבורה, איזון עומסים גלובלי) ושילוב עם שירותים אחרים של Google Cloud . חשיפת שירותים חיצונית, סביבות מרובות אשכולות או אשכולות עם שיעורי שאילתות DNS גבוהים (QPS).
פריסת `kube-dns` בהתאמה אישית שליטה נוספת בהגדרות, בהקצאת משאבים ובאפשרות להשתמש בספקי DNS חלופיים. אשכולות בקנה מידה גדול או צרכים ספציפיים של DNS שדורשים שינוי גודל אגרסיבי יותר או שליטה מדויקת בהקצאת משאבים.

זיהוי שירותים מחוץ לאשכול יחיד

אפשר להרחיב את גילוי השירותים מעבר לאשכול GKE יחיד באמצעות השיטות הבאות:

היקף Cloud DNS

אפשר להפעיל אשכולות שמשתמשים ב-Cloud DNS ל-DNS של האשכול באחד משלושת ההיקפים הבאים:

  • היקף האשכול: זו התנהגות ברירת המחדל של Cloud DNS. במצב הזה, הפונקציות של Cloud DNS דומות לאלה של kube-dns, והוא מספק המרת DNS רק למשאבים שנמצאים באשכול. אפשר לבצע רזולוציה של רשומות DNS רק מתוך האשכול, והן תואמות לסכימת שירות Kubernetes הרגילה: <svc>.<ns>.svc.cluster.local.
  • היקף VPC מצטבר: התכונה האופציונלית הזו מרחיבה את היקף האשכול, כך שאפשר לפתור שירותים ללא ראש (headless) ממשאבים אחרים באותה רשת VPC, כמו מכונות וירטואליות של Compute Engine או לקוחות מקומיים שמתחברים באמצעות Cloud VPN או Cloud Interconnect.
  • היקף VPC: בהגדרה הזו, אפשר לפתור רשומות DNS של שירותי אשכולות בכל רשת ה-VPC. המשמעות של הגישה הזו היא שכל לקוח שנמצא באותו VPC או שמחובר אליו (דרך Cloud VPN או Cloud Interconnect) יכול לפתור ישירות את שמות השירותים.

מידע נוסף על DNS בהיקף VPC זמין במאמר שימוש ב-Cloud DNS ב-GKE.

שירותים מרובי אשכולות

שירותים מרובי אשכולות (MCS) מאפשרים גילוי שירותים וניהול תעבורה בכמה אשכולות GKE. ‫MCS מאפשרת לכם ליצור אפליקציות שפועלות על פני אשכולות, תוך שמירה על חוויית שירות מאוחדת.

שירות MCS משתמש בזיהוי שירותים מבוסס-DNS כדי לחבר שירותים בין אשכולות. כשיוצרים מופע MCS, נוצרות רשומות DNS בפורמט הבא: <svc>.<ns>.svc.clusterset.local. הרשומות האלה מומרות לכתובות ה-IP של נקודות הקצה של השירות בכל אשכול משתתף.

כשלקוח באשכול אחד ניגש ל-MCS, הבקשות מנותבות לנקודת הקצה הזמינה הקרובה ביותר בכל אחד מהאשכולות המשתתפים. הפצת התנועה הזו מנוהלת על ידי kube-proxy (או Cilium ב-GKE GKE Dataplane V2) בכל צומת, מה שעוזר להבטיח תקשורת יעילה ואיזון עומסים בין האשכולות.

Service Directory ל-GKE

‫Service Directory for GKE מספק רישום מאוחד לגילוי שירותים בפריסות של Kubernetes ובפריסות שאינן של Kubernetes. ב-Service Directory אפשר לרשום גם שירותי GKE וגם שירותים שלא שייכים ל-GKE במאגר רישום יחיד.

ספריית השירותים שימושית במיוחד אם רוצים:

  • מאגר יחיד לאפליקציות Kubernetes ולאפליקציות שאינן Kubernetes, שמאפשר לאפליקציות לגלות אחת את השנייה.
  • כלי לזיהוי שירותים מנוהלים.
  • היכולת לאחסן מטא-נתונים לגבי השירות שלכם, שלקוחות אחרים יכולים לגשת אליהם.
  • היכולת להגדיר הרשאות גישה ברמת השירות. אפשר לפענח את השירותים של Service Directory באמצעות DNS,‏ HTTP ו-gRPC. ‫Service Directory משולב עם Cloud DNS, ויכול לאכלס רשומות של Cloud DNS שתואמות לשירותים ב-Service Directory.

מידע נוסף זמין במאמר הגדרת Service Directory ל-GKE.

אופטימיזציה של הביצועים של DNS ושיטות מומלצות

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

אופטימיזציה של הביצועים באמצעות NodeLocal DNSCache

אם יש לכם אשכולות עם צפיפות גבוהה של Pods או אפליקציות שמייצרות נפח גבוה של שאילתות DNS, תוכלו לשפר את מהירות החיפוש של DNS על ידי הפעלת NodeLocal DNSCache. ‫NodeLocal DNSCache הוא תוסף ל-GKE שמריץ מטמון DNS בכל צומת באשכול. כש-Pod שולח בקשת DNS, הבקשה מגיעה למטמון שנמצא באותו צומת. הגישה הזו מפחיתה את זמן האחזור ואת נפח התנועה ברשת.

מידע נוסף על הפעלה והגדרה של התכונה הזו זמין במאמר בנושא הגדרת NodeLocal DNSCache.

הגדלת הקיבולת של ספק ה-DNS

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

הוראות מפורטות מופיעות במאמר בנושא הגדרת פריסה מותאמת אישית של kube-dns.

המלצות כלליות

  • בוחרים את ספק ה-DNS המתאים: בוחרים את ספק ה-DNS בהתאם לצרכים של האשכול. מומלץ להשתמש ב-Cloud DNS לעומסי עבודה עם QPS גבוה, לסביבות מרובות אשכולות וכשצריך שילוב עם רשת ה-VPC הרחבה יותר. הגרסה החדשה של kube-dns מתאימה למגוון רחב של אשכולות, מקטנים ועד גדולים, עם צרכים סטנדרטיים של גילוי שירותים באשכול.
  • לא מומלץ להשתמש במכונות Spot או במכונות preemptible VM עבור kube-dns: כדי להבטיח את היציבות של שירות ה-DNS באשכול, לא מומלץ להריץ רכיבי מערכת קריטיים כמו kube-dns במכונות Spot או במכונות preemptible VM. סיום לא צפוי של צומת עלול לגרום לבעיות בפענוח DNS.
  • להשתמש בשמות שירות ברורים ותיאוריים: כדאי להשתמש בשמות שירות עקביים ובעלי משמעות כדי להקל על קריאה ותחזוקה של הגדרות האפליקציה.
  • ארגון באמצעות מרחבי שמות: שימוש במרחבי שמות של Kubernetes כדי לקבץ שירותים קשורים. הגישה הזו עוזרת למנוע התנגשויות בשמות ולשפר את הארגון של משאבי האשכול.
  • ניטור ואימות של DNS: מומלץ לנטר באופן קבוע את מדדי ה-DNS והיומנים כדי לזהות בעיות פוטנציאליות לפני שהן משפיעות על האפליקציות. מעת לעת, כדאי לבדוק את פענוח ה-DNS מתוך ה-Pods כדי לוודא שזיהוי השירותים פועל כצפוי.

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