Editar

Share via


Gestão de custos do Kubernetes

Azure Cost Management
Azure Kubernetes Service (AKS)
Azure Managed Disks
Azure Storage
Azure Virtual Machines

Este guia explica como funcionam os preços e a gestão de custos no Azure Kubernetes Service (AKS) em comparação com o Amazon Elastic Kubernetes Service (Amazon EKS). O artigo descreve como otimizar os custos e implementar soluções de governação de custos para o cluster do AKS.

Nota

Este artigo faz parte de uma série de artigos que ajudam os profissionais que estão familiarizados com o Amazon EKS a compreender o AKS.

Noções básicas sobre os custos do Amazon EKS

No Amazon EKS, paga um preço fixo por hora por cada cluster do Amazon EKS. Também paga a rede, as ferramentas de operações e o armazenamento que o cluster utiliza.

Os nós de trabalho do Amazon EKS são instâncias padrão do Amazon EC2, pelo que incorrem em preços regulares do Amazon EC2. Também paga outros recursos do Amazon Web Services (AWS) que aprovisiona para executar os nós de trabalho do Kubernetes.

Não existem custos adicionais para utilizar grupos de nós geridos do Amazon EKS. Paga apenas pelos recursos do AWS que aprovisiona, incluindo instâncias do Amazon EC2, volumes amazon EBS, horas de cluster do Amazon EKS e qualquer outra infraestrutura do AWS.

Ao criar um grupo de nós geridos, pode optar por utilizar o tipo de capacidade Instâncias a Pedido ou Spot para gerir o custo dos nós do agente. O Amazon EKS implementa um grupo de nós geridos com um grupo de Dimensionamento Automático Amazon EC2 que contém todas as Instâncias a Pedido ou todas as Instâncias Spot.

Com as Instâncias a Pedido, paga a capacidade de computação até ao segundo, sem compromissos a longo prazo. O Amazon EC2 Spot Instances poupa capacidade amazon EC2 que oferece descontos em comparação com os preços a Pedido.

  • O Amazon EC2 Spot Instances pode ser interrompido com um aviso de interrupção de dois minutos quando o EC2 precisar da capacidade de volta.

  • A Amazon fornece o Spot Fleet, um método para automatizar grupos de Instâncias a Pedido e Spot, e o Spot Instance Advisor para ajudar a prever que região ou Zona de Disponibilidade podem fornecer interrupções mínimas.

  • Os preços do AWS Spot Instance variam. O AWS define o preço consoante as tendências de oferta e procura a longo prazo para a capacidade da Instância Spot e paga o preço em vigor durante o período de tempo em que a instância subiu.

Noções básicas de custos do AKS

A arquitetura do Kubernetes baseia-se em duas camadas, o plano de controlo e um ou mais nós ou conjuntos de nós. O modelo de preços do AKS baseia-se nas duas camadas de arquitetura do Kubernetes.

  • O plano de controlo fornece serviços principais do Kubernetes, como o servidor de API e etcda orquestração da carga de trabalho da aplicação. A plataforma do Azure gere o plano de controlo do AKS e, para o escalão gratuito do AKS, o plano de controlo não tem custos.

  • Os nós, também denominados nós de agente ou nós de trabalho, alojam cargas de trabalho e aplicações do Kubernetes. No AKS, os clientes gerem e pagam todos os custos pelos nós do agente.

O diagrama seguinte mostra a relação entre o plano de controlo e os nós numa arquitetura do AKS Kubernetes.

Diagrama que mostra o plano de controlo e os nós na arquitetura do AKS.

Plano de controlo

O Azure aprovisiona e configura automaticamente a camada do plano de controlo quando cria um cluster do AKS. Para o escalão Gratuito do AKS, o plano de controlo é gratuito.

Para um contrato de nível de serviço (SLA) de plano de controlo superior, pode criar um cluster do AKS no escalão Standard. O SLA de tempo de atividade está incluído por predefinição no escalão Standard e está ativado por cluster. O preço é de $0,10 por cluster por hora. Para obter mais informações, veja Detalhes de preços do AKS.

