הגדרת אשכולות עם VPC משותף

במדריך הזה מוסבר איך ליצור שני אשכולות Google Kubernetes Engine ‏ (GKE) בפרויקטים נפרדים, שמשתמשים ב-VPC משותף. מידע כללי על רישות ב-GKE זמין במאמר סקירה כללית על רשתות.

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

למה כדאי להשתמש ב-VPC משותף עם GKE

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

אפשר להשתמש ב-VPC משותף עם אשכולות במצב Autopilot ועם אשכולות סטנדרטיים אזוריים ואזוריים.

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

אפשר להגדיר רשת VPC משותפת כשיוצרים אשכול חדש. ‫GKE לא תומך בהמרת אשכולות קיימים למודל של רשת VPC משותפת.

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

לפני שמתחילים

לפני שמתחילים להגדיר אשכול עם VPC משותף:

לפני שמבצעים את התרגילים במדריך הזה:

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

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

שם שקל להבין ‫מזהה פרויקט
placeholder
פלייסהולדר של מספר הפרויקט
הפרויקט המארח HOST_PROJECT_ID HOST_PROJECT_NUM
פרויקט השירות הראשון שלכם SERVICE_PROJECT_1_ID SERVICE_PROJECT_1_NUM
הפרויקט השני שלכם SERVICE_PROJECT_2_ID SERVICE_PROJECT_2_NUM

איך מוצאים את מזהי הפרויקטים ואת מספרי הפרויקטים

אפשר למצוא את מזהה הפרויקט ואת המספרים שלו באמצעות ה-CLI של gcloud או Cloud de Confiance המסוף.

המסוף

  1. נכנסים לדף Home במסוף Cloud de Confiance .

    חזרה לדף הבית

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

  3. בקטע Project info (פרטי הפרויקט) אפשר לראות את שם הפרויקט, מזהה הפרויקט ומספר הפרויקט. כדאי לרשום את המזהה והמספר כדי להשתמש בהם בהמשך.

  4. מבצעים את אותן פעולות לכל אחד מהפרויקטים שבחרתם כפרויקטים של שירות.

gcloud

מריצים את הפקודה הבאה כדי לראות את הפרויקטים:

gcloud projects list

בפלט מוצגים השמות, המזהים והמספרים של הפרויקטים. רושמים את המזהה והמספר כדי להשתמש בהם בהמשך:

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

הפעלת GKE API בפרויקטים

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

אפשר להפעיל את GKE API באמצעות Cloud de Confiance המסוף או Google Cloud CLI.

המסוף

  1. נכנסים לדף APIs & Services במסוף Cloud de Confiance .

    כניסה אל APIs & Services

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

  3. אם Kubernetes Engine API מופיע ברשימת ממשקי ה-API, הוא כבר מופעל ואין צורך לעשות דבר. אם הוא לא מופיע ברשימה, לוחצים על Enable APIs and Services. חיפוש של Kubernetes Engine API. לוחצים על הכרטיס Kubernetes Engine API ואז על Enable.

  4. חוזרים על השלבים האלה לכל פרויקט שבחרתם כפרויקט שירות. יכול להיות שיעבור קצת זמן עד להשלמת כל פעולה.

gcloud

מפעילים את GKE API בשלושת הפרויקטים. יכול להיות שיעבור קצת זמן עד להשלמת כל פעולה:

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

יצירת רשת ושתי רשתות משנה

בקטע הזה תבצעו את המשימות הבאות:

  1. בפרויקט המארח, יוצרים רשת בשם shared-net.
  2. יוצרים שתי רשתות משנה בשמות tier-1 ו-tier-2.
  3. לכל תת-רשת, יוצרים שני טווחים משניים של כתובות: אחד לשירותים ואחד ל-Pods.

המסוף

  1. נכנסים לדף VPC networks במסוף Cloud de Confiance .

    מעבר לרשתות VPC

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

  3. לוחצים על יצירת רשת VPC.

  4. בשדה Name (שם), מזינים shared-net.

  5. בקטע Subnet creation mode, בוחרים באפשרות Custom.

הוספת tier-1

  1. בקטע Subnets בתיבה New subnet, בשדה Name, מזינים tier-1.
  2. בשדה Region, בוחרים אזור.
  3. בקטע IP stack type, בוחרים באפשרות IPv4 (single-stack).
  4. בקטע טווח IPv4, מזינים 10.0.4.0/22 כטווח הכתובות הראשי של רשת המשנה.
  5. לוחצים על הוספת טווח משני של כתובות IPv4.

    • בשדה שם טווח תת-הרשת, מזינים tier-1-services.
    • בשדה Secondary IPv4 range, מזינים 10.0.32.0/20.
  6. לוחצים על סיום.

  7. לוחצים על הוספת טווח משני של כתובות IPv4.

    • בשדה שם טווח תת-הרשת, מזינים tier-1-pods.
    • בשדה Secondary IPv4 range, מזינים 10.4.0.0/14.
  8. לוחצים על סיום.

