במדריך הזה מוסבר איך ליצור שני אשכולות Google Kubernetes Engine (GKE) בפרויקטים נפרדים, שמשתמשים ב-VPC משותף. מידע כללי על רישות ב-GKE זמין במאמר סקירה כללית על רשתות.
בדוגמאות במדריך הזה מוגדרת התשתית של אפליקציית אינטרנט דו-שכבתית, כפי שמתואר בסקירה הכללית על VPC משותף.
למה כדאי להשתמש ב-VPC משותף עם GKE
ב-VPC משותף, אתם מגדירים פרויקט אחד כפרויקט מארח, ויכולים לצרף אליו פרויקטים אחרים שנקראים פרויקטים של שירותים. יוצרים רשתות, תת-רשתות, טווחי כתובות משניים, כללי חומת אש ומשאבי רשת אחרים בפרויקט המארח. לאחר מכן משתפים את רשתות המשנה שנבחרו, כולל טווחים משניים, עם פרויקטים של שירותים. רכיבים שפועלים בפרויקט שירות יכולים להשתמש ב-VPC המשותף כדי לתקשר עם רכיבים שפועלים בפרויקטים אחרים של שירותים.
אפשר להשתמש ב-VPC משותף עם אשכולות במצב Autopilot ועם אשכולות סטנדרטיים אזוריים ואזוריים.
בקטרי סטנדרט שמשתמשים ב-VPC משותף אי אפשר להשתמש ברשתות מדור קודם, וחייבת להיות מופעלת בהם הפניית תנועה מקורית של VPC. באשכולות Autopilot, ניתוב התנועה מותאם תמיד ל-VPC.
אפשר להגדיר רשת VPC משותפת כשיוצרים אשכול חדש. GKE לא תומך בהמרת אשכולות קיימים למודל של רשת VPC משותפת.
ב-VPC משותף, חלות מכסות ומגבלות מסוימות. לדוגמה, יש מכסה למספר הרשתות בפרויקט, ויש הגבלה על מספר הפרויקטים של השירות שאפשר לצרף לפרויקט המארח. פרטים נוספים זמינים במאמר בנושא מכסות ומגבלות.
לפני שמתחילים
לפני שמתחילים להגדיר אשכול עם VPC משותף:
- מוודאים שיש לכם Cloud de Confiance by S3NS ארגון.
- מוודאים שיש לארגון שלושה Cloud de Confiance by S3NS פרויקטים.
- חשוב לוודא שאתם מכירים את המושגים של VPC משותף, כולל התפקידים השונים של ניהול זהויות והרשאות גישה (IAM) שמשמשים ב-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 המסוף.
המסוף
נכנסים לדף Home במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את הפרויקט שבחרתם להיות הפרויקט המארח.
בקטע Project info (פרטי הפרויקט) אפשר לראות את שם הפרויקט, מזהה הפרויקט ומספר הפרויקט. כדאי לרשום את המזהה והמספר כדי להשתמש בהם בהמשך.
מבצעים את אותן פעולות לכל אחד מהפרויקטים שבחרתם כפרויקטים של שירות.
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.
המסוף
נכנסים לדף APIs & Services במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר כפרויקט המארח.
אם
Kubernetes Engine APIמופיע ברשימת ממשקי ה-API, הוא כבר מופעל ואין צורך לעשות דבר. אם הוא לא מופיע ברשימה, לוחצים על Enable APIs and Services. חיפוש שלKubernetes Engine API. לוחצים על הכרטיס Kubernetes Engine API ואז על Enable.חוזרים על השלבים האלה לכל פרויקט שבחרתם כפרויקט שירות. יכול להיות שיעבור קצת זמן עד להשלמת כל פעולה.
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
יצירת רשת ושתי רשתות משנה
בקטע הזה תבצעו את המשימות הבאות:
- בפרויקט המארח, יוצרים רשת בשם
shared-net. - יוצרים שתי רשתות משנה בשמות
tier-1ו-tier-2. - לכל תת-רשת, יוצרים שני טווחים משניים של כתובות: אחד לשירותים ואחד ל-Pods.
המסוף
נכנסים לדף VPC networks במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
לוחצים על add_box יצירת רשת VPC.
בשדה Name (שם), מזינים
shared-net.בקטע Subnet creation mode, בוחרים באפשרות Custom.
הוספת tier-1
- בקטע Subnets בתיבה New subnet, בשדה Name, מזינים
tier-1. - בשדה Region, בוחרים אזור.
- בקטע IP stack type, בוחרים באפשרות IPv4 (single-stack).
- בקטע טווח IPv4, מזינים
10.0.4.0/22כטווח הכתובות הראשי של רשת המשנה. לוחצים על הוספת טווח משני של כתובות IPv4.
- בשדה שם טווח תת-הרשת, מזינים
tier-1-services. - בשדה Secondary IPv4 range, מזינים
10.0.32.0/20.
- בשדה שם טווח תת-הרשת, מזינים
לוחצים על סיום.
לוחצים על הוספת טווח משני של כתובות IPv4.
- בשדה שם טווח תת-הרשת, מזינים
tier-1-pods. - בשדה Secondary IPv4 range, מזינים
10.4.0.0/14.
- בשדה שם טווח תת-הרשת, מזינים
לוחצים על סיום.
הוספת tier-2
- לוחצים על הוספת רשת משנה.
- בשדה Name (שם), מזינים
tier-2. - בשדה Region, בוחרים את אותו אזור שבחרתם עבור רשת המשנה הקודמת.
- בקטע טווח IPv4, מזינים
172.16.4.0/22כטווח הכתובות הראשי של רשת המשנה. לוחצים על הוספת טווח משני של כתובות IPv4.
- בשדה שם טווח תת-הרשת, מזינים
tier-2-services. - בשדה Secondary IPv4 range, מזינים
172.16.16.0/20.
- בשדה שם טווח תת-הרשת, מזינים
לוחצים על סיום.
לוחצים על הוספת טווח משני של כתובות IPv4.
- בשדה שם טווח תת-הרשת, מזינים
tier-2-pods. - בשדה Secondary IPv4 range, מזינים
172.20.0.0/14.
- בשדה שם טווח תת-הרשת, מזינים
לוחצים על סיום.
גוללים לחלק התחתון של הדף ולוחצים על יצירה.
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) בארגון או בתיקייה אחת או יותר.
בקטע הזה תבצעו את המשימות הבאות:
- בפרויקט המארח, מפעילים VPC משותף.
- מצרפים את שני פרויקטי השירות לפרויקט המארח.
- צריך להסיר את התפקיד
Compute Network Userמחשבונות השירות ששייכים לפרויקטים של השירותים, או להעניק להם אותו. אם משתמשים במסוףCloud de Confiance , מסירים את התפקיד. אם משתמשים ב-CLI של gcloud, מקצים את התפקיד.
המסוף
נכנסים לדף VPC משותף במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
לוחצים על הגדרת VPC משותף. מוצג המסך הפעלת פרויקט מארח.
לוחצים על הפעלה והמשך. מוצג הקטע Attach service projects and select principals (צירוף פרויקטים של שירות ובחירת גורמים ראשיים).
בקטע Kubernetes Engine access (גישה ל-Kubernetes Engine), בוחרים באפשרות Enabled (מופעל).
בקטע Select projects to attach (בחירת פרויקטים לצירוף), לוחצים על add_boxAdd item (הוספת פריט).
בשדה Select project, לוחצים על Select ובוחרים את פרויקט השירות הראשון.
לוחצים שוב על add_box Add item (הוספת פריט) ובוחרים את פרויקט השירות השני.
לוחצים על Continue. יופיע הקטע הענקת גישה.
בקטע מצב גישה, בוחרים באפשרות גישה לרשת משנה מסוימת.
בקטע Subnets with individual subnet access, גוללים ברשימה ובוחרים באפשרויות tier-1 ו-tier-2.
לוחצים על Save. יוצג דף חדש.
בוחרים באפשרות הצגת רשתות משנה שיש להן מדיניות IAM נפרדת בלבד.
הסרה של חשבונות שירות מ-tier-1
- בקטע גישה לרשת משנה ספציפית, בוחרים באפשרות רמה 1 ולוחצים על הצגת חלונית ההרשאות.
- בחלונית ההרשאות, בקטע תפקיד/גורם ראשי, מרחיבים את משתמש ברשת Compute.
- חיפוש של
SERVICE_PROJECT_2_NUM. - מוחקים את כל חשבונות השירות ששייכים לפרויקט השירות השני. כלומר, מוחקים את חשבונות השירות שמכילים את
SERVICE_PROJECT_2_NUM. מוודאים שחשבונות השירות הבאים של פרויקט השירות הראשון מופיעים ברשימה עם התפקיד Compute Network User:
service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.comSERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.comSERVICE_PROJECT_1_NUM-compute@developer.s3ns.iam.gserviceaccount.com
אם חשבון שירות לא מופיע ברשימה, צריך להוסיף אותו באופן הבא:
- לוחצים על add_box Add Principal (הוספת גורם ראשי).
- בשדה New principals, מזינים את השם של חשבון השירות.
- בקטע הקצאת תפקידים, בוחרים באפשרות משתמש ברשת מחשוב.
- לוחצים על Save.
בקטע Individual subnet access [גישה לרשתות משנה נפרדות], מבטלים את הסימון של התיבה tier-1 [רמה 1].
הסרה של חשבונות שירות מ-tier-2
- בקטע גישה לרשתות משנה ספציפיות, בוחרים באפשרות tier-2.
- בחלונית ההרשאות, בקטע תפקיד/גורם ראשי, מרחיבים את משתמש ברשת Compute.
- חיפוש של
SERVICE_PROJECT_1_NUM. - מוחקים את כל חשבונות השירות ששייכים לפרויקט השירות הראשון. כלומר, מוחקים את כל חשבונות השירות שמכילים את
SERVICE_PROJECT_1_NUM. מוודאים שחשבונות השירות הבאים של פרויקט השירות השני מופיעים ברשימה עם התפקיד Compute Network User:
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.comSERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.comSERVICE_PROJECT_2_NUM-compute@developer.s3ns.iam.gserviceaccount.com
אם חשבון שירות לא מופיע ברשימה, צריך להוסיף אותו באופן הבא:
- לוחצים על add_box Add Principal (הוספת גורם ראשי).
- מזינים את השם של חשבון השירות בשדה New principals.
- בקטע הקצאת תפקידים, בוחרים באפשרות משתמש ברשת מחשוב.
- לוחצים על Save.
gcloud
מפעילים VPC משותף בפרויקט המארח. הפקודה שבה משתמשים תלויה בתפקיד האדמין הנדרש שיש לכם.
אם יש לכם תפקיד אדמין ל-VPC משותף ברמת הארגון:
gcloud compute shared-vpc enable HOST_PROJECT_IDאם יש לכם תפקיד אדמין של VPC משותף ברמת התיקייה:
gcloud beta compute shared-vpc enable HOST_PROJECT_IDמצרפים את פרויקט השירות הראשון לפרויקט המארח:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \ --host-project HOST_PROJECT_IDמצרפים את פרויקט השירות השני לפרויקט המארח:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \ --host-project HOST_PROJECT_IDמקבלים את מדיניות ה-IAM עבור רשת המשנה
tier-1:gcloud compute networks subnets get-iam-policy tier-1 \ --project HOST_PROJECT_ID \ --region COMPUTE_REGIONהפלט מכיל את השדה
etag. רושמים את הערךetag.יוצרים קובץ בשם
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שרשמתם קודם.מגדירים את מדיניות ה-IAM עבור רשת המשנה
tier-1:gcloud compute networks subnets set-iam-policy tier-1 \ tier-1-policy.yaml \ --project HOST_PROJECT_ID \ --region COMPUTE_REGIONמקבלים את מדיניות ה-IAM עבור רשת המשנה
tier-2:gcloud compute networks subnets get-iam-policy tier-2 \ --project HOST_PROJECT_ID \ --region COMPUTE_REGIONהפלט מכיל את השדה
etag. רושמים את הערךetag.יוצרים קובץ בשם
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שרשמתם קודם.מגדירים את מדיניות ה-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בפרויקט המארח.
המסוף
נכנסים לדף IAM במסוף Cloud de Confiance .
בוחרים את פרויקט המארח.
לוחצים על Grant access ומזינים את החשבון הראשי של חשבון השירות של פרויקט השירות ב-GKE,
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.בוחרים את התפקיד
Compute Security Adminמהרשימה הנפתחת.לוחצים על 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 שצוינו קודם:
נכנסים לדף Roles במסוף Cloud de Confiance .
מהרשימה הנפתחת בחלק העליון של הדף, בוחרים את פרויקט המארח.
לוחצים על Create Role.
מזינים את השדות Title, Description, ID ו-Role launch stage של התפקיד. אי אפשר לשנות את שם התפקיד אחרי שיוצרים אותו.
לוחצים על Add Permissions.
מסננים לפי
compute.networksובוחרים את הרשאות ה-IAM שצוינו קודם.אחרי שבוחרים את כל ההרשאות הנדרשות, לוחצים על הוספה.
לוחצים על יצירה.
מקצים לחשבון השירות של GKE בפרויקט השירות את התפקיד המותאם אישית החדש שנוצר בפרויקט המארח:
נכנסים לדף IAM במסוף Cloud de Confiance .
בוחרים את פרויקט המארח.
לוחצים על Grant access ומזינים את שם המשתמש (principal) של חשבון השירות של GKE בפרויקט השירות,
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.מסננים לפי שם התפקיד החדש בהתאמה אישית ובוחרים אותו.
לוחצים על Save.
gcloud
יוצרים תפקיד בהתאמה אישית בפרויקט המארח שכולל את הרשאות ה-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מקצים לחשבון השירות של 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
בפרויקט הראשון, צריך להעניק את התפקיד 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בפרויקט השני, מקצים את התפקיד 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 .
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .
בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.
לוחצים על add_box יצירה.
בקטע Autopilot או Standard, לוחצים על Configure (הגדרה).
בשדה Name (שם), מזינים
tier-1-cluster.בתפריט הנפתח Region, בוחרים את אותו אזור שבו השתמשתם עבור רשתות המשנה.
בחלונית הניווט, לוחצים על Networking (רשת).
בקטע Cluster networking, לוחצים על Networks shared with me.
בשדה Network, בוחרים באפשרות shared-net.
בקטע Node subnet, בוחרים באפשרות tier-1.
בקטע אפשרויות מתקדמות של רשת, בשדה טווח CIDR משני של Pod, בוחרים באפשרות tier-1-pods.
בשדה טווח CIDR משני של שירותים, בוחרים באפשרות tier-1-services.
לוחצים על יצירה.
אם יצרתם אשכול רגיל, תוכלו לראות שהצמתים של האשכול נמצאים בטווח הכתובות הראשי של רשת המשנה ברמה 1, כך:
- כשהיצירה תושלם, יוצג הדף Cluster details.
- לוחצים על הכרטיסייה Nodes.
- בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל).
- בקטע Instance groups (קבוצות של מופעים), לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה, gke-tier-1-cluster-default-pool-5c5add1f-grp.
- ברשימת המופעים, מוודאים שכתובות ה-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 .
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט השירות השני.
לוחצים על add_box יצירה.
בקטע 'רגיל' או 'טייס אוטומטי', לוחצים על הגדרה.
בשדה Name (שם), מזינים
tier-2-cluster.בתפריט הנפתח Region, בוחרים את אותו אזור שבו השתמשתם עבור רשתות המשנה.
בחלונית הניווט, לוחצים על Networking (רשת).
בקטע Cluster networking, לוחצים על Networks shared with me.
בשדה Network, בוחרים באפשרות shared-net.
בשדה Node subnet, בוחרים באפשרות tier-2.
בקטע אפשרויות מתקדמות של רשת, בשדה טווח CIDR משני של Pod, בוחרים באפשרות tier-2-pods.
בשדה Service secondary CIDR range, בוחרים באפשרות tier-2-services.
לוחצים על יצירה.
אם יצרתם אשכול Standard, תוכלו לראות שהצמתים של האשכול נמצאים בטווח הכתובות הראשי של רשת המשנה ברמה 2, כך:
- כשהיצירה תושלם, יוצג הדף Cluster details.
- לוחצים על הכרטיסייה Nodes.
- בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל).
- בקטע Instance groups (קבוצות של מופעים), לוחצים על השם של קבוצת המופעים שרוצים לבדוק. לדוגמה,
gke-tier-2-cluster-default-pool-5c5add1f-grp. - ברשימת המופעים, מוודאים שכתובות ה-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 לצומת: הסבר על יצירת כלל חומת אש שמאפשר תעבורת נתונים מחוץ לאשכולות באמצעות SSH.
עדכון כלל חומת האש כדי לבצע פינג בין הצמתים: מוסבר איך לעדכן את כלל חומת האש כדי לאפשר תעבורת נתוני ICMP בין האשכולות.
השתמשנו ב-SSH וב-ICMP כדוגמאות, אבל אתם צריכים ליצור כללים בחומת האש שמאפשרים את דרישות הרשת של האפליקציה הספציפית שלכם.
יצירת כלל לחומת האש כדי להפעיל חיבור SSH לצומת
בפרויקט המארח, יוצרים כלל לחומת האש עבור רשת shared-net.
מאפשרים לתנועה להיכנס דרך יציאת TCP 22, וכך אפשר להתחבר לצמתי האשכול באמצעות SSH.
המסוף
נכנסים לדף Firewall במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
בתפריט VPC Networking (רשתות VPC), לוחצים על Create Firewall Rule (יצירת כלל לחומת אש).
בשדה Name (שם), מזינים
my-shared-net-rule.בשדה רשת, בוחרים באפשרות shared-net.
בשדה כיוון התנועה, בוחרים באפשרות תנועה נכנסת.
בקטע פעולה בהתאמה, בוחרים באפשרות אישור.
בקטע יעדים, בוחרים באפשרות כל המופעים ברשת.
בשדה מסנן מקור, בוחרים באפשרות טווח כתובות IP.
בשדה טווחים של כתובות IP של המקור, מזינים
0.0.0.0/0.בקטע פרוטוקולים ויציאות, בוחרים באפשרות פרוטוקולים ויציאות שצוינו. בתיבה, מזינים
tcp:22.לוחצים על יצירה.
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.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .
בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.
לוחצים על tier-1-cluster.
בדף פרטי האשכול, לוחצים על הכרטיסייה צמתים.
בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים.
בקטע Instance groups (קבוצות של מכונות), לוחצים על השם של קבוצת המכונות. לדוגמה, gke-tier-1-cluster-default-pool-faf87d48-grp.
ברשימת המכונות, רושמים את כתובות ה-IP הפנימיות של הצמתים. הכתובות האלה נמצאות בטווח
10.0.4.0/22.באחד מהצמתים, לוחצים על 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 בתוך האזור.
עדכון כלל חומת האש כדי לאפשר תעבורת נתונים בין הצמתים
בחלון שורת הפקודה של SSH, מפעילים את CoreOS Toolbox:
/usr/bin/toolboxבמעטפת של ארגז הכלים, שולחים פינג לאחד מהצמתים האחרים באותו אשכול. לדוגמה:
ping 10.0.4.4הפקודה
pingמצליחה, כי הצומת שלכם והצומת השני נמצאים שניהם בטווח10.0.4.0/22.עכשיו, נסו לבצע פינג לאחד מהצמתים באשכול בפרויקט השירות האחר שלכם. לדוגמה:
ping 172.16.4.3הפעם הפקודה
pingנכשלת, כי כלל חומת האש לא מאפשר תעבורת נתונים של פרוטוקול הודעות הבקרה באינטרנט (ICMP).בשורת פקודה רגילה, לא במעטפת של ארגז הכלים, מעדכנים את כלל חומת האש כדי לאפשר ICMP:
gcloud compute firewall-rules update my-shared-net-rule \ --project HOST_PROJECT_ID \ --allow tcp:22,icmpבמעטפת של ארגז הכלים, שולחים שוב פינג לצומת. לדוגמה:
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.getcompute.networks.updatePeering
בנוסף, צריך לוודא שטווח כתובות ה-IP של מישור הבקרה לא חופף לטווחים שמורים אחרים ברשת המשותפת.
בקטע הזה, יוצרים אשכול שמותאם ל-VPC בשם cluster-vpc ברשת VPC משותפת מוגדרת מראש.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .
לוחצים על add_box יצירה.
בקטע Autopilot או Standard, לוחצים על Configure (הגדרה).
בשדה Name (שם), מזינים
cluster-vpc.בחלונית הניווט, לוחצים על Networking (רשת).
בקטע Cluster networking (רשת של אשכול), מסמנים את התיבה Enable Private nodes (הפעלת צמתים פרטיים).
(אופציונלי ל-Autopilot): מגדירים את טווח כתובות ה-IP של מישור הבקרה ל-
172.16.0.16/28.ברשימה הנפתחת רשת, בוחרים את רשת ה-VPC שיצרתם קודם.
ברשימה הנפתחת Node subnet, בוחרים את רשת המשנה המשותפת שיצרתם קודם.
מגדירים את האשכול לפי הצורך.
לוחצים על יצירה.
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 ברמת הפרויקט.
הסרת המשאבים
אחרי שתסיימו את התרגילים במדריך הזה, תצטרכו לבצע את המשימות הבאות כדי להסיר את המשאבים ולמנוע חיובים לא רצויים בחשבון:
מחיקת האשכולות
מוחקים את שני האשכולות שיצרתם.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .
בבורר הפרויקטים, בוחרים את פרויקט השירות הראשון.
בוחרים באפשרות tier-1-cluster ולוחצים על מחיקה.
בכלי לבחירת פרויקטים, בוחרים את פרויקט השירות השני.
בוחרים באפשרות 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 המשותף בפרויקט המארח.
המסוף
נכנסים לדף VPC משותף במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
לוחצים על השבתת VPC משותף.
מזינים את
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
מחיקת הכללים של חומת האש
מסירים את הכללים של חומת האש שיצרתם.
המסוף
נכנסים לדף Firewall במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
ברשימת הכללים, בוחרים באפשרויות my-shared-net-rule, my-shared-net-rule-2 ו-my-shared-net-rule-3.
לוחצים על 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
מחיקת הרשת המשותפת
מוחקים את הרשת המשותפת שיצרתם.
המסוף
נכנסים לדף VPC networks במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
ברשימת הרשתות, לוחצים על הקישור shared-net.
לוחצים על מחיקת רשת 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
מסירים את תפקידי המשתמש של נציג שירות המארח משני פרויקטי השירות.
המסוף
נכנסים לדף IAM במסוף Cloud de Confiance .
בכלי לבחירת פרויקטים, בוחרים את פרויקט המארח.
בוחרים באפשרות Include Google-provided role grants.
ברשימת החברים, בוחרים את השורה שבה מוצג
service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.comis granted the Kubernetes Engine Host Service Agent User role.לוחצים על edit עריכת המשתמש הראשי.
בקטע Kubernetes Engine Host Service Agent User, לוחצים על הסמל delete כדי להסיר את התפקיד.
לוחצים על Save.
בוחרים את השורה שבה מוצג
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.comis granted the Kubernetes Engine Host Service Agent User role.לוחצים על edit עריכת המשתמש הראשי.
בקטע Kubernetes Engine Host Service Agent User, לוחצים על הסמל delete כדי להסיר את התפקיד.
לוחצים על Save.
gcloud
מסירים את התפקיד 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מסירים את התפקיד 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 מאשכול.
המאמרים הבאים
- סקירה כללית על VPC משותף
- מידע נוסף על הקצאת VPC משותף
- סקירה כללית על רשת GKE
- מידע נוסף על כללים של חומת אש שנוצרו באופן אוטומטי
- כאן מוסבר איך לפתור בעיות בקישוריות בין מופעים של מכונות וירטואליות (VM) עם כתובות IP פנימיות.