Editar

Compartilhar via

Gerenciamento de custos para Kubernetes

Gerenciamento de Custos do Azure
AKS (Serviço de Kubernetes do Azure)
Azure Managed Disks
Armazenamento do Azure
Máquinas Virtuais do Azure

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

Observação

Este artigo faz parte de uma série de artigos que ajudam profissionais familiarizados com o Amazon EKS a entender o Serviço Azure Kubernetes (AKS).

Noções básicas de custo do Amazon EKS

No Amazon EKS, você paga um preço fixo por hora para cada cluster do Amazon EKS. Você também paga pela rede, pelas ferramentas de operações e pelo armazenamento que o cluster usa.

Os nós de trabalho do Amazon EKS são instâncias padrão do Amazon EC2, portanto, incorrem em preços regulares do Amazon EC2. Você também paga por outros recursos da Amazon Web Services (AWS) provisionados para executar seus nós de trabalho do Kubernetes.

Não há custos adicionais para usar grupos de nós gerenciados do Amazon EKS. Você paga apenas pelos recursos do AWS provisionados, incluindo instâncias do Amazon EC2, volumes do Amazon EBS, horas de cluster do Amazon EKS e qualquer outra infraestrutura do AWS.

Ao criar um grupo de nós gerenciados, você pode optar por usar o tipo de capacidade de Instâncias sob Demanda ou Instâncias Spot para gerenciar o custo dos nós do agente. O Amazon EKS implanta um grupo de nós gerenciados com um Grupo de dimensionamento automático do Amazon EC2 que contém todas as instâncias sob demanda ou todas as instâncias spot.

Com instâncias sob demanda, você paga pela capacidade de computação por segundo, sem compromissos de longo prazo. As instâncias spot do Amazon EC2 são a capacidade sobressalente do Amazon EC2 que oferece descontos em comparação com os preços sob demanda.

  • As instâncias spot do Amazon EC2 podem ser interrompidas 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 sob demanda e Spot, e o Spot Instance Advisor para ajudar a prever qual região ou zona de disponibilidade pode fornecer interrupção mínima.

  • Os preços da Instância Spot do AWS variam. O AWS define o preço dependendo das tendências de oferta e demanda de longo prazo para a capacidade da Instância Spot, e você paga o preço em vigor pelo período de tempo em que a instância estiver ativa.

Análise de custo do Serviço de Kubernetes do Azure

Um cluster do Serviço de Kubernetes do Azure (AKS) depende de vários recursos do Azure, como máquinas virtuais, discos virtuais, balanceadores de carga e endereços IP. Esses recursos podem ser utilizados por vários aplicativos, que podem ser gerenciados por diferentes equipes dentro de uma organização. Os padrões de consumo desses recursos podem variar, resultando em uma contribuição variável para o custo total dos recursos do cluster. Além disso, alguns aplicativos podem ter pegadas em vários clusters, tornando a atribuição de custos e o gerenciamento um desafio.

Para cenários em que um cluster contém uma única carga de trabalho, o Microsoft Cost Management pode ser usado para medir o consumo de recursos do cluster no grupo de recursos do cluster. No entanto, alguns cenários não são cobertos nativamente por essa solução isoladamente, por exemplo:

  • Detalhamento granular do uso de recursos, como computação, rede e armazenamento.
  • Distinção entre custos de aplicação individuais e custos compartilhados.
  • Análise de custos em vários clusters no mesmo escopo de assinatura.

Para aumentar a observabilidade de custos, o AKS integrou-se ao Microsoft Cost Management para fornecer detalhamentos de custos em construções do Kubernetes, como cluster e namespace. Essa integração permite a análise de custos nas categorias de computação, rede e armazenamento do Azure.

O add-on de análise de custo do AKS é construído no OpenCost, um projeto de código aberto para coleta de dados de uso. Ele fornece visibilidade de custo reconciliando dados com sua fatura do Azure. Os dados pós-processados são diretamente visíveis no portal de análise de custos de Gerenciamento de Custos. Para obter mais informações, confira análise de custo do Serviço de Kubernetes do Azure.