הוספת tier-2

  1. לוחצים על הוספת רשת משנה.
  2. בשדה Name (שם), מזינים tier-2.
  3. בשדה Region, בוחרים את אותו אזור שבחרתם עבור רשת המשנה הקודמת.
  4. בקטע טווח IPv4, מזינים 172.16.4.0/22 כטווח הכתובות הראשי של רשת המשנה.
  5. לוחצים על הוספת טווח משני של כתובות IPv4.

    • בשדה שם טווח תת-הרשת, מזינים tier-2-services.
    • בשדה Secondary IPv4 range, מזינים 172.16.16.0/20.
  6. לוחצים על סיום.

  7. לוחצים על הוספת טווח משני של כתובות IPv4.

    • בשדה שם טווח תת-הרשת, מזינים tier-2-pods.
    • בשדה Secondary IPv4 range, מזינים 172.20.0.0/14.
  8. לוחצים על סיום.

  9. גוללים לחלק התחתון של הדף ולוחצים על יצירה.

gcloud

בפרויקט המארח, יוצרים רשת בשם shared-net:

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

ברשת החדשה, יוצרים תת-רשת בשם tier-1:

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

יוצרים עוד תת-רשת בשם tier-2:

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

מחליפים את COMPUTE_REGION באזור של Compute Engine.

קביעת השמות של חשבונות השירות בפרויקטים של השירות

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

בטבלה הבאה מפורטים השמות של חשבונות השירות של GKE ו-Google APIs בשני פרויקטי השירות:

סוג חשבון השירות שם חשבון השירות
GKE service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
Google APIs SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com

הפעלת VPC משותף והקצאת תפקידים

כדי לבצע את המשימות בקטע הזה, צריך להיות אדמין של VPC משותף. אם אין לכם הרשאות אדמין של VPC משותף, אתם צריכים לבקש מאדמין בארגון להקצות לכם את התפקידים 'אדמין של VPC משותף ב-Compute' ‏ (compute.xpnAdmin) ו'אדמין IAM בפרויקט' ‏(resourcemanager.projectIamAdmin) בארגון או בתיקייה אחת או יותר.

בקטע הזה תבצעו את המשימות הבאות:

  1. בפרויקט המארח, מפעילים VPC משותף.
  2. מצרפים את שני פרויקטי השירות לפרויקט המארח.
  3. צריך להסיר את התפקיד Compute Network User מחשבונות השירות ששייכים לפרויקטים של השירותים, או להעניק להם אותו. אם משתמשים במסוףCloud de Confiance , מסירים את התפקיד. אם משתמשים ב-CLI של gcloud, מקצים את התפקיד.

המסוף

  1. נכנסים לדף VPC משותף במסוף Cloud de Confiance .

    מעבר ל-VPC משותף

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

  3. לוחצים על הגדרת VPC משותף. מוצג המסך הפעלת פרויקט מארח.

  4. לוחצים על הפעלה והמשך. מוצג הקטע Attach service projects and select principals (צירוף פרויקטים של שירות ובחירת גורמים ראשיים).

  5. בקטע Kubernetes Engine access (גישה ל-Kubernetes Engine), בוחרים באפשרות Enabled (מופעל).

  6. בקטע Select projects to attach (בחירת פרויקטים לצירוף), לוחצים על Add item (הוספת פריט).

  7. בשדה Select project, לוחצים על Select ובוחרים את פרויקט השירות הראשון.

  8. לוחצים שוב על Add item (הוספת פריט) ובוחרים את פרויקט השירות השני.

  9. לוחצים על Continue. יופיע הקטע הענקת גישה.

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

  11. בקטע Subnets with individual subnet access, גוללים ברשימה ובוחרים באפשרויות tier-1 ו-tier-2.

  12. לוחצים על Save. יוצג דף חדש.

  13. בוחרים באפשרות הצגת רשתות משנה שיש להן מדיניות IAM נפרדת בלבד.

הסרה של חשבונות שירות מ-tier-1

  1. בקטע גישה לרשת משנה ספציפית, בוחרים באפשרות רמה 1 ולוחצים על הצגת חלונית ההרשאות.
  2. בחלונית ההרשאות, בקטע תפקיד/גורם ראשי, מרחיבים את משתמש ברשת Compute.
  3. חיפוש של SERVICE_PROJECT_2_NUM.
  4. מוחקים את כל חשבונות השירות ששייכים לפרויקט השירות השני. כלומר, מוחקים את חשבונות השירות שמכילים את SERVICE_PROJECT_2_NUM.
  5. מוודאים שחשבונות השירות הבאים של פרויקט השירות הראשון מופיעים ברשימה עם התפקיד Compute Network User:

    • service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
    • SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
    • SERVICE_PROJECT_1_NUM-compute@developer.s3ns.iam.gserviceaccount.com

    אם חשבון שירות לא מופיע ברשימה, צריך להוסיף אותו באופן הבא:

    1. לוחצים על Add Principal (הוספת גורם ראשי).
    2. בשדה New principals, מזינים את השם של חשבון השירות.
    3. בקטע הקצאת תפקידים, בוחרים באפשרות משתמש ברשת מחשוב.
    4. לוחצים על Save.
  6. בקטע Individual subnet access [גישה לרשתות משנה נפרדות], מבטלים את הסימון של התיבה tier-1 [רמה 1].

