Compartilhar via

Conheça as melhores práticas de desempenho e escala para cargas de trabalho pequenas e médias no Serviço de Kubernetes do Azure (AKS).

  • Artigo

Observação

Esse artigo se concentra nas melhores práticas gerais para cargas de trabalho pequenas e médias. Para ver as melhores práticas específicas de cargas de trabalho grandes, consulte Melhores práticas de desempenho e escala para cargas de trabalho grandes no Serviço de Kubernetes do Azure (AKS).

Ao implantar e manter clusters no AKS, use as melhores práticas a seguir para ajudar a otimizar o desempenho e a escala.

Neste artigo, você aprenderá sobre:

  • Compensações e recomendações para dimensionamento automático de suas cargas de trabalho.
  • Como gerenciar o dimensionamento e a eficiência do nó com base nas demandas de carga de trabalho.
  • Considerações de rede para o tráfego de entrada e saída.
  • Monitoramento e solução de problemas de desempenho do painel de controle e do nó.
  • Planejamento de capacidade, cenários de aumento e atualizações de cluster.
  • Considerações de armazenamento e rede para o desempenho do plano de dados.

Dimensionamento automático de aplicativos versus dimensionamento automático de infraestrutura

Dimensionamento automático do aplicativo

O dimensionamento automático de aplicativos é útil ao lidar com limitações de infraestrutura ou otimização de custo. Um dimensionador automático bem configurado mantém alta disponibilidade para seu aplicativo, minimizando também os custos. Você paga apenas pelos recursos necessários para manter a disponibilidade, independentemente da demanda.

Por exemplo, se um nó existente tiver espaço, mas não houver IPs suficientes na sub-rede, ele poderá ignorar a criação de um novo nó e, em vez disso, iniciar imediatamente a execução do aplicativo em um novo pod.

Dimensionamento Automático de Pod Horizontal

Implementar o dimensionamento automático de pod horizontal é útil para aplicativos com uma demanda de recursos estável e previsível. O Dimensionador Automático de Pod Horizontal (HPA) dimensiona dinamicamente o número de réplicas de pod, que distribui efetivamente a carga entre vários pods e nós. Esse mecanismo de dimensionamento normalmente é mais benéfico para aplicativos que podem ser decompostos em componentes menores e independentes capazes de serem executados em paralelo.

O HPA fornece métricas de utilização de recursos por padrão. Você também pode integrar métricas personalizadas ou aproveitar ferramentas como o Dimensionador Automático Controlado por Eventos do Kubernetes (KEDA) (versão prévia). Essas extensões permitem que o HPA tome decisões de dimensionamento com base em várias perspectivas e critérios, fornecendo uma visão mais holística do desempenho do aplicativo. Isso é especialmente útil para aplicativos com requisitos de dimensionamento complexos variados.

Observação

Se a manutenção da alta disponibilidade para seu aplicativo for prioridade máxima, recomendamos deixar um buffer ligeiramente mais alto para o número mínimo de pod para seu HPA para considerar o tempo de dimensionamento.

Dimensionamento automático de Pod Vertical

Implementar o dimensionamento automático de pod vertical é útil para aplicativos com demandas de recursos flutuantes e imprevisíveis. O Dimensionador Automático de Pod Vertical (VPA) permite ajustar solicitações de recursos, incluindo CPU e memória, para pods individuais, permitindo o controle preciso sobre a alocação de recursos. Essa granularidade minimiza o desperdício de recursos e aumenta a eficiência geral da utilização do cluster. O VPA também simplifica o gerenciamento de aplicativos automatizando a alocação de recursos, liberando recursos para tarefas críticas.

Aviso

Você não deve usar o VPA em conjunto com o HPA nas mesmas métricas de CPU ou memória. Essa combinação pode levar a conflitos, pois ambos os dimensionadores automáticos tentam responder às alterações na demanda usando as mesmas métricas. No entanto, você pode usar o VPA para CPU ou memória em conjunto com o HPA para métricas personalizadas para evitar a sobreposição e garantir que cada dimensionador automático se concentre em aspectos distintos do dimensionamento da carga de trabalho.

