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

  • Artigo

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

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

Partimos do princípio de que compreende os princípios de design do sistema, tem conhecimentos práticos sobre Azure Kubernetes Service e está familiarizado com as suas funcionalidades. Para obter mais informações, veja Azure Kubernetes Service.

Pré-requisitos

Compreender os pilares do Well-Architected Framework pode ajudar a produzir uma arquitetura de cloud de alta qualidade, estável e eficiente. Recomendamos que reveja a carga de trabalho com a avaliação do Azure Well-Architected Framework Review .

Para contexto, considere rever uma arquitetura de referência que reflita estas considerações na estrutura. Recomendamos que comece com a arquitetura de linha de base de um cluster de Azure Kubernetes Service (AKS) e arquitetura de Microsserviços no Azure Kubernetes Service. Reveja também o acelerador de zonas de destino do AKS, que fornece uma abordagem arquitetónica e uma implementação de referência para preparar subscrições de zona de destino para um cluster de Azure Kubernetes Service dimensionável (AKS).

Fiabilidade

Na cloud, reconhecemos que ocorrem falhas. Em vez de tentar evitar simplesmente as falhas, o objetivo é minimizar os efeitos da falha de um único componente. Utilize as seguintes informações para minimizar as instâncias com falhas.

Ao debater a fiabilidade com Azure Kubernetes Service, é importante distinguir entre a fiabilidade do cluster e a fiabilidade da carga de trabalho. A fiabilidade do cluster é uma responsabilidade partilhada entre o administrador do cluster e o respetivo fornecedor de recursos, enquanto a fiabilidade da carga de trabalho é o domínio de um programador. Azure Kubernetes Service 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 escolha é aplicável à arquitetura do cluster, à arquitetura da carga de trabalho ou a ambas.

Lista de verificação de estruturação

  • Arquitetura do cluster: Para cargas de trabalho críticas, utilize zonas de disponibilidade para os clusters do AKS.
  • Arquitetura do cluster: Planeie o espaço de endereços IP para garantir que o cluster pode dimensionar de forma fiável, incluindo o processamento do tráfego de ativação pós-falha em topologias de vários clusters.
  • Arquitetura do cluster: Ative o Container Insights para monitorizar o cluster e configurar alertas para eventos com impacto na fiabilidade.
  • Arquitetura da carga de trabalho: Confirme que as cargas de trabalho são criadas para suportar o dimensionamento horizontal e comunicar a preparação e o estado de funcionamento das aplicações.
  • Arquiteturas de clusters e cargas de trabalho: Certifique-se de que a carga de trabalho está em execução nos conjuntos de nós de utilizador e selecione o SKU de tamanho certo. No mínimo, inclua dois nós para conjuntos de nós de utilizador e três nós para o conjunto de nós do sistema.
  • Arquitetura do cluster: Utilize o SLA de Tempo de Atividade do AKS para cumprir os objetivos de disponibilidade das cargas de trabalho de produção.

Recomendações de configuração do AKS

Explore o seguinte índice de recomendações para otimizar a configuração do AKS para Fiabilidade.