הסרה של חשבונות שירות מ-tier-2

  1. בקטע גישה לרשתות משנה ספציפיות, בוחרים באפשרות tier-2.
  2. בחלונית ההרשאות, בקטע תפקיד/גורם ראשי, מרחיבים את משתמש ברשת Compute.
  3. חיפוש של SERVICE_PROJECT_1_NUM.
  4. מוחקים את כל חשבונות השירות ששייכים לפרויקט השירות הראשון. כלומר, מוחקים את כל חשבונות השירות שמכילים את SERVICE_PROJECT_1_NUM.
  5. מוודאים שחשבונות השירות הבאים של פרויקט השירות השני מופיעים ברשימה עם התפקיד Compute Network User:

    • service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
    • SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
    • SERVICE_PROJECT_2_NUM-compute@developer.s3ns.iam.gserviceaccount.com

    אם חשבון שירות לא מופיע ברשימה, צריך להוסיף אותו באופן הבא:

    1. לוחצים על Add Principal (הוספת גורם ראשי).
    2. מזינים את השם של חשבון השירות בשדה New principals.
    3. בקטע הקצאת תפקידים, בוחרים באפשרות משתמש ברשת מחשוב.
    4. לוחצים על Save.

gcloud

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

    אם יש לכם תפקיד אדמין ל-VPC משותף ברמת הארגון:

    gcloud compute shared-vpc enable HOST_PROJECT_ID
    

    אם יש לכם תפקיד אדמין של VPC משותף ברמת התיקייה:

    gcloud beta compute shared-vpc enable HOST_PROJECT_ID
    
  2. מצרפים את פרויקט השירות הראשון לפרויקט המארח:

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
        --host-project HOST_PROJECT_ID
    
  3. מצרפים את פרויקט השירות השני לפרויקט המארח:

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
        --host-project HOST_PROJECT_ID
    
  4. מקבלים את מדיניות ה-IAM עבור רשת המשנה tier-1:

    gcloud compute networks subnets get-iam-policy tier-1 \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
    

    הפלט מכיל את השדה etag. רושמים את הערך etag.

  5. יוצרים קובץ בשם tier-1-policy.yaml עם התוכן הבא:

    bindings:
    - members:
      - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
      - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
      role: roles/compute.networkUser
    etag: ETAG_STRING
    

    מחליפים את ETAG_STRING בערך etag שרשמתם קודם.

  6. מגדירים את מדיניות ה-IAM עבור רשת המשנה tier-1:

    gcloud compute networks subnets set-iam-policy tier-1 \
        tier-1-policy.yaml \
        --project HOST_PROJECT_ID \
        --region COMPUTE_REGION
    
  7. מקבלים את מדיניות ה-IAM עבור רשת המשנה tier-2:

    gcloud compute networks subnets get-iam-policy tier-2 \
        --project HOST_PROJECT_ID \
        --region COMPUTE_REGION
    

    הפלט מכיל את השדה etag. רושמים את הערך etag.

  8. יוצרים קובץ בשם tier-2-policy.yaml עם התוכן הבא:

    bindings:
    - members:
      - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
      - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
      role: roles/compute.networkUser
    etag: ETAG_STRING
    

    מחליפים את ETAG_STRING בערך etag שרשמתם קודם.

  9. מגדירים את מדיניות ה-IAM עבור רשת המשנה tier-2:

    gcloud compute networks subnets set-iam-policy tier-2 \
        tier-2-policy.yaml \
        --project HOST_PROJECT_ID \
        --region COMPUTE_REGION
    

ניהול משאבים של חומת אש

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

  • מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד Compute Security Admin בפרויקט המארח.

המסוף

  1. נכנסים לדף IAM במסוף Cloud de Confiance .

    כניסה ל-IAM

  2. בוחרים את פרויקט המארח.

  3. לוחצים על Grant access ומזינים את החשבון הראשי של חשבון השירות של פרויקט השירות ב-GKE,‏ service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

  4. בוחרים את התפקיד Compute Security Admin מהרשימה הנפתחת.

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

gcloud

מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד Compute Security Admin בפרויקט המארח:

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/compute.securityAdmin

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

  • HOST_PROJECT_ID: מזהה פרויקט המארח של ה-VPC המשותף
  • SERVICE_PROJECT_NUM: מזהה פרויקט השירות שמכיל את חשבון השירות של GKE
  • כדי להשתמש בגישה פרטנית יותר, יוצרים תפקיד IAM בהתאמה אישית שכולל רק את ההרשאות הבאות: compute.networks.updatePolicy,‏ compute.firewalls.list,‏ compute.firewalls.get,‏ compute.firewalls.create,‏ compute.firewalls.update ו-compute.firewalls.delete. מקצים את התפקיד המותאם אישית הזה לחשבון השירות של GKE בפרויקט השירות בפרויקט המארח.

המסוף

