Considerações sobre topologia de rede e conectividade para AKS

Considerações sobre o design

O Serviço de Kubernetes do Azure (AKS) fornece três modelos de rede diferentes para rede de contêiner: Kubenet, CNI Overlay e CNI. Cada um desses modelos tem seu conjunto exclusivo de recursos e vantagens, oferecendo opções de flexibilidade e escalabilidade para redes de contêineres no AKS.

Kubenet

Kubenet é uma solução de rede básica que conserva o espaço de endereço IP e oferece configuração simples. É ideal para pequenos clusters AKS com menos de 400 nós, onde o gerenciamento e a manutenção manuais de rotas definidas pelo usuário são aceitáveis. É adequado para cenários em que balanceadores de carga internos ou externos são suficientes para alcançar pods de fora do cluster.

CNI do Azure

O Azure CNI é um modelo de rede projetado para redes avançadas. Ele fornece conectividade de rede virtual completa para pods, permitindo conectividade pod-to-pod e pod-to-VM. É ideal para cenários em que recursos avançados do AKS, como nós virtuais, são necessários. É adequado para cenários em que há espaço de endereço IP suficiente disponível e recursos externos precisam acessar pods diretamente. As políticas de rede AKS também são suportadas com o Azure CNI.

Sobreposição de CNI do Azure

O Azure CNI Overlay foi projetado para resolver a escassez de endereços IP e simplificar a configuração de rede. É adequado para cenários em que escalar até 1000 nós e 250 pods por nó é suficiente, e um salto adicional para conectividade de pod é aceitável. Os requisitos de saída do AKS também podem ser atendidos com o Azure CNI Overlay.

Para obter um resumo dos casos de uso recomendados por modelo de rede, consulte Comparar modelos de rede no AKS.

Além disso, ao projetar seu cluster AKS, é importante planejar cuidadosamente o endereçamento IP e o tamanho da sub-rede de rede virtual para oferecer suporte ao dimensionamento. Nós virtuais podem ser usados para dimensionamento rápido de cluster, mas há algumas limitações conhecidas.

Os clusters AKS dão suporte a SKUs Básicos e Padrão do Azure Load Balancer, e os serviços podem ser expostos com balanceadores de carga públicos ou internos. O AKS usa o CoreDNS para fornecer resolução de nomes para pods em execução no cluster, e o tráfego de rede de saída (saída) pode ser enviado por meio de um Firewall do Azure ou cluster de dispositivo virtual de rede.

Por padrão, todos os pods em um cluster do AKS podem enviar e receber tráfego sem limitações. No entanto, as políticas de rede do Kubernetes podem ser usadas para melhorar a segurança e filtrar o tráfego de rede entre pods em um cluster AKS. Dois modelos de política de rede estão disponíveis para AKS: políticas de rede do Azure e Calico.

Finalmente, o AKS configura um NSG (grupo de segurança de rede) na sub-rede na qual o cluster é implantado. É recomendável não editar manualmente esse NSG, mas os serviços implantados no AKS podem influenciá-lo.

No geral, selecionar o modelo de rede apropriado e planejar cuidadosamente os recursos de rede pode ajudar a otimizar o desempenho, a segurança e o custo do cluster AKS.

Clusters privados

A visibilidade de IP do cluster do AKS pode ser pública ou privada. Os clusters privados expõem a API do Kubernetes em um endereço IP privado, mas não em um público. Esse endereço IP privado é representado na rede virtual do AKS por meio de um ponto de extremidade privado. A API do Kubernetes não deve ser acessada por meio de seu endereço IP, mas por meio de seu FQDN (nome de domínio totalmente qualificado). A resolução do FQDN da API do Kubernetes para seu endereço IP normalmente será executada por uma zona DNS privado do Azure. Essa zona DNS pode ser criada pelo Azure no grupo de recursos do nó do AKS ou você pode especificar uma zona DNS existente.

Seguindo práticas comprovadas de escala empresarial, a resolução DNS para cargas de trabalho do Azure é oferecida por servidores DNS centralizados implantados na assinatura de conectividade, seja em uma rede virtual de hub ou em uma rede virtual de serviços compartilhados conectada a uma WAN Virtual do Azure. Esses servidores resolverão condicionalmente nomes públicos e específicos do Azure usando DNS do Azure (endereço IP 168.63.129.16) e nomes privados usando servidores DNS corporativos. No entanto, esses servidores DNS centralizados não poderão resolver o FQDN da API do AKS até que estejam conectados à zona privada de DNS criada para o cluster AKS. Cada AKS tem uma zona privada DNS exclusiva, uma vez que um GUID aleatório é anexado ao nome da zona. Assim, para cada novo cluster AKS, sua zona DNS privada correspondente deve ser conectada à rede virtual onde os servidores DNS centrais estão localizados.