Recomendação Vantagem
Arquiteturas de clusters e cargas de trabalho: Controlar o agendamento de pods com seletores de nós e afinidade. Permite que o agendador do Kubernetes isole logicamente cargas de trabalho por hardware no nó. Ao contrário das tolerâncias, os pods sem um seletor de nós correspondente podem ser agendados em nós etiquetados, o que permite que os recursos não utilizados nos nós consumam, mas dá prioridade aos pods que definem o seletor de nós correspondente. Utilize a afinidade de nó para obter mais flexibilidade, o que lhe permite definir o que acontece se o pod não puder ser correspondido com um nó.
Arquitetura do cluster: Garanta uma seleção adequada do plug-in de rede com base nos requisitos de rede e no dimensionamento do cluster. O Azure CNI é necessário para cenários específicos, por exemplo, conjuntos de nós baseados no Windows, requisitos de rede específicos e Políticas de Rede do Kubernetes. Veja Kubenet versus CNI do Azure para obter mais informações.
Arquiteturas de clusters e cargas de trabalho: Utilize 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 final do servidor da API do Kubernetes para Clusters do AKS que utilizam o Azure Zonas de Disponibilidade ou
- 99.9%disponibilidade para Clusters do AKS que não utilizam o Azure Zonas de Disponibilidade.
Arquiteturas de clusters e cargas de trabalho: Configurar a monitorização do cluster com as Informações do contentor. As informações de contentor ajudam a monitorizar o estado de funcionamento e o desempenho dos controladores, nós e contentores que estão disponíveis no Kubernetes através da API de Métricas. A integração com o Prometheus permite a recolha de métricas de aplicação e carga de trabalho.
Arquitetura do cluster: Utilize zonas de disponibilidade para maximizar a resiliência numa região do Azure ao distribuir nós de agentes do AKS em datacenters fisicamente separados. Ao distribuir conjuntos de nós por várias zonas, os nós num conjunto de nós continuarão a ser executados mesmo que outra zona tenha caído. Se existirem requisitos de colocalidade, pode ser utilizada uma implementação regular do AKS baseado em VMSS numa única zona ou grupos de colocação por proximidade para minimizar a latência interna.
Arquitetura do cluster: Adote uma estratégia de várias regiões ao implementar clusters do AKS implementados em diferentes regiões do Azure para maximizar a disponibilidade e proporcionar continuidade de negócio. As cargas de trabalho com acesso à Internet devem tirar partido do Azure Front Door ou do Gestor de Tráfego do Azure para encaminhar o tráfego globalmente entre clusters do AKS.
Arquiteturas de clusters e cargas de trabalho: Defina os pedidos de recursos do Pod e os limites nos manifestos de implementação de aplicações e aplique com Azure Policy. Os limites da CPU de contentor e dos recursos de memória são necessários para evitar o esgotamento de recursos no cluster do Kubernetes.
Arquiteturas de clusters e cargas de trabalho: Mantenha o Conjunto de nós do sistema isolado das cargas de trabalho da aplicação. Os conjuntos de nós de sistema requerem um SKU de VM de, pelo menos, 2 vCPUs e 4 GB de memória, mas é recomendado 4 vCPUs ou mais. Veja Sistema e conjuntos de nós de utilizador para obter requisitos detalhados.
Arquiteturas de clusters e cargas de trabalho: Separe as aplicações para conjuntos de nós dedicados com base em requisitos específicos. As aplicações podem partilhar a mesma configuração e precisar de VMs ativadas para GPU, CPU ou VMs otimizadas para memória ou a capacidade de dimensionar para zero. Evite um grande número de conjuntos de nós para reduzir a sobrecarga de gestão adicional.
Arquitetura do cluster: Utilize um NAT gateway para clusters que executam cargas de trabalho que fazem muitas ligações de saída simultâneas. Para evitar problemas de fiabilidade com Balanceador de Carga do Azure limitações com tráfego de saída em simultâneo elevado, em vez disso, utilizamos um NAT Gateway para suportar tráfego de saída fiável em escala.

Para obter mais sugestões, veja Princípios do pilar de fiabilidade.

Azure Policy

Azure Kubernetes Service oferece uma grande variedade de Políticas do Azure incorporadas que se aplicam tanto ao recurso do Azure como às Políticas típicas do Azure e, com o suplemento Azure Policy para Kubernetes, também dentro do cluster. Existem inúmeras políticas e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma vista mais detalhada, veja definições de política incorporadas para o Kubernetes.

Arquitetura de clusters e cargas de trabalho

  • Os clusters têm sondas de estado de funcionamento de preparação ou liveness configuradas para as especificações do pod.

Além das definições de Azure Policy incorporadas, podem ser criadas políticas personalizadas para o recurso do AKS e para o suplemento Azure Policy para o Kubernetes. Isto permite-lhe adicionar restrições de fiabilidade adicionais que gostaria de impor na arquitetura do cluster e da 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 da sua aplicação, recomendamos que reveja os Princípios de conceção de segurança. Se o cluster de Azure Kubernetes Service tiver de ser concebido para executar uma carga de trabalho confidencial que cumpra os requisitos regulamentares da Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS 3.2.1), veja Cluster regulado do AKS para PCI-DSS 3.2.1.

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

