יצירת אשכול באמצעות מאגרי צמתים של Windows Server

בדף הזה מוסבר איך ליצור אשכול ב-Google Kubernetes Engine‏ (GKE) עם מאגרי צמתים שמריצים את Microsoft Windows Server. באשכול הזה אפשר להשתמש בקונטיינרים של Windows Server. בשלב הזה אין תמיכה בקונטיינרים של Microsoft Hyper-V. בדומה לקונטיינרים של Linux, קונטיינרים של Windows Server מספקים בידוד של תהליכים ומרחבי שמות.

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

יצירת אשכול באמצעות מאגרי צמתים של Windows Server

בקטע הזה יוצרים אשכול שמשתמש בקונטיינר של Windows Server.

כדי ליצור את האשכול הזה, צריך לבצע את המשימות הבאות:

  1. בחירת קובץ האימג' של צומת Windows Server.
  2. מעדכנים ומגדירים את gcloud.
  3. יצירת אשכול ומאגרי צמתים.
  4. מקבלים את פרטי הכניסה ל-kubectl.
  5. מחכים שהאשכול יתחיל לפעול.

הגדרת חשבונות שירות של IAM ל-GKE

כדי להריץ משימות מערכת כמו רישום ביומן ומעקב, GKE משתמש בחשבונות שירות של IAM שמקושרים לצמתים. לכל הפחות, לחשבונות השירות של הצמתים צריך להיות התפקיד חשבון השירות שמוגדר כברירת מחדל לצומת ב-Kubernetes Engine‏ (roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

כדי להקצות את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות שמוגדר כברירת המחדל של Compute Engine:

המסוף

  1. נכנסים לדף Welcome:

    לדף Welcome

  2. בשדה Project number, לוחצים על Copy to clipboard.
  3. נכנסים לדף IAM:

    כניסה לדף IAM

  4. לוחצים על Grant access.
  5. בשדה New principals, מציינים את הערך הבא: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     מחליפים את הערך PROJECT_NUMBER במספר הפרויקט שהעתקתם.
  6. בתפריט Select a role, בוחרים את התפקיד Kubernetes Engine Default Node Service Account.
  7. לוחצים על Save.

gcloud

  1. מאתרים את מספר הפרויקט ב- Google Cloud : 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

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

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

    12345678901
  2. מקצים את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    מחליפים את PROJECT_NUMBER במספר הפרויקט מהשלב הקודם.

בחירת תמונת הצומת של Windows Server

כדי להריץ ב-GKE, צריך ליצור קובצי אימג' של צומת קונטיינר של Windows Server בגרסה המומלצת של Windows Server‏ 2022 ‏ (LTSC), או בגרסה של Windows Server‏ 2019 ‏ (LTSC), שהוצאה משימוש על ידי GKE ואי אפשר להשתמש בה למאגרי צמתים שמריצים את GKE בגרסה 1.37 ואילך. לאשכול אחד יכולים להיות כמה מאגרי צמתים של Windows Server שמשתמשים בגרסאות שונות של Windows Server, אבל כל מאגר צמתים יכול להשתמש רק בגרסה אחת של Windows Server.

כשבוחרים את קובץ האימג' של הצומת, כדאי להביא בחשבון את הנקודות הבאות:

  • עדכונים: צריך להשתמש ב-LTSC2022, כי GKE הוציא משימוש את LTSC2019. חשוב לדעת את הדברים הבאים לגבי LTSC2019:
    • אין עדכונים של קובצי אימג' של צמתים: GKE לא מספק עדכונים של קובצי אימג' של צמתים ל-LTSC2019 בגלל בעיות יציבות בעדכונים של קובץ האימג' הבסיסי, מאז שמיקרוסופט סיימה את התמיכה הרגילה בקובץ האימג'. תמונות הצמתים של GKE מוצמדות לגרסה של דצמבר 2025 של התמונה הבסיסית. מידע נוסף זמין במאמר Windows Server 2019.
    • תאימות לגרסה 1.37: בגרסה 1.37 של GKE ואילך, אי אפשר להשתמש ב-LTSC2019. אי אפשר ליצור מאגרי צמתים חדשים עם LTSC2019 ועם גרסה 1.37, או לשדרג מאגרי צמתים קיימים של LTSC2019 לגרסה 1.37.
  • זמני התמיכה:
  • תאימות ומורכבות של גרסאות:
    • אפשר להשתמש גם ב-Windows Server Core וגם ב-Nano Server כקובץ אימג' בסיסי לקונטיינרים.
    • כדי לנהל את המורכבות של ניהול הגרסאות, אתם יכולים ליצור את קובצי האימג' של קונטיינרים של Windows Server כקובצי אימג' עם כמה ארכיטקטורות, שיכולים לטרגט כמה גרסאות של Windows Server.

עדכון והגדרה של gcloud

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

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

יצירת אשכול ומאגרי צמתים

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

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

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

gcloud

יוצרים אשכול עם השדות הבאים:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

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

  • ‫CLUSTER_NAME: השם שבחרתם לאשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. באשכולות אזוריים צריך לציין אזור, ובאשכולות של תחומים צריך לציין תחום.
  • --enable-ip-alias מפעיל את כתובת ה-IP החלופית. בצמתים של Windows Server צריך להשתמש בכתובת IP חלופית. למידע נוסף על היתרונות של ניתוב קונטיינרים מקורי עם כתובות IP חלופיות, קראו את המאמר הסבר על ניתוב קונטיינרים מקורי עם כתובות IP חלופיות.
  • ‫NUMBER_OF_NODES: מספר הצמתים של Linux שאתם יוצרים. חשוב לספק מספיק משאבי מחשוב כדי להריץ את התוספים של האשכול. זהו שדה אופציונלי, ואם משמיטים אותו, המערכת משתמשת בערך ברירת המחדל 3.
  • ‫VERSION_NUMBER: גרסת האשכול הספציפית שבה רוצים להשתמש. אם לא תציינו ערוץ הפצה, GKE ירשום את האשכול לערוץ ההפצה הכי בשל שבו הגרסה זמינה.
  • ‫CHANNEL: ערוץ ההפצה שאליו רוצים לרשום את האשכול. אפשר לבחור באחד מהערוצים הבאים: rapid,‏ regular,‏ stable או None (הוצא משימוש). כברירת מחדל, האשכול רשום לערוץ ההפצה regular.

אנחנו ממליצים מאוד להגדיר חשבון שירות ב-IAM עם הרשאות מינימליות, שהצמתים יוכלו להשתמש בו במקום בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. במאמר שימוש בחשבון שירות עם הרשאות מינימליות מוסבר איך יוצרים חשבון שירות עם הרשאות מינימליות.

כדי לציין חשבון שירות בהתאמה אישית ב-CLI של gcloud, מוסיפים לפקודה את הדגל הבא:

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

מחליפים את SERVICE_ACCOUNT_NAME בשם של חשבון השירות עם ההרשאות המינימליות.

יוצרים את מאגר הצמתים של Windows Server עם השדות הבאים:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

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

  • ‫NODE_POOL_NAME: השם שבחרתם למאגר הצמתים של Windows Server.
  • ‫CLUSTER_NAME: השם של האשכול שיצרתם למעלה.
  • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. באשכולות אזוריים צריך לציין אזור, ובאשכולות של תחומים צריך לציין תחום.
  • ‫MACHINE_TYPE_NAME: מגדיר את סוג המכונה. ‫n1-standard-2 הוא סוג המכונה המינימלי המומלץ, כי צומתי Windows Server דורשים משאבים נוספים. אין תמיכה בסוגי המכונות f1-micro ו-g1-small. כל סוג מכונה מחויב באופן שונה. למידע נוסף, קראו את גיליון המחירים של סוגי המכונות.
  • ‫WINDOWS_OS_VERSION: דגל אופציונלי שמגדיר את גרסת מערכת ההפעלה Windows שבה משתמשים לסוג קובץ האימג' WINDOWS_LTSC_CONTAINERD. בגרסה 1.37 של GKE ואילך, אפשר להשתמש רק ב-LTSC2022 (ltsc2022). בגרסה 1.36 או בגרסאות קודמות, מומלץ להגדיר את הערך באופן מפורש ל-ltsc2022. אחרת, GKE משתמש ב-LTSC2019 (ltsc2019), שלא מומלץ כי הוא הוצא משימוש על ידי GKE.

בדוגמה הבאה אפשר לראות איך יוצרים מאגר צמתים של Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

בדוגמה הבאה אפשר לראות איך מעדכנים מאגר קיים של צומתי Windows כדי להשתמש בקובץ אימג' של מערכת ההפעלה Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --windows-os-version=ltsc2022

המסוף

  1. נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .

    יצירת אשכול Kubernetes

  2. בקטע Cluster basics, מבצעים את הפעולות הבאות:
    1. מזינים את השם (Name) של האשכול.
    2. ב-Location type, בוחרים אזור או תחום לאשכול.
    3. בקטע ערוצי הפצה, בוחרים ערוץ הפצה ואם רוצים, גם גרסת יעד.
  3. בחלונית הניווט, בקטע Node Pools, לוחצים על default-pool כדי ליצור את מאגר הצמתים של Linux. כשמגדירים את מאגר הצמתים הזה, צריך לספק מספיק משאבי מחשוב כדי להריץ את התוספים של האשכול. בנוסף, צריכה להיות לכם מכסת משאבים זמינה לצמתים ולמשאבים שלהם (כמו מסלולים של חומת אש).
  4. בחלק העליון של הדף, לוחצים על Add Node Pool כדי ליצור את מאגר הצמתים של Windows Server.
  5. בקטע פרטי מאגר צמתים, מבצעים את הפעולות הבאות:
    1. מזינים שם למאגר הצמתים.
    2. מזינים את מספר הצמתים שרוצים ליצור במאגר הצמתים.

  6. בחלונית הניווט, בקטע מאגרי צמתים, לוחצים על צמתים.

    1. ברשימה הנפתחת Image type, בוחרים את קובץ האימג' הבא של הצומת:

      • ערוץ שירות לטווח ארוך של Windows עם containerd

      מידע נוסף זמין בקטע בחירת קובץ אימג' של צומת Windows.

    2. בוחרים את Machine configuration שיוגדר כברירת המחדל למכונות. ‫n1-standard-2 הוא הגודל המינימלי המומלץ, כי צומתי Windows Server דורשים משאבים נוספים. אין תמיכה בסוגי המכונות f1-micro ו-g1-small. כל סוג מכונה מחויב באופן שונה. למידע נוסף, קראו את גיליון המחירים של סוגי המכונות.

  7. בחלונית הניווט, בקטע Cluster, בוחרים באפשרות Networking.

    1. בקטע Advanced networking options, מוודאים שהאפשרות Enable VPC-native traffic routing (uses alias IP) מסומנת. בצמתים של Windows Server צריך להשתמש בכתובת IP חלופית. למידע נוסף על היתרונות של ניתוב קונטיינרים מקורי עם כתובות IP חלופיות, קראו את המאמר הסבר על ניתוב קונטיינרים מקורי עם כתובות IP חלופיות.

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

Terraform

כדי ליצור אשכול GKE Standard ומאגר צמתים של Windows Server באמצעות Terraform, תוכלו להיעזר בדוגמה הבאה:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

בדוגמה הזו משתמשים ב-Windows Server LTSC עם containerd. זהו סוג קובץ האימג' של מערכת ההפעלה גם ל-Windows Server 2022 וגם ל-Windows Server 2019 (הוצא משימוש על ידי GKE). מידע נוסף על קובצי אימג' של צמתים זמין במאמר בחירת קובץ אימג' של צומת Windows.

מידע נוסף על השימוש ב-Terraform זמין במאמר תמיכה של Terraform ב-GKE.

אחרי שיוצרים מאגר של צומתי Windows Server, האשכול עובר למצב RECONCILE למשך כמה דקות בזמן שמישור הבקרה מתעדכן.

קבלת פרטי הכניסה של kubectl

משתמשים בפקודה get-credentials כדי לאפשר ל-kubectl לעבוד עם האשכול שיצרתם.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

מידע נוסף על הפקודה get-credentials זמין במאמרי העזרה של SDK בנושא get-credentials.

המתנה להפעלת האשכול

לפני שמשתמשים באשכול, ממתינים כמה שניות עד ליצירת windows.config.common-webhooks.networking.gke.io. ה-webhook הזה מוסיף סבילות לתזמון לפודים שנוצרו באמצעות בורר הצמתים kubernetes.io/os: windows כדי לוודא שהם יכולים לפעול בצמתים של Windows Server. הוא גם מאמת את ה-Pod כדי לוודא שהוא משתמש רק בתכונות שנתמכות ב-Windows.

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

kubectl get mutatingwebhookconfigurations

הפלט אמור להראות שה-webhook פועל:

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

עכשיו, כשיש לכם אשכול עם שני מאגרי צמתים (אחד של Linux ואחד של Windows), אתם יכולים לפרוס אפליקציית Windows.

מיפוי גרסאות GKE ו-Windows

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

כדי לראות את מיפוי הגרסאות בין גרסאות GKE לגרסאות Windows Server, משתמשים בפקודה gcloud beta container get-server-config:

gcloud beta container get-server-config

מיפוי הגרסאות מוחזר בשדה windowsVersionMaps של התגובה. כדי לסנן את התשובה ולראות את מיפוי הגרסאות של גרסאות GKE ספציפיות באשכול, מבצעים את השלבים הבאים במעטפת Linux או ב-Cloud Shell.

  1. מגדירים את המשתנים הבאים:

    CLUSTER_NAME=CLUSTER_NAME \
NODE_POOL_NAME=NODE_POOL_NAME \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫NODE_POOL_NAME: השם של מאגר הצמתים של Windows Server.
    • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. באשכולות אזוריים צריך לציין אזור, ובאשכולות של תחומים צריך לציין תחום.

  2. משיגים את הגרסה של מאגר הצמתים ושומרים אותה במשתנה NODE_POOL_VERSION:

    NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster=$CLUSTER_NAME \
--location=$CONTROL_PLANE_LOCATION \
--format="value(version)"`

  3. משיגים את הגרסאות של Windows Server ל-NODE_POOL_VERSION:

    gcloud beta container get-server-config \
    --location=$CONTROL_PLANE_LOCATION \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

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

    windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

  4. משיגים את גרסת Windows Server של סוג קובץ האימג' WINDOWS_LTSC:

    gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_LTSC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

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

    10.0.17763.1577

שדרוג מאגרי צמתים של Windows Server

דרישות התאימות של גרסת הקונטיינר של Windows Server אומרות שיכול להיות שתצטרכו לבנות מחדש את קובצי האימג' של הקונטיינרים כך שיתאימו לגרסת Windows Server של גרסת GKE חדשה, לפני שתשדרגו את מאגרי הצמתים. כדאי לקרוא את ההמלצות הבאות לגבי שדרוג של מאגר צמתים מהסוג הזה:

  • אם צריך, אפשר למנוע שדרוגים אוטומטיים של צמתים באמצעות החרגות תחזוקה.
  • כדי לוודא שקובצי האימג' של הקונטיינרים תואמים לצמתים, צריך לבדוק את מיפוי הגרסאות וליצור את קובצי האימג' של הקונטיינרים של Windows Server כקובצי אימג' עם כמה ארכיטקטורות שיכולים לטרגט כמה גרסאות של Windows Server. אחר כך תוכלו לעדכן את פריסות הקונטיינרים כך שיתמקדו בקובצי האימג' עם ריבוי הארכיטקטורות, שיפעלו גם בגרסה הנוכחית וגם בגרסה הבאה של GKE, לפני שתפעילו באופן ידני שדרוג של מאגר הצמתים של GKE.
  • אם אתם מונעים שדרוגים אוטומטיים של צמתים, בצעו שדרוגים ידניים של מאגרי צמתים באופן קבוע, כי הצמתים לא יכולים להיות יותר משתי גרסאות משניות מאחורי הגרסה של מישור הבקרה.
  • כדי לקבל עדכונים באופן יזום על גרסאות חדשות של GKE ועל גרסאות של מערכת ההפעלה Windows שבהן הן משתמשות, הירשמו לקבלת התראות על שדרוגים.
  • כדאי לאפשר ל-GKE לבצע שדרוגים אוטומטיים של צמתים רק אם אתם יוצרים באופן רציף קובצי אימג' של קונטיינרים של Windows Server עם כמה ארכיטקטורות, שמטרגטים את הגרסאות העדכניות ביותר של Windows Server. שדרוגים אוטומטיים של צמתים לא צפויים לגרום לבעיות בסוג קובץ האימג' של צומת Windows Server LTSC, אבל עדיין יש סיכון להיתקל בבעיות של חוסר תאימות בין גרסאות.

עדכוני Windows

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

שליטה באופן התקשורת בין Pods ושירותים של Windows

אתם יכולים לשלוט באופן שבו פודים ושירותים של Windows מתקשרים באמצעות מדיניות רשת ב-Kubernetes.

אפשר להשתמש בקונטיינר של Windows Server באשכולות שבהם מופעלת מדיניות רשת ב-GKE בגרסאות 1.22.2 ואילך. התכונה הזו זמינה לאשכולות שמשתמשים בסוגי קובצי האימג' של הצומת WINDOWS_LTSC או WINDOWS_LTSC_CONTAINERD.

אם מישורי הבקרה או הצמתים שלכם פועלים בגרסאות קודמות, אתם יכולים להעביר את מאגרי הצמתים לגרסה שתומכת במדיניות רשת ב-Kubernetes. כדי לעשות את זה, אתם צריכים לשדרג את מאגרי הצמתים ואת מישור הבקרה לגרסה 1.22.2 של GKE או לגרסה חדשה יותר. האפשרות הזו זמינה רק אם יצרתם את האשכול עם הדגל --enable-dataplane-v2.

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

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

צפייה ביומנים והרצת שאילתות

רישום ביומן מופעל באופן אוטומטי באשכולות GKE. אפשר להציג את היומנים של הקונטיינרים ואת היומנים משירותים אחרים בצומתי Windows Server באמצעות המעקב של Kubernetes Engine.

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

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

גישה לצומת של Windows Server באמצעות פרוטוקול Remote Desktop ‏ (RDP)

אתם יכולים להתחבר לצומת של Windows Server באשכול באמצעות RDP. הוראות להתחברות מופיעות במאמר התחברות למכונות Windows במסמכי התיעוד של Compute Engine.

יצירת קובצי אימג' עם כמה ארכיטקטורות

אתם יכולים ליצור את קובצי האימג' עם כמה ארכיטקטורות באופן ידני או באמצעות כלי ליצירת קובצי אימג' ב-Cloud Build. הוראות מפורטות זמינות במאמר יצירת קובצי אימג' של Windows עם כמה ארכיטקטורות.

שימוש ב-gMSA

כך משתמשים בחשבון שירות מנוהל של קבוצה (gMSA) עם מאגרי צמתים של Windows Server.

  1. מגדירים את צומתי Windows Server באשכול כך שיצטרפו אוטומטית לדומיין AD. להוראות, קראו את המאמר הגדרת צומתי Windows Server להצטרפות אוטומטית לדומיין של Active Directory.

  2. יוצרים חשבון gMSA ונותנים לו גישה לקבוצת האבטחה שנוצרה באופן אוטומטי על ידי שירות ההצטרפות לדומיין. צריך לבצע את השלב הזה במחשב עם הרשאת אדמין לדומיין של AD.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName

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

    • ‫NODE_POOL_NAME: השם של מאגר הצמתים של Windows Server. לקבוצת האבטחה שנוצרה באופן אוטומטי יש שם זהה לזה של מאגר הצמתים של Windows Server.
    • ‫CLUSTER_NAME: שם האשכול.
    • ‫GMSA_NAME: השם שבחרתם ל-gMSA החדש.
    • ‫DNS_HOST_NAME: שם הדומיין שמוגדר במלואו (FQDN) של חשבון השירות שיצרתם. לדוגמה, אם הערך של GMSA_NAME הוא webapp01 והדומיין הוא example.com, אז הערך של DNS_HOST_NAME הוא webapp01.example.com.

  3. מגדירים את ה-gMSA לפי ההוראות במדריך הגדרת GMSA לפודים ולמאגרי Windows.

מחיקת מאגרי צמתים של Windows Server

מוחקים מאגר צמתים של Windows Server באמצעות gcloud או המסוף Google Cloud .

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION

המסוף

כדי למחוק מאגר צמתים של Windows Server באמצעות המסוף Google Cloud :

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    כניסה ל-Google Kubernetes Engine

  2. לצד האשכול שרוצים לערוך, לוחצים על Actions ואז על Edit.

  3. לוחצים על הכרטיסייה Nodes.

  4. בקטע Node Pools, לוחצים על Delete ליד מאגר הצמתים שרוצים למחוק.

  5. כשמופיעה בקשת אישור, לוחצים שוב על מחיקה.

מגבלות

התכונות הבאות לא נתמכות במאגרי צמתים של Windows Server:

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

פתרון בעיות

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

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

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