Compartilhar via


Implantar um contêiner do Windows Server em um cluster do AKS (Serviço de Kubernetes do Azure) usando a CLI do Azure

O AKS (Serviço de Kubernetes do Azure) é um serviço de Kubernetes gerenciado que permite implantar e gerenciar clusters rapidamente. Neste artigo, você usará a CLI do Azure para implantar um cluster do AKS que executa contêineres do Windows Server. Também implanta um aplicativo de exemplo do ASP.NET em um contêiner do Windows Server para o cluster.

Observação

Para começar a provisionar rapidamente um cluster do AKS, este artigo inclui etapas para implantar um cluster com configurações padrão somente para fins de avaliação. Antes de implantar um cluster pronto para produção, recomendamos que você se familiarize com nossa arquitetura de referência de linha de base para considerar como ele se alinha aos seus requisitos de negócios.

Antes de começar

Este guia de início rápido pressupõe uma compreensão básica dos conceitos do Kubernetes. Para obter mais informações, confira Principais conceitos do Kubernetes para o AKS (Serviço de Kubernetes do Azure).

  • Se você ainda não tiver uma conta do Azure, crie uma conta gratuita antes de começar.
  • Este artigo exige a versão 2.0.64 ou posterior da CLI do Azure. Se você estiver usando o Azure Cloud Shell, a versão mais recente já está instalada lá.
  • Certifique-se de que a identidade que você está usando para criar seu cluster tenha as permissões mínimas apropriadas. Para obter mais detalhes sobre acesso e identidade do AKS, consulte Opções de acesso e identidade para o AKS (Serviço de Kubernetes do Azure).
  • Se tiver várias assinaturas do Azure, selecione a ID da assinatura adequada para cobrança dos recursos usando o comando az account set. Para obter mais informações, veja Como gerenciar assinaturas do Azure – CLI do Azure.
  • Se você estiver usando --os-sku Windows2025, será necessário instalar a aks-preview extensão e registrar o sinalizador de visualização. A versão mínima é 18.0.0b40.

Instalar a aks-preview extensão

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

  1. Instale a extensão aks-preview da CLI do Azure usando o comando az extension add.
az extension add --name aks-preview
  1. Atualize para a última versão da extensão usando o comando az extension update. O Windows Server 2025 requer um mínimo de 18.0.0b40.
az extension update --name aks-preview

Registrar o sinalizador de recurso AksWindows2025Preview

  1. Registre o sinalizador do recurso AksWindows2025Preview usando o comando [az feature register][az-feature-register].
az feature register --name AksWindows2025Preview --namespace Microsoft.ContainerService
  1. Verifique o status do registro usando o comando [az feature show][az-feature-show]. Demora alguns minutos para o status mostrar Registrado.
az feature show --name AksWindows2025Preview --namespace Microsoft.ContainerService
  1. Quando o status refletir Registrado, atualize o registro do provedor do recurso Microsoft.ContainerService usando o comando [az provider register][az-provider-register].

    az provider register --namespace Microsoft.ContainerService
    

Criar um grupo de recursos

Um grupo de recursos do Azure é um grupo lógico no qual os recursos do Azure são implantados e gerenciados. Ao criar um grupo de recursos, você é solicitado a especificar um local. Essa é a localização na qual os metadados do grupo de recursos são armazenados e na qual os recursos são executados no Azure, caso você não especifique outra região durante a criação de recursos.

  • Crie um grupo de recursos usando o comando az group create. O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local westus2 .

    export RANDOM_SUFFIX=$(openssl rand -hex 3)
    export REGION="canadacentral"
    export MY_RESOURCE_GROUP_NAME="myAKSResourceGroup$RANDOM_SUFFIX"
    az group create --name $MY_RESOURCE_GROUP_NAME --location $REGION
    

    Resultados:

    {
      "id": "/subscriptions/xxxxx-xxxxx-xxxxx-xxxxx/resourceGroups/myResourceGroupxxxxx",
      "location": "WestUS2",
      "managedBy": null,
      "name": "myResourceGroupxxxxx",
      "properties": {
        "provisioningState": "Succeeded"
      },
      "tags": null,
      "type": "Microsoft.Resources/resourceGroups"
    }
    

Criar um cluster AKS

Nesta seção, criamos um cluster do AKS com a seguinte configuração:

  • O cluster é configurado com dois nós para garantir que ele opere de forma confiável. Um é uma máquina virtual (VM) do Azure que executa os componentes do nó do Kubernetes e o runtime do contêiner.
  • Os parâmetros --windows-admin-password e --windows-admin-username definem as credenciais de administrador para qualquer nó do Windows Server no cluster e devem atender aos requisitos de senha do Windows Server.
  • O pool de nós usa VirtualMachineScaleSets.

Use as seguintes etapas para criar o cluster do AKS com a CLI do Azure:

  1. Crie um nome de usuário para usá-lo como as credenciais de administrador nos nós do Windows Server no seu cluster.

    export WINDOWS_USERNAME="winadmin"
    
  2. Crie uma senha para o nome de usuário do administrador que você criou na etapa anterior. A senha deve ter no mínimo 14 caracteres e atender aos requisitos de complexidade de senha do Windows Server.

    export WINDOWS_PASSWORD=$(echo "P@ssw0rd$(openssl rand -base64 10 | tr -dc 'A-Za-z0-9!@#$%^&*()' | cut -c1-6)")
    
  3. Crie seu cluster usando o comando az aks create e especifique os parâmetros --windows-admin-username e --windows-admin-password. O comando de exemplo a seguir cria um cluster usando os valores de WINDOWS_USERNAME e WINDOWS_PASSWORD que você definiu nos comandos anteriores. Um sufixo aleatório é acrescentado ao nome do cluster para exclusividade.

    export MY_AKS_CLUSTER="myAKSCluster$RANDOM_SUFFIX"
    az aks create \
        --resource-group $MY_RESOURCE_GROUP_NAME \
        --name $MY_AKS_CLUSTER \
        --node-count 2 \
        --enable-addons monitoring \
        --generate-ssh-keys \
        --windows-admin-username $WINDOWS_USERNAME \
        --windows-admin-password $WINDOWS_PASSWORD \
        --vm-set-type VirtualMachineScaleSets \
        --network-plugin azure
    

    Após alguns minutos, o comando será concluído e retornará informações no formato JSON sobre o cluster. Ocasionalmente, o cluster pode levar mais de alguns minutos para ser provisionado. Aguarde até 10 minutos para o provisionamento.

    Se você receber um erro de validação de senha e a senha definida atender aos requisitos de comprimento e complexidade, tente criar seu grupo de recursos em outra região. Em seguida, tente criar o cluster com o novo grupo de recursos.

    Se você não especificar um nome de usuário e senha de administrador ao criar o pool de nós, o nome de usuário será definido como azureuser e a senha será definida como um valor aleatório. Para obter mais informações, consulte as Perguntas frequentes do Windows Server

    Você não pode alterar o nome de usuário do administrador, mas pode alterar a senha de administrador que o cluster do AKS usa para nós do Windows Server usando az aks update. Para saber mais, confira Perguntas frequentes sobre o Windows Server.

    Para executar um cluster AKS que dá suporte aos pools de nós para contêineres do Windows Server, o cluster precisa usar uma política de rede que usa o plug-in de rede CNI do Azure (avançado). O parâmetro --network-plugin azure especifica a CNI do Azure.

Adicionar um pool de nós

Por padrão, todos os clusters do AKS são criados com um pool de nós que pode executar contêineres do Linux. Você deve adicionar um pool de nós do Windows que possa executar contêineres do Windows Server ao lado do pool de nós do Linux. Para verificar se você tem um pool de nós do Windows em seu cluster, você pode exibir os nós em seu cluster usando o kubectl get nodes -o wide comando.

Para criar um pool de nós do Windows, você precisa especificar um suporte OsType e OsSku. Use as informações na tabela a seguir para determinar qual é apropriado para o cluster:

OsType OsSku Padrão Versões do K8s com suporte Detalhes
windows Windows2025 Atualmente, na versão preliminar. Não é padrão. 1.32+ Padrões atualizados: containerd 2.0, a imagem de Geração 2 é usada por padrão.
windows Windows2022 Padrão nos K8s 1.25-1.35 Não disponível em K8s 1.36+ Aposenta em março de 2027. Padrões atualizados: o FIPS está habilitado por padrão.
windows Windows2019 Padrão no K8s 1.24 e abaixo Não disponível no K8s 1.33+ Aposenta em março de 2026.

O Windows Server 2022 é o sistema operacional padrão para versões do Kubernetes 1.25-1.35. O Windows Server 2019 é o sistema operacional padrão para versões anteriores. Se você não especificar um SKU do sistema operacional específico, o Azure criará o novo pool de nós com a SKU padrão para a versão do Kubernetes usada pelo cluster.

Observação

  • O Windows Server 2019 se desativa em 1º de março de 2026. Após essa data, o AKS não produzirá mais novas imagens de nó ou fornecerá patches de segurança. Após essa data, você não poderá mais criar novos pools de nós usando o Windows Server 2019 em qualquer versão do Kubernetes. Todos os pools de nós existentes com o Windows Server 2019 não terão suporte. Não há suporte para o Windows Server 2019 no Kubernetes versão 1.33 e superior. A partir de 1º de abril de 2027, o AKS removerá todas as imagens de nós existentes para Windows Server 2019, o que significa que as operações de dimensionamento falharão.
  • O Windows Server 2022 se desativa em 15 de março de 2027. Após essa data, o AKS não produzirá mais novas imagens de nó ou fornecerá patches de segurança. Após essa data, você não poderá criar novos pools de nós com o Windows Server 2022 em qualquer versão do Kubernetes. Todos os pools de nós existentes com o Windows Server 2022 não terão suporte. Não há suporte para o Windows Server 2022 no Kubernetes versão 1.36 e superior. A partir de 1º de abril de 2028, o AKS removerá todas as imagens de nós existentes para Windows Server 2022, o que significa que as operações de dimensionamento falharão.

Para obter mais informações, confira Notas de lançamento do AKS. Para se manter atualizado sobre as versões mais recentes do sistema operacional do Windows Server e saber mais sobre nosso roteiro do que está planejado para o suporte no AKS, consulte nosso roteiro público do AKS.

  • Adicione um pool de nós do Windows usando o comando az aks nodepool add com um OsType e OsSku especificados. Se você não especificar um SKU do sistema operacional específico, o Azure criará o novo pool de nós com a SKU padrão para a versão do Kubernetes usada pelo cluster.

    az aks nodepool add \
      --resource-group $MY_RESOURCE_GROUP_NAME \
      --cluster-name $MY_AKS_CLUSTER \
      --os-type Windows \
      --os-sku Windows2022 \
      --name npwin \
      --node-count 1
    

    Esse comando cria um novo pool de nós chamado npwin e o adiciona ao myAKSCluster. O comando acima também usa a sub-rede padrão na VNet padrão criada durante a execução de az aks create.

Conectar-se ao cluster

Para gerenciar um cluster do Kubernetes, use o kubectl, o cliente de linha de comando do Kubernetes. Se você usar o Azure Cloud Shell, o kubectl já estará instalado. Se você quiser instalar e executar kubectl localmente, use o az aks install-cli comando.

  1. Configure o kubectl para se conectar ao cluster do Kubernetes usando o comando az aks get-credentials. Este comando baixa as credenciais e configura a CLI do Kubernetes para usá-las.

    az aks get-credentials --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_AKS_CLUSTER
    
  2. Verifique a conexão com seu cluster usando o comando kubectl get, que retorna uma lista de nós de cluster.

    kubectl get nodes -o wide
    

    Os resultados de exemplo a seguir mostram todos os nós no cluster. Verifique se o status de todos os nós é Pronto:

    NAME                                STATUS   ROLES   AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION      CONTAINER-RUNTIME
    aks-nodepool1-20786768-vmss000000   Ready    agent   22h   v1.27.7   10.224.0.4    <none>        Ubuntu 22.04.3 LTS               5.15.0-1052-azure   containerd://1.7.5-1
    aks-nodepool1-20786768-vmss000001   Ready    agent   22h   v1.27.7   10.224.0.33   <none>        Ubuntu 22.04.3 LTS               5.15.0-1052-azure   containerd://1.7.5-1
    aksnpwin000000                      Ready    agent   20h   v1.27.7   10.224.0.62   <none>        Windows Server 2022 Datacenter   10.0.20348.2159     containerd://1.6.21+azure
    

    Observação

    O runtime do contêiner para cada pool de nós é mostrado em CONTAINER-RUNTIME. Os valores de runtime do contêiner começam com containerd://, o que significa que cada um deles usa containerd para o runtime do contêiner.

Implantar o aplicativo

Um arquivo de manifesto do Kubernetes define um estado desejado para o cluster, como as imagens de contêiner a serem executadas. Neste artigo, você usa um manifesto para criar todos os objetos necessários para executar o aplicativo de exemplo ASP.NET em um contêiner do Windows Server. Esse manifesto inclui uma implantação do Kubernetes para o aplicativo de exemplo ASP.NET e um serviço do Kubernetes externo para acessar ao aplicativo da Internet.

O aplicativo de exemplo ASP.NET é fornecido como parte das Amostras .NET Framework e é executado em um contêiner do Windows Server. O AKS requer que os contêineres do Windows Server sejam baseados em imagens do Windows Server 2019 ou posterior. O arquivo de manifesto Kubernetes também deve definir um seletor de nó para instruir o cluster AKS a executar o pod de seu aplicativo de exemplo ASP.NET em um nó que possa executar contêineres do Windows Server.

  1. Crie um arquivo nomeado sample.yaml e copie na seguinte definição yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: sample
      labels:
        app: sample
    spec:
      replicas: 1
      template:
        metadata:
          name: sample
          labels:
            app: sample
        spec:
          nodeSelector:
            "kubernetes.io/os": windows
          containers:
          - name: sample
            image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
            resources:
              limits:
                cpu: 1
                memory: 800M
            ports:
              - containerPort: 80
      selector:
        matchLabels:
          app: sample
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: sample
    spec:
      type: LoadBalancer
      ports:
      - protocol: TCP
        port: 80
      selector:
        app: sample
    

    Para obter um detalhamento dos arquivos de manifesto YAML, confira Implantações e manifestos YAML.

    Se você criar e salvar o arquivo YAML localmente, poderá carregar o arquivo de manifesto no diretório padrão no CloudShell selecionando o botão Carregar/Baixar arquivos e selecionando o arquivo no sistema de arquivos local.

  2. Implante o aplicativo usando o comando kubectl apply e especifique o nome do manifesto YAML.

    kubectl apply -f sample.yaml
    

    A saída de exemplo a seguir mostra a implantação e o serviço criados com êxito:

    {
      "deployment.apps/sample": "created",
      "service/sample": "created"
    }
    

Testar o aplicativo

Quando o aplicativo é executado, um serviço de Kubernetes expõe o front-end do aplicativo à Internet. A conclusão desse processo pode levar alguns minutos. Ocasionalmente, o serviço pode levar mais do que alguns minutos para ser provisionado. Aguarde até 10 minutos para o provisionamento.

  1. Verifique o status dos pods implantados usando o comando kubectl get pods. Garanta que todos os pods estejam Running, antes de continuar.

    kubectl get pods
    
  2. Monitore o andamento usando o comando kubectl get service com o argumento --watch.

    while true; do
      export EXTERNAL_IP=$(kubectl get service sample -o jsonpath="{.status.loadBalancer.ingress[0].ip}" 2>/dev/null)
      if [[ -n "$EXTERNAL_IP" && "$EXTERNAL_IP" != "<pending>" ]]; then
        kubectl get service sample
        break
      fi
      echo "Still waiting for external IP assignment..."
      sleep 5
    done
    

    Inicialmente, a saída mostra o EXTERNAL-IP para o serviço de exemplo como pendente:

    NAME     TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
    sample   LoadBalancer   xx.xx.xx.xx    pending          xx:xxxx/TCP     2m
    
  3. Quando o endereço EXTERNAL-IP for alterado de pendente para um endereço IP público real, use CTRL-C para interromper o processo de inspeção do kubectl.

    A seguinte saída de exemplo mostra um endereço IP público válido atribuído ao serviço:

    {
      "NAME": "sample",
      "TYPE": "LoadBalancer",
      "CLUSTER-IP": "10.0.37.27",
      "EXTERNAL-IP": "52.179.23.131",
      "PORT(S)": "80:30572/TCP",
      "AGE": "2m"
    }
    
  4. Consulte o aplicativo de exemplo em ação abrindo um navegador da Web para o endereço IP externo do serviço após alguns minutos.

    Captura de tela que mostra a navegação para o aplicativo de exemplo do ASP.NET.

Próximas etapas

Neste início rápido, você implantou um cluster Kubernetes e implantou um aplicativo de amostra ASP.NET em um contêiner do Windows Server para ele. Esse aplicativo de exemplo é apenas para fins de demonstração e não representa todas as melhores práticas para aplicativos do Kubernetes. Para obter diretrizes sobre como criar soluções completas com o AKS para produção, consulte Diretrizes sobre a solução AKS.

Para saber mais sobre o AKS e para percorrer um exemplo completo de código para implantação, continue no tutorial do cluster Kubernetes.