הגדרת רשת של אשכול Dataproc

תיאור: הבנת הגדרות הרשת של אשכול Dataproc. הטמעת מסלולי VPC, כללי חומת אש, גישה פרטית ל-Google ו-VPC משותף לפריסות מאובטחות עם כתובות IP פנימיות בלבד.

בדף הזה מוסבר על הדרישות והאפשרויות להגדרת הרשת של אשכול Dataproc.

דרישות הקישוריות של Dataproc

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

דרישות לגבי מסלולים

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

כברירת מחדל, אשכולות של גרסאות תמונות Dataproc 2.2 ואילך מקצים מכונות וירטואליות עם כתובות IP פנימיות בלבד. ‫Dataproc מפעיל באופן אוטומטי גישה פרטית ל-Google (PGA) ברשת המשנה של האשכול, כדי לאפשר למכונות וירטואליות (VM) באשכול עם כתובות IP פנימיות להגיע לשירותים ול-Google APIs באמצעות נתיב ברירת מחדל שנוצר על ידי המערכת לשער האינטרנט שמוגדר כברירת מחדל.

כלל סוג טווח כתובות ה-IP של היעד עדיפות מגבלות על היקף הצעד הבא
default-route-[id] סטטי 0.0.0.0/0 1000 - שער ברירת המחדל באינטרנט

השימוש ב-PGA מבטיח שהתנועה בין האשכולות לא תעבור דרך האינטרנט הציבורי ולא תצא ממרכזי הנתונים של Google (ראו תרשים לדוגמה של PGA).

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

אם מחקתם את נתיב ברירת המחדל לשער האינטרנט, אתם צריכים להוסיף נתיב ברירת מחדל. טווחי כתובות ה-IP של היעד צריכים להיות 0.0.0.0/0 כי טווחי כתובות ה-IP של Dataproc Control API לא קבועים.

דרישות לגבי חומת האש

ברשת ה-VPC של אשכול Dataproc צריך לאפשר באופן מפורש את התנועה הבאה:

  • תעבורה שנוצרת ממכונות וירטואליות באשכול Dataproc אל Dataproc Control API וממכונות וירטואליות אחרות באשכול Dataproc. התנועה הזו מותרת כברירת מחדל על ידי כלל ברירת המחדל של יציאה מרשת ה-VPC. אם הוספתם כללי חומת אש שדוחים תעבורה יוצאת, צריך ליצור כלל חומת אש שמאפשר תעבורה יוצאת.

  • תעבורת התגובה מ-Dataproc Control API למכונות הווירטואליות של אשכול Dataproc מותרת כברירת מחדל, בגלל שמצב חומת אש בין רשתות של רשת ה-VPC נשמר.

  • תנועת נתונים שמתקבלת ממכונות וירטואליות באשכול Dataproc ממכונות וירטואליות אחרות באשכול Dataproc. התנועה הזו תידחה כברירת מחדל על ידי כלל חומת האש המרומזת של תעבורת נתונים נכנסת (ingress) של רשת VPC. צריך ליצור כלל חומת אש שמאפשר תעבורת נתונים נכנסת.

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

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

יצירת כלל חומת אש להרשאת תעבורת נתונים נכנסת (ingress)

אם אתם או מנהל הרשת או מנהל האבטחה שלכם יוצרים כלל חומת אש לתעבורת נתונים נכנסת כדי להחיל אותו על רשת VPC של אשכול Dataproc, הכלל צריך לכלול את המאפיינים הבאים:

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

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

  • הכלל חייב לכלול את הפרוטוקולים והיציאות הבאים:

    • ‫TCP (כל היציאות, 0 עד 65535)
    • ‫UDP (כל היציאות, 0 עד 65535)
    • ICMP

    ‫Dataproc משתמש בשירותים שפועלים בכמה יציאות. ציון של כל היציאות עוזר להפעיל את השירותים בהצלחה.

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

יצירת כלל חומת אש שמאפשר תעבורת נתונים יוצאת (egress)