Ao debater a segurança com Azure Kubernetes Service, é importante distinguir entre a segurança do cluster e a segurança da carga de trabalho. A segurança do cluster é uma responsabilidade partilhada entre o administrador do cluster e o respetivo fornecedor de recursos, enquanto a segurança da carga de trabalho é o domínio de um programador. Azure Kubernetes Service 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 escolha é aplicável à arquitetura do cluster, à arquitetura da carga de trabalho ou a ambas.

Lista de verificação de estruturação

  • Arquitetura do cluster: Utilize identidades geridas para evitar gerir e rodar princípios de serviço.
  • Arquitetura do cluster: Utilize o controlo de acesso baseado em funções (RBAC) 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 do cluster: Utilize Microsoft Defender para contentores com o Azure Sentinel para detetar e responder rapidamente a ameaças no seu cluster e cargas de trabalho em execução nos mesmos.
  • Arquitetura do cluster: Implemente um cluster do AKS privado para garantir que o tráfego de gestão de clusters no servidor de API permanece na sua rede privada. Em alternativa, utilize a lista de permissões do servidor de API para clusters não privados.
  • Arquitetura da carga de trabalho: Utilize um Firewall de Aplicações Web para proteger o tráfego HTTP(S).
  • Arquitetura da carga de trabalho: Certifique-se de que o pipeline CI/CID está endurecido com a análise com deteção de contentores.

Recomendações

Explore o seguinte índice de recomendações para otimizar a configuração do AKS para segurança.

Recomendação Vantagem
Arquitetura do cluster: Utilize Microsoft Entra integração. Utilizar Microsoft Entra ID centraliza o componente de gestão de identidades. Qualquer alteração no estado da conta de utilizador ou do grupo é atualizada automaticamente no acesso ao cluster do AKS. Os programadores e os proprietários de aplicações do cluster do Kubernetes precisam de acesso a diferentes recursos.
Arquitetura do cluster: Autentique com Microsoft Entra ID para Azure Container Registry. O AKS e o Microsoft Entra ID permitem a autenticação com Azure Container Registry sem a utilização de imagePullSecrets segredos. Veja Autenticar com Azure Container Registry do Azure Kubernetes Service para obter mais informações.
Arquitetura do cluster: Proteja o tráfego de rede para o servidor de API com o cluster do AKS privado. Por predefinição, o tráfego de rede entre os conjuntos de nós e o servidor de API percorre a rede principal da Microsoft; Ao utilizar um cluster privado, pode garantir que o tráfego de rede para o servidor de API permanece apenas na rede privada.
Arquitetura do cluster: Para clusters do AKS não privados, utilize intervalos de IP autorizados do servidor de API. Ao utilizar clusters públicos, ainda pode limitar o tráfego que pode aceder ao servidor de API dos clusters com a funcionalidade de intervalo de IP autorizado. Inclua origens como os IPs públicos dos agentes de compilação de implementação, a gestão de operações e o ponto de saída dos conjuntos de nós (por exemplo, Azure Firewall).
Arquitetura do 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 pode fazer para proteger o cluster. Integre o controlo de acesso baseado em funções (RBAC) do Kubernetes com Microsoft Entra ID para controlar o acesso ao servidor de API. Desative as contas locais para impor todo o acesso ao cluster com identidades baseadas em Microsoft Entra ID.
Arquitetura do cluster: Utilize as políticas de rede do Azure ou o Calico. Proteger e controlar o tráfego de rede entre pods num cluster.
Arquitetura do cluster: Proteger clusters e pods com Azure Policy. Azure Policy podem ajudar a aplicar a imposição à escala e as salvaguardas nos clusters de forma centralizada e consistente. Também pode controlar que pods de funções são concedidos e se alguma coisa está em execução contra a política da empresa.
Arquitetura do cluster: Proteger o acesso de contentor aos recursos. Limitar o acesso a ações que os contentores podem executar. Forneça o menor número de permissões e evite a utilização de escalamento de raiz ou privilegiado.
Arquitetura da carga de trabalho: Utilize um Firewall de Aplicações Web para proteger o tráfego HTTP(S). Para analisar o tráfego de entrada relativamente a potenciais ataques, utilize uma firewall de aplicações Web, como o Azure Firewall de Aplicações Web (WAF) no Gateway de Aplicação do Azure ou no Azure Front Door.
Arquitetura do cluster: Controlar o tráfego de saída do cluster. Certifique-se de que o tráfego de saída do cluster está a passar por um ponto de segurança de rede, como Azure Firewall ou um proxy HTTP.
Arquitetura do cluster: Utilize o controlador CSI open source ID de carga de trabalho Microsoft Entra e Secrets Store com o Azure Key Vault. Proteja e rode segredos, certificados e cadeias de ligação no Azure Key Vault com encriptação forte. Fornece um registo de auditoria de acesso e mantém os segredos principais fora do pipeline de implementação.
Arquitetura do cluster: Utilize Microsoft Defender para Contentores. Monitorize e mantenha a segurança dos clusters, dos contentores e das respetivas aplicações.

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

