יצירת אשכול פרטי

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

הגבלות ומגבלות

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

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

Getting Pod secondary range 'pod' must have a CIDR block larger or equal to /24

ב-GKE אי אפשר לציין טווח קטן מ-/24 ברמת מאגר הצמתים. עם זאת, אפשר לציין טווח קטן יותר ברמת האשכול. אפשר לעשות זאת באמצעות Google Cloud CLI עם הארגומנט --cluster-ipv4-cidr. מידע נוסף זמין במאמר בנושא יצירת אשכול עם טווח CIDR ספציפי.

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

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

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.

• מוודאים שיש לכם את ההרשאה המתאימה ליצירת אשכולות. לכל הפחות, צריך להיות לכם תפקיד אדמין של אשכול Kubernetes Engine.

• מוודאים שיש נתיב ל-Default Internet Gateway.

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

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

• אשכול פרטי בשם private-cluster-0 עם צמתים פרטיים, וללקוחות אין גישה לנקודת הקצה הציבורית.
• רשת בשם my-net-0.
• תת-רשת בשם my-subnet-0.

בשלב הזה, אלה כתובות ה-IP היחידות שיש להן גישה למישור הבקרה:

• הטווח הראשי של my-subnet-0.
• הטווח המשני שמשמש לפודים.

לדוגמה, נניח שיצרתם מכונה וירטואלית בטווח הראשי של my-subnet-0. אחר כך, במכונה הווירטואלית הזו, תוכלו להגדיר את kubectl כך שישתמש בכתובת ה-IP הפנימית של מישור הבקרה.

אם רוצים לגשת למישור הבקרה מחוץ ל-my-subnet-0, צריך לאשר שלפחות טווח כתובות אחד תהיה גישה לנקודת הקצה הפרטית.

נניח שיש לכם מכונה וירטואלית ברשת ברירת המחדל, באותו אזור של האשכול, אבל לא ב-my-subnet-0.

לדוגמה:

• my-subnet-0: 10.0.0.0/22
• טווח משני של Pod: ‏10.52.0.0/14
• כתובת ה-VM: ‏ 10.128.0.3

כדי לאשר ל-VM לגשת למישור הבקרה, אפשר להשתמש בפקודה הזו:

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

יצירת אשכול פרטי עם גישה מוגבלת לנקודת הקצה הציבורית

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

שימוש ברשת משנה שנוצרה באופן אוטומטי

בקטע הזה, יוצרים אשכול פרטי בשם private-cluster-1 שבו GKE יוצר באופן אוטומטי רשת משנה לצומתי האשכול. ברשת המשנה מופעלת גישה פרטית ל-Google. בתת-הרשת,‏ GKE יוצר באופן אוטומטי שני טווחים משניים: אחד בשביל Pod ואחד בשביל Services.

אפשר להשתמש ב-Google Cloud CLI או ב-GKE API.

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster control plane
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

בשלב הזה, אלה כתובות ה-IP היחידות שיש להן גישה למישור הבקרה של האשכול:

• הטווח העיקרי של my-subnet-1.
• הטווח המשני שמשמש ל-Pods.

נניח שיש לכם קבוצת מכונות מחוץ לרשת ה-VPC, עם כתובות בטווח 203.0.113.0/29. אפשר לתת למכונות האלה הרשאה לגשת לנקודת הקצה הציבורית על ידי הזנת הפקודה הבאה:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

עכשיו אלה כתובות ה-IP היחידות שיש להן גישה למישור הבקרה:

• הטווח העיקרי של my-subnet-1.
• הטווח המשני שמשמש ל-Pods.
• טווחי כתובות שאישרתם, למשל 203.0.113.0/29.

שימוש ברשת משנה בהתאמה אישית

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

• אשכול פרטי בשם private-cluster-2.
• רשת בשם my-net-2.
• רשת משנה בשם my-subnet-2, עם טווח ראשי 192.168.0.0/20, לצומתי האשכול. לרשת המשנה יש את טווחי הכתובות המשניים הבאים:
  • ‫my-pods לכתובות ה-IP של הפודים.
  • ‫my-services לכתובות ה-IP של השירות.

gcloud compute networks create my-net-2 \
    --subnet-mode custom

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-2 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
    --enable-private-ip-google-access

בשלב הזה, אלה כתובות ה-IP היחידות שיש להן גישה למישור הבקרה:

• הטווח הראשי של my-subnet-2.
• הטווח המשני my-pods.

נניח שיש לכם קבוצת מכונות מחוץ ל-my-net-2, עם כתובות בטווח 203.0.113.0/29. כדי לתת למכונות האלה הרשאת גישה לנקודת הקצה הציבורית, מזינים את הפקודה הבאה:

gcloud container clusters update private-cluster-2 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

בשלב הזה, אלה כתובות ה-IP היחידות שיש להן גישה למישור הבקרה:

• הטווח הראשי של my-subnet-2.
• הטווח המשני my-pods.
• טווח כתובות שאושר על ידכם, לדוגמה, 203.0.113.0/29.

שימוש ב-Cloud Shell כדי לגשת לאשכול פרטי

אם הפעלתם נקודת קצה פרטית, אתם לא יכולים לגשת למישור הבקרה של GKE באמצעות Cloud Shell.

אם אתם רוצים להשתמש ב-Cloud Shell כדי לגשת לאשכול, אתם צריכים להוסיף את כתובת ה-IP החיצונית של Cloud Shell לרשימת הרשתות המורשות של האשכול.

לשם כך:

1. בחלון שורת הפקודה של Cloud Shell, משתמשים בפקודה dig כדי למצוא את כתובת ה-IP החיצונית של Cloud Shell:

   dig +short myip.opendns.com @resolver1.opendns.com
   

2. מוסיפים את הכתובת החיצונית של Cloud Shell לרשימת הרשתות המורשות של האשכול:

   gcloud container clusters update CLUSTER_NAME \
       --enable-master-authorized-networks \
       --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
   

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

   • ‫CLUSTER_NAME: שם האשכול.

   • ‫EXISTING_AUTH_NETS: כתובות ה-IP של הרשימה הקיימת של הרשתות המורשות. אפשר למצוא את הרשתות המורשות במסוף או באמצעות הפקודה הבאה:

     gcloud container clusters describe CLUSTER_NAME --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
     

   • ‫SHELL_IP: כתובת ה-IP החיצונית של Cloud Shell.

3. מקבלים פרטי כניסה כדי להשתמש ב-kubectl לגישה לאשכול:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --internal-ip
   

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

4. משתמשים ב-kubectl ב-Cloud Shell כדי לגשת לאשכול:

   kubectl get nodes
   

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

   NAME                                               STATUS   ROLES    AGE    VERSION
   gke-cluster-1-default-pool-7d914212-18jv   Ready    <none>   104m   v1.21.5-gke.1302
   gke-cluster-1-default-pool-7d914212-3d9p   Ready    <none>   104m   v1.21.5-gke.1302
   gke-cluster-1-default-pool-7d914212-wgqf   Ready    <none>   104m   v1.21.5-gke.1302
   

יצירת אשכול פרטי עם גישה בלתי מוגבלת לנקודת הקצה הציבורית

בקטע הזה, יוצרים אשכול פרטי שבו כל כתובת IP יכולה לגשת למישור הבקרה.

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

בקטע הזה מוסבר איך להוסיף כלל של חומת אש לאשכול. כברירת מחדל, כללי חומת האש מגבילים את מישור הבקרה של האשכול כך שהוא יכול ליזום רק חיבורי TCP לצמתים ול-Pods ביציאות 443 (HTTPS) ו-10250 (kubelet). יכול להיות שתצטרכו להוסיף כללים לחומת האש כדי לאפשר גישה ליציאות נוספות, אם אתם משתמשים בתכונות מסוימות של Kubernetes. אל תיצרו כללים של חומת אש או כללים של מדיניות חומת אש היררכית עם עדיפות גבוהה יותר מכללי חומת האש שנוצרו באופן אוטומטי.

תכונות של Kubernetes שדורשות כללים נוספים של חומת אש כוללות:

• תגובות לפעולות של משתמשים (webhooks) לאישור
• שרתי API מצטברים
• המרת Webhook
• הגדרת ביקורת דינמית
• באופן כללי, כל API שיש לו שדה ServiceReference דורש כללי חומת אש נוספים.

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

• היציאה שצוינה של כל צומת (hostPort).
• היציאה שצוינה של כל Pod שפועל בצמתים האלה.
• היציאה שצוינה לכל שירות שפועל בצמתים האלה.

מידע נוסף על כללים של חומת אש זמין במאמר כללים של חומת אש במסמכי התיעוד של Cloud Load Balancing.

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

צפייה בבלוק ה-CIDR של מישור הבקרה

כדי להוסיף כלל לחומת האש, צריך את בלוק ה-CIDR של מישור הבקרה של האשכול.

gcloud container clusters describe CLUSTER_NAME

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

צריך לציין את היעד (במקרה הזה, צומתי היעד) שבו משתמשים כללי חומת האש הקיימים של האשכול.

gcloud compute firewall-rules list \
    --filter 'name~^gke-CLUSTER_NAME' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

