Compartilhar via

Revisão do Azure Well-Architected Framework – Serviço de Kubernetes do Azure (AKS)

  • Artigo

Este artigo fornece as melhores práticas de arquitetura para o AKS (Serviço de Kubernetes do Azure). A orientação é baseada nos cinco pilares da excelência da arquitetura:

  • Confiabilidade
  • Segurança
  • Otimização de custos
  • Excelência operacional
  • Eficiência de desempenho

Presumimos que você entenda os princípios de design do sistema, tenha conhecimento prático do Serviço de Kubernetes do Azure e seja bem versado em seus recursos. Para obter mais informações, confira Serviço de Kubernetes do Azure.

Pré-requisitos

Compreender os pilares do Well-Architected Framework pode ajudar a produzir uma arquitetura de nuvem de alta qualidade, estável e eficiente. Recomendamos que você examine sua carga de trabalho usando a avaliação de Revisão do Azure Well-Architected Framework.

Para contextualizar, considere revisar uma arquitetura de referência que reflita essas considerações em seu design. Recomendamos que você comece com a arquitetura de linha de base para um cluster do AKS (Serviço de Kubernetes do Azure) e a arquitetura de microsserviços no Serviço de Kubernetes do Azure. Examine também o acelerador de zona de destino do AKS, que fornece uma abordagem arquitetônica e uma implementação de referência para preparar assinaturas de zona de destino para um cluster escalonável do AKS (Serviço de Kubernetes do Azure).

Confiabilidade

Na nuvem, reconhecemos antecipadamente que as falhas ocorrerão. Em vez de tentar evitar completamente a falha, a meta é minimizar os efeitos de uma falha em um componente individual. Use as informações a seguir para minimizar instâncias com falha.

Ao discutir a confiabilidade com o Serviço de Kubernetes do Azure, é importante distinguir entre a confiabilidade do cluster e a confiabilidade da carga de trabalho. A confiabilidade do cluster é uma responsabilidade compartilhada entre o administrador do cluster e seu provedor de recursos, enquanto a confiabilidade da carga de trabalho é o domínio de um desenvolvedor. Serviço de Kubernetes do Azure tem considerações e recomendações para ambas as funções.

Na lista de verificação de design e na lista de recomendações abaixo, os textos explicativos são feitos para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura de carga de trabalho ou a ambas.

Lista de verificação de projeto

  • Arquitetura de cluster: para cargas de trabalho críticas, use zonas de disponibilidade para os clusters do AKS.
  • Arquitetura de cluster: planeje o espaço de endereço IP para garantir que seu cluster possa ser dimensionado de forma confiável, incluindo o tratamento do tráfego de failover em topologias de vários clusters.
  • Arquitetura de cluster: examine as práticas recomendadas para monitorar o Kubernetes com o Azure Monitor para determinar a melhor estratégia de monitoramento para suas cargas de trabalho.
  • Arquitetura de carga de trabalho: certifique-se de que as cargas de trabalho sejam criadas para dar suporte ao dimensionamento horizontal e relatar a preparação e a integridade do aplicativo.
  • Arquiteturas de cluster e carga de trabalho: verifique se a carga de trabalho está em execução em pools de nós do usuário e escolha o SKU do tamanho certo. No mínimo, inclua dois nós para pools de nós de usuário e três nós para o pool de nós do sistema.
  • Arquitetura de cluster: use o SLA de Tempo de Atividade do AKS para atender às metas de disponibilidade para cargas de trabalho de produção.

Recomendações de configuração do AKS