Observação

O VPA funciona com base em dados históricos. É recomendável aguardar pelo menos 24 horas depois de implantar o VPA antes de aplicar as alterações para dar tempo para coletar dados de recomendação.

Dimensionamento automático de infraestrutura

Dimensionamento automático do cluster

Implementar o dimensionamento automático de cluster é útil se os nós existentes não tiverem capacidade suficiente, pois isso ajudará no dimensionamento e no provisionamento de novos nós.

Ao considerar o dimensionamento automático do cluster, a decisão de quando remover um nó envolve uma compensação entre otimizar a utilização de recursos e garantir a disponibilidade de recursos. A eliminação de nós subutilizados melhora a utilização do cluster, mas pode resultar em novas cargas de trabalho que precisam esperar que os recursos sejam provisionados antes que possam ser implantados. É importante encontrar um equilíbrio entre esses dois fatores que se alinham aos requisitos de cluster e carga de trabalho e definir as configurações de perfil do dimensionador automático de cluster adequadamente.

As configurações de perfil do Dimensionador Automático de Cluster se aplicam universalmente a todos os pools de nós habilitados para dimensionamento automático em seu cluster. Isso significa que todas as ações de dimensionamento que ocorrem em um pool de nós habilitado para dimensionamento automático podem afetar o comportamento de dimensionamento automático em outro pool de nós. É importante aplicar configurações de perfil consistentes e sincronizadas em todos os pools de nós relevantes para garantir que o dimensionador automático se comporte conforme o esperado.

Provisionamento em excesso

O excesso de provisionamento é uma estratégia que ajuda a reduzir o risco de pressão do aplicativo, garantindo que haja um excesso de recursos prontamente disponíveis. Essa abordagem é especialmente útil para aplicativos que experimentam cargas altamente variáveis e padrões de dimensionamento de cluster que mostram escalas e reduções de escala frequentes.

Para determinar a quantidade ideal de superprovisionamento, você pode usar a seguinte fórmula:

1-buffer/1+traffic

Por exemplo, digamos que você queira evitar atingir 100% de utilização da CPU em seu cluster. Você pode optar por um buffer de 30% para manter uma margem de segurança. Se você prever uma taxa média de crescimento de tráfego de 40%, poderá considerar o excesso de provisionamento em 50%, conforme calculado pela fórmula:

1-30%/1+40%=50%

Um método de superprovisionamento eficaz envolve o uso de pods de pausa. Os pods de pausa são implantações de baixa prioridade que podem ser facilmente substituídas por implantações de alta prioridade. Você cria pods de baixa prioridade que servem à única finalidade de reservar espaço em buffer. Quando um pod de alta prioridade requer espaço, os pods de pausa são removidos e reagendados em outro nó ou em um novo nó para acomodar o pod de alta prioridade.

O YAML a seguir mostra um exemplo de manifesto de pod de pausa:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Escala e eficiência do nó

Orientação de melhor prática:

Monitore cuidadosamente as políticas de utilização e agendamento de recursos para garantir que os nós estejam sendo usados com eficiência.

O dimensionamento de nós permite ajustar dinamicamente o número de nós em seu cluster com base nas demandas de carga de trabalho. É importante entender que adicionar mais nós a um cluster nem sempre é a melhor solução para melhorar o desempenho. Para garantir o desempenho ideal, você deve monitorar cuidadosamente as políticas de utilização e agendamento de recursos para garantir que os nós estejam sendo usados com eficiência.

Imagens de nó

Orientação de melhor prática:

Use a versão mais recente da imagem do nó para garantir que você tenha os patches de segurança e correções de bug mais recentes.

Usar a versão mais recente da imagem do nó fornece a melhor experiência de desempenho. O AKS fornece melhorias de desempenho nas versões semanais de imagem. As imagens de daemonset mais recentes são armazenadas em cache na imagem VHD mais recente, que fornece benefícios de latência mais baixos para provisionamento de nó e inicialização. Atrasos na implementação de atualizações podem ter um impacto negativo no desempenho, portanto, é importante evitar grandes lacunas entre as versões.

