Revisão do Azure Well-Architected Framework – SERVIÇO DE KUBERNETES DO AZURE (AKS)

  • Artigo

Este artigo fornece práticas recomendadas de arquitetura para Serviço de Kubernetes do Azure (AKS). A orientação baseia-se nos cinco pilares da excelência em arquitetura:

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

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

Pré-requisitos

Entender 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 do Azure Well-Architected Framework Review .

Para o contexto, 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 implementação de referência para preparar assinaturas de zona de destino para um cluster do AKS (Serviço de Kubernetes do Azure escalonável).

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 Serviço de Kubernetes do Azure, é importante distinguir entre confiabilidade do cluster e 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, são feitas chamadas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura da carga de trabalho ou a ambos.

Lista de verificação de projeto

  • Arquitetura de cluster: Para cargas de trabalho críticas, use zonas de disponibilidade para seus clusters do AKS.
  • Arquitetura de cluster: Planeje o espaço de endereço IP para garantir que o 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: Habilite os insights do contêiner para monitorar o cluster e configurar alertas para eventos que afetam a confiabilidade.
  • Arquitetura da carga de trabalho: Verifique se as cargas de trabalho foram 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 de usuário e escolha o SKU de 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: Controlar o agendamento de pods 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 consumam, 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 as 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: Configurar o monitoramento do cluster com insights de contêiner. Os insights de contêiner ajudam a monitorar a integridade e o desempenho de controladores, nós e contêineres disponíveis no Kubernetes por meio da API de Métricas. A integração com o Prometheus permite a coleta de métricas de aplicativo e carga de trabalho.
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 entre 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 VMSS em uma única zona ou grupos de posicionamento por proximidade poderá ser usada para minimizar a latência do internode.
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 uma SKU de VM de pelo menos 2 vCPUs e 4 GB de memória, mas 4 vCPU 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 com otimização de CPU ou memória ou a capacidade de dimensionar para zero. Evite um grande número de pools de nós para reduzir a sobrecarga extra de gerenciamento.
Arquitetura de cluster: Use um gateway da NAT para clusters que executam cargas de trabalho que fazem muitas conexões de saída simultâneas. Para evitar problemas de confiabilidade com limitações de Azure Load Balancer com alto tráfego de saída simultâneo, nós um Gateway da 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

Serviço de Kubernetes do Azure oferece uma ampla variedade de Políticas internas do Azure que se aplicam ao recurso do Azure, como políticas típicas do Azure e, usando o complemento Azure Policy para Kubernetes, também dentro do cluster. Há várias políticas e as principais políticas relacionadas a esse pilar são resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para Kubernetes.

Arquitetura de cluster e carga de trabalho

Além das definições de Azure Policy internas, as políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento 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 Serviço de Kubernetes do Azure precisar ser projetado para executar uma carga de trabalho confidencial que atenda aos requisitos regulatórios do Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 3.2.1), examine o cluster regulamentado do AKS para PCI-DSS 3.2.1.

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

Ao discutir a segurança com Serviço de Kubernetes do Azure, é importante distinguir entre a segurança do cluster e a segurança da 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, são feitas chamadas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura da carga de trabalho ou a ambos.

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 Microsoft Entra ID 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 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 do 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 da carga de trabalho: Use um Firewall de Aplicativo Web para proteger o tráfego HTTP(S).
  • Arquitetura da carga de trabalho: Verifique se o pipeline de CI/CID está protegido com a 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 Microsoft Entra integração. Usar Microsoft Entra ID centraliza o componente de gerenciamento de identidades. 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 Microsoft Entra ID para Registro de Contêiner do Azure. O AKS e o Microsoft Entra ID permitem a autenticação com Registro de Contêiner do Azure sem o uso de imagePullSecrets segredos. Examine Autenticar com Registro de Contêiner do Azure de 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 do AKS privado. Por padrão, o tráfego de rede entre os pools de nós e o servidor de API percorre a 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 apenas na rede privada.
Arquitetura de cluster: Para clusters aks não privados, use intervalos de IP autorizados do servidor de API. Ao usar clusters públicos, você ainda pode limitar o tráfego que pode alcançar o servidor de API de clusters usando o recurso de intervalo de IP autorizado. Inclua fontes como os IPs públicos dos agentes de build de implantação, o gerenciamento de operações e o ponto de saída dos pools de nós (como Firewall do Azure).
Arquitetura de cluster: Proteja o servidor de API com Microsoft Entra RBAC. 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 ao Microsoft Entra ID para controlar o acesso ao servidor de API. Desabilite as contas locais para impor todo o acesso ao cluster usando identidades baseadas em Microsoft Entra ID.
Arquitetura de cluster: Use as políticas de rede do Azure ou o Calico. Proteja e controle o tráfego de rede entre pods em um cluster.
Arquitetura de cluster: Proteger clusters e pods com Azure Policy. Azure Policy pode ajudar a aplicar a imposição e as proteções em escala em seus clusters de maneira centralizada e consistente. Pode também controlar quais pods de funções são concedidos e se algo está em execução contra a política da empresa.
Arquitetura de cluster: Proteger o acesso 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 da 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 (Azure Firewall de Aplicativo Web) no Gateway de Aplicativo do Azure ou noAzure Front Door.
Arquitetura de cluster: Controlar 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 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 Key Vault do Azure. 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 em um subconjunto dos itens listados na seção de política abaixo, como clusters sem RBAC configurado, configuração de Microsoft Defender ausente, acesso irrestrito à rede ao Servidor de API. Da mesma forma, ele faz recomendações de carga de trabalho para alguns dos itens da iniciativa de segurança de pod. Examine as recomendações.

