יצירת אשכול באמצעות מאגרי צמתים של 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 Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

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

המסוף

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

    מעבר לדף Welcome

  2. בשדה מספר הפרויקט, לוחצים על העתקה ללוח.
  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). לכל אשכול יכולים להיות כמה מאגרי צמתים של Windows Server שמשתמשים בגרסאות שונות של Windows Server, אבל כל מאגר צמתים יכול להשתמש רק בגרסה אחת של Windows Server.

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

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

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 של כינוי. נדרשת כתובת IP של כינוי לצמתים של Windows Server. למידע נוסף על היתרונות של התכונה, אפשר לקרוא את המאמר הסבר על ניתוב מאגרי תגים מקוריים באמצעות כתובות 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. זהו דגל אופציונלי, אבל מומלץ להגדיר את הערך ל-ltsc2022 כדי ליצור מאגר צמתים של Windows Server 2022. אם לא מציינים גרסה, ברירת המחדל של גרסת מערכת ההפעלה היא LTSC2019 ‏ (ltsc2019), ולא מומלץ להשתמש בה.

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

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

    1. ברשימה הנפתחת סוג התמונה, בוחרים את צומת התמונה הבא:

      • ערוץ שירות לטווח ארוך של 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) (הפעלה של ניתוב תנועה מקורי של VPC (שימוש ב-IP של כינוי)) מסומנת. נדרשת כתובת IP של כינוי לצמתים של Windows Server. למידע נוסף על היתרונות של התכונה, אפשר לקרוא את המאמר הסבר על ניתוב מאגרי תגים מקוריים באמצעות כתובות 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. מידע נוסף על תמונות של צמתים זמין במאמר בחירת תמונת צומת של Windows.

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

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

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

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

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

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

המתנה לאתחול האשכול

לפני שמשתמשים באשכול, צריך להמתין כמה שניות עד שנוצר windows.config.common-webhooks.networking.gke.io. ה-webhook הזה מוסיף סבילות לתזמון ל-Pods שנוצרו באמצעות kubernetes.io/os: windowsnode selector כדי לוודא שהם יכולים לפעול בצמתי 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. ‫GKE מאפשר עדכוני Windows על ידי עדכון תקופתי של תמונות הצמתים של Windows Server שמשמשות בגרסאות חדשות של GKE. יכול להיות שיחול עיכוב בין המועד שבו Microsoft מפרסמת את העדכונים של Windows לבין המועד שבו הם זמינים ב-GKE. כשמתפרסמים עדכוני אבטחה קריטיים, GKE מעדכן את תמונות הצמתים של שרתי Windows במהירות האפשרית.

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

אתם יכולים לקבוע איך שירותים ו-Pods של Windows מתקשרים באמצעות מדיניות רשת.

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

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

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

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

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

הרישום ביומן מופעל אוטומטית באשכולות 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 Protocol ‏ (RDP)

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

יצירת תמונות מרובות ארכיטקטורות

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

שימוש ב-gMSA

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

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

  2. יצירה של gMSA ומתן גישה ל-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. לצד האשכול שרוצים לערוך, לוחצים על פעולות ואז על עריכה.

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

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

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

מגבלות

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

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

פתרון בעיות

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

בעיות בצומת של Containerd

לבעיות מוכרות בשימוש בקובץ אימג' של צומת Containerd, אפשר לעיין בבעיות מוכרות.

הפעלת Windows Pods נכשלת

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

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

שגיאות בשליפת תמונות

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

יכול להיות שנתקלתם בבעיה הזו אם מוצגות הודעות השגיאה 'השליפה של התמונה נכשלה' או 'הקשר של שליפת התמונה בוטל', או אם הסטטוס של ה-Pods הוא ErrImagePull.

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

כדי לשלוף בהצלחה את קובצי ה-container של Windows Server, נסו את האפשרויות הבאות:

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

  • מתחברים לצמתים של Windows Server ומשתמשים בפקודה docker pull באופן ידני בקובצי האימג' של הקונטיינרים לפני שיוצרים את ה-Pods.

  • מגדירים את הדגל image-pull-progress-deadline עבור שירות kubelet כדי להאריך את הזמן הקצוב לתפוגה של שליפת תמונות של מאגרי תגים.

    כדי להגדיר את הדגל, מתחברים לצמתי Windows ומריצים את פקודות PowerShell הבאות.

    1. מאחזרים את שורת הפקודה הקיימת של שירות Kubelet ממאגר הרישום של Windows.

      PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
       
      PS C:\> $name = "ImagePath"
       
      PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