הוספת כלל לחומת האש

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges CONTROL_PLANE_RANGE \
    --rules PROTOCOL:PORT \
    --target-tags TARGET

--project HOST_PROJECT_ID
--network NETWORK_ID

איך מוודאים שלצמתים אין כתובות IP חיצוניות

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

kubectl get nodes --output wide

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS
Ready      v1.8.7-gke.1                Container-Optimized OS
Ready      v1.8.7-gke.1                Container-Optimized OS

אימות השימוש החוזר בקישור בין רשתות VPC שכנות באשכול

כל אשכול GKE עם צמתים פרטיים שנוצר אחרי 15 בינואר 2020 משתמש מחדש בחיבורי קישור בין רשתות שכנות (peering) של רשת VPC.

אתם יכולים לבדוק אם האשכול הפרטי שלכם משתמש מחדש בחיבורי VPC Network Peering באמצעות gcloud CLI או Cloud de Confiance המסוף.

gcloud container clusters describe CLUSTER_NAME \
    --format="value(privateClusterConfig.peeringName)"

הגדרות מתקדמות של אשכולות

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

הענקת גישה לאינטרנט מחוץ לצמתים פרטיים

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

Cloud Router מאפשר לכל הצמתים באזור להשתמש ב-Cloud NAT לכל טווחי כתובות ה-IP הראשיים והחלופיים. בנוסף, הוא מקצה באופן אוטומטי את כתובות ה-IP החיצוניות לשער ה-NAT.

הוראות ליצירה ולהגדרה של Cloud Router מופיעות במאמר יצירת הגדרת Cloud NAT באמצעות Cloud Router במסמכי Cloud NAT.

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

במאמר יצירת אשכול פרטי ב-VPC משותף מוסבר איך יוצרים אשכול פרטי ברשת VPC משותפת.

פריסת אפליקציה בקונטיינר של Windows Server

במסמכי התיעוד של מאגר הצמתים של Windows מוסבר איך פורסים אפליקציית קונטיינר של Windows Server באשכול עם צמתים פרטיים.

גישה לנקודת הקצה הפרטית של מישור הבקרה באופן גלובלי

נקודת הקצה הפרטית של מישור הבקרה מיושמת על ידי מאזן עומסי רשת פנימי להעברת נתונים ללא שינוי ברשת ה-VPC של מישור הבקרה. לקוחות פנימיים או לקוחות שמחוברים דרך מנהרות Cloud VPN וצירופים ל-VLAN של Cloud Interconnect יכולים לגשת למאזני עומסי רשת פנימיים ב-Passthrough.

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

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

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

הפעלת גישה גלובלית לנקודת קצה פרטית של מישור הבקרה

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

• במקרים של אשכולות רגילים, אפשר להשתמש ב-Google Cloud CLI או במסוף Cloud de Confiance .
• במקרים של אשכולות Autopilot, אפשר להשתמש במשאב google_container_cluster Terraform.

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --enable-master-global-access

gcloud container clusters update CLUSTER_NAME \
    --enable-master-global-access

אימות של גישה גלובלית לנקודת קצה פרטית של מישור הבקרה

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

gcloud container clusters describe CLUSTER_NAME

הפלט כולל קטע של privateClusterConfig שבו אפשר לראות את הסטטוס של masterGlobalAccessConfig.

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

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

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

• רשת מקומית שמחוברת לרשת ה-VPC של האשכול באמצעות מנהרות Cloud VPN או קבצים מצורפים של Cloud Interconnect VLAN
• רשת VPC אחרת שמחוברת לרשת ה-VPC של האשכול באמצעות מנהרות Cloud VPN

בתרשים הבא מוצג נתיב ניתוב בין רשת מקומית לבין צמתים של מישור הבקרה של GKE:

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

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

   gcloud container clusters describe CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --format="yaml(network, privateClusterConfig)"
   

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

   • ‫CLUSTER_NAME: השם של האשכול.
   • COMPUTE_LOCATION: המיקום של האשכול ב-Compute Engine

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

   • ‫network: השם או ה-URI של רשת ה-VPC של האשכול.
   • ‫privateEndpoint: כתובת ה-IPv4 של נקודת הקצה הפרטית של מישור הבקרה או טווח ה-CIDR של IPv4 שכולל אותה (masterIpv4CidrBlock).
   • ‫peeringName: השם של החיבור ב-VPC Network Peering שמשמש לחיבור בין רשת ה-VPC של האשכול לבין רשת ה-VPC של מישור הבקרה.

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

   network: cluster-network
   privateClusterConfig:
     enablePrivateNodes: true
     masterGlobalAccessConfig:
       enabled: true
     masterIpv4CidrBlock: 172.16.1.0/28
     peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
     privateEndpoint: 172.16.1.2
     publicEndpoint: 34.68.128.12
   

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