Definições de custo

Nas exibições de namespaces e ativos do Kubernetes, você verá as cobranças, como:

  • Preços ociosos: representa o custo da capacidade de recurso disponível que não foi usada por nenhuma carga de trabalho.
  • Taxas de serviço: representa as cobranças associadas a serviços como o contrato de nível de serviço (SLA) de tempo de atividade e o Microsoft Defender para contêineres.
  • Encargos do sistema: Representa o custo da capacidade reservada pelo AKS em cada nó para executar os processos do sistema exigidos pelo cluster.
  • Preços não alocados: representa o custo dos recursos que não puderam ser alocados para namespaces.

Noções básicas de custo do AKS

A arquitetura do Kubernetes é baseada em duas camadas, o plano de controle e um ou mais nós ou pools de nós. O modelo de preços do AKS é baseado nas duas camadas de arquitetura do Kubernetes.

  • O plano de controle fornece serviços principais do Kubernetes, como o servidor API e etcd, e orquestração de carga de trabalho de aplicativos. A plataforma Azure gerencia o plano de controle AKS e, para a camada gratuita do AKS, o plano de controle não tem custo.

  • Os nós, também chamados de nós de agente ou nós de trabalho, hospedam cargas de trabalho e aplicativos do Kubernetes. No AKS, os clientes gerenciam e pagam totalmente todos os custos pelos nós do agente.

O diagrama a seguir mostra a relação entre o plano de controle e os nós em uma arquitetura AKS Kubernetes.

Diagrama que mostra o painel de controle e os nós na arquitetura AKS.

Painel de controle

O Azure provisiona e configura automaticamente a camada do plano de controle quando você cria um cluster AKS. Para a camada gratuita do AKS, o plano de controle é gratuito.

Para um contrato de nível de serviço (SLA) com plano de controle mais alto, você pode criar um cluster AKS na camada Standard. O SLA de tempo de atividade está incluído por padrão na camada Standard e é habilitado por cluster. O preço é US$ 0,10 por cluster por hora. Para obter mais informações, confira Detalhes de preços do AKS.

Os clusters na camada Standard têm mais recursos do plano de controle, como o número de instâncias do servidor de API, limites de recursos do Etcd, escalabilidade de até 5.000 nós e o suporte existente ao SLA de tempo de atividade com suporte financeiro. O AKS usa réplicas de nó principal em domínios de atualização e falha para atender aos requisitos de disponibilidade.

É melhor usar a camada Standard em cargas de trabalho de produção para fornecer maior disponibilidade de componentes do plano de controle. Os clusters de camada gratuita têm menos réplicas e recursos limitados do plano de controle e não são recomendados para cargas de trabalho de produção.

Nós

No AKS, você cria nós de agente ou de trabalho em um ou mais pools de nós, que podem usar muitos recursos principais do Azure no ambiente do Kubernetes. Você paga apenas pelos nós anexados ao cluster do AKS.

Os nós do AKS usam muitos recursos da infraestrutura do Azure, incluindo conjuntos de dimensionamento de máquinas virtuais, redes virtuais e discos gerenciados. Por exemplo, você pode usar a maioria dos tipos de máquina virtual (VM) do Azure diretamente no AKS. Você pode usar as Reservas do Azure e o plano de economia do Azure para computação para obter descontos significativos nesses recursos.

O preço do cluster AKS é baseado na classe, no número e no tamanho das VMs nos pools de nós. O custo da VM depende do tamanho, do tipo de CPU, do número de vCPUs, da memória, da família e do tipo de armazenamento disponível, como SSD (unidade de estado sólido) de alto desempenho ou HD padrão. Para obter mais informações, confira Séries de máquina virtual. Planeje o tamanho do nó de acordo com os requisitos do aplicativo, o número de nós e as necessidades de escalabilidade do cluster.

Para obter mais informações sobre nós de agente e pools de nós, consulte o artigo Pools de nós nesta série e Criar e gerenciar vários pools de nós para um cluster no Serviço de Kubernetes do Azure (AKS).