Explore a tabela de recomendações a seguir para otimizar a configuração do AKS para confiabilidade.

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: controle o agendamento de pod usando seletores de nó e afinidade. Permite que o agendador do Kubernetes isole logicamente as cargas de trabalho por hardware no nó. Ao contrário das tolerâncias, os pods sem um seletor de nó correspondente podem ser agendados em nós rotulados, o que permite que recursos não utilizados nos nós sejam consumidos, mas dá prioridade aos pods que definem o seletor de nó correspondente. Use a afinidade do nó para obter mais flexibilidade, o que permite definir o que acontece se não for possível corresponder o pod a um nó.
Arquitetura de cluster: Garanta a seleção adequada do plug-in de rede com base nos requisitos de rede e no dimensionamento do cluster. A CNI do Azure é necessária para cenários específicos, por exemplo, pools de nós baseados em Windows, requisitos de rede específicos e Políticas de Rede do Kubernetes. Consulte Kubenet versus CNI do Azure para obter mais informações.
Arquiteturas de cluster e carga de trabalho: use o SLA de Tempo de Atividade do AKS para clusters de nível de produção. O SLA de Tempo de Atividade do AKS garante:
- 99.95% disponibilidade do ponto de extremidade do servidor de API do Kubernetes para Clusters do AKS que usam Zonas de Disponibilidade do Azure ou
- 99.9% disponibilidade para Clusters do AKS que não usam as Zonas de Disponibilidade do Azure.
Arquiteturas de cluster e carga de trabalho: examine as práticas recomendadas para monitorar o Kubernetes com o Azure Monitor para determinar a melhor estratégia de monitoramento para suas cargas de trabalho. N/D
Arquitetura de cluster: use zonas de disponibilidade para maximizar a resiliência em uma região do Azure distribuindo nós de agente do AKS em data centers fisicamente separados. Ao distribuir pools de nós em várias zonas, os nós em um pool de nós continuarão em execução mesmo que outra zona tenha ficado inativa. Se existirem requisitos de colocalidade, uma implantação regular do AKS baseada em Conjuntos de Dimensionamento de Máquinas Virtuais em uma única zona ou grupos de posicionamento por proximidade poderão ser usados para minimizar a latência do entrenó.
Arquitetura de cluster: adote uma estratégia de várias regiões implantando clusters do AKS implantados em diferentes regiões do Azure para maximizar a disponibilidade e fornecer continuidade dos negócios. As cargas de trabalho voltadas para a Internet devem aproveitar o Azure Front Door ou o Gerenciador de Tráfego do Azure para rotear o tráfego globalmente entre clusters do AKS.
Arquiteturas de cluster e carga de trabalho: defina solicitações e limites de recursos de pod em manifestos de implantação de aplicativo e imponha com Azure Policy. Os limites de recursos de CPU e memória do contêiner são necessários para evitar o esgotamento de recursos no cluster do Kubernetes.
Arquiteturas de cluster e carga de trabalho: mantenha o pool de nós do sistema isolado das cargas de trabalho do aplicativo. Os pools de nós do sistema exigem um SKU de VM de pelo menos 2 vCPUs e 4 GB de memória, mas 4 vCPUs ou mais são recomendados. Veja Pools de nós do sistema e do usuário para obter requisitos detalhados.
Arquiteturas de cluster e carga de trabalho: Separe aplicativos para pools de nós dedicados com base em requisitos específicos. Os aplicativos podem compartilhar a mesma configuração e precisar de VMs habilitadas para GPU, VMs otimizadas para CPU ou memória ou a capacidade de escalar para zero. Evite um grande número de pools de nós para reduzir a sobrecarga de gerenciamento extra.
Arquitetura de cluster: use um gateway NAT para clusters que executam cargas de trabalho que fazem muitas conexões de saída simultâneas. Para evitar problemas de confiabilidade com as limitações do Azure Load Balancer com alto tráfego de saída simultâneo, use um Gateway NAT para dar suporte ao tráfego de saída confiável em escala.

Para obter mais sugestões, consulte Princípios do pilar de confiabilidade.

Azure Policy

O Serviço de Kubernetes do Azure oferece uma ampla variedade de Políticas do Azure internas que se aplicam ao recurso do Azure, como Políticas típicas do Azure e, usando o complemento do Azure Policy para Kubernetes, também dentro do cluster. Existem inúmeras políticas importantes relacionadas a este pilar que estão resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para o Kubernetes.

Arquitetura de cluster e carga de trabalho

Além das definições internas do Azure Policy, políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento do Azure Policy para Kubernetes. Isso permite que você adicione restrições de confiabilidade adicionais que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Segurança

