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

Considerações de design

O Serviço Kubernetes do Azure (AKS) fornece três modelos de rede diferentes para rede de contêiner: Kubenet, Sobreposição CNI 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 manual e a manutenção 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.

Azure CNI

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 onde 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 alcançar pods diretamente. As políticas de rede AKS também são suportadas com o Azure CNI.

Sobreposição do Azure CNI

A Sobreposição CNI do Azure foi projetada para resolver a escassez de endereços IP e simplificar a configuração da rede. É adequado para cenários em que o dimensionamento de 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 a Sobreposição CNI do Azure.

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ço IP e o tamanho da sub-rede de rede virtual para suportar o dimensionamento. Os nós virtuais podem ser usados para dimensionamento rápido de cluster, mas há algumas limitações conhecidas.

Os clusters AKS suportam SKUs do Balanceador de Carga do Azure Básico e Padrão, e os serviços podem ser expostos com balanceadores de carga públicos ou internos. O AKS usa 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 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 o AKS: políticas de rede do Azure e Calico.

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

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

Clusters privados

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

Seguindo práticas comprovadas em 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 o DNS do Azure (endereço 168.63.129.16IP) 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 de DNS exclusiva, uma vez que um GUID aleatório é precedido do 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 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 onde os servidores DNS centrais são implantados. A rede virtual AKS também foi configurada para usar os servidores DNS centrais na assinatura de conectividade, e o acesso do administrador à API do AKS Kubernetes seguirá este fluxo:

Nota

As imagens neste artigo refletem o design usando o modelo de conectividade hub e spoke tradicional. As zonas de aterrissagem em escala empresarial 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 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 de 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 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 ponto de extremidade privado da API do Kubernetes implantado na rede virtual AKS.

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

Os controladores de entrada (entrada) podem ser usados para expor aplicativos em execução nos clusters AKS.

• Os controladores de entrada fornecem roteamento no nível do aplicativo ao custo de um ligeiro aumento da complexidade.
• Os controladores de ingresso podem incorporar a funcionalidade WAF (Web Application Firewall).
• Os controladores de entrada podem ser executados fora do cluster 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 (Azure Application Gateway Ingress Controller).
  • Uma solução em cluster consome recursos de cluster AKS para computação (como roteamento de tráfego HTTP ou terminação TLS). Os controladores de entrada em cluster podem oferecer custos mais baixos, mas exigem planejamento e manutenção cuidadosos de recursos.
• O complemento básico de roteamento de aplicativos HTTP é fácil de usar, mas tem algumas restrições, conforme documentado no roteamento de aplicativos HTTP.

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

• A configuração deve ser alinhada com o design da filtragem de saída para evitar 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 tráfego da Internet.
• Se a terminação TLS for necessária, o gerenciamento de certificados TLS deve ser considerado.

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

O tráfego local segue o fluxo dos textos explicativos azuis 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 um gateway VPN ou ExpressRoute.
3. O roteamento na sub-rede do gateway é 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 AKS.

O Gateway de Aplicativo do Azure neste exemplo pode ser implantado na mesma assinatura que o cluster AKS, uma vez que sua configuração está intimamente relacionada às cargas de trabalho implantadas no AKS e, portanto, é gerenciada pela mesma equipe de aplicativos. O acesso a partir da 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.

Nota

Estes fluxos só são válidos para aplicações 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 estiver usando o modelo de conectividade da WAN Virtual.

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

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

Os pods executados dentro do cluster AKS podem precisar acessar serviços de back-end, como o Armazenamento do Azure, bancos 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 de 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 da 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 de pods AKS para serviços 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 um 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 endpoints 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 do hub (ou pelo hub virtual seguro se estiver usando a WAN Virtual), mesmo que o cluster AKS esteja 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 de design

• Se sua política de segurança exigir ter a API do Kubernetes com um endereço IP privado (em vez de um endereço IP público), implante um cluster 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.
  • Acompanhe a documentação sobre planejamento de endereços IP com a CNI.
  • Para usar pools de nós e nós virtuais do Windows Server para verificar eventuais limitações, consulte as Perguntas frequentes sobre suporte do Windows AKS.
• 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 geral da rede com a arquitetura de WAN Virtual ou hub and spoke do Azure, zonas DNS do Azure e sua própria infraestrutura DNS.
• Use o Private Link para proteger conexões de rede e use a conectividade privada baseada em IP para outros serviços gerenciados do Azure usados que dão suporte ao Private Link, como o Armazenamento do Azure, o Registro de Contêiner do Azure, o Banco de Dados SQL do Azure e o Cofre da Chave do Azure.
• Use um controlador de entrada para fornecer roteamento HTTP avançado e segurança 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 acesso por HTTP não criptografado. Essa política já será aplicada se a assinatura incluir as políticas recomendadas em Políticas incluídas implementações de referência de zonas de aterrissagem em 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 (Azure Application Gateway Ingress Controller), que é um serviço gerenciado primário do Azure.
  • Com a 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 suportada pelo Kubernetes.
• Para aplicativos Web voltados para a Internet e críticos para a segurança, use um firewall de aplicativo Web com o controlador de entrada.
  • O Azure Application Gateway 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 (NVA) de terceiros 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 suportada pela WAN Virtual do Azure ou pelo Servidor de Rotas do Azure.
• Para clusters não privados, use intervalos de IP autorizados.
• Use a camada Standard em vez da camada Basic 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 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 compreender 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.