Práticas recomendadas para executar aplicações Kubernetes otimizadas em termos de custos no GKE

Last reviewed 2024-09-11 UTC

Este documento aborda as funcionalidades e as opções do Google Kubernetes Engine (GKE), bem como as práticas recomendadas para executar aplicações otimizadas em termos de custos no GKE, de modo a tirar partido da elasticidade fornecida pela Google Cloud. Este documento pressupõe que tem conhecimentos sobre o Kubernetes, Google Cloud, o GKE e a escala automática.

Introdução

À medida que o Kubernetes ganha uma adoção generalizada, um número crescente de empresas e fornecedores de plataforma como serviço (PaaS) e software como serviço (SaaS) está a usar clusters do Kubernetes multi-inquilino para as respetivas cargas de trabalho. Isto significa que um único cluster pode estar a executar aplicações que pertencem a diferentes equipas, departamentos, clientes ou ambientes. A multi-tenancy fornecida pelo Kubernetes permite que as empresas geram alguns clusters grandes, em vez de vários mais pequenos, com vantagens como a utilização adequada de recursos, o controlo de gestão simplificado e a fragmentação reduzida.

Ao longo do tempo, algumas destas empresas com clusters do Kubernetes em rápido crescimento começam a ter um aumento desproporcionado nos custos. Isto acontece porque as empresas tradicionais que adotam soluções baseadas na nuvem, como o Kubernetes, não têm programadores nem operadores com experiência na nuvem. Esta falta de preparação para a nuvem faz com que as aplicações fiquem instáveis durante o dimensionamento automático (por exemplo, a volatilidade do tráfego durante um período normal do dia), os picos ou os aumentos repentinos (como anúncios de TV ou eventos de pico de escala, como a Black Friday e a Cyber Monday). Na tentativa de "corrigir" o problema, estas empresas tendem a aprovisionar em excesso os respetivos clusters da mesma forma que faziam num ambiente não elástico. O aprovisionamento excessivo resulta numa alocação de CPU e memória consideravelmente superior à que as aplicações usam durante a maior parte do dia.

Este documento fornece práticas recomendadas para executar cargas de trabalho do Kubernetes otimizadas em função dos custos no GKE. O diagrama seguinte descreve esta abordagem.

A abordagem à otimização de aplicações Kubernetes em função do custo.

A base da criação de aplicações otimizadas em função dos custos é a disseminação da cultura de poupança de custos entre as equipas. Além de mover as discussões sobre custos para o início do processo de desenvolvimento, esta abordagem força-o a compreender melhor o ambiente em que as suas aplicações estão a ser executadas, neste contexto, o ambiente do GKE.

Para alcançar um custo baixo e a estabilidade da aplicação, tem de definir ou ajustar corretamente algumas funcionalidades e configurações (como o dimensionamento automático, os tipos de máquinas e a seleção da região). Outra consideração importante é o tipo de carga de trabalho porque, consoante o tipo de carga de trabalho e os requisitos da sua aplicação, tem de aplicar configurações diferentes para reduzir ainda mais os custos. Por último, tem de monitorizar os seus gastos e criar restrições para poder aplicar as práticas recomendadas no início do ciclo de desenvolvimento.

A tabela seguinte resume os desafios que o GKE ajuda a resolver. Embora seja recomendável ler o documento completo, esta tabela apresenta um mapa do que está abrangido.

Desafio Ação
Quero analisar poupanças de custos fáceis no GKE. Selecione a região adequada, inscreva-se nos descontos de utilização garantida e use tipos de máquinas E2.
Preciso de compreender os meus custos do GKE. Observe os seus clusters do GKE e procure recomendações, e ative a medição da utilização do GKE
Quero tirar o máximo partido da elasticidade do GKE para as minhas cargas de trabalho existentes. Leia sobre a escala automática horizontal de pods, o redimensionador automático de cluster e compreenda as práticas recomendadas para o redimensionador automático e o aprovisionamento excessivo.
Quero usar os tipos de máquinas mais eficientes. Escolha o tipo de máquina certo para a sua carga de trabalho.
Muitos nós no meu cluster estão inativos. Leia as práticas recomendadas para o Cluster Autoscaler.
Preciso de melhorar a poupança de custos nos meus trabalhos em lote. Leia as práticas recomendadas para cargas de trabalho em lote.
Preciso de melhorar as poupanças de custos nas minhas cargas de trabalho de publicação. Leia as práticas recomendadas para servir cargas de trabalho.
Não sei como dimensionar os meus pedidos de recursos de pods. Use a escala automática vertical de pods (VPA), mas preste atenção às práticas recomendadas para misturar a escala automática horizontal de pods (HPA) e a VPA.
As minhas aplicações estão instáveis durante as atividades de escalabilidade automática e manutenção. Prepare aplicações baseadas na nuvem para o Kubernetes e compreenda como funciona o Metrics Server e como monitorizá-lo.
Como posso fazer com que os meus programadores prestem atenção à utilização de recursos das respetivas aplicações? Dissemine a cultura de redução de custos, considere usar o Policy Controller do GKE Enterprise, conceba o seu pipeline de CI/CD para aplicar práticas de redução de custos e use quotas de recursos do Kubernetes.
Que outros aspetos devo considerar para reduzir ainda mais os custos do meu ecossistema? Reveja pequenos clusters de desenvolvimento, reveja as suas estratégias de registo e monitorização e reveja o tráfego de saída entre regiões em clusters regionais e multizonais.

Funcionalidades e opções de otimização de custos do GKE

As aplicações Kubernetes otimizadas em termos de custos dependem fortemente do redimensionamento automático do GKE. Para equilibrar o custo, a fiabilidade e o desempenho de escalabilidade no GKE, tem de compreender como funciona a escalabilidade automática e que opções tem. Esta secção aborda o ajuste de escala automático do GKE e outras configurações úteis otimizadas em termos de custos para cargas de trabalho de fornecimento e em lote.

Otimize a escala automática do GKE

O dimensionamento automático é a estratégia que o GKE usa para permitir que os Google Cloud clientes paguem apenas pelo que precisam, minimizando o tempo de atividade da infraestrutura. Por outras palavras, a escala automática poupa custos 1) fazendo com que as cargas de trabalho e a respetiva infraestrutura subjacente comecem antes de a procura aumentar e 2) encerrando-as quando a procura diminui.

O diagrama seguinte ilustra este conceito. No Kubernetes, as suas cargas de trabalho são aplicações em contentores que estão a ser executadas em Pods. Além disso, a infraestrutura subjacente, que é composta por um conjunto de nós, tem de fornecer capacidade de computação suficiente para executar as cargas de trabalho.

A escala automática poupa custos 1) fazendo com que as cargas de trabalho e a respetiva infraestrutura subjacente comecem antes de a procura aumentar e 2) encerrando-as quando a procura diminui.

Conforme mostra o diagrama seguinte, este ambiente tem quatro dimensões de escalabilidade. A carga de trabalho e a infraestrutura podem ser dimensionadas horizontalmente adicionando e removendo Pods ou nós, e podem ser dimensionadas verticalmente aumentando e diminuindo o tamanho dos Pods ou dos nós.