A Segurança é um dos aspectos mais importantes de qualquer arquitetura. Para explorar como o AKS pode reforçar a segurança da carga de trabalho do aplicativo, recomendamos que você examine os princípios de design de segurança. Se o cluster do Serviço de Kubernetes do Azure precisar ser projetado para executar uma carga de trabalho confidencial que atenda aos requisitos regulatórios do PCI-DSS 3.2.1 (Padrão de Segurança de Dados do Setor de Cartões de Pagamento), examine o cluster regulamentado pelo AKS para PCI-DSS 3.2.1.

Para saber mais sobre o suporte e os requisitos de IL5 (Nível de Impacto 5) do DoD com o AKS, examine os requisitos de isolamento de IL5 do Azure Governamental.

Ao discutir a segurança com o Serviço de Kubernetes do Azure, é importante distinguir entre segurança de cluster e segurança de carga de trabalho. A segurança do cluster é uma responsabilidade compartilhada entre o administrador do cluster e seu provedor de recursos, enquanto a segurança da carga de trabalho é o domínio de um desenvolvedor. Serviço de Kubernetes do Azure tem considerações e recomendações para ambas as funções.

Na lista de verificação de design e na lista de recomendações abaixo, as chamadas são feitas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura de carga de trabalho ou a ambas.

Lista de verificação de projeto

  • Arquitetura de cluster: use identidades gerenciadas para evitar o gerenciamento e a rotação de princípios de serviço.
  • Arquitetura de cluster: use o RBAC (controle de acesso baseado em função) do Kubernetes com a ID do Microsoft Entra para acesso com privilégios mínimos e minimize a concessão de privilégios de administrador para proteger a configuração e o acesso a segredos.
  • Arquitetura de cluster: use o Microsoft Defender para contêineres com o Azure Sentinel para detectar e responder rapidamente a ameaças em seu cluster e cargas de trabalho em execução neles.
  • Arquitetura de cluster: implante um cluster AKS privado para garantir que o tráfego de gerenciamento de cluster para o servidor de API permaneça em sua rede privada. Ou use a lista de permissões do servidor de API para clusters não privados.
  • Arquitetura de carga de trabalho: use um firewall de aplicativo Web para proteger o tráfego HTTP(S).
  • Arquitetura de carga de trabalho: verifique se o pipeline de CI/CID é protegido com verificação com reconhecimento de contêiner.

Recomendações

Explore a tabela de recomendações a seguir para otimizar a configuração do AKS para segurança.

Recomendação Benefício
Arquitetura de cluster: use a integração do Microsoft Entra. O uso do Microsoft Entra ID centraliza o componente de gerenciamento de identidade. Qualquer alteração na conta do usuário ou no status do grupo é atualizada automaticamente no acesso ao cluster do AKS. Os desenvolvedores e proprietários de aplicativos do cluster do Kubernetes precisam ter acesso a recursos diferentes.
Arquitetura de cluster: autentique com a ID do Microsoft Entra no Registro de Contêiner do Azure. O AKS e a ID do Microsoft Entra permitem a autenticação com o Registro de Contêiner do Azure sem o uso de imagePullSecrets segredos. Examine Autenticar com o Registro de Contêiner do Azure do Serviço de Kubernetes do Azure para obter mais informações.
Arquitetura de cluster: proteja o tráfego de rede para o servidor de API com o cluster AKS privado. Por padrão, o tráfego de rede entre os pools de nós e o servidor de API viaja pela rede de backbone da Microsoft; usando um cluster privado, você pode garantir que o tráfego de rede para o servidor de API permaneça somente na rede privada.
Arquitetura de cluster: para clusters do AKS não privados, use intervalos de IP autorizados pelo servidor de API. Ao usar clusters públicos, você ainda pode limitar o tráfego que pode chegar ao servidor de API de clusters usando o recurso de intervalo de IP autorizado. Inclua fontes como os IPs públicos de seus agentes de build de implantação, gerenciamento de operações e ponto de saída de pools de nós (como Firewall do Azure).
Arquitetura de cluster: proteja o servidor de API com o RBAC do Microsoft Entra. Proteger o acesso ao servidor de API do Kubernetes é uma das coisas mais importantes que você pode fazer para proteger seu cluster. Integre o RBAC (controle de acesso baseado em função) do Kubernetes com a ID do Microsoft Entra para controlar o acesso ao servidor de API. Desabilite contas locais para impor todo o acesso ao cluster usando identidades baseadas em ID do Microsoft Entra.
Arquitetura de cluster: use políticas de rede do Azure ou Calico. Proteja e controle o tráfego de rede entre pods em um cluster.
Arquitetura de cluster: proteja clusters e pods com o Azure Policy. O Azure Policy pode ajudar a aplicar imposições e proteções em escala em seus clusters de maneira centralizada e consistente. Ele também pode controlar quais pods de funções são concedidos e se algo está em execução em relação à política da empresa.
Arquitetura de cluster: acesso seguro de contêiner aos recursos. Limite o acesso às ações que podem ser executadas por contêineres. Forneça o menor número de permissões e evite o uso de escalonamento raiz ou privilegiado.
Arquitetura de carga de trabalho: use um firewall de aplicativo Web para proteger o tráfego HTTP(S). Para verificar o tráfego de entrada em busca de possíveis ataques, use um firewall de aplicativo Web, como o WAF (Firewall de Aplicativo Web) do Azure no Gateway de Aplicativo do Azure ou no Azure Front Door.
Arquitetura do cluster: controle o tráfego de saída do cluster. Verifique se o tráfego de saída do cluster está passando por um ponto de segurança de rede, como o Firewall do Azure ou um proxy HTTP.
Arquitetura de cluster: use a ID de carga de trabalho do Microsoft Entra de software livre e o driver CSI do repositório de segredos com o Azure Key Vault. Proteja e gire segredos, certificados e cadeias de conexão no Azure Key Vault com criptografia forte. Fornece um log de auditoria de acesso e mantém os segredos principais fora do pipeline de implantação.
Arquitetura de cluster: use Microsoft Defender para Contêineres. Monitore e mantenha a segurança de seus clusters, contêineres e seus aplicativos.

