Diese Seite wurde von der Cloud Translation API übersetzt.

Windows Server-Anwendung bereitstellen

Standard

Auf dieser Seite erfahren Sie, wie Sie eine zustandslose Windows Server-Anwendung in einem GKE-Cluster (Google Kubernetes Engine) bereitstellen. Dies kann entweder öffentlich oder privat sein. Außerdem erfahren Sie, wie Sie eine zustandsorientierte Windows-Anwendung bereitstellen.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Artifact Registry API und die Google Kubernetes Engine API.

APIs aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Windows Server-Anwendung in einem Cluster bereitstellen

Zum Bereitstellen einer Windows Server-Anwendung in einem öffentlichen GKE-Cluster müssen Sie die folgenden Aufgaben ausführen:

Erstellen Sie einen Cluster.
Erstellen Sie eine Manifestdatei für das Deployment.
Erstellen Sie das Deployment und geben Sie es frei.
Prüfen Sie, ob der Pod ausgeführt wird.

Cluster erstellen

Wenn Sie bereits einen GKE-Cluster haben, der Windows Server-Knotenpools verwendet, fahren Sie mit dem nächsten Schritt fort. Erstellen Sie andernfalls mithilfe von Windows Server-Knotenpools einen Cluster.

Manifestdatei für das Deployment erstellen

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 Knotenselektor enthalten:

nodeSelector:
 kubernetes.io/os: windows

Ein im Cluster 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:
- effect: NoSchedule
  key: node.kubernetes.io/os
  operator: Equal
  value: windows

In einigen Fällen müssen Sie diese Toleranz explizit in Ihre Manifestdatei aufnehmen. Wenn Sie beispielsweise ein DaemonSet mit einem Container-Image für mehrere Architekturen bereitstellen, das auf allen Linux- und Windows Server-Knoten im Cluster ausgeführt werden soll, enthält die Manifestdatei keinen Windows-Knotenselektor. Sie müssen die Toleranz für die Windows-Markierung explizit einschließen.

Beispiel für eine Manifestdatei

Mit der folgenden Beispiel-Deployment-Datei (iis.yaml) wird das IIS-Image von Microsoft in einem einzelnen Pod bereitgestellt:

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

Diese Datei ist für einen Cluster vorgesehen, in dem alle Arbeitslasten denselben Windows Server-Knoten-Image-Typ und dieselbe Version verwenden. Weitere Informationen zum Arbeiten mit Images mit gemischten Knoten finden Sie im Abschnitt Images mit gemischten Knoten verwenden.

Deployment erstellen und freigeben

Erstellen Sie aus der Deployment-Datei, die Sie im vorherigen Schritt erstellt haben, einen Kubernetes-Dienst mit einem externen Load-Balancer-Deployment und geben Sie diesen frei,

Führen Sie den folgenden Befehl aus, um die Deployment-Ressource zu erstellen:
```
kubectl apply -f iis.yaml
```
Führen Sie den folgenden Befehl aus, um das Deployment als externen Load-Balancer verfügbar zu machen:
```
kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
```

Prüfen Sie, ob der Pod ausgeführt wird.

Prüfen Sie, ob der Pod richtig funktioniert, indem Sie ihn validieren.

Prüfen Sie den Status des Pods mit kubectl:
```
kubectl get pods
```

Warten Sie, bis der Status des Pods in der zurückgegebenen Ausgabe als Running angegeben wird:

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 Feld EXTERNAL-IP ausgefüllt ist:

kubectl get service iis

Es sollte folgende Ausgabe angezeigt werden:

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

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

Windows Server-Anwendung in einem privaten Cluster bereitstellen

In diesem Abschnitt erfahren Sie, wie Sie eine Windows Server-Containeranwendung in einem privaten Cluster bereitstellen.

