Como implantar um aplicativo do Windows Server


Nesta página, você aprenderá a implantar um aplicativo sem estado do Windows Server em um cluster do Google Kubernetes Engine (GKE), que pode ser público ou particular. Também é possível aprender a implantar um aplicativo do Windows com estado.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou de Autopilot.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project PROJECT_ID
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone COMPUTE_ZONE
  • Se você estiver trabalhando com clusters de Autopilot ou regionais, defina a região do Compute padrão:
    gcloud config set compute/region COMPUTE_REGION
  • Atualize gcloud para a versão mais recente:
    gcloud components update
  • Se você estiver usando o Container Registry (gcr.io) para hospedar as imagens, verifique se está configurado para enviar e extrair as imagens.

Como implantar um aplicativo do Windows Server em um cluster padrão

Para implantar um aplicativo do Windows Server em um cluster público do GKE, você precisará executar as seguintes tarefas:

  1. Crie um cluster.
  2. Crie um arquivo de manifesto de implantação.
  3. Crie e exponha a implantação.
  4. Verifique se o pod está em execução.

Criar um cluster

Se você já tiver um cluster do GKE que use pools de nós do Windows Server, passe para a próxima etapa. Crie um cluster usando os pools de nós do Windows Server.

Criar um arquivo de manifesto de implantação

Os nós do Windows Server têm taint com o par de chave-valor a seguir: node.kubernetes.io/os=windows:NoSchedule.

Esse taint garante que o programador do GKE não tente executar contêineres do Linux em nós do Windows Server. Para programar contêineres do Windows Server em nós desse sistema operacional, o arquivo de manifesto precisa incluir este seletor de nós:

nodeSelector:
 kubernetes.io/os: windows

Um webhook de admissão em execução no cluster verifica novas cargas de trabalho quanto à presença desse seletor de nós do Windows e, quando encontrado, aplica a tolerância à carga de trabalho a seguir, que permite a execução nos nós do Windows Server corrompidos:

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

Em alguns casos, talvez seja necessário incluir essa tolerância explicitamente no arquivo de manifesto. Por exemplo, se você estiver implantando um DaemonSet com uma imagem de contêiner multi-arch para ser executado em todos os nós do Linux e do Windows Server no cluster, o arquivo de manifesto não incluirá o seletor de nós do Windows. Você precisa incluir explicitamente a tolerância para o taint do Windows.

Exemplo de arquivo do manifesto

O exemplo de arquivo a seguir (iis.yaml) implanta a imagem IIS da Microsoft em um único pod:

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

Esse arquivo é para um cluster em que todas as cargas de trabalho usam o mesmo tipo de imagem e versão do nó do Windows Server. Para detalhes sobre como trabalhar com imagens de nó mistas, consulte esta seção.

Criar e expor a implantação

Crie e exponha o arquivo de implantação criado na etapa anterior como um serviço do Kubernetes com uma implantação de balanceador de carga externo.

  1. Para criar a implantação, execute o comando a seguir:

    kubectl apply -f iis.yaml
    
  2. Para expor a implantação como um balanceador de carga externo, execute o seguinte comando:

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

Verifique se ele está em execução

Verifique se o pod está funcionando por meio da validação.

  1. Verifique o status do pod usando kubectl:

    kubectl get pods
    
  2. Aguarde até que a saída retornada mostre que o pod tem Running como seu status:

    NAME                   READY     STATUS    RESTARTS   AGE
    iis-5c997657fb-w95dl   1/1       Running   0          28s
    
  3. Receba o status do serviço e aguarde até que o campo EXTERNAL-IP seja preenchido:

    kubectl get service iis
    

    Você verá esta resposta:

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

Agora você pode usar o navegador para abrir http://EXTERNAL_IP e ver a página da Web do IIS.

Como implantar um aplicativo do Windows Server em um cluster particular

Nesta seção, você verá como implantar um aplicativo de contêiner do Windows Server em um cluster privado.

As imagens de contêiner do Windows Server têm várias camadas, e as camadas de base são fornecidas pela Microsoft. As camadas de base são armazenadas como uma camada externa em vez de serem incorporadas com a imagem, como acontece com as camadas de imagem do Docker. Quando uma imagem de contêiner do Windows Server é extraída pela primeira vez, as camadas de base geralmente precisam ser baixadas dos servidores da Microsoft. Como os nós de cluster privados não têm conectividade com a Internet, as camadas de contêiner base do Windows Server não podem ser obtidas diretamente dos servidores da Microsoft.

Para usar clusters particulares, configure o daemon do Docker para permitir o envio de camadas não distribuíveis para registros particulares. Para saber mais, consulte Considerações sobre registros com intervalo de tempo insuficiente (em inglês) na página do GitHub do Docker.

