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

פתרון בעיות

למה מופיעה השגיאה `not found` כשמוסיפים נקודת קצה?

אם אתם מקבלים שגיאות 404 כשאתם מוסיפים שירותים או נקודות קצה, ודאו שיצרתם גם את מרחב השמות וגם את השירות (בסדר הזה) לפני שאתם מוסיפים נקודת קצה. השירות חייב להיות קיים כדי שאפשר יהיה להוסיף נקודות קצה נוספות.

כשמחפשים שירות, למה לא מופיעות נקודות הקצה שלי?

מוודאים שהפרויקט, האזור, שם מרחב השמות ושם השירות נכונים בבקשה וזהים לפרטים שבהם רשמתם את נקודות הקצה. כל השירותים של Service Directory נמצאים במרחב שמות אזורי, ולכן שירותים שנרשמו באזור אחד לא תואמים לנתונים באזור אחר.

הענקתי למישהו גישה לשירות, אבל הוא ממשיך לקבל את ההודעה `permission denied`.

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

הוספתי כמה נקודות קצה ואז הסרתי את ה-backend של השירות. למה נקודות הקצה עדיין מופיעות?

ב-Service Directory לא מתבצעת בדיקת תקינות אוטומטית או בדיקת פעימות לב, והוא לא מסיר נקודות קצה אלא אם מסירים אותן באופן מפורש. חשוב להוסיף קוד ל-backends או למנהלי התזמור של השירות כדי להסיר את נקודת הקצה מ-Service Directory ברגע שהיא כבר לא קיימת. מומלץ להשתמש בשדות הערות של זמן החיים (TTL) בנקודות קצה כדי לתעד את הפעם האחרונה שבה נקודת קצה נרשמה או עודכנה.

אני מצליח לחפש נקודות קצה, אבל כל ניסיון שלי להתחבר אליהן נכשל.

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

איך אפשר להוסיף נתוני בריאות לנקודות קצה כדי שהלקוחות שלי ידעו לאיזו נקודה להתחבר?

כשמשתמשים באיזון עומסים בצד הלקוח, מומלץ שמסדי נתונים עורפיים של שירותים יעודכנו מדי פעם בשדה הערה בנקודת הקצה, שבה הלקוחות יכולים להשתמש כדי להחליט לאיזה מסד נתונים עורפי להתחבר. ‫Service Directory לא בודק את הנתונים האלה ולא מעריך אותם.

יצרתי מרחב שמות. למה אי אפשר להקצות לו תחום פרטי ב-Cloud DNS?

חשוב לוודא שיש לכם הרשאת IAM במרחב השמות servicedirectory.namespaces.associatePrivateZone, כי ההרשאה הזו מאפשרת ליצור את האזור הפרטי המשויך. כברירת מחדל, התפקידים 'עריכת פרויקט', 'בעלי הפרויקט', 'אדמין בספריית השירותים' ו'עריכה בספריית השירותים' כוללים את ההרשאה הזו.

כשמבצעים חיפוש DNS של שירות, למה לא מקבלים את נקודות הקצה?

יכולות להיות לכך כמה סיבות, למשל:

מרחב השמות המשויך נמחק. כדי לבדוק את זה, מריצים את הפקודה get באזור הפרטי. אם הערך של serviceDirectoryConfig.deletionTime מוגדר, אז מרחב השמות המשויך וכל נקודות הקצה שלו נמחקו.
צריך לוודא שהבקשה מגיעה מרשת שיש לה הרשאה לשלוח שאילתות לאזור הפרטי. כדי לראות את רשימת הרשתות, מריצים את הפקודה get באזור הפרטי.
אין נקודות קצה (endpoint) (תקינות) לשירות. מריצים את הפקודה resolve בשירות באמצעות Service Directory API כדי לוודא שהשירות לא ריק ושיש לו לפחות כתובת IP אחת תקפה של נקודת קצה. תמיכה ב-DNS זמינה רק לנקודות קצה עם כתובות IP חוקיות מסוג IPv4 או IPv6.
חשוב לוודא שאתם שולחים שאילתה לאזור הנכון. לדוגמה, נניח שיוצרים אזור של Service Directory בשם example.com, ויש עוד אזור פרטי (רגיל) בשם billing.example.com. כל שאילתת DNS אל billing.example.com תחזיר רשומות משאבים ששייכות לאזור billing.example.com, ולא לשירות billing במרחב השמות של Service Directory שמשויך ל-example.com.למידע נוסף, אפשר לעיין במאמר בנושא סדר של פתרון שמות.

למה שירותי GKE שלי לא מסתנכרנים עם Service Directory?