O Assistente do Azure ajuda a garantir e melhorar o serviço Kubernetes do Azure. Faz recomendações sobre um subconjunto dos itens listados na secção de política abaixo, como clusters sem RBAC configurado, configuração de Microsoft Defender em falta, acesso de rede sem restrições ao Servidor de API. Da mesma forma, faz recomendações de cargas de trabalho para alguns dos itens de iniciativa de segurança do pod. Reveja as recomendações.

Definições de política

Azure Policy oferece várias definições de política incorporadas que se aplicam tanto ao recurso do Azure como ao AKS, como definições de política padrão, e ao utilizar o suplemento Azure Policy para o Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure são utilizadas em Auditoria/Negação, mas também numa variante Implementar Se Não Existir .

Existem inúmeras políticas e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma vista mais detalhada, veja definições de política incorporadas para o Kubernetes.

Arquitetura do cluster

  • Microsoft Defender para políticas baseadas na cloud
  • Modo de autenticação e políticas de configuração (Microsoft Entra ID, RBAC, desativar a autenticação local)
  • Políticas de acesso à rede do Servidor API, incluindo cluster privado

Arquitetura de clusters e cargas de trabalho

  • Kubernetes cluster pod security initiatives Linux-based workloads (Cargas de trabalho baseadas no Linux)
  • Inclua políticas de capacidade de pods e contentores, tais como AppArmor, sysctl, maiúsculas de segurança, SELinux, seccomp, contentores com privilégios, credenciais da API de cluster de montagem automática
  • Políticas de montagem, controladores de volume e sistema de ficheiros
  • Políticas de rede pod/contentor, como rede de anfitrião, porta, IPs externos permitidos, HTTPs e balanceadores de carga internos

Azure Kubernetes Service implementações também utilizam frequentemente Azure Container Registry para gráficos Helm e imagens de contentor. Azure Container Registry também suporta uma grande variedade de políticas do Azure que abrangem restrições de rede, controlo de acesso e Microsoft Defender para a Cloud, o que complementa uma arquitetura segura do AKS.

Além das políticas incorporadas, podem ser criadas políticas personalizadas para o recurso do AKS e para o suplemento Azure Policy para o Kubernetes. Isto permite-lhe adicionar restrições de segurança adicionais que gostaria de impor na arquitetura do cluster e da carga de trabalho.

Para obter mais sugestões, veja Conceitos de segurança do AKS e avalie as nossas recomendações de proteção de segurança com base na referência do CIS Kubernetes.

Otimização de custos

A otimização de custos consiste em compreender as diferentes opções de configuração e as melhores práticas recomendadas para reduzir as despesas desnecessárias e melhorar a eficiência operacional. Antes de seguir as orientações neste artigo, recomendamos que reveja os seguintes recursos:

Ao debater a otimização de custos com Azure Kubernetes Service, é 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 partilhada entre o administrador do cluster e o respetivo fornecedor de recursos, enquanto os recursos de carga de trabalho são o domínio de um programador. Azure Kubernetes Service 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 escolha é aplicável à arquitetura do cluster, à arquitetura da carga de trabalho ou a ambas.