Para implantar o aplicativo do Windows Server em um cluster particular:

  1. Crie um cluster privado com nós do Windows Server.
  2. Crie a imagem do Docker do aplicativo do Windows Server.
  3. Implante o aplicativo em um cluster privado.
  4. Verifique se o pod está em execução.

crie um cluster privado

Siga as instruções em Como criar um cluster com nós do Windows Server e Como criar um cluster particular para criar e adicionar um pool de nós do Windows a um cluster particular.

Crie a imagem do Docker do aplicativo do Windows Server

  1. Para criar a imagem do Docker, inicie uma instância do Compute Engine com a versão do Windows Server em que você quer executar os contêineres do aplicativo, como o Windows Server 2019 ou a versão 1909. Além disso, verifique se você tem conectividade com a Internet.

  2. Na instância do Compute, navegue até a configuração do Docker daemon:

    cat C:\ProgramData\docker\config\daemon.json
    
  3. Configure o arquivo daemon.json do Docker para permitir que camadas externas sejam enviadas ao seu registro particular adicionando estas linhas:

    {
      "allow-nondistributable-artifacts": ["gcr.io"]
    }
    

    Neste exemplo, gcr.io refere-se ao Container Registry, em que a imagem será hospedada.

  4. Reinicie o daemon do Docker:

    Restart-Service docker
    
  5. Crie e marque a imagem do Docker para seu aplicativo:

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

    Este comando instrui o Docker a construir a imagem usando o Dockerfile no diretório atual e marcá-la com um nome, como gcr.io/my-project/my-app:v2.

  6. Envie a imagem do Docker do aplicativo para o registro gcr.io em my-project. O conjunto de configurações allow-nondistributable-artifacts faz com que as camadas de base do Windows sejam enviadas para seu registro particular.

    docker push gcr.io/my-project/my-app:v2
    

Criar um arquivo de manifesto de implantação

Veja a seguir um exemplo de arquivo de manifesto de implantação chamado my-app.yaml. A imagem neste exemplo é a que você enviou na etapa anterior (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
  1. Use o comando get-credentials para permitir que kubectl funcione com o cluster que você criou.

    gcloud container clusters get-credentials CLUSTER_NAME
    

    Substitua CLUSTER_NAME pelo nome do cluster particular que você criou.

  2. Implante o aplicativo especificado no arquivo my-app.yaml no cluster particular:

    kubectl apply -f my-app.yaml
    

Verificar se o pod está em execução

Liste todos os pods para garantir que o aplicativo esteja sendo executado corretamente:

kubectl get pods

Você verá o pod com um status Running como este:

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

Como usar imagens de nó mistas

Os clusters podem conter pools de nós com vários tipos e versões do Windows Server. Eles também podem combinar cargas de trabalho do Windows Server e do Linux. As seções a seguir fornecem detalhes sobre como configurar suas cargas de trabalho para usar esses tipos de clusters.

Como usar cargas de trabalho com diferentes tipos de imagem de nó do Windows Server

É possível adicionar pools de nós usando diferentes tipos de imagem do Windows Server (LTSC ou SAC) ao cluster. Em um cluster com tipos mistos do Windows Server, você precisa garantir que seus contêineres do Windows Server não estejam programados em um nó incompatível do Windows Server.

Se você tiver um pool de nós LTSC do Windows Server e um pool de nós SAC do Windows Server, adicione o rótulo do nó gke-os-distribution às duas cargas de trabalho.

Inclua o nodeSelector a seguir no arquivo de manifesto para suas cargas de trabalho LTSC do Windows Server:

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

Inclua o nodeSelector a seguir no arquivo de manifesto para suas cargas de trabalho SAC do Windows Server:

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

A adição desse rótulo garante que suas imagens de contêiner LTSC não sejam programadas em nós SAC incompatíveis e vice-versa.

Como usar cargas de trabalho com diferentes versões do Windows Server

Se você precisar executar pools de nós do Windows Server com várias versões diferentes de LTSC ou SAC, recomendamos criar suas imagens de contêiner como imagens de vários arquivamentos que podem ser executadas em todas as versões do Windows Server em uso no cluster. O rótulo do nó gke-os-distribution não é suficiente para impedir que suas cargas de trabalho sejam possivelmente programadas em nós incompatíveis.

Como usar cargas de trabalho do Linux e do Windows Server em um cluster

Adicione o seletor de nó a seguir às cargas de trabalho do Linux para garantir que elas estejam sempre programadas nos nós do Linux:

nodeSelector:
   kubernetes.io/os: linux

Isso fornece mais proteção para evitar que as cargas de trabalho do Linux sejam programadas nos nós do Windows Server caso o taint NoSchedule seja removido acidentalmente dos nós do Windows Server.