Para obter mais sugestões, consulte Princípios do pilar de segurança.

O Assistente do Azure ajuda a garantir e melhorar o serviço de Kubernetes do Azure. Ele faz recomendações sobre um subconjunto dos itens listados na seção de política abaixo, como clusters sem RBAC configurado, configuração ausente do Microsoft Defender, acesso irrestrito à rede para o Servidor de API. Da mesma forma, ele faz recomendações de carga de trabalho para alguns dos itens da iniciativa de segurança do pod. Revise as recomendações.

Definições de política

O Azure Policy oferece várias definições de política internas que se aplicam ao recurso do Azure e ao AKS, como definições de política padrão e usando o complemento do Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negar, mas também em uma variante Implantar Se Não Existir .

Existem inúmeras políticas importantes relacionadas a este pilar que estão resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para o Kubernetes.

Arquitetura de cluster

  • Microsoft Defender para políticas baseadas em nuvem
  • Modo de autenticação e políticas de configuração (ID do Microsoft Entra, RBAC, desabilitar autenticação local)
  • Políticas de acesso à rede do servidor de API, incluindo cluster privado

Arquitetura de cluster e carga de trabalho

  • Iniciativas de segurança do pod de cluster do Kubernetes Cargas de trabalho baseadas em Linux
  • Inclua políticas de capacidade de pod e contêiner, como AppArmor, sysctl, limites de segurança, SELinux, seccomp, contêineres privilegiados, credenciais de API de cluster de montagem automática
  • Mount, drivers de volume e políticas de sistema de arquivos
  • Políticas de rede de pod/contêiner, como rede de host, porta, IPs externos permitidos, HTTPs e balanceadores de carga internos

As implantações do Serviço de Kubernetes do Azure geralmente também usam o Registro de Contêiner do Azure para gráficos do Helm e imagens de contêiner. O Registro de Contêiner do Azure também dá suporte a uma ampla variedade de políticas do Azure que abrangem restrições de rede, controle de acesso e Microsoft Defender para Nuvem, que complementa uma arquitetura segura do AKS.

Além das políticas internas, políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento do Azure Policy para Kubernetes. Isso permite que você adicione restrições de segurança adicionais que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Para obter mais sugestões, consulte Conceitos de segurança do AKS e avalie nossas recomendações de proteção de segurança com base no parâmetro de comparação do CIS Kubernetes.

Otimização de custo

