Partilhar via

Práticas recomendadas para desempenho e dimensionamento para cargas de trabalho pequenas e médias no Serviço Kubernetes do Azure (AKS)

  • Artigo

Nota

Este artigo se concentra nas práticas recomendadas gerais para cargas de trabalho pequenas e médias. Para obter práticas recomendadas específicas para grandes cargas de trabalho, consulte Práticas recomendadas de desempenho e dimensionamento para grandes cargas de trabalho no Serviço Kubernetes do Azure (AKS).

Ao implantar e manter clusters no AKS, você pode usar as seguintes práticas recomendadas para ajudá-lo a otimizar o desempenho e o dimensionamento.

Neste artigo, você aprende sobre:

  • Compensações e recomendações para dimensionar automaticamente suas cargas de trabalho.
  • Gerenciando o dimensionamento e a eficiência do nó com base em suas demandas de carga de trabalho.
  • Considerações de rede para tráfego de entrada e saída.
  • Monitoramento e solução de problemas de desempenho do plano 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 de aplicativos

O dimensionamento automático de aplicativos é útil ao lidar com otimização de custos ou limitações de infraestrutura. Um autoscaler bem configurado mantém a alta disponibilidade para sua aplicação e, ao mesmo tempo, minimiza 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 IPs suficientes na sub-rede, ele poderá ignorar a criação de um novo nó e, em vez disso, começar imediatamente a executar o aplicativo em um novo pod.

Autodimensionamento horizontal do pod

A implementação do dimensionamento automático de pods horizontais é útil para aplicativos com uma demanda de recursos constante e previsível. O Horizontal Pod Autoscaler (HPA) dimensiona dinamicamente o número de réplicas de pods, o que distribui efetivamente a carga entre vários pods e nós. Esse mecanismo de dimensionamento normalmente é mais benéfico para aplicações que podem ser decompostas em componentes menores e independentes capazes de funcionar em paralelo.

O HPA fornece métricas de utilização de recursos por padrão. Você também pode integrar métricas personalizadas ou alavancar ferramentas como o Kubernetes Event-Driven Autoscaler (KEDA) (Preview). Essas extensões permitem que a HPA tome decisões de dimensionamento com base em várias perspetivas e critérios, fornecendo uma visão mais holística do desempenho do seu aplicativo. Isso é especialmente útil para aplicativos com requisitos de dimensionamento complexos variados.

Nota

Se manter a alta disponibilidade para seu aplicativo for uma prioridade máxima, recomendamos deixar um buffer um pouco maior para o número mínimo de pod para seu HPA para levar em conta o tempo de dimensionamento.

Dimensionamento automático de pods verticais

A implementação do dimensionamento automático de pod vertical é útil para aplicativos com demandas de recursos flutuantes e imprevisíveis. O Vertical Pod Autoscaler (VPA) permite ajustar solicitações de recursos, incluindo CPU e memória, para pods individuais, permitindo um 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, já que ambos os autoscalers tentam responder a mudanças 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 sobreposições e garantir que cada dimensionador automático se concentre em aspetos distintos do dimensionamento da carga de trabalho.

Nota

O APV funciona com base em dados históricos. Recomendamos aguardar pelo menos 24 horas após a implantação do VPA antes de aplicar quaisquer alterações para dar tempo de coletar dados de recomendação.

Dimensionamento automático de infraestrutura

Dimensionamento automático de cluster

A implementação do dimensionamento automático de cluster é útil se os nós existentes não tiverem capacidade suficiente, pois ajuda na expansão e no provisionamento de novos nós.

Ao considerar o dimensionamento automático de 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 tendo que esperar que os recursos sejam provisionados antes de poderem ser implantados. É importante encontrar um equilíbrio entre esses dois fatores que se alinhe com os requisitos do cluster e da carga de trabalho e configurar as configurações do perfil do autoscaler do cluster de acordo.

As configurações do perfil do Autoscaler de cluster aplicam-se universalmente a todos os pools de nós habilitados para autoscaler em seu cluster. Isso significa que quaisquer ações de dimensionamento que ocorram em um pool de nós habilitado para autoscaler 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 autoscaler se comporte conforme o esperado.

Provisionamento excessivo

O provisionamento excessivo é 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 aumentos e reduções de escala frequentes.

Para determinar a quantidade ideal de provisionamento excessivo, 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ê prevê uma taxa média de crescimento de tráfego de 40%, pode considerar o provisionamento excessivo em 50%, conforme calculado pela fórmula:

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

Um método eficaz de superprovisionamento 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 ao único propósito de reservar espaço no buffer. Quando um pod de alta prioridade requer espaço, os pods de pausa são removidos e reprogramados 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

Dimensionamento e eficiência de nós

Orientações sobre boas práticas:

Monitore cuidadosamente a utilização de recursos e as políticas de agendamento para garantir que os nós estejam sendo usados de forma eficiente.

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 a utilização de recursos e as políticas de agendamento para garantir que os nós estejam sendo usados de forma eficiente.