Os clusters no escalão Standard têm mais recursos do plano de controlo, como o número de instâncias do servidor de API, limites de recursos etc., escalabilidade até 5000 nós e o suporte de SLA de Uptime com suporte financeiro. O AKS utiliza réplicas de nós principais em domínios de atualização e falha para cumprir os requisitos de disponibilidade.

É melhor utilizar o escalão Standard em cargas de trabalho de produção para fornecer uma maior disponibilidade do componente do plano de controlo. Os clusters de escalão gratuito têm menos réplicas e recursos de planos de controlo limitados e não são recomendados para cargas de trabalho de produção.

Nós

No AKS, cria nós de agente ou de trabalho num ou mais conjuntos de nós, que podem utilizar muitas capacidades principais do Azure no ambiente do Kubernetes. Custos do AKS apenas para os nós anexados ao cluster do AKS.

Os nós do AKS utilizam vários recursos de infraestrutura do Azure, incluindo conjuntos de dimensionamento de máquinas virtuais, redes virtuais e discos geridos. Por exemplo, pode utilizar a maioria dos tipos de máquina virtual (VM) do Azure diretamente no AKS. Pode utilizar o plano de poupança do Azure Reservations e do Azure para computação para obter descontos significativos nestes recursos.

Os preços do cluster do AKS baseiam-se na classe, número e tamanho das VMs nos conjuntos de nós. O custo da VM depende do tamanho, tipo de CPU, número de vCPUs, memória, família e tipo de armazenamento disponíveis, como SSD de alto desempenho ou HDD padrão. Para obter mais informações, veja Virtual Machine Series (Série de Máquinas Virtuais). Planeie o tamanho do nó de acordo com os requisitos da aplicação, o número de nós e as necessidades de escalabilidade do cluster.

Para obter mais informações sobre nós de agente e conjuntos de nós, veja o artigo Conjuntos de nós nesta série e Criar e gerir múltiplos conjuntos de nós para um cluster no Azure Kubernetes Service (AKS).

Implementação do cluster do AKS

Cada implementação do AKS abrange dois grupos de recursos do Azure.

  • Pode criar o primeiro grupo de recursos, que contém apenas o recurso do serviço Kubernetes e não tem custos associados ao mesmo.

  • O fornecedor de recursos do AKS cria automaticamente o segundo ou grupo de recursos de nós durante a implementação. O nome predefinido para este grupo de recursos é MC_<resourcegroupname>_<clustername>_<location>, mas pode especificar outro nome. Para obter mais informações, consulte Fornecer o meu próprio nome para o grupo de recursos de nós do AKS.

    O grupo de recursos do nó contém todos os recursos de infraestrutura do cluster e é aquele que mostra os custos para a sua subscrição. Os recursos incluem as VMs do nó do Kubernetes, redes virtuais, armazenamento e outros serviços. O AKS elimina automaticamente o grupo de recursos do nó quando o cluster é eliminado, pelo que deve utilizá-lo apenas para recursos que partilham o ciclo de vida do cluster.

Custos de computação

Paga as VMs do Azure de acordo com o respetivo tamanho e utilização. Para obter informações sobre como a computação do Azure se compara ao AWS, veja Compute services on Azure and AWS (Serviços de computação no Azure e no AWS).

Geralmente, quanto maior for o tamanho da VM selecionado para um conjunto de nós, maior será o custo por hora para os nós do agente. Quanto mais especializada for a série de VMs que utiliza para o conjunto de nós, por exemplo, a unidade de processamento gráfico (GPU) ativada ou otimizada para memória, mais caro será o conjunto.