Otimizar custos é entender as diferentes opções de configuração e as práticas recomendadas para reduzir despesas desnecessárias e melhorar a eficiência operacional. Antes de seguir as diretrizes deste artigo, recomendamos que você examine os seguintes recursos:

Ao discutir a otimização de custos no Serviço de Kubernetes do Azure, é importante distinguir entre o custo dos recursos de cluster e o custo dos recursos de carga de trabalho. Os recursos de cluster são uma responsabilidade compartilhada entre o administrador do cluster e seu provedor de recursos, enquanto os recursos de carga de trabalho são o domínio de um desenvolvedor. Serviço de Kubernetes do Azure tem considerações e recomendações para ambas as funções.

Na lista de verificação de design e na lista de recomendações, as chamadas são feitas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura de carga de trabalho ou a ambas.

Para otimização de custo de cluster, acesse a calculadora de preços do Azure e selecione Serviço de Kubernetes do Azure entre os produtos disponíveis. Você pode testar diferentes configurações e planos de pagamento na calculadora.

Lista de verificação de projeto

  • Arquitetura do cluster: use a SKU de VM apropriada por pool de nós e instâncias reservadas em que a capacidade de longo prazo é esperada.
  • Arquiteturas de cluster e carga de trabalho: use a camada e o tamanho do disco gerenciado apropriados.
  • Arquitetura do cluster: examine as métricas de desempenho, começando com CPU, memória, armazenamento e rede, para identificar oportunidades de otimização de custos por cluster, nós e namespace.
  • Arquitetura de cluster e carga de trabalho: use dimensionadores automáticos para reduzir horizontalmente quando as cargas de trabalho estiverem menos ativas.

Recomendações

Confira a tabela de recomendações a seguir para otimizar a configuração do AKS para segurança do serviço.

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: alinhe a seleção de SKU e o tamanho do disco gerenciado com os requisitos de carga de trabalho. Combinar sua seleção com suas demandas de carga de trabalho garante que você não pague por recursos desnecessários.
Arquitetura de cluster: selecione o tipo de instância de máquina virtual correto. Selecionar o tipo de instância de máquina virtual correto é fundamental, pois afeta diretamente o custo de execução de aplicativos no AKS. A escolha de uma instância de alta performance sem a utilização adequada pode levar a gastos desnecessários, enquanto a escolha de uma instância menos potente pode levar a problemas de performance e aumento do tempo de inatividade. Para determinar o tipo de instância de máquina virtual correto, considere as características da carga de trabalho, os requisitos de recursos e as necessidades de disponibilidade.
Arquitetura de cluster: selecione máquinas virtuais com base na arquitetura Arm. O AKS dá suporte à criação de nós de agente do Ubuntu Arm64, bem como a uma combinação de nós de arquitetura Intel e ARM em um cluster que pode trazer melhor desempenho a um custo menor.
Arquitetura de cluster: selecione Máquinas Virtuais Spot do Azure. As VMs spot permitem que você aproveite a capacidade não utilizada do Azure com descontos significativos (até 90% em comparação com os preços de pagamento conforme o uso). Se o Azure precisar de capacidade de volta, a infraestrutura do Azure removerá os nós Spot.
Arquitetura de cluster: selecione a região apropriada. Devido a muitos fatores, o custo dos recursos varia de acordo com a região no Azure. Avalie os requisitos de custo, latência e conformidade para garantir que você esteja executando sua carga de trabalho de maneira econômica e que ela não afete seus usuários finais nem crie cobranças extras de rede.
Arquitetura de carga de trabalho: mantenha imagens pequenas e otimizadas. Simplificar suas imagens ajuda a reduzir custos, pois novos nós precisam baixar essas imagens. Crie imagens de uma forma que permita que o contêiner seja iniciado o mais rápido possível para ajudar a evitar falhas de solicitação do usuário ou tempos limite enquanto o aplicativo está sendo inicializado, potencialmente levando ao superprovisionamento.
Arquitetura de cluster: habilite o Dimensionador Automático de Cluster para reduzir automaticamente o número de nós do agente em resposta ao excesso de capacidade de recursos. Reduzir verticalmente automaticamente o número de nós no cluster do AKS permite que você execute um cluster eficiente quando a demanda é baixa e escale verticalmente quando a demanda retornar.
Arquitetura de cluster: habilite o provisionamento automático de nó para automatizar a seleção de SKU de VM. O Node Autoprovision simplifica o processo de seleção de SKU e decide, com base nos requisitos de recursos de pod pendentes, a configuração ideal da VM para executar cargas de trabalho da maneira mais eficiente e econômica.
Arquitetura de carga de trabalho: use o Horizontal Pod Autoscaler. Ajuste o número de pods em uma implantação dependendo da utilização da CPU ou de outras métricas selecionadas, que dão suporte a operações de redução horizontal do cluster.
Arquitetura de carga de trabalho: use o Vertical Pod Autoscaler (versão prévia). Dimensione corretamente seus pods e defina dinamicamente solicitações e limites com base no uso histórico.
Arquitetura de carga de trabalho: use o Kubernetes Event Driven Autoscaling (KEDA). Dimensione com base no número de eventos que estão sendo processados. Escolha entre um rico catálogo de 50+ scalers KEDA.
Arquiteturas de cluster e carga de trabalho: adote uma disciplina financeira de nuvem e uma prática cultural para impulsionar a propriedade do uso da nuvem. A base para habilitar a otimização de custos é a disseminação de um cluster de economia de custos. Uma abordagem de operações financeiras (FinOps) é frequentemente usada para ajudar as organizações a reduzir os custos da nuvem. É uma prática que envolve a colaboração entre as equipes de finanças, operações e engenharia para impulsionar o alinhamento das metas de economia de custos e trazer transparência aos custos da nuvem.
Arquitetura de cluster: inscreva-se nas Reservas do Azure ou no Plano de Economia do Azure. Se você planejou corretamente a capacidade, sua carga de trabalho é previsível e existe por um longo período de tempo, inscreva-se em uma Reserva do Azure ou em um plano de economia para reduzir ainda mais seus custos de recursos.
Arquitetura de cluster: examine as práticas recomendadas para monitorar o Kubernetes com o Azure Monitor para determinar a melhor estratégia de monitoramento para suas cargas de trabalho. N/D
Arquitetura de cluster: configure o complemento Análise de Custos do AKS. A extensão de cluster de análise de custos permite que você obtenha insights granulares sobre os custos associados a vários recursos do Kubernetes em seus clusters ou namespaces.