As quatro dimensões de escalabilidade de um ambiente otimizado em função dos custos.

O GKE processa estes cenários de escala automática através de funcionalidades como as seguintes:

O diagrama seguinte ilustra estes cenários.

Usando os cenários de HPA, VPA, CA e aprovisionamento automático de nós.

O resto desta secção aborda estas capacidades de escalamento automático do GKE de forma mais detalhada e abrange outras configurações úteis otimizadas em termos de custos para cargas de trabalho de publicação e em lote.

Redimensionador automático horizontal de pods

O redimensionador automático horizontal de pods (HPA) destina-se a dimensionar aplicações que estão a ser executadas em pods com base em métricas que expressam a carga. Pode configurar a utilização da CPU ou outras métricas personalizadas (por exemplo, pedidos por segundo). Em resumo, o HPA adiciona e elimina réplicas de pods, e é mais adequado para trabalhadores sem estado que podem ser iniciados rapidamente para reagir a picos de utilização e ser encerrados corretamente para evitar a instabilidade da carga de trabalho.

O limite de utilização alvo do HPA permite-lhe personalizar quando acionar automaticamente o ajuste de escala.

Conforme mostra a imagem anterior, o HPA requer um limite de utilização alvo, expresso em percentagem, que lhe permite personalizar quando acionar automaticamente o ajuste de escala. Neste exemplo, a utilização da CPU alvo é de 70%. Isto significa que a sua carga de trabalho tem um buffer de CPU de 30% para processar pedidos enquanto são iniciadas novas réplicas. Um pequeno buffer impede aumentos iniciais, mas pode sobrecarregar a sua aplicação durante picos. No entanto, um grande buffer provoca um desperdício de recursos, o que aumenta os seus custos. O alvo exato é específico da aplicação e tem de considerar que o tamanho do buffer é suficiente para processar pedidos durante dois ou três minutos durante um pico. Mesmo que garanta que a sua aplicação pode ser iniciada em segundos, este tempo adicional é necessário quando o Cluster Autoscaler adiciona novos nós ao cluster ou quando os pods são limitados devido à falta de recursos.

Seguem-se as práticas recomendadas para ativar o HPA na sua aplicação:

Para mais informações, consulte o artigo Configurar um redimensionador automático de pods horizontal.

Redimensionador automático vertical de pods

Ao contrário do HPA, que adiciona e elimina réplicas de pods para reagir rapidamente aos picos de utilização, a escala automática vertical de pods (VPA) observa os pods ao longo do tempo e encontra gradualmente os recursos de CPU e memória ideais necessários pelos pods. A definição dos recursos certos é importante para a estabilidade e a eficiência de custos. Se os recursos do pod forem demasiado pequenos, a sua aplicação pode ser limitada ou falhar devido a erros de falta de memória. Se os seus recursos forem demasiado grandes, tem desperdícios e, por isso, faturas mais elevadas. O VPA destina-se a cargas de trabalho sem estado e com estado que não são processadas pelo HPA ou quando não conhece os pedidos de recursos de pods adequados.

O VPA deteta que um pod está a ser executado consistentemente nos seus limites e recria o pod com recursos maiores.

Como mostra a imagem anterior, o VPA deteta que o pod está a ser executado de forma consistente nos seus limites e recria o pod com recursos maiores. O oposto também acontece quando o pod é consistentemente subutilizado: é acionada uma redução.

O VPA pode funcionar em três modos diferentes:

  • Desativado. Neste modo, também conhecido como modo de recomendação, o VPA não aplica nenhuma alteração ao seu pod. As recomendações são calculadas e podem ser inspecionadas no objeto VPA.
  • Inicial: o VPA atribui pedidos de recursos apenas na criação do grupo e nunca os altera posteriormente.
  • Auto: o VPA atualiza os pedidos de CPU e memória durante a vida útil de um pod. Isto significa que o pod é eliminado, a CPU e a memória são ajustadas e, em seguida, é iniciado um novo pod.

Se planeia usar o VPA, a prática recomendada é começar com o modo Desativado para receber recomendações do VPA. Certifique-se de que está em execução durante 24 horas, idealmente uma semana ou mais, antes de obter recomendações. Em seguida, quando se sentir confiante, considere mudar para o modo Inicial ou Automático.

Siga estas práticas recomendadas para ativar a VPA no modo Inicial ou Automático na sua aplicação:

Quer esteja a considerar usar o modo Automático, certifique-se de que também segue estas práticas:

  • Certifique-se de que a sua aplicação pode ser reiniciada enquanto recebe tráfego.
  • Adicione um orçamento de interrupção de pods (PDB) para controlar quantos pods podem ser desativados em simultâneo.

Para mais informações, consulte o artigo Configurar a escala automática vertical de pods.

Misturar HPA e VPA

A recomendação oficial é que não deve misturar VPA e HPA na CPU nem na memória. No entanto, pode combiná-las em segurança quando usar o modo de recomendação no VPA ou métricas personalizadas no HPA, por exemplo, pedidos por segundo. Quando combinar VPA com HPA, certifique-se de que as suas implementações estão a receber tráfego suficiente, o que significa que estão a ser executadas consistentemente acima das réplicas mínimas do HPA. Isto permite que o VPA compreenda as necessidades de recursos do seu pod.

Para mais informações sobre as limitações do VPA, consulte o artigo Limitações da escalabilidade automática de pods vertical.

Redimensionador automático de clusters

O redimensionador automático de clusters (CA) redimensiona automaticamente a infraestrutura informática subjacente. O CA fornece nós para pods que não têm um local para serem executados no cluster e remove nós subutilizados. A CA está otimizada para o custo da infraestrutura. Por outras palavras, se existirem dois ou mais tipos de nós no cluster, o CA escolhe o menos caro que se adequa à procura especificada.

Ao contrário do HPA e do VPA, o CA não depende das métricas de carga. Em vez disso, baseia-se na simulação de agendamento e nos pedidos de pods declarados. É uma prática recomendada ativar a CA sempre que usar a HPA ou a VPA. Esta prática garante que, se os escaladores automáticos de pods determinarem que precisa de mais capacidade, a sua infraestrutura subjacente cresce em conformidade.

A CA adiciona e remove automaticamente capacidade de computação para processar picos de tráfego.

Conforme mostram estes diagramas, a CA adiciona e remove automaticamente capacidade de computação para processar picos de tráfego e poupar dinheiro quando os seus clientes estão a dormir. É uma prática recomendada definir um orçamento de interrupção de pods (PDB) para todas as suas aplicações. É particularmente importante na fase de redução quando o PDB controla o número de réplicas que podem ser desativadas de uma só vez.

Determinados pods não podem ser reiniciados por nenhum dimensionador automático quando causam alguma interrupção temporária, pelo que não é possível eliminar o nó no qual são executados. Por exemplo, os agrupamentos do sistema (como metrics-server e kube-dns) e os agrupamentos que usam armazenamento local não são reiniciados. No entanto, pode alterar este comportamento definindo PDBs para estes pods do sistema e definindo a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para pods que usam armazenamento local e que são seguros para o reinício automático. Além disso, considere executar pods de longa duração que não podem ser reiniciados num conjunto de nós separado, para que não bloqueiem a redução de outros nós. Por último, saiba como analisar eventos de CA nos registos para compreender por que motivo uma determinada atividade de escalabilidade não ocorreu como esperado.