Azure Linux

O Host de Contêiner do Linux do Azure no AKS usa uma imagem nativa do AKS e fornece um único lugar para o desenvolvimento do Linux. Cada pacote é criado a partir da origem e validado, garantindo que seus serviços sejam executados em componentes comprovados.

O Azure Linux é leve e inclui apenas o conjunto essencial de pacotes necessário para executar cargas de trabalho de contêiner. Ele fornece uma superfície de ataque reduzida e elimina a aplicação de patch e a manutenção de pacotes desnecessários. Na camada base, há um kernel protegido pela Microsoft ajustado para o Azure. Essa imagem é ideal para cargas de trabalho com diferenciação de desempenho e engenheiros de plataforma ou operadores que gerenciam frotas de clusters do AKS.

Ubuntu 2204

A imagem do Ubuntu 2204 é a imagem de nó padrão do AKS. É um sistema operacional leve e eficiente otimizado para executar cargas de trabalho em contêineres. Isso significa que ele pode ajudar a reduzir o uso de recursos e melhorar o desempenho geral. A imagem inclui os patches e atualizações de segurança mais recentes, que ajudam a garantir que suas cargas de trabalho estejam protegidas contra vulnerabilidades.

A imagem do Ubuntu 2204 é totalmente compatível com a Microsoft, a Canonical e a comunidade Ubuntu e pode ajudá-lo a obter melhor desempenho e segurança para suas cargas de trabalho em contêineres.

VMs (máquinas virtuais)

Orientação de melhor prática:

Ao selecionar uma VM, verifique se o tamanho e o desempenho do disco do sistema operacional e da SKU da VM não têm uma discrepância grande. Uma discrepância no tamanho ou no desempenho pode causar problemas de desempenho e contenção de recursos.

O desempenho do aplicativo está intimamente vinculado às SKUs de VM que você usa em suas cargas de trabalho. VMs maiores e mais poderosas geralmente fornecem melhor desempenho. Para cargas de trabalho de missão críticas ou de produto, recomendamos usar VMs com pelo menos uma CPU de 8 núcleos. VMs com gerações de hardware mais recentes, como v4 e v5, também podem ajudar a melhorar o desempenho. Tenha em mente que a latência de criação e escala pode variar dependendo das SKUs de VM usadas.

Use pools de nós de sistema dedicados

Para dimensionar o desempenho e a confiabilidade, recomendamos usar um pool de nós do sistema dedicado. Com essa configuração, o pool de nós do sistema dedicado reserva espaço para recursos críticos do sistema, como daemons do sistema operacional. A carga de trabalho do aplicativo pode ser executada em um pool de nós de usuário para aumentar a disponibilidade de recursos alocáveis para seu aplicativo. Essa configuração também ajuda a reduzir o risco de competição de recursos entre o sistema e o aplicativo.

Criar operações

Examine as extensões e complementos que você habilitou durante o provisionamento de criação. Extensões e complementos podem adicionar latência à duração geral das operações de criação. Se você não precisar de uma extensão ou complemento, recomendamos removê-las para melhorar a latência de criação.

Você também pode usar zonas de disponibilidade para fornecer um nível mais alto de disponibilidade para proteger contra possíveis falhas de hardware ou eventos de manutenção planejada. Os clusters do AKS distribuem recursos entre seções lógicas da infraestrutura subjacente do Azure. As zonas de disponibilidade separam fisicamente nós de outros nós para ajudar a garantir que uma única falha não afete a disponibilidade do aplicativo. As zonas de Disponibilidade estão disponíveis somente em determinadas regiões. Para obter mais informações, confira Zonas de disponibilidade no Azure.

Servidor de API do Kubernetes

Operações LIST e WATCH

O Kubernetes usa as operações LIST e WATCH para interagir com o servidor de API do Kubernetes e monitorar informações sobre recursos de cluster. Essas operações são fundamentais para como o Kubernetes executa o gerenciamento de recursos.

