Nutzerhandbuch für Windows Server-Betriebssystem-Knotenpools

Mit Google Distributed Cloud können Sie einen Knotenpool mit Windows Server-Betriebssystemknoten erstellen. Der Nutzercluster, auf dem die Knotenpools des Windows Server-Betriebssystems ausgeführt werden, kann auch Knotenpools von Knoten mit Ubuntu oder einem Container-Optimized OS ausführen.

Anforderungen für einen Windows Server-Betriebssystem-Knotenpool

Die Knoten in einem Knotenpool müssen alle das gleiche Betriebssystem verwenden, das durch den Parameter osImageType angegeben wird.

Bevor Sie einen Knotenpool mit Windows Server-OS-Knoten in Ihrem Nutzercluster erstellen, müssen Sie folgende Anforderungen erfüllen:

  • Es muss bereits ein Admin-Cluster vorhanden sein, bevor Sie einen Windows-Knotenpool erstellen können, da ein Windows-Knotenpool nur im Nutzercluster unterstützt wird.
  • Der Nutzercluster muss mindestens einen Linux-Knotenpool ausführen, da der Linux-Knotenpool zum Erstellen eines Windows-Knotenpools erforderlich ist.
  • Bei einem Nutzercluster mit Windows-Knotenpools muss das Feld enabledataplanev2 in der Nutzercluster-Konfigurationsdatei auf true festgelegt sein. Dadurch wird Dataplane V2 auf den Linux-Knoten in diesem Cluster aktiviert.

  • Standardmäßig ist Windows Dataplane V2 für die Windows-Knotenpools für neue Nutzercluster aktiviert.

  • Sie haben ein Windows Server 2019-ISO von Microsoft heruntergeladen, um eine VM-Vorlage für Windows-Knotenpools zu erstellen. Das Sprach-/Regions-Tag für das ISO muss "en-US" sein.

  • Ihre vSphere-Umgebung muss vSphere Version 6.7, Update 3 oder höher sein.

Windows-Knotenpool in einem Nutzercluster erstellen

Schritt 1: Windows-VM-Vorlage für Google Distributed Cloud erstellen

Bevor Sie beginnen, sollten Sie einen Administratorcluster erstellt haben.

  1. Erstellen Sie eine Windows-VM-Basisvorlage aus dem Windows Server 2019-ISO.

    • Der anfängliche Netzwerkadaptertyp für die Windows-VM zum Installieren von Windows Server 2019-ISO sollte E1000E sein.
    • Führen Sie die folgenden Schritte aus: VMware-vSphere-Vorlage für Windows Server 2019 erstellen
    • Notieren Sie sich das anfängliche Passwort, das beim Ausführen des Windows-ISO-Installationsprogramms festgelegt wird, um es in Zukunft verwenden zu können.
    • Sie sollten die neueste qualifizierte Patchversion für Windows Server 2019 verwenden. Lesen Sie in unseren Versionshinweisen nach, wie Sie die neueste qualifizierte Windows-Betriebssystem-Image-Version für eine bestimmte Anthos-Release-Version abrufen. Siehe Sicherheitspatch-Prozess.
    • Sie können kein Gerät, das den IDE-Controller verwendet, an die Basis-VM-Vorlage anhängen.

  2. Installieren Sie die VMware Tools auf der Basis-Windows-VM-Vorlage, falls nicht bereits installiert, mithilfe der VMWare-Anleitungen.

  3. Erstellen Sie eine Windows-VM-Vorlage:

    gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.

    • BASE_WINDOWS_VM_TEMPLATE: Pfad zur Windows-Basis-VM-Vorlage

    • BUNDLE: der Pfad zur Google Distributed Cloud-Bundle-Datei

    Beim Erstellen der Windows-VM-Basisvorlage führt gkectl prepare windows Windows sysprep aus. Dadurch wird die VM-Vorlage generalisiert und Netzwerkeinstellungen für die VM bereinigt. Dadurch werden Konflikte mit IP-Adressen vermieden, wenn VMs aus derselben Vorlage geklont werden. Windows sysprep wird jedoch als geschlossenes Feld ausgeführt, sodass bestimmte sysprep-Fehler schwer zu bewältigen sind.

    Wenn Sie eine Windows-VM-Basisvorlage erstellen möchten, ohne Windows sysprep auszuführen, fügen Sie --skip-sysprep in den Befehl gkectl prepare windows ein.

  4. In der letzten Zeile der Befehlsausgabe finden Sie den Namen der generierten Windows-VM-Vorlage. Notieren Sie sich den Namen für die zukünftige Verwendung. Der Name hat folgendes Format:

    Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"

Schritt 2: Windows-Container-Images in eine private Registry hochladen

Wenn Sie keine private Registry verwenden, können Sie diesen Schritt überspringen.

