Como implantar um aplicativo do Windows Server


Nesta página, você aprenderá a implantar um aplicativo sem estado do Windows Server. Também é possível aprender a implantar um aplicativo do Windows com estado.

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

As tarefas a seguir orientam você na implantação do aplicativo do Windows Server:

  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.

Crie um cluster

Para instruções, consulte Criar um cluster usando 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, execute o comando a seguir:

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

Verificar se o pod 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 de IP externo seja preenchido.

    kubectl get service iis
    

    Você verá a seguinte saída:

    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 particular 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 uma imagem de aplicativo do Windows Server para uso com clusters particulares.

  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:

    PS C:\> 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"]
    }
    

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

  4. Reinicie o daemon do Docker:

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

    PS C:\> cd C:\my-app
    
    PS 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.

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

Criar um arquivo de manifesto de implantação

Veja abaixo 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

Para implantar esse aplicativo no seu cluster privado:

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

Em que private-cluster-name é o nome do cluster que você criou.

Verificar se o pod está em execução

Liste todos os pods para garantir que ele esteja sendo executado corretamente.

kubectl get pods

O resultado esperado precisa mostrar o pod com um status de Running.

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.