Compartilhar via

Arquitetura de linha de base do AKS (Serviço de Kubernetes do Azure) para AKS no Azure Local

AKS (Serviço de Kubernetes do Azure)
Azure Local
Azure Arc

Este cenário ilustra como projetar e implementar uma arquitetura de linha de base para o AKS (Serviço de Kubernetes do Microsoft Azure) executado no Azure Local.

Este artigo inclui recomendações para rede, segurança, identidade, gerenciamento e monitoramento do cluster com base nos requisitos de negócios de uma organização.

Importante

As informações neste artigo se aplicam ao AKS no Azure Local e no AKS no Windows Server. A versão mais recente do AKS é executada no Azure Stack HCI, sistema operacional versão 23H2. Para obter mais informações sobre a versão mais recente, consulte o AKS no Azure Local.

Arquitetura

Diagrama que mostra uma arquitetura de linha de base para o Serviço de Kubernetes do Azure no Azure Local.

Baixe um arquivo do Visio dessa arquitetura.

Componentes

  • Os seguintes componentes são instalados na borda ou local:

    • O Azure Local é uma solução de cluster HCI (infraestrutura hiperconvergente) que hospeda cargas de trabalho virtualizadas do Linux e do Windows e seu armazenamento em um ambiente local híbrido. Uma instância local do Azure consiste em um cluster que pode variar de 1 a 16 nós.

    • A ponte de recursos do Azure Arc é uma VM (máquina virtual) altamente disponível que é executada no Azure Local. A ponte de recursos é responsável por implantar e gerenciar vários clusters do AKS.

    • O AKS no Azure Local é uma implementação local do AKS que automatiza a execução de aplicativos em contêineres em escala. Um AKS no cluster local do Azure inclui nós de plano de controle altamente disponíveis e nós de trabalho. Aplicativos em contêineres são executados nos nós de trabalho no cluster do AKS. Para obter o isolamento do aplicativo, você pode implantar até 32 clusters do AKS. O cluster do AKS consiste nos seguintes componentes:

      • O plano de controle é executado no Azure Linux e inclui componentes de servidor de API que interagem com a API do Kubernetes. Ele também usa etcd, que é um repositório de chave-valor distribuído, para armazenar toda a configuração e os dados do cluster.

      • Os nós de trabalho são executados no sistema operacional Linux do Azure ou no sistema operacional Windows Server. Eles hospedam aplicativos em contêineres em pods. Os pods representam uma única instância do seu aplicativo e geralmente mapeiam um para um com um contêiner. No entanto, alguns pods incluem vários contêineres. As implantações consistem em um ou mais pods idênticos. Pods e implantações são agrupados logicamente em um namespace, que define o acesso ao gerenciamento desses recursos.

  • Os seguintes componentes são instalados no Azure:

    • O Azure Arc é um serviço baseado em nuvem que estende o modelo de gerenciamento baseado no Azure Resource Manager para recursos que não são do Azure, incluindo VMs não Azure, clusters kubernetes e bancos de dados em contêineres.

    • A Automação do Azure fornece um serviço de configuração e automação baseado em nuvem que dá suporte a gerenciamento consistente em seus ambientes do Azure e não do Azure.

    • O Azure Monitor é um serviço baseado em nuvem que maximiza a disponibilidade e o desempenho de seus aplicativos e serviços fornecendo uma solução abrangente para coletar, analisar e agir em relação a dados telemétricos de seus ambientes locais e de nuvem.

    • O Azure Policy é um serviço baseado em nuvem que ajuda a impor padrões organizacionais e avaliar a conformidade em escala avaliando o Azure, incluindo recursos habilitados pelo Azure Arc, para as propriedades desses recursos às regras de negócios. Esses padrões também incluem o Azure Policy para Kubernetes, que aplica políticas às cargas de trabalho executadas dentro do cluster.

    • O Microsoft Defender para Nuvem é um sistema unificado de gerenciamento de segurança de infraestrutura que fortalece a postura de segurança de seus datacenters e fornece proteção avançada contra ameaças em suas cargas de trabalho híbridas na nuvem e no local.

Detalhes do cenário

