הגדרת אשכולות עם 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 או Google Cloud המסוף.

המסוף

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

    חזרה לדף הבית

  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 באמצעות Google Cloud המסוף או Google Cloud CLI.

המסוף

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

    כניסה אל 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 במסוף Google Cloud .

    מעבר לרשתות 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.iam.gserviceaccount.com
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
Google APIs SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com

הפעלת Shared VPC והקצאת תפקידים

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

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

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

המסוף

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

    מעבר ל-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. יופיע הקטע Grant access.

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

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

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

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

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

  1. בקטע Individual subnet access (גישה לרשת משנה ספציפית), בוחרים באפשרות tier-1 (רמה 1) ולוחצים על Show Permissions Panel (הצגת חלונית ההרשאות).
  2. בחלונית ההרשאות, בקטע תפקיד/גורם ראשי, מרחיבים את משתמש ברשת Compute.
  3. חיפוש של SERVICE_PROJECT_2_NUM.
  4. מוחקים את כל חשבונות השירות ששייכים לפרויקט השירות השני. כלומר, מוחקים את חשבונות השירות שמכילים את SERVICE_PROJECT_2_NUM.

  5. מוודאים שחשבונות השירות הבאים של פרויקט השירות הראשון מופיעים ברשימה עם התפקיד Compute Network User:

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

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

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

  6. בקטע Individual subnet access [גישה לרשתות משנה נפרדות], מבטלים את הסימון בתיבה tier-1 [רמה 1].

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

  1. בקטע Individual subnet access, בוחרים באפשרות 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.iam.gserviceaccount.com
    • SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com
    • SERVICE_PROJECT_2_NUM-compute@developer.iam.gserviceaccount.com

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

    1. לוחצים על Add Principal (הוספת גורם ראשי).
    2. מזינים את השם של חשבון השירות בשדה New principals.
    3. בקטע הקצאת תפקידים, בוחרים באפשרות Compute Network User.
    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.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.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.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.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 במסוף Google Cloud .

    כניסה ל-IAM

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

  3. לוחצים על Grant access ומזינים את החשבון הראשי של חשבון השירות של פרויקט השירות ב-GKE,‏ service-SERVICE_PROJECT_NUM@container-engine-robot.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.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 במסוף Google Cloud .

    לדף Roles

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

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

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

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

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

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

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

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

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

    כניסה ל-IAM

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

  3. לוחצים על Grant access ומזינים את שם המשתמש הראשי של חשבון השירות של GKE בפרויקט השירות, service-SERVICE_PROJECT_NUM@container-engine-robot.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.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.iam.gserviceaccount.com משתמש ברשת מחשוב tier-1
SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com משתמש ברשת מחשוב tier-1
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com משתמש ברשת מחשוב tier-2
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com משתמש ברשת מחשוב tier-2

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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.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.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

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

כשיוצרים אשכול, צריך לציין רשת משנה ואת טווחי כתובות ה-IP המשניות שישמשו את ה-Pods והשירותים של האשכול. יכולות להיות כמה סיבות לכך שטווח כתובות IP לא יהיה זמין לשימוש. כשיוצרים את האשכול באמצעות מסוף Google Cloud או ה-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 או המסוף Google Cloud .

המסוף

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

    מעבר אל 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 או מסוף Google Cloud .

המסוף

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

    מעבר אל 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. בקטע אפשרויות מתקדמות של רשת, בשדה Pod secondary CIDR range (טווח CIDR משני של Pod), בוחרים באפשרות tier-2-pods.

  12. בשדה טווח CIDR משני של שירות, בוחרים באפשרות 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 במסוף Google Cloud .

    כניסה לדף Firewall

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

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

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

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

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

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

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

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

  10. בשדה Source IP ranges (טווחים של כתובות 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 במסוף Google Cloud .

    מעבר אל 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" למשאב ה-Ingress. תמיד אפשר להסיר את ההערה הזו כדי להפעיל את ההשתקה.

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

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

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

  • compute.networks.get

  • compute.networks.updatePeering

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

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

המסוף

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

    מעבר אל 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. ברשימה הנפתחת Network, בוחרים את רשת ה-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 במסוף Google Cloud .

    מעבר אל 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 משותף במסוף Google Cloud .

    מעבר ל-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 במסוף Google Cloud .

    כניסה לדף 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 במסוף Google Cloud .

    מעבר לרשתות 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 במסוף Google Cloud .

    כניסה לדף IAM

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

  3. מסמנים את התיבה Include Google-provided role grants.

  4. ברשימת החברים, בוחרים בשורה שבה מוצג service-SERVICE_PROJECT_1_NUM@container-engine-robot.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.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.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.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 ‏ (container.serviceAgent) בפרויקט המארח. יכול להיות שהקישור הוסר בטעות.

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

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

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

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

  • אם GKE API מופעל בפרויקט המארח, המשמעות היא שחשבון השירות של GKE בפרויקט המארח נמחק או שאין לו את התפקיד סוכן שירות של Kubernetes Engine (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 מאשכול.

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