Se as suas cargas de trabalho forem resilientes ao reinício inadvertido de nós e às perdas de capacidade, pode poupar mais dinheiro criando um cluster ou um conjunto de nós com VMs de spot. Para que a CA funcione como esperado, os pedidos de recursos de agrupamentos têm de ser suficientemente grandes para que o agrupamento funcione normalmente. Se os pedidos de recursos forem demasiado pequenos, os nós podem não ter recursos suficientes e os seus pods podem falhar ou ter problemas durante a execução.

Segue-se um resumo das práticas recomendadas para ativar o escalador automático de clusters no seu cluster:

  • Use o HPA ou o VPA para ajustar automaticamente a escala das suas cargas de trabalho.
  • Certifique-se de que está a seguir as práticas recomendadas descritas no ajuste automático de pods escolhido.
  • Dimensionar corretamente a sua aplicação através da definição de pedidos e limites de recursos adequados ou da utilização de VPA.
  • Defina um PDB para as suas aplicações.
  • Defina o PDB para os pods do sistema que podem bloquear a redução. Por exemplo, kube-dns. Para evitar a interrupção temporária no cluster, não defina o PDB para pods do sistema que tenham apenas 1 réplica (como metrics-server).
  • Execute agrupamentos de curta duração e agrupamentos que podem ser reiniciados em conjuntos de nós separados, para que os agrupamentos de longa duração não bloqueiem a respetiva redução de escala.
  • Evite o aprovisionamento excessivo configurando nós inativos no cluster. Para isso, tem de saber a sua capacidade mínima (para muitas empresas, é durante a noite) e definir o número mínimo de nós nos seus conjuntos de nós para suportar essa capacidade.
  • Se precisar de capacidade adicional para processar pedidos durante picos, use pods de pausa, que são abordados no artigo Criação automática de escala e aprovisionamento excessivo.

Para mais informações, consulte o artigo Dimensionamento automático de um cluster.

Aprovisionamento automático de nós

O aprovisionamento automático de nós (NAP) é um mecanismo do Cluster Autoscaler que adiciona automaticamente novos pools de nós, além de gerir o respetivo tamanho em nome do utilizador. Sem o aprovisionamento automático de nós, o GKE considera iniciar novos nós apenas a partir do conjunto de pools de nós criados pelo utilizador. Com o aprovisionamento automático de nós, o GKE pode criar e eliminar automaticamente novos node pools.

O aprovisionamento automático de nós tende a reduzir o desperdício de recursos através da criação dinâmica de conjuntos de nós que se ajustam melhor às cargas de trabalho agendadas. No entanto, a latência do ajuste automático pode ser ligeiramente superior quando é necessário criar novos conjuntos de nós. Se as suas cargas de trabalho forem resilientes ao reinício inadvertido de nós e às perdas de capacidade, pode reduzir ainda mais os custos configurando a tolerância de VMs do Spot no seu pod.

Seguem-se as práticas recomendadas para ativar o aprovisionamento automático de nós:

  • Siga todas as práticas recomendadas do redimensionador automático de clusters.
  • Defina tamanhos mínimos e máximos de recursos para evitar que o NAP faça alterações significativas no cluster quando a aplicação não estiver a receber tráfego.
  • Quando usar a escala automática horizontal de pods para publicar cargas de trabalho, considere reservar um buffer de utilização de destino ligeiramente maior, porque a NAP pode aumentar a latência da escala automática em alguns casos.

Para mais informações, consulte os artigos Usar o aprovisionamento automático de nós e Funcionalidades não suportadas.

Redimensionador automático e aprovisionamento excessivo

Para controlar os seus custos, recomendamos vivamente que ative o escalamento automático de acordo com as secções anteriores. Nenhuma configuração se adequa a todos os cenários possíveis, pelo que tem de ajustar as definições da sua carga de trabalho para garantir que os escaladores automáticos respondem corretamente aos aumentos no tráfego.

No entanto, conforme indicado na secção Redimensionador automático horizontal de pods, os aumentos da escala podem demorar algum tempo devido ao aprovisionamento da infraestrutura. Para visualizar esta diferença no tempo e possíveis cenários de expansão, considere a seguinte imagem.

Visualizar a diferença de tempo e os possíveis cenários de expansão.

Quando o cluster tem espaço suficiente para implementar novos pods, é acionado um dos cenários de aumento da escala da carga de trabalho. Isto significa que, se um nó existente nunca tiver implementado a sua aplicação, tem de transferir as respetivas imagens de contentores antes de iniciar o pod (cenário 1). No entanto, se o mesmo nó tiver de iniciar uma nova réplica do pod da sua aplicação, o tempo total de expansão diminui porque não é necessária a transferência de imagens (cenário 2).

Quando o cluster não tem espaço suficiente para implementar novos pods, é acionado um dos cenários de expansão da infraestrutura e da carga de trabalho. Isto significa que o Cluster Autoscaler tem de aprovisionar novos nós e iniciar o software necessário antes de se aproximar da sua aplicação (cenário 1). Se usar o aprovisionamento automático de nós, dependendo da carga de trabalho agendada, podem ser necessários novos conjuntos de nós. Nesta situação, o tempo total de expansão aumenta porque o Cluster Autoscaler tem de aprovisionar nós e node pools (cenário 2).

Para cenários em que é necessária uma nova infraestrutura, não comprima demasiado o cluster, o que significa que tem de fazer o aprovisionamento em excesso, mas apenas para reservar o buffer necessário para processar os picos de pedidos esperados durante os aumentos de escala.

Existem duas estratégias principais para este tipo de aprovisionamento excessivo:

  • Ajuste o alvo de utilização de HPA. A seguinte equação é uma forma simples e segura de encontrar um bom objetivo de CPU:

    (1 - buff)/(1 + perc)

    • buff é uma margem de segurança que pode definir para evitar atingir 100% da CPU. Esta variável é útil porque atingir 100% da CPU significa que a latência do processamento de pedidos é muito superior ao habitual.
    • perc é a percentagem de crescimento do tráfego que espera em dois ou três minutos.

    Por exemplo, se espera um crescimento de 30% nos seus pedidos e quiser evitar atingir 100% da CPU definindo uma margem de segurança de 10%, a sua fórmula seria a seguinte:

    (1 - 0,1)/(1 + 0,3) = 0,69

  • Configure pausas de pods. Não existe forma de configurar o redimensionador automático de clusters para iniciar nós antecipadamente. Em alternativa, pode definir um objetivo de utilização do HPA para fornecer uma margem que ajude a processar picos de carga. No entanto, se esperar picos grandes, definir um alvo de utilização de HPA pequeno pode não ser suficiente ou pode tornar-se demasiado caro.

    Uma solução alternativa para este problema é usar a opção pausar pods. Os Pause Pods são implementações de baixa prioridade que não fazem nada além de reservar espaço no cluster. Sempre que um agrupamento de pods de alta prioridade é agendado, os agrupamentos de pods em pausa são removidos e o agrupamento de pods de alta prioridade ocupa imediatamente o respetivo lugar. Em seguida, os pods de pausa despejados são reagendados e, se não houver espaço no cluster, o redimensionador automático de cluster cria novos nós para os ajustar. É uma prática recomendada ter apenas um Pod de pausa por nó. Por exemplo, se estiver a usar 4 nós de CPU, configure o pedido de CPU dos pods de pausa com cerca de 3200 m.

