Partilhar via

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

  • Artigo

Este artigo fornece práticas recomendadas de arquitetura para o Serviço Kubernetes do Azure (AKS). As orientações baseiam-se nos cinco pilares da excelência arquitetónica:

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

Supomos que você entenda os princípios de design do sistema, tenha conhecimento prático do Serviço Kubernetes do Azure e conheça bem seus recursos. Para obter mais informações, consulte Serviço 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ê revise sua carga de trabalho usando a avaliação do Azure Well-Architected Framework Review .

Para contextualizar, considere a revisão de 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 Serviço Kubernetes do Azure (AKS) e a arquitetura de Microsserviços no Serviço Kubernetes do Azure. Analise também o acelerador de zona de aterrissagem AKS, que fornece uma abordagem arquitetônica e implementação de referência para preparar assinaturas de zona de aterrissagem para um cluster escalável do Serviço Kubernetes do Azure (AKS).

Fiabilidade

Na nuvem, reconhecemos que falhas acontecem. Em vez de tentar evitar simplesmente as falhas, o objetivo é minimizar os efeitos da falha de um único componente. Use as informações a seguir para minimizar instâncias com falha.

Ao discutir a confiabilidade com o Serviço Kubernetes do Azure, é importante distinguir entre confiabilidade de cluster e confiabilidade de 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. O Serviço 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 ambas.

Lista de verificação de estruturação

  • Arquitetura de cluster: Para cargas de trabalho críticas, use zonas de disponibilidade para seus clusters 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 a manipulação do tráfego de failover em topologias de vários clusters.
  • Arquitetura de cluster: revise 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: garanta que as cargas de trabalho sejam criadas para dar suporte ao dimensionamento horizontal e relatar a prontidão e a integridade do aplicativo.
  • Arquiteturas de cluster e carga de trabalho: verifique se sua carga de trabalho está sendo executada em pools de nós de usuário e escolha a 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 sua configuração AKS para confiabilidade.

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: Controle o agendamento de pods usando seletores de nó e afinidade. Permite que o agendador do Kubernetes isole logicamente cargas de trabalho por hardware no nó. Ao contrário das tolerações, 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 o pod não puder ser correspondido 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 no Windows, requisitos de rede específicos e Políticas de Rede do Kubernetes. Consulte Kubenet versus Azure CNI 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 AKS Uptime garante:
- 99.95% disponibilidade do ponto de extremidade do servidor da API do Kubernetes para Clusters AKS que usam Zonas de Disponibilidade do Azure, ou
- 99.9% disponibilidade para Clusters AKS que não usam Zonas de Disponibilidade do Azure.
Arquiteturas de cluster e carga de trabalho: revise 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/A
Arquitetura de cluster: use zonas de disponibilidade para maximizar a resiliência em uma região do Azure distribuindo nós de agente AKS em data centers fisicamente separados. Ao espalhar pools de nós por várias zonas, os nós em um pool de nós continuarão em execução mesmo que outra zona tenha caído. Se existirem requisitos de colocalidade, uma implantação AKS regular baseada em VMSS em uma única zona ou grupos de posicionamento de proximidade podem ser usados para minimizar a latência internade.
Arquitetura de cluster: adote uma estratégia de várias regiões implantando clusters AKS implantados em diferentes regiões do Azure para maximizar a disponibilidade e fornecer continuidade de negócios. As cargas de trabalho voltadas para a Internet devem aproveitar o Azure Front Door ou o Azure Traffic Manager para rotear o tráfego globalmente em clusters AKS.
Arquiteturas de cluster e carga de trabalho: defina solicitações e limites de recursos do Pod em manifestos de implantação de aplicativos e aplique com a Política do Azure. 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. Sistema de referência e pools de nós de usuário para 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, CPU ou VMs otimizadas para memória ou a capacidade de dimensionar 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 Balanceador de Carga do Azure com alto tráfego de saída simultâneo, usamos um Gateway NAT para oferecer suporte ao tráfego de saída confiável em escala.

Para mais sugestões, consulte Princípios do pilar da fiabilidade.

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 as Políticas típicas do Azure, e, usando o complemento de Política do Azure para Kubernetes, também dentro do cluster. Há um grande número de políticas, e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma visão mais detalhada, consulte Definições de política internas para o Kubernetes.