Imagens de nó

Orientações sobre boas práticas:

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

Usar a versão mais recente da imagem do nó oferece a melhor experiência de desempenho. O AKS envia melhorias de desempenho dentro dos lançamentos semanais de imagens. As imagens daemonset mais recentes são armazenadas em cache na imagem VHD mais recente, o que oferece benefícios de latência mais baixa para provisionamento e inicialização de nós. Ficar para trás nas atualizações pode ter um impacto negativo no desempenho, por isso é importante evitar grandes lacunas entre as versões.

Azure Linux

O Azure Linux Container Host no AKS usa uma imagem AKS nativa e fornece um único local para o desenvolvimento Linux. Todos os pacotes são criados a partir da origem e validados, garantindo que seus serviços sejam executados em componentes comprovados.

O Azure Linux é leve, incluindo apenas o conjunto necessário de pacotes para executar cargas de trabalho de contêiner. Ele fornece uma superfície de ataque reduzida e elimina a aplicação de patches e a manutenção de pacotes desnecessários. Em sua camada base, ele tem um kernel protegido pela Microsoft ajustado para o Azure. Esta imagem é ideal para cargas de trabalho sensíveis ao desempenho e engenheiros de plataforma ou operadores que gerenciam frotas de clusters AKS.

Ubuntu 2204

A imagem do Ubuntu 2204 é a imagem de nó padrão para 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 suportada pela Microsoft, Canonical e pela comunidade Ubuntu e pode ajudá-lo a alcançar um melhor desempenho e segurança para suas cargas de trabalho em contêineres.

Máquinas virtuais (VMs)

Orientações sobre boas práticas:

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 grande discrepância. Uma discrepância no tamanho ou no desempenho pode causar problemas de desempenho e contenção de recursos.

O desempenho do aplicativo está intimamente ligado às SKUs de VM que você usa em suas cargas de trabalho. VMs maiores e mais poderosas, geralmente oferecem melhor desempenho. Para cargas de trabalho de missão crítica ou de produtos, recomendamos o uso de VMs com pelo menos uma CPU de 8 núcleos. As VMs com gerações de hardware mais recentes, como v4 e v5, também podem ajudar a melhorar o desempenho. Lembre-se de que a latência de criação e dimensionamento pode variar dependendo das SKUs de VM que você usa.

Usar pools de nós do sistema dedicados

Para dimensionar o desempenho e a confiabilidade, recomendamos o uso de um pool de nós de 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

Revise as extensões e complementos que você habilitou durante o provisionamento de criação. Extensões e complementos podem adicionar latência à duração total das operações de criação. Se você não precisar de uma extensão ou complemento, recomendamos removê-lo 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 AKS distribuem recursos entre seções lógicas da infraestrutura subjacente do Azure. As zonas de disponibilidade separam fisicamente os nós de outros nós para ajudar a garantir que uma única falha não afete a disponibilidade do seu aplicativo. As zonas de disponibilidade só estão disponíveis em determinadas regiões. Para obter mais informações, consulte Zonas de disponibilidade no Azure.

Servidor da 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 a forma como o Kubernetes executa o gerenciamento de recursos.

A operação LIST recupera uma lista de recursos que se encaixam em 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 operar vários recursos ao mesmo tempo.

A operação LIST pode recuperar grandes quantidades de dados, especialmente em grandes clusters com vários recursos. Esteja ciente do fato de que fazer chamadas LIST ilimitadas ou frequentes coloca uma carga significativa no servidor de API e pode reduzir os tempos de resposta.

A operação WATCH realiza 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 controladores, como o controlador ReplicaSet, que dependem do WATCH para manter o estado desejado de recursos.

Esteja ciente do fato de que assistir a 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:

Quotas 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 equidade da API