Implantação de cluster do AKS

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

  • Você cria o primeiro grupo de recursos, que contém apenas o recurso de serviço do Kubernetes e não tem custos associados a ele.

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

    O grupo de recursos de nó contém todos os recursos de infraestrutura de cluster e é aquele que mostra os encargos para sua assinatura. Os recursos incluem as máquinas virtuais do nó do Kubernetes, rede virtual, armazenamento e outros serviços. O AKS exclui automaticamente o grupo de recursos de nó quando o cluster é excluído e, portanto, só deve ser usado para os recursos que compartilham o ciclo de vida do cluster.

Custos de computação

Você paga por VMs do Azure de acordo com seu tamanho e uso. Para obter informações sobre como a computação do Azure se compara ao AWS, consulte Serviços de computação no Azure e no AWS.

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

Ao investigar os preços da VM do Azure, esteja ciente dos 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.

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

  • Os discos gerenciados usados como unidades do SO são cobrados separadamente, e você deve adicionar o custo às suas estimativas. O tamanho do disco gerenciado depende da classe, como HDs padrão, SSDs padrão, SSDs Premium ou Armazenamento de Disco Ultra. As operações de entrada-saída por segundo (IOPS) e a taxa de transferência em MB/s dependem do tamanho e da classe. Os discos efêmeros do SO são gratuitos e estão incluídos no preço da VM.

  • Os discos de dados, incluindo aqueles criados com declarações de volume persistentes, são opcionais e são cobrados individualmente com base na sua classe, como HDs padrão, SSDs padrão, SSDs Premium e Armazenamento de Disco Ultra. Você deve adicionar explicitamente discos de dados às estimativas de custo. O número de discos de dados permitidos, SSDs de armazenamento temporário, IOPS e taxa de transferência em MB/s dependem do tamanho e da classe da VM.

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

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

Custos de armazenamento

A Interface de Armazenamento de Contêiner (CSI) é um padrão para expor sistemas de blocos e de armazenamento de arquivos a cargas de trabalho em contêineres no Kubernetes. Ao adotar e utilizar o CSI, o AKS pode escrever, implementar e iterar plug-ins que expõem os sistemas de armazenamento Kubernetes sem tocar no código principal do Kubernetes ou esperar pelos seus ciclos de lançamento.

Se você executar cargas de trabalho que usam volumes persistentes de CSI no seu cluster do AKS, considere o custo associado do armazenamento que seus aplicativos provisionam e usam. Os drivers de armazenamento de CSI no AKS fornecem suporte nativo para as seguintes opções de armazenamento:

  • Os Discos do Azure criam recursos de disco de dados do Kubernetes. Os discos podem usar o Armazenamento Premium do Azure, apoiados por SSDs de alto desempenho, ou o Armazenamento Standard do Azure, apoiado por HDDs regulares ou SSDs Standard. A maioria das cargas de trabalho de produção e desenvolvimento usa Armazenamento Premium. Os discos do Azure são montados como ReadWriteOnce, o que os torna disponíveis para apenas um nó do AKS. Para volumes de armazenamento que podem ser acessados simultaneamente por vários pods, use os Arquivos do Azure. Para obter informações sobre custo, consulte Preços do Managed Disks.

  • Os Arquivos do Azure montam compartilhamentos de arquivos de bloco de mensagens do servidor (SMB) 3.0/3.1 com suporte de uma conta de Armazenamento do Azure em pods do AKS. Você pode compartilhar dados em vários nós e pods. Os Arquivos do Azul podem usar o Armazenamento Standard do Azure apoiado por SSDs de alto desempenho ou o Armazenamento Standard apoiado por HDDs comuns. Os Arquivos do Azure usam uma conta de Armazenamento do Azure e cobram com base nos seguintes fatores:

    • Serviço: Blob, Arquivo, Fila, Tabela ou discos não gerenciados
    • Tipo de conta de armazenamento: GPv1, GPv2, Blob ou Blob Premium
    • Resiliência: armazenamento com redundância local (LRS), armazenamento com redundância de zona (ZRS), armazenamento com redundância geográfica (GRS) ou armazenamento com redundância geográfica com acesso de leitura (RA-GRS)
    • Camada de acesso: frequente, esporádica ou de arquivos
    • Operações e transferências de dados
    • Capacidade usada em GB

  • O Azure NetApp Files está disponível em várias camadas de SKU e requer uma capacidade provisionada mínima de 4 TiB, com incrementos de 1 TiB. As cobranças do Azure NetApp Files são baseadas nos seguintes fatores:

    • SKU
    • Resiliência: LRS, ZRS ou GRS
    • Tamanho ou capacidade provisionada, não capacidade usada
    • Operações e transferência de dados
    • Backups e restaurações

