Executando 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ções relativas à 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 da Linha de Base do AKS para 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 o código de implantação de exemplo.

Design de rede

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

• Os controladores de domínio do Ative Directory foram adicionados para suportar as cargas de trabalho baseadas no Windows.
• A solução de ingresso nessa arquitetura usa o Azure Front Door (AFD) e o proxy de aplicativo Microsoft Entra em vez do Azure App Gateway, que é usado na arquitetura AKS Baseline .

Design de ingresso

Componentes:

• Azure Front Door with WAF: 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, proporcionando o mais alto nível de segurança. O Web Application Firewall (WAF) protege contra vulnerabilidades e explorações 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 intervalos de IP não autorizados (o proxy do 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 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 de Kerberos para logon único (SSO) para seus aplicativos com Proxy de Aplicativo
• Balanceador de carga interno: Gerenciado pelo AKS. Este balanceador de carga expõe o controlador de entrada através 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 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.

Transfira um ficheiro do Visio desta arquitetura.

Topologia do pool de nós

Essa arquitetura usa três pools de nós: um pool de nós do sistema executando Linux, um pool de nós de usuário executando Linux e um pool de nós de usuário executando 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 para o 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 firewall de aplicativo Web (WAF) integrado e negocia o handshake TLS para bicycle.contoso.com, permitindo apenas cifras seguras. O Azure Front Door Gateway é um ponto de terminação TLS, pois é necessário para processar regras de inspeção WAF e executar regras de roteamento que encaminham o tráfego para o back-end configurado. O certificado TLS é armazenado no Cofre da Chave do Azure.
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-se 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 do aplicativo de back-end por meio do balanceador de carga AKS.

Fluxo de tráfego de saída

Todas as orientações encontradas no artigo AKS Baseline aplicam-se 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 do Firewall do Azure.

Planeamento de endereços IP

Ao contrário dos clusters AKS com pools de nós Linux, os clusters AKS com pools de nós do Windows requerem o Azure CNI. Usar o Azure CNI permite que um pod receba um endereço IP de uma Rede Virtual do Azure. O pod pode então se comunicar por meio da Rede Virtual do Azure como qualquer outro dispositivo. Ele pode se conectar a outros pods, a redes emparelhadas ou redes locais usando a Rota Expressa ou uma VPN, ou a outros serviços do Azure usando o Link Privado.

Todas as orientações relativas ao planejamento dos endereços IP fornecidas no artigo AKS Baseline architecture se aplicam aqui, com uma recomendação adicional: considere provisionar 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.

Atualização do pool de nós

O processo de atualização dos nós do Windows permanece inalterado em relação às orientações fornecidas na documentação de atualização da imagem do nó do Serviço 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 esta programação. Usar o GitHub Actions para criar um trabalho cron que é executado em uma programação permite que você programe programaticamente atualizações mensais. 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 programação 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 de nós de trabalho para obter orientações adicionais.

Considerações sobre computação

Os tamanhos de imagem maiores associados às imagens baseadas em servidor do Windows exigem a implantação de discos de sistema operacional de tamanho apropriado 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.

Gestão de identidades

Os contêineres do Windows não podem ser associados ao domínio, portanto, se você precisar de autenticação e autorização do Ative 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 autoscaler de cluster permanece inalterada para contêineres do Windows. Consulte a documentação do Cluster autoscaler para obter orientações.

A documentação do cluster de linha de base descreve as abordagens manuais e de dimensionamento 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 orientações 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 a conclusão das operações de dimensionamento 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 atenuar os atrasos na remoção da imagem durante os tempos de dimensionamento, você pode utilizar um DaemonSet para puxar a imagem do ACR para armazenar em cache em cada nó do Windows e, portanto, girar os pods com a imagem pré-carregada. A partir desse ponto, os pods precisariam apenas passar pelos processos de configuração do aplicativo definidos para sua carga de trabalho antes de serem colocados online.

Devem ser realizados exercícios de avaliação comparativa para compreender o impacto temporal da realização de operações de dimensionamento e estes dados devem ser ponderados em relação aos requisitos empresariais. 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 de "hot spare":

Primeiro, você precisará realizar testes de linha de base para identificar quantos pods precisará executar nos horários de pico de carregamento e fora do pico. 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 de dimensionamento manual para seu cluster e a definição do número inicial de nós para o número fora do pico de nós necessários. Quando você se aproxima de um período de tempo de pico, 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 as alterações no uso do aplicativo ou outros requisitos de negócios.

Monitorização

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 RSS de memória. Como resultado, ele 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 em 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.

Gestão de políticas

Todas as orientações de política encontradas no artigo de linha de base do AKS aplicam-se 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 do Windows do cluster Kubernetes não devem comprometer demais a CPU e a memória
• Os contêineres do Windows do cluster Kubernetes não devem ser executados como ContainerAdministrator
• Os contêineres do Windows do cluster Kubernetes só devem ser executados com usuário aprovado e grupo de usuários de domínio

Inicialização de cluster

Tal como acontece com as orientações de arranque de cluster fornecidas no artigo AKS Baseline (Linha de base AKS), os operadores de cluster também devem considerar a sua abordagem de arranque para cargas de trabalho baseadas no Windows. As mesmas orientações fornecidas no artigo AKS Baseline também se aplicam aqui.

Gestão de custos

Todas as diretrizes de otimização de custos encontradas no artigo AKS Baseline aplicam-se a cargas de trabalho do Windows. Outras considerações de custo que devem ser levadas em conta 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, caso você já as tenha para outros usos comerciais.
  • Consulte a documentação do Benefício Híbrido do Azure para Windows Server (AHUB) para saber mais sobre os 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 do Azure Container Registry (ACR) devido à quantidade de armazenamento necessária para várias imagens, ao número de nós simultâneos que são extraídos do ACR e aos requisitos de replicação geográfica.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

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

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

Próximos passos

• Saiba mais sobre os contêineres do Windows

Recursos relacionados

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