Implementar uma aplicação do Windows Server

Padrão

---

Nesta página, vai saber como implementar uma aplicação Windows Server sem estado num cluster do Google Kubernetes Engine (GKE). Também pode saber como implementar uma aplicação Windows com estado.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Artifact Registry e a API Google Kubernetes Engine.
Ativar APIs
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Implementar uma aplicação do Windows Server num cluster com nós públicos

Para implementar uma aplicação Windows Server num cluster do GKE com apenas nós públicos, tem de realizar as seguintes tarefas:

1. Crie um cluster com nós públicos.
2. Crie um ficheiro de manifesto de implementação.
3. Crie e exponha a implementação.
4. Verifique se o Pod está em execução.

Crie um cluster com nós públicos

Se já tiver um cluster do GKE que use pools de nós do Windows Server, continue para o passo seguinte. Caso contrário, crie um cluster com node pools do Windows Server. Para aprovisionar nós com endereços IP externos (nós públicos), use a flag --no-enable-private-nodes ao criar o cluster.

Crie um ficheiro de manifesto de implementação

Os nós do Windows Server estão contaminados com o seguinte par de chave-valor: node.kubernetes.io/os=windows:NoSchedule.

Esta restrição garante que o programador do GKE não tenta executar contentores Linux em nós do Windows Server. Para agendar contentores do Windows Server em nós do Windows Server, o ficheiro de manifesto tem de 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 deste seletor de nós do Windows e, quando encontrado, aplica a seguinte tolerância à carga de trabalho, o que lhe permite ser executada nos nós do Windows Server contaminados:

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

Em alguns casos, pode ter de incluir esta tolerância explicitamente no ficheiro de manifesto. Por exemplo, se estiver a implementar um DaemonSet com uma imagem de contentor multi-arch para ser executada em todos os nós do Linux e do Windows Server no cluster, o ficheiro de manifesto não inclui o seletor de nós do Windows. Tem de incluir explicitamente a tolerância para a restrição do Windows.

Exemplo de ficheiro de manifesto

O ficheiro de implementação de exemplo seguinte (iis.yaml) implementa a imagem do IIS da Microsoft num ú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

Este ficheiro destina-se a um cluster onde todas as cargas de trabalho usam o mesmo tipo e versão de imagem do nó do Windows Server. Para ver detalhes sobre como trabalhar com imagens de nós mistos, consulte a secção Usar imagens de nós mistos.

Crie e exponha a implementação

Crie e exponha o ficheiro de implementação que criou no passo anterior como um serviço do Kubernetes com uma implementação de equilibrador de carga externo.

1. Para criar o recurso Deployment, execute o seguinte comando:

   kubectl apply -f iis.yaml
   

2. Para expor a implementação como um balanceador de carga externo, execute o seguinte comando:

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

Verifique se o Pod está em execução

Certifique-se de que o Pod está a funcionar validando-o.

1. Verifique o estado do Pod através do kubectl:

   kubectl get pods
   

2. Aguarde até que o resultado devolvido mostre que o agrupamento tem Running como estado:

   NAME                   READY     STATUS    RESTARTS   AGE
   iis-5c997657fb-w95dl   1/1       Running   0          28s
   

3. Obtenha o estado do serviço e aguarde até que o campo EXTERNAL-IP seja preenchido:

   kubectl get service iis
   

   Deverá ver o seguinte resultado:

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

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

Implementar uma aplicação do Windows Server num cluster com nós privados

Esta secção mostra como implementar uma aplicação de contentor do Windows Server num cluster do GKE ativado apenas com nós privados.

As imagens de contentores do Windows Server têm várias camadas, e as camadas base são fornecidas pela Microsoft. As camadas base são armazenadas como uma camada externa em vez de serem incorporadas na imagem, como acontece com as camadas de imagens do Linux Docker. Quando uma imagem de contentor do Windows Server é extraída pela primeira vez, as camadas base têm normalmente de ser transferidas dos servidores da Microsoft. Uma vez que os nós privados não têm conetividade à Internet, não é possível extrair diretamente as camadas do contentor base do Windows Server dos servidores da Microsoft.

Para usar clusters com nós privados ativados, pode configurar o daemon do Docker para permitir o envio de camadas não distribuíveis para registos privados. Para saber mais, consulte o artigo Permitir o envio de artefactos não distribuíveis na página do GitHub do Docker.

Para implementar a sua aplicação Windows Server num cluster ativado com nós privados:

1. Crie um cluster com nós do Windows Server e ative os nós privados.
2. Crie a imagem do Docker da aplicação Windows Server.
3. Implemente a aplicação num cluster ativado com nós privados.
4. Verifique se o Pod está em execução.

Crie um cluster com nós privados

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

Crie a imagem do Docker da aplicação Windows Server

1. Para criar a imagem do Docker, inicie uma instância do Compute Engine com a versão do Windows Server na qual quer executar os contentores da sua aplicação, como o Windows Server 2019 ou o Windows Server versão 20H2. Além disso, certifique-se de que tem conetividade de Internet.

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

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

3. Configure o ficheiro daemon.json do Docker para permitir o envio de camadas externas para o seu registo privado adicionando estas linhas:

   {
     "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
   }
   

   Neste exemplo, REGISTRY_REGION-docker.pkg.dev refere-se ao Artifact Registry, onde a imagem vai ser alojada.

4. Reinicie o daemon do Docker:

   Restart-Service docker
   

5. Crie um repositório Docker no Artifact Registry.

6. Crie e etiquete a imagem do Docker para a sua aplicação:

   cd C:\my-app
   

   docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
   

   Este comando indica ao Docker para criar a imagem com o Dockerfile no diretório atual e etiquetá-la com um nome, como us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.

7. Envie a imagem do Docker da aplicação para o repositório do Artifact Registry no seu projeto. A configuração allow-nondistributable-artifacts faz com que as camadas base do Windows sejam enviadas para o seu registo privado.

   docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
   

Crie um ficheiro de manifesto de implementação

Segue-se um exemplo de um ficheiro de manifesto de implementação com o nome my-app.yaml. A imagem neste exemplo é a que enviou no passo 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

1. Use o comando get-credentials para permitir que o kubectl funcione com o cluster que criou:

   gcloud container clusters get-credentials CLUSTER_NAME
   

   Substitua CLUSTER_NAME pelo nome do cluster que criou.

2. Implemente a aplicação especificada no ficheiro my-app.yaml no seu cluster:

   kubectl apply -f my-app.yaml
   

Verifique se o pod está em execução

Liste todos os pods para garantir que a aplicação está a ser executada corretamente:

kubectl get pods

Deve ver o pod com o estado Running, como no seguinte resultado:

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

Usar imagens de nós misturadas

Os seus clusters podem conter conjuntos de nós com vários tipos de Windows Server e versões do Windows Server. Também podem combinar cargas de trabalho do Windows Server e do Linux. As secções seguintes fornecem detalhes sobre como configurar as suas cargas de trabalho para usar estes tipos de clusters.

Usar cargas de trabalho com diferentes tipos de imagens de nós do Windows Server

Pode adicionar pools de nós com diferentes tipos de imagens do Windows Server ao seu cluster. Num cluster com tipos de Windows Server mistos, tem de garantir que os contentores do Windows Server não são agendados num nó do Windows Server incompatível.

Se tiver um pool de nós do Windows Server LTSC e um pool de nós do Windows Server SAC, adicione a etiqueta de nó gke-os-distribution a ambas as cargas de trabalho.

Inclua o nodeSelector seguinte no ficheiro de manifesto para as suas cargas de trabalho do Windows Server LTSC:

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

Inclua o nodeSelector seguinte no ficheiro de manifesto para as suas cargas de trabalho do Windows Server SAC.

Aviso: as imagens do canal semianual (SAC) do Windows Server não são suportadas após 9 de agosto de 2022, uma vez que a Microsoft vai remover o suporte para o SAC. Para ver o potencial impacto e as instruções de migração, consulte o artigo Fim do serviço do canal semianual do Windows Server.

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

A adição desta etiqueta garante que as suas imagens de contentores LTSC não são agendadas em nós SAC incompatíveis e vice-versa.

Usar cargas de trabalho com diferentes versões do SO Windows Server LTSC

Os nós do Windows Server suportam imagens do SO LTSC2022 e LTSC2019. Pode especificar a versão do SO Windows a usar (LTSC2022) com o seguinte par chave-valor em nodeSelector: cloud.google.com/gke-windows-os-version=2022.

Esta etiqueta de nó garante que o programador do GKE escolhe os nós do Windows Server corretos para executar cargas de trabalho do LTSC2022 ou do LTSC2019. Os nós do Windows Server pertencem ao tipo de imagem windows_ltsc_containerd. O valor da etiqueta do nó pode ser 2022 ou 2019. Se a etiqueta do nó não for especificada, é possível usar nós LTSC2019 ou LTSC2022 para agendar contentores. Para agendar contentores do Windows Server apenas em nós do Windows Server LTSC2022, o ficheiro de manifesto tem de 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

Usar cargas de trabalho com diferentes versões do Windows Server

Se precisar de executar pools de nós do Windows Server com várias versões LTSC ou SAC diferentes, recomendamos que crie as suas imagens de contentores como imagens multi-arquitetura que podem ser executadas em todas as versões do Windows Server em utilização no seu cluster. A etiqueta do nó gke-os-distribution não é suficiente para impedir que as suas cargas de trabalho sejam potencialmente agendadas em nós incompatíveis.

Usar cargas de trabalho do Linux e do Windows Server num cluster

Adicione o seguinte seletor de nós às suas cargas de trabalho do Linux para garantir que são sempre agendadas para nós do Linux:

nodeSelector:
   kubernetes.io/os: linux

Isto oferece proteção adicional para evitar que as cargas de trabalho do Linux sejam agendadas em nós do Windows Server caso a marca NoSchedule seja removida acidentalmente dos nós do Windows Server.

Nota: para DaemonSets que são executados apenas no Linux, este nodeSelector é obrigatório.