יצירת אשכול

בדף הזה מוסבר איך ליצור אשכול ומאגר צמתים ב-GKE ב-Azure ב-Kubernetes בגרסה 1.34.1-gke.4700.

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

כדי לבצע את השלבים בדף הזה:

  1. פועלים לפי השלבים במאמר הגדרת דרישות מוקדמות.

  2. בוחרים אם להפעיל את מישור הבקרה בכמה אזורים או באזור אחד.

  3. בוחרים טווחי כתובות IP בפורמט Classless Inter-Domain Routing‏ (CIDR) כדי לספק אותם לאשכול.

מיקום אזורי של מישור הבקרה

כברירת מחדל, GKE on Azure ממקם רפליקות נפרדות של מישור הבקרה באותה רשת משנה בשלושה אזורים באזור שבחרתם. אתם יכולים לבחור את האזורים ואת רשתות המשנה האלה.

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

שער NAT של Azure ומישורי בקרה של אשכולות

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

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

אם רוצים למקם רפליקות של מישור הבקרה באזור אחד, צריך להשתמש בתת-רשת ובאזור אחד. אם אתם משתמשים ב-NAT Gateway לקישוריות יוצאת, ודאו שנקודת הקצה ממוקמת באותו אזור.

אם רוצים למקם רפליקות בשני אזורים או בשלושה, אפשר להעביר רשימה של רשתות משנה ואזורים כשיוצרים אשכול. כשמעבירים שתי רשתות משנה ואזורים, מערכת GKE on Azure ממקמת שני עותקים משוכפלים באזור הראשון שצוין. כשמעבירים שלוש תת-רשתות ואזורים, GKE ב-Azure ממקם עותקים משוכפלים בכל תת-רשת. מידע נוסף על הצבת רפליקות ברשת משנה ספציפית

מידע נוסף על הגדרת תתי-רשתות ואזורים ב-Azure לזמינות גבוהה זמין במאמר Zone isolation with zonal stacks (בידוד אזורים באמצעות מחסניות אזוריות) במסמכי התיעוד של Azure.

הצבת רפליקות ברשת משנה ספציפית

הקטע הזה הוא אופציונלי.

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

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

  1. אחזר את מזהי רשתות המשנה ב-Azure באמצעות הכלי az של שורת הפקודה:

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

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

    • ‫CLUSTER_RESOURCE_GROUP_NAME: שם של קבוצת משאבים קיימת שבה רוצים להריץ את האשכול
    • ‫VNET_RESOURCE_GROUP_NAME: השם של קבוצת המשאבים שמכילה את רשת ה-VNet
    • ‫VNET_NAME: השם של רשת ה-VNet
    • ‫SUBNET_NAME: השם של רשת המשנה

    הפלט הוא המזהה של רשת המשנה. מזהי רשתות משנה ב-Azure נראים כך:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

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

  2. יוצרים רשימה מופרדת בפסיקים של מזהי רשתות משנה ואזורי זמינות ב-Azure, עם נקודתיים שמפרידות בין רשת המשנה לאזור. לדוגמה, כדי ליצור רפליקות של מישור הבקרה ב-subnet1 באזור 1, ב-subnet2 באזור 2 וב-subnet3 באזור 3, משתמשים במחרוזת הבאה:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3

    מעתיקים את המחרוזת הזו ומשתמשים בה כערך של הדגל --replica-placements כשיוצרים אשכול.

בחירת טווחי CIDR לאשכול

כשיוצרים אשכול ב-GKE ב-Azure, צריך לספק טווחי כתובות IPv4 לשימוש ב-Pods וב-Services.

טווח כתובות ה-IP האלה מצוין באמצעות סימון Classless Inter-Domain Routing‏ (CIDR) – לדוגמה, 100.64.0.0/16.

אנחנו ממליצים על טווחי ה-CIDR הבאים לשירותים ול-Pods:

  • שירותים: 100.64.0.0/16
  • ‫Pods: 100.96.0.0/11

הטווחים האלה גדולים מספיק כדי שתוכלו להגדיל את האשכול בלי בעיות.

בקטעים הבאים מפורטים פרטים נוספים.

פרטים על בחירת טווחים