אם אתם או מנהל הרשת או מנהל האבטחה שלכם יוצרים כלל חומת אש לתעבורת נתונים יוצאת כדי להחיל אותו על רשת VPC של אשכול Dataproc, הכלל צריך לכלול את המאפיינים הבאים:

  • הפרמטר destinations מציין את היעדים של החבילות. כל מכונות ה-VM באשכול Dataproc צריכות להיות מסוגלות ליזום תעבורה אחת לשנייה ול-Dataproc Control API. כתובות ה-IP של API הבקרה הן לא סטטיות, ולכן צריך לציין את היעד לפי טווח כתובות IP 0.0.0.0/0.

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

  • הכלל חייב לכלול את הפרוטוקולים והיציאות הבאים:

    • ‫TCP (כל היציאות, 0 עד 65535)
    • ‫UDP (כל היציאות, 0 עד 65535)
    • ICMP

    ‫Dataproc משתמש בשירותים שפועלים בכמה יציאות. ציון של כל היציאות עוזר להפעיל את השירותים בהצלחה.

  • העדיפות של הכלל צריכה להיות גבוהה יותר מהעדיפות של כל כללי חומת האש של תעבורת נתונים יוצאת (egress) שחלים על אותם יעדים ומטרות.

אבחון של כללי חומת אש בין רשתות ברשת VPC

כדי לבדוק מנות שלא עברו עיבוד על ידי כללי חומת אש עם עדיפות גבוהה יותר, אפשר ליצור את שני כללי חומת האש הבאים עם עדיפות נמוכה (65534) מסוג deny. בניגוד לכללי חומת האש המשתמעים, אפשר להפעיל רישום ביומן של כללי חומת האש בכל אחד מהכללים האלה בעדיפות נמוכה:

  1. כלל לדחיית תעבורת נכנסת (מקורות 0.0.0.0/0, כל הפרוטוקולים, כל היעדים ברשת ה-VPC)

  2. כלל לדחיית תעבורת נתונים יוצאת (יעדים 0.0.0.0/0, כל הפרוטוקולים, כל היעדים ברשת ה-VPC)

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

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

יצירת רשת VPC

במקום להשתמש ברשת ה-VPC‏ default, אפשר ליצור רשת VPC משלכם במצב אוטומטי או מותאם אישית. כשיוצרים את האשכול, משייכים את הרשת לאשכול.

סביבת Assured Workloads: כשמשתמשים בסביבת Assured Workloads לצורך עמידה בתקנות, האשכול, רשת ה-VPC שלו והקטגוריות שלו ב-Cloud Storage צריכים להיכלל בסביבת Assured Workloads.

יצירת אשכול שמשתמש ברשת ה-VPC

המסוף

בקטע Network configuration (הגדרות רשת) בחלונית Customize cluster (התאמה אישית של האשכול), בוחרים את הרשת. אחרי שבוחרים את הרשת, בתפריט הבחירה Subnetwork מוצגות רשתות משנה שזמינות באזור שבחרתם עבור האשכול.

Google Cloud CLI

משתמשים ב-gcloud dataproc clusters create עם הדגל ‑‑network או ‑‑subnet כדי ליצור אשכול ברשת משנה ברשת שלכם. אם משתמשים בדגל ‎‑‑network, האשכול ישתמש ברשת משנה עם אותו שם כמו הרשת שצוינה באזור שבו האשכול נוצר.

‫--network example. מכיוון שרשתות במצב אוטומטי נוצרות עם רשתות משנה בכל אזור, ולכל רשת משנה ניתן שם הרשת, אפשר להעביר את שם רשת ה-VPC במצב אוטומטי אל הדגל ‑‑network. האשכול ישתמש בתת-רשת של VPC במצב אוטומטי באזור שצוין באמצעות הדגל ‎‑‑region.

gcloud dataproc clusters create CLUSTER_NAME \
    --network NETWORK_NAME \
    --region=REGION \
    ... other args ...

‫--subnet example. אפשר להשתמש בדגל ‑‑subnet כדי ליצור אשכול שמשתמש בתת-רשת של רשת VPC במצב אוטומטי או בהתאמה אישית באזור האשכול. מציינים את הנתיב המלא למשאב של רשת המשנה.

‫
gcloud dataproc clusters create CLUSTER_NAMEW \
    --subnet projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME \
    --region=REGION \
    ... other args ...