Escolha o tipo de máquina certo

Além da escala automática, outras configurações podem ajudar a executar aplicações Kubernetes otimizadas em termos de custos no GKE. Esta secção aborda a escolha do tipo de máquina certo.

VMs do Spot

As VMs do Spot são instâncias de VM do Compute Engine que não oferecem garantias de disponibilidade. As VMs de capacidade disponível são até 91% mais baratas do que as VMs padrão do Compute Engine, mas recomendamos que as use com cautela em clusters do GKE. As VMs do Spot no GKE são mais adequadas para executar tarefas de lote ou com tolerância a falhas menos sensíveis à natureza efémera e não garantida das VMs do Spot. As cargas de trabalho com estado e de serviço não podem usar VMs de spot, a menos que prepare o seu sistema e arquitetura para lidar com as restrições das VMs de spot.

Qualquer que seja o tipo de carga de trabalho, tem de prestar atenção às seguintes restrições:

  • O orçamento de interrupção de pods pode não ser respeitado porque as VMs de capacidade instantânea podem ser encerradas inadvertidamente.
  • Não existe garantia de que os seus pods sejam encerrados corretamente quando a remoção preventiva de nós ignora o período de tolerância dos pods.
  • Pode demorar vários minutos para que o GKE detete que o nó foi anulado e que os pods já não estão em execução, o que atrasa o reagendamento dos pods para um novo nó.

A partir do GKE v1.20, o encerramento elegante de nós está ativado por predefinição para enviar um aviso às cargas de trabalho em execução.

As VMs de capacidade instantânea não têm disponibilidade garantida, o que significa que podem ficar facilmente indisponíveis em algumas regiões. Para ultrapassar esta limitação, recomendamos que defina um conjunto de nós alternativo sem VMs Spot. O Cluster Autoscaler dá preferência às VMs do Spot porque está otimizado para o custo da infraestrutura.

Para mais informações, consulte os artigos Execute cargas de trabalho com tolerância a falhas a custos mais baixos com VMs do Spot, Execute cargas de trabalho com tolerância a falhas a custos mais baixos em pods do Spot e Execute aplicações Web no GKE com VMs do Spot otimizadas em função dos custos.

Tipos de máquinas E2

Os tipos de máquinas E2 (VMs E2) são VMs com custos otimizados que lhe oferecem uma poupança de 31% em comparação com os tipos de máquinas N1. As VMs E2 são adequadas para uma vasta gama de cargas de trabalho, incluindo servidores Web, microserviços, aplicações críticas para a empresa, bases de dados de pequenas a médias dimensões e ambientes de desenvolvimento.

Para mais informações sobre as VMs E2 e como se comparam com outros Google Cloud tipos de máquinas, consulte Gestão dinâmica de recursos orientada pelo desempenho nas VMs E2 e Tipos de máquinas.

Selecione a região adequada

Quando o custo é uma restrição, a localização dos clusters do GKE é importante. Devido a vários fatores, o custo varia consoante a região de computação. Por isso, certifique-se de que está a executar a sua carga de trabalho na opção menos dispendiosa, mas onde a latência não afeta o seu cliente. Se a sua carga de trabalho exigir a cópia de dados de uma região para outra, por exemplo, para executar uma tarefa em lote, também tem de considerar o custo da movimentação destes dados.

Para mais informações sobre como escolher a região certa, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.

Inscreva-se para receber descontos de fidelidade

Se pretende permanecer com o Google Cloud durante alguns anos, recomendamos vivamente que adquira descontos por fidelização em troca de uma utilização de VM a preços significativamente reduzidos. Google Cloud Quando assina um contrato de fidelização, compra recursos de computação a um preço com desconto (até 70% de desconto) em troca do compromisso de pagar esses recursos durante um ou três anos. Se não tiver a certeza de quantos recursos comprometer, analise a sua utilização mínima de computação, por exemplo, durante a noite, e comprometa o pagamento desse valor.

Para mais informações sobre os preços de fidelização para diferentes tipos de máquinas, consulte Preços das instâncias de VM.

Reveja pequenos clusters de desenvolvimento

Para pequenos clusters de desenvolvimento onde precisa de minimizar os custos, considere usar clusters do Autopilot. Com os clusters neste modo de funcionamento, não lhe são cobrados custos relativos a pods do sistema, custos do sistema operativo nem cargas de trabalho não agendadas.

Reveja as suas estratégias de registo e monitorização

Se usar o Cloud Logging e o Cloud Monitoring para fornecer observabilidade nas suas aplicações e infraestrutura, está a pagar apenas pelo que usa. No entanto, quanto mais a sua infraestrutura e aplicações registarem e quanto mais tempo mantiver esses registos, mais paga por eles. Da mesma forma, quanto mais métricas externas e personalizadas tiver, mais elevados serão os seus custos.

Reveja o tráfego de saída entre regiões em clusters regionais e multizonais

Os tipos de clusters do GKE disponíveis são: de zona única, multizonais e regionais. Devido à elevada disponibilidade de nós em várias zonas, os clusters regionais e multizonais são adequados para ambientes de produção. No entanto, é-lhe cobrado o tráfego de saída entre zonas. Para ambientes de produção, recomendamos que monitorize a carga de tráfego em todas as zonas e melhore as suas APIs para a minimizar. Considere também usar configurações de afinidade e antiafinidade entre pods para colocar dependentes de diferentes serviços nos mesmos nós ou na mesma zona de disponibilidade para minimizar os custos e a latência da rede entre eles. A forma sugerida de monitorizar este tráfego é ativar a medição da utilização do GKE e o respetivo agente de saída de rede, que está desativado por predefinição.

Para ambientes de não produção, a prática recomendada para poupar custos é implementar clusters de zona única.

Prepare o seu ambiente para se adequar ao tipo de carga de trabalho

As empresas têm requisitos de custos e disponibilidade diferentes. As respetivas cargas de trabalho podem ser divididas em cargas de trabalho de publicação, que têm de responder rapidamente a picos ou aumentos repentinos, e cargas de trabalho em lote, que se preocupam com o trabalho eventual a realizar. As cargas de trabalho de serviço requerem uma pequena latência de expansão. As cargas de trabalho em lote são mais tolerantes à latência. As diferentes expetativas para estes tipos de carga de trabalho tornam a escolha de diferentes métodos de redução de custos mais flexível.

Cargas de trabalho em lote

Uma vez que as cargas de trabalho em lote se preocupam com o trabalho final, permitem uma poupança de custos no GKE porque as cargas de trabalho são normalmente tolerantes a alguma latência no tempo de arranque do trabalho. Esta tolerância dá espaço ao redimensionador automático de clusters para iniciar novos nós apenas quando as tarefas são agendadas e desativá-los quando as tarefas terminam.