Ao investigar os preços da VM do Azure, tenha em atenção os seguintes pontos:

  • Os preços diferem por região e nem todos os serviços e tamanhos de VM estão disponíveis em todas as regiões.

  • Existem várias famílias de VMs otimizadas para diferentes tipos de cargas de trabalho.

  • Os discos geridos utilizados como unidades de SO são cobrados separadamente e tem de adicionar os custos às suas estimativas. O tamanho do disco gerido depende da classe, como HDDs Standard, SSDs Standard, SSDs Premium ou SSDs Ultra. As operações de saída de entrada por segundo (IOPS) e o débito em MB/seg dependem do tamanho e da classe. Os discos de SO efémero são gratuitos e estão incluídos no preço da VM.

  • Os discos de dados, incluindo os criados com afirmações de volume persistentes, são opcionais e são cobrados individualmente com base na respetiva classe, como HDDs Standard, SSDs Standard, SSDs Premium e SSDs Ultra. Tem de adicionar explicitamente discos de dados a estimativas de custos. O número de discos de dados permitidos, SSDs de armazenamento temporário, IOPS e débito em MB/seg depende do tamanho e classe da VM.

  • Quanto mais tempo os nós de agente estiverem em execução, maior será o custo total do cluster. Normalmente, os ambientes de desenvolvimento não precisam de ser executados continuamente.

  • As interfaces de rede (NICs) são gratuitas.

Custos de armazenamento

A Interface de Armazenamento de Contentores (CSI) é uma norma para expor sistemas de armazenamento de ficheiros e blocos a cargas de trabalho em contentores no Kubernetes. Ao adotar e utilizar o CSI, o AKS pode escrever, implementar e iterar plug-ins que expõem sistemas de armazenamento do Kubernetes sem tocar no código principal do Kubernetes ou aguardar pelos ciclos de lançamento.

Se executar cargas de trabalho que utilizam volumes persistentes csi no cluster do AKS, considere o custo associado do armazenamento que as suas aplicações aprovisionam e utilizam. Os controladores de armazenamento CSI no AKS fornecem suporte nativo para as seguintes opções de armazenamento:

  • O Azure Disks cria recursos do disco de dados do Kubernetes. Os discos podem utilizar Armazenamento Premium do Azure, apoiados por SSDs de alto desempenho ou Armazenamento Standard do Azure, apoiados por HDDs regulares ou SSDs Standard. A maioria das cargas de trabalho de produção e desenvolvimento utiliza Armazenamento Premium. Os discos do Azure são montados como ReadWriteOnce, o que os torna disponíveis apenas para um nó do AKS. Para volumes de armazenamento aos quais vários pods podem aceder em simultâneo, utilize Ficheiros do Azure. Para obter informações sobre custos, veja Managed Disks preços.

  • Ficheiros do Azure monta partilhas de ficheiros do bloco de mensagens do servidor (SMB) 3.0/3.1 apoiadas por uma conta de Armazenamento do Azure em pods do AKS. Pode partilhar dados em vários nós e pods. Ficheiros do Azure pode utilizar o armazenamento Standard suportado por HDDs normais ou armazenamento Premium suportado por SSDs de alto desempenho. Ficheiros do Azure utiliza uma conta de Armazenamento do Azure e acumula custos com base nos seguintes fatores:

    • Serviço: Blob, Ficheiro, Fila, Tabela ou discos não geridos
    • Tipo de conta de armazenamento: GPv1, GPv2, Blob ou Blob Premium
    • Resiliência: armazenamento localmente redundante (LRS), armazenamento com redundância entre zonas (ZRS), armazenamento georredundante (GRS) ou armazenamento georredundante com acesso de leitura (RA-GRS)
    • Camada de acesso: Frequente, esporádico ou arquivo
    • Operações e transferências de dados
    • Capacidade utilizada em GB
  • Azure NetApp Files está disponível em vários escalões de SKU e requer uma capacidade mínima aprovisionada de 4 TiB, com incrementos de 1 TiB. Azure NetApp Files custos baseiam-se nos seguintes fatores:

    • SKU
    • Resiliência: LRS, ZRS ou GRS
    • Tamanho ou capacidade aprovisionada, não capacidade utilizada
    • Operações e transferência de dados
    • Cópias de segurança e restauros

Custos de redes

