Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

מדריך למשתמש למאגרי צמתים של מערכת הפעלה Windows Server

בעזרת Google Distributed Cloud, אתם יכולים ליצור מאגר צמתים של צמתים במערכת ההפעלה Windows Server. באשכול המשתמש שבו פועלים מאגרי הצמתים של מערכת ההפעלה Windows Server יכולים לפעול גם מאגרי צמתים שמכילים צמתים שמשתמשים ב-Ubuntu או במערכת הפעלה שמותאמת לקונטיינרים.

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

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

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

לפני שיוצרים מאגר צמתים של Windows, צריך לוודא שקיים כבר אשכול אדמין, כי מאגר צמתים של Windows נתמך רק באשכול המשתמשים.
ב-cluster של המשתמשים צריך להפעיל לפחות מאגר צמתים של Linux, כי מאגר הצמתים של Linux נדרש ליצירת מאגר צמתים של Windows.
ב-user cluster עם מאגרי צמתים של Windows, השדה enabledataplanev2 צריך להיות מוגדר לערך true בקובץ התצורה של ה-user cluster. ההגדרה הזו מפעילה את Dataplane V2 בצמתי Linux באותו אשכול.
כברירת מחדל, Windows Dataplane V2 מופעל במאגרי הצמתים של Windows באשכולות משתמשים חדשים.
הורדתם קובץ ISO של Windows Server 2019 מ-Microsoft כדי ליצור תבנית של VM שספציפית למאגרי צמתים של Windows. תג השפה או האזור של ה-ISO חייב להיות en-US.
סביבת vSphere צריכה להיות vSphere 6.7, ‏ Update 3 ואילך.
יש מגבלות על מאגרי צמתים של מערכת הפעלה Windows Server:
- אין תמיכה ב-IPv6.
- אין תמיכה במאגרי צמתים של Windows באשכולות מתקדמים.

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

שלב 1: יצירת תבנית של מכונה וירטואלית עם Windows ל-Google Distributed Cloud

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