Windows Server-Container-Images bestehen aus mehreren Ebenen, wobei die Basisebenen von Microsoft stammen. Die Basisebenen werden als fremde Ebene gespeichert und nicht wie Linux-Docker-Image-Ebenen in das Image eingebettet. Wenn ein Windows Server-Container-Image zum ersten Mal abgerufen wird, müssen die Basisebenen in der Regel von Microsoft-Servern heruntergeladen werden. Da private Clusterknoten nicht mit dem Internet verbunden sind, können die Windows Server-Basiscontainerebenen nicht direkt von Microsoft-Servern abgerufen werden.

Wenn Sie private Cluster verwenden möchten, können Sie den Docker-Daemon so konfigurieren, dass es zulässig ist, nicht verteilbare Ebenen in private Registries zu übertragen. Weitere Informationen finden Sie auf der GitHub-Seite von Docker unter Push von nicht verteilbaren Artefakten zulassen.

So stellen Sie Ihre Windows Server-Anwendung in einem privaten Cluster bereit:

Erstellen Sie einen privaten Cluster mit Windows Server-Knoten.
Erstellen Sie das Docker-Image der Windows Server-Anwendung.
Stellen Sie die Anwendung in einem privaten Cluster bereit.
Prüfen Sie, ob der Pod ausgeführt wird.

Privaten Cluster erstellen

Folgen Sie den Anleitungen unter Cluster mit Windows Server-Knoten erstellen und Private Cluster erstellen, um einen Windows-Knotenpool zu erstellen und diesen einem privaten Cluster hinzuzufügen.

Erstellen Sie das Docker-Image der Windows Server-Anwendung.

Starten Sie zum Erstellen des Docker-Images eine Compute Engine-Instanz mit der Windows Server-Version, auf der Sie Ihre Anwendungscontainer ausführen möchten, z. B. Windows Server 2019 oder Windows Server Version 20H2. Stellen Sie außerdem sicher, dass eine Internetverbindung besteht.
Wechseln Sie auf der Compute Engine-Instanz zur Docker-Daemon-Konfiguration:
```
cat C:\ProgramData\docker\config\daemon.json
```
Konfigurieren Sie die Docker-Datei daemon.json so, dass fremde Ebenen in Ihre private Registry übertragen werden können, indem Sie die folgenden Zeilen hinzufügen:
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
In diesem Beispiel bezieht sich REGISTRY_REGION-docker.pkg.dev auf Artifact Registry, wo das Image gehostet wird.
Starten Sie den Docker-Daemon neu:
```
Restart-Service docker
```
Docker-Repository in Artifact Registry erstellen.
Erstellen und taggen Sie das Docker-Image für Ihre Anwendung:
```
cd C:\my-app
```
```
docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
```
Dieser Befehl weist Docker an, das Image mithilfe des Dockerfiles im aktuellen Verzeichnis zu erstellen und mit einem Namen wie us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2 zu taggen.
Übertragen Sie das Docker-Image der Anwendung in das Artifact Registry-Repository in Ihrem Projekt. Die Konfiguration allow-nondistributable-artifacts bewirkt, dass die Windows-Basisebenen in Ihre private Registry übertragen werden.
```
docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
```

Manifestdatei für das Deployment erstellen