API ל-REST

אפשר לציין את השדה networkUri או subnetworkUri GceClusterConfig כחלק מבקשת clusters.create.

דוגמה

‫
POST /v1/projects/my-project-id/regions/us-central1/clusters/
{
  "projectId": "PROJECT_ID",
  "clusterName": CLUSTER_NAME,
  "config": {
    "configBucket": "",
    "gceClusterConfig": {
      "subnetworkUri": SUBNET_NAME,
    },
    ...

יצירת אשכול שמשתמש ברשת VPC בפרויקט אחר

אפשר להשתמש באשכול Dataproc ברשת VPC משותפת שמוגדרת בפרויקט מארח. הפרויקט שבו נוצר אשכול Dataproc נקרא פרויקט שירות.

  1. מאתרים את מספר הפרויקט של אשכול Dataproc:

    1. פותחים את הדף IAM & Admin (ניהול הרשאות גישה) Settings (הגדרות) במסוףGoogle Cloud . בוחרים את הפרויקט שבו רוצים ליצור את אשכול Dataproc. מעתיקים את מזהה הפרויקט.

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

    1. מוודאים שהפרויקט המארח של ה-VPC המשותף מופעל.

    2. מצרפים את הפרויקט עם אשכול Dataproc לפרויקט המארח.

    3. מגדירים את חשבון השירות של סוכן השירות של Dataproc (service-[project-number]@dataproc-accounts.iam.gserviceaccount.com) כך שיהיה לו התפקיד Network User בפרויקט המארח:

      1. פותחים את הדף IAM & Admin במסוף Google Cloud .

      2. משתמשים בבורר הפרויקטים כדי לבחור את פרויקט המארח החדש.

      3. לוחצים על הענקת גישה.

      4. ממלאים את טופס הענקת הגישה:

        1. הוספת חשבונות משתמשים: מזינים את חשבון השירות.

        2. הקצאת תפקידים: מזינים Compute Network בתיבת המסנן, ואז בוחרים בתפקיד Compute Network User.

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

  3. אחרי שחשבון השירות מקבל את התפקיד Network User בפרויקט המארח, יוצרים אשכול שמשתמש ברשת ה-VPC המשותפת.

יצירת אשכול שמשתמש בתת-רשת VPC בפרויקט אחר

בפרויקט אחר.

אפשר להשתמש באשכול Dataproc בתת-רשת של VPC משותף שמוגדרת בפרויקט מארח. הפרויקט שבו נוצר אשכול Dataproc נקרא פרויקט שירות.

  1. מאתרים את מספר הפרויקט של אשכול Dataproc:

    1. פותחים את הדף IAM & Admin (ניהול הרשאות גישה) Settings (הגדרות) במסוףGoogle Cloud . בוחרים את הפרויקט שבו רוצים ליצור את אשכול Dataproc. מעתיקים את מזהה הפרויקט.

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

    1. מוודאים שהפרויקט המארח של ה-VPC המשותף מופעל.

    2. מצרפים את הפרויקט עם אשכול Dataproc לפרויקט המארח.

    3. מגדירים את חשבון השירות של סוכן השירות של Dataproc (service-[project-number]@dataproc-accounts.iam.gserviceaccount.com) כך שיהיה לו התפקיד Network User בפרויקט המארח:

      1. פותחים את הדף VPC networks במסוף Google Cloud .

      2. משתמשים ברשימת הפרויקטים כדי לבחור את פרויקט המארח.

      3. לוחצים על הרשת שמכילה את רשת המשנה שבה ישתמש אשכול Dataproc.

      4. בדף VPC Network Details (פרטי רשת ה-VPC), לוחצים על תיבת הסימון לצד השם של תת-הרשת שבה ישתמש האשכול.

      5. אם חלונית המידע לא פתוחה, לוחצים על Show Info Panel.

      6. מבצעים את השלבים הבאים לכל חשבון שירות:

        1. בחלונית הפרטים, לוחצים על הוספת גורם ראשי.

        2. ממלאים את טופס הענקת הגישה:

          1. הוספת חשבונות משתמשים: מזינים את חשבון השירות.

          2. הקצאת תפקידים: מזינים Compute Network בתיבת המסנן, ואז בוחרים בתפקיד Compute Network User.

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

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

יצירת אשכול עם כתובות IP פנימיות בלבד

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

אפשר להשתמש במסוף Google Cloud , ב-CLI של gcloud או ב-Dataproc API כדי ליצור אשכול עם כתובות IP פנימיות בלבד. שימו לב: כשמפעילים את האפשרות 'כתובת IP פנימית בלבד',‏ Dataproc מפעיל אוטומטית גישה פרטית ל-Google ברשת המשנה האזורית של האשכול, כדי לאפשר חיבורים לשירותים ולממשקי Google API.

המסוף

אפשר ליצור אשכול Dataproc עם כתובות IP פנימיות רק מדף יצירת אשכול של Dataproc במסוף Google Cloud . כדי להפעיל את התכונה הזו באשכול, לוחצים על Internal IP only (כתובת IP פנימית בלבד) בחלונית Customize cluster (התאמה אישית של האשכול).

‫CLI של gcloud

אפשר ליצור אשכול עם כתובות IP פנימיות בלבד באמצעות הפקודה gcloud dataproc clusters create עם הדגל ‑‑no-address. 

gcloud dataproc clusters create CLUSTER_NAME \
    --no-address \
    --network NETWORK_NAME \
    --region=REGION \
    ... other args ...

מכיוון שרשתות אוטומטיות נוצרות עם רשתות משנה בכל אזור עם אותו שם כמו הרשת האוטומטית, אפשר להעביר את שם הרשת האוטומטית אל ‑‑network flag כדי ליצור אשכול שישתמש ברשת המשנה האוטומטית באזור של האשכול.

אפשרות אחרת היא להשתמש בדגל ‑‑subnet כדי ליצור אשכול שישתמש בתת-רשת אוטומטית או מותאמת אישית באזור שבו האשכול ייווצר. מעבירים את האפשרות ‑‑subnet עם הנתיב המלא למשאב של תת-הרשת.

gcloud dataproc clusters create cluster-name \
    --no-address \
    --subnet projects/project-id/regions/region/subnetworks/subnetwork-name \
    --region=region \
    ... other args ...

API ל-REST

אפשר להשתמש בשדה GceClusterConfig.internalIpOnly כחלק מבקשת clusters.create כדי ליצור אשכול שמופעלות בו רק כתובות IP פנימיות.

לדוגמה:

POST /v1/projects/my-project-id/regions/us-central1/clusters/
{
  "projectId": "my-project-id",
  "clusterName": "example-cluster",
  "config": {
    "configBucket": "",
    "gceClusterConfig": {
      "subnetworkUri": "custom-subnet-1",
      "zoneUri": "us-central1-b",
      "internalIpOnly": true
    },
    ...

הורדת יחסי תלות באמצעות אשכולות עם כתובות IP פנימיות בלבד

כברירת מחדל, לאשכולות עם כתובות IP פנימיות בלבד אין גישה לאינטרנט. לכן, משימות שמורידות תלות מהאינטרנט, כמו משימות שמורידות חבילות תלות של Spark מ-Maven Central, ייכשלו. יש כמה דרכים לעקוף את הבעיה:

  1. משתמשים ב-Cloud NAT כדי לאפשר גישה של האשכול לאינטרנט.

  2. יוצרים קובץ אימג' בהתאמה אישית שכולל את יחסי התלות (לדוגמה, חבילות של יחסי תלות ב-Spark ב-/usr/lib/spark/jars/).

  3. מעלים את התלויות לקטגוריה של Cloud Storage, ואז משתמשים בפעולת אתחול כדי להוריד את התלויות מהקטגוריה במהלך יצירת האשכול.

רשתות Dataproc ו-VPC Service Controls

בעזרת VPC Service Controls, אדמינים יכולים להגדיר גבולות גזרה מסביב למשאבים של שירותים בניהול Google, וכך לשלוט בתקשורת אל השירותים האלה וביניהם.

כשמשתמשים ברשתות של VPC Service Controls עם אשכולות Dataproc, חשוב לשים לב למגבלות ולשיטות הבאות:

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