A primeira prática recomendada é separar as cargas de trabalho em lote em diferentes node pools usando etiquetas e seletores e usando manchas e tolerâncias. A justificação é a seguinte:

  • O redimensionador automático de clusters pode eliminar nós vazios mais rapidamente quando não precisa de reiniciar pods. À medida que as tarefas em lote terminam, o cluster acelera o processo de redução se a carga de trabalho estiver a ser executada em nós dedicados que estão agora vazios. Para melhorar ainda mais a velocidade das reduções, pondere configurar o perfil de otimização da utilização do CA.
  • Não é possível reiniciar alguns pods, pelo que bloqueiam permanentemente a redução dos respetivos nós. Estes pods, que incluem os pods do sistema, têm de ser executados em pools de nós diferentes para não afetarem a redução de escala.

A segunda prática recomendada é usar o aprovisionamento automático de nós para criar automaticamente pools de nós dedicados para tarefas com uma tolerância ou uma mancha correspondente. Desta forma, pode separar muitas cargas de trabalho diferentes sem ter de configurar todos esses conjuntos de nós diferentes.

Recomendamos que use VMs Spot apenas se executar tarefas com tolerância a falhas menos sensíveis à natureza efémera e não garantida das VMs Spot.

Publicação de cargas de trabalho

Ao contrário das cargas de trabalho em lote, as cargas de trabalho de publicação têm de responder o mais rapidamente possível a picos ou aumentos repentinos. Estes aumentos súbitos no tráfego podem resultar de vários fatores, por exemplo, anúncios de TV, eventos de grande escala, como a Black Friday, ou notícias de última hora. A sua aplicação tem de estar preparada para os processar.

Os problemas no processamento destes picos estão normalmente relacionados com um ou mais dos seguintes motivos:

  • As aplicações não estarem prontas para serem executadas no Kubernetes, por exemplo, apps com tamanhos de imagens grandes, tempos de arranque lentos ou configurações do Kubernetes não ideais.
  • Aplicações que dependem de infraestrutura que demora a ser aprovisionada, como GPUs.
  • Ajustadores automáticos e aprovisionamento excessivo não estão definidos corretamente.

Prepare aplicações Kubernetes baseadas na nuvem

Algumas das práticas recomendadas nesta secção podem poupar dinheiro por si só. No entanto, uma vez que a maioria destas práticas se destina a fazer com que a sua aplicação funcione de forma fiável com os escaladores automáticos, recomendamos vivamente que as implemente.

Compreenda a capacidade da sua aplicação

Quando planear a capacidade da aplicação, saiba quantos pedidos simultâneos a sua aplicação consegue processar, quanta CPU e memória requer e como responde sob carga elevada. A maioria das equipas não conhece estas capacidades, pelo que recomendamos que teste o comportamento da sua aplicação sob pressão. Experimente isolar uma única réplica do pod de aplicação com o dimensionamento automático desativado e, em seguida, execute os testes simulando uma carga de utilização real. Isto ajuda a compreender a sua capacidade por pod. Em seguida, recomendamos que configure o Cluster Autoscaler, os pedidos de recursos e os limites, bem como o HPA ou o VPA. Em seguida, aplique novamente pressão na aplicação, mas com mais força para simular picos ou aumentos súbitos.

Idealmente, para eliminar preocupações com a latência, estes testes têm de ser executados na mesma região ou zona em que a aplicação está a ser executada Google Cloud. Pode usar a ferramenta da sua escolha para estes testes, quer seja um script criado por si ou uma ferramenta de desempenho mais avançada, como o Apache Benchmark, o JMeter ou o Locust.

Para ver um exemplo de como pode realizar os seus testes, consulte o artigo Testes de carga distribuídos com o Google Kubernetes Engine.

Certifique-se de que a sua aplicação pode crescer vertical e horizontalmente

Certifique-se de que a sua aplicação pode aumentar e diminuir. Isto significa que pode optar por processar os aumentos de tráfego adicionando mais CPU e memória ou adicionando mais réplicas de pods. Isto dá-lhe a flexibilidade de experimentar o que se adapta melhor à sua aplicação, quer seja uma configuração de dimensionamento automático diferente ou um tamanho de nó diferente. Infelizmente, algumas aplicações têm uma única thread ou estão limitadas por um número fixo de trabalhadores ou subprocessos que tornam esta experiência impossível sem uma refatoração completa da respetiva arquitetura.

Defina pedidos e limites de recursos adequados

Ao compreender a capacidade da sua aplicação, pode determinar o que configurar nos recursos do contentor. Os recursos no Kubernetes são definidos principalmente como CPU e memória (RAM). Configura a CPU ou a memória como a quantidade necessária para executar a sua aplicação através do pedido spec.containers[].resources.requests.<cpu|memory> e configura o limite máximo através do pedido spec.containers[].resources.limits.<cpu|memory>. Para mais informações sobre como configurar pedidos de recursos, consulte o artigo Defina pedidos de recursos de pods manualmente.

Quando define corretamente os pedidos de recursos, o programador do Kubernetes pode usá-los para decidir em que nó colocar o seu pod. Isto garante que os agrupamentos estão a ser colocados em nós que os podem fazer funcionar normalmente, para que tenha uma melhor estabilidade e um menor desperdício de recursos. Além disso, a definição de limites de recursos ajuda a garantir que estas aplicações nunca usam toda a infraestrutura subjacente disponível fornecida pelos nós de computação.

Use as seguintes práticas recomendadas para definir os pedidos e os limites de recursos do contentor:

  • Memória: defina a mesma quantidade de memória para o pedido e o limite.
  • CPU: para o pedido, especifique a CPU mínima necessária para garantir o funcionamento correto, de acordo com os seus próprios SLOs. Defina um limite de CPU ilimitado.

Considere a seguinte implementação como exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

O raciocínio para o padrão anterior baseia-se no funcionamento do processamento de recursos esgotados do Kubernetes. Resumidamente, quando os recursos do computador se esgotam, os nós tornam-se instáveis. Para evitar esta situação, o kubelet monitoriza e impede a privação total destes recursos através da classificação dos pods com elevada procura de recursos. Quando a CPU está em disputa, estes pods podem ser limitados às respetivas solicitações. No entanto, como a memória é um recurso não comprimível, quando a memória se esgota, o Pod tem de ser desativado. Para evitar a desativação dos pods e, consequentemente, a desestabilização do seu ambiente, tem de definir a memória pedida para o limite de memória. Pode identificar as cargas de trabalho que não têm pedidos de recursos nem limites configurados para os respetivos contentores através da visualização das estatísticas do subtipo REQUEST_OR_LIMIT_NOT_SET. Para mais informações, consulte o artigo Identifique cargas de trabalho sem pedidos de recursos nem limites.

Também pode usar o VPA no modo de recomendação para ajudar a determinar a utilização da CPU e da memória para uma determinada aplicação. Para mais informações, consulte o artigo Analise pedidos de recursos.