Para otimizar os custos do cluster, aceda à calculadora de preços do Azure e selecione Azure Kubernetes Service nos produtos disponíveis. Pode testar diferentes planos de configuração e pagamento na calculadora.

Lista de verificação de estruturação

  • Arquitetura do cluster: Utilize o SKU de VM adequado por conjunto de nós e instâncias reservadas em que a capacidade de longo prazo é esperada.
  • Arquiteturas de clusters e cargas de trabalho: Utilize o escalão e o tamanho do disco gerido adequados.
  • Arquitetura do cluster: Reveja as métricas de desempenho, começando pela CPU, memória, armazenamento e rede, para identificar oportunidades de otimização de custos por cluster, nós e espaço de nomes.
  • Arquitetura de clusters e cargas de trabalho: Utilize dimensionadores automáticos para reduzir horizontalmente quando as cargas de trabalho estiverem menos ativas.

Recomendações

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

Recomendação Vantagem
Arquiteturas de clusters e cargas de trabalho: Alinhar a seleção de SKU e o tamanho do disco gerido com os requisitos da carga de trabalho. Corresponder a sua seleção às exigências da carga de trabalho garante que não paga por recursos desnecessários.
Arquitetura do cluster: Selecione o tipo de instância de máquina virtual correto. Selecionar o tipo de instância de máquina virtual certo é fundamental, uma vez que afeta diretamente o custo de execução de aplicações no AKS. Escolher uma instância de alto desempenho sem uma utilização adequada pode levar a gastos desperdiçados, ao passo que escolher uma instância poderosa pode levar a problemas de desempenho e a um 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 do 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 de nós de arquitetura Intel e ARM mistos dentro de um cluster que podem proporcionar um melhor desempenho a um custo mais baixo.
Arquitetura do cluster: Selecione Azure Spot Máquinas Virtuais. As VMs Spot permitem-lhe tirar partido da capacidade não otimizada do Azure com descontos significativos (até 90% em comparação com os preços pay as you go). Se o Azure precisar de capacidade de volta, a infraestrutura do Azure expulsa os nós Spot.
Arquitetura do cluster: Selecione a região adequada. 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 está a executar a carga de trabalho de forma económica e que não afeta os utilizadores finais nem cria custos adicionais de rede.
Arquitetura da carga de trabalho: Manter imagens pequenas e otimizadas. Simplificar as imagens ajuda a reduzir os custos, uma vez que os novos nós precisam de transferir estas imagens. Crie imagens de uma forma que permita que o contentor seja iniciado o mais rapidamente possível para ajudar a evitar falhas ou tempos limite de pedidos do utilizador enquanto a aplicação está a iniciar, o que pode levar ao sobreaprovisionamento.
Arquitetura do cluster: Ative o Dimensionador Automático de Clusters para reduzir automaticamente o número de nós de agente em resposta ao excesso de capacidade de recursos. Reduzir verticalmente automaticamente o número de nós no cluster do AKS permite-lhe executar um cluster eficiente quando a procura é baixa e aumentar verticalmente quando a procura é devolvida.
Arquitetura do cluster: Ative o Aprovisionamento Automático do Nó para automatizar a seleção de SKU da VM. O Aprovisionamento Automático do Nó 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 forma mais eficiente e económica.
Arquitetura da carga de trabalho: Utilize o Horizontal Pod Autoscaler. Ajuste o número de pods numa implementação consoante a utilização da CPU ou outras métricas selecionadas, que suportam operações de redução horizontal de clusters.
Arquitetura da carga de trabalho: Utilize o Dimensionador Automático de Pods Vertical (pré-visualização). Defina os seus pods com direitos e defina dinamicamente pedidos e limites com base na utilização histórica.
Arquitetura da carga de trabalho: Utilize o Dimensionamento Automático Condicionado por Eventos do Kubernetes (KEDA). Dimensionar com base no número de eventos que estão a ser processados. Escolha entre um catálogo avançado com mais de 50 dimensionadores KEDA.
Arquiteturas de clusters e cargas de trabalho: Adote uma disciplina financeira e prática cultural da cloud para impulsionar a propriedade da utilização da cloud. A base da ativação da otimização de custos é a propagação de um cluster de poupança de custos. Uma abordagem de operações financeiras (FinOps) é frequentemente utilizada para ajudar as organizações a reduzir os custos da cloud. É uma prática que envolve a colaboração entre as equipas de finanças, operações e engenharia para impulsionar o alinhamento em objetivos de poupança de custos e trazer transparência aos custos da cloud.
Arquitetura do cluster: Inscreva-se nas Reservas do Azure ou no Plano de Poupança do Azure. Se planeou corretamente a capacidade, a carga de trabalho é previsível e existe durante um longo período de tempo, inscreva-se numa Reserva do Azure ou num plano de poupança para reduzir ainda mais os custos dos recursos.
Arquitetura do cluster: Configurar a monitorização do cluster com as Informações do contentor. As informações de contentor ajudam a fornecer informações acionáveis sobre os seus clusters inativos e recursos não alocados. O Container Insights também suporta a recolha de métricas do Prometheus e integra-se com o Azure Managed Grafana para obter uma vista holística da sua aplicação e infraestrutura.
Arquitetura do cluster: Configure o suplemento Análise de Custos do AKS. A extensão do cluster de análise de custos permite-lhe obter informações granulares sobre os custos associados a vários recursos do Kubernetes nos seus clusters ou espaços de nomes.

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

