הגדרת רשתות בשירות מנוהל ל-Apache Kafka

לקוחות יכולים להתחבר לאשכול של שירות מנוהל ל-Apache Kafka מכל רשת ענן וירטואלי פרטי (VPC) בפרויקטים שלכם ב- Google Cloud.

בדף הזה מוסבר איך להגדיר את הרשת בשירות המנוהל ל-Apache Kafka, איך להפעיל חיבורים בין לקוחות Kafka לבין האשכול שלכם ואיך להפעיל קישוריות בין פרויקטים.

סקירה כללית

כשיוצרים אשכול, השירות ממקם אותו ברשת VPC שמנוהלת על ידי Google Cloud. הרשת הזו נקראת רשת הדייר. לכל אשכול של שירות מנוהל ל-Apache Kafka יש רשת דיירים מבודדת משלו. כדי לאפשר לאפליקציות לקוח לתקשר עם האשכול, צריך לחבר את תת-הרשתות ברשתות ה-VPC לרשת הדייר.

בתרשים הבא מוצגים שני פרויקטים, Google Cloud ו-project-2.project-1 אשכול של שירות מנוהל ל-Apache Kafka ממוקם ב-project-1.

אשכול של שירות מנוהל ל-Apache Kafka עם שלושה תתי-רשתות מקושרים

רשתות המשנה הבאות מחוברות לאשכול:

  • ‫subnet-1, ברשת ה-VPC‏ vpc-1 ב-project-1.
  • ‫subnet-2, ברשת ה-VPC‏ vpc-2 ב-project-1.
  • ‫subnet-3, ברשת ה-VPC‏ vpc-3 ב-project-2.

חיבור רשתות משנה לאשכול

כשיוצרים בפעם הראשונה אשכול של שירות מנוהל ל-Apache Kafka, צריך לציין לפחות רשת משנה אחת. בהמשך תוכלו לעדכן את האשכול כדי להוסיף או להסיר רשתות משנה.

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

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

רשומות DNS של אשכול

כשמקשרים רשת משנה לאשכול, השירות יוצר רשומות DNS ברשת המשנה עבור כתובת האתחול והברוקרים של האשכול. לקוחות Kafka משתמשים בכתובת ה-bootstrap כדי לאתר את ה-brokers וליצור חיבור.

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

דוגמאות ליישומי לקוח שמתחברים לשירות המנוהל ל-Apache Kafka מופיעות במדריכים הבאים:

התאמת הגודל של תת-רשת

כשמוסיפים תת-רשת לאשכול, צריכות להיות בתת-הרשת מספיק כתובות IP זמינות. לכל תת-רשת נדרשת כתובת IP אחת לכל ברוקר של Kafka, בנוסף לכתובת IP אחת לכתובת ה-bootstrap. הגודל המינימלי של אשכול בשירות המנוהל ל-Apache Kafka הוא שלושה ברוקרים, ולכן כל רשת משנה צריכה לכלול לפחות ארבע כתובות IP שניתן להשתמש בהן, כולל כתובת ה-bootstrap.

אם באשכול יש יותר מ-45 מעבדי vCPU, אז באשכול יש ברוקר אחד לכל 15 מעבדי vCPU. במקרה כזה, מחשבים את מספר כתובות ה-IP המינימלי לכל רשת משנה באופן הבא:

  1. מחלקים את מספר המעבדים הווירטואליים ב-15.
  2. מעגלים כלפי מעלה למספר השלם הקרוב ביותר.
  3. מוסיפים 1 כדי לכלול את כתובת ה-bootstrap.

לדוגמה, קלאסטר עם 60 ליבות וירטואליות צריך לפחות (60/15 + 1) = 5 כתובות IP שמישות.

יכול להיות ש-Google תשנה בעתיד את היחס בין הברוקרים לבין vCPU. כדי להתכונן לשינויים עתידיים, מומלץ להקצות פי 3 ממספר כתובות ה-IP שחושב בשלב הקודם.

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

אם אתם מתכננים להשתמש ב-Kafka Connect, כדאי גם להביא בחשבון את דרישות רשת המשנה עבור אשכול Connect. מידע נוסף זמין במאמר בנושא רשת משנה של עובדים.

טווחי כתובות IP ציבוריות שמשמשים לשימוש פרטי

אפשר לחבר את האשכול לתת-רשתות שמשתמשות במרחב כתובות שאינו RFC 1918. טווחים כאלה של כתובות IP נקראים טווחים של כתובות IP ציבוריות לשימוש פרטי (PUPI).

לא נדרשת הגדרה נוספת כדי להתחבר לתת-רשתות של PUPI. תת-הרשתות של PUPI צריכות להשתמש בטווח IPv4 תקין שלא נמצא בטווח תת-הרשתות האסור של IPv4.

חיבור לקוחות ואשכולות בין פרויקטים

אם יש לכם לקוחות Kafka בפרויקטים שונים, אתם יכולים לחבר אותם לאשכול בדרכים הבאות: Google Cloud

בקטעים הבאים מפורטות האפשרויות האלה.

קישור אשכול בין פרויקטים

אפשר לקשר רשתות משנה מפרויקטים אחרים לאשכול. כדי להפעיל גישה בין פרויקטים, צריך לתת הרשאות לחשבון השירות שמנוהל על ידי Google שמשויך לאשכול. בכל פרויקט שבו רוצים שלקוחות Kafka יוכלו לגשת לאשכול, לחשבון השירות צריך להיות מוקצה תפקיד ה-IAM‏ Managed Kafka Service Agent בפרויקט הזה. התפקיד הזה מאפשר לאשכול לגשת למשאביGoogle Cloud , כדי ליצור משאבי רשת ורשומות DNS.