Uma vez que o VPA fornece essas recomendações com base na utilização da sua aplicação, recomendamos que use o VPA no modo de recomendação num ambiente semelhante ao de produção para enfrentar tráfego real. Em seguida, o estado do VPA gera um relatório com os pedidos e os limites de recursos sugeridos, que pode especificar estaticamente no manifesto de implementação. Se a sua aplicação já definir o HPA, consulte o artigo Misturar HPA e VPA.

Certifique-se de que o contentor é o mais simples possível

Quando executa contentores no Kubernetes, a sua aplicação pode iniciar e parar em qualquer momento. Por conseguinte, é importante seguir estas práticas recomendadas:

  • Ter a imagem mais pequena possível. É uma prática recomendada ter imagens pequenas porque, sempre que o Cluster Autoscaler aprovisiona um novo nó para o seu cluster, o nó tem de transferir as imagens que vão ser executadas nesse nó. Quanto mais pequena for a imagem, mais rapidamente o nó a pode transferir.

  • Inicie a aplicação o mais rapidamente possível. Algumas aplicações podem demorar minutos a iniciar devido ao carregamento de classes, à colocação em cache, etc. Quando um Pod requer um arranque longo, os pedidos dos seus clientes podem falhar enquanto a sua aplicação está a arrancar.

Considere estas duas práticas ao conceber o seu sistema, especialmente se esperar picos ou aumentos repentinos. Ter uma imagem pequena e um arranque rápido ajuda a reduzir a latência dos aumentos de escala. Consequentemente, pode gerir melhor os aumentos de tráfego sem se preocupar demasiado com a instabilidade. Estas práticas funcionam melhor com as práticas recomendadas de escala automática abordadas no artigo Escala automática do GKE.

Adicione um orçamento de interrupção de pods à sua aplicação

O orçamento de interrupção de agrupamentos (PDB) limita o número de agrupamentos que podem ser desativados em simultâneo devido a uma interrupção voluntária. Isto significa que o orçamento de interrupção definido é respeitado nas implementações, nas atualizações de nós e em quaisquer atividades de dimensionamento automático. No entanto, não é possível garantir este orçamento quando ocorrem situações involuntárias, como uma falha de hardware, um pânico do kernel ou alguém eliminar uma VM por engano.

Quando o PDB é respeitado durante a fase de compactação do Cluster Autoscaler, é uma prática recomendada definir um orçamento de interrupção de pods para cada aplicação. Desta forma, pode controlar o número mínimo de réplicas necessárias para suportar a sua carga em qualquer altura, incluindo quando o CA está a reduzir a escala do cluster.

Para mais informações, consulte o artigo Especificar um orçamento de interrupção para a sua aplicação.

Defina sondas de prontidão e atividade significativas para a sua aplicação

A definição de sondagens significativas garante que a sua aplicação recebe tráfego apenas quando está em funcionamento e pronta para aceitar tráfego. O GKE usa sondas de prontidão para determinar quando adicionar ou remover pods dos balanceadores de carga. O GKE usa testes de vitalidade para determinar quando reiniciar os seus pods.

A sondagem de atividade é útil para informar o Kubernetes de que um determinado pod não consegue progredir, por exemplo, quando é detetado um estado de impasse. A sonda de disponibilidade é útil para indicar ao Kubernetes que a sua aplicação não está pronta para receber tráfego, por exemplo, durante o carregamento de grandes quantidades de dados de cache no arranque.

Para garantir o ciclo de vida correto da sua aplicação durante as atividades de expansão, é importante fazer o seguinte:

  • Defina a sondagem de prontidão para todos os seus contentores.
  • Se a sua aplicação depender de uma cache para ser carregada no arranque, a sondagem de disponibilidade tem de indicar que está pronta apenas depois de a cache estar totalmente carregada.
  • Se a sua aplicação puder começar a publicar imediatamente, uma boa implementação da sondagem predefinida pode ser o mais simples possível, por exemplo, um ponto final HTTP que devolva um código de estado 200.
  • Se implementar uma sondagem mais avançada, como verificar se o conjunto de ligações tem recursos disponíveis, certifique-se de que a taxa de erros não aumenta em comparação com uma implementação mais simples.
  • Nunca permita que a lógica de sondagem aceda a outros serviços. Pode comprometer o ciclo de vida do seu Pod se estes serviços não responderem rapidamente.

Para mais informações, consulte o artigo Configure as sondas de atividade, disponibilidade e arranque.

Certifique-se de que as suas aplicações estão a ser encerradas de acordo com as expetativas do Kubernetes

Os escaladores automáticos ajudam a responder a picos ao criar novos pods e nós e eliminá-los quando os picos terminam. Isto significa que, para evitar erros durante a publicação, os seus pods têm de estar preparados para um início rápido ou um encerramento normal.

Uma vez que o Kubernetes atualiza os pontos finais e os equilibradores de carga de forma assíncrona, é importante seguir estas práticas recomendadas para garantir encerramentos sem interrupções:

  • Não deixe de aceitar novos pedidos imediatamente após SIGTERM. A sua aplicação não deve parar imediatamente, mas sim concluir todos os pedidos que estão em curso e continuar a ouvir as ligações recebidas que chegam após o início da terminação do pod. A atualização de todos os kube-proxies e equilibradores de carga pode demorar algum tempo. Se a sua aplicação terminar antes de estas serem atualizadas, alguns pedidos podem causar erros no lado do cliente.
  • Se a sua aplicação não seguir a prática anterior, use o gancho preStop. A maioria dos programas não deixa de aceitar pedidos imediatamente. No entanto, se estiver a usar código de terceiros ou a gerir um sistema sobre o qual não tem controlo, como o nginx, o gancho preStop é uma boa opção para acionar um encerramento elegante sem modificar a aplicação. Uma estratégia comum é executar, no gancho preStop, um período de inatividade de alguns segundos para adiar o SIGTERM. Isto dá ao Kubernetes tempo adicional para concluir o processo de eliminação de pods e reduz os erros de ligação no lado do cliente.
  • Processar SIGTERM para limpezas. Se a sua aplicação tiver de limpar ou tiver um estado na memória que tenha de ser mantido antes de o processo terminar, agora é o momento de o fazer. Os diferentes idiomas de programação têm formas diferentes de captar este sinal. Por isso, encontre a forma certa no seu idioma.
  • Configure terminationGracePeriodSeconds para se adequar às necessidades da sua aplicação. Algumas aplicações precisam de mais do que os 30 segundos predefinidos para terminar. Neste caso, tem de especificar terminationGracePeriodSeconds. Os valores elevados podem aumentar o tempo necessário para as atualizações ou as implementações de nós, por exemplo. Os valores baixos podem não dar tempo suficiente para o Kubernetes terminar o processo de encerramento do pod. De qualquer forma, recomendamos que defina o período de rescisão da sua aplicação para menos de 10 minutos, porque o Cluster Autoscaler só o respeita durante 10 minutos.
  • Se a sua aplicação usar equilíbrio de carga nativo do contentor, comece a falhar a sua sondagem de prontidão quando receber um SIGTERM. Esta ação sinaliza diretamente aos balanceadores de carga que devem parar de encaminhar novos pedidos para o pod de back-end. Consoante a corrida entre a configuração da verificação de estado e a programação do ponto final, o pod de back-end pode ser retirado do tráfego mais cedo.

