Kafka דרך פרוקסי: ה-bootstrap עובד, חיבורי ה-broker נכשלים
מסביר מדוע חיבור bootstrap מוצלח של Kafka אינו מבטיח גישה דרך הפרוקסי לכל broker שהתגלה.
חיבור bootstrap יכול להצליח בעוד לקוח Kafka עדיין אינו יכול לייצר או לצרוך. שרתי bootstrap עוזרים ללקוח לגלות את האשכול; הם אינם בהכרח נקודות הקצה היחידות שאליהן יתחבר.
מטא-נתוני ה-broker מכילים כתובות המשמשות לחיבורים מאוחרים יותר. אם השמות או הפורטים האלה אינם נגישים דרך נתיב הפרוקסי המיועד, החיבור המוצלח הראשון אינו פותר את שאר העבודה.
קראו את נקודות הקצה המוכרזות
השוו את כתובת ה-bootstrap לכתובות ה-broker שהלקוח מקבל בפועל. כינוי bootstrap ציבורי יכול להוביל לשמות מוכרזים פרטיים, והעברת פורט מקומי אחד אינה משכתבת אוטומטית כל כתובת במטא-נתונים.
זהו גם את נתיב הפרוקסי שהמימוש של הלקוח תומך בו. מאפיין SOCKS של מערכת Java אינו ערובה לכך שתעבורה של ספרייה המבוססת על NIO משתמשת במנגנון הפרוקסי של JDK Socket. בדקו את לקוח Kafka בפועל ואת שילוב הרשת במקום להניח שכל socket של Java מכבד את אותה הגדרה.
לקוח המודע לפרוקסי זקוק לנתיב מורשה לנקודות הקצה הרלוונטיות של ה-broker. סידור ברמת הרשת זקוק לנגישות ולפתרון שמות מתאימים. אלה עיצובים שונים, ואף אחד מהם אינו מסופק רק על ידי רישום פרוקסי כשרת bootstrap.
הפרידו בין הגדרות פרוטוקול האבטחה לבין הגדרות האימות. פרוקסי יכול להקים נתיב TCP בעוד זהות TLS, אימות SASL או הרשאת broker עדיין נכשלים.
לצורך אבחון, ציינו איזו נקודת קצה נכשלה והאם היא באה מתצורה סטטית או ממטא-נתונים שהוחזרו. הבחנה זו מצמצמת את הבעיה הרבה יותר מאשר שינוי חוזר של נקודת קצה שכבר הייתה נגישה.