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

בדף הזה מוסבר איך ליצור אשכול פרטי של 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 ותנועה כשיוצרים אשכול, מרחיבים את הקטעים הבאים.

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

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה:

• my-subnet-0: 10.0.0.0/22
• טווח משני של פוד: 10.52.0.0/14
• כתובת המכונה הווירטואלית: 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 יוצר באופן אוטומטי שני טווחים משניים: אחד ל-Pods ואחד ל-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 של ה-Pod.
  • ‫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 שדורשות כללי חומת אש נוספים כוללות:

• Admission webhooks
• Aggregated API servers
• המרת 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 שכנות באשכול

כל אשכול פרטי שתיצרו אחרי 15 בינואר 2020 ישתמש מחדש בחיבורים של VPC Network Peering.

אפשר לבדוק אם האשכול הפרטי שלכם משתמש מחדש בחיבורי VPC Network Peering באמצעות ה-CLI של gcloud או 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 Server לאשכול עם צמתים פרטיים, אפשר לעיין במסמכי מידע על מאגר צמתים של Windows.

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

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

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

כשמפעילים גישה גלובלית למישור הבקרה, מאזן העומסים הפנימי מסוג 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 או קבצים מצורפים של Cloud Interconnect VLAN שנמצאים בכל אזור, ולא רק באזור של האשכול.

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

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

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

4. מגדירים את רשת ה-VPC של האשכול לייצא את המסלולים המותאמים אישית שלה בקשר ה-peering לרשת ה-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 Routers ברשת ה-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 פרטיים.