O Kubernetes introduziu o conceito de API Priority and Fairness (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 HTTP 429 Too Many Requests respostas vistas pelos aplicativos cliente.

Recurso personalizado Funcionalidades principais
PriorityLevelConfigurations • Definir 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 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.
• Permitir que você especifique se as solicitações em um determinado nível de prioridade devem estar sujeitas a limites de tarifa.
FluxoEsquemas • Definir como as solicitações de API devem ser roteadas para diferentes níveis de prioridade com base nos 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 no PriorityLevelConfiguration associado.
• Pode usar para definir a ordem de avaliação quando vários FlowSchemas correspondem a uma solicitação para garantir que certas regras tenham precedência.

A configuração da API com PriorityLevelConfigurations e FlowSchemas permite a priorização de solicitações críticas de API sobre solicitações menos importantes. Isso garante que as operações essenciais não passem fome ou sofram atrasos devido a solicitações de prioridade mais baixa.

Otimize 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.

No Kubernetes, as operações CREATE e UPDATE referem-se a ações que gerenciam e modificam recursos de cluster.

Operações CREATE e UPDATE

A operação CREATE cria novos recursos no cluster Kubernetes, como pods, serviços, implantações, configmaps 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 quaisquer políticas de controlador de admissão e, em seguida, cria o recurso no estado desejado do cluster.

A operação UPDATE modifica recursos existentes no cluster 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 simultâneas de CREATE ou UPDATE, isso pode levar a um aumento nas solicitações de API que chegam ao servidor ao mesmo tempo. Isso pode sobrecarregar a capacidade de processamento do servidor de API e causar problemas de desempenho.
  • Definições de recursos complexas: as definições de recursos que são excessivamente complexas ou envolvem vários objetos aninhados podem aumentar o tempo necessário para o servidor de API validar e processar solicitações CREATE e UPDATE, o que pode levar à degradação do desempenho.
  • Validação de recursos e controle de admissão: o Kubernetes aplica várias políticas de controle de admissão e verificações de validação em solicitações CREATE e UPDATE recebidas. Grandes definições de recursos, como aquelas com anotações ou configurações extensas, podem exigir mais tempo de processamento.
  • Controladores personalizados: controladores personalizados que observam alterações nos recursos, como Implantações ou controladores StatefulSet, podem gerar um número significativo de atualizações ao dimensionar ou implementar alterações. Essas atualizações podem sobrecarregar os recursos do servidor de API.

Para obter mais informações, consulte Solucionar problemas do servidor de API e 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êineres e políticas de rede, para garantir que seus aplicativos em contêineres funcionem sem problemas e com eficiência.

Tipos de armazenamento

O AKS recomenda e padroniza o uso de discos efêmeros do sistema operacional. Os discos efêmeros do sistema operacional são criados no armazenamento de VM local e não são salvos no armazenamento remoto do Azure, como os discos gerenciados do sistema operacional. Eles têm tempos de recriação de imagens e inicialização mais rápidos, permitindo operações de cluster mais rápidas, e fornecem menor latência de leitura/gravação no disco do sistema operacional dos nós do agente AKS. Os discos de SO efêmeros funcionam bem para cargas de trabalho sem monitoração de estado, em que os aplicativos são tolerantes a falhas de VM individuais, mas não ao tempo de implantação da VM ou a instâncias individuais de recriação de imagens de VM. Apenas alguns SKUs de VM suportam discos de SO efêmeros, 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 Kubernetes do Azure (AKS).

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

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

Tipo de disco do SO Funcionalidades principais Casos de uso sugeridos
Discos de SO Efémeros • Recriação de imagens e tempos de arranque mais rápidos.
• Menor latência de leitura/gravação no disco do sistema operacional dos nós do agente 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 de SO 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 empresariais intensivas de entrada/saída (IO).
Discos de SO SSD padrão • Desempenho consistente.
• Melhor disponibilidade e latência em comparação com discos HDD padrão.		 • Servidores Web.
• Servidores de aplicações de baixas operações de entrada/saída por segundo (IOPS).
• Aplicações empresariais pouco utilizadas.
• Cargas de trabalho de desenvolvimento/teste.
Discos HDD padrão • Baixo custo.
• Apresenta variabilidade no desempenho e latência.		 • Armazenamento de backup.
• Armazenamento em massa com acesso pouco frequente.

IOPS e taxa de transferência

Operações de entrada/saída por segundo (IOPS) refere-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 de tempo.

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 grande discrepância. 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 do que as VMs, ele poderá limitar a quantidade de espaço disponível para dados do aplicativo e fazer com que o sistema fique sem espaço em disco. Se o disco do sistema operacional tiver um desempenho inferior ao das VMs, ele pode se tornar um gargalo e limitar o desempenho geral do sistema. Certifique-se de que o tamanho e o desempenho estejam 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 para o portal do Azure.
  2. Pesquise conjuntos de dimensionamento de máquina virtual e selecione seu conjunto de dimensionamento de máquina virtual.
  3. Em Monitorização, selecione Métricas.

Os discos de SO efêmeros podem fornecer IOPS dinâmicas 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 efêmeros do sistema operacional para VMs do Azure.

O SSD Premium do Azure v2 foi projetado para cargas de trabalho empresariais intensas de E/S que exigem latências de disco inferiores a milissegundos e IOPS e taxa de transferência altas a um baixo custo. É adequado para uma ampla gama de cargas de trabalho, como SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/analytics, jogos e muito mais. Esse tipo de disco é a opção de melhor 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, é atribuída uma certa quantidade de recursos de memória e CPU, que são usados para executar o aplicativo. Se a VM não tiver memória suficiente ou recursos de CPU disponíveis, isso pode fazer com que os pods diminuam a velocidade ou até mesmo falhem. Se a VM tiver muita memória ou recursos de CPU disponíveis, isso pode 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 previsibilidade e desempenho de agendamento. Você também pode definir o máximo de pods por nó com base no seu planejamento de capacidade usando --max-podso .