Service Discovery

במסמך הזה יש סקירה כללית של גילוי שירותים מבוסס-DNS ב-Kubernetes, ושל אופן השימוש בו עם Kf.

מתי כדאי להשתמש בגילוי שירותים של Kubernetes עם Kf

אפליקציות שצריכות לאתר שירותי גיבוי באופן עקבי, בלי קשר למיקום הפריסה שלהן, יכולות להשתמש בזיהוי שירותים ב-Kubernetes. לדוגמה, צוות יכול להשתמש ב-URI משותף בהגדרה שלו שתמיד מצביע על שער SMTP מקומי, כדי להפריד את הקוד מהסביבה שבה הוא פועל.

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

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

אפשר להשתמש בגילוי שירותים ב-Kubernetes במקרים הבאים:

  • אפליקציות משתמשות בהגדרות ה-DNS של הקונטיינר שלהן כדי לפתור מארחים.
  • האפליקציות נפרסות עם שירותי הגיבוי שלהן באותו אשכול או מרחב שמות של Kubernetes.
  • לשירותי גיבוי יש שירות Kubernetes משויך. ‫Kf יוצר את הקבצים האלה לכל אפליקציה.
  • כללי מדיניות של רשת Kubernetes מאפשרים תעבורת נתונים בין אפליקציה לבין שירות Kubernetes שהיא צריכה לתקשר איתו. ‫Kf יוצר את כללי המדיניות האלה בכל מרחב Kf.

לא מומלץ להשתמש בגילוי שירותים ב-Kubernetes אם:

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

איך פועל גילוי שירותים ב-Kubernetes

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

דומיינים ללא כמה חלקים יפוענחו מול השמות של שירותי Kubernetes במרחב השמות של הקונטיינר. כל אפליקציית Kf יוצרת שירות Kubernetes עם אותו שם. אם שתי אפליקציות Kf‏, ping ו-pong, נפרסו באותו מרחב Kf, אז אפליקציה ping יכולה להשתמש בכתובת ה-URL‏ http://pong כדי לשלוח תנועה לשירות השני.

דומיינים עם נקודה אחת יפורשו מול שירותי Kubernetes במרחב השמות של Kubernetes עם אותו שם כמו התווית אחרי הנקודה. לדוגמה, אם יש מסד נתונים של PostgreSQL עם שירות customers במרחב השמות database, אפליקציה במרחב שמות אחר יכולה לפתור אותו באמצעות postgres://customers.database.

איך משתמשים בגילוי שירותים עם Kf

אפשר להשתמש בגילוי שירותים מבוסס DNS של Kubernetes בכל אפליקציית Kf. כל אפליקציית Kf יוצרת שירות Kubernetes עם אותו שם, וכל מרחב Kf יוצר מרחב שמות של Kubernetes עם אותו שם.

  • אפשר להפנות לאפליקציית Kf במרחב הנוכחי באמצעות התג protocol://app-name.
  • כדי להפנות לאפליקציית Kf במרחב אחר, משתמשים ב-protocol://app-name.space-name.
  • הפניה לאפליקציית Kf במרחב הנוכחי שמקשיבה ביציאה מותאמת אישית באמצעות protocol://app-name:port.
  • הפניה לאפליקציית Kf במרחב אחר שמקשיבה ליציאה מותאמת אישית באמצעות protocol://app-name.space-name:port.

שיטות מומלצות

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

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

אם יש שירותים ספציפיים לסביבה מחוץ לאשכול, אפשר לבצע רזולוציה שלהם באמצעות DNS של Kubernetes אם מגדירים שירותי ExternalName של Kubernetes. שירותי Kubernetes האלה מספקים את אותן יכולות של פתרון בעיות, אבל מחזירים רשומת CNAME כדי להפנות בקשות לרשות חיצונית.

השוואה ל-Eureka

‫Eureka הוא מאזן עומסים בצד הלקוח בקוד פתוח, שנוצר על ידי Netflix. הוא משמש בדרך כלל כחלק ממתווך השירותים של Spring Cloud Services. ‫Eureka נוצרה כמאזן עומסים אזורי ומנגנון לחיפוש שירותים לשירותים שפועלים בסביבה שגורמת לשיבושים תכופים בעומסי העבודה, מה שמוביל לכתובות IP לא יציבות.

‫Eureka מתוכנן כמודל לקוח/שרת. הלקוחות נרשמים בשרת ומציינים את השמות שהם רוצים לשייך לעצמם, ובאופן תקופתי הם שולחים לשרת פעימות לב. השרת מאפשר לכל הלקוחות המחוברים לפתור שמות.

באופן כללי, מומלץ להשתמש ב-Kubernetes DNS במקום ב-Eureka ב-Kubernetes מהסיבות הבאות:

  • מערכת ה-DNS פועלת עם כל שפות התכנות והאפליקציות בלי צורך בספריות.
  • הבדיקה הקיימת של תקינות האפליקציה תשמש שוב, וכך יצטמצמו שילובים של שגיאות.
  • ‫Kubernetes מנהל את שרת ה-DNS, כך שאתם יכולים להסתמך על פחות תלות.
  • מערכת ה-DNS של Kubernetes פועלת בהתאם לאותה מדיניות ולאותן מגבלות RBAC כמו שאר המערכות של Kubernetes.

יש כמה מקרים שבהם כדאי לפרוס שרת Eureka:

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

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