Definições de política

Embora não existam políticas incorporadas relacionadas com a otimização de custos, podem ser criadas políticas personalizadas para o recurso do AKS e para o suplemento Azure Policy para o Kubernetes. Isto permite-lhe adicionar restrições adicionais de otimização de custos que gostaria de impor na arquitetura do cluster e da carga de trabalho.

Eficiência da cloud

Tornar as cargas de trabalho mais sustentáveis e eficientes na cloud requer combinar esforços em torno da otimização de custos, reduzir as emissões de carbono e otimizar o consumo de energia. Otimizar o custo da aplicação é o passo 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 Azure Kubernetes Service (AKS).

Excelência operacional

A monitorização e o diagnóstico são fundamentais. Não só pode medir as estatísticas de desempenho, como também utilizar métricas para resolver e remediar problemas rapidamente. Recomendamos que reveja os princípios de design de excelência operacional e o Guia de operações do Dia-2.

Ao debater a excelência operacional com Azure Kubernetes Service, é 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 partilhada entre o administrador do cluster e o respetivo fornecedor de recursos, enquanto as operações de carga de trabalho são o domínio de um programador. Azure Kubernetes Service 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 escolha é aplicável à arquitetura do cluster, à arquitetura da carga de trabalho ou a ambas.

Lista de verificação de estruturação

  • Arquitetura do cluster: Utilize uma implementação baseada em modelos com o Bicep, Terraform ou outros. Confirme que todas as implementações são repetíveis, rastreáveis e armazenadas num repositório de código fonte.
  • Arquitetura do cluster: Crie um processo automatizado para garantir que os clusters são iniciados com as configurações e implementações necessárias em todo o cluster. Esta ação é frequentemente efetuada com o GitOps.
  • Arquitetura da carga de trabalho: Utilize processos de implementação repetíveis e automatizados para a carga de trabalho no ciclo de vida de desenvolvimento de software.
  • Arquitetura do cluster: Ative as definições de diagnóstico para garantir que as interações do plano de controlo ou do servidor de API principal são registadas.
  • Arquiteturas de clusters e cargas de trabalho: Ative o Container Insights para recolher métricas, registos e diagnósticos para monitorizar a disponibilidade e o desempenho do cluster e das cargas de trabalho em execução no mesmo.
  • Arquitetura da carga de trabalho: A carga de trabalho deve ser concebida para emitir telemetria que possa ser recolhida, o que também deve incluir liveliness e estados de preparação.
  • Arquiteturas de clusters e cargas de trabalho: Utilize as práticas de engenharia de caos que visam o Kubernetes para identificar problemas de fiabilidade da aplicação ou da plataforma.
  • Arquitetura da carga de trabalho: Otimize a carga de trabalho para operar e implementar de forma eficiente num contentor.
  • Arquiteturas de clusters e cargas de trabalho: Impor governação de clusters e cargas de trabalho com Azure Policy.