Possíveis casos de uso

  • Implemente cargas de trabalho baseadas em contêiner altamente disponíveis em uma implementação local do Kubernetes do AKS.

  • Automatize a execução de aplicativos conteinerizados em escala.

  • Menor custo total de propriedade (TCO) usando soluções certificadas pela Microsoft, automação baseada em nuvem, gerenciamento centralizado e monitoramento centralizado.

Hardware certificado

Use o hardware certificado local do Azure, que fornece configurações de Inicialização Segura, UEFI (Interface de Firmware Extensível Unida) e TPM (Trusted Platform Module). Os requisitos de computação dependem do aplicativo e do número total de nós de plano de controle e nós de trabalho em todos os clusters do AKS executados no Azure Local. Use vários nós físicos para implantação do Azure Local para obter alta disponibilidade. Todos os servidores devem ser do mesmo fabricante e modelo e usar processadores compatíveis com Intel nehalem de 64 bits, amd epyc ou posteriores compatíveis com a conversão de endereços de segundo nível.

Requisitos de rede

O Kubernetes fornece uma camada de abstração à rede conectando os nós do Kubernetes à rede de sobreposição virtual. Ele também fornece conectividade de entrada e saída para pods por meio do componente kube-proxy .

Essa arquitetura usa uma rede de sobreposição virtual que aloca endereços IP usando a rede de endereços IP estáticos. Essa arquitetura usa o Calico como o provedor de interface de rede de contêiner. A rede de endereços IP estáticos requer pools de endereços predefinidos para todos os objetos na implantação. Ele adiciona benefícios extras e garante que a carga de trabalho e o aplicativo estejam sempre acessíveis. Um pool de endereços IP separado é usado para alocar endereços IP aos serviços do Kubernetes.

As especificações de rede são definidas como redes lógicas no Azure Local. Antes de criar as redes lógicas no Azure Local, consulte os requisitos de rede e o planejamento de endereço IP.

Requisitos de armazenamento

Para cada servidor no cluster, use os mesmos tipos de unidades que são do mesmo tamanho e modelo. O Azure Local funciona com anexo de tecnologia avançada serial anexado direto, interface de sistema de computador pequena anexada em série, expressão de memória nãovolatile ou unidades de memória persistentes que são fisicamente anexadas a um servidor cada. Para volumes de cluster, o HCI usa tecnologia de armazenamento definida por software, como Espaços de Armazenamento Diretos, para combinar as unidades físicas no pool de armazenamento para tolerância a falhas, escalabilidade e desempenho. Os aplicativos executados no AKS no Azure Local geralmente esperam que as seguintes opções de armazenamento estejam disponíveis:

  • Os volumes representam uma maneira de armazenar, recuperar e persistir dados entre pods e durante o ciclo de vida do aplicativo.

  • Volumes persistentes são um recurso de armazenamento que a API do Kubernetes cria e gerencia. Eles podem existir além do tempo de vida de um pod individual.

Considere a definição de classes de armazenamento para diferentes níveis e locais para otimizar o custo e o desempenho. As classes de armazenamento oferecem suporte ao provisionamento dinâmico de volumes persistentes e definem a reclaimPolicy para especificar a ação do recurso de armazenamento subjacente para gerenciar volumes persistentes quando o pod é excluído.

Criar e gerenciar o AKS no Azure Local

Você deve criar e gerenciar o AKS no Azure Local, como qualquer outro recurso do Azure gerenciado. Você pode usar o portal do Azure, a CLI do Azure, os modelos do ARM (Azure Resource Manager) ou o Bicep.

O serviço kubernetes habilitado para Azure Arc fornece a representação do AKS do Resource Manager em uma instância local do Azure. Quando você cria um AKS no cluster local do Azure, os agentes do Azure Arc são implantados automaticamente em um namespace do Kubernetes para coletar logs e métricas e coletar metadados de cluster, versão do Kubernetes e contagem de nós.