Para obter mais sugestões, consulte Princípios do pilar de otimização de custos e Otimizar custos no Serviço de Kubernetes do Azure.

Definições de política

Embora não haja políticas internas relacionadas à otimização de custos, políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento do Azure Policy para o Kubernetes. Isso permite que você adicione restrições adicionais de otimização de custos que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Eficiência da nuvem

Tornar as cargas de trabalho mais sustentáveis e eficientes na nuvem requer a combinação de esforços em torno da otimização de custos, redução das emissões de carbono e otimização do consumo de energia. Otimizar o custo do aplicativo é a etapa inicial para tornar as cargas de trabalho mais sustentáveis.

Saiba como criar cargas de trabalho do AKS sustentáveis e eficientes, em Princípios de engenharia de software sustentável no AKS (Serviço de Kubernetes do Azure).

Excelência operacional

Monitoramento e diagnóstico são cruciais. Você não apenas pode medir estatísticas de desempenho, mas também usar métricas, solucionar problemas e corrigir problemas rapidamente. Recomendamos que você revise os Princípios de design de excelência operacional e o guia de operações do Dia 2.

Ao discutir a excelência operacional com o Serviço de Kubernetes do Azure, é importante distinguir entre excelência operacional do cluster e excelência operacional da carga de trabalho. As operações de cluster são uma responsabilidade compartilhada entre o administrador do cluster e seu provedor de recursos, enquanto as operações de carga de trabalho são o domínio de um desenvolvedor. Serviço de Kubernetes do Azure tem considerações e recomendações para ambas as funções.

Na lista de verificação de design e na lista de recomendações abaixo, as chamadas são feitas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura de carga de trabalho ou a ambas.