A operação LIST recupera uma lista de recursos que se ajustam a determinados critérios, como todos os pods em um namespace específico ou todos os serviços no cluster. Essa operação é útil quando você deseja obter uma visão geral dos recursos do cluster ou precisa operador em vários recursos ao mesmo tempo.

A operação LIST pode recuperar grandes quantidades de dados, especialmente em clusters grandes com vários recursos. Lembre-se de que fazer chamadas LIST não associadas ou frequentes coloca uma carga significativa no servidor de API e pode fechar os tempos de resposta.

A operação WATCH executa o monitoramento de recursos em tempo real. Quando você configura um WATCH em um recurso, o servidor de API envia atualizações sempre que há alterações nesse recurso. Isso é importante para os controladores, como o controlador ReplicaSet, que dependem do WATCH para manter o estado desejado dos recursos.

Lembre-se de que observar muitos recursos mutáveis ou fazer muitas solicitações WATCH simultâneas pode sobrecarregar o servidor de API e causar consumo excessivo de recursos.

Para evitar possíveis problemas e garantir a estabilidade do plano de controle do Kubernetes, você pode usar as seguintes estratégias:

Cotas de recursos

Implemente cotas de recursos para limitar o número de recursos que podem ser listados ou observados por um determinado usuário ou namespace para evitar chamadas excessivas.

Prioridade e Imparcialidade da API

O Kubernetes introduziu o conceito de Prioridade e Imparcialidade da API (APF) para priorizar e gerenciar solicitações de API. Você pode usar o APF no Kubernetes para proteger o servidor de API do cluster e reduzir o número de respostas HTTP 429 Too Many Requests vistas por aplicativos cliente.

Recurso Personalizado Principais recursos
PriorityLevelConfigurations • Defina diferentes níveis de prioridade para solicitações de API.
• Especifica um nome exclusivo e atribui um valor inteiro que representa o nível de prioridade. Níveis de prioridade mais altos têm valores inteiros mais baixos, indicando que eles são mais críticos.
• Pode usar vários para categorizar solicitações em diferentes níveis de prioridade com base em sua importância.
• Permite que você especifique se as solicitações em um determinado nível de prioridade devem estar sujeitas a limites de taxa.
FlowSchemas • Defina como as solicitações de API devem ser roteada para diferentes níveis de prioridade com base em atributos de solicitação.
• Especifique regras que correspondam às solicitações com base em critérios como grupos de API, versões e recursos.
• Quando uma solicitação corresponde a uma determinada regra, a solicitação é direcionada para o nível de prioridade especificado na PriorityLevelConfiguration associada.
• Pode usar para definir a ordem de avaliação quando vários FlowSchemas corresponderem a uma solicitação para garantir que determinadas regras têm precedência.

Configurar a API com PriorityLevelConfigurations e FlowSchemas permite a priorização de solicitações de API críticas em relação a solicitações menos importantes. Isso garante que as operações essenciais não percam fome ou experimentem atrasos devido a solicitações de prioridade mais baixa.

Otimizar a rotulagem e os seletores

Ao usar operações LIST, otimize os seletores de rótulo para restringir o escopo dos recursos que você deseja consultar para reduzir a quantidade de dados retornados e a carga no servidor de API.

Nas operações CREATE e UPDATE do Kubernetes, consulte as ações que gerenciam e modificam os recursos do cluster.

Operações CREATE e UPDATE

A operação CREATE cria novos recursos no cluster do Kubernetes, como pods, serviços, implantações, configurações e segredos. Durante uma operação CREATE, um cliente, como kubectl ou um controlador, envia uma solicitação ao servidor de API do Kubernetes para criar o novo recurso. O servidor de API valida a solicitação, garante a conformidade com todas as políticas do controlador de admissão e, em seguida, cria o recurso no estado desejado do cluster.