As seguintes recomendações aplicam-se à maioria dos cenários. Siga as recomendações, a menos que você tenha um requisito específico que o substitua. Os seguintes serviços do Azure devem ser implantados na mesma região do Azure que o cluster do AKS:

  • Use a extensão MetalLB para implantar um balanceador de carga MetalLB no cluster do AKS para balanceamento de carga L2.

  • Habilite o Azure Monitor Container Insights para monitorar o desempenho de cargas de trabalho de contêiner que são executadas em pools de nós do Linux e do Windows. Ele coleta métricas de memória e processador de controladores, nós e contêineres por meio da API de Métrica. Usando o Container Insights, você pode identificar o uso de memória e processador, detectar o desempenho geral do cluster do Kubernetes, entender o comportamento do cluster e configurar alertas para monitoramento proativo.

  • Use os recursos de Automação disponíveis para gerenciamento de ponta a ponta. O AKS fornece uma ampla gama de recursos de automação, incluindo atualizações do sistema operacional e atualizações de pilha completa, como firmware e drivers de fornecedores e parceiros locais do Azure. Você pode executar o Windows PowerShell localmente em um dos computadores locais do Azure ou remotamente em um computador de gerenciamento. A integração com a Automação do Azure e o Azure Arc dá suporte a uma variedade de cenários de automação para cargas de trabalho virtualizadas e em contêineres .

  • Aplique governança com o Azure Policy para impor controles de recursos em escala. O Azure Policy estende o Gatekeeper v3, que é um webhook do controlador de admissão para o Open Policy Agent, para impor centralmente proteções em componentes do AKS, como pods, contêineres e namespaces.

  • Implante aplicativos consistentemente usando as configurações do Flux v2 e o Azure Policy para Kubernetes para obter implantações escalonáveis e controladas por políticas. Você pode selecionar uma definição de política interna e criar atribuições de política que tenham parâmetros específicos para a instalação do Flux. Para dar suporte à separação de preocupações, crie várias atribuições que tenham configurações diferentes do Flux que apontem para fontes separadas, como um repositório Git para administradores de cluster e outro repositório para equipes de aplicativos.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

  • Implemente de três a cinco nós de plano de controle e vários nós de trabalho no cluster kubernetes para atender aos requisitos mínimos de disponibilidade para aplicativos.

  • Examine os requisitos para clustering de failover. As implantações do AKS usam clustering de failover e a migração dinâmica para alta disponibilidade e tolerância a falhas. A migração ao vivo é um recurso Hyper-V que permite mover de forma transparente as VMs em execução de um host Hyper-V para outro sem tempo de inatividade percebido.

  • Configure implantações para usar recursos do Kubernetes, como implantações, mapeamento de afinidade e ReplicaSets, para garantir que os pods sejam resilientes em cenários de interrupção.

  • Limite o uso de imagens de contêiner público e extraia apenas dos registros de contêiner para os quais você tem controle sobre o contrato de nível de serviço, como o Registro de Contêiner do Azure.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Concentre-se em toda a pilha protegendo o host e seus contêineres.

Segurança da infraestrutura

  • Use o hardware certificado local do Azure que fornece configurações de Inicialização Segura, UEFI e TPM prontas para uso. Essas tecnologias, combinadas com a segurança baseada em virtualização, ajudam a proteger cargas de trabalho sensíveis à segurança. Para obter mais informações sobre soluções validadas, consulte soluções locais do Azure.

  • Use a Inicialização Segura para garantir que o servidor inicialize apenas o software em que um fabricante de equipamento original confia.

  • Use UEFI para controlar o processo de inicialização do servidor.

  • Use o TPM para armazenar chaves criptográficas e isolar todas as funções relacionadas à segurança baseadas em hardware.

  • Use a Criptografia de Unidade do BitLocker para criptografar volumes diretos de espaços de armazenamento em repouso.

  • Use o Defender para Nuvem para gerenciar as configurações de segurança para servidores e clusters. Ele fornece proteção contra ameaças para seus clusters do Kubernetes habilitados para Azure Arc. A extensão do Defender para Nuvem coleta dados de nós no cluster e os envia para o back-end do Azure Defender para Kubernetes na nuvem para análise posterior.

  • Use o RBAC (controle de acesso baseado em função) do Azure para atribuições de função e para gerenciar o acesso ao cluster do AKS.

  • Use a identidade da carga de trabalho para proteger e gerenciar identidades para acessar recursos do Azure de pods de carga de trabalho.

  • O AKS vem com a criptografia de segredos etcd usando um plug-in kms (serviço de gerenciamento de chaves). Todos os clusters do AKS têm um plug-in KMS interno habilitado por padrão. Esse plug-in gera a chave de criptografia e a gira automaticamente a cada 30 dias.