יוצרים תפקיד בהתאמה אישית בפרויקט המארח שכולל את הרשאות ה-IAM שצוינו קודם:

  1. נכנסים לדף Roles במסוף Cloud de Confiance .

    לדף Roles

  2. מהרשימה הנפתחת בחלק העליון של הדף, בוחרים את פרויקט המארח.

  3. לוחצים על Create Role.

  4. מזינים את השדות Title, ‏ Description, ‏ ID ו-Role launch stage של התפקיד. אי אפשר לשנות את שם התפקיד אחרי שיוצרים אותו.

  5. לוחצים על Add Permissions.

  6. מסננים לפי compute.networks ובוחרים את הרשאות ה-IAM שצוינו קודם.

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

  8. לוחצים על יצירה.

מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד המותאם אישית החדש שנוצר בפרויקט המארח:

  1. נכנסים לדף IAM במסוף Cloud de Confiance .

    כניסה ל-IAM

  2. בוחרים את פרויקט המארח.

  3. לוחצים על Grant access ומזינים את שם המשתמש (principal) של חשבון השירות של GKE בפרויקט השירות, service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

  4. מסננים לפי שם התפקיד החדש בהתאמה אישית ובוחרים אותו.

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

gcloud

  1. יוצרים תפקיד בהתאמה אישית בפרויקט המארח שכולל את הרשאות ה-IAM שצוינו קודם:

    gcloud iam roles create ROLE_ID \
        --title="ROLE_TITLE" \
        --description="ROLE_DESCRIPTION" \
        --stage=LAUNCH_STAGE \
        --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
        --project=HOST_PROJECT_ID
    
  2. מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד המותאם אישית החדש שנוצר בפרויקט המארח:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
        --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
        --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
    

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

    • ROLE_ID: שם התפקיד, למשל gkeFirewallAdmin
    • ROLE_TITLE: שם קליט לתפקיד, למשל GKE Firewall Admin
    • ROLE_DESCRIPTION: תיאור קצר של התפקיד, למשל GKE service account FW permissions
    • LAUNCH_STAGE: שלב ההשקה של התפקיד במחזור החיים שלו, למשל ALPHA,‏ BETA או GA
    • HOST_PROJECT_ID: מזהה פרויקט המארח של ה-VPC המשותף
    • SERVICE_PROJECT_NUM: מזהה פרויקט השירות שמכיל את חשבון השירות של GKE

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

סיכום של התפקידים שניתנו ברשתות משנה

סיכום של התפקידים שניתנו ברשתות המשנה:

חשבון שירות תפקיד תת-רשת
service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב tier-1
SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב tier-1
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב tier-2
SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב tier-2

אימות הגישה ל-GKE

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

כשמפעילים גישה ל-GKE, המערכת מקצה אוטומטית את התפקיד הבא בפרויקט המארח:

חבר תפקיד משאב
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש נציג שירות של המארח חשבון שירות של GKE בפרויקט המארח

עם זאת, כדי לגשת לרשת המארחת, צריך להוסיף באופן ידני את הרשאת ה-IAM‏ Compute Network User לחשבון השירות של GKE בפרויקט השירות.

חבר תפקיד משאב
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב פרויקט ספציפי של רשת משנה או של מארח שלם

אם פרויקט שירות צורף בלי להפעיל גישה ל-GKE, בהנחה ש-GKE API כבר הופעל גם בפרויקט המארח וגם בפרויקט השירות, אפשר להקצות ידנית את ההרשאות לחשבון השירות של GKE בפרויקט השירות על ידי הוספת התפקידים הבאים ב-IAM בפרויקט המארח:

חבר תפקיד משאב
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש ברשת מחשוב פרויקט ספציפי של רשת משנה או של מארח שלם
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com משתמש נציג שירות של המארח סוכן שירות GKE בפרויקט המארח

איך נותנים את התפקיד 'משתמש בסוכן שירות של מארח'

לכל סוכן שירות GKE בפרויקט שירות צריך להיות קישור לתפקיד Host Service Agent User ‏(roles/container.hostServiceAgentUser) בפרויקט המארח. ‫ GKE service agent מופיע באופן הבא:

service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com

כאשר SERVICE_PROJECT_NUM הוא מספר הפרויקט של השירות.

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

המסוף

אם השתמשתם במסוף Cloud de Confiance , לא צריך להקצות את התפקיד Host Service Agent User באופן מפורש. הפעולה הזו בוצעה באופן אוטומטי כשחיברתם פרויקטי שירות לפרויקט המארח באמצעות מסוף Cloud de Confiance .

gcloud

  1. בפרויקט הראשון, צריך להעניק את התפקיד Host Service Agent User לסוכן השירות של GKE בפרויקט. התפקיד הזה מוקצה בפרויקט המארח:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
        --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
        --role roles/container.hostServiceAgentUser
    
  2. בפרויקט השני, מקצים את התפקיד Host Service Agent User לסוכן השירות של GKE בפרויקט. התפקיד הזה מוקצה בפרויקט המארח:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
        --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
        --role roles/container.hostServiceAgentUser
    

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