‫GKE on Azure משתמש ברשת שכבת-על בשביל Pods ושירותים, כך שאין צורך שטווח כתובות ה-IP של הרשתות האלה יהיה ניתן לניתוב בתוך ה-VNet. צריך לוודא שכל טווחי כתובות ה-IP שבהם אתם משתמשים זמינים. מידע נוסף זמין במאמר בנושא Dataplane V2.

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

  • טווח כתובות ה-IP של ה-Pod והשירות חייב להיות אחד מטווח כתובות ה-IP הפרטיות הבאים:

    • ‫10.0.0.0/8, ‏ 172.16.0.0/12, ‏ 192.168.0.0/16 – כתובות IP פרטיות (RFC 1918)
    • ‫100.64.0.0/10 — מרחב כתובות משותף (RFC 6598)
    • ‫192.0.0.0/24 — הקצאות פרוטוקול של IETF‏ (RFC 6890)
    • ‫192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — מסמכי תיעוד (RFC 5737)
    • ‫192.88.99.0/24 — IPv6 to IPv4 relay (הוצא משימוש) (RFC 7526)
    • ‫198.18.0.0/15 – בדיקת השוואה לשוק (RFC 2544)

מומלץ להשתמש בטווחים של כתובות IP בתוך 100.64.0.0/10 (RFC 6598). הטווח הזה שמור ל-NAT ברמת הספק, שסביר להניח שלא נעשה בו שימוש ב-VNet שלכם.

לדוגמה, ההגדרה הבאה היא הגדרה תקינה שבה הרשתות של ה-Pod, השירות והצומת לא חופפות (רשת ה-VNet משתמשת בכתובות IP פרטיות לפי RFC 1918, ואילו הרשתות של ה-Pod והשירות מוצבות על כתובות IP פרטיות לפי RFC 6598).

  • רשת VNet: 10.0.0.0/16, ‏ 172.16.1.0/24, ‏ 172.16.2.0/24
  • רשת Pod: 100.65.0.0/16
  • רשת שירות: 100.66.0.0/16

ההגדרה הבאה תקפה גם היא, למרות שיש חפיפה בין רשתות ה-Pod והשירות לבין רשת ה-VNet, כי אין חפיפה עם הרפליקות של מישור הבקרה.

  • רשת VNet: 10.0.0.0/16
  • רשת Pod: 10.0.1.0/24
  • רשת שירות: 10.0.2.0/24
  • תת-רשתות של העתק של מישור הבקרה: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

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

  • רשת VNet: 10.0.0.0/16
  • רשת Pod: 10.0.1.0/24
  • רשת שירות: 10.1.0.0/24
  • תת-רשתות של העתק של מישור הבקרה: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

פרטים על טווח הכתובות של ה-Pod

‫Kubernetes מקצה כתובות לאובייקטים מסוג Pod מתוך טווח הכתובות של ה-Pod. טווח ה-Pod של אשכול מחולק לטווחים קטנים יותר לכל צומת. כשמגדירים תזמון של Pod בצומת מסוים, מערכת Kubernetes מקצה כתובת IP של Pod מתוך הטווח של הצומת.

כדי לחשב את הגודל של טווח כתובות ה-Pod, צריך להעריך את מספר הצמתים שרוצים באשכול ואת מספר ה-Pods שרוצים להפעיל בכל צומת.

בטבלה הבאה מפורטות המלצות לגבי גודל טווחי ה-CIDR של ה-Pod, על סמך מספר הצמתים וה-Pods שאתם מתכוונים להפעיל.

טבלה של טווחי כתובות של Pod

טווח כתובות של Pod כתובות IP מקסימליות של Pod מספר הצמתים המקסימלי מספר המכשירים המקסימלי
‫‎/24
טווח הכתובות הקטן ביותר האפשרי של Pod		 ‫256 כתובות צומת אחד ‫110 טבליות
/23 ‫512 כתובות ‫2 צמתים ‫220 טבליות
/22 ‫1,024 כתובות ‫4 צמתים ‫440 טבליות
/21 ‫2,048 כתובות ‫8 צמתים ‫880 קבוצות Pod
/20 ‫4,096 כתובות ‫16 צמתים ‫1,760 טבליות
/19 ‫8,192 כתובות ‫32 צמתים ‫3,520 טבליות
/18 ‫16,384 כתובות ‫64 צמתים ‫7,040 טבליות
/17 ‫32,768 כתובות ‫128 צמתים ‫14,080 טבליות
/16 ‫65,536 כתובות ‫256 צמתים ‫28,160 טבליות
/15 ‫131,072 כתובות ‫512 צמתים ‫56,320 טבליות
/14 ‫262,144 כתובות ‫1,024 צמתים ‫112,640 טבליות

פרטים על טווח הכתובות למקרי חירום

‫Kubernetes מקצה כתובות IP וירטואליות לאובייקטים של Service – לדוגמה, מאזני עומסים מתוך טווח הכתובות הזה.

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

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