Lista de verificação de projeto

  • Arquitetura de cluster: use uma implantação baseada em modelo usando Bicep, Terraform ou outros. Verifique se todas as implantações são repetíveis, rastreáveis e armazenadas em um repositório de código-fonte.
  • Arquitetura de cluster: crie um processo automatizado para garantir que seus clusters sejam inicializados com as configurações e implantações necessárias em todo o cluster. Isso geralmente é feito usando o GitOps.
  • Arquitetura de carga de trabalho: use processos de implantação repetíveis e automatizados para sua carga de trabalho dentro do ciclo de vida de desenvolvimento de software.
  • Arquitetura de cluster: habilite as configurações de diagnóstico para garantir que as interações do painel de controle ou do servidor de API principal sejam registradas.
  • Arquiteturas de cluster e carga de trabalho: examine as práticas recomendadas para monitorar o Kubernetes com o Azure Monitor para determinar a melhor estratégia de monitoramento para suas cargas de trabalho.
  • Arquitetura de carga de trabalho: a carga de trabalho deve ser projetada para emitir telemetria que pode ser coletada, que também deve incluir status de atividade e preparação.
  • Arquiteturas de cluster e carga de trabalho: use práticas de engenharia de caos direcionadas ao Kubernetes para identificar problemas de confiabilidade de aplicativos ou plataformas.
  • Arquitetura de carga de trabalho: otimize sua carga de trabalho para operar e implantar com eficiência em um contêiner.
  • Arquiteturas de cluster e carga de trabalho: imponha a governança de cluster e carga de trabalho usando Azure Policy.

Recomendações

Explore a tabela de recomendações a seguir para otimizar a configuração do AKS para operações.

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: examine a documentação de práticas recomendadas do AKS. Para criar e executar aplicativos com êxito no AKS, há considerações importantes a serem entendidas e implementadas. Essas áreas incluem a multilocação e recursos do agendador, cluster e segurança do pod, ou continuidade dos negócios e recuperação de desastres.
Arquiteturas de cluster e carga de trabalho: examine o Azure Chaos Studio. O Azure Chaos Studio pode ajudar a simular falhas e disparar situações de recuperação de desastre.
Arquiteturas de cluster e carga de trabalho: examine as práticas recomendadas para monitorar o Kubernetes com o Azure Monitor para determinar a melhor estratégia de monitoramento para suas cargas de trabalho. N/D
Arquitetura de cluster: adote uma estratégia de várias regiões implantando clusters do AKS implantados em diferentes regiões do Azure para maximizar a disponibilidade e fornecer continuidade dos negócios. As cargas de trabalho voltadas para a Internet devem aproveitar o Azure Front Door ou o Gerenciador de Tráfego do Azure para rotear o tráfego globalmente entre clusters do AKS.
Arquitetura de cluster: operacionalize os padrões de configuração de clusters e pods com o Azure Policy. O Azure Policy pode ajudar a aplicar imposições e proteções em escala em seus clusters de maneira centralizada e consistente. Ele também pode controlar quais pods de funções são concedidos e se algo está em execução em relação à política da empresa.
Arquitetura de carga de trabalho: use os recursos da plataforma em seu processo de engenharia de lançamento. O Kubernetes e os controladores de entrada oferecem suporte a muitos padrões avançados de implantação para inclusão em seu processo de engenharia de lançamento. Considere padrões como implantações azul-verde ou versões canário.
Arquiteturas de cluster e carga de trabalho: para cargas de trabalho críticas, use implantações azul/verde no nível do selo. Automatize suas áreas de projeto de missão crítica, incluindo implantação e teste.

Para mais sugestões, consulte Princípios do pilar de excelência operacional.

O Assistente do Azure também faz recomendações sobre um subconjunto dos itens listados na seção de política abaixo, como versões do AKS sem suporte e configurações de diagnóstico não configuradas. Da mesma forma, ele faz recomendações de carga de trabalho em torno do uso do namespace padrão.

Definições de política

O Azure Policy oferece várias definições de política internas que se aplicam ao recurso do Azure e ao AKS, como definições de política padrão e usando o complemento do Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negar, mas também em uma variante Implantar Se Não Existir .

Existem inúmeras políticas importantes relacionadas a este pilar que estão resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para o Kubernetes.

Arquitetura de cluster

  • Complemento do Azure Policy para Kubernetes
  • Políticas de configuração do GitOps
  • Políticas de configurações de diagnóstico
  • Restrições de versão do AKS
  • Impedir invocação de comando