Definições de política

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 Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negação, mas também em uma variante Implantar Se Não Existir .

Há várias políticas e as principais políticas relacionadas a esse pilar são resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para Kubernetes.

Arquitetura de cluster

  • Microsoft Defender para políticas baseadas em nuvem
  • Modo de autenticação e políticas de configuração (Microsoft Entra ID, RBAC, desabilitar a 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 de pod de cluster do Kubernetes cargas de trabalho baseadas em Linux
  • Inclua políticas de capacidade de pod e contêiner, como AppArmor, sysctl, caps de segurança, SELinux, seccomp, contêineres privilegiados, credenciais de API de cluster de montagem automática
  • Políticas de montagem, drivers de volume e 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

Serviço de Kubernetes do Azure implantações geralmente também usam Registro de Contêiner do Azure para gráficos do Helm e imagens de contêiner. 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, as políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento 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, confira 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 Kubernetes do CIS.

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, são feitas chamadas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura da carga de trabalho ou a ambos.

Para otimização de custo do cluster, acesse a calculadora de preços do Azure e selecione Serviço de Kubernetes do Azure nos produtos disponíveis. Você pode testar diferentes planos de configuração e 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. Corresponder sua seleção às 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 certo é fundamental, pois afeta diretamente o custo da execução de aplicativos no AKS. Escolher uma instância de alto desempenho sem utilização adequada pode levar a gastos desperdiçados, enquanto escolher uma instância poderosa pode levar a problemas de desempenho e maior 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 do Arm. O AKS dá suporte à criação de nós de agente do Ubuntu ARM64, bem como a 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 Azure Spot Máquinas Virtuais. 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 pagos 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 por 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 isso não afete os usuários finais ou crie encargos de rede extras.
Arquitetura da carga de trabalho: Manter imagens pequenas e otimizadas. Simplificar suas imagens ajuda a reduzir os custos, pois novos nós precisam baixar essas imagens. Crie imagens de uma maneira que permita que o contêiner seja iniciado o mais rápido possível para ajudar a evitar falhas ou tempos limite de solicitação do usuário enquanto o aplicativo está sendo iniciado, potencialmente levando ao excesso de provisionamento.
Arquitetura de cluster: Habilite o Dimensionador Automático de Cluster para reduzir automaticamente o número de nós de agente em resposta ao excesso de capacidade do recurso. Reduzir verticalmente automaticamente o número de nós no cluster do AKS permite executar um cluster eficiente quando a demanda é baixa e escalar verticalmente quando a demanda retorna.
Arquitetura de cluster: Habilite o Provisionamento Automático de Nó para automatizar a seleção de SKU da VM. O Provisionamento Automático de Nós 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 da carga de trabalho: Use o Dimensionador Automático de Pod Horizontal. 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 de cluster.
Arquitetura da carga de trabalho: Use o Dimensionador Automático de Pod Vertical (versão prévia). Rightsize seus pods e defina dinamicamente solicitações e limites com base no uso histórico.
Arquitetura da carga de trabalho: Use o KEDA ( Dimensionamento Automático Controlado por Eventos do Kubernetes ). Dimensione com base no número de eventos que estão sendo processados. Escolha entre um catálogo rico de mais de 50 dimensionadores 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) geralmente é usada para ajudar as organizações a reduzir os custos de nuvem. É uma prática que envolve colaboração entre equipes de finanças, operações e engenharia para impulsionar o alinhamento nas metas de economia de custos e trazer transparência aos custos de 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 os custos de recursos.
Arquitetura de cluster: Configurar o monitoramento do cluster com insights de contêiner. A ajuda dos insights do contêiner fornece insights acionáveis sobre os recursos ociosos e não alocados dos clusters. Os insights do contêiner também dão suporte à coleta de métricas do Prometheus e se integram ao Espaço Gerenciado do Azure para grafana para obter uma visão holística do aplicativo e da infraestrutura.
Arquitetura de cluster: Configure o complemento análise de custo do AKS. A extensão de cluster de análise de custo 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 em 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 Azure Policy para Kubernetes. Isso permite que você adicione restrições adicionais de otimização de custo que gostaria de impor em sua arquitetura de cluster e carga de trabalho.