Custos de rede

Vários serviços de rede do Azure podem fornecer acesso aos seus aplicativos executados no AKS:

  • Azure Load Balancer. Por padrão, o Load Balancer usa SKU padrão. Os encargos do Load Balancer são baseados em:

    • Regras: o número de regras de saída e balanceamento de carga configuradas. As regras de conversã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 na entrada e na saída não depende das regras. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra está configurada.

  • Gateway de Aplicativo do Azure. O AKS geralmente usa o Gateway de Aplicativo por meio do Controlador de Entrada do Gateway de Aplicativo ou fazendo frente a um controlador de entrada diferente com o Gateway de Aplicativo gerenciado manualmente. O Gateway de Aplicativo oferece suporte ao roteamento de gateway, à terminação TLS e à funcionalidade Firewall de Aplicativo Web. As cobranças do Gateway de Aplicativo são baseadas em:

    • Preço fixo definido por hora ou hora parcial.
    • Preço unitário da capacidade, um custo adicional baseado no consumo. Cada unidade de capacidade tem no máximo uma unidade de computação, 2.500 conexões persistentes e taxa de transferência de 2,22 Mbps.

  • Endereços IP públicos têm um custo associado que depende de:

    • associação reservada x associação dinâmica.
    • Camada Standard básica x segura e com redundância de zona.

Custos de expansão

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

  • Sob demanda, você pode atualizar manualmente o número de VMs que fazem parte de um pool de nós ou adicionar mais pools de nós.

  • O dimensionador automático de 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 dá suporte à execução de contêineres em Instâncias de Contêiner do Azure usando a implementação de kubelet virtual. Um nó virtual do AKS provisiona pods de instâncias de contêiner que começam em segundos, permitindo que o AKS seja executado com capacidade suficiente para uma carga de trabalho média. Como o cluster do AKS fica sem capacidade, você pode expandir mais pods de instâncias de contêiner sem gerenciar nenhum servidor adicional. Você pode combinar essa abordagem com o dimensionamento automático do cluster e o dimensionamento manual.

Se você usar o dimensionamento sob demanda ou o dimensionador automático de cluster, leve em conta as VMs adicionadas. As cobranças de instâncias de contêiner são baseadas nos seguintes fatores:

  • Faturamento de métricas baseadas em uso por grupo de contêineres
  • Coleção vCPU e memória
  • Uso de contêiner único ou compartilhamento de vários contêineres
  • Uso de contêineres coagendados que compartilham o ciclo de vida da rede e do nó
  • Duração de uso calculada a partir do pull da imagem ou reinicialização até a parada
  • Cobrança adicional para grupos de contêineres do Windows

Custos de atualização

Parte do ciclo de vida do cluster do AKS envolve a execução de atualizações periódicas para a última versão do Kubernetes. É importante aplicar as últimas versões de segurança e obter os recursos mais recentes. Você pode atualizar clusters do AKS e pools de nó único manual ou automaticamente. Para obter mais informações, confira Atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

Por padrão, o AKS configura as atualizações para atingirem um pico com um nó extra. Um valor padrão de 1 para a configuração max-surge minimiza a interrupção da carga de trabalho criando um nó extra para substituir nós com versões mais antigas antes de isolar ou esgotar os aplicativos existentes. Você pode personalizar o valor de max-surge por pool de nós para permitir um equilíbrio entre velocidade e interrupção de atualização. Aumentar o valor de max-surge conclui o processo de atualização mais rapidamente, mas um valor grande para max-surge pode causar interrupções durante o processo de atualização e incorrer em custos adicionais para VMs extras.