Segurança de aplicativo

  • Use a extensão do provedor de Segredos do Azure Key Vault em seu AKS na instância local do Azure para proteger ainda mais seus segredos que diferentes aplicativos usam armazenando-os no Key Vault.

  • Use o Azure Policy para Kubernetes para impor políticas de segurança de cluster, como nenhum pod privilegiado.

  • Use uma instância do Registro de Contêiner que contenha a verificação de vulnerabilidades em seu repositório de contêineres.

Segurança do contêiner

  • Proteja o ambiente de host e daemon removendo serviços desnecessários.

  • Mantenha os segredos fora das imagens e monte-os apenas através do mecanismo de orquestração de contêineres.

  • Proteja as imagens em uma instância do Registro de Contêiner que dá suporte à verificação de vulnerabilidades e ao RBAC do Azure.

  • Use o isolamento de contêineres e evite executar contêineres no modo privilegiado para impedir que invasores aumentem privilégios se um contêiner estiver comprometido.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Excelência operacional

A Excelência operacional abrange os processos de operações que implantam uma aplicação e as mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.

  • Infraestrutura como código: Use modelos do ARM, Bicep ou Terraform para automatizar a implantação de cluster em escala. Use o portal do Azure para explorar as opções disponíveis e compatíveis para a criação do cluster e exportar suas seleções como um modelo. Examine os módulos verificados do Azure para obter uma opção de implantação escalonável. Para obter mais informações, consulte o módulo de serviço de contêiner híbrido no GitHub.

  • Azure Arc: Integre-se ao Azure Arc ou aos serviços do Azure, como o Azure Monitor e o Log Analytics, que fornecem recursos extras de gerenciamento, manutenção e resiliência.

  • GitOps: Em vez de configurar manualmente os componentes do Kubernetes, use ferramentas automatizadas para aplicar configurações a um cluster do Kubernetes porque essas configurações são verificadas em um repositório de origem. Esse processo geralmente é conhecido como GitOps. As soluções comuns do GitOps para Kubernetes incluem Flux e Argo CD. Nesta arquitetura, recomendamos que você use a extensão GitOps fornecida pela Microsoft, que se baseia no Flux.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.

  • Use o hardware certificado local do Azure para melhorar o tempo de atividade e o desempenho do aplicativo, o gerenciamento e as operações simplificados e o TCO inferior.

  • Entenda os limites do AKS no Azure Local. A Microsoft dá suporte ao AKS em implantações locais do Azure que têm no máximo 16 servidores físicos por cluster, 32 clusters kubernetes e 200 VMs.

  • Determine o AKS nos requisitos locais do Azure com base no número de nós do plano de controle, nós de trabalho e clusters do AKS. Para dimensionar corretamente o hardware, preveja o número de pods, contêineres e nós de trabalho necessários para cada cluster do AKS. Reserve pelo menos 15% da capacidade local do Azure para acomodar falhas planejadas e não planejadas.

    Para obter eficiência de desempenho, use os recursos de computação de uma maneira que atenda aos requisitos do sistema, mantendo essa eficiência à medida que as mudanças de demanda e as tecnologias evoluem. Como regra geral, se um nó ficar offline, seja por causa da manutenção ou de uma falha inesperada, os nós restantes deverão ter capacidade suficiente para lidar com o aumento da carga.

  • Examine a lógica de posicionamento do nó do AKS. O AKS no Azure Local distribui os nós de trabalho para cada pool de nós em um cluster do AKS usando a lógica de posicionamento local do Azure por meio de conjuntos de disponibilidade.

  • Planeje reservas de endereço IP para configurar clusters do AKS e serviços do Kubernetes.

  • Implemente a otimização do desempenho da rede para alocação de largura de banda de tráfego.

  • Use a aceleração da unidade de processamento gráfico para cargas de trabalho extensas.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

Outro colaborador:

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

Próxima etapa