Vários serviços de rede do Azure podem fornecer acesso às suas aplicações executadas no AKS:

  • Balanceador de Carga do Azure. Por predefinição, Balanceador de Carga utiliza o SKU Standard. Balanceador de Carga custos são baseados em:

    • Regras: o número de regras de balanceamento de carga e saída configuradas. As regras de tradução de endereços de rede (NAT) de entrada não contam no número total de regras.
    • Dados processados: a quantidade de dados processados de entrada e saída, independentemente das regras. Não existem custos por hora para Balanceador de Carga Standard sem regras configuradas.
  • Gateway de Aplicação do Azure. O AKS utiliza frequentemente Gateway de Aplicação através do Controlador de Entrada Gateway de Aplicação ou ao fazer frente a um controlador de entrada diferente com Gateway de Aplicação geridos manualmente. Gateway de Aplicação suporta o encaminhamento do gateway, a terminação de segurança de camada de transporte (TLS) e a funcionalidade Firewall de Aplicações Web (WAF). Gateway de Aplicação custos são baseados em:

    • Preço fixo definido por hora ou hora parcial.
    • Preço unitário de capacidade, um custo baseado no consumo adicionado. Cada unidade de capacidade tem, no máximo, uma unidade de computação, 2500 ligações persistentes e débito de 2,22 Mbps.
  • Os endereços IP públicos têm um custo associado que depende de:

    • Associação reservada vs. dinâmica.
    • Escalão Standard básico vs. seguro e com redundância entre zonas.

Custos de aumento horizontal

Existem várias opções para dimensionar um cluster do AKS para adicionar capacidade extra aos conjuntos de nós:

  • A pedido, pode atualizar manualmente o número de VMs que fazem parte de um conjunto de nós ou adicionar mais conjuntos de nós.

  • O dimensionador automático do cluster do AKS observa pods que não podem ser agendados em nós devido a restrições de recursos e aumenta automaticamente o número de nós.

  • O AKS suporta a execução de contentores no Azure Container Instances através da implementação do kubelet virtual. Um nó virtual do AKS aprovisiona Container Instances pods que começam em segundos, permitindo que o AKS seja executado com capacidade suficiente para uma carga de trabalho média. À medida que o cluster do AKS fica sem capacidade, pode aumentar horizontalmente mais Container Instances pods sem gerir servidores adicionais. Pode combinar esta abordagem com o dimensionador automático de clusters e o dimensionamento manual.

Se utilizar o dimensionamento a pedido ou o dimensionador automático do cluster, tenha em conta as VMs adicionadas. Container Instances custos baseiam-se nos seguintes fatores:

  • Faturação de métricas baseada na utilização por grupo de contentores
  • VCPU e memória da coleção
  • Utilização de contentor único ou partilha de vários contentores
  • Utilização de contentores co-agendados que partilham o ciclo de vida da rede e do nó
  • Duração da utilização calculada a partir do início ou reinício da solicitação da imagem até parar
  • Custo adicionado para grupos de contentores do Windows

Custos de atualização

Parte do ciclo de vida do cluster do AKS envolve atualizações periódicas para a versão mais recente do Kubernetes. É importante aplicar as versões de segurança mais recentes e obter as funcionalidades mais recentes. Pode atualizar clusters do AKS e conjuntos de nós únicos manual ou automaticamente. Para obter mais informações, veja Atualizar um cluster do Azure Kubernetes Service (AKS).

Por predefinição, o AKS configura as atualizações para o pico com um nó extra. Um valor predefinido de 1 para a definição minimiza a max-surge interrupção da carga de trabalho ao criar um nó extra para substituir nós com versões mais antigas antes de isolar ou drenar aplicações existentes. Pode personalizar o max-surge valor por conjunto de nós para permitir uma troca entre a velocidade de atualização e a interrupção da atualização. Aumentar o max-surge valor conclui o processo de atualização mais rapidamente, mas um grande valor para max-surge pode causar interrupções durante o processo de atualização e incorrer em custos adicionais para VMs adicionais.

Outros custos

Consoante a utilização e os requisitos, os clusters do AKS podem incorrer nos seguintes custos adicionais:

Otimização de custos