Arquitetura de cluster e carga de trabalho

  • Os clusters têm sondas de integridade de prontidão ou vivacidade configuradas para sua especificação de pod.

Além das definições internas da Política do Azure, as políticas personalizadas podem ser criadas para o recurso AKS e para o complemento Política do Azure 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 aspetos mais importantes de qualquer arquitetura. Para explorar como o AKS pode reforçar a segurança da carga de trabalho do seu aplicativo, recomendamos que você revise os princípios de design de segurança. Se o cluster do Serviço 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), revise o cluster regulado pelo AKS para PCI-DSS 3.2.1.

Para saber mais sobre o suporte e os requisitos do DoD Impact Level 5 (IL5) com o AKS, consulte os requisitos de isolamento do Azure Government IL5.

Ao discutir a segurança com o Serviço 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. O Serviço 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 ambas.

Lista de verificação de estruturação

  • 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 obter 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 detetar 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 seu 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 Web Application Firewall para proteger o tráfego HTTP(S).
  • Arquitetura da carga de trabalho: certifique-se de que seu pipeline de CI/CID seja fortalecido com a verificação com reconhecimento de contêiner.

Recomendações

Explore a tabela de recomendações a seguir para otimizar sua 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 identidades. Qualquer alteração na conta de usuário ou status do grupo é automaticamente atualizada no acesso ao cluster AKS. Os desenvolvedores e proprietários de aplicativos do cluster Kubernetes precisam ter acesso a diferentes recursos.
Arquitetura de cluster: autentique-se com o Microsoft Entra ID no Registro de Contêiner do Azure. O AKS e o Microsoft Entra ID permitem a autenticação com o Registro de Contêiner do Azure sem o uso de imagePullSecrets segredos. Consulte Autenticar com o Registro de Contêiner do Azure do Serviço Kubernetes do Azure para obter mais informações.
Arquitetura de cluster: Proteja o tráfego de rede para o seu servidor de API com cluster 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 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 compilação de implantação, gerenciamento de operações e ponto de saída dos pools de nós (como o Firewall do Azure).
Arquitetura de cluster: Proteja o servidor de API com o Microsoft Entra RBAC. Proteger o acesso ao Kubernetes API Server é uma das coisas mais importantes que você pode fazer para proteger seu cluster. Integre o controle de acesso baseado em função (RBAC) do Kubernetes com o Microsoft Entra ID para controlar o acesso ao servidor de API. Desative as contas locais para impor todo o acesso ao cluster usando identidades baseadas em ID do Microsoft Entra.
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: proteja clusters e pods com a Política do Azure. A Política do Azure pode ajudar a aplicar a imposição e as salvaguardas em escala em seus clusters de maneira centralizada e consistente. Ele também pode controlar quais funções são concedidas e se algo está indo contra a política da empresa.
Arquitetura de cluster: Proteja o acesso do contêiner aos recursos. Limite o acesso a ações que os contêineres podem executar. 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 Web Application Firewall 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 Firewall de Aplicativo Web do Azure (WAF) no Gateway de Aplicativo do Azure ou na Porta da Frente do Azure.
Arquitetura de 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 código aberto 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 Cofre de Chaves do Azure com criptografia forte. Fornece um log de auditoria de acesso e mantém os principais segredos fora do pipeline de implantação.
Arquitetura de cluster: use o Microsoft Defender for Containers. Monitore e mantenha a segurança de seus clusters, contêineres e seus aplicativos.

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

O Azure Advisor ajuda a garantir e melhorar o serviço 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 ao 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. Reveja as recomendações.

Definições de política

A Política do Azure 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 de Política do Azure 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 .

Há um grande número de políticas, e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma visão mais detalhada, consulte Definições de política internas para o Kubernetes.

