Windows Server-Anwendung bereitstellen

Auf dieser Seite erfahren Sie, wie Sie eine zustandslose Windows Server-Anwendung bereitstellen. Außerdem erfahren Sie, wie Sie eine zustandsorientierte Windows-Anwendung bereitstellen.

Windows Server-Anwendung in einem Standardcluster bereitstellen

Die folgenden Aufgaben führen Sie durch den Bereitstellungsprozess Ihrer Windows Server-Anwendung:

  1. Erstellen Sie einen Cluster.
  2. Erstellen Sie eine Manifestdatei für das Deployment.
  3. Erstellen Sie das Deployment und geben Sie es frei.
  4. Stellen Sie fest, ob der Pod ausgeführt wird.

Cluster erstellen

Eine Anleitung dazu finden Sie unter Cluster mit Windows Server-Knotenpools erstellen.

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,

  1. Führen Sie den folgenden Befehl aus, um das Deployment zu erstellen:

    kubectl apply -f iis.yaml

  2. Führen Sie den folgenden Befehl aus, um das Deployment freizugeben:

    kubectl expose deployment iis \
--type=LoadBalancer \
--name=iis

Prüfen, ob der Pod ausgeführt wird

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

  1. Prüfen Sie den Status des Pods mit kubectl.

    kubectl get pods

  2. 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

  3. Rufen Sie den Status des Dienstes ab und warten Sie, bis das externe IP-Feld 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 aufzurufen.

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 für Docker unter den Hinweisen zu Registries mit "Luftspalt".

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

  1. Erstellen Sie einen privaten Cluster mit Windows Server-Knoten.
  2. Erstellen Sie das Docker-Image der Windows Server-Anwendung.
  3. Stellen Sie die Anwendung in einem privaten Cluster bereit.
  4. 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.

Windows Server-Anwendungs-Image zur Verwendung mit privaten Clustern erstellen

  1. 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 1909. Stellen Sie außerdem sicher, dass eine Internetverbindung besteht.

  2. Wechseln Sie auf der Compute Engine-Instanz zur Docker-Daemon-Konfiguration:

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

  3. 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": ["gcr.io"]
}

    gcr.io bezieht sich auf Container Registry. Dort wird das Image gehostet.

  4. Starten Sie den Docker-Daemon neu:

    PS C:\> Restart-Service docker

  5. Erstellen und taggen Sie das Docker-Image für Ihre Anwendung:

    PS C:\> cd C:\my-app

    PS C:\my-app> docker build -t gcr.io/my-project/my-app:v2 .

    Dieser Befehl weist Docker an, das Image mithilfe des Dockerfiles im aktuellen Verzeichnis zu erstellen und mit einem Namen wie gcr.io/my-project/my-app:v2 zu taggen.

  6. Übertragen Sie das Docker-Image der Anwendung in die gcr.io-Registry in my-project. Die Konfiguration allow-nondistributable-artifacts bewirkt, dass die Windows-Basisebenen in Ihre private Registry übertragen werden.

    PS C:\my-app> docker push gcr.io/my-project/my-app:v2

Manifestdatei für das Deployment erstellen

Es folgt eine Beispiel-Manifestdatei für ein Deployment mit dem Namen my-app.yaml. Das Image in diesem Beispiel ist jenes, das Sie im vorherigen Schritt übertragen haben (gcr.io/my- project/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: gcr.io/my-project/my-app:v2

So stellen Sie diese Anwendung in dem privaten Cluster bereit:

gcloud container clusters get-credentials var>private-cluster-name
kubectl apply -f my-app.yaml

Dabei ist private-cluster-name der Name des von Ihnen erstellten Clusters.

Prüfen, ob der Pod ausgeführt wird

Lassen Sie alle Pods auflisten, um zu prüfen, ob der Pod richtig ausgeführt wird.

kubectl get pods

Im erwarteten Ergebnis sollte der Pod mit dem Status Running 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 (LTSC oder SAC) 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-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.