3. יוצרים נתיב לכתובת ה-IP של privateEndpoint או לטווח כתובות ה-IP של masterIpv4CidrBlock ברשת השנייה. מכיוון שכתובת ה-IP הפרטית של נקודת הקצה של מישור הבקרה תמיד נכללת בטווח כתובות ה-IPv4‏ masterIpv4CidrBlock, יצירת מסלול לכתובת ה-IP‏ privateEndpoint או לטווח שכולל אותה מספקת נתיב לחבילות מהרשת השנייה לנקודת הקצה הפרטית של מישור הבקרה אם:

   • הרשת השנייה מתחברת לרשת ה-VPC של האשכול באמצעות צירופים ל-VLAN של Cloud Interconnect או מנהרות Cloud VPN שמשתמשות בנתיבים דינמיים (BGP): משתמשים בנתיב מותאם אישית שפורסם ב-Cloud Router. מידע נוסף זמין במאמר פרסום טווחי כתובות בהתאמה אישית במסמכי התיעוד של Cloud Router.

   • הרשת השנייה מתחברת לרשת ה-VPC של האשכול באמצעות מנהרות VPN קלאסיות שלא משתמשות בנתיבים דינמיים: צריך להגדיר נתיב סטטי ברשת השנייה.

4. מגדירים את רשת ה-VPC של האשכול כך שתייצא את המסלולים בהתאמה אישית ביחסי הקישור לרשת ה-VPC של מישור הבקרה. Cloud de Confiance תמיד מגדיר את רשת ה-VPC של מישור הבקרה כך שתייבא מסלולים בהתאמה אישית מרשת ה-VPC של האשכול. השלב הזה מספק נתיב לחבילות מנקודת הקצה הפרטית של מישור הבקרה בחזרה לרשת השנייה.

   כדי להפעיל ייצוא של מסלולים בהתאמה אישית מרשת ה-VPC של האשכול, משתמשים בפקודה הבאה:

   gcloud compute networks peerings update PEERING_NAME \
       --network=CLUSTER_VPC_NETWORK \
       --export-custom-routes
   

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

   • ‫PEERING_NAME: השם של הקישור בין רשתות ה-VPC (peering) שמקשר בין רשת ה-VPC של האשכול לבין רשת ה-VPC של מישור הבקרה
   • ‫CLUSTER_VPC_NETWORK: השם או ה-URI של רשת ה-VPC של האשכול

   אם הפעלתם ייצוא של מסלולים בהתאמה אישית ל-VPC, יצירת מסלולים שחופפים לטווחי ה-IP שלCloud de Confiance עלולה לשבש את האשכול.

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

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

יעדים נתמכים מהרשת השנייה

טווחי הכתובות שהרשת האחרת שולחת לנתבי Cloud Router ברשת ה-VPC של האשכול צריכים לעמוד בתנאים הבאים:

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

• אם רשת ה-VPC של מישור הבקרה מקבלת נתיבים שמחליפים בפועל נתיב ברירת מחדל, הנתיבים האלה מנתקים את הקישוריות לממשקי ה-API ולשירותים שלCloud de Confiance , וקוטעים את מישור הבקרה של האשכול. לדוגמה, הרשת השנייה לא יכולה לפרסם מסלולים עם יעדים 0.0.0.0/1 ו-128.0.0.0/1. אפשר לעיין בנקודה הקודמת כדי לראות חלופה.

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

הגנה על אשכול פרטי באמצעות VPC Service Controls

כדי לאבטח עוד יותר את האשכולות הפרטיים של GKE, אתם יכולים להגן עליהם באמצעות VPC Service Controls.

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

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

אם אתם משתמשים ב-Artifact Registry עם אשכול פרטי של GKE בגבולות גזרה לשירות של VPC Service Controls, אתם צריכים להגדיר ניתוב לכתובת ה-IP הווירטואלית המוגבלת כדי למנוע זליגת נתונים.

סידור וארגון

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

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

gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3

מחיקת הרשת

gcloud compute networks delete my-net-0

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

• מידע על הגדרות מתקדמות באשכולות פרטיים
• איך יוצרים אשכולות המותאמים ל-VPC
• מידע נוסף על קישור בין רשתות VPC שכנות (peering)
• כאן תוכלו לקרוא מדריך על גישה לאשכולות GKE פרטיים באמצעות מאגרים פרטיים של Cloud Build.