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

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

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

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

סקירה כללית

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

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

בתרשים הבא מוצגים שני פרויקטים, Google Cloud , project-1 ו-project-2. אשכול של שירות מנוהל ל-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 בפעם הראשונה, צריך לציין לפחות רשת משנה אחת. אפשר לעדכן את האשכול בהמשך כדי להוסיף או להסיר רשתות משנה.

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

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

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

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

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

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

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

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

כשמוסיפים תת-רשת לאשכול, בתת-הרשת צריכים להיות מספיק כתובות 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. כדי להתמודד עם שינויים אפשריים, מומלץ להקצות פי שלושה ממספר כתובות ה-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.

קישור לקוחות לאשכול ציבורי

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

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

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

כדי להוסיף או להסיר טווחי כתובות IP מותרים של מקורות, צריך לעדכן את האשכול. בשירות המנוהל ל-Apache Kafka נעשה שימוש ב-Cloud Next Generation Firewall כדי להגביל את הגישה לאשכולות ציבוריים. הסרת טווחי כתובות IP של מקורות מורשים חלה רק על חיבורים חדשים (ראו השפעות על תעבורה קיימת).

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

אדמינים של אבטחה יכולים לאסור על שימוש באשכולות ציבוריים על ידי הפעלת האילוץ Restrict Managed Kafka Public Clusters (constraints/managedkafka.managed.restrictPublicClusters) של מדיניות הארגון המנוהלת. מידע נוסף על אילוצים מנוהלים זמין במאמר בנושא אילוצים מנוהלים.

הגדרת חומות אש לתעבורת נתונים יוצאת מרשתות חיצוניות

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

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

  1. כתובות ה-IPv4 החיצוניות שמשויכות לאשכול זמינות ב-שירות מנוהל ל-Apache Kafka API‏, gcloud וב-Terraform.

  2. השירות שומר רשומת DNS אחת או יותר של גילוי. אלה רשומות DNS A שמכילות את כל כתובות ה-IPv4 החיצוניות שמשויכות לאשכול. אפשר להשתמש ברשומות האלה בחומות אש שמבוססות על FQDN, כמו Cloud NGFW, שמעדכנות את הכללים באופן אוטומטי כשיש שינויים ברשימת נקודות הקצה. רשימת נקודות הקצה של Discovery זמינה ב-API,‏ gcloud וב-Terraform.

כשמשתמשים בכתובות ה-IP הציבוריות שמשויכות לאשכול, חשוב להביא בחשבון את הנקודות הבאות:

  1. רשימת כתובות ה-IPv4 הציבוריות שמשויכות לאשכול עשויה להשתנות או לגדול. לכן, כדאי להגדיר תהליך אוטומטי לצריכת המידע הזה, או להגדיר תהליך שיביא בחשבון רשומות DNS חדשות של גילוי כשמגדילים את האשכול. שינויים יכולים להתרחש במקרים הבאים:

    • מגדילים את הקיבולת של האשכול. הגדלת הקיבולת עשויה להוסיף כתובת IPv4 חיצונית אחת או יותר כשמוסיפים ברוקרים חדשים. כדי להבין איך מספר ליבות ה-vCPU משפיע על מספר הברוקרים, אפשר לעיין במאמר בנושא קביעת גודל רשת המשנה.

    • מכבים את התכונה של אשכול ציבורי ומפעילים אותה מחדש. בפעולה הזו מוקצה אשכול חדש של כתובות IPv4 חיצוניות לאשכול.

  2. כל רשומת DNS של גילוי מכילה עד 30 כתובות IP. ההגדרה הזו נשארת במסגרת המגבלות הנפוצות שנאכפות על ידי חומות אש של FQDN. במקרים שבהם יש 29 ברוקרים או פחות, יש רשומת DNS אחת לגילוי שמכילה 30 כתובות IPv4 חיצוניות (כולל רשומת ה-bootstrap). השירות מוסיף רשומת DNS אחת של גילוי לכל 30 ברוקרים נוספים. כדי להבין איך מספר ליבות ה-vCPU משפיע על מספר הברוקרים, אפשר לעיין במאמר הגדרת גודל רשת המשנה.

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

  4. אם אתם משתמשים במידע הזה כדי להגדיר חומות אש ליציאת נתונים, צריך לאפשר קישוריות ליציאות TCP‏ 9092 (SASL) ו-9192 (mTLS).

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

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

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

  • ברשת הדייר, לאשכול יש כתובת IP אחת של bootstrap וכתובת 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. כך מובטחת זמינות גבוהה ועמידות בפני תקלות אזוריות, כי כתובת האתחול לא מוגבלת למתווך או לאזור יחיד.

מגבלות

המגבלות הבאות חלות על חיבורי VPC ועל אשכולות ציבוריים:

  • האזור של רשת המשנה. רשתות המשנה המחוברות צריכות להיות באותו אזור של האשכול.

  • מספר רשתות המשנה. אפשר לחבר לקלאסטר לפחות רשת משנה אחת ולכל היותר עשר רשתות משנה.

  • רשתות משנה לכל רשת. אפשר לחבר לאשכול לכל היותר רשת משנה אחת לכל רשת VPC.

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

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

  • טווחים של כתובות IP מותרות של מקורות. כל טווח כתובות IP מותרות של מקור עבור אשכול ציבורי צריך להיות מוגדר בסימון CIDR של IPv4. כל גודל של רשת משנה בפורמט CIDR חייב להיות בין /16 ל-/32. אסור שיהיה חפיפה בין טווחי CIDR. אין תמיכה בכתובות IPv6. אפשר לציין עד 500 טווחי כתובות IP מותרים של מקורות.

  • פענוח DNS של רשומת גילוי. רשומות DNS של Discovery מיועדות רק להגדרת חומות אש ליציאה שמבוססות על FQDN. אל תגדירו את לקוחות Kafka להתחבר לרשומות ה-discovery האלה. במקום זאת, הגדירו את הלקוחות להתחבר לכתובת ה-bootstrap.

פתרון בעיות

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

מה השלב הבא?

‫Apache Kafka®‎ הוא סימן מסחרי רשום של The Apache Software Foundation או של השותפים העצמאיים שלה בארצות הברית או במדינות אחרות.