טבלה של טווחי כתובות למקרי חירום

טווח כתובות למקרי חירום מספר השירותים המקסימלי
/27
טווח כתובות השירות הקטן ביותר האפשרי		 ‫32 Services
/26 ‫64 שירותים
/25 ‫128 Services
/24 ‫256 שירותים
/23 ‫512 שירותים
/22 ‫1,024 שירותים
/21 ‫2,048 שירותים
/20 ‫4,096 שירותים
/19 ‫8,192 שירותים
/18 ‫16,384 שירותים
/17 ‫32,768 שירותים
/16
טווח כתובות השירות הגדול ביותר האפשרי		 ‫65,536 שירותים

אימות ב-Azure

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

איחוד שירותי אימות הזהות של עומסי עבודה

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר ל-GKE ב-Azure לבצע אימות ב-Azure באמצעות חשבון שירות של Google, כדי לנהל בהמשך משאבים באפליקציית Azure AD. בניגוד ל-AzureClient, לא צריך לנהל אישורים ולהעלות אותם ל-Azure AD באופן ידני.

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

  1. שומרים את מזהה האפליקציה ב-Azure במשתני סביבה:

    APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

  2. יוצרים קובץ JSON בשם credential.json.

    {
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}
    • ‫CREDENTIAL_NAME: שם פרטי הכניסה.
    • ‫PROJECT_NUMBER: מספר Google Cloud הפרויקט שמארח את האשכול.

  3. יצירת פרטי כניסה מאוחדים לזהות באפליקציית Azure AD:

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

פרטים נוספים זמינים במאמרי העזרה של Azure בנושא איחוד שירותי אימות הזהות של עומסי עבודה ב-Azure AD עם Google Cloud.

אפשר גם להקצות את אישורי הזהות המאוחדת של Azure באמצעות Terraform. פרטים נוספים זמינים במאמר בנושא azuread_application_federated_identity_credential.

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

יצירת זוג מפתחות SSH

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

  1. כדי ליצור זוג מפתחות חדש, משתמשים בכלי שורת הפקודה ssh-keygen:

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    מחליפים את KEY_PATH בנתיב למפתח הפרטי החדש.

  2. מאחסנים את המפתח במשתנה סביבה:

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    לדוגמה, כדי ליצור זוג מפתחות חדש ב-~/.ssh/anthos-multicloud-key.pub ולאחסן את המפתח הציבורי במשתנה סביבה, מריצים את הפקודה הבאה:

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

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

בחירת פרויקט לאירוח צי הרכבים

Fleets הםGoogle Cloud קונספט לארגון אשכולות לקבוצות גדולות יותר. באמצעות צי של אשכולות, אפשר לנהל כמה אשכולות בכמה עננים ולהחיל עליהם מדיניות עקבית. ממשק ה-API של GKE Multi-Cloud רושם אוטומטית את האשכולות שלכם ב-Fleet כשהאשכול נוצר.

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

רישום חוצה-פרויקטים

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

  1. כדי להוסיף את סוכן השירות לפרויקט, מריצים את הפקודה הבאה:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    מחליפים את CLUSTER_PROJECT_NUMBER במספר הפרויקט ב- Google Cloud .

  2. מקצים את הקישור הזה באמצעות הפקודה הבאה:

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

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

    • ‫FLEET_PROJECT_ID: הפרויקט המארח של ה-Fleet, כלומרGoogle Cloud project
    • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud

השם של חשבון סוכן השירות לריבוי עננים הוא בפורמט הבא: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

אפשר למצוא את חשבונות השירות בדף Service account במסוף Google Cloud . מידע נוסף על איתור מספר הפרויקט זמין במאמר זיהוי פרויקטים.