Todas as redes virtuais devem ser configuradas para usar esses servidores DNS centrais para resolução de nomes. No entanto, se a rede virtual AKS estiver configurada para usar os servidores DNS centrais e esses servidores DNS ainda não estiverem conectados à zona DNS privada, os nós AKS não poderão resolver o FQDN da API do Kubernetes e a criação do cluster AKS falhará. A rede virtual do AKS deve ser configurada para usar os servidores DNS centrais somente após a criação do cluster.

Depois que o cluster é criado, a conexão é criada entre a zona privada DNS e a rede virtual em que os servidores DNS centrais estão implantados. A rede virtual do AKS também foi configurada para usar os servidores DNS centrais na assinatura de conectividade, e o acesso de administrador à API AKS Kubernetes seguirá este fluxo:

Observação

As imagens neste artigo refletem o design usando o modelo de conectividade hub e spoke tradicional. As zonas de destino em escala corporativa podem optar pelo modelo de conectividade WAN Virtual, no qual os servidores DNS centrais estariam em uma rede virtual de serviços compartilhados conectada a um hub de WAN Virtual.

1. O administrador resolve o FQDN da API do Kubernetes. Os servidores DNS locais encaminham a solicitação para os servidores autoritativos: os resolvedores DNS no Azure. Esses servidores encaminham a solicitação para o servidor DNS do Azure (168.63.129.16), que obterá o endereço IP da zona DNS privado do Azure.
2. Depois de resolver o endereço IP, o tráfego para a API do Kubernetes é roteado do local para o gateway de VPN ou ExpressRoute no Azure, dependendo do modelo de conectividade.
3. O ponto de extremidade privado terá introduzido uma /32 rota na rede virtual do hub. Os gateways VPN e ExpressRoute enviam tráfego diretamente para o endpoint privado da API do Kubernetes implantado na rede virtual AKS.

Tráfego de usuários do aplicativo para o cluster

Controladores de entrada podem ser usados para expor aplicativos em execução nos clusters do AKS.

• Os controladores de entrada fornecem roteamento no nível do aplicativo às custas de um pequeno aumento de complexidade.
• Os controladores de entrada podem incorporar a funcionalidade WAF (Firewall de Aplicativo Web).
• Os controladores de entrada podem ser executados fora e no cluster:
  • Um controlador de entrada fora do cluster descarrega a computação (como roteamento de tráfego HTTP ou terminação TLS) para outro serviço fora do AKS, como o complemento AGIC (Controlador de entrada do Gateway de Aplicativo do Azure).
  • Uma solução no cluster consome recursos de cluster do AKS para computação (como roteamento de tráfego HTTP ou terminação TLS). Os controladores de entrada no cluster podem oferecer um custo menor, mas exigem planejamento e manutenção de recursos cuidadosos.
• O complemento básico de roteamento de aplicativo HTTP é fácil de usar, mas tem algumas restrições, conforme documentado no roteamento de aplicativos HTTP.

Os controladores de entrada podem expor aplicativos e APIs com um endereço IP público ou privado.

• A configuração deve ser alinhada com o design de filtragem de saída para evitar o roteamento assimétrico. UDRs podem causar roteamento assimétrico (potencialmente), mas não necessariamente. O Application Gateway pode SNAT no tráfego, o que significa que o tráfego de retorno volta para o nó do Application Gateway e não para a rota UDR se o UDR estiver configurado apenas para o tráfego da Internet.
• Se a terminação TLS for necessária, o gerenciamento de certificados TLS deverá ser considerado.

O tráfego do aplicativo pode vir do local ou da Internet pública. A figura a seguir descreve um exemplo em que um Gateway de Aplicativo do Azure é configurado para conexões de proxy reverso para os clusters tanto do local quanto da Internet pública.

O tráfego do local segue o fluxo dos textos explicativos numerados no diagrama anterior.