Para mais informações, consulte o artigo Práticas recomendadas do Kubernetes: terminar com elegância.

Configure a DNSCache local do nó

O DNS gerido pelo GKE é implementado pelo kube-dns, um suplemento implementado em todos os clusters do GKE. Quando executa aplicações com elevada utilização de DNS, a configuração kube-dns-autoscaler predefinida, que ajusta o número de réplicas kube-dns com base no número de nós e núcleos no cluster, pode não ser suficiente. Neste cenário, as consultas DNS podem ficar mais lentas ou atingir o limite de tempo. Para mitigar este problema, as empresas estão habituadas a ajustar o kube-dns-autoscalerConfigMap para aumentar o número de réplicas kube-dns nos respetivos clusters. Embora esta estratégia possa funcionar conforme esperado, aumenta a utilização de recursos e o custo total do GKE.

Uma alternativa mais escalável e otimizada em termos de custos é configurar o NodeLocal DNSCache no seu cluster. O NodeLocal DNSCache é um suplemento opcional do GKE que melhora a latência de procura de DNS, torna os tempos de procura de DNS mais consistentes e reduz o número de consultas DNS para kube-dns executando uma cache DNS em cada nó do cluster.

Para mais informações, consulte o artigo Configurar o NodeLocal DNSCache.

Use o balanceamento de carga nativa do contentor através da entrada

O equilíbrio de carga nativo do contentor permite que os equilibradores de carga segmentem diretamente os pods do Kubernetes e distribuam o tráfego uniformemente para os pods através de um modelo de dados denominado grupos de pontos finais de rede (NEGs). Esta abordagem melhora o desempenho da rede, aumenta a visibilidade, permite funcionalidades avançadas de balanceamento de carga e permite a utilização do Cloud Service Mesh, o plano de controlo de tráfego totalmente gerido da Google Cloudpara a malha de serviços.

Devido a estas vantagens, o balanceamento de carga nativa do contentor é a solução recomendada para o balanceamento de carga através da entrada. Quando os NEGs são usados com o GKE Ingress, o controlador Ingress facilita a criação de todos os aspetos do equilibrador de carga de nível 7. Isto inclui a criação do endereço IP virtual, regras de encaminhamento, verificações de funcionamento, regras de firewall e muito mais.

O balanceamento de carga nativa do contentor torna-se ainda mais importante quando usa o Cluster Autoscaler. Para equilibradores de carga não NEG, durante as reduções de escala, a programação do equilíbrio de carga e a drenagem de ligações podem não ser totalmente concluídas antes de o Cluster Autoscaler terminar as instâncias de nós. Isto pode interromper as ligações em curso que fluem através do nó, mesmo quando os pods de back-end não estão no nó.

O balanceamento de carga nativa do contentor está ativado por predefinição para os serviços quando todas as seguintes condições são verdadeiras:

  • Os serviços foram criados em clusters do GKE 1.17.6-gke.7 e superiores.
  • Se estiver a usar clusters nativos de VPC.
  • Se não estiver a usar uma VPC partilhada.
  • Se não estiver a usar a política de rede do GKE.

Para mais informações, consulte a documentação do GKE sobre a entrada e Como usar o balanceamento de carga nativo do contentor.

Considere usar novas tentativas com retirada exponencial

Em arquiteturas de microsserviços executadas no Kubernetes, podem ocorrer falhas transitórias por vários motivos, por exemplo:

Estes problemas são efémeros e pode mitigá-los chamando o serviço novamente após um atraso. No entanto, para evitar sobrecarregar o serviço de destino com pedidos, é importante que execute estas chamadas usando uma retirada exponencial.

Para facilitar este padrão de repetição, muitas bibliotecas existentes implementam a lógica de repetição exponencial. Pode usar a biblioteca da sua escolha ou escrever o seu próprio código. Se usar o Istio ou o Cloud Service Mesh (ASM), pode optar pelo mecanismo de repetição ao nível do proxy, que executa as repetições de forma transparente em seu nome.

É importante planear a sua aplicação para suportar novas tentativas de chamadas de serviço, por exemplo, para evitar a inserção de informações já inseridas. Tenha em atenção que uma cadeia de novas tentativas pode afetar a latência do utilizador final, o que pode exceder o limite de tempo se não for planeado corretamente.

Monitorize o seu ambiente e aplique configurações e práticas otimizadas em função dos custos

Em muitas empresas de média e grande dimensão, uma equipa de infraestrutura e plataforma centralizada é frequentemente responsável pela criação, manutenção e monitorização de clusters do Kubernetes para toda a empresa. Isto representa uma forte necessidade de ter responsabilidade pela utilização de recursos e de garantir que todas as equipas seguem as políticas da empresa. Esta secção aborda as opções de monitorização e aplicação de práticas relacionadas com custos.

Observe os seus clusters do GKE e procure recomendações

Pode verificar a utilização de recursos num cluster do Kubernetes examinando os contentores, os pods e os serviços, bem como as caraterísticas do cluster geral. Existem muitas formas de realizar esta tarefa, mas a abordagem inicial que recomendamos é observar os seus clusters do GKE através do painel de controlo de monitorização. Isto dá-lhe dados de séries cronológicas sobre a forma como o seu cluster está a ser usado, o que lhe permite agregar e abranger a infraestrutura, as cargas de trabalho e os serviços.

Embora seja um bom ponto de partida, Google Cloud oferece outras opções, por exemplo:

  • Na Google Cloud consola, na página GKE Clusters, consulte a coluna Notifications. Se tiver um elevado desperdício de recursos num cluster, a IU dá-lhe uma sugestão das informações gerais alocadas versus pedidas.

    Aceda à lista de clusters do GKE

  • Na Google Cloud consola, na página Recomendações, procure cartões de recomendação de Poupanças de custos.

    Aceda ao centro de recomendações

Para mais detalhes, consulte os artigos Monitorizar os clusters do GKE e Introdução ao Recommendation Hub.

Ative a medição de utilização do GKE

Para uma abordagem mais flexível que lhe permite ver discriminações de custos aproximados, experimente a Medição de utilização do GKE. A medição de utilização do GKE permite-lhe ver os perfis de utilização dos seus clusters do GKE discriminados por namespaces e etiquetas. Monitoriza informações sobre os pedidos de recursos e o consumo de recursos das cargas de trabalho do seu cluster, como CPU, GPU, TPU, memória, armazenamento e, opcionalmente, saída de rede.

A medição da utilização do GKE ajuda a compreender a estrutura de custos geral dos seus clusters do GKE, que equipa ou aplicação está a gastar mais, que ambiente ou componente causou um aumento repentino na utilização ou nos custos e que equipa está a desperdiçar recursos. Ao comparar os pedidos de recursos com a utilização real, pode compreender que cargas de trabalho estão subaprovisionadas ou sobreaprovisionadas.