"(?s)${name}.*(C:.*kubelet\.exe.*)"
       
      PS C:\> $kubelet_cmd = $Matches[1] -replace `
"--image-pull-progress-deadline=.* ","" -replace "\r\n"," "

    2. מגדירים שורת פקודה חדשה לשירות Kubelet, עם דגל נוסף להגדלת הזמן הקצוב לתפוגה.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
--image-pull-progress-deadline=40m "

    3. מוודאים שהשינוי בוצע בהצלחה.

      PS C:\> reg query ${regkey} /v ${name}

    4. מפעילים מחדש את שירות kubelet כדי שהדגל החדש ייכנס לתוקף.

      PS C:\> Restart-Service kubelet

    5. מוודאים שהשירות kubelet הופעל מחדש בהצלחה.

      PS C:\> Get-Service kubelet # ensure state is Running

הגענו לסוף חיי המוצר של משפחת התמונות

כשיוצרים מאגר צמתים עם תמונת Windows, מקבלים שגיאה דומה לזו שמופיעה בהמשך:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer versions are still available.

כדי לפתור את השגיאה הזו, צריך לבחור תמונת Windows שזמינה ונתמכת. כדי למצוא את תאריך סיום התמיכה בתמונות של צומת GKE Windows, אפשר להשתמש בפקודה gcloud container get-server-config כמו שמתואר בקטע מיפוי גרסאות של GKE ו-Windows.

תם פרק הזמן שהוקצב לחיבור במהלך יצירת מאגר הצמתים

יכול להיות שייווצר פסק זמן ביצירת מאגר צמתים אם יוצרים מספר גדול של צמתים (לדוגמה, 500) וזהו מאגר הצמתים הראשון באשכול שמשתמש בתמונה של Windows Server.

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

צמתי Windows הופכים ל-NotReady עם השגיאה: 'PLEG is not healthy'

זו בעיה מוכרת ב-Kubernetes שמתרחשת כשמפעילים כמה פודים במהירות רבה בצומת יחיד של Windows. כדי לפתור את הבעיה, צריך להפעיל מחדש את צומת Windows Server. פתרון מומלץ לבעיה הזו הוא להגביל את קצב היצירה של Windows Pods ל-Pod אחד כל 30 שניות.

‫TerminationGracePeriod לא עקבי

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

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

בעיות בחיבור לרשת

אם נתקלתם בבעיות בקישוריות לרשת ממכולות Windows Server, יכול להיות שהסיבה לכך היא שרשת המכולות של Windows Server מניחה לעיתים קרובות MTU של רשת בגודל 1500, שלא תואם ל-MTU של Google Cloudבגודל 1460.

בודקים שערך ה-MTU של ממשק הרשת במאגר ושל ממשקי הרשת בצומת Windows Server עצמו מוגדרים לאותו ערך (כלומר, 1460 או פחות). מידע על הגדרת MTU מופיע במאמר בנושא בעיות מוכרות במאגרי Windows.

בעיות בהפעלה של צומת

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

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

gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE

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

  • ‫NODE_NAME: השם של הצומת.
  • ‫COMPUTE_ZONE: אזור המחשוב של הצומת הספציפי.

שירותים שלא ניתן להגיע אליהם לסירוגין בצמתי Windows עם אשכול שפועל בגרסה 1.24 או בגרסה מוקדמת יותר

כשמפעילים צמתי Windows באשכולות Kubernetes עם מספר גדול של כללים של מאזן עומסים של שירות רשת מארח, יש עיכוב בעיבוד הכללים. במהלך העיכוב, שנמשך כ-30 שניות לכל כלל, אי אפשר לגשת לשירותים לסירוגין. אם יש מספיק כללים, העיכוב הכולל יכול להיות משמעותי. מידע נוסף זמין בבעיה המקורית ב-GitHub.

באשכולות GKE שמריצים גרסה 1.24 או גרסה מוקדמת יותר, עם צמתים של Windows שהיה בהם אירוע שהפעיל מחדש את kube-proxy – לדוגמה, הפעלה של צומת, שדרוג של צומת, הפעלה מחדש ידנית – לא תהיה גישה לשירותים שאליהם מגיעים דרך Pod שפועל בצומת הזה, עד שכל הכללים יסונכרנו על ידי הרכיב.

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

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