Executando contêineres do Windows no AKS

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

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

Design de rede

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

• Os controladores de domínio do Active Directory foram adicionados para dar suporte às cargas de trabalho baseadas no Windows.
• A solução de entrada nessa arquitetura usa o AFD (Azure Front Door) e Azure AD Proxy de Aplicativo (AAP) em vez de Azure App Gateway, que é usado na arquitetura da Linha de Base do AKS.

Design de entrada

Componentes:

• Azure Front Door com WAF: AFD é o ponto de entrada voltado para o público para os aplicativos hospedados no cluster do AKS. O AFD Premium é usado nesse design, pois permite o uso de Link Privado, que bloqueia o tráfego interno do aplicativo para a rede privada, fornecendo o mais alto nível de segurança. Firewall de Aplicativo Web (WAF) protege contra vulnerabilidades e explorações comuns de aplicativos Web.
• Azure AD Proxy de Aplicativo: esse componente serve como o segundo ponto de entrada na frente do balanceador de carga interno gerenciado pelo AKS. Ele tem o Azure Active Directory habilitado para pré-autenticação de usuários e usa uma política de acesso condicional para evitar intervalos de IP não autorizados (a AAP vê o IP do cliente de origem, que ele compara com a política de acesso condicional) e os usuários acessam o site. Essa é a única maneira de rotear solicitações de autenticação Kerberos ao usar um serviço do Azure que dá 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 do Kerberos para SSO (logon único) 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 de entrada.
• 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 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 do 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 de usuário executando o Linux e um pool de nós de usuário executando o Windows. Os pools de nós de usuário do Windows e do 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 o 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 para o endereço IP público do Azure Front Door. Esse tráfego é criptografado para garantir que o tráfego entre o navegador cliente e o gateway não possa ser inspecionado ou alterado.
2. O Azure Front Door tem um WAF (firewall de 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, pois é necessário processar regras de inspeção do 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 de usuário para o Proxy de Aplicativo Azure. O AFD está configurado para permitir apenas o tráfego HTTPS. O usuário deve se autenticar com Azure AD se a pré-autenticação estiver habilitada.
4. O Proxy de Aplicativo roteia o usuário para o contêiner do aplicativo de back-end por meio do balanceador de carga do 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 em seu conjunto de regras de Firewall do Azure.

Planejamento de endereço IP

Ao contrário dos clusters do AKS com pools de nós do Linux, os clusters do AKS com pools de nós do Windows exigem CNI do Azure. O uso da CNI do Azure permite que um pod receba um endereço IP de um Rede Virtual do Azure. Em seguida, o pod pode se comunicar por meio do 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 fornecidos no artigo arquitetura de linha de base do AKS se aplicam aqui, com uma recomendação adicional: considere o provisionamento de uma sub-rede dedicada para seus controladores de domínio. Em relação ao pool de nós do Windows, é recomendável separar isso dos outros pools de nós logicamente por meio de sub-redes separadas.

Atualização do pool de nós

O processo de atualização de nós do Windows é inalterado em relação às diretrizes fornecidas na documentação de atualização de imagem do nó 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 nenhuma aplicação automática de patch ou atualizações. Dessa forma, você deve atualizar manual ou programaticamente seus nós de acordo com esse agendamento. Usar GitHub Actions para criar um trabalho cron executado em um agendamento permite agendar atualizações mensais programaticamente. As diretrizes fornecidas na documentação vinculada acima refletem os processos de nó do Linux, mas você pode atualizar o arquivo YAML para definir seu agendamento cron para ser executado mensalmente em vez de quinzenalmente. Você também precisará alterar o parâmetro "run-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 aplicação de patch e atualização de nó de trabalho para obter diretrizes adicionais.

Considerações de computação

Os tamanhos de imagem maiores associados a imagens baseadas em servidor do Windows exigem a implantação de discos do sistema operacional de tamanho apropriado no pool de nós. O uso de discos do sistema operacional efêmero ainda é recomendado para todos os nós, incluindo o Windows, portanto, verifique se você entende os requisitos de tamanho aos quais 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 gMSA ( Contas de Serviço Gerenciado de Grupo ). Para usar gMSA, você deve habilitar o perfil gMSA no cluster do AKS executando nós do Windows. Consulte a documentação do AKS gMSA para obter uma revisão completa da arquitetura e um guia sobre como habilitar o perfil.

Dimensionamento de nó e pod

As diretrizes do dimensionador automático de cluster não são alteradas para contêineres do Windows. Consulte a documentação do dimensionador automático de cluster para obter diretrizes.

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

O que difere entre os contêineres do Linux e do Windows em relação às operações de dimensionamento de pods é 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 runtime do .NET. Para atenuar os atrasos na redução da imagem durante os tempos de dimensionamento, você pode utilizar um DaemonSet para efetuar pull da imagem do ACR para armazenar em cache em cada nó do Windows e, portanto, criar os pods com a imagem pré-carregada. A partir desse ponto, os pods precisariam apenas executar os processos de configuração de aplicativo definidos para sua carga de trabalho antes de serem colocados online.

Os exercícios de benchmarking devem ser executados 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 o possível por meio do dimensionamento automático, é recomendável considerar a seguinte solução alternativa de "sobressalente quente":

Primeiro, você precisará realizar testes de linha de base para identificar quantos pods você precisará executar nos horários de pico de carga e nos horários de carga fora do pico. Com essa linha de base estabelecida, você pode planejar sua contagem de nós para considerar o número total de nós que você precisará ter disponíveis 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 abordar um período de pico, você precisará dimensionar preventivamente para o número de nós de tempo de carga de pico. Com o passar do tempo, você precisará restabelecer sua linha de base regularmente para considerar 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 contêineres do Linux. Dessa forma, as diretrizes encontradas no artigo linha de base do AKS se aplicam aqui também na maior parte do tempo. No entanto, o monitoramento do Insights de Contêiner 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 do 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. Políticas adicionais específicas do Windows encontradas no Azure Policy definições internas para Serviço de Kubernetes do Azure artigo de referência a ser considerado são:

• Os contêineres do Windows do cluster kubernetes não devem comprometer demais 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 as diretrizes de inicialização de cluster fornecidas no artigo linha de base do AKS, os operadores de cluster também devem considerar sua abordagem de inicialização para cargas de trabalho baseadas no Windows. As mesmas diretrizes fornecidas no artigo linha de base do AKS também se aplicam aqui.

Gerenciamento de custos

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

• Os custos de licenciamento do Windows Server aumentam o custo de nós para o cluster do AKS. As recomendações de otimização de custo 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 Benefício Híbrido do Azure para Windows Server (AHUB) para saber mais sobre descontos para suas licenças do Windows Server aplicáveis ao 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 de 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 que extraem do ACR e dos requisitos de replicação geográfica.

Colaboradores

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

Autores principais:

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

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

Próximas etapas

• Saiba mais sobre contêineres do Windows

Recursos relacionados

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