יוצרים תבנית בסיס של מכונה וירטואלית של Windows מקובץ ה-ISO של Windows Server 2019.
- סוג מתאם הרשת הראשוני של מכונת ה-VM של Windows להתקנת Windows Server 2019 ISO צריך להיות E1000E.
- פועלים לפי השלבים הבאים: יצירת תבנית VMware vSphere ל-Windows Server 2019.
- חשוב לשים לב לסיסמה הראשונית שמוגדרת כשמריצים את קובץ ה-ISO של Windows לצורך התקנה, כדי להשתמש בה בעתיד.
- מוודאים שאתם משתמשים בגרסת התיקון המוסמכת העדכנית ביותר ל-Windows Server 2019. כדי לגלות מהי גרסת תמונת מערכת ההפעלה המוסמכת העדכנית ביותר של Windows לגרסה מסוימת של Anthos, אפשר לעיין בהערות הגרסה. מידע על תהליך תיקון האבטחה
- אי אפשר לצרף תבנית של מכונה וירטואלית בסיסית למכשיר שמשתמש בבקר IDE.
אם עדיין לא התקנתם את VMware Tools, צריך להתקין אותם בתבנית הבסיסית של מכונת Windows וירטואלית. מידע נוסף מופיע במאמר בנושא התקנה ידנית של VMware Tools ב-Windows במסמכי VMware.
יוצרים תבנית של מכונת Windows וירטואלית:
```
gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫BASE_WINDOWS_VM_TEMPLATE: הנתיב לתבנית הבסיס של מכונת Windows וירטואלית
- ‫BUNDLE: הנתיב לקובץ החבילה של Google Distributed Cloud
במסגרת בניית תבנית הבסיס של מכונת Windows וירטואלית, gkectl prepare windows מריץ את Windows sysprep. הפעולה הזו יוצרת הכללה של תבנית המכונה הווירטואלית ומנקה את הגדרות הרשת של המכונה הווירטואלית, וכך עוזרת למנוע התנגשויות בכתובות IP כשמבצעים שיבוט של מכונות וירטואליות מאותה תבנית. עם זאת, Windows sysprep פועל כקופסה סגורה, ולכן קשה לטפל בכשלים מסוימים של sysprep.

אם רוצים ליצור תבנית בסיס של מכונה וירטואלית של Windows בלי להפעיל את Windows sysprep, צריך לכלול את --skip-sysprep בפקודה gkectl prepare windows.
בשורה האחרונה של פלט הפקודה, אפשר למצוא את השם של תבנית מכונת ה-VM של Windows שנוצרה. חשוב לזכור את השם, כי צריך להשתמש בו באחד מהשלבים הבאים. השם הוא בפורמט הבא:
```
Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"
```

שלב 2: העלאה של קובצי אימג' לקונטיינרים של Windows למאגר פרטי

אם אתם לא משתמשים במאגר פרטי, אפשר לדלג על השלב הזה.

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

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

gkectl prepare --config <var class="edit">ADMIN_CLUSTER_CONFIG</var> --upload-windows-images

מחליפים את ADMIN_CLUSTER_CONFIG בנתיב לקובץ התצורה של אשכול האדמין.

הדגל --upload-windows-images מציין שקובצי אימג' של קונטיינרים של Windows יידחפו. רק תמונות של קונטיינרים של Linux יידחפו למאגר הפרטי בלי לציין את הדגל הזה.

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

לפני שמנסים לבצע את השלבים האלה, צריך להשתמש במחשב Windows שמותקן בו Docker ושיש לו גישה אל gcr.io. אפשר למשוך תמונות של קונטיינרים של Windows רק למכונת Windows.
מריצים את הפקודה docker login כדי לבצע אימות בפני הרישום הפרטי.
כדי להעלות את תמונות מאגר Windows יחד עם שכבות הבסיס שלהן למאגר הפרטי, פועלים לפי השלבים הבאים:
- עוברים לקובץ Docker daemon.json במחשב Windows:
```
PS C:> cat C:\ProgramData\docker\config\daemon.json
```
- מוסיפים את השורות הבאות לקובץ Docker daemon.json כדי לאפשר העלאה של שכבות חיצוניות למאגר הפרטי:
```
{
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
```
- מורידים את קובצי האימג' הנדרשים של Windows Container למחשב Windows המקומי, ואז מתייגים אותם ומעבירים אותם בדחיפה למאגר הפרטי. השינויים שביצעתם בקובץ התצורה של daemon.json Docker מאפשרים לדחוף את שכבת הבסיס למאגר הפרטי. כדי להשלים את המשימות האלה, מריצים את הפקודות הבאות:

# Pull the Windows container images
docker pull gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Tag the images to use private registry
docker tag gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019 $PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker tag gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019 $PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker tag gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019 $PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

שלב 3: (חובה אם משתמשים ב-proxy) הוספה לרשימת ההיתרים של כתובות URL ליצירת מאגרי צמתים של Windows

אם האשכול שלכם נמצא מאחורי שרת proxy, צריך להוסיף את כתובות ה-URL האלה לרשימת ההיתרים של שרת ה-proxy, בנוסף לכתובות אחרות שנדרשות ל-Google Distributed Cloud.

# Microsoft registry URLs, needed by every Windows node if using GCR
mcr.microsoft.com
.data.mcr.microsoft.com
go.microsoft.com
winlayers.cdn.mscr.io

# Microsoft WSUS server URLs, needed by `gkectl prepare windows` on the Windows VM
windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.update.microsoft.com
.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com

# Cloudbase-Init URL, needed by `gkectl prepare windows` on the Windows VM
https://cloudbase.it

# Powershell Gallery URLs, needed by `gkectl prepare windows` on the Windows VM
psg-prod-eastus.azureedge.net
az818661.vo.msecnd.net
devopsgallerystorage.blob.core.windows.net
.powershellgallery.com

# Windows Update Service, needed by `gkectl prepare windows` on the Windows VM
onegetcdn.azureedge.net
sws.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
fe3.delivery.mp.microsoft.com
.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
adl.windows.com
activation-v2.sls.microsoft.com
crl.microsoft.com
ocsp.digicert.com
ctldl.windowsupdate.com
login.live.com
licensing.mp.microsoft.com
www.msftconnecttest.com
settings-win.data.microsoft.com
wdcp.microsoft.com
smartscreen-prod.microsoft.com
checkappexec.microsoft.com
arc.msn.com
ris.api.iris.microsoft.com
.tlu.dl.delivery.mp.microsoft.com
.au.windowsupdate.com
www.microsoft.com
fe3.delivery.dsp.mp.microsoft.com.nsatc.net
cs9.wac.phicdn.net
geo-prod.do.dsp.mp.microsoft.com
slscr.update.microsoft.com
v10.events.data.microsoft.com

# Access for Installing docker, needed by `gkectl prepare windows` on the Windows VM
dockermsft.azureedge.net

שלב 4: מוסיפים מאגר צמתים של Windows לקובץ ההגדרה של אשכול המשתמשים

כדי להשתמש במאגרי צמתים של Windows, צריך להפעיל את Dataplane V2 באשכול המשתמשים. כדי להפעיל את Dataplane V2, מוסיפים את השורה הבאה לקובץ התצורה של אשכול המשתמשים:
```
enableDataplaneV2: true
```
מוסיפים מאגר צמתים של Windows לקטע nodePools בקובץ התצורה של אשכול המשתמשים. בנוסף למאגרי הצמתים של Windows, צריך לפחות מאגר צמתים אחד של Linux. כדי ליצור מאגרי צמתים של Windows, מגדירים את השדות osImage ו-osImageType:

‫osImage: מחליפים את WINDOWS_VM_TEMPLATE_NAME בשם של תבנית מכונת ה-VM של Windows שהוכנה בשלב 1, שאמורה להיות באותו מאגר נתונים של vCenter שצוין בקובץ התצורה של אשכול המשתמשים.
‫osImageType: מציינים שסוג תמונת מערכת ההפעלה הוא windows.

# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 8
  memoryMB: 16384
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

שלב 5: יצירת מאגרי צמתים של Windows

לפני שיוצרים מאגרי צמתים של Windows, מריצים רשימה של כלי אימות קדם-הפעלה עבור Windows. אם כבר יש לכם אשכול משתמשים, אפשר לדלג על השלב הזה. ‫– (אופציונלי) מריצים את בדיקות קדם-ההפעלה המהירות או האיטיות, או את שתיהן, שיוצרות VM לבדיקה עבור Windows ומאמתות את תבנית ה-VM של Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

הפקודה הזו מיועדת להרצה לפני יצירת אשכול משתמשים. אם כבר יש לכם אשכול משתמשים, יכול להיות שחלק מהבדיקות ייכשלו. לדוגמה, יכול להיות שכתובות ה-IP בקובץ hostconfig.yaml כבר נמצאות בשימוש על ידי צמתים קיימים באשכול המשתמשים.
אפשר לדלג על בדיקות קדם-הפעלה ב-Windows באמצעות הדגל --skip-validation-windows, אבל לא מומלץ לעשות זאת.
הניהול של מאגרי צמתים של Windows זהה לניהול של מאגרי צמתים של Linux. מידע נוסף זמין במדריך למשתמש בנושא מאגרי צמתים של מערכת ההפעלה Windows Server. הפקודות ליצירה, לעדכון ולשדרוג של אשכולות ושל מאגרי צמתים נשארות ללא שינוי ומפורטות כאן.

# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Update an existing cluster with the new Windows node pool
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

שלב 6: בדיקה שהצמתים של Windows פועלים

בודקים שצמתי Windows נוצרו ושהם Ready.
```
kubectl --kubeconfig USER_KUBECONFIG get nodes
```

מאבחנים את אשכול המשתמשים כדי לבדוק אם הוא תקין.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG  --cluster-name CLUSTER_NAME

פריסת Pod של Windows

צמדי המפתח/ערך הבאים node.kubernetes.io/os=windows:NoSchedule מוגדרים כ-taint בצמתי Windows Server.

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

nodeSelector:
    kubernetes.io/os: windows

אחרי שמגדירים את nodeSelector, ווּבּוּק (webhook) של הרשאות גישה שפועל באשכול בודק אם יש עומסי עבודה חדשים שכוללים את בורר הצמתים של Windows. אם נמצאים עומסי עבודה כאלה, הווּבּוּק מחיל עליהם את ההגדרה הבאה של טולרנטיות, שמאפשרת להם לפעול בצמתים של שרתי Windows עם דחייה (taint):

tolerations:
- key: "node.kubernetes.io/os"
  operator: "Equal"
  value: "windows"
  effect: "NoSchedule"

שלב 1: יצירת קובץ פריסה של Internet Information Services ‏ (IIS)

הנה דוגמה להגדרה שפורסת את תמונת ה-IIS הרשמית של מיקרוסופט ל-Pod יחיד.

יוצרים קובץ IIS בשם iis.yaml עם התוכן הבא:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: iis
  name: iis
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: iis
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: [Fill in with an available IP address]

שלב 2: יצירת הפריסה וחשיפתה באמצעות שירות

# Create the deployment
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG create -f iis.yaml

שלב 3: מאמתים את ה-Pod

בודקים את הסטטוס של ה-Pod באמצעות kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

ממתינים עד שהפלט שמוחזר יראה שהסטטוס של ה-Pod הוא 'פועל'.

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

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

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   35.x.x.x     80:32233/TCP   17s

אפשר להשתמש בדפדפן כדי לפתוח את הכתובת http://EXTERNAL_IP ולראות את דף האינטרנט של IIS.

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

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

במהלך השדרוג, אפשר לעדכן את גרסת ה-build של תיקון האבטחה של תבנית ה-VM הבסיסית על ידי הורדה של גרסת תיקון אבטחה חדשה יותר של Windows Server 2019 מ-Microsoft. מידע על תהליך תיקון האבטחה

‫

gkectl prepare windows --base-vm-template $BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG

מעדכנים את השדה osImage של מאגר הצמתים בקובץ התצורה עם השם החדש של תבנית מכונת ה-VM. מריצים את הפקודה הבאה כדי לשדרג את אשכול המשתמשים:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

‫ADMIN_CLUSTER_KUBECONFIG עם הנתיב של קובץ ה-kubeconfig של האדמין
‫ADMIN_CLUSTER_CONFIG עם הנתיב של קובץ התצורה של אשכול האדמין

גישה לצמתים של Windows

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

בצמתים של Windows ב-vSphere, שם המשתמש הוא Administrator. הסיסמה נוצרת על ידי clusterapi-controller ונשמרת בסוד windows-node-password במרחב השמות של המשתמש באשכול Admin. הפקודה לקבלת הסיסמה מהסוד הזה היא:

kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d

אפשר גם לקבל את הסיסמה באמצעות ממשק המשתמש של vCenter. עוברים למכונה הווירטואלית שאליה רוצים להיכנס, ואז אפשר למצוא את הסיסמה בpasswordמאפיין vApp של המכונה הווירטואלית הזו.

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

שימוש ב-Remote Desktop Protocol

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

שימוש ב-SSH

כדי להתחבר ב-SSH ל-VM של Windows:

ssh Administrator@[VM_IP_ADDRESS]

פועלים לפי ההנחיה להקלדת הסיסמה כדי להתחבר ל-VM.

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

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

העלאת קבצים ל-VM של Windows:

scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]

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

scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]

מקלידים את הסיסמה כשמוצגת בקשה לעשות זאת.

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

עדכון ההגדרה של Windows Server

החל מגרסה 1.11,‏ Containerd ו-Windows Dataplane V2 זמינים לכלל המשתמשים.

‫Docker ו-Flannel לצמתים של Windows יוצאו משימוש בגרסה הבאה. מומלץ לעדכן את ההגדרה עכשיו, אם רלוונטי, כדי להשתמש ב-containerd וב-Windows Dataplane V2 במקום זאת. אפשר לעיין במאמר בנושא עדכון ההגדרה של Windows Server.

אי אפשר להתחבר ב-SSH או ב-RDP למכונה וירטואלית של Windows

בודקים אם יש למכונה הווירטואלית חיבור לרשת על ידי הפעלת Test-NetConnection במסוף האינטרנט של vCenter.

התוצאה צריכה להכיל PingSucceeded: true אם יש חיבור לרשת. אם למכונה הווירטואלית אין חיבור לרשת, צריך לבדוק את מתאם הרשת שמשמש את המכונה הווירטואלית. מוודאים שהרשת מאפשרת חיבורים נכנסים ל-VM מתחנת העבודה שבה רוצים להריץ את SSH/RDP.

מוודאים ששירותי kubelet,‏ kube-proxy ו-CNI פועלים במכונה הווירטואלית של Windows

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

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

# Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy

אם האשכול מוגדר עם windowsDataplaneV2 שמוגדר ל-true, צריך לוודא שהשירותים antrea-agent, ‏ ovsdb-server ו-ovs-vswitchd פועלים.
```
# Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd
```
אחרת, בודקים שהתהליך flanneld הוא 'Running':
```
# Check that the flanneld process exists
Get-Process flanneld
```

שימוש בכלי הצילום

משתמשים בכלי ליצירת תמונת מצב כדי ליצור את קובץ ה-tar.gz של תמונת המצב. קובץ ה-tarball הזה מכיל את קובצי היומן בצמתים, וגם פלט של פקודות לפתרון בעיות שמופעלות בצומת.

gkectl diagnose snapshot --scenario system-with-logs --cluster-name [USER_CLUSTER_NAME] --kubeconfig [PATH_TO_KUBECONFIG]

יצירת מכונת VM של Windows נכשלת

בודקים את היומנים מהקונטיינר vsphere-controller-manager ב-Pod clusterapi-controllers במרחב השמות של המשתמש באשכול האדמין.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME logs clusterapi-controllers-POD_NAME_SUFFIX vsphere-controller-manager

מוודאים שתבנית ה-VM נמצאת באותו מרכז נתונים ובאותו מאגר נתונים שצוינו בקובץ התצורה של אשכול המשתמשים.

מכונה וירטואלית של Windows נוצרת, אבל הצומת לא מופעל בצורה תקינה או לא מופיע

בודקים את יומני ההפעלה בצומת שנמצא במיקום C:\var\log\startup.log כדי לראות אם משהו נכשל בהפעלה.
- אם flanneld לא פועל, מנסים להריץ מחדש את סקריפט לטעינה בזמן ההפעלה שנמצא ב-C:\etc\startup\startup-script.ps1
- אם kubelet לא פועל, בודקים את היומנים של kubelet ב-C:\var\log.
- אם kube-proxy לא פועל, כדאי לבדוק את היומנים של kube-proxy ב-C:\var\log.
לפני שמריצים את סקריפט לטעינה בזמן ההפעלה, בודקים אם הפקודה UserDataPlugin כבר הופעלה על ידי cloudbase-init.

כדי לבדוק את זה, צריך להתחבר למכונת ה-Windows הווירטואלית באמצעות SSH ולהריץ את הפקודה הבאה:

ls "HKLM:\\Software\Cloudbase Solutions\Cloudbase-Init\id-ovf\"

אם מופיע UserDataPlugin: 1 בפלט, המשמעות היא שהתוסף cloudbase-init כבר הופעל, ולכן הביצוע של סקריפט לטעינה בזמן ההפעלה ידלג על השלב הזה, והצומת של Windows לא יופעל בכלל.

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

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

רישום ביומן ומעקב

‫Google Distributed Cloud תומך ברישום ביומן ובמעקב של צמתי Windows ו-Pods, כמו שהוא תומך בצמתי Linux ו-Pods.

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

סוכן Logging ל-Windows

סוכן רישום היומנים של Windows אוסף את היומנים הבאים:

סוג המשאב של ה-Pod: עומסי עבודה של מערכת ואפליקציות של משתמשים.

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

עורכים את fluent-bit-windows-config configmap ומוסיפים הערה לפריט [Input] שאוסף את יומני האפליקציה (הפריט [Input] הראשון):

kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system

חשוב להוסיף הערה לכל השדות שמתחת לפריט הזה. לדוגמה:

#    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?<podname>[a-z0-9](?:[-a-z0-9][a-z0-9])?(?:.[a-z0-9]([-a-z0-9][a-z0-9])?)*)(?<namespacename>[^]+)_(?<container_name>.+)-(?<docker_id>[a-z0-9]{64}).log$
#      Tag                k8s_container.<namespace_name>.<pod_name>.<container_name>
#      Path               C:\var\log\containers\*.log
#      Exclude_Path       kube-system.log,gke-connect.log,knative-serving.log,gke-system.log,istio-system.log,monitoring-system.log,config-management-system.log,gatekeeper-system.log,cnrm-system.log
#      DB                 C:\var\log\fluent-bit-k8s-container-application.db
#      Mem_Buf_Limit      30MB
#      Skip_Long_Lines    On
#      Refresh_Interval   10
#      # storage.type       filesystem
#      Buffer_Chunk_Size  512KB
#      Buffer_Max_Size    5M
#      Rotate_Wait        30
#      Ignore_Older       4h

מריצים את הפקודה rollout restart כדי להפעיל מחדש את fluent-bit-windows daemonset:
```
kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system
```

סוג המשאב של הצומת: kubelet, ‏ kube-proxy ויומני אירועים של Windows

אפשר לגשת ליומנים באמצעות Logs Explorer במסוף. מידע נוסף זמין במאמר בנושא יומני גישה.

סוכן לניטור Windows

סוכן הניטור של Windows אוסף קבוצה שונה של מדדים לגבי השימוש במעבד ובזיכרון בהשוואה לסוכן הניטור של Linux. כדי לעקוב אחרי הסטטוס של צמתי Windows ושל Pods, אפשר להשתמש בלוחות הבקרה המוכנים. במסוף, בוחרים באפשרות Monitoring > Dashboards (מעקב > לוחות בקרה), ואז בוחרים באפשרות GKE on-prem Windows node status (סטטוס של צומת Windows ב-GKE on-prem) ובאפשרות GKE on-prem Windows pod status (סטטוס של פוד Windows ב-GKE on-prem) מהרשימה All Dashboards (כל לוחות הבקרה).

לוחות הבקרה האלה נוצרים באופן אוטומטי במהלך ההתקנה של אשכול האדמין אם Cloud Monitoring מופעל. אם כבר מופעל אצלכם אשכול אדמין, אפשר לפעול לפי ההוראות האלה כדי ליצור את לוחות הבקרה האלה באמצעות קובצי ה-JSON הבאים:

הרשימה המלאה של המדדים שנאספים על ידי סוכני Windows

אחסון מתמיד ב-Windows

כשעובדים עם קונטיינרים של Windows Server עם אחסון קבוע, צריך ליצור אובייקט StorageClass ולציין את השם של האובייקט הזה בשדה storageClassName של האובייקט PersistentVolumeClaim, כי ברירת המחדל StorageClass באשכול משתמשים מקומי משתמשת ב-ext4 כסוג מערכת הקבצים, שפועל רק בקונטיינרים של Linux. ב-Windows, צריך להגדיר את סוג מערכת הקבצים ל-ntfs.

דוגמה לסוג אחסון ב-Windows:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-storage-class
provisioner: kubernetes.io/vsphere-volume
parameters:
  datastore: my-datastore
  diskformat: thin
  fstype: ntfs

שרת ה-Proxy של CSI נפרס אוטומטית בצמתי Windows. אתם יכולים להתקין ולהשתמש במנהל התקן CSI של Windows לפי בחירתכם, כמו מנהל התקן ה-CSI של SMB.

Node Problem Detector בצמתי Windows

הדמון Node Problem Detector זמין בצמתי Windows. אם שדרגתם לגרסה 1.9, הכלי Node Problem Detector מופעל באופן אוטומטי. הכלי Node Problem Detector עוזר לזהות במהירות כמה בעיות נפוצות בצמתים. הכלי Node Problem Detector ממשיך לבדוק אם יש בעיות אפשריות ומדווח עליהן כאירועים ותנאים בצומת. אם צומת מתנהג בצורה לא תקינה, אפשר להשתמש בפקודה kubectl כדי למצוא את האירועים והתנאים התואמים.

הגדרות המעקב הבאות מופעלות ב-Node Problem Detector:

כדי לקבל אירועים ותנאים בצומת:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

מחליפים את:

‫KUBECONFIG עם הנתיב של קובץ ה-kubeconfig של האשכול שמכיל את הצומת.
‫NODE_NAME בשם הצומת.

כדי לזהות את האירועים שנוצרו על ידי כלי המעקב של Node Problem Detector, מחפשים את שם כלי המעקב בשדה reason של כלל שצוין בקטע rules.

בנוסף, התנאים הבאים נוצרים בצומת על ידי המעקב של Node Problem Detector. כל אחד מהם מוגדר ל-true אם הכלי Node Problem Detector מזהה את תרחיש הכשל המתאים בצומת.

KubeletUnhealthy
KubeProxyUnhealthy
ContainerRuntimeUnhealthy

אם אחד מהתנאים מוגדר כ-true, התנאי Ready של הצומת יהפוך ל-false, וכך לא ניתן יהיה לתזמן יחידות Pod חדשות בצומת.

כשמתגלה מצב לא תקין, הכלי Node Problem Detector מנסה לתקן את הצומת באופן אוטומטי על ידי הפעלה מחדש של שירות המערכת הרלוונטי.

היומנים של Node Problem Detector נמצאים בתיקייה C:\var\log\node-problem-detector של הצומת. אם רישום ביומן ומעקב מופעלים, היומן מיוצא ל-Cloud Logging ואפשר לראות אותו ב-Logs Explorer.

כדי לקבל יומנים של Node Problem Detector ב-Logs Explorer, משתמשים במסנן הזה:

resource.type="k8s_node"
log_name="projects/PROJECT_NAME/logs/node-problem-detector"

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

תהליך תיקון האבטחה

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

תהליך תיקון האבטחה כולל את השלבים הבאים:

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

צירוף לדומיין של Active Directory

כדי להצטרף לדומיין Active Directory, אורך שם המארח של המכונה הווירטואלית צריך להיות 15 תווים או פחות. במצב IPAM, שם המארח של מכונת ה-VM מוגדר בקובץ התצורה של אשכול המשתמשים, ולכן צריך לוודא שהאורך שלו הוא 15 תווים או פחות. ההוראות האלה מבוססות על ההוראות ליצירת מאגרי צמתים של Windows, עם השלב הנוסף של אספקת סקריפט מותאם אישית במהלך יצירת תבנית Windows VM.

אימות שאפשר להגיע לשרת ה-DNS של הדומיין הפעיל

שירותי הדומיין של Active Directory ‏ (AD DS) משתמשים בשירותי פענוח שמות של מערכת שמות דומיין (DNS) כדי לאפשר ללקוחות לאתר בקרי דומיין, ולבקרי הדומיין שמארחים את שירות הספריות לתקשר זה עם זה.

שרת ה-DNS נוצר כשמותקן יער הבסיס בתפקיד AD DS. כדי שמכונה וירטואלית של Windows תצטרף לדומיין AD, היא צריכה להיות מסוגלת להגיע לשרת ה-DNS. מגדירים את ה-DNS ואת חומת האש בהתאם להנחיות של ספק שירותי ה-DNS שבו אתם משתמשים. כדי לוודא שהמכונות הווירטואליות של Windows ברשת הנוכחית יכולות ליצור קשר עם שרת ה-DNS של דומיין ה-AD, מריצים את הפקודה הבאה:

PS C:\> nslookup DOMAIN_NAME DOMAIN_SERVER_IP
Server:  example-1-2-3-4.anthos
Address:  1.2.3.4
Name:    example.org
Address:  1.2.3.4

שלב 1: יצירת תבנית של מכונת Windows וירטואלית עם סקריפט בהתאמה אישית

הפעלת סקריפט מותאם אישית לפני שהצומת של Windows מצטרף לאשכול המשתמשים לצורך הצטרפות לדומיין של Active Directory. מאחסנים את הסקריפט הזה בנתיב מקומי בתחנת העבודה של האדמין. חשוב לדעת:
- אתם יכולים להחליף את הסקריפט בסקריפט משלכם כדי לבצע הצטרפות לדומיין Active Directory.
- מומלץ להשתמש בחשבון משתמש עם ההרשאות המינימליות שנדרשות לצירוף לדומיין של Active Directory, במקום להשתמש בחשבון משתמש עם הרשאת אדמין.
- (אופציונלי) כדי להימנע מאחסון הסיסמה כטקסט לא מוצפן בסקריפט הזה, אפשר להציב את הסיסמה בקובץ בתבנית של VM, לאפשר לסקריפט לקרוא מהקובץ הזה ואז למחוק את הקובץ אחרי הצטרפות לדומיין.
```
$domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force
```

יצירת תבנית של מכונה וירטואלית עם Windows באמצעות סקריפט בהתאמה אישית:

gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG --customized-script CUSTOMIZED_SCRIPT_PATH

מחליפים את הערך ב-BUNDLE_PATH בנתיב לחבילה.

שלב 2: יצירת מאגר צמתים של Windows

ממשיכים לפי ההוראות הרגילות בשלבים 2-6 כדי ליצור מאגר צמתים של Windows באמצעות תבנית מותאמת אישית של מכונה וירטואלית של Windows.

שלב 3: אימות ההצטרפות של הדומיין הפעיל לצמתי Windows

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

PS C:\> Get-ADComputer -Filter 'Name -like "user-host-prefix*"'

DistinguishedName : CN=AD-VM-1,CN=Computers,DC=example,DC=org
DNSHostName       : ad-vm-1.example.org
Enabled           : True
Name              : AD-VM-1
ObjectClass       : computer
ObjectGUID        : b3609717-d24b-4df6-bccb-26ca8e8b9eb0
SamAccountName    : AD-VM-1$
SID               : S-1-5-21-3236879623-1561052741-2808297733-1103

שלב 4: הגדרת חשבונות שירות מנוהלים לקבוצה (אופציונלי)

פועלים לפי ההוראות האלה: הגדרת GMSA עבור קובצי Pod ומאגרי Windows. אפשר להגדיר GMSA עבור תרמילים וקונטיינרים של Windows אחרי שהצמתים מצטרפים לדומיין.

פתרון בעיות

יומנים של הפעלת סקריפט בהתאמה אישית של cloudbase-init נמצאים בכתובת C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. חפשו את LocalScriptPlugin בקובץ היומן ובדקו את הרישומים שקשורים אליו. – יצירת תבנית חדשה של מכונה וירטואלית עם Windows. ‫- מעדכנים את מאגרי הצמתים של Windows כדי להשתמש בתבנית החדשה על ידי הפעלת הפקודה:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

שיקולים לגבי קונטיינרים של Windows

ההבדלים העיקריים בין קונטיינרים של Windows ושל Linux הם:

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

מגבלות של Google Distributed Cloud ב-vSphere Windows

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

בעיות ידועות

בקטע הזה מפורטות בעיות מוכרות בצמתים של Windows שמשמשים עם Google Distributed Cloud, וגם פתרונות עקיפים שיעזרו לכם להימנע מהבעיות האלה או לפתור אותן.

אי אפשר ליצור קשר בין Windows Pods לכתובות IP חיצוניות

הבעיה הזו מתוארת במסמכי Microsoft, שבהם מצוין: "צריך להחריג את כתובת ה-IP החיצונית שמנסים לשלוח אליה שאילתה מהרשימה ExceptionList".

כדי להמשיך עם פתרון עקיף, צריך לפנות לתמיכה של Google Cloud.

לא מתבצע ניקוי של קונטיינרים של Windows אחרי הסרת Windows Pods

זו בעיה מוכרת שבה docker RemoveContainer מנסה גם לקרוא ל-CreateFile ב-Windows. כפתרון עקיף, אפשר להתחבר לצומת Windows שבו הבעיה מתרחשת, להריץ את הפקודה Restart-Service docker והבעיה תיפתר. החל מ-Google Distributed Cloud 1.9, גרסת קובץ האימג' של הקונטיינר fluent-bit-win וגרסת Docker עודכנו כדי לכלול את התיקונים במעלה הזרם לבעיה הזו, ולכן היא לא אמורה להתרחש יותר. אם אתם נתקלים בבעיה הזו, פנו לתמיכה של Google Cloud.

צמתים של Windows שבהם יש התנגשויות בכתובות IP

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

אם אתם משתמשים במצב IPAM, אתם יכולים להסיר באופן ידני מ-vCenter את מכונות ה-VM שבהן יש התנגשויות בכתובות ה-IP. מערכת תצורת כתובות ה-IP תצור מכונות VM חדשות באופן אוטומטי, שאמורות לקבל הקצאות נכונות של כתובות IP. אפשר גם לחכות עד שהתיקון האוטומטי של הצומת יזהה את הבעיה וייצור מחדש את צמתי Windows.
אם אתם משתמשים במצב DHCP, סביר להניח שלמכונות הווירטואליות החדשות שנוצרו יהיו שוב כתובות IP כפולות, כי יש בעיות בהקצאת כתובות IP בשרת ה-DHCP. אתם יכולים למחוק את מאגר הצמתים של Windows שנמצא בהמתנה על ידי הפעלת הפקודה gkectl update cluster, להוסיף אותו בחזרה לקובץ user-cluster.yaml ולהפעיל שוב את הפקודה gkectl update cluster כדי ליצור אותו. למאגר הצמתים החדש שנוצר אמורות להיות הקצאות כתובות IP תקינות.

צומת Windows עובר למצב NotReady אחרי הפעלה מחדש של המכונה הווירטואלית

בשלב הזה, סקריפט לטעינה בזמן ההפעלה של הצומת פועל רק בפעם הראשונה שמפעילים את ה-VM. לכן, אם מפעילים מחדש את ה-VM, סקריפט לטעינה בזמן ההפעלה של הצומת לא פועל שוב. הפעולה הזו תגרום להפסקת הפעולה של חלק משירותי Windows, כולל שירותי kubelet,‏ kube-proxy וכו'. כתוצאה מכך, הצומת נמצא בסטטוס NotReady. אם אתם משתמשים ב-Windows Dataplane V2, צריך גם לפנות את הרשת הלא פעילה לפני שאפשר להפעיל מחדש את שירותי Dataplane V2, ויהיה צורך להריץ סקריפט לניקוי נתונים, מה שעלול לגרום לסיבוכים. לכן, צריך ליצור מחדש את הצומת. כדי לעקוף את הבעיה, אפשר למחוק את הצומת על ידי הפעלת הפקודה שבהמשך, ולהמתין עד שהבקר ייצור אותו מחדש באופן אוטומטי.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

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

אם תבנית המכונה הווירטואלית של Windows משתמשת בגרסה ישנה של חומרה, הפקודה gkectl diagnose cluster תיכשל ותוצג ההודעה הבאה:

Checking storage...FAILURE
    Reason: 1 storage error(s).
    Unhealthy Resources:
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue. Use --detailed=true for the list of VMs.
    Debug Information:
    {
      "NODE_NAME": "vmx-XX",
    }

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

משנים את השם של תבנית המכונה הווירטואלית שנמצאת בשימוש.

הפעולה הזו נדרשת כדי ליצור תבנית חדשה של מכונה וירטואלית בשלבים הבאים.
להמיר את תבנית הבסיס של מכונה וירטואלית של Windows למכונה וירטואלית.
כדי לשדרג את גרסת החומרה של המכונה הוירטואלית, פועלים לפי השלבים במאמר בנושא שדרוג מכונה וירטואלית לגרסת החומרה העדכנית ביותר.
ממירים את ה-VM בחזרה לתבנית VM.
מריצים את הפקודה הבאה כדי להכין תבנית חדשה של מכונה וירטואלית, באמצעות תבנית המכונה הווירטואלית המשודרגת מהשלבים הקודמים כתבנית הבסיס של המכונה הווירטואלית.
```
gkectl prepare windows
```
השם החדש של תבנית מכונת ה-VM שנוצרה צריך להיות זהה לערך השדה osImage בקובץ התצורה של אשכול המשתמשים. אם הערכים זהים, ממשיכים לשלב הבא כדי ליצור מחדש את צומת Windows.

אם שם התבנית לא תואם לערך בשדה osImage, צריך לעדכן את הערך osImage כך שיתאים לשם החדש של תבנית המכונה הווירטואלית שנוצרה ולהריץ את הפקודה הבאה:
```
gkectl update cluster
```
יוצרים מחדש את צומת Windows על ידי הפעלת הפקודה הבאה:
```
kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
```
מחכים שהבקר ייצור מחדש את הצומת באופן אוטומטי.