Pode tirar partido dos modelos predefinidos do Looker Studio ou ir mais longe e personalizar os painéis de controlo de acordo com as necessidades da sua organização. Para mais informações sobre a medição de utilização do GKE e os respetivos pré-requisitos, consulte o artigo Compreender a utilização de recursos do cluster.

Compreenda como funciona o servidor de métricas e monitorize-o

O servidor de métricas é a origem das métricas de recursos do contentor para pipelines de escalamento automático incorporados do GKE. O Metrics Server obtém métricas dos kubelets e expõe-nas através da API Metrics do Kubernetes. Em seguida, o HPA e o VPA usam estas métricas para determinar quando acionar o dimensionamento automático.

Para o bom funcionamento da escala automática do GKE, tem de ter um servidor de métricas em bom estado. Com a implementação do GKE, é instalado um nanny de redimensionamento, que faz com que o contentor do servidor de métricas cresça verticalmente adicionando ou removendo CPU e memória de acordo com a quantidade de nós do cluster.metrics-server A atualização no local de pods ainda não é suportada no Kubernetes, motivo pelo qual o nanny tem de reiniciar o pod metrics-server para aplicar os novos recursos necessários.

Embora o reinício ocorra rapidamente, a latência total para que os escaladores automáticos se apercebam de que têm de agir pode aumentar ligeiramente após uma alteração de tamanho metrics-server. Para evitar reinícios frequentes do servidor de métricas em clusters que mudam rapidamente, a partir do GKE 1.15.11-gke.9, o nanny suporta atrasos no redimensionamento.

Siga estas práticas recomendadas quando usar o servidor de métricas:

  • Escolha a versão do GKE que suporta metrics-server atrasos no redimensionamento. Pode confirmá-lo verificando se o ficheiro YAML de implementação tem a configuração no contentor metrics-server-nanny.metrics-serverscale-down-delay
  • Monitorize a implementação metrics-server. Se o servidor de métricas estiver em baixo, significa que o dimensionamento automático não está a funcionar. Quer que os seus serviços de monitorização de prioridade máxima monitorizem esta implementação.
  • Siga as práticas recomendadas abordadas no artigo Escala automática do GKE.

Use quotas de recursos do Kubernetes

Em clusters multi-inquilinos, é comum que diferentes equipas se tornem responsáveis por aplicações implementadas em diferentes espaços de nomes. Para uma plataforma centralizada e um grupo de infraestrutura, é preocupante que uma equipa possa usar mais recursos do que o necessário. A falta de recursos de computação de todos os clusters ou até mesmo o acionamento de demasiados aumentos podem aumentar os seus custos.

Para resolver esta preocupação, tem de usar quotas de recursos. As quotas de recursos gerem a quantidade de recursos usados por objetos num espaço de nomes. Pode definir quotas em termos de recursos de computação (CPU e memória) e armazenamento, ou em termos de contagens de objetos. As quotas de recursos permitem-lhe garantir que nenhum inquilino usa mais do que a respetiva parte atribuída dos recursos do cluster.

Para mais informações, consulte o artigo Configure quotas de memória e CPU para um espaço de nomes.

Considere usar o Policy Controller do GKE Enterprise

O GKE Enterprise Policy Controller é um controlador de admissão dinâmico do Kubernetes que verifica, audita e aplica a conformidade dos seus clusters com políticas relacionadas com segurança, regulamentos ou regras empresariais arbitrárias. O Policy Controller usa restrições para aplicar a conformidade dos seus clusters. Por exemplo, pode instalar restrições no seu cluster para muitas das práticas recomendadas abordadas na secção Preparar a sua aplicação Kubernetes baseada na nuvem. Desta forma, as implementações são rejeitadas se não cumprirem rigorosamente as suas práticas do Kubernetes. A aplicação destas regras ajuda a evitar picos de custos inesperados e reduz as probabilidades de ter instabilidade da carga de trabalho durante o dimensionamento automático.

Para mais informações sobre como aplicar e escrever as suas próprias regras, consulte os artigos Criar restrições e Escrever um modelo de restrição. Se não for cliente do GKE Enterprise, pode considerar usar o Gatekeeper, o software de código aberto no qual o Policy Controller se baseia.

Conceba a sua pipeline de CI/CD para aplicar práticas de poupança de custos

O GKE Enterprise Policy Controller ajuda a evitar a implementação de software não conforme no seu cluster do GKE. No entanto, recomendamos que aplique essas restrições de políticas no início do ciclo de desenvolvimento, quer em verificações pré-commit, pedidos de obtenção verificações, fluxos de trabalho de entrega ou qualquer passo que faça sentido no seu ambiente. Esta prática permite-lhe encontrar e corrigir rapidamente configurações incorretas, e ajuda a compreender a que deve prestar atenção através da criação de limites.

Considere também usar as funções kpt na sua pipeline de CI/CD para validar se os seus ficheiros de configuração do Kubernetes cumprem as restrições aplicadas pelo Policy Controller do GKE Enterprise e para estimar a utilização de recursos ou o custo de implementação. Desta forma, pode parar o pipeline quando for detetado um problema relacionado com custos. Em alternativa, pode criar um processo de aprovação de implementação diferente para configurações que, por exemplo, aumentam o número de réplicas.

Para mais informações, consulte o artigo Usar o Policy Controller numa pipeline de CI e, para ver um exemplo completo de uma plataforma de entrega, consulte o artigo CI/CD moderno com o GKE Enterprise.

Dissemine a cultura de poupança de custos

Muitas organizações criam abstrações e plataformas para ocultar a complexidade da infraestrutura. Esta é uma prática comum em empresas que estão a migrar os respetivos serviços de máquinas virtuais para o Kubernetes. Por vezes, estas empresas permitem que os programadores configurem as suas próprias aplicações em produção. No entanto, não é incomum ver programadores que nunca usaram um cluster do Kubernetes.

As práticas que recomendamos nesta secção não significam que deve parar de fazer abstrações. Em vez disso, ajudam a ver os seus gastos no Google Cloud e a formar os seus programadores e operadores na sua infraestrutura. Pode fazê-lo criando incentivos e programas de aprendizagem onde pode usar aulas tradicionais ou online, grupos de discussão, revisões por pares, programação em pares, CI/CD e gamificações de poupança de custos, entre outros. Por exemplo, no mundo do Kubernetes, é importante compreender o impacto de uma aplicação de imagem de 3 GB, de uma sondagem de prontidão em falta ou de uma configuração incorreta do HPA.

Por último, conforme demonstrado na investigação DORA da Google, as capacidades culturais são alguns dos principais fatores que geram um melhor desempenho organizacional, menos reformulação, menos esgotamento, etc. A poupança de custos não é diferente. Dar aos seus funcionários acesso aos respetivos gastos alinha-os mais estreitamente com os objetivos e as restrições da empresa.

Resumo das práticas recomendadas

A tabela seguinte resume as práticas recomendadas neste documento.

Tópico Tarefa
Funcionalidades e opções de otimização de custos do GKE
Prepare as suas aplicações Kubernetes nativas da nuvem
Monitorize o seu ambiente e aplique configurações e práticas otimizadas em função dos custos
Cultura

O que se segue?