Recomendações

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

Recomendação Vantagem
Arquiteturas de clusters e cargas de trabalho: Veja a documentação de melhores práticas do AKS . Para criar e executar aplicações com êxito no AKS, existem considerações fundamentais para compreender e implementar. Estas áreas incluem funcionalidades multi-inquilinos e scheduler, segurança de clusters e pods ou continuidade de negócio e recuperação após desastre.
Arquiteturas de clusters e cargas de trabalho:Reveja Azure Chaos Studio. O Azure Chaos Studio pode ajudar a simular falhas e acionar situações de recuperação após desastre.
Arquiteturas de clusters e cargas de trabalho: Configurar a monitorização do cluster com as Informações do contentor. As informações de contentor ajudam a monitorizar o desempenho dos contentores ao recolher métricas de memória e processador de controladores, nós e contentores disponíveis no Kubernetes através da API de Métricas e dos registos de contentor.
Arquitetura da carga de trabalho: Monitorizar o desempenho da aplicação com o Azure Monitor. Configure o Application Insights para monitorização baseada em código de aplicações em execução num cluster do AKS.
Arquitetura da carga de trabalho: Configure a extração de métricas do Prometheus com o Container Insights. As informações de contentor, que fazem parte do Azure Monitor, proporcionam uma experiência de integração totalmente integrada para recolher métricas do Prometheus. Referência Configurar a extração de métricas do Prometheus para obter mais informações.
Arquitetura do cluster: Adote uma estratégia de várias regiões ao implementar clusters do AKS implementados em diferentes regiões do Azure para maximizar a disponibilidade e proporcionar continuidade de negócio. As cargas de trabalho com acesso à Internet devem tirar partido do Azure Front Door ou do Gestor de Tráfego do Azure para encaminhar o tráfego globalmente entre clusters do AKS.
Arquitetura do cluster: Operacionalize os padrões de configuração de clusters e pods com Azure Policy. Azure Policy podem ajudar a aplicar a imposição à escala e as salvaguardas nos clusters de forma centralizada e consistente. Também pode controlar que pods de funções são concedidos e se alguma coisa está em execução contra a política da empresa.
Arquitetura da carga de trabalho: Utilize as capacidades da plataforma no seu processo de engenharia de versões. O Kubernetes e os controladores de entrada suportam muitos padrões de implementação avançados para inclusão no processo de engenharia de versões. Considere padrões como implementações verde-azulado ou versões canary.
Arquiteturas de clusters e cargas de trabalho: Para cargas de trabalho críticas para a missão, utilize implementações azul/verde ao nível do selo. Automatize as suas áreas de design fundamentais para a missão, incluindo implementação e teste.

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

O Assistente do Azure também faz recomendações sobre um subconjunto dos itens listados na secção de política abaixo, tais como versões do AKS não suportadas e definições de diagnóstico não configuradas. Da mesma forma, faz recomendações de cargas de trabalho sobre a utilização do espaço de nomes predefinido.

Definições de política

Azure Policy oferece várias definições de política incorporadas que se aplicam tanto ao recurso do Azure como ao AKS, como definições de política padrão, e ao utilizar o suplemento Azure Policy para o Kubernetes, também dentro do cluster. Muitas das políticas de recursos do Azure são utilizadas em Auditoria/Negação, mas também numa variante Implementar Se Não Existir .

Existem inúmeras políticas e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma vista mais detalhada, veja definições de política incorporadas para o Kubernetes.

Arquitetura do cluster

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

Arquitetura de clusters e cargas de trabalho

  • Restrições de implementação do espaço de nomes

Além das políticas incorporadas, podem ser criadas políticas personalizadas para o recurso do AKS e para o suplemento Azure Policy para o Kubernetes. Isto permite-lhe adicionar restrições de segurança adicionais que gostaria de impor na arquitetura do cluster e da 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 reveja os princípios de eficiência de desempenho.