1. O cliente resolve o FQDN atribuído ao aplicativo, usando os servidores DNS implantados na assinatura de conectividade ou servidores DNS locais.
2. Depois de resolver o FQDN do aplicativo para um endereço IP (o endereço IP privado do gateway de aplicativo), o tráfego é roteado por meio de uma VPN ou gateway do ExpressRoute.
3. O roteamento na sub-rede do gateway está configurado para enviar a solicitação para o firewall do aplicativo Web.
4. O firewall do aplicativo Web envia solicitações válidas para a carga de trabalho em execução no cluster do AKS.

O Gateway de Aplicativo do Azure neste exemplo pode ser implantado na mesma assinatura que o cluster do AKS, pois sua configuração está intimamente relacionada às cargas de trabalho implantadas no AKS e, portanto, é gerenciada pela mesma equipe de aplicativos. O acesso pela Internet segue o fluxo dos textos explicativos verdes numerados no diagrama anterior.

1. Os clientes da Internet pública resolvem o nome DNS do aplicativo usando o Gerenciador de Tráfego do Azure. Como alternativa, outras tecnologias globais de balanceamento de carga, como o Azure Front Door podem ser usadas.
2. O FQDN público do aplicativo será resolvido pelo Gerenciador de Tráfego para o endereço IP público do gateway do aplicativo, que os clientes acessam pela Internet pública.
3. O gateway de aplicativo acessa a carga de trabalho implantada no AKS.

Observação

Esses fluxos só são válidos para aplicativos Web. Os aplicativos não Web estão fora do escopo deste artigo e podem ser expostos por meio do Firewall do Azure na rede virtual do hub ou do hub virtual seguro se usar o modelo de conectividade da WAN Virtual.

Como alternativa, os fluxos de tráfego para aplicativos baseados na Web podem ser feitos para percorrer o Firewall do Azure na assinatura de conectividade e o WAF na rede virtual do AKS. Essa abordagem tem a vantagem de oferecer um pouco mais de proteção, como o uso da filtragem baseada em inteligência do Firewall do Azure para descartar o tráfego de endereços IP maliciosos conhecidos na Internet. No entanto, ela também tem algumas desvantagens. Por exemplo, a perda do endereço IP do cliente original e a coordenação extra necessária entre o firewall e as equipes de aplicativo ao expor aplicativos. Isso porque as regras DNAT (conversão de endereços de rede de destino) serão necessárias no Firewall do Azure.

Tráfego dos pods do AKS para serviços de back-end

Os pods em execução dentro do cluster do AKS podem precisar acessar serviços de back-end, como o Armazenamento do Microsoft Azure, Banco de dados SQL do Azure ou bancos de dados NoSQL do Azure Cosmos DB. Os pontos de extremidade de serviço de rede virtual e o Link Privado podem ser usados para proteger a conectividade com esses serviços gerenciados do Azure.

Se você estiver usando pontos de extremidade privados do Azure para tráfego de back-end, a resolução DNS para os serviços do Azure poderá ser executada usando zonas DNS Privadas do Azure. Como os resolvedores de DNS para todo o ambiente estão na rede virtual do hub (ou na rede virtual de serviços compartilhados se estiver usando o modelo de conectividade WAN Virtual), essas zonas privadas devem ser criadas na assinatura de conectividade. Para criar o registro A necessário para resolver o FQDN do serviço privado, você pode associar a zona DNS privada (na assinatura de conectividade) ao ponto de extremidade privado (na assinatura do aplicativo). Esta operação requer certos privilégios nessas assinaturas.

É possível criar os registros A manualmente, mas associar a zona DNS privada ao ponto de extremidade privado resulta em uma configuração menos propensa a configurações incorretas.

A conectividade de back-end dos pods AKS para os serviços de PaaS do Azure expostos por meio de pontos de extremidade privados segue esta sequência:

1. Os pods AKS resolvem o FQDN da plataforma Azure como serviço (PaaS) usando os servidores DNS centrais na assinatura de conectividade, que são definidos como servidores DNS personalizados na rede virtual AKS.
2. O IP resolvido é o endereço IP privado dos pontos de extremidade privados, que são acessados diretamente dos pods AKS.

O tráfego entre os pods AKS e os pontos de extremidade privados por padrão não passará pelo Firewall do Azure na rede virtual de hub (ou no hub virtual seguro se estiver usando WAN Virtual), mesmo se o cluster AKS estiver configurado para filtragem de saída com o Firewall do Azure. O motivo é que o ponto de extremidade privado cria uma /32 rota nas sub-redes da rede virtual do aplicativo, onde o AKS é implantado.