As seguintes recomendações ajudam-no a otimizar os custos do cluster do AKS:

  • Reveja a secção Otimização de custos do Azure Well-Architected Framework para AKS.

  • Para soluções multi-inquilino, o isolamento físico é mais dispendioso e adiciona uma sobrecarga de gestão. O isolamento lógico requer mais experiência do Kubernetes e aumenta a área de superfície para alterações e ameaças de segurança, mas partilha os custos.

  • As Reservas do Azure podem ajudá-lo a poupar ao comprometer-se com planos de um ou três anos para vários produtos, como as VMs no cluster do AKS. Obtém descontos ao reservar capacidade. Utilize as Reservas do Azure para Armazenamento e Computação para reduzir o custo dos nós de agente.

    As reservas podem reduzir os custos dos recursos até 72% dos preços pay as you go e não afetam o estado de tempo de execução dos seus recursos. Depois de comprar uma reserva, o desconto é aplicado automaticamente aos recursos correspondentes. Pode comprar reservas no portal do Azure ou com as APIs REST do Azure, o PowerShell ou a CLI do Azure. Se utilizar ferramentas operacionais que dependem de áreas de trabalho do Log Analytics, considere também utilizar Reservas para este armazenamento.

  • Adicione um ou mais conjuntos de nós spot ao cluster do AKS. Um conjunto de nós spot é um conjunto de nós apoiado pelo Azure Spot Conjuntos de Dimensionamento de Máquinas Virtuais. A utilização de VMs spot para os nós de cluster do AKS tira partido da capacidade do Azure não utilizada com uma poupança de custos significativa. A quantidade de capacidade não utilizada disponível varia com base em vários fatores, incluindo o tamanho do nó, a região e a hora do dia. O Azure aloca os nós spot se existir capacidade disponível, mas não existe nenhum SLA para nós spot. Um conjunto de dimensionamento spot que suporta o conjunto de nós spot é implementado num único domínio de falha e não oferece garantias de elevada disponibilidade. Quando o Azure precisa da capacidade de volta, a infraestrutura do Azure expulsa os nós spot.

    Quando cria um conjunto de nós spot, pode definir o preço máximo a pagar por hora e ativar o dimensionador automático do cluster, que é recomendado para conjuntos de nós spot. O dimensionador automático do cluster aumenta horizontalmente e aumenta horizontalmente o número de nós no conjunto de nós com base nas cargas de trabalho em execução. Para conjuntos de nós spot, o dimensionador automático do cluster aumenta horizontalmente o número de nós após uma expulsão se os nós ainda forem necessários. Para obter mais informações, veja Adicionar um conjunto de nós spot a um cluster de Azure Kubernetes Service (AKS).

  • Escolha o tamanho certo da VM para os conjuntos de nós de cluster do AKS com base nas necessidades de CPU e memória das cargas de trabalho. O Azure oferece muitos tipos de instâncias de VM diferentes que correspondem a uma vasta gama de casos de utilização, com diferentes combinações de CPU, memória, armazenamento e capacidade de rede. Cada tipo tem um ou mais tamanhos, pelo que pode dimensionar facilmente os seus recursos.

    Agora, pode implementar e gerir aplicações em contentores com o AKS em execução em processadores baseados em Arm do Ampere Altra. Para obter mais informações, veja Azure Máquinas Virtuais com processadores baseados em ARM do Ampere Altra.

  • Crie múltiplos conjuntos de nós com diferentes tamanhos de VM para fins especiais e cargas de trabalho. Utilize taints e tolerâncias do Kubernetes e etiquetas de nós para colocar aplicações com muitos recursos em conjuntos de nós específicos para evitar problemas de vizinhos ruidosos. Mantenha estes recursos de nó disponíveis para cargas de trabalho que os exijam e não agende outras cargas de trabalho nestes nós. A utilização de diferentes tamanhos de VM para diferentes conjuntos de nós também pode otimizar os custos. Para obter mais informações, veja Utilizar múltiplos conjuntos de nós no Azure Kubernetes Service (AKS).

  • Os conjuntos de nós no modo de sistema têm de conter, pelo menos, um nó, enquanto os conjuntos de nós no modo de utilizador podem conter zero ou mais nós. Sempre que possível, pode configurar um conjunto de nós no modo de utilizador para dimensionar automaticamente de 0 para N nós. Pode configurar as cargas de trabalho para aumentar horizontalmente e aumentar horizontalmente com um dimensionador automático de pods horizontal. Dimensionamento automático base na CPU e na memória ou utilize o Dimensionamento Automático Orientado por Eventos do Kubernetes (KEDA) para basear o dimensionamento automático nas métricas de um sistema externo, como o Apache Kafka, RabbitMQ ou Azure Service Bus.

  • Certifique-se de que define corretamente os pedidos e limites dos pods para melhorar a densidade da aplicação e evite atribuir demasiados recursos de CPU e memória às suas cargas de trabalho. Observe o consumo médio e máximo da CPU e da memória com o Prometheus ou o Container Insights. Configure corretamente limites e quotas para os pods nos manifestos YAML, gráficos Helm e manifestos kustomize para as suas implementações.

  • Utilize objetos ResourceQuota para definir quotas para a quantidade total de memória e CPU para todos os pods em execução num determinado espaço de nomes. A utilização sistemática de quotas de recursos evita problemas de vizinhos ruidosos, melhora a densidade da aplicação e reduz o número de nós de agente e os custos totais. Utilize também objetos LimitRange para configurar os pedidos predefinidos de CPU e memória para pods num espaço de nomes.

  • Utilize Container Instances para rebentar.

  • As cargas de trabalho do AKS poderão não precisar de ser executadas continuamente, como cargas de trabalho específicas em conjuntos de nós do cluster de desenvolvimento. Para otimizar os custos, pode desativar completamente um cluster do AKS ou parar um ou mais conjuntos de nós no cluster do AKS. Para obter mais informações, veja Parar e iniciar um cluster do Azure Kubernetes Service (AKS) e Iniciar e parar um conjunto de nós no Azure Kubernetes Service (AKS).

  • Azure Policy integra-se no AKS através de políticas incorporadas para aplicar medidas e salvaguardas centralizadas, consistentes e em escala. Ative o suplemento Azure Policy no cluster e aplique os pedidos e limites predefinidos da CPU e os limites de recursos de memória, que garantem que os limites de recursos de CPU e memória são definidos em contentores de cluster.

  • Utilize o Assistente do Azure para monitorizar e libertar recursos não utilizados.

  • Utilize orçamentos e revisões do Microsoft Cost Management para controlar as despesas.