Das folgende Beispiel zeigt eine Bereitstellungsmanifestdatei namens my-app.yaml. Das Image in diesem Beispiel ist jenes, das Sie im vorherigen Schritt übertragen haben (REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: my-server
        image: REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2

Verwenden Sie den Befehl get-credentials, um kubectl für die Arbeit mit dem von Ihnen erstellten Cluster zu aktivieren.
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Ersetzen Sie CLUSTER_NAME durch den Namen des privaten Clusters, den Sie erstellt haben.
Stellen Sie die in der Datei my-app.yaml angegebene Anwendung in Ihrem privaten Cluster bereit:
```
kubectl apply -f my-app.yaml
```

Prüfen, ob der Pod ausgeführt wird

Listen Sie alle Pods auf, um zu prüfen, ob die Anwendung ordnungsgemäß ausgeführt wird:

kubectl get pods

Der Pod sollte mit dem Status Running wie in der folgenden Ausgabe angezeigt werden:

NAME                     READY   STATUS    RESTARTS   AGE
my-app-c95fc5596-c9zcb   1/1     Running   0          5m

Images mit gemischten Knoten verwenden

Ihre Cluster können Knotenpools mit mehreren Windows Server-Typen und Windows Server-Versionen enthalten. Sie können auch Windows Server- und Linux-Arbeitslasten kombinieren. In den folgenden Abschnitten erhalten Sie detaillierte Informationen dazu, wie Sie Ihre Arbeitslasten für die Verwendung dieser Clustertypen konfigurieren.

Arbeitslasten mit verschiedenen Windows Server-Knoten-Image-Typen verwenden

Sie können Knotenpools mit verschiedenen Windows Server-Image-Typen zu Ihrem Cluster hinzufügen. In einem Cluster mit gemischten Windows Server-Typen müssen Sie darauf achten, dass die Windows Server-Container nicht auf einem inkompatiblen Windows Server-Knoten geplant werden.

Wenn Sie einen Windows Server LTSC-Knotenpool und einen Windows Server SAC-Knotenpool haben, fügen Sie beiden Arbeitslasten das Knotenlabel gke-os-distribution hinzu.

Fügen Sie den folgenden nodeSelector in die Manifestdatei für Ihre Windows Server LTSC-Arbeitslasten ein:

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc

Fügen Sie den folgenden nodeSelector in die Manifestdatei für Ihre Windows Server-SAC-Arbeitslasten ein.

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_sac

Durch Hinzufügen dieses Labels wird dafür gesorgt, dass Ihre LTSC-Container-Images nicht auf inkompatiblen SAC-Knoten geplant werden und umgekehrt.

Arbeitslasten mit verschiedenen Windows Server LTSC OS-Versionen verwenden

Windows Server-Knoten unterstützen sowohl Betriebssystem-Images als LTSC2022 und LTSC2019. Sie können die zu verwendende Windows-Betriebssystemversion (LTSC2022) mit dem folgenden Schlüssel/Wert-Paar in nodeSelector angeben: cloud.google.com/gke-windows-os-version=2022.

Dieses Knotenlabel sorgt dafür, dass der GKE-Planer die richtigen Windows Server-Knoten auswählt, um entweder LTSC2022- oder LTSC2019-Arbeitslasten auszuführen. Die Windows Server-Knoten gehören beide zum Image-Typ windows_ltsc_containerd. Der Wert des Knotenlabels kann 2022 oder 2019 sein. Wenn das Knotenlabel nicht angegeben ist, können sowohl LTSC2019- als auch LTSC2022-Knoten zum Planen von Containern verwendet werden. Um Windows Server-Container nur auf Windows Server LTSC2022-Knoten zu planen, muss Ihre Manifestdatei diesen Knotenselektor enthalten:

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc
   cloud.google.com/gke-windows-os-version: 2022

Arbeitslasten mit verschiedenen Windows Server-Versionen verwenden

Wenn Sie Windows Server-Knotenpools mit mehreren verschiedenen LTSC- oder SAC-Versionen ausführen müssen, empfehlen wir Ihnen, Ihre Container-Images als Images für mehrere Architekturen zu erstellen, die auf allen in Ihrem Cluster verwendeten Windows Server-Versionen ausgeführt werden können. Das Knotenlabel gke-os-distribution reicht nicht aus, um zu verhindern, dass Ihre Arbeitslasten möglicherweise auf inkompatiblen Knoten geplant werden.

Linux- und Windows Server-Arbeitslasten in einem Cluster verwenden

Fügen Sie Ihren Linux-Arbeitslasten den folgenden Knotenselektor hinzu, damit sie immer auf Linux-Knoten geplant werden:

nodeSelector:
   kubernetes.io/os: linux

Dies bietet weiteren Schutz, um zu verhindern, dass Linux-Arbeitslasten auf Windows Server-Knoten geplant werden, falls die NoSchedule-Markierung versehentlich von den Windows Server-Knoten entfernt wird.