Eficiência de 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, da redução das emissões de carbono e da 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. Não só você pode medir estatísticas de desempenho, mas também usar métricas para solucionar problemas e corrigir problemas rapidamente. Recomendamos que você examine 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 Serviço de Kubernetes do Azure, é importante distinguir entre a excelência operacional do cluster e a 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, são feitas chamadas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura da carga de trabalho ou a ambos.

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 é executado usando o GitOps.
  • Arquitetura da carga de trabalho: Use processos de implantação repetíveis e automatizados para sua carga de trabalho no ciclo de vida de desenvolvimento de software.
  • Arquitetura de cluster: Habilite diagnóstico configurações para garantir que as interações do plano de controle ou do servidor de API principal sejam registradas.
  • Arquiteturas de cluster e carga de trabalho: Habilite os insights do contêiner para coletar métricas, logs e diagnóstico para monitorar a disponibilidade e o desempenho do cluster e das cargas de trabalho em execução nele.
  • Arquitetura da carga de trabalho: A carga de trabalho deve ser projetada para emitir telemetria que pode ser coletada, o que também deve incluir linhas de vida e status de 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 aplicativo ou plataforma.
  • Arquitetura da 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: Impor 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 para entender e implementar. 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: Configurar o monitoramento do cluster com insights de contêiner. Os insights de contêiner ajudam a monitorar o desempenho dos contêineres coletando métricas de memória e processador de controladores, nós e contêineres que estão disponíveis no Kubernetes por meio da API de Métricas e dos logs de contêiner.
Arquitetura da carga de trabalho: Monitorar o desempenho do aplicativo com o Azure Monitor. Configure o Application Insights para monitoramento baseado em código de aplicativos em execução em um cluster do AKS.
Arquitetura da carga de trabalho: Configure a extração de métricas do Prometheus com insights de contêiner. Os insights de contêiner, que fazem parte do Azure Monitor, fornecem uma experiência de integração perfeita para coletar métricas do Prometheus. Referência Configure a extração de métricas do Prometheus para obter mais informações.
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 Azure Policy. Azure Policy pode ajudar a aplicar a imposição e as proteções em escala em seus clusters de maneira centralizada e consistente. Pode também controlar quais pods de funções são concedidos e se algo está em execução contra a política da empresa.
Arquitetura da carga de trabalho: Use as funcionalidades da plataforma em seu processo de engenharia de versão. O Kubernetes e os controladores de entrada dão suporte a muitos padrões de implantação avançados para inclusão em seu processo de engenharia de versão. 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 azuis/verdes no nível do selo. Automatize suas áreas de design críticas, incluindo implantação e teste.

Para obter 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, tais 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 relação ao uso do namespace padrão.

Definições de política

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 Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negação, mas também em uma variante Implantar Se Não Existir .

Há várias políticas e as principais políticas relacionadas a esse pilar são resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para Kubernetes.

Arquitetura de cluster

  • Azure Policy complemento 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, as políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento 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 sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Recomendamos que você examine os princípios de eficiência de desempenho.

Ao discutir o desempenho com 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, são feitas chamadas para indicar se cada opção é aplicável à arquitetura de cluster, à arquitetura da carga de trabalho ou a ambos.

Lista de verificação de projeto

À medida que você faz escolhas de design para 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 de teste de carga contínuas que exerçam o dimensionador automático de pod e cluster.
  • Arquiteturas de cluster e carga de trabalho: Separe as cargas de trabalho em pools de nós diferentes, permitindo escala independente.

Recomendações

Explore a tabela de recomendações a seguir para otimizar sua configuração de 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 do cluster: Habilite o dimensionador automático de cluster para ajustar automaticamente o número de nós de agente em resposta às restrições de recurso. 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 cargas de trabalho em pools de nós diferentes e considere dimensionar pools de nós de 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 de usuário permitem escalar ou reduzir verticalmente.
Arquitetura da carga de trabalho: Use recursos avançados do agendador do AKS. Ajuda a controlar o balanceamento de recursos para cargas de trabalho que exigem eles.
Arquitetura da 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 até mesmo externos. Use KEDA para criar um conjunto de regras de dimensionamento automático significativo com base em sinais específicos da carga de trabalho.

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

Definições de política

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 Azure Policy para Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negação, mas também em uma variante Deploy If Not Exists .

Há várias políticas e as principais políticas relacionadas a esse pilar são resumidas aqui. Para obter uma exibição mais detalhada, consulte definições de política internas para Kubernetes.

Arquitetura de cluster e carga de trabalho

  • Limites de recursos de CPU e memória

Além das políticas internas, as políticas personalizadas podem ser criadas para o recurso do AKS e para o complemento 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