כשיוצרים אשכול, צריך לציין רשת משנה ואת טווחי כתובות ה-IP המשניות שישמשו את ה-Pods והשירותים של האשכול. יכולות להיות כמה סיבות לכך שטווח כתובות IP לא זמין לשימוש. בין אם אתם יוצרים את האשכול באמצעות מסוף Cloud de Confiance או ה-CLI של gcloud, אתם צריכים לציין טווחי כתובות IP שניתן להשתמש בהם.

אפשר להשתמש בטווח כתובות IP עבור השירותים של האשכול החדש אם הטווח עדיין לא נמצא בשימוש. טווח כתובות ה-IP שאתם מציינים עבור ה-Pods של האשכול החדש יכול להיות טווח שלא נמצא בשימוש, או טווח שמשותף עם ה-Pods באשכולות אחרים. אי אפשר להשתמש בטווחים של כתובות IP שנוצרו ומנוהלים על ידי GKE באשכול שלכם.

אפשר לרשום את רשתות המשנה שניתן להשתמש בהן ואת טווחי כתובות ה-IP המשניות של פרויקט באמצעות ה-CLI של gcloud.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

מחליפים את SERVICE_PROJECT_ID במזהה פרויקט של פרויקט השירות.

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

הפלט אמור להיראות כך:

PROJECT               REGION    NETWORK     SUBNET  RANGE
example-host-project  us-west1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘
example-host-project  us-west1  shared-net  tier-2  172.16.4.0/22
┌──────────────────────┬────────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
├──────────────────────┼────────────────┼─────────────────────────────┤
│ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
│ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
└──────────────────────┴────────────────┴─────────────────────────────┘

הפקודה list-usable מחזירה רשימה ריקה במקרים הבאים:

  • כשחשבון השירות של GKE בפרויקט השירות לא מקבל את התפקיד Host Service Agent User בפרויקט המארח.
  • אם חשבון השירות של GKE בפרויקט המארח לא קיים (לדוגמה, אם מחקתם את החשבון הזה בטעות).
  • כש-GKE API לא מופעל בפרויקט המארח, מה שאומר שחשבון השירות של GKE בפרויקט המארח חסר.

מידע נוסף זמין בקטע פתרון בעיות.

מגבלות על טווחים משניים של כתובות IP

אפשר ליצור 30 טווחי משנה ברשת משנה נתונה. לכל אשכול צריך שני טווחי משנה: אחד ל-Pods ואחד ל-Services.

יצירת אשכול בפרויקט השירות הראשון

כדי ליצור אשכול בפרויקט השירות הראשון, מבצעים את השלבים הבאים באמצעות ה-CLI של gcloud או מסוף Cloud de Confiance .

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

    מעבר אל Google Kubernetes Engine

  2. בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.

  3. לוחצים על יצירה.

  4. בקטע Autopilot או Standard, לוחצים על Configure (הגדרה).

  5. בשדה Name (שם), מזינים tier-1-cluster.

  6. בתפריט הנפתח Region, בוחרים את אותו אזור שבו השתמשתם עבור רשתות המשנה.

  7. בחלונית הניווט, לוחצים על Networking (רשת).

  8. בקטע Cluster networking, לוחצים על Networks shared with me.

  9. בשדה Network, בוחרים באפשרות shared-net.

  10. בקטע Node subnet, בוחרים באפשרות tier-1.

  11. בקטע אפשרויות מתקדמות של רשת, בשדה טווח CIDR משני של Pod, בוחרים באפשרות tier-1-pods.

  12. בשדה טווח CIDR משני של שירותים, בוחרים באפשרות tier-1-services.

  13. לוחצים על יצירה.

אם יצרתם אשכול רגיל, תוכלו לראות שהצמתים של האשכול נמצאים בטווח הכתובות הראשי של רשת המשנה ברמה 1, כך:

  1. כשהיצירה תושלם, יוצג הדף Cluster details.
  2. לוחצים על הכרטיסייה Nodes.
  3. בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל).
  4. בקטע Instance groups (קבוצות של מופעים), לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה, gke-tier-1-cluster-default-pool-5c5add1f-grp.
  5. ברשימת המופעים, מוודאים שכתובות ה-IP הפנימיות של הצמתים נמצאות בטווח הראשי של רשת המשנה ברמה 1: 10.0.4.0/22.

gcloud

יוצרים אשכול בשם tier-1-cluster בפרויקט השירות הראשון:

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

מחליפים את CONTROL_PLANE_LOCATION באזור של Compute Engine במישור הבקרה של האשכול.

בסיום היצירה, מוודאים שצמתי האשכול נמצאים בטווח הראשי של רשת המשנה ברמה 1: 10.0.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

בפלט מוצגות כתובות ה-IP הפנימיות של הצמתים:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

יצירת אשכול בפרויקט השירות השני