Governação de custos

A cloud pode melhorar significativamente o desempenho técnico das cargas de trabalho empresariais. As tecnologias de cloud também podem reduzir o custo e a sobrecarga da gestão de recursos organizacionais. No entanto, esta oportunidade de negócio também cria riscos, uma vez que as implementações na cloud podem aumentar o potencial de desperdício e ineficiências.

A governação de custos é o processo de implementação contínua de políticas ou controlos para limitar os gastos e os custos. As ferramentas nativas do Kubernetes e as ferramentas do Azure suportam a governação de custos com monitorização proativa e otimização dos custos da infraestrutura subjacente.

  • O Azure Cost Management + Faturação é um conjunto de ferramentas da Microsoft que o ajuda a analisar, gerir e otimizar os custos da carga de trabalho do Azure. Utilize o conjunto de aplicações para ajudar a garantir que a sua organização está a tirar partido dos benefícios que a cloud proporciona.

  • Reveja as melhores práticas de governação Cloud Adoption Framework da Disciplina de Gestão de Custos para compreender melhor como gerir e gerir os custos da cloud.

  • Explore ferramentas open source, como o KubeCost , para monitorizar e gerir os custos do cluster do AKS. Pode definir o âmbito da alocação de custos para uma implementação, serviço, etiqueta, pod e espaço de nomes, o que proporciona flexibilidade na apresentação e carregamento de utilizadores do cluster.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuintes.

Autores principais:

Outros contribuidores:

Para ver perfis do LinkedIn não públicos, inicie sessão no LinkedIn.

Passos seguintes