יצירת אשכול

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

  1. שומרים את מזהי קבוצת המשאבים, ה-VNet והתת-רשת ב-Azure כמשתני סביבה:

    SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

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

    • ‫CLUSTER_RESOURCE_GROUP_NAME: שם של קבוצת משאבים קיימת שבה רוצים להריץ את האשכול
    • ‫VNET_RESOURCE_GROUP_NAME: השם של קבוצת המשאבים שמכילה את רשת ה-VNet
    • ‫VNET_NAME: השם של הרשת הווירטואלית

  2. יוצרים אשכול באמצעות Google Cloud CLI:

    איחוד שירותי אימות הזהות של עומסי עבודה

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.34.1-gke.4700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Azure client

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.34.1-gke.4700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

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

    • ‫CLUSTER_NAME: השם של האשכול
    • ‫GOOGLE_CLOUD_LOCATION: Google Cloud המיקום שבו מנוהל האשכול
    • ‫FLEET_PROJECT עם פרויקט המארח של ה-Fleet שבו האשכול יירשם. אם רוצים לנהל את האשכול הזה מפרויקט אחר, אפשר לעיין במאמר בנושא רישום בין פרויקטים.Google Cloud
    • ‫AZURE_REGION: אזור נתמך ב-Azure שמשויך לאזור Google Cloud שלכם
    • ‫POD_CIDR: טווח כתובות ה-Pod של האשכול – לדוגמה, 10.0.1.0/18
    • ‫SERVICE_CIDR: טווח כתובות השירות של האשכול
    • ‫VM_SIZE: a supported Azure VM size
    • ‫ADMIN_USERS_LIST (אופציונלי): רשימה מופרדת בפסיקים של כתובות אימייל של המשתמשים שרוצים להעניק להם הרשאות אדמין – לדוגמה, "kai@example.com,hao@example.com,kalani@example.com". ברירת המחדל היא המשתמש שיוצר את האשכול
    • ‫CLIENT_NAME: השם של AzureClient

  3. בודקים את הסטטוס של האשכול:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

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

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    הפלט כולל מידע על הסטטוס וההגדרה של האשכול.

אישור של Cloud Logging / Cloud Monitoring

כדי ש-GKE ב-Azure יוכל ליצור ולהעלות יומנים ומדדים של המערכת אלGoogle Cloud, צריך לתת לו הרשאה.

כדי לתת לזהות של עומס העבודה ב-Kubernetes‏ gke-system/gke-telemetry-agentהרשאה לכתוב יומנים ב- Google Cloud Logging ומדדים ב- Google Cloud Monitoring, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

מחליפים את GOOGLE_PROJECT_ID במזהה הפרויקט של האשכול. Google Cloud

הקישור הזה ב-IAM מעניק גישה לכל האשכולות בפרויקט Google Cloud project project להעלאת יומנים ומדדים. צריך להריץ אותה רק אחרי שיוצרים את האשכול הראשון בפרויקט.

הוספת הקישור הזה של IAM תיכשל אלא אם נוצר לפחות אשכול אחד בפרויקט Google Cloud . הסיבה לכך היא שמאגר הזהויות של עומסי העבודה שאליו הוא מתייחס (GOOGLE_PROJECT_ID.svc.id.goog) לא מוקצה עד ליצירת האשכול.

יצירת מאגר צמתים

לפני שיוצרים מאגר צמתים, צריך:

  • הרשאות לשימוש בכלי az של שורת הפקודה כדי לאחזר מזהה של רשת משנה ב-Azure.
  • גישה למפתח הציבורי SSH של האשכול.

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

  1. שומרים את מזהה רשת המשנה של Azure VNet ואת המפתח הציבורי של SSH במשתני סביבה:

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

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

    • ‫VNET_RESOURCE_GROUP_NAME: השם של קבוצת המשאבים שמכילה את רשת ה-VNet
    • ‫VNET_NAME: השם של הרשת הווירטואלית
    • ‫KEY_PATH: הנתיב לזוג המפתחות

  2. יוצרים מאגר צמתים באמצעות Google Cloud CLI:

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.34.1-gke.4700 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"

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

    • ‫NODE_POOL_NAME: שם ייחודי למאגר הצמתים, לדוגמה node-pool-1
    • ‫CLUSTER_NAME: השם של אשכול GKE ב-Azure
    • ‫GOOGLE_CLOUD_LOCATION: Google Cloud המיקום שבו מתנהל האשכול
    • ‫VM_SIZE: a supported Azure VM size
    • ‫MIN_NODES: מספר הצמתים המינימלי במאגר הצמתים. מידע נוסף זמין במאמר בנושא Cluster Autoscaler.
    • ‫MAX_NODES: המספר המקסימלי של הצמתים במאגר הצמתים

  3. בודקים את הסטטוס של מאגר הצמתים:

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

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

    • ‫NODE_POOL_NAME: שם ייחודי למאגר הצמתים, לדוגמה node-pool-1
    • ‫CLUSTER_NAME: השם של אשכול GKE ב-Azure
    • ‫GOOGLE_CLOUD_LOCATION: Google Cloud המיקום שבו מתנהל האשכול

    הפלט כולל את הסטטוס של מאגר הצמתים, כולל אם הוא PROVISIONING או RUNNING.

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