Como implantar um aplicativo do Windows Server

Padrão

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:

Ative a API Artifact Registry e a API Google Kubernetes Engine.

Ative as APIs

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

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:

Crie um cluster.
Crie um arquivo de manifesto de implantação.
Crie e exponha a implantação.
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.

Para criar a implantação, execute o comando a seguir:
```
kubectl apply -f iis.yaml
```
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.

Verifique o status do pod usando kubectl:
```
kubectl get pods
```

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

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 Permitir o envio de artefatos não distribuíveis na página do GitHub do Docker.

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

Crie um cluster privado com nós do Windows Server.
Crie a imagem do Docker do aplicativo do Windows Server.
Implante o aplicativo em um cluster privado.
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

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 20H2. Além disso, verifique se você tem conectividade com a Internet.
Na instância do Compute, navegue até a configuração do Docker daemon:
```
cat C:\ProgramData\docker\config\daemon.json
```
Configure o arquivo daemon.json do Docker para permitir que camadas externas sejam enviadas ao seu registro particular adicionando estas linhas:
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
Neste exemplo, REGISTRY_REGION-docker.pkg.dev refere-se ao Artifact Registry, em que a imagem será hospedada.
Reinicie o daemon do Docker:
```
Restart-Service docker
```
Criar um repositório do Docker no Artifact Registry
Crie e marque a imagem do Docker para seu aplicativo:
```
cd C:\my-app
```
```
docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/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 us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.
Envie a imagem do Docker do aplicativo para o repositório do Artifact Registry no seu projeto. 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 REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/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 (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

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.
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 imagens do Windows Server no 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 SO do Windows Server LTSC

Os nós do Windows Server oferecem suporte às imagens do SO LTSC2022 e LTSC2019. Especifique a versão do SO do Windows a ser usada (LTSC2022) com o seguinte par de chave-valor no nodeSelector: cloud.google.com/gke-windows-os-version=2022.

Esse rótulo de nó garante que o programador do GKE escolha os nós corretos do Windows Server para executar as cargas de trabalho LTSC2022 ou LTSC2019. Os dois nós do Windows Server pertencem ao tipo de imagem windows_ltsc_containerd. O valor do rótulo do nó pode ser 2022 ou 2019. Se o rótulo do nó não for especificado, os dois nós LTSC2019 ou LTSC2022 poderão ser usados para programar contêineres. Para programar contêineres do Windows Server apenas em nós LTSC2022 do Windows Server, o arquivo de manifesto precisa incluir este seletor de nós:

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

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.