Arquitetura de cluster

  • Políticas baseadas no Microsoft Defender for Cloud
  • Modo de autenticação e políticas de configuração (Microsoft Entra ID, RBAC, desativar 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 pods de cluster do Kubernetes Cargas de trabalho baseadas em Linux
  • Inclua políticas de capacidade de pod e contêiner, como AppArmor, sysctl, security caps, 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

As implantações do Serviço Kubernetes do Azure geralmente também usam o Registro de Contêiner do Azure para gráficos de Helm e imagens de contêiner. O Registo de Contentores do Azure também suporta uma grande variedade de políticas do Azure que abrangem restrições de rede, controlo de acesso e o Microsoft Defender for Cloud, que complementa uma arquitetura AKS segura.

Além das políticas internas, políticas personalizadas podem ser criadas para o recurso AKS e para o complemento Política do Azure 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 os conceitos de segurança do AKS e avalie nossas recomendações de proteção de segurança com base no benchmark CIS Kubernetes.

Otimização de custos

A otimização de custos consiste em compreender 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 orientações deste artigo, recomendamos que você revise os seguintes recursos:

Ao discutir a otimização de custos com o Serviço Kubernetes do Azure, é importante distinguir entre o custo dos recursos do cluster e o custo dos recursos da 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. O Serviço 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 de carga de trabalho ou a ambas.

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

Lista de verificação de estruturação

  • Arquitetura de cluster: use SKU de VM apropriado por pool de nós e instâncias reservadas onde a capacidade de longo prazo é esperada.
  • Arquiteturas de cluster e carga de trabalho: use a camada e o tamanho do disco gerenciado apropriados.
  • Arquitetura de cluster: analise 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 dimensionar quando as cargas de trabalho estiverem menos ativas.

Recomendações

Explore a tabela de recomendações a seguir para otimizar sua configuração do AKS em termos de custo.

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. Adequar sua seleção às 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 alto desempenho sem a utilização adequada pode levar a gastos desnecessários, enquanto a escolha de uma instância menos poderosa pode levar a problemas de desempenho 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 suporta a criação de nós de agente ARM64 Ubuntu, bem como uma mistura de nós de arquitetura Intel e ARM dentro de um cluster que pode trazer melhor desempenho a um custo mais baixo.
Arquitetura de cluster: Selecione Máquinas Virtuais do Azure Spot. 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 pré-pagos). 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 forma econômica e que isso não afete seus usuários finais ou crie taxas de rede extras.
Arquitetura de carga de trabalho: mantenha imagens pequenas e otimizadas. Simplificar suas imagens ajuda a reduzir custos, já que 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 durante a inicialização do aplicativo, potencialmente levando ao excesso de provisionamento.
Arquitetura de cluster: habilite o Cluster Autoscaler para reduzir automaticamente o número de nós do agente em resposta ao excesso de capacidade de recursos. Reduzir automaticamente o número de nós em seu cluster AKS permite executar um cluster eficiente quando a demanda é baixa e aumentar a escala quando a demanda retorna.
Arquitetura de cluster: habilite o provisionamento automático de nós 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 pendentes de recursos do pod, a configuração de VM ideal 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 suportam operações de escalonamento de cluster.
Arquitetura de carga de trabalho: use o Vertical Pod Autoscaler (visualização). Dimensione corretamente seus pods e defina dinamicamente solicitações e limites com base no histórico de uso.
Arquitetura de carga de trabalho: use o Kubernetes Event Driven Autoscaling (KEDA). Escala com base no número de eventos que estão sendo processados. Escolha a partir de um rico catálogo de escaladores 50+ KEDA.
Arquiteturas de cluster e carga de trabalho: adote uma disciplina financeira e uma prática cultural na nuvem para impulsionar a propriedade do uso da nuvem. A base para permitir 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 em 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 Poupança 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: revise 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/A
Arquitetura de cluster: Configure o complemento AKS Cost Analysis. A extensão de cluster de análise de custos permite obter informações 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 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 AKS e para o complemento Política do Azure para 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 na 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 é o passo inicial para tornar as cargas de trabalho mais sustentáveis.

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

Excelência operacional

A monitorização e o diagnóstico são fundamentais. Você não só 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 Kubernetes do Azure, é importante distinguir entre excelência operacional de cluster e excelência operacional de 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 do domínio de um desenvolvedor. O Serviço 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 ambas.