דוגמה: אם project-1 מכיל את האשכול, ואתם רוצים שלקוחות ב-project-2 תהיה גישה לאשכול, צריך לתת לחשבון השירות המנוהל של Kafka עבור project-1 את התפקיד Managed Kafka Service Agent ב-project-2. לאחר מכן, מחברים רשת משנה מ-project-2 לאשכול, כמו שמתואר במאמר חיבור רשתות משנה לאשכול.

כדי להעניק את התפקידים הנדרשים:

המסוף

  1. קובעים את Google Cloud הפרויקטים שבהם רוצים שלקוחות Kafka יוכלו לגשת לאשכול של השירות המנוהל ל-Apache Kafka.

  2. לכל פרויקט, במסוף Google Cloud , נכנסים לדף IAM של הפרויקט:

    כניסה לדף IAM

  3. לוחצים על Grant access.

  4. בשדה New principals, מזינים את הערכים הבאים:

    service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com

    מחליפים את הערך CLUSTER_PROJECT_NUMBER במספר הפרויקט של הפרויקט שמכיל את האשכול של השירות המנוהל ל-Apache Kafka.

  5. לוחצים על הוספת תפקידים.

  6. בשדה חיפוש תפקידים, מזינים Managed Kafka Service Agent. השם של סוכן השירות מופיע בתוצאות החיפוש.

  7. בתוצאות החיפוש, בוחרים באפשרות Managed Kafka Service Agent.

  8. לוחצים על אישור.

  9. לוחצים על Save.

gcloud

  1. קובעים את Google Cloud הפרויקטים שבהם רוצים שלקוחות Kafka יוכלו לגשת לאשכול של השירות המנוהל ל-Apache Kafka.

  2. לכל פרויקט, מריצים את הפקודה gcloud projects add-iam-policy-binding:

    gcloud projects add-iam-policy-binding CLIENT_PROJECT_ID \
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --role=roles/managedkafka.serviceAgent

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLIENT_PROJECT_ID: השם של הפרויקט שמכיל את רשת ה-VPC שאליה רוצים להתחבר
    • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט שמכיל את האשכול של השירות המנוהל ל-Apache Kafka

שימוש ב-VPC משותף לחיבור פרויקטים

VPC משותף מאפשר לארגון לחבר משאבים מכמה פרויקטים לרשת VPC משותפת. כדי להשתמש ב-VPC משותף עם שירות מנוהל ל-Apache Kafka, צריך לבצע את השלבים הבאים:

  1. יוצרים אשכול של שירות מנוהל ל-Apache Kafka.

  2. הקצאת הרשאות ל-VPC משותף.

  3. מקצים לחשבון השירות של Managed Kafka את התפקידים הנדרשים בפרויקט המארח של ה-VPC המשותף, כמו שמתואר בקטע הקודם.

  4. מחברים את האשכול של השירות המנוהל ל-Apache Kafka לרשת משנה ברשת ה-VPC המשותפת.

לקוחות בפרויקט המארח של ה-VPC המשותף או בפרויקטים של השירות יכולים להתחבר לאשכול.

מידע על מקרים שבהם כדאי להשתמש ב-VPC משותף בארכיטקטורות של רשתות זמין במאמר שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC.

ארכיטקטורת הרשת של אשכול

בקטע הזה מתוארים פרטים על ארכיטקטורת הרשת שמשמשת בשירות המנוהל ל-Apache Kafka.

  • אשכול Kafka משתרע על רשת דיירים ועל רשת צרכנים אחת או יותר.

  • ברשת הדייר, לאשכול יש כתובת IP אחת וכתובת URL אחת לאתחול. כתובת ה-bootstrap הזו תואמת למאזן עומסים שמחובר לכל הברוקרים באשכול. כל ברוקר יכול לשמש גם כשרת bootstrap, אבל מומלץ להשתמש בכתובת ה-bootstrap כדי להבטיח אמינות.

  • בכל רשת צרכנים, השירות יוצר נקודת קצה של Private Service Connect לכתובת האתחול ונקודת קצה אחת לכל ברוקר.

  • כתובת ה-URL של כתובת ה-bootstrap זהה בכל רשתות ה-VPC שאליהן מקושר אשכול. כתובת ה-IP היא מקומית לרשת הצרכנים.

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

  • הלקוחות משתמשים בכתובת ה-bootstrap כדי לאחזר כתובות URL של ברוקרים. כתובות ה-URL האלה מומרות לכתובות IP מקומיות לכל רשת VPC. אפשר למצוא את כתובות ה-IP וכתובות ה-URL של הברוקר בפועל ב-Cloud DNS.

בתרשים הבא מוצגת דוגמה לארכיטקטורה של רשת אשכולות של שירות מנוהל ל-Apache Kafka.

רשת של שירות מנוהל ל-Apache Kafka

  • בדוגמה הזו, באשכול יש שלושה ברוקרים והאשכול נמצא ב-VPC של הדייר.

  • הברוקרים מתקשרים עם הלקוחות דרך יציאת ברירת המחדל של Kafka ‏ (9092) ויש להם כתובות IP ייחודיות. בדוגמה הזו, ל-3 הברוקרים יש כתובות IP‏: 10.128.10.2, ‏ 10.128.10.3 ו-10.128.10.4, בהתאמה.

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

פתרון בעיות

מידע על פתרון בעיות ברשת זמין במאמר שגיאות ברשת.

מה השלב הבא?