Outros custos

Dependendo do uso e dos requisitos, os clusters do AKS podem incorrer nos seguintes custos adicionais:

Otimização de custo

As recomendações a seguir ajudam a otimizar os custos do cluster do AKS:

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

  • Para soluções multilocatário, o isolamento físico é mais caro e adiciona sobrecarga de gerenciamento. O isolamento lógico requer mais experiência do Kubernetes e aumenta a área de superfície para alterações e ameaças à segurança, mas compartilha os custos.

  • As Reservas do Azure podem ajudá-lo a economizar dinheiro comprometendo-se com planos de um ou três anos para vários produtos, como as VMs em seu cluster do AKS. Você obtém descontos reservando capacidade. Use as reservas do Azure para Armazenamento e Computação para reduzir o custo dos nós do agente.

    As reservas podem reduzir seus custos de recursos em até 72% em relação aos preços pagos conforme o uso e não afetam o estado de tempo de execução de seus recursos. Após você comprar uma reserva, o desconto se aplica automaticamente aos recursos correspondentes. Você pode comprar reservas no portal do Azure ou usando as APIs REST do Azure, o PowerShell ou a CLI do Azure. Se você usa ferramentas operacionais que dependem de workspaces do Log Analytics, considere usar Reservas para esse armazenamento também.

  • Adicione um ou mais pools de nós spot ao cluster do AKS. Um pool de nós spot é apoiado por Conjuntos de dimensionamento de máquinas virtuais do Azure Spot. A utilização de VMs spot para seus nós de cluster do AKS aproveita a capacidade não utilizada do Azure com poupanças de custos significativas. A quantidade de capacidade disponível não utilizada varia com base em muitos fatores, como região, hora do dia e tamanho do nó. O Azure alocará os nós spot se houver capacidade disponível, mas não há SLA para nós spot. Um conjunto de dimensionamento de spot que apoia o pool de nós spot é implantado em um domínio de falha único e não oferece garantias de alta disponibilidade. Quando o Azure precisa da capacidade de volta, a infraestrutura do Azure despeja os nós spot.

    Ao criar um pool de nós spot, você pode definir o preço máximo a pagar por hora e habilitar o dimensionador automático de cluster, que é recomendado para pools de nós spot. O dimensionador automático de cluster aumenta e aumenta o número de nós no pool de nós com base nas cargas de trabalho em execução. Para pools de nós spot, o dimensionador automático de cluster escalará horizontalmente o número de nós após uma remoção se mais nós ainda forem necessários. Para obter mais informações, consulte Adicionar um pool de nós spot a um cluster do Serviço de Kubernetes do Azure (AKS).

  • Escolha o tamanho de VM certo para seus pools de nós de cluster do AKS com base nas necessidades de CPU e memória de suas cargas de trabalho. O Azure oferece muitos tipos de instância de VM diferentes que correspondem a uma ampla variedade de casos de uso, com diferentes combinações de CPU, memória, armazenamento e capacidade de rede. Cada tipo vem em um ou mais tamanhos, para que você possa facilmente dimensionar seus recursos.

    Agora você pode implantar e gerenciar aplicativos conteinerizados com AKS em execução em processadores baseados em ARM Ampere Altra. Para obter mais informações, veja Máquinas Virtuais do Azure com processadores baseados em ARM Ampere Altra.

  • Crie vários pools de nós com diferentes tamanhos de VM para fins especiais e cargas de trabalho. Use taints e tolerâncias do Kubernetes e rótulos de nós para colocar aplicativos com uso intensivo de recursos em pools de nós específicos e evitar problemas de vizinhos barulhentos. Mantenha esses recursos de nó disponíveis para cargas de trabalho que os exigem e não programe outras cargas de trabalho nesses nós. Usar tamanhos de VM diferentes para pools de nós diferentes também pode otimizar os custos. Para obter mais informações, consulte Usar vários pools de nós no Serviço de Kubernetes do Azure (AKS).

  • Os pools de nós no modo do sistema devem conter pelo menos um nó, e os pools de nós no modo de usuário podem conter zero ou mais nós. Sempre que possível, você pode configurar um pool de nós no modo de usuário para dimensionar automaticamente de 0 para N nós. Você pode configurar suas cargas de trabalho para dimensionar horizontal e verticalmente usando um Dimensionador Automático de Pod Horizontal. Baseie o dimensionamento automático na CPU e na memória ou use o KEDA (Kubernetes Event-driven Autoscaling) para basear o dimensionamento automático nas métricas de um sistema externo, como Apache Kafka, RabbitMQ ou Barramento de Serviço do Azure.

  • Defina corretamente solicitações e limites para seus pods para melhorar a densidade do aplicativo e evitar atribuir muitos recursos de CPU e memória às suas cargas de trabalho. Observe o consumo médio e máximo de CPU e memória usando a solução Prometheus ou Insights de contêiner. Configure corretamente limites e cotas para seus pods nos manifestos YAML, gráficos Helm e manifestos Kustomize para suas implantações.

  • Use objetos ResourceQuota para definir cotas para a quantidade total de memória e CPU para todos os pods que estão sendo executados em um determinado namespace. O uso sistemático de cotas de recursos evita problemas de vizinhos barulhentos, melhora a densidade de aplicativos e reduz o número de nós de agente e os custos totais. Use também objetos LimitRange para configurar as solicitações padrão de CPU e memória para pods em um namespace.

  • Use Instâncias de Contêiner para bursting.

  • Suas cargas de trabalho do AKS talvez não precisem ser executadas continuamente, como cargas de trabalho específicas em pools de nós de cluster de desenvolvimento. Para otimizar os custos, você pode desativar completamente um cluster do AKS ou parar um ou mais pools de nós no cluster do AKS. Para obter mais informações, consulte Parar e iniciar um cluster do Serviço de Kubernetes do Azure (AKS) e Iniciar e parar um pool de nós no Serviço de Kubernetes do Azure (AKS).

  • A Política do Azure integra-se ao AKS por meio de políticas incorporadas para aplicar imposições e salvaguardas centralizadas, consistentes e em escala. Habilite o complemento Política do Azure no seu cluster e aplique as solicitações e limites de CPU padrão e os limites de recursos de memória, que garantem que os limites de recursos de CPU e memória sejam definidos em contêineres de cluster.

  • Use o Assistente do Azure para monitorar e liberar recursos não utilizados.

  • Use orçamentos e revisões do Gerenciamento de Custos da Microsoft para acompanhar as despesas.