כדי ליצור אשכול בפרויקט השירות השני, מבצעים את השלבים הבאים באמצעות ה-CLI של gcloud או מסוף Cloud de Confiance .

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

    מעבר אל Google Kubernetes Engine

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

  3. לוחצים על יצירה.

  4. בקטע 'רגיל' או 'טייס אוטומטי', לוחצים על הגדרה.

  5. בשדה Name (שם), מזינים tier-2-cluster.

  6. בתפריט הנפתח Region, בוחרים את אותו אזור שבו השתמשתם עבור רשתות המשנה.

  7. בחלונית הניווט, לוחצים על Networking (רשת).

  8. בקטע Cluster networking, לוחצים על Networks shared with me.

  9. בשדה Network, בוחרים באפשרות shared-net.

  10. בשדה Node subnet, בוחרים באפשרות tier-2.

  11. בקטע אפשרויות מתקדמות של רשת, בשדה טווח CIDR משני של Pod, בוחרים באפשרות tier-2-pods.

  12. בשדה Service secondary CIDR range, בוחרים באפשרות tier-2-services.

  13. לוחצים על יצירה.

אם יצרתם אשכול Standard, תוכלו לראות שהצמתים של האשכול נמצאים בטווח הכתובות הראשי של רשת המשנה ברמה 2, כך:

  1. כשהיצירה תושלם, יוצג הדף Cluster details.
  2. לוחצים על הכרטיסייה Nodes.
  3. בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל).
  4. בקטע Instance groups (קבוצות של מופעים), לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה, gke-tier-2-cluster-default-pool-5c5add1f-grp.
  5. ברשימת המופעים, מוודאים שכתובות ה-IP הפנימיות של הצמתים נמצאות בטווח הראשי של רשת המשנה ברמה 2: 172.16.4.0/22.

gcloud

יוצרים אשכול בשם tier-2-cluster בפרויקט השירות השני:

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

אחרי שהיצירה מסתיימת, צריך לוודא שצמתי האשכול נמצאים בטווח הראשי של רשת המשנה ברמה 2: 172.16.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

בפלט מוצגות כתובות ה-IP הפנימיות של הצמתים:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

יצירת כללים לחומת האש

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

יצירת כלל לחומת האש כדי להפעיל חיבור SSH לצומת

בפרויקט המארח, יוצרים כלל לחומת האש עבור רשת shared-net. מאפשרים לתנועה להיכנס דרך יציאת TCP‏ 22, וכך אפשר להתחבר לצמתי האשכול באמצעות SSH.

המסוף

  1. נכנסים לדף Firewall במסוף Cloud de Confiance .

    כניסה לדף Firewall

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

  3. בתפריט VPC Networking (רשתות VPC), לוחצים על Create Firewall Rule (יצירת כלל לחומת אש).

  4. בשדה Name (שם), מזינים my-shared-net-rule.

  5. בשדה רשת, בוחרים באפשרות shared-net.

  6. בשדה כיוון התנועה, בוחרים באפשרות תנועה נכנסת.

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

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

  9. בשדה מסנן מקור, בוחרים באפשרות טווח כתובות IP.

  10. בשדה טווחים של כתובות IP של המקור, מזינים 0.0.0.0/0.

  11. בקטע פרוטוקולים ויציאות, בוחרים באפשרות פרוטוקולים ויציאות שצוינו. בתיבה, מזינים tcp:22.

  12. לוחצים על יצירה.

gcloud

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

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

התחברות לצומת באמצעות SSH

אחרי שיוצרים את חומת האש שמאפשרת תעבורת נתונים נכנסת ביציאת TCP‏ 22, מתחברים לצומת באמצעות SSH.

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

    מעבר אל Google Kubernetes Engine

  2. בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.

  3. לוחצים על tier-1-cluster.

  4. בדף פרטי האשכול, לוחצים על הכרטיסייה צמתים.

  5. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים.

  6. בקטע Instance groups (קבוצות של מכונות), לוחצים על השם של קבוצת המכונות. לדוגמה, gke-tier-1-cluster-default-pool-faf87d48-grp.

  7. ברשימת המכונות, רושמים את כתובות ה-IP הפנימיות של הצמתים. הכתובות האלה נמצאות בטווח 10.0.4.0/22.

  8. באחד מהצמתים, לוחצים על SSH. הפעולה הזו מצליחה כי SSH משתמש ביציאת TCP‏ 22, שמותרת לפי כלל חומת האש.

gcloud

מציגים ברשימה את הצמתים בפרויקט השירות הראשון:

gcloud compute instances list --project SERVICE_PROJECT_1_ID

הפלט כולל את שמות הצמתים באשכול:

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

מתחברים לאחד מהצמתים באמצעות SSH:

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

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

  • NODE_NAME: השם של אחד מהצמתים.
  • COMPUTE_ZONE: השם של אזור Compute Engine בתוך האזור.

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

  1. בחלון שורת הפקודה של SSH, מפעילים את CoreOS Toolbox:

    /usr/bin/toolbox
    
  2. במעטפת של ארגז הכלים, שולחים פינג לאחד מהצמתים האחרים באותו אשכול. לדוגמה:

    ping 10.0.4.4
    

    הפקודה ping מצליחה, כי הצומת שלכם והצומת השני נמצאים שניהם בטווח 10.0.4.0/22.

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

    ping 172.16.4.3
    

    הפעם הפקודה ping נכשלת, כי כלל חומת האש לא מאפשר תעבורת נתונים של פרוטוקול הודעות הבקרה באינטרנט (ICMP).

  4. בשורת פקודה רגילה, לא במעטפת של ארגז הכלים, מעדכנים את כלל חומת האש כדי לאפשר ICMP:

    gcloud compute firewall-rules update my-shared-net-rule \
        --project HOST_PROJECT_ID \
        --allow tcp:22,icmp
    
  5. במעטפת של ארגז הכלים, שולחים שוב פינג לצומת. לדוגמה:

    ping 172.16.4.3
    

    הפעם הפקודה ping מסתיימת בהצלחה.

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

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