Ao debater o desempenho com Azure Kubernetes Service, é importante distinguir entre o desempenho do cluster e o desempenho da carga de trabalho. O desempenho do cluster é uma responsabilidade partilhada entre o administrador do cluster e o respetivo fornecedor de recursos, enquanto o desempenho da carga de trabalho é o domínio de um programador. Azure Kubernetes Service 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 escolha é aplicável à arquitetura do cluster, à arquitetura da carga de trabalho ou a ambas.

Lista de verificação de estruturação

À medida que faz escolhas de estrutura para Azure Kubernetes Service, reveja os princípios de eficiência de desempenho.

  • Arquiteturas de clusters e cargas de trabalho: Execute e itere num exercício detalhado do plano de capacidade que inclua SKU, definições de dimensionamento automático, endereçamento IP e considerações de ativação pós-falha.
  • Arquitetura do cluster: Ative o dimensionador automático de clusters para ajustar automaticamente o número de nós de agente nas exigências da carga de trabalho de resposta.
  • Arquitetura do cluster: Utilize o dimensionador automático de pods horizontal para ajustar o número de pods numa implementação, dependendo da utilização da CPU ou de outras métricas selecionadas.
  • Arquiteturas de clusters e cargas de trabalho: Realize atividades de teste de carga contínuas que exerçam o pod e o dimensionador automático de clusters.
  • Arquiteturas de clusters e cargas de trabalho: Separe as cargas de trabalho em conjuntos de nós diferentes, permitindo o dimensionamento independente.

Recomendações

Explore o seguinte índice de recomendações para otimizar a configuração do Azure Kubernetes Service para o desempenho.

Recomendação Vantagem
Arquiteturas de clusters e cargas de trabalho: Desenvolva um plano de capacidade detalhado e reveja e reveja continuamente. Depois de formalizar o seu plano de capacidade, este deve ser atualizado com frequência ao observar continuamente a utilização de recursos do cluster.
Arquitetura do cluster: Ative o dimensionador automático do cluster para ajustar automaticamente o número de nós de agente em resposta a restrições de recursos. A capacidade de aumentar ou reduzir verticalmente automaticamente o número de nós no cluster do AKS permite-lhe executar um cluster eficiente e económico.
Arquiteturas de clusters e cargas de trabalho: Separe cargas de trabalho em conjuntos de nós diferentes e considere dimensionar conjuntos de nós de utilizador. Ao contrário dos conjuntos de nós do sistema que exigem sempre nós em execução, os conjuntos de nós de utilizador permitem-lhe aumentar ou reduzir verticalmente.
Arquitetura da carga de trabalho: Utilize as funcionalidades do agendador avançado do AKS. Ajuda a controlar o balanceamento de recursos para cargas de trabalho que os exigem.
Arquitetura da carga de trabalho: Utilize métricas significativas de dimensionamento de cargas de trabalho. Nem todas as decisões de dimensionamento podem derivar da CPU ou das métricas de memória. Muitas vezes, as considerações de dimensionamento provêm de pontos de dados mais complexos ou mesmo externos. Utilize a KEDA para criar um conjunto de regras de dimensionamento automático significativo com base em sinais específicos da sua carga de trabalho.

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

Definições de política

Azure Policy oferece várias definições de política incorporadas que se aplicam tanto ao recurso do Azure como ao AKS, como definições de política padrão, e ao utilizar o suplemento Azure Policy para Kubernetes, também no cluster. Muitas das políticas de recursos do Azure vêm em Auditoria/Negar, mas também numa variante Deploy If Not Exists .

Existem inúmeras políticas e as principais políticas relacionadas com este pilar são resumidas aqui. Para obter uma vista mais detalhada, veja definições de política incorporadas para o Kubernetes.

Arquitetura de clusters e cargas de trabalho

  • Limites de recursos de CPU e memória

Além das políticas incorporadas, podem ser criadas políticas personalizadas para o recurso do AKS e para o suplemento Azure Policy para o Kubernetes. Isto permite-lhe adicionar restrições de segurança adicionais que gostaria de impor na arquitetura do cluster e da carga de trabalho.

Recursos adicionais

Orientação do Centro de Arquitetura do Azure

Orientações do Cloud Adoption Framework

Passos seguintes