Arquitetura de cluster e carga de trabalho

  • Restrições de implantação de namespace

Além das políticas internas, políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento do Azure Policy para Kubernetes. Isso permite que você adicione restrições de segurança adicionais que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Recomendamos que você revise os princípios de eficiência de desempenho.

Ao discutir o desempenho com o Serviço de Kubernetes do Azure, é importante distinguir entre o desempenho do cluster e o desempenho da carga de trabalho. O desempenho do cluster é uma responsabilidade compartilhada entre o administrador do cluster e seu provedor de recursos, enquanto o desempenho da carga de trabalho é o domínio de um desenvolvedor. Serviço de Kubernetes do Azure tem considerações e recomendações para ambas as funções.

Na lista de verificação de design e na lista de recomendações abaixo, as chamadas são feitas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura de carga de trabalho ou a ambas.

Lista de verificação de projeto

Ao fazer escolhas de design para o Serviço de Kubernetes do Azure, examine os princípios de eficiência de desempenho.

  • Arquiteturas de cluster e carga de trabalho: execute e itere em um exercício detalhado de plano de capacidade que inclui SKU, configurações de dimensionamento automático, endereçamento IP e considerações de failover.
  • Arquitetura de cluster: habilite o dimensionador automático de cluster para ajustar automaticamente o número de nós de agente em demandas de carga de trabalho de resposta.
  • Arquitetura de cluster: use o dimensionador automático de pod horizontal para ajustar o número de pods em uma implantação, dependendo da utilização da CPU ou de outras métricas selecionadas.
  • Arquiteturas de cluster e carga de trabalho: execute atividades contínuas de teste de carga que exercitam o dimensionador automático de pod e cluster.
  • Arquiteturas de cluster e carga de trabalho: Separe as cargas de trabalho em diferentes pools de nós, permitindo chamadas independentes.

Recomendações

Explore a tabela de recomendações a seguir para otimizar a configuração do Serviço de Kubernetes do Azure para desempenho.

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: desenvolva um plano de capacidade detalhado e revise e revise continuamente. Depois de formalizar seu plano de capacidade, ele deve ser atualizado com frequência, observando continuamente a utilização de recursos do cluster.
Arquitetura de cluster: habilite o dimensionador automático de cluster para ajustar automaticamente o número de nós do agente em resposta a restrições de recursos. A capacidade de escalar ou reduzir verticalmente o número de nós no cluster do AKS permite a execução de um cluster eficiente e econômico.
Arquiteturas de cluster e carga de trabalho: separe as cargas de trabalho em pools de nós diferentes e considere dimensionar pools de nós do usuário. Ao contrário dos pools de nós do sistema que sempre exigem nós em execução, os pools de nós do usuário permitem que você aumente ou diminua verticalmente.
Arquitetura de carga de trabalho: use os recursos avançados do agendador do AKS. Ajuda a controlar o balanceamento de recursos para cargas de trabalho que os exigem.
Arquitetura de carga de trabalho: use métricas significativas de dimensionamento de carga de trabalho. Nem todas as decisões de escala podem ser derivadas de métricas de CPU ou memória. Muitas vezes, as considerações de escala virão de pontos de dados mais complexos ou mesmo externos. Use o KEDA para criar um conjunto de regras de dimensionamento automático significativo com base em sinais específicos para sua carga de trabalho.

Para obter mais sugestões, consulte Princípios do pilar de eficiência de desempenho.

Definições de política

O Azure Policy oferece várias definições de política internas que se aplicam ao recurso do Azure e ao AKS, como definições de política padrão e usando o complemento do Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negar, mas também em uma variante Implantar Se Não Existir .

Existem inúmeras políticas importantes relacionadas a este pilar que estão resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para o Kubernetes.

Arquitetura de cluster e carga de trabalho

  • Limites de recursos de CPU e memória

Além das políticas internas, políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento do Azure Policy para Kubernetes. Isso permite que você adicione restrições de segurança adicionais que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Recursos adicionais

Diretrizes do Centro de Arquitetura do Azure

Diretrizes do Cloud Adoption Framework

Próximas etapas