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

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

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

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

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

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

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

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

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

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

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

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

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

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

שם שקל להבין ‫מזהה פרויקט
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. נכנסים אל הדף של Kubernetes Engine API במסוף Google Cloud :

    עוברים אל הדף Kubernetes Engine API

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

  3. אם הכיתוב API enabled מופיע בכותרת הדף, סימן ש-GKE API מופעל. אם לא מופיעה האפשרות API enabled, לוחצים על הלחצן 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 range, מזינים 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.

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

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

בטבלה הבאה מפורטים השמות של סוכני השירות של 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

הפעלת 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. לוחצים שוב על הוספת פריט ובוחרים את פרויקט השירות השני.

  9. לוחצים על Continue. מוצג הקטע Grant access.

  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.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.
    4. לוחצים על Save.

  6. בקטע Individual subnet access, מבטלים את הסימון בתיבה tier-1.

הסרת סוכני שירות מ-tier-2

  1. בקטע Individual subnet access, בוחרים באפשרות tier-2.
  2. בחלונית ההרשאות, בקטע Role/Principal, מרחיבים את Compute Network User.
  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.
    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 agent 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 Compute Network User tier-1
SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com Compute Network User tier-1
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com Compute Network User tier-2
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com Compute Network User tier-2

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

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

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

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

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

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

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

חבר תפקיד משאב
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com Compute Network User רשת משנה ספציפית או פרויקט מארח שלם
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com משתמש Data Agent User של המארח סוכן שירות 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. בקטע Services secondary CIDR range (טווח CIDR משני של שירותים), בוחרים באפשרות tier-1-services (שירותים ברמה 1).

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

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

  1. כשהיצירה תושלם, יוצג הדף Cluster details.
  2. לוחצים על הכרטיסייה Nodes (צמתים).
  3. בקטע Node Pools, לוחצים על default-pool.
  4. בקטע קבוצות של מופעים, לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה, 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. בקטע אפשרויות מתקדמות של רשת, באפשרות טווח CIDR משני של Pod, בוחרים באפשרות tier-2-pods.

  12. בשדה Service secondary CIDR range (טווח CIDR משני של השירות), בוחרים באפשרות tier-2-services (שירותים ברמה 2).

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

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

  1. כשהיצירה תושלם, יוצג הדף Cluster details.
  2. לוחצים על הכרטיסייה Nodes (צמתים).
  3. בקטע Node Pools, לוחצים על default-pool.
  4. בקטע קבוצות של מופעים, לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה, 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. בשדה כיוון התנועה, בוחרים באפשרות תנועה נכנסת (ingress).

  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. בדף Cluster details, לוחצים על הכרטיסייה Nodes.

  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 (Internet Control Message Protocol).

  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 במסוף 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. בתפריט הנפתח רשת, בוחרים את רשת ה-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 User משני פרויקטי השירות.

המסוף

  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 התפקיד 'משתמש סוכן שירות מארח של Kubernetes Engine' הוקצה ל.

  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 Service Agent ‏ (container.serviceAgent) בפרויקט המארח. יכול להיות שהקישור הוסר בטעות.

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

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

אם סוכן השירות לא קיים, צריך לבצע את הפעולות הבאות:

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

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

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

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

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

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

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