Governança de custos

A nuvem pode melhorar significativamente o desempenho técnico das cargas de trabalho empresariais. As tecnologias de nuvem também podem reduzir o custo e a sobrecarga do gerenciamento de ativos organizacionais. No entanto, essa oportunidade de negócios também cria riscos, porque as implantações em nuvem podem aumentar o potencial de desperdício e ineficiências.

A governança de custos é o processo de implementação contínua de políticas ou controles para limitar gastos e custos. As ferramentas nativas do Kubernetes e do Azure oferecem suporte à governança de custos com monitoramento proativo e otimização de custos de infraestrutura subjacente.

  • O Gerenciamento de Custos da Microsoft é um conjunto de ferramentas da Microsoft que ajuda você a analisar, gerenciar e otimizar os custos das cargas de trabalho do Azure. Use o conjunto para ajudar a garantir que a organização aproveite ao máximo os benefícios fornecidos pela nuvem.

  • Analise as práticas recomendadas de governança do Cloud Adoption Framework para a Disciplina de Gerenciamento de Custos para entender melhor como gerenciar e controlar os custos de nuvem.

  • Explore ferramentas de código aberto como KubeCost para monitorar e controlar o custo do cluster do AKS. Você pode criar o escopo da alocação de custo para uma implantação, serviço, rótulo, pod ou namespace, o que oferece flexibilidade na cobrança ou na exibição de usuários do cluster.

Material de referência

Aqui estão alguns materiais de referência que podem ajudá-lo a entender melhor e utilizar a análise de custos do AKS:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

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

Próximas etapas