A operação UPDATE modifica os recursos existentes no cluster do Kubernetes, incluindo alterações nas especificações de recursos, como número de réplicas, imagens de contêiner, variáveis de ambiente ou rótulos. Durante uma operação UPDATE, um cliente envia uma solicitação ao servidor de API para atualizar um recurso existente. O servidor de API valida a solicitação, aplica as alterações à definição de recurso e atualiza o recurso de cluster.

As operações CREATE e UPDATE podem afetar o desempenho do servidor de API do Kubernetes nas seguintes condições:

  • Alta simultaneidade: quando vários usuários ou aplicativos fazem solicitações CREATE ou UPDATE simultâneas, isso pode levar a um aumento nas solicitações de API que chegam ao servidor ao mesmo tempo. Isso pode enfatizar a capacidade de processamento do servidor de API e causar problemas de desempenho.
  • Definições de recursos complexas: definições de recursos excessivamente complexas ou que envolvem vários objetos aninhados podem aumentar o tempo necessário para que o servidor de API valide e processe solicitações CREATE e UPDATE, o que pode levar à degradação do desempenho.
  • Validação de recursos e controle de admissão: o Kubernetes impõe várias políticas de controle de admissão e verificações de validação em solicitações CREATE e UPDATE de entrada. Definições de recursos grandes, como as com anotações ou configurações extensas, podem exigir mais tempo de processamento.
  • Controladores personalizados: controladores personalizados que observam as alterações nos recursos, como Implantações ou controladores StatefulSet, podem gerar um número significativo de atualizações ao dimensionar ou distribuir alterações. Essas atualizações podem dificultar os recursos do servidor de API.

Para obter mais informações, consulte Solucionar problemas de servidor de API e de etcd no AKS.

Desempenho do plano de dados

O plano de dados do Kubernetes é responsável por gerenciar o tráfego de rede entre contêineres e serviços. Problemas com o plano de dados podem levar a tempos de resposta lentos, desempenho degradado e tempo de inatividade do aplicativo. É importante monitorar e otimizar cuidadosamente as configurações do plano de dados, como latência de rede, alocação de recursos, densidade de contêiner e políticas de rede, para garantir que seus aplicativos em contêineres sejam executados de forma suave e eficiente.

Tipos de armazenamento

O AKS recomenda e usa como padrão o uso de discos do sistema operacional efêmero. Os discos do sistema operacional efêmero são criados no armazenamento de VM local e não são salvos no armazenamento remoto do Azure, como discos gerenciados do sistema operacional. Eles têm tempos de reimaginação e inicialização mais rápidos, permitindo operações de cluster mais rápidas e fornecem latência de leitura/gravação mais baixa no disco do sistema operacional dos nós do agente do AKS. Os discos do SO efêmero funcionam bem para cargas de trabalho sem estado, onde os aplicativos são tolerantes a falhas individuais de VM, mas não ao tempo de implantação de VM ou a instâncias individuais de recriação de imagem de VM. Somente determinadas SKUs de VM dão suporte a discos efêmeros do sistema operacional, portanto, você precisa garantir que a geração e o tamanho de SKU desejados sejam compatíveis. Para obter mais informações, consulte discos do sistema operacional efêmero no Serviço de Kubernetes do Azure (AKS).

Se a carga de trabalho não puder usar discos do sistema operacional efêmero, o AKS usará discos do sistema operacional SSD Premium. Se os discos do sistema operacional SSD Premium não forem compatíveis com sua carga de trabalho, o AKS usará como padrão discos SSD Standard. Atualmente, o único outro tipo de disco do sistema operacional disponível é o HDD Standard. Para obter mais informações, consulte Opções de armazenamento para aplicativos no Serviço de Kubernetes do Azure (AKS).

A tabela a seguir fornece um detalhamento dos casos de uso sugeridos para discos do sistema operacional com suporte no AKS:

Tipo de disco de SO Principais recursos Casos de uso sugeridos
Discos do SO Efêmero • Tempos de reimaginação e inicialização mais rápidos.
• Latência de leitura/gravação mais baixa no disco do sistema operacional de nós do agente do AKS.
• Alto desempenho e disponibilidade.		 • Cargas de trabalho corporativas exigentes, como SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite etc.
• Cargas de trabalho de produção sem estado que exigem alta disponibilidade e baixa latência.
Discos do sistema operacional SSD Premium • Desempenho consistente e baixa latência.
• Alta disponibilidade.		 • Cargas de trabalho corporativas exigentes, como SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite etc.
• Cargas de trabalho corporativas intensivas de E/S (entrada/saída).
Discos do sistema operacional SSD Standard • Desempenho consistente.
• Melhor disponibilidade e latência em comparação com discos HDD Standard.		 • Servidores Web.
• Baixos servidores de aplicativos IOPS (operações de entrada/saída por segundo).
• Aplicativos empresariais levemente usados.
• Cargas de trabalho de desenvolvimento/teste.
Discos HDD Standard • Baixo custo.
• Exibe variabilidade no desempenho e na latência.		 • Armazenamento de backup.
• Armazenamento em massa com acesso pouco frequente.

IOPS e taxa de transferência

As operações de entrada/saída por segundo (IOPS) referem-se ao número de operações de leitura e gravação que um disco pode executar em um segundo. A taxa de transferência refere-se à quantidade de dados que podem ser transferidos em um determinado período.

Os discos do sistema operacional são responsáveis por armazenar o sistema operacional e seus arquivos associados, e as VMs são responsáveis pela execução dos aplicativos. Ao selecionar uma VM, verifique se o tamanho e o desempenho do disco do sistema operacional e da SKU da VM não têm uma discrepância grande. Uma discrepância no tamanho ou no desempenho pode causar problemas de desempenho e contenção de recursos. Por exemplo, se o disco do sistema operacional for significativamente menor que as VMs, ele poderá limitar a quantidade de espaço disponível para os dados do aplicativo e fazer com que o sistema fiquem sem espaço em disco. Se o disco do sistema operacional tiver um desempenho menor que as VMs, ele poderá se tornar um gargalo e limitar o desempenho geral do sistema. Verifique se o tamanho e o desempenho estão equilibrados para garantir o desempenho ideal no Kubernetes.

Você pode usar as seguintes etapas para monitorar IOPS e medidores de largura de banda em discos do sistema operacional no portal do Azure:

  1. Navegue até o Portal do Azure.
  2. Pesquise Conjuntos de dimensionamento de máquinas virtuais e selecione seu conjunto de dimensionamento de máquinas virtuais.
  3. Em Monitoramento, selecione Métricas.

Os discos do sistema operacional efêmero podem fornecer IOPS dinâmico e taxa de transferência para seu aplicativo, enquanto os discos gerenciados têm IOPS e taxa de transferência limitadas. Para obter mais informações, consulte Discos do sistema operacional efêmero para VMs do Azure.

O SSD Premium v2 do Azure foi projetado para cargas de trabalho corporativas intensas em E/S que exigem latências de disco de submilissegundos e alta IOPS e taxa de transferência a um custo baixo. Ele é adequado para uma ampla gama de cargas de trabalho, como SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/análise, jogos e muito mais. Esse tipo de disco é a opção de maior desempenho atualmente disponível para volumes persistentes.

Agendamento de pods

Os recursos de memória e CPU alocados para uma VM têm um impacto direto no desempenho dos pods em execução na VM. Quando um pod é criado, ele recebe uma determinada quantidade de recursos de memória e CPU, que são usados para executar o aplicativo. Se a VM não tiver recursos suficientes de memória ou CPU disponíveis, isso poderá fazer com que os pods diminuam ou até mesmo falhem. Se a VM tiver muita memória ou recursos de CPU disponíveis, isso poderá fazer com que os pods sejam executados de forma ineficiente, desperdiçando recursos e aumentando os custos. Recomendamos monitorar o total de solicitações de pod em suas cargas de trabalho em relação ao total de recursos alocáveis para melhor agendamento de previsão e desempenho. Defina o máximo de pods por nó com base no planejamento da capacidade por meio de --max-pods.