Esta página foi traduzida pela API Cloud Translation.

Como implantar um aplicativo do Windows Server

Padrão

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

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

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

Ativar APIs

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da gcloud CLI, 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 com nós públicos

Para implantar um aplicativo do Windows Server em um cluster do GKE com apenas nós públicos, você precisará realizar as seguintes tarefas:

Crie um cluster com nós públicos.
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 com nós públicos

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. Para provisionar nós com endereços IP externos (nós públicos), use a flag --no-enable-private-nodes ao criar o cluster.

Criar um arquivo de manifesto de implantação

Os nós do Windows Server têm taint com o seguinte par de chave-valor: 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 executada em todos os nós do Linux e do Windows Server no cluster, o arquivo de manifesto não vai 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 com nós particulares

Esta seção mostra como implantar um aplicativo de contêiner do Windows Server em um cluster do GKE ativado apenas com nós particulares.

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 particulares não têm conectividade com a Internet, as camadas de contêiner base do Windows Server não podem ser extraídas diretamente dos servidores da Microsoft.

Para usar clusters com nós particulares ativados, 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 ativado com nós particulares:

Crie um cluster com nós do Windows Server e ative os nós particulares.
Crie a imagem do Docker do aplicativo do Windows Server.
Implante o aplicativo em um cluster ativado com nós particulares.
Verifique se o pod está em execução.

Criar um cluster com nós particulares

Siga as instruções em Como criar um cluster com nós do Windows Server. Para provisionar nós com apenas endereços IP internos (nós particulares), use a flag --enable-private-nodes ao criar o cluster.

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 que você criou.
Implante o aplicativo especificado no arquivo my-app.yaml no cluster:
```
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.