יצירת אשכול באמצעות מאגרי צמתים של 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 (חשבון השירות שמשמש כברירת מחדל לצומת ב-Kubernetes Engine).
  7. לוחצים על Save.

gcloud

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

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

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

    12345678901
  2. מקצים לחשבון השירות של Compute Engine שמוגדר כברירת מחדל את התפקיד roles/container.defaultNodeServiceAccount: 
    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 2019 ‏ (LTSC) או בגרסה Windows Server 2022 ‏(LTSC). לכל אשכול יכולים להיות כמה מאגרי צמתים של Windows Server בגרסאות שונות של Windows Server, אבל כל מאגר צמתים יכול להשתמש רק בגרסה אחת של Windows Server.

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

  • זמני התמיכה:
  • תאימות ורמת מורכבות של הגרסה:

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

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

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

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

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

בגלל החשיבות של התוספים, מומלץ להפעיל את התכונה 'התאמה אוטומטית לעומס (automatic scaling)' כדי לוודא שלמאגר הצמתים של 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: גרסת האשכול הספציפית שבה רוצים להשתמש, שצריכה להיות 1.16.8-gke.9 ומעלה. אם לא מציינים ערוץ הפצה, מערכת GKE רושמת את האשכול לערוץ ההפצה הכי יציב שבו הגרסה הזו זמינה.
  • ‫CHANNEL: ערוץ ההפצה שאליו רוצים לרשום את האשכול. האפשרויות הן rapid, ‏regular, ‏stable או None. כברירת מחדל, האשכול רשום לערוץ ההפצה regular, אלא אם מציינים לפחות אחד מהדגלים הבאים: --cluster-version, ‏--release-channel, ‏--no-enable-autoupgrade ו---no-enable-autorepair. אם בוחרים גרסת אשכול ולא רוצים לרשום את האשכול לערוץ הפצה, צריך לציין None.

מומלץ מאוד לציין חשבון שירות 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 \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

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

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

בדוגמה הבאה אפשר לראות איך יוצרים מאגר צמתים של 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, בוחרים את האזור או התחום הרצויים בשביל האשכול.
    3. בקטע Control plane Version (גרסת מישור הבקרה), בוחרים Release channel (ערוץ הפצה) או בוחרים באפשרות לציין Static version (גרסה סטטית). הגרסה הסטטית צריכה להיות 1.16.8-gke.9 ומעלה.
  3. בחלונית הניווט, בקטע Node Pools (מאגרי צמתים), לוחצים על default-pool (מאגר ברירת המחדל) כדי ליצור את מאגר צמתי ה-Linux. כשמגדירים את מאגר הצמתים הזה, צריך לספק מספיק משאבי מחשוב כדי להריץ תוספים של אשכולות. בנוסף, צריך לוודא שיש לכם מכסת משאבים זמינה לצמתים ולמשאבים שלהם (כמו מסלולי חומת אש).
  4. בחלק העליון של הדף, לוחצים על Add Node Pool (הוספת מאגר צמתים) כדי ליצור את מאגר הצמתים של Windows Server.
  5. בקטע פרטים של מאגר הצמתים, משלימים את הפרטים הבאים:
    1. מזינים שם למאגר הצמתים.
    2. לצמתי גרסה סטטיים, בוחרים באפשרות Node version (גרסת הצומת).
    3. מזינים את מספר הצמתים שרוצים ליצור במאגר הצמתים.

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

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

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

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

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

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

    1. בקטע Automation (אוטומציה), מבטלים את הסימון בתיבה Enable node auto-upgrade (הפעלת שדרוג אוטומטי של הצומת). לפני שמפעילים את השדרוג האוטומטי, כדאי לעיין בקטע שדרוג מאגרי צמתים של Windows Server.

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

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

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

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. בתוך גרסה משנית של GKE, הגרסאות של LTSC בדרך כלל נשארות קבועות.

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

מומלץ להירשם לקבלת הודעות על שדרוגים באמצעות Pub/Sub כדי לקבל עדכונים באופן יזום על גרסאות חדשות של GKE ועל גרסאות מערכת ההפעלה Windows שבהן הן משתמשות.

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

עדכוני Windows

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

קביעת אופן התקשורת בין Windows 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.

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

אפשר ליצור את תמונות המולטי-ארכיטקטורה באופן ידני או להשתמש בכלי ליצירת תמונות ב-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 Pods וקונטיינרים.

מחיקה של מאגרי צמתים ב-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. כשמופיעה בקשת אישור, לוחצים שוב על מחיקה.

מגבלות

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

בנוסף לתכונות Kubernetes שלא נתמכות, יש גם כמה תכונות GKE שלא נתמכות.

בקלאסטרים של GKE, התכונות הבאות לא נתמכות במאגרי צמתים של Windows Server:

יכול להיות שמוצרים אחרים שרוצים להשתמש בהם עם אשכולות GKE לא תומכים במאגרי צמתים של Windows Server. Google Cloud הגבלות ספציפיות מפורטות במסמכי העזרה של המוצר.

פתרון בעיות

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

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

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

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

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

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

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

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

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

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

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

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