Recomendações sobre design

• Se a sua política de segurança exigir que a API do Kubernetes tenha um endereço IP privado (em vez de um endereço IP público), implante um cluster do AKS privado.
  • Use zonas DNS privadas personalizadas ao criar um cluster privado, em vez de permitir que o processo de criação use uma zona DNS privada do sistema.
• Use a CNI (Interface de Rede de Contêiner do Azure) como um modelo de rede, a menos que você tenha um intervalo limitado de endereços IP que podem ser atribuídos ao cluster AKS.
  • Siga a documentação sobre o planejamento de endereços IP com CNI.
  • Para usar os pools de nós do servidor Windows e os nós virtuais para verificar as limitações eventuais, consulte as Perguntas frequentes sobre suporte do AKS do Windows.
• Use a Proteção contra DDoS do Azure para proteger a rede virtual usada para o cluster AKS, a menos que você use o Firewall do Azure ou o WAF em uma assinatura centralizada.
• Use a configuração de DNS vinculada à configuração de rede geral com a arquitetura da WAN Virtual do Azure ou hub e spoke do Azure, zonas DNS do Azure e sua própria infraestrutura de DNS.
• Use o Link Privado para proteger as conexões de rede e use a conectividade baseada em IP privado para outros serviços gerenciados do Azure usados que dão suporte ao Link Privado, como Armazenamento do Microsoft Azure, Registro de Contêiner do Azure, Banco de Dados SQL do Azure e Azure Key Vault.
• Use um controlador de entrada para fornecer segurança e roteamento HTTP avançados e para oferecer um único ponto de extremidade para aplicativos.
• Todos os aplicativos Web configurados para usar uma entrada devem usar criptografia TLS e não permitir o acesso por HTTP não criptografado. Essa política já será imposta se a assinatura incluir as políticas recomendadas em Políticas incluídas em implementações de referência de zonas de destino de escala empresarial.
• Opcionalmente, para conservar os recursos de computação e armazenamento do cluster AKS, use um controlador de entrada fora do cluster.
  • Use o complemento AGIC (Controlador de entrada do Gateway de Aplicativo do Azure), que é um serviço gerenciado do Azure.
  • Com o AGIC, implante um Gateway de Aplicativo do Azure dedicado para cada cluster AKS e não compartilhe o mesmo Gateway de Aplicativo em vários clusters AKS.
  • Se não houver restrições operacionais ou de recursos, ou se o AGIC não fornecer os recursos necessários, use uma solução de controlador de entrada no cluster como NGINX, Traefik ou qualquer outra solução compatível com o Kubernetes.
• Para aplicativos Web voltados para a Internet e críticos para a segurança, use um firewall do aplicativo Web com o controlador de entrada.
  • O Gateway de Aplicativo do Azure e o Azure Front Door integram o Firewall de Aplicativo Web do Azure para proteger aplicativos baseados na Web.
• Se a sua política de segurança exigir a inspeção de todo o tráfego de saída da Internet gerado no cluster AKS, proteja o tráfego de rede de saída usando o Firewall do Azure ou um dispositivo virtual de rede de terceiros (NVA) implantado na rede virtual do hub gerenciado. Para obter mais informações, consulte Limitar o tráfego de saída. O UDR do tipo de saída AKS requer a associação de uma tabela de rotas à sub-rede do nó AKS, portanto, não pode ser usado hoje com a injeção de rota dinâmica com suporte na WAN Virtual do Azure ou no Servidor de Rotas do Azure.
• Para clusters não privados, use intervalos de IP autorizados.
• Use a camada Standard em vez da camada básica do Azure Load Balancer.
• Ao projetar um cluster Kubernetes no Azure, uma das principais considerações é selecionar o modelo de rede apropriado para seus requisitos específicos. O Serviço de Kubernetes do Azure (AKS) oferece três modelos de rede diferentes: Kubenet, Azure CNI e Azure CNI Overlay. Para tomar uma decisão informada, é essencial entender as capacidades e características de cada modelo.

Para uma comparação de recursos entre os três modelos de rede no AKS; Kubenet, Azure CNI e Azure CNI Overlay, consulte Comparar modelos de rede no AKS.