Lista de verificação de estruturação

  • Arquitetura de cluster: use uma implantação baseada em modelo usando Bicep, Terraform ou outros. Certifique-se de que todas as implantações sejam 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 é realizado usando 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 plano de controle ou do servidor de API principal sejam registradas.
  • Arquiteturas de cluster e carga de trabalho: revise 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 da carga de trabalho: a carga de trabalho deve ser projetada para emitir telemetria que pode ser coletada, que também deve incluir status de vivacidade e prontidã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 a Política do Azure.

Recomendações

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

Recomendação Benefício
Arquiteturas de cluster e carga de trabalho: analise a documentação de práticas recomendadas do AKS. Para criar e executar aplicativos com sucesso no AKS, há considerações importantes para entender e implementar. Essas áreas incluem recursos de multilocação e agendamento, segurança de cluster e pod ou continuidade de negócios e recuperação de desastres.
Arquiteturas de cluster e carga de trabalho: analise o Azure Chaos Studio. O Azure Chaos Studio pode ajudar a simular falhas e acionar situações de recuperação de desastres.
Arquiteturas de cluster e carga de trabalho: revise 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/A
Arquitetura de cluster: adote uma estratégia de várias regiões implantando clusters AKS implantados em diferentes regiões do Azure para maximizar a disponibilidade e fornecer continuidade de negócios. As cargas de trabalho voltadas para a Internet devem aproveitar o Azure Front Door ou o Azure Traffic Manager para rotear o tráfego globalmente em clusters AKS.
Arquitetura de cluster: operacionalize clusters e padrões de configuração de pods com a Política do Azure. A Política do Azure pode ajudar a aplicar a imposição e as salvaguardas em escala em seus clusters de maneira centralizada e consistente. Ele também pode controlar quais funções são concedidas e se algo está indo contra a política da empresa.
Arquitetura de carga de trabalho: use os recursos da plataforma em seu processo de engenharia de versão. O Kubernetes e os controladores de entrada suportam muitos padrões avançados de implantação para inclusão em seu processo de engenharia de versão. Considere padrões como implantações azul-esverdeadas ou lançamentos canários.
Arquiteturas de cluster e carga de trabalho: para cargas de trabalho de missão crítica, use implantações azuis/verdes de nível de carimbo. Automatize suas áreas de projeto de missão crítica, incluindo implantação e testes.

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

O Consultor do Azure também faz recomendações sobre um subconjunto dos itens listados na seção de política abaixo, como versões 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

A Política do Azure 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 de Política do Azure 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 .

Há um grande número de políticas, e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma visão mais detalhada, consulte Definições de política internas para o Kubernetes.

Arquitetura de cluster

  • Complemento de Política do Azure para Kubernetes
  • Políticas de configuração do GitOps
  • Políticas de configurações de diagnóstico
  • Restrições de versão do AKS
  • Comando Prevent invoke

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 AKS e para o complemento Política do Azure 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

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Recomendamos que você revise os princípios de eficiência de desempenho.

Ao discutir o desempenho com o Serviço 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. O Serviço 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 ambas.

Lista de verificação de estruturação

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

  • Arquiteturas de cluster e carga de trabalho: execute e itere em um exercício de plano de capacidade detalhado 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 autoscaler 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 exercitem o dimensionador automático do pod e do cluster.
  • Arquiteturas de cluster e carga de trabalho: Separe cargas de trabalho em pools de nós diferentes, permitindo chamadas independentes.

Recomendações

Explore a tabela de recomendações a seguir para otimizar a configuração do Serviço 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 aumentar ou reduzir automaticamente o número de nós em seu cluster AKS permite que você execute 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 a execução de nós, os pools de nós do usuário permitem aumentar ou diminuir a escala.
Arquitetura de carga de trabalho: use os recursos avançados do agendador 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 significativo de regras de dimensionamento automático com base em sinais específicos para sua carga de trabalho.

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

Definições de política

A Política do Azure 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 de Política do Azure 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 .

Há um grande número de políticas, e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma visã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 AKS e para o complemento Política do Azure 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

Orientação do Centro de Arquitetura do Azure

Orientações do Cloud Adoption Framework

Próximos passos