לדוגמה, הכלל הבא מאפשר לתעבורה להיכנס מכל צומת, Pod או שירות ב-tier-1-cluster בכל יציאת TCP או UDP:

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

הכלל הבא מאפשר לתעבורה להיכנס מכל צומת, Pod או שירות ב-tier-2-cluster בכל יציאת TCP או UDP:

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

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

אם רוצים לתת ל-Kubernetes הרשאה לשנות את הכללים של חומת האש, אפשר לעיין במאמר ניהול משאבים של חומת האש.

במאזני עומסים של Ingress, אם ל-Kubernetes אין הרשאה מספקת לשנות את כללי חומת האש, המערכת תפיק אירוע firewallXPNError כל כמה דקות. ב-GLBC 1.4 ואילך, אפשר להשתיק את האירוע firewallXPNError על ידי הוספת ההערה networking.gke.io/suppress-firewall-xpn-error: "true" למשאב הכניסה. תמיד אפשר להסיר את ההערה הזו כדי להפעיל את ההשתקה.

יצירת אשכול שמבוסס על קישור בין רשתות VPC שכנות (peering) ב-VPC משותף

אפשר להשתמש ב-VPC משותף עם אשכולות שמבוססים על קישור בין רשתות VPC שכנות (peering).

כדי לעשות את זה, צריך להעניק את ההרשאות הבאות בפרויקט המארח לחשבון המשתמש או לחשבון השירות שמשמש ליצירת האשכול:

  • compute.networks.get

  • compute.networks.updatePeering

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

בקטע הזה, יוצרים אשכול שמותאם ל-VPC בשם cluster-vpc ברשת VPC משותפת מוגדרת מראש.

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

    מעבר אל Google Kubernetes Engine

  2. לוחצים על יצירה.

  3. בקטע Autopilot או Standard, לוחצים על Configure (הגדרה).

  4. בשדה Name (שם), מזינים cluster-vpc.

  5. בחלונית הניווט, לוחצים על Networking (רשת).

  6. בקטע Cluster networking (רשת של אשכול), מסמנים את התיבה Enable Private nodes (הפעלת צמתים פרטיים).

  7. (אופציונלי ל-Autopilot): מגדירים את טווח כתובות ה-IP של מישור הבקרה ל-172.16.0.16/28.

  8. ברשימה הנפתחת רשת, בוחרים את רשת ה-VPC שיצרתם קודם.

  9. ברשימה הנפתחת Node subnet, בוחרים את רשת המשנה המשותפת שיצרתם קודם.

  10. מגדירים את האשכול לפי הצורך.

  11. לוחצים על יצירה.

gcloud

מריצים את הפקודה הבאה כדי ליצור אשכול בשם cluster-vpc ברשת VPC משותפת מוגדרת מראש:

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

שמירת כתובות IP

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

לכתובות IP פנימיות, צריך לציין את רשת המשנה שאליה שייכת כתובת ה-IP. כדי לשמור כתובת IP בפרויקטים, צריך להשתמש בכתובת ה-URL המלאה של המשאב כדי לזהות את רשת המשנה.

אפשר להשתמש בפקודה הבאה ב-Google Cloud CLI כדי לשריין כתובת IP פנימית:

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

כדי להפעיל את הפקודה הזו, צריך להוסיף את ההרשאה compute.subnetworks.use לרשת המשנה. אפשר להעניק למבצע הקריאה את התפקיד compute.networkUser ברשת המשנה, או להעניק למבצע הקריאה תפקיד בהתאמה אישית עם ההרשאה compute.subnetworks.use ברמת הפרויקט.

הסרת המשאבים

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

מחיקת האשכולות

מוחקים את שני האשכולות שיצרתם.

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

    מעבר אל Google Kubernetes Engine

  2. בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.

  3. בוחרים באפשרות tier-1-cluster ולוחצים על מחיקה.

  4. בכלי לבחירת פרויקטים, בוחרים את פרויקט השירות השני.

  5. בוחרים באפשרות tier-2-cluster ולוחצים על מחיקה.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --location CONTROL_PLANE_LOCATION

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --location CONTROL_PLANE_LOCATION

השבתת VPC משותף

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

המסוף

  1. נכנסים לדף VPC משותף במסוף Cloud de Confiance .

    מעבר ל-VPC משותף

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

  3. לוחצים על השבתת VPC משותף.

  4. מזינים את HOST_PROJECT_ID בשדה ולוחצים על השבתה.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