Sie können den Upload von Windows-Container-Images in eine private Registry automatisieren, indem Sie „containerd“ auf einer Linux-Administrator-Workstation verwenden. Containerd kann jedoch die Basisebene des Windows-Container-Images nicht per Push übertragen, weshalb die Basisebenen beim Abrufen des Images aus der Microsoft-Registry abgerufen werden müssen. Um die Basisebenen zu übertragen, führen Sie die Schritte in Option 2 aus.

Option 1: Wenn Sie die Images der Windows-Basisebene nicht manuell in die private Registry verschieben müssen:

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

Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad zur Konfigurationsdatei des Administrator-Clusters.

Das Flag --upload-windows-images gibt an, dass Windows Container-Images übertragen werden. Nur Linux-Container-Images werden in die private Registry übertragen, ohne dieses Flag anzugeben.

Option 2: Wenn Sie die Windows-Basisebenen-Images manuell in die private Registry übertragen müssen:

  • Verwenden Sie einen Windows-Computer mit installiertem Docker und Zugriff auf gcr.io, bevor Sie diese Schritte ausführen. Sie können Windows-Container-Images nur auf einen Windows-Rechner herunterladen.
  • Führen Sie docker login aus, um sich in Ihrer privaten Registry zu authentifizieren.

  • So laden Sie die Windows-Container-Images mit ihren Basisebenen in Ihre private Registry hoch:

    • Rufen Sie auf Ihrem Windows-Computer die Docker-Datei daemon.json auf: 

      PS C:> cat C:\ProgramData\docker\config\daemon.json

    • Fügen Sie die folgenden Zeilen hinzu, um Ihre Docker-Datei daemon.json so zu konfigurieren, dass fremde Ebenen in Ihre private Registry übertragen werden können:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Laden Sie die erforderlichen Windows-Container-Images auf Ihren lokalen Windows-Computer herunter, taggen Sie sie und übertragen Sie sie per Push in Ihre private Registry. Die Änderungen, die Sie an der Docker-Konfigurationsdatei daemon.json vorgenommen haben, bedeuten, dass die Basisebene in die private Registry übertragen werden kann. Führen Sie die folgenden Befehle aus, um diese Aufgaben abzuschliessen:
# 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

Schritt 3: (erforderlich bei Verwendung von Proxy) Zulassungslisten-URLs zum Erstellen von Windows-Knotenpools

Wenn sich der Cluster hinter einem Proxyserver befindet, fügen Sie diese URLs zusätzlich zu den anderen Adressen, die für Google Distributed Cloud erforderlich sind, Ihrer Zulassungsliste des Proxyservers hinzu.

# 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

Schritt 4: Windows-Knotenpool zur Konfigurationsdatei des Nutzerclusters hinzufügen

  1. Dataplane V2 muss in Ihrem Nutzercluster aktiviert sein, um Windows-Knotenpools zu verwenden. Fügen Sie der Konfigurationsdatei des Nutzerclusters die folgende Zeile hinzu, um Dataplane V2 zu aktivieren:

    enableDataplaneV2: true

  2. Fügen Sie einen Windows-Knotenpool in den Abschnitt nodePools in der Nutzercluster-Konfigurationsdatei ein. Zusätzlich zu Ihren Windows-Knotenpools ist mindestens ein Linux-Knotenpool erforderlich. Legen Sie die Felder osImage und osImageType fest, um Windows-Knotenpools zu erstellen:

  • osImage: Ersetzen Sie WINDOWS_VM_TEMPLATE_NAME durch den Namen Ihrer vorbereiteten Windows-VM-Vorlage in Schritt 1. Diese sollte sich im selben vCenter-Datenspeicher befinden, der in der Konfigurationsdatei des Nutzerclusters angegeben ist.
  • osImageType: Geben Sie als Betriebssystem-Image-Typ windows an.
# user-cluster.yaml

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

Schritt 5: Windows-Knotenpools erstellen

Führen Sie vor dem Erstellen von Windows-Knotenpools eine Liste der Preflight-Validierungen für Windows aus. Überspringen Sie diesen Schritt, wenn Sie bereits einen Nutzercluster haben. - (Optional) Führen Sie einen oder beide der schnellen und langsamen Preflight-Prüfungen aus, die eine Test-VM für Windows erstellen und die Windows-VM-Vorlage validieren:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Dieser Befehl ist erforderlich, bevor Sie einen Nutzercluster erstellen. Wenn Sie bereits einen Nutzercluster haben, können bestimmte Prüfungen fehlschlagen. Beispielsweise werden die IP-Adressen in der hostconfig.yaml-Datei möglicherweise bereits von vorhandenen Knoten in Ihrem Nutzercluster verwendet.
  • Obwohl dies nicht empfohlen wird, können Sie die Windows-Preflight-Prüfungen mit dem Flag --skip-validation-windows überspringen.
  • Die Verwaltung von Windows-Knotenpools ist die gleiche wie bei Linux-Knotenpools. Siehe Knotenpools verwalten. Die Befehle zum Erstellen, Aktualisieren und Upgraden von Clustern und Knotenpools bleiben ebenfalls gleich und werden hier aufgeführt.
# 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

Schritt 6: Prüfen, ob Windows-Knoten ausgeführt werden

  1. Prüfen Sie, ob die Windows-Knoten erstellt wurden und den Status Ready haben.

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Diagnostizieren Sie den Nutzercluster, um zu prüfen, ob er fehlerfrei ist.

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

Windows-Pod bereitstellen

Windows Server-Knoten sind mit dem folgenden Schlüssel/Wert-Paar markiert: node.kubernetes.io/os=windows:NoSchedule.

Diese Markierung sorgt dafür, dass der GKE-Planer nicht versucht, Linux-Container auf Windows Server-Knoten auszuführen. Um Windows Server-Container auf Windows Server-Knoten zu planen, muss Ihre Manifestdatei diesen nodeSelector-Abschnitt enthalten:

nodeSelector:
    kubernetes.io/os: windows

Ein im Cluster mit nodeSelector konfigurierter und ausgeführter Zugangs-Webhook prüft neue Arbeitslasten auf das Vorhandensein dieses Windows-Knotenselektors. Sollte er vorliegen, wendet der Webhook die folgende Toleranz auf die Arbeitslast an, mit der sie auf den markierten Windows Server-Knoten ausgeführt werden kann:

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

Schritt 1: Bereitstellungsdatei für Internetinformationsdienste (IIS) erstellen

Mit der folgenden Beispielkonfiguration wird das offizielle IIS-Image von Microsoft in einem einzelnen Pod bereitgestellt.

Erstellen Sie eine IIS-Datei mit dem Namen iis.yaml mit folgendem Inhalt:

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]

Schritt 2: Deployment erstellen und über einen Dienst bereitstellen

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

Schritt 3: Pod validieren

Prüfen Sie den Status des Pods mit kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Warten Sie, bis in der zurückgegebenen Ausgabe angezeigt wird, dass der Pod den Status „Wird ausgeführt“ hat.

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

Rufen Sie den Status des Dienstes ab und warten Sie, bis das externe IP-Feld ausgefüllt ist.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Erwartete Ausgabe:

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

Sie können in Ihrem Browser http://EXTERNAL_IP aufrufen, um die IIS-Webseite aufzurufen.

Nutzercluster mit Windows-Knotenpools upgraden

Das Upgrade für einen Nutzercluster mit Windows-Knotenpools ähnelt dem Upgrade für Linux-Nutzercluster, mit dem Unterschied, dass Sie vor dem Upgrade eine Windows-VM-Vorlage aus einer Basis-VM-Vorlage erstellen müssen.

Sie können die Patch-Build-Version der Basis-VM-Vorlage während des Upgrades aktualisieren. Laden Sie dazu eine neuere Patchversion von Windows Server 2019 von Microsoft als Sicherheitspatch herunter. Siehe Sicherheitspatch-Prozess.

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

Aktualisieren Sie das Feld osImage des Knotenpools in der Konfigurationsdatei mit dem neuen VM-Vorlagennamen. Führen Sie den folgenden Befehl aus, um ein Upgrade des Nutzerclusters durchzuführen:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG durch den Pfad zu Ihrer Administrator-kubeconfig-Datei
  • ADMIN_CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei Ihres Administratorclusters

Auf Windows-Knoten zugreifen

Der Zugriff auf Windows-Knoten erfolgt standardmäßig mit einem Nutzernamen und einem Passwort. Dies unterscheidet sich von Linux-Knoten, auf die normalerweise über SSH-Schlüsselpaare zur Authentifizierung zugegriffen wird.

Für Windows-Knoten in vSphere lautet der Nutzername Administrator. Das Passwort wird vom clusterapi-controller generiert und im Secret windows-node-password im Nutzer-Namespace des Administratorclusters gespeichert. Der Befehl zum Abrufen des Passworts von diesem Secret lautet:

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

Sie können das Passwort auch über die vCenter-Benutzeroberfläche abrufen. Gehen Sie zu der VM, bei der Sie sich anmelden möchten, und finden Sie das Passwort im vApp-Attribut password dieser VM.

Nachdem Sie den Nutzernamen und das Passwort kennen, können Sie mit einer der folgenden Methoden auf Ihre Windows-VM zugreifen:

Remote Desktop Protocol verwenden

Da RDP während der Vorlagenerstellung aktiviert wurde, können Sie über einen RDP-Client auf Ihre Windows-VM zugreifen.

SSH verwenden

So stellen Sie eine SSH-Verbindung zu einer Windows-VM her:

ssh Administrator@[VM_IP_ADDRESS]

Geben Sie das Passwort ein, um eine Verbindung zu der VM herzustellen.

Dateien von und zu Ihrer Windows-VM übertragen

Mit dem Befehl scp können Sie Dateien von und zu Ihrer Windows-VM übertragen:

Laden Sie die Dateien auf eine Windows-VM hoch:

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

Laden Sie Dateien von der Windows-VM herunter:

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

Geben Sie das Passwort ein, wenn Sie dazu aufgefordert werden.

Alternativ können Sie Dateien auch mithilfe von Cloud Storage oder RDP übertragen. Eine Beschreibung hierzu finden Sie unter Dateien auf Windows-VMs übertragen.

Windows Server-Konfiguration aktualisieren

Containerd und Windows Dataplane V2 sind jetzt ab Version 1.11 allgemein verfügbar.

Docker und Flannel für Windows-Knoten werden in einer zukünftigen Version verworfen. Wir empfehlen Ihnen, gegebenenfalls Ihre Konfiguration zu aktualisieren, um stattdessen containerd und Windows Dataplane V2 zu verwenden. Siehe Windows Server-Konfiguration aktualisieren.

SSH/RDP-Verbindung auf die Windows-VM nicht möglich

Prüfen Sie, ob die VM eine Netzwerkverbindung hat. Führen Sie dazu Test-NetConnection in Ihrer vCenter-Webkonsole aus.

Wenn eine Netzwerkverbindung besteht, sollte das Ergebnis PingSucceeded: true enthalten. Wenn die VM keine Netzwerkverbindung hat, prüfen Sie den für diese VM verwendeten Netzwerkadapter. Achten Sie darauf, dass das Netzwerk eingehende Verbindungen zur VM von Ihrer Workstation zulässt, auf der Sie das SSH/RDP ausführen möchten.

Prüfen Sie, ob die Kubelet-, Kube-Proxy- und CNI-Dienste auf der Windows-VM ausgeführt werden

Stellen Sie gemäß dieser Anleitung eine Verbindung zu Ihrer VM her und führen Sie je nach Einrichtung die folgenden Befehle aus:

  1. Führen Sie für alle Konfigurationen die folgenden Befehle aus:

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

  2. Wenn der Cluster mit windowsDataplaneV2 auf true konfiguriert ist, prüfen Sie, ob die Antrea-Agent-, OVSDB-Server- und OVS-VSwitchd-Dienste „ausgeführt” werden.

    # Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd

  3. Prüfen Sie andernfalls, ob der Flask-Prozess-Status „Wird ausgeführt” lautet:

    # Check that the flanneld process exists
Get-Process flanneld

Snapshot-Tool verwenden

Verwenden Sie das Snapshot-Tool, um den Snapshot-Tarball zu erfassen. Dieser Tarball enthält die Logdateien von Knoten sowie Ausgaben für Befehle zur Fehlerbehebung, die auf dem Knoten ausgeführt werden.

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

Windows-VM kann nicht erstellt werden

Prüfen Sie die Logs aus dem vsphere-controller-manager-Container im clusterapi-controllers-Pod im Nutzer-Namespace des Administratorclusters.

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

Achten Sie darauf, dass sich die VM-Vorlage im selben Rechenzentrum und im selben Datenspeicher befindet wie in der Nutzercluster-Konfigurationsdatei angegeben.

Windows-VM wird erstellt, aber der Knoten kann nicht ordnungsgemäß gestartet werden oder wird nicht angezeigt

  • Überprüfen Sie die Startlogs auf dem Knoten unter C:\var\log\startup.log, um festzustellen, ob etwas nicht gestartet werden konnte.

    • Wenn flanneld nicht ausgeführt wird, versuchen Sie, das Startskript unter C:\etc\startup\startup-script.ps1 noch einmal auszuführen.
    • Wenn kubelet nicht ausgeführt wird, prüfen Sie die Kubelet-Logs unter C:\var\log.
    • Wenn kube-proxy nicht ausgeführt wird, prüfen Sie die kube-proxy-Logs unter C:\var\log.

  • Prüfen Sie, ob „cloudbase-init“ die UserDataPlugin bereits ausgeführt hat, bevor Sie das Startskript ausführen.

Stellen Sie eine SSH-Verbindung zur Windows-VM her und führen Sie den folgenden Befehl aus, um dies zu prüfen:

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

Wenn Sie UserDataPlugin: 1 in der Ausgabe finden, bedeutet dies, dass cloudbase-init dieses Plug-in bereits ausgeführt hat. Dies führt dazu, dass die Ausführung des Startskripts übersprungen und der Windows-Knoten überhaupt kein Bootstrapping gestartet wird.

Dieser Fehler tritt normalerweise auf, wenn die von gkectl prepare windows generierte VM-Vorlage in eine VM zurückkonvertiert und eingeschaltet wird.

Erstellen Sie zum Beheben dieses Problems eine neue VM-Vorlage. Führen Sie dazu gkectl prepare windows noch einmal aus und verwenden Sie sie zum Erstellen/Aktualisieren/Aktualisieren des Windows-Knotenpools.

Logging und Monitoring

Google Distributed Cloud unterstützt Logging und Monitoring für Windows-Knoten und -Pods genauso wie für Linux-Knoten und -Pods.

Wenn Logging und Monitoring konfiguriert sind, werden Agents auf Windows-Knoten bereitgestellt. Diese Agents erfassen, verarbeiten und exportieren die Logs und Messwerte des Knotens.

Windows-Logging-Agent

Der Windows-Logging-Agent erfasst die folgenden Logs:

  • Pod-Ressourcentyp: System- und Nutzeranwendungsarbeitslasten.

    Beachten Sie, dass Logs von Windows-Nutzeranwendungsarbeitslasten standardmäßig gesammelt werden. So deaktivieren Sie Anwendungslogs:

    • Bearbeiten Sie die Configmap fluent-bit-windows-config und kommentieren Sie das [Input]-Element aus, das die Anwendungslogs erfasst (das erste [Input]-Element): 
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      Achten Sie darauf, alle Felder unter diesem Element auszukommentieren. Beispiel: 
      #    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?a-z0-9?(?:.a-z0-9?))_(?[^]+)(?.+)-(?[a-z0-9]{64}).log$
#      Tag                k8s_container...
#      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
    • Führen Sie den Befehl rollout restart aus, um das Daemonset fluent-bit-windows neu zu starten: 
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

  • Knotenressourcentyp: Kubelet, Kube-Proxy und Windows-Ereignislogs

Sie können mit dem Log-Explorer in der Konsole auf Logs zugreifen. Weitere Informationen finden Sie unter Zugriffslogs.

Windows-Monitoring-Agent

Der Windows-Monitoring-Agent erfasst andere CPU- und Arbeitsspeichernutzungsmesswerte als der Linux-Monitoring-Agent. Um den Windows-Knoten- und Pod-Status zu überwachen, verwenden Sie die vorbereiteten Dashboards. Wählen Sie in der Konsole Monitoring > Dashboards aus und wählen Sie dann in der Liste Alle Dashboards die Option "GKE On-Prem-Windows-Knotenstatus" und "GKE On-Prem-Windows-Pod-Status" aus.

Diese Dashboards werden während der Installation des Administratorclusters automatisch erstellt, wenn Cloud Monitoring aktiviert ist. Wenn Sie bereits einen Administratorcluster haben, folgen Sie dieser Anleitung, um diese Dashboards mit den folgenden JSON-Dateien zu erstellen:

Vollständige Liste der Messwerte, die von den Windows-Agents erfasst wurden

Nichtflüchtiger Windows-Speicher

Wenn Sie mit Windows Server-Containern mit nichtflüchtigem Speicher arbeiten, müssen Sie ein StorageClass-Objekt erstellen und den Namen dieses Objekts im Feld storageClassName des PersistentVolumeClaim-Objekts angeben, da die standardmäßige StorageClass im lokalen Nutzercluster ext4 als Dateisystemtyp verwendet, was nur für Linux-Container funktioniert. Unter Windows müssen Sie den Dateisystemtyp auf ntfs setzen.

Beispiel für eine Windows-Speicherklasse:

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

Der CSI-Proxy wird automatisch auf Windows-Knoten bereitgestellt. Sie können einen Windows-CSI-Treiber Ihrer Wahl installieren und verwenden, z. B. den SMB-CSI-Treiber.

Node Problem Detector auf Windows-Knoten

Der Node Daemon Problem Detector ist für Windows-Knoten verfügbar. Wenn Sie ein Upgrade auf Version 1.9 durchgeführt haben, wird der Node Problem Detector automatisch aktiviert. Der Node Problem Detector hilft Ihnen, einige häufig auftretende Knotenprobleme schnell zu erkennen. Der Node Problem Detector sucht weiterhin nach möglichen Problemen und meldet sie auf dem Knoten als Ereignisse und Bedingungen. Wenn ein Knoten fehlerhaft ist, können Sie mit dem Befehl kubectl die entsprechenden Ereignisse und Bedingungen ermitteln.

Die folgenden Monitoring-Konfigurationen sind für den Node Problem Detector aktiviert:

So rufen Sie Ereignisse und Bedingungen auf einem Knoten ab:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Ersetzen Sie:

  • KUBECONFIG durch den Pfad der kubeconfig-Datei für den Cluster, der den Knoten enthält.
  • NODE_NAME durch den Namen des Knotens.

Suchen Sie im Feld reason einer Regel, die im Abschnitt rules angegeben ist, nach den Monitoring-Namen, um die Ereignisse zu ermitteln, die vom Node Problem Detector-Monitoring generiert werden.

Node Problem Detector-Monitoring generiert auch die folgenden Bedingungen auf dem Knoten. Alle Werte werden auf true gesetzt, wenn der Node Problem Detector das entsprechende Fehlerszenario auf dem Knoten erkennt.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Wenn eine der Bedingungen auf true gesetzt ist, wird die Bedingung „Bereit“ des Knotens zu false, wodurch verhindert wird, dass neue Pods auf dem Knoten geplant werden.

Wenn eine fehlerhafte Bedingung gefunden wird, versucht der Node Problem Detector, den Knoten automatisch zu reparieren, indem der relevante Systemdienst neu gestartet wird.

Node Problem Detector-Logs befinden sich im Ordner C:\var\log\node-problem-detector des Knotens. Wenn Logging und Monitoring aktiviert sind, wird das Log nach Cloud Logging exportiert und kann im Log-Explorer angesehen werden.

Verwenden Sie diesen Filter, um Logs des Node Problem Detector im Log-Explorer aufzurufen:

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

Ersetzen Sie PROJECT_NAME durch den Projektnamen.

Sicherheitspatch-Prozess

Neben den regelmäßigen Patch-Releases für die unterstützten Anthos-Versionen qualifiziert das Anthos-Team auch kontinuierlich neuere Windows-Patch-Updates während der Nicht-Release-Zeiträume und veröffentlicht die Ergebnisse. Wenn ein dringendes Sicherheitspatch-Update zwischen den Anthos-Patch-Releases erforderlich ist, können Sie eine neue VM-Vorlage mit der neuesten Version erstellen und dann ein Rolling Update für die vorhandenen Windows-Knotenpools durchführen, um die neue Vorlage zu verwenden.

Der Sicherheitspatch-Prozess umfasst die folgenden Schritte:

  • Microsoft veröffentlicht einen neuen Sicherheitspatch für Windows Server 2019.
  • Anthos qualifizieren die neueste Sicherheitspatch-Version und kündigt das Qualifikationsergebnis an.
  • Qualifizierte Nutzer können:
    • Die neueste Patchversion von Microsoft herunterladen
    • Mithilfe dieser Patchversion eine neue Windows-VM-Vorlage erstellen. Folgen Sie dazu diesen Schritten.
    • Aktualisieren Sie die Windows-Knotenpools so, dass die neue Vorlage verwendet wird:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • Wenn die neue Version Änderungen von Anthos erfordert, müssen Sie auf den nächsten monatlichen Patch-Release warten und die Cluster upgraden.

  • Wenn die neue Windows-Version überhaupt nicht mit Anthos kompatibel ist, überspringt das Anthos-Team diese Version und wartet auf das nächste Sicherheitsupdate von Microsoft.

Active Directory-Domainbeitritt

Beim Active Directory-Domainbeitritt darf der VM-Hostnamen höchstens 15 Zeichen lang sein. Da der VM-Hostname in der Konfigurationsdatei des Nutzerclusters festgelegt wird, darf der IPAM-Modus nicht länger als 15 Zeichen sein. Diese Anweisungen basieren auf den Anweisungen zum Erstellen von Windows-Knotenpools, mit dem zusätzlichen Schritt der Bereitstellung eines angepassten Skripts während der Erstellung der Windows-VM-Vorlage.

Erreichbarkeit des Active Domain-DNS-Servers prüfen

Active Directory Domain Services (AD DS) verwenden DNS-Namensauflösungsdienste (Domain Name System), um es den Clients zu ermöglichen, Domain-Controller zu finden und den Domain-Controllern, die den Verzeichnisdienst hosten, die Kommunikation untereinander zu ermöglichen.

Der DNS-Server wurde erstellt, als die AD DS-Rolle die Stammstruktur installierte. Damit eine Windows-VM der AD-Domain beitreten kann, muss sie den DNS-Server erreichen können. Konfigurieren Sie die DNS- und Firewall-Konfigurationen entsprechend der Anleitung des verwendeten DNS-Dienstanbieters. Mit dem folgenden Befehl können Sie prüfen, ob die Windows-VMs im aktuellen Netzwerk den DNS-Server der AD-Domain kontaktieren können:

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

Schritt 1: Windows-VM-Vorlage mit einem benutzerdefinierten Skript erstellen

  1. Führen Sie ein angepasstes Skript aus, bevor der Windows-Knoten dem Nutzercluster für den Active Directory-Domainbeitritt beitritt. Speichern Sie dieses Skript in einem lokalen Pfad auf Ihrer Administrator-Workstation. Hinweis:

    • Sie können das Skript durch ein eigenes Skript ersetzen, um den Active Directory-Domainbeitritt durchzuführen.
    • Wir empfehlen, statt eines Administratornutzers ein Nutzerkonto mit den für einen Active Directory-Domainbeitritt erforderlichen Mindestberechtigungen zu verwenden.
    • (Optional) Um zu vermeiden, dass das Passwort in diesem Skript als Klartext gespeichert wird, hinterlegen Sie das Passwort in einer Datei auf der VM-Vorlage, lassen Sie das Skript aus dieser Passwortdatei lesen und löschen Sie die Datei dann nach dem Domainbeitritt.
    $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

  2. Erstellen Sie eine Windows-VM-Vorlage mit einem benutzerdefinierten Skript:

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

Ersetzen Sie BUNDLE_PATH durch den Pfad zum Bundle.

Schritt 2: Windows-Knotenpool erstellen

Fahren Sie mit den Standardanleitungen in den Schritten 2 bis 6 fort, um einen Windows-Knotenpool mit der benutzerdefinierten Windows-VM-Vorlage zu erstellen.

Schritt 3: Active Domain-Join für die Windows-Knoten prüfen

Führen Sie auf der AD-Domaincontroller-VM den folgenden Befehl aus:

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

Schritt 4: Gruppenverwaltete Dienstkonten konfigurieren (optional)

Folgen Sie dieser Anleitung: GMSA für Windows-Pods und -Container konfigurieren. Sie können GMSA für Windows-Pods und -Container konfigurieren, nachdem die Knoten der Domain hinzugefügt wurden.

Fehlerbehebung

Logs für die Ausführung der benutzerdefinierten Skriptausführung von cloudbase-init finden Sie unter C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Suchen Sie in der Logdatei nach LocalScriptPlugin und prüfen Sie die zugehörigen Logs. - Erstellen Sie eine neue Windows-VM-Vorlage. - Aktualisieren Sie die Windows-Knotenpools so, dass die neue Vorlage verwendet wird:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Hinweise für Windows-Container

Hier einige wichtige Unterschiede zwischen Windows- und Linux-Containern:

  • Versionskompatibilität von Windows-Container-Images und Host-/Knotenbetriebssystem-Images.
    • Das Windows Server-Betriebssystemversions-Tupel besteht aus vier Teilen: Major, Minor, Build und Revision.
    • Das Basis-Image des Windows Server-Containers muss mit den ersten drei Teilen des Versionstupels des Host-Betriebssystem-Images übereinstimmen. Die Überarbeitung muss nicht übereinstimmen, es wird jedoch empfohlen, sowohl das Host- als auch das Container-Basis-Image zu aktualisieren.
    • Nutzer müssen ihre Container-Images neu erstellen, wenn sich die Version des Betriebssystem-Images ändert
  • Privilegierte Container und Host-Namespaces werden nicht unterstützt.
    • Nutzer können keine Knoten durch bereitstellen von Containern, wie Daemonsets, konfigurieren und ändern.

Einschränkungen für Google Distributed Cloud unter Windows

  • Nutzercluster müssen mindestens einen Linux-Knotenpool enthalten.

    • Sie können keinen Cluster mit nur einem Windows-Knotenpool erstellen
    • Die Linux-Knotenpools sind erforderlich, um kritische Add-ons auszuführen.

  • Da für Windows-Knoten 1,5-mal mehr Ressourcen reserviert sind als für Linux-Knoten, sind die zuweisbaren Ressourcen für Windows geringer.

  • Für die Verwendung von Windows-Knoten ist möglicherweise eine höhere Mindestmaschinengröße erforderlich als die Mindestmaschinengröße von Google Distributed Cloud Linux. Windows-Knoten benötigen in der Regel mehr Ressourcen aufgrund des höheren Aufwands bei der Ausführung von Knotenkomponenten/-diensten.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme mit Windows-Knoten aufgeführt, die mit Google Distributed Cloud verwendet werden, sowie Problemumgehungen zur Vermeidung oder Behebung dieser Probleme.

Windows-Pods können nicht mit externen IP-Adressen kommunizieren

Dieses Problem wird in der Microsoft-Dokumentation beschrieben, in der es heißt: "Sie müssen die externe IP, die Sie abfragen wollen, aus der ExceptionList ausschließen."

Wenden Sie sich an den Google Cloud-Support, um eine Umgehungslösung zu finden.

Windows-Container werden nach dem Entfernen von Windows-Pods nicht bereinigt

Dies ist ein bekanntes Problem, bei dem Docker RemoveContainer auch versucht, CreateFile unter Windows aufzurufen. Als Abhilfe melden Sie sich bei dem Windows-Knoten an, bei dem das Problem auftritt, und führen Sie Restart-Service docker aus. Das Problem sollte dann behoben sein. In Google Distributed Cloud 1.9 wurden die Container-Image-Version von fluent-bit-win und die Docker-Version aktualisiert, um die Upstream-Fehlerbehebungen für dieses Problem zu übernehmen. Dies sollte nicht mehr reproduziert werden. Wenden Sie sich ansonsten an den Google Cloud-Support.

Windows-Knoten mit IP-Adresskonflikten

Dies ist ein bekanntes Problem, das sehr selten auftritt. Wenn es bei der Erstellung des Windows-Knotenpools auftritt, können Sie das Problem so beheben:

  • Wenn Sie den IPAM-Modus verwenden, können Sie die VMs mit IP-Adressen-Konflikten manuell aus dem vCenter entfernen. Es werden automatisch neue VMs mit korrekten IP-Zuweisungen erstellt. Sie können auch einfach warten, bis die automatische Knotenreparatur dieses Problem erkennt und die Windows-Knoten neu erstellt.

  • Wenn Sie den DHCP-Modus verwenden, werden die neu erstellten VMs wahrscheinlich wieder doppelte IP-Adressen haben, da der DHCP-Server Probleme bei der IP-Zuweisung hat. Sie können den ausstehenden Windows-Knotenpool löschen, indem Sie gkectl update cluster ausführen, und ihn in der Datei user-cluster.yaml wieder hinzufügen; führen Sie gkectl update cluster noch einmal aus, um ihn zu erstellen; der neu erstellte Knotenpool sollte korrekte IP-Zuweisungen haben.

Windows-Knoten wird nach dem Neustart der VM nicht bereit

Derzeit wird das Startskript des Knotens nur beim ersten Einschalten der VM ausgeführt. Wenn Sie die VM also neu starten, wird das Startskript nicht noch einmal ausgeführt. Dies führt dazu, dass einige Windows-Dienste nicht mehr ausgeführt werden, einschließlich der Kubelet-, Kube-Proxy-Dienste usw. Dadurch befindet sich der Knoten im Status NotReady. Wenn Sie Windows Dataplane V2 verwenden, muss das veraltete Netzwerk ebenfalls bereinigt werden, bevor die Dataplane V2-Dienste neu gestartet werden können. Außerdem muss ein Skript zur Bereinigung ausgeführt werden, was zu Komplikationen führen kann. Erstellen Sie daher den Knoten neu. Als Behelfslösung können Sie den Knoten löschen, indem Sie den folgenden Befehl ausführen und warten, bis der Controller ihn automatisch neu erstellt.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Der Diagnosebefehl schlägt fehl, wenn die Windows-VM-Hardwareversionen niedriger als erwartet sind

Wenn die Windows-VM-Vorlage eine alte Hardwareversion verwendet, schlägt der Befehl gkectl diagnose cluster mit der folgenden Meldung fehl:

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",
    }

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

  1. Benennen Sie die derzeit verwendete VM-Vorlage um.

    Dies ist erforderlich, um in den nächsten Schritten eine neue VM-Vorlage erstellen zu können.

  2. Konvertieren Sie die VM-Basisvorlage von Windows in eine VM.

  3. Führen Sie die Schritte unter Upgrade einer virtuellen Maschine auf die neueste Hardwareversion aus, um die Hardwareversion der VM zu aktualisieren.

  4. Konvertieren Sie die VM wieder in eine VM-Vorlage.

  5. Führen Sie den folgenden Befehl aus, um eine neue VM-Vorlage vorzubereiten. Verwenden Sie dabei die aktualisierte VM-Vorlage aus den vorherigen Schritten als Basis-VM-Vorlage.

    gkectl prepare windows

    Der Name der neu generierten VM-Vorlage sollte mit dem Wert des Feldwerts osImage des Windows-Knotenpools in der Konfigurationsdatei des Nutzerclusters übereinstimmen. Wenn die Werte übereinstimmen, fahren Sie mit dem nächsten Schritt fort, um den Windows-Knoten neu zu erstellen.

    Wenn der Vorlagenname nicht mit dem Feldwert osImage übereinstimmt, aktualisieren Sie den Wert osImage entsprechend dem neu generierten VM-Vorlagennamen und führen Sie den folgenden Befehl aus:

    gkectl update cluster

  6. Erstellen Sie den Windows-Knoten mit dem folgenden Befehl neu:

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    Warten Sie, bis der Controller den Knoten automatisch neu erstellt.