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 auftrue
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.
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.
Installieren Sie die VMware Tools auf der Basis-Windows-VM-Vorlage, falls nicht bereits installiert, mithilfe der VMWare-Anleitungen.
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
Windowssysprep
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. Windowssysprep
wird jedoch als geschlossenes Feld ausgeführt, sodass bestimmtesysprep
-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 Befehlgkectl prepare windows
ein.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
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
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 FelderosImage
undosImageType
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-Typwindows
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
Prüfen Sie, ob die Windows-Knoten erstellt wurden und den Status
Ready
haben.kubectl --kubeconfig USER_KUBECONFIG get nodes
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:
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
Wenn der Cluster mit
windowsDataplaneV2
auftrue
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
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
.
- Wenn flanneld nicht ausgeführt wird, versuchen Sie, das Startskript unter
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): Achten Sie darauf, alle Felder unter diesem Element auszukommentieren. Beispiel: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.(?
a-z0-9?(?:.a-z0-9?))_(? [^]+)(? .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.+)-(? [a-z0-9]{64}).log$ # Tag k8s_container. . . # Path C:\var\log\containers\ - Führen Sie den Befehl
rollout restart
aus, um das Daemonsetfluent-bit-windows
neu zu starten:kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system
- Bearbeiten Sie die Configmap
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:
- windows-health-checker-kubelet
- windows-health-checker-kubeproxy
- windows-health-checker-docker
- windows-health-checker-containerd
- windows-defender-monitor
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
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
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 Siegkectl 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:
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.
Konvertieren Sie die VM-Basisvorlage von Windows in eine VM.
Führen Sie die Schritte unter Upgrade einer virtuellen Maschine auf die neueste Hardwareversion aus, um die Hardwareversion der VM zu aktualisieren.
Konvertieren Sie die VM wieder in eine VM-Vorlage.
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 WertosImage
entsprechend dem neu generierten VM-Vorlagennamen und führen Sie den folgenden Befehl aus:gkectl update cluster
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.