מחיקת הכללים של חומת האש

מסירים את הכללים של חומת האש שיצרתם.

המסוף

  1. נכנסים לדף Firewall במסוף Cloud de Confiance .

    כניסה לדף Firewall

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

  3. ברשימת הכללים, בוחרים באפשרויות my-shared-net-rule,‏ my-shared-net-rule-2 ו-my-shared-net-rule-3.

  4. לוחצים על Delete.

gcloud

מוחקים את הכללים של חומת האש:

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

מחיקת הרשת המשותפת

מוחקים את הרשת המשותפת שיצרתם.

המסוף

  1. נכנסים לדף VPC networks במסוף Cloud de Confiance .

    מעבר לרשתות VPC

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

  3. ברשימת הרשתות, לוחצים על הקישור shared-net.

  4. לוחצים על מחיקת רשת VPC.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

הסרת תפקיד המשתמש Host Service Agent

מסירים את תפקידי המשתמש של נציג שירות המארח משני פרויקטי השירות.

המסוף

  1. נכנסים לדף IAM במסוף Cloud de Confiance .

    כניסה לדף IAM

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

  3. בוחרים באפשרות Include Google-provided role grants.

  4. ברשימת החברים, בוחרים את השורה שבה מוצג service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com is granted the Kubernetes Engine Host Service Agent User role.

  5. לוחצים על עריכת המשתמש הראשי.

  6. בקטע Kubernetes Engine Host Service Agent User, לוחצים על הסמל כדי להסיר את התפקיד.

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

  8. בוחרים את השורה שבה מוצג service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com is granted the Kubernetes Engine Host Service Agent User role.

  9. לוחצים על עריכת המשתמש הראשי.

  10. בקטע Kubernetes Engine Host Service Agent User, לוחצים על הסמל כדי להסיר את התפקיד.

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

gcloud

  1. מסירים את התפקיד Host Service Agent User מחשבון השירות של GKE של פרויקט השירות הראשון:

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
        --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
        --role roles/container.hostServiceAgentUser
    
  2. מסירים את התפקיד Host Service Agent User מחשבון השירות של GKE בפרויקט השירות השני:

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
        --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
        --role roles/container.hostServiceAgentUser
    

פתרון בעיות

בקטעים הבאים מוסבר איך לפתור בעיות נפוצות באשכולות של VPC משותף.

שגיאה: קבלת המטא-נתונים מפרויקט הרשת נכשלה

ההודעה הבאה היא שגיאה נפוצה כשעובדים עם אשכולות של VPC משותף:

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

השגיאה הזו יכולה להתרחש מהסיבות הבאות:

  • ‫GKE API לא הופעל בפרויקט המארח.

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

  • לחשבון השירות של GKE בפרויקט המארח אין את התפקיד Kubernetes Engine Service Agent ‏ (container.serviceAgent) בפרויקט המארח. יכול להיות שהקישור הוסר בטעות.

  • לחשבון השירות של GKE בפרויקט השירות אין את התפקיד Host Service Agent User (משתמש של סוכן שירות מארח) בפרויקט המארח.

כדי לפתור את הבעיה, צריך לבדוק אם חשבון השירות של GKE בפרויקט המארח קיים.

אם חשבון השירות לא קיים, מבצעים את הפעולות הבאות:

  • אם GKE API לא מופעל בפרויקט המארח, צריך להפעיל אותו. הפעולה הזו יוצרת את חשבון השירות של GKE בפרויקט המארח ומקצה לחשבון השירות של GKE בפרויקט המארח את התפקיד סוכן השירות של Kubernetes Engine (container.serviceAgent) בפרויקט המארח.

  • אם GKE API מופעל בפרויקט המארח, המשמעות היא שחשבון השירות של GKE בפרויקט המארח נמחק או שאין לו את התפקיד Kubernetes Engine Service Agent (container.serviceAgent) בפרויקט המארח. כדי לשחזר את חשבון השירות של GKE או את קישור התפקיד, צריך להשבית את GKE API ואז להפעיל אותו מחדש. מידע נוסף זמין במאמר שגיאה 400 או 403: חסרות הרשאות עריכה בחשבון.

בעיה: קישוריות

אם אתם נתקלים בבעיות קישוריות בין מכונות וירטואליות של Compute Engine שנמצאות באותה רשת של ענן וירטואלי פרטי (VPC) או בין שתי רשתות VPC שמקושרות באמצעות קישור בין רשתות VPS שכנות (peering), תוכלו לעיין במאמר פתרון בעיות בקישוריות בין מופעים של מכונות וירטואליות (VM) עם כתובות IP פנימיות במסמכי הענן הווירטואלי הפרטי (VPC).

בעיה: אובדן מנות

אם אתם נתקלים בבעיות של אובדן חבילות כשאתם שולחים תעבורה מאשכול לכתובת IP חיצונית באמצעות Cloud NAT,‏ VPC-native clusters או IP masquerade agent, כדאי לעיין במאמר פתרון בעיות של אובדן חבילות ב-Cloud NAT מאשכול.

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