Execução de contêineres do Windows no AKS

Este artigo deve ser considerado como uma extensão da arquitetura AKS Baseline, que fornece uma revisão completa das configurações recomendadas para implantar um cluster AKS em um ambiente de produção. O foco deste artigo é fornecer orientação relativa à implantação de contêineres do Windows no AKS. Como tal, este artigo se concentra nas configurações específicas para implantar o Windows no AKS e você deve consultar a documentação do AKS Baseline para obter as configurações já descritas lá.

Consulte o projeto GitHub de linha de base do AKS Windows para revisar a implementação de referência associada a essa arquitetura de referência, incluindo código de implantação de exemplo.

Design de rede

O design de rede usado nessa arquitetura é baseado no design usado na arquitetura AKS Baseline e, portanto, compartilha todos os componentes principais com esse projeto, exceto as alterações a seguir.

• Os controladores de domínio do Active Directory foram adicionados para oferecer suporte às cargas de trabalho baseadas no Windows.
• A solução de entrada nessa arquitetura usa o Azure Front Door (AFD) e o proxy de aplicativo do Microsoft Entra em vez do Gateway de Aplicativo do Azure, que é usado na arquitetura AKS Baseline.

Design de entrada

Componentes:

• Azure Front Door com WAF: o AFD é o ponto de entrada voltado para o público para os aplicativos hospedados no cluster AKS. O AFD Premium é usado neste design, pois permite o uso do Private Link, que bloqueia o tráfego interno do aplicativo para a rede privada, fornecendo o mais alto nível de segurança. Instale o Firewall do Aplicativo Web (WAF) protege contra explorações e vulnerabilidades comuns de aplicativos Web.
• Proxy de aplicativo Microsoft Entra: Este componente serve como o segundo ponto de entrada na frente do balanceador de carga interno gerenciado pelo AKS. Ele tem o Microsoft Entra ID habilitado para pré-autenticação de usuários e usa uma política de acesso condicional para impedir que intervalos de IP não autorizados (o proxy de aplicativo vê o IP do cliente de origem, que ele compara à política de acesso condicional) e os usuários acessem o site. Essa é a única maneira de rotear solicitações de autenticação Kerberos ao usar um serviço do Azure que ofereça suporte ao WAF. Para obter uma descrição detalhada do fornecimento de acesso de logon único a aplicativos protegidos por Proxy de Aplicativo, consulte Delegação Restrita de Kerberos para logon único (SSO) para seus aplicativos com Proxy de Aplicativo
• Balanceador de carga interno: Gerenciado pelo AKS. Esse balanceador de carga expõe o controlador de entrada por meio de um endereço IP estático privado. Ele serve como um único ponto de contato que recebe solicitações HTTP.
• Nenhum controlador de entrada no cluster (como o Nginx) é usado nessa arquitetura.

Para implementar esse design, o AFD deve ser configurado para usar a URL do Proxy de Aplicativo que é criada quando o aplicativo é publicado nesse serviço. Essa configuração roteia o tráfego de entrada para o proxy e permite que a pré-autenticação aconteça.

Topologia de rede

O diagrama abaixo mostra o design de rede hub-spoke usado nessa arquitetura.

Baixe um Arquivo Visio dessa arquitetura.

Topologia do pool de nós

Essa arquitetura usa três pools de nós: um pool de nós do sistema executando o Linux, um pool de nós do usuário executando o Linux e um pool de nós do usuário executando o Windows. Os pools de nós de usuário do Windows e Linux são usados para cargas de trabalho, enquanto o pool de nós do sistema é usado para todas as configurações no nível do sistema, como CoreDNS.

Fluxo de tráfego de entrada

1. O cliente envia uma solicitação HTTPS para o nome de domínio: bicycle.contoso.com. Esse nome está associado ao registro DNS A do endereço IP público do Azure Front Door. Esse tráfego é criptografado para garantir que o tráfego entre o navegador do cliente e o gateway não possa ser inspecionado ou alterado.
2. O Azure Front Door tem um WAF (firewall do aplicativo Web) integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas criptografias seguras. O Gateway do Azure Front Door é um ponto de terminação TLS, porque é necessário para processar regras de inspeção de WAF e executar regras de roteamento que encaminham o tráfego para o back-end configurado. O certificado TLS é armazenado no Azure Key Vault
3. O AFD roteia a solicitação do usuário para o Proxy de Aplicativo do Azure. O AFD está configurado para permitir apenas tráfego HTTPS. O usuário deve autenticar com o Microsoft Entra ID se a pré-autenticação estiver habilitada.
4. O Proxy de Aplicativo roteia o usuário para o contêiner de aplicativo de back-end por meio do balanceador de carga AKS.

Fluxo de tráfego de saída

Todas as diretrizes encontradas no artigo Linha de base do AKS se aplicam aqui com uma recomendação adicional para cargas de trabalho do Windows: para aproveitar as atualizações automáticas do Windows Server, você não deve bloquear os FQDNs necessários no conjunto de regras do Firewall do Azure.

Planejamento de endereço IP

Ao contrário dos clusters AKS com pools de nós Linux, os clusters AKS com pools de nós do Windows exigem o Azure CNI. O uso do CNI do Azure permite que um pod seja atribuído a um endereço IP de uma Rede Virtual do Azure. Então, o pod pode se comunicar pela Rede Virtual do Azure, assim como qualquer outro dispositivo. Ele pode se conectar a outros pods, a redes ponto a ponto ou redes locais usando o ExpressRoute ou uma VPN, ou a outros serviços do Azure usando o Link Privado.

Todas as diretrizes relativas ao planejamento dos endereços IP fornecidas no artigo Arquitetura do AKS Baseline se aplicam aqui, com uma recomendação adicional: considere o provisionamento de uma sub-rede dedicada para seus controladores de domínio. Com relação ao pool de nós do Windows, é recomendável separá-lo dos outros pools de nós logicamente por meio de sub-redes separadas.

Upgrade do pool de nós

O processo de atualização dos nós do Windows não foi alterado em relação às orientações fornecidas na documentação de atualização de imagem nó do Serviço de Kubernetes do Azure (AKS) mas você deve considerar as seguintes diferenças de agendamento para planejar sua cadência de atualização.

A Microsoft fornece novas imagens do Windows Server, incluindo patches atualizados, para nós mensalmente e não executa nenhum patch ou atualização automática. Como tal, você deve atualizar manualmente ou programaticamente seus nós de acordo com este cronograma. Usar as Ações do GitHub para criar um trabalho cron executado em uma agenda permite que você programe atualizações mensais programaticamente. A orientação fornecida na documentação vinculada acima reflete os processos do nó Linux, mas você pode atualizar o arquivo YAML para definir sua agenda cron para ser executada mensalmente em vez de quinzenalmente. Você também precisará alterar o parâmetro "runs-on" no arquivo YAML para "windows-latest" para garantir que você esteja atualizando para a imagem mais recente do Windows Server.

Consulte o guia do operador AKS sobre correção e atualização do nó de trabalho para obter orientações adicionais.

Considerações de computação

Os tamanhos de imagem maiores associados a imagens baseadas no servidor Windows exigem a implantação de discos do sistema operacional de tamanho adequado no pool de nós. O uso de discos efêmeros do sistema operacional ainda é recomendado para todos os nós, incluindo o Windows, portanto, certifique-se de entender os requisitos de tamanho aos quais você deve aderir ao planejar sua implantação.

Gerenciamento de identidades

Os contêineres do Windows não podem ser ingressados no domínio, portanto, se você precisar de autenticação e autorização do Active Directory, poderá usar as Contas de Serviço Gerenciado de Grupo (gMSA). Para usar o gMSA, você deve habilitar o perfil gMSA no cluster AKS que executa nós do Windows. Consulte a documentação do gMSA AKS para obter uma revisão completa da arquitetura e um guia sobre como habilitar o perfil.

Dimensionamento de nós e pods

A orientação do dimensionador automático de cluster permanece inalterada para contêineres do Windows. Consulte a documentação do Cluster autoscaler para obter orientação.

A documentação do cluster de linha de base descreve as abordagens de dimensionamento manual e automático disponíveis para dimensionamento de pod. Ambas as abordagens estão disponíveis para clusters que executam contêineres do Windows e as diretrizes fornecidas nesse artigo geralmente também se aplicam aqui.

O que difere entre contêineres Linux e Windows em relação às operações de dimensionamento de pod é o tamanho da imagem na maioria dos casos. Os tamanhos de imagem maiores dos contêineres do Windows provavelmente aumentarão a quantidade de tempo para que as operações de dimensionamento sejam concluídas e, portanto, algumas considerações sobre a abordagem de dimensionamento devem ser tomadas. Esse cenário é comum com aplicativos .NET herdados devido ao tamanho do tempo de execução do .NET. Para reduzir os atrasos na extração da imagem para baixo durante os tempos de dimensionamento, você pode utilizar um DaemonSet para puxar a imagem do ACR para o cache em cada nó do Windows e, portanto, girar os pods com a imagem pré-carregada. A partir desse ponto, os pods precisariam apenas executar os processos de configuração do aplicativo definidos para sua carga de trabalho antes de serem colocados online.

Exercícios de benchmarking devem ser realizados para entender o impacto no tempo da execução de operações de dimensionamento e esses dados devem ser ponderados em relação aos requisitos de negócios. Se sua carga de trabalho precisar ser dimensionada mais rápido do que é possível por meio do dimensionamento automático, é recomendável considerar a seguinte solução alternativa "hot spare":

Primeiro, você precisará realizar testes de linha de base para identificar quantos pods você precisará executar nos horários de pico de carga e fora dos horários de pico de carregamento. Com essa linha de base estabelecida, você pode planejar sua contagem de nós para contabilizar o número total de nós que você precisará ter disponível a qualquer momento. Essa solução envolve o uso do dimensionamento manual para o cluster e a definição do número inicial de nós para o número de nós fora do pico necessário. Ao se aproximar de um período de tempo de pico, você precisará dimensionar preventivamente para o número de nós de tempo de pico de carga. Com o passar do tempo, você precisará restabelecer sua linha de base regularmente para levar em conta a alteração do uso do aplicativo ou outros requisitos de negócios.

Monitoramento

Os contêineres que executam o Windows podem ser monitorados com o Azure Monitor e o Container Insights, assim como os contêineres do Linux. Como tal, as orientações encontradas no artigo AKS Baseline também se aplicam aqui na maior parte. No entanto, o monitoramento do Container Insights para um cluster do Windows Server tem as seguintes limitações:

• O Windows não tem uma métrica de RSS de Memória. Como resultado, ela não está disponível para nós e contêineres do Windows. A métrica Conjunto de Trabalho está disponível.
• As informações sobre a capacidade de armazenamento do disco não estão disponíveis para nós do Windows.

Você também pode complementar o Container Insights usando regras de coleta de dados para coletar eventos e contadores de desempenho de seus sistemas Windows Server.

Gerenciamento de política

Todas as diretrizes de política encontradas no artigo de linha de base do AKS se aplicam a cargas de trabalho do Windows. As políticas adicionais específicas do Windows encontradas nas definições internas da Política do Azure para o artigo de referência do Serviço Kubernetes do Azure a serem consideradas são:

• Os contêineres Windows do cluster do Kubernetes não devem sobrecarregar a CPU e a memória
• Os contêineres do Windows do cluster de Kubernetes não devem ser executados como ContainerAdministrator
• Os contêineres Windows do cluster do Kubernetes só devem ser executados com o usuário aprovado e o grupo de usuários de domínio

Inicialização do cluster

Assim como acontece com a orientação de inicialização de cluster fornecida no artigo AKS Baseline, os operadores de cluster também devem considerar sua abordagem de inicialização para cargas de trabalho baseadas no Windows. As mesmas orientações fornecidas no artigo do AKS Baseline também se aplicam aqui.

Gerenciamento de custos

Todas as diretrizes de otimização de custo encontradas no artigo de linha de base do AKS se aplicam a cargas de trabalho do Windows. Outras considerações de custo que devem ser consideradas são:

• Os custos de licenciamento do Windows Server aumentam o custo dos nós para o cluster AKS. As recomendações de otimização de custos para esse fator incluem a reserva de capacidade ou o uso de licenças existentes, se você já as tiver para outros usos comerciais.
  • Consulte a documentação do Benefício Híbrido do Azure para Windows Server(AHUB) para saber mais sobre descontos para suas licenças aplicáveis do Windows Server do Software Assurance (SA).
  • Consulte as Perguntas frequentes sobre contêineres do Windows Server para obter instruções sobre como aplicar o benefício a clusters novos e existentes.
• O tamanho das imagens de contêiner do Windows pode incorrer em custos adicionais do Registro de Contêiner do Azure (ACR) devido à quantidade de armazenamento necessária para várias imagens, ao número de nós simultâneos extraídos do ACR e aos requisitos de replicação geográfica.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Isabelle Bersano | Arquiteto de Soluções em Nuvem
• Akshay Nimbalkar | Arquiteto Principal de Soluções em Nuvem
• Clayton Siemens | Desenvolvedor de Conteúdo Principal

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

• Saiba mais sobre os contêineres do Windows

Recursos relacionados

• Saiba como implantar pools de nós do Windows em um cluster AKS