Este documento aborda os recursos e opções do Google Kubernetes Engine (GKE) e as práticas recomendadas para executar aplicativos econômicos no GKE para aproveitar a elasticidade fornecida pelo Google Cloud. Para seguir este documento, é necessário ter familiaridade com o Kubernetes, o Google Cloud, o GKE e o escalonamento automático.
Introdução
À medida que o Kubernetes ganha a adoção generalizada, um número cada vez maior de empresas e provedores de plataforma como serviço (PaaS) e software como serviço (SaaS) está usando clusters de multilocação do Kubernetes para as cargas de trabalho. Isso significa que um único cluster pode executar aplicativos que pertencem a diferentes equipes, departamentos, clientes ou ambientes. A multilocação fornecida pelo Kubernetes permite que as empresas gerenciem alguns clusters grandes, em vez de vários menores, com benefícios como utilização apropriada de recursos, controle de gerenciamento simplificado e fragmentação reduzida.
Com o tempo, algumas empresas com clusters em rápido crescimento no Kubernetes começam a ter um aumento desproporcional no custo. Isso acontece porque as empresas tradicionais que adotam soluções baseadas na nuvem, como o Kubernetes, não têm desenvolvedores e operadores com experiência em nuvem. Essa falta de preparo para a nuvem faz com que os aplicativos se tornem instáveis durante o escalonamento automático (por exemplo, a instabilidade do tráfego durante um período normal do dia), bursts repentinos ou picos (como comerciais de TV ou eventos de grande escala, como Black Friday e Cyber Monday). Em uma tentativa de "corrigir" o problema, essas empresas tendem a provisionar os clusters da mesma maneira que em um ambiente não elástico. O provisionamento excessivo resulta em uma alocação de CPU e memória consideravelmente maior que a que os aplicativos usam para a maior parte do dia.
Neste documento, você conhecerá as práticas recomendadas para executar cargas de trabalho do Kubernetes com economia no GKE. O diagrama a seguir descreve essa abordagem.
A base da criação de aplicativos com otimização de custos está espalhando a cultura de economia de custos entre as equipes. Além de mover as discussões de custos para o início do processo de desenvolvimento, essa abordagem obriga você a entender melhor o ambiente em que seus aplicativos estão sendo executados. Nesse contexto, o ambiente do GKE.
Para conseguir baixo custo e estabilidade do aplicativo, é preciso definir ou ajustar corretamente alguns recursos e configurações (como escalonamento automático, tipos de máquina e seleção de região). Outra consideração importante é o tipo de carga de trabalho porque, dependendo do tipo de carga de trabalho e dos requisitos do aplicativo, você precisa aplicar configurações diferentes para reduzir ainda mais os custos. Por fim, é preciso monitorar seus gastos e criar proteções para que você possa aplicar as práticas recomendadas no início do ciclo de desenvolvimento.
A tabela a seguir resume os desafios que o GKE ajuda você a resolver. Recomendamos que você leia o documento inteiro. No entanto, esta tabela apresenta um mapa com os tópicos abordados.
Recursos e opções de otimização de custos do GKE
Aplicativos do Kubernetes com custo otimizado dependem muito do escalonamento automático do GKE. Para equilibrar custos, confiabilidade e escalonamento de desempenho no GKE, é preciso entender como o escalonamento automático funciona e quais opções você tem. Nesta seção, discutimos o escalonamento automático do GKE e outras configurações úteis de custo otimizado para as cargas de trabalho de veiculação e lote.
Ajustar o escalonamento automático do GKE
O escalonamento automático é a estratégia que o GKE usa para permitir que os clientes do Google Cloud paguem apenas pelo que precisam, minimizando o tempo de atividade da infraestrutura. Em outras palavras, o escalonamento automático economiza 1) fazendo com que as cargas de trabalho e a infraestrutura subjacente comecem antes que a demanda aumente e 2) desativando as cargas quando a demanda diminui.
O diagrama a seguir ilustra esse conceito. No Kubernetes, as cargas de trabalho são aplicativos em contêineres executados dentro de pods, e a infraestrutura subjacente, composta por um conjunto de nós, precisa fornecer capacidade de computação suficiente para executar as cargas de trabalho.
Como mostra o diagrama a seguir, esse ambiente tem quatro dimensões de escalonabilidade. A carga de trabalho e a infraestrutura podem ser escalonadas horizontalmente adicionando ou removendo pods ou nós. Além disso, elas podem ser escalonadas verticalmente ao aumentar e diminuir o tamanho do pod ou do nó.
O GKE lida com esses cenários de escalonamento automático usando recursos como os seguintes:
- escalonador automático de pod horizontal (HPA) para adicionar e remover pods com base em métricas de utilização.
- Escalonador automático de pod vertical (VPA), para dimensionar os pods.
- Escalonador automático do cluster, para adicionar e remover nós com base na carga de trabalho programada.
- Aprovisionamento automático de nós, para criar dinamicamente novos pools de nós com nós que correspondam às necessidades dos pods dos usuários.
O diagrama a seguir ilustra esses cenários.
Na parte restante desta seção discutimos em mais detalhes esses recursos de escalonamento automático do GKE e cobrimos outras configurações úteis de custo otimizadas para cargas de trabalho de serviço e em lote.
Escalonador automático horizontal de pods
O Escalonador automático horizontal de pods (HPA) destina-se a escalonar aplicativos em execução em pods com base em métricas que expressam carga. Configure a utilização da CPU ou outras métricas personalizadas (por exemplo, solicitações por segundo). Em resumo, o HPA adiciona e exclui réplicas de pods e é mais adequado para workers sem estado que podem ativá-lo rapidamente para reagir a picos de uso e encerrar corretamente para evitar instabilidade da carga de trabalho.
Como mostra a imagem anterior, o HPA exige um limite de utilização de destino, expresso em porcentagem, que permite personalizar quando acionar o escalonamento automaticamente. Neste exemplo, a utilização da CPU de destino é 70%. Isso significa que a carga de trabalho tem um buffer de CPU de 30% para processar solicitações enquanto novas réplicas estão aumentando. Um buffer pequeno evita o escalonamento vertical antecipado, mas pode sobrecarregar o aplicativo durante picos. No entanto, um buffer grande causa desperdício de recursos, aumentando seus custos. O destino exato é específico do aplicativo e o tamanho do buffer precisa ser suficiente para processar solicitações por dois ou três minutos durante um pico. Mesmo garantindo que seu aplicativo inicie em questão de segundos, esse tempo extra é necessário quando o escalonador automático de cluster adiciona novos nós ao cluster ou quando os pods estão limitados por falta de recursos.
A seguir, as práticas recomendadas para ativar o HPA no aplicativo:
- Dimensione o aplicativo corretamente ao definir solicitações e limites de recursos adequados.
- Defina a meta de utilização para reservar um buffer que possa processar solicitações durante um pico.
- Certifique-se de que o aplicativo inicie o mais rápido possível e desligue de acordo com as expectativas do Kubernetes.
- Defina sondas de prontidão e vivacidade significativas.
- Verifique se o servidor de métricas está sempre ativado.
- Informe aos clientes do aplicativo que eles precisam considerar implementar novas tentativas exponenciais para lidar com problemas temporários.
Para mais informações, consulte Como configurar um Escalonador automático horizontal de pods.
Autoescalonador de Pods Vertical
Ao contrário do HPA, que adiciona e exclui réplicas de pods para reagir rapidamente a picos de uso, o Autoescalonador de Pods Vertical (VPA) observa pods ao longo do tempo e encontra gradualmente os recursos ideais de CPU e memória exigidos pelos pods. Definir os recursos certos é importante para garantir a estabilidade e a eficiência de custos. Se os recursos do pod forem muito pequenos, o aplicativo poderá ser limitado ou falhar devido a erros de falta de memória. Se os recursos forem muito grandes, você terá desperdício e, consequentemente, contas maiores. O VPA é destinado a cargas de trabalho sem estado e com estado não processados pelo HPA ou quando você não conhece as solicitações de recursos do pod adequadas.
Como mostrado na imagem anterior, o VPA detecta que o pod está em execução consistentemente nos limites e recria o pod com recursos maiores. O oposto também acontece quando o pod é subutilizado de forma consistente: uma redução da escala é acionada.
A VPA pode funcionar em três modos diferentes:
- Desativado. Nesse 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 solicitações de recursos somente na criação do pod e nunca as altera posteriormente.
- Automático: o VPA atualiza as solicitações de CPU e memória durante a vida útil de um pod. Isso significa que o pod é excluído, a CPU e a memória são ajustadas e, em seguida, um novo pod é iniciado.
Se você planeja usar o VPA, a prática recomendada é começar com o modo Off para receber recomendações VPA. Certifique-se de que ele esteja em execução por 24 horas, de preferência uma semana ou mais, antes de extrair recomendações. Em seguida, somente quando você achar seguro, considere alternar para o modo Inicial ou Automático.
Siga estas práticas recomendadas para ativar o VPA no modo Initial ou Automático no seu app:
- Não use o modo VPA Initial ou Automático se precisar lidar com picos repentinos no tráfego. Em vez disso, use o HPA.
- Verifique se o aplicativo pode crescer verticalmente.
- Defina os tamanhos mínimo e máximo do contêiner nos objetos VPA para evitar que o escalonador automático faça alterações significativas quando o aplicativo não estiver recebendo tráfego.
- Não faça alterações abruptas, como descartar as réplicas do pod de 30 a 5 de uma só vez. Esse tipo de mudança requer uma nova implantação, um novo conjunto de rótulos e um novo objeto VPA.
- Certifique-se de que o aplicativo inicie o mais rápido possível e desligue de acordo com as expectativas do Kubernetes.
- Defina sondas de prontidão e vivacidade significativas.
- Verifique se o servidor de métricas está sempre ativado.
- Informe aos clientes do aplicativo que eles precisam considerar implementar novas tentativas exponenciais para lidar com problemas temporários.
- Considere usar o provisionamento automático de nós com o VPA para que, no caso de um pod ficar grande demais para caber nos tipos de máquina existentes, o escalonador automático de cluster provisione máquinas maiores que comportem o novo pod.
Se você está considerando usar o modo Automático, siga estas práticas:
- Verifique se o aplicativo pode ser reiniciado ao receber tráfego.
- Adicione o orçamento de interrupção de pods (PDB) para controlar quantos pods podem ser removidos ao mesmo tempo.
Para mais informações, consulte Como configurar o escalonamento automático vertical de pods.
Como misturar HPA e VPA
A recomendação oficial é que você não deve misturar VPA e HPA na CPU ou na memória. No entanto, você pode misturá-los com segurança ao usar o modo de recomendação no VPA ou métricas personalizadas no HPA, por exemplo, solicitações por segundo. Ao misturar o VPA com o HPA, verifique se as implantações estão recebendo tráfego suficiente, o que significa que elas estão sendo executadas consistentemente acima das réplicas mínima do HPA. Isso permite que o VPA entenda as necessidades dos recursos do pod.
Para mais informações sobre as limitações do VPA, consulte Limitações do escalonamento automático do pod vertical.
Escalonador automático de cluster
A CA, escalonador automático de cluster, redimensiona automaticamente a infraestrutura de computação subjacente. A CA fornece nós para pods que não têm um local para ser executado no cluster e remove nós subutilizados. A CA é otimizada para o custo da infraestrutura. Em outras palavras, se houver dois ou mais tipos de nó no cluster, a CA escolherá o mais barato que se encaixa na demanda especificada.
Ao contrário do HPA e do VPA, a CA não depende das métricas de carregamento. Em vez disso, ele se baseia na programação de simulação e nas solicitações de pod declaradas. É uma prática recomendada ativar a CA sempre que você estiver usando o HPA ou o VPA. Essa prática garante que, se os escalonadores automáticos de pod determinarem que você precisa de mais capacidade, sua infraestrutura subjacente aumentará de acordo com isso.
Como esses diagramas mostram, a CA adiciona e remove automaticamente a capacidade de computação para lidar com picos de tráfego e economizar seu dinheiro quando seus clientes estão dormindo. É uma prática recomendada definir o Orçamento de interrupção de pod (PDB) para todos os aplicativos. É particularmente importante na fase de redução de escala da CA quando o PDB controla o número de réplicas que podem ser removidas de uma só vez.
Determinados pods não podem ser reiniciados por escalonadores automáticos
quando eles causam alguma interrupção temporária, portanto, não é possível excluir o nó
em que eles são executados. Por exemplo, pods do sistema (como metrics-server e kube-dns) e pods que usam armazenamento local não serão reiniciados. No entanto, é possível
alterar esse comportamento
definindo PDBs
para esses pods do sistema e definindo a anotação
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
aos pods que usam o armazenamento local seguro para reiniciar o
escalonador automático. Além disso, pense em executar pods de longa duração que não podem ser reiniciados em um pool de nós separado para que eles não bloqueiem a redução de outros nós. Por fim, saiba
como analisar eventos de CA nos registros
para entender por que uma atividade de escalonamento específica não aconteceu conforme o esperado.
Se suas cargas de trabalho forem resilientes à reinicialização acidental de nós e à perda de capacidade, é possível economizar criando um cluster ou pool de nós com VMs spots. Para que a CA funcione como esperado, as solicitações de recursos do pod precisam ser grandes o bastante para que o pod funcione normalmente. Se as solicitações de recursos forem muito pequenas, os nós poderão não ter recursos suficientes e seus pods poderão falhar ou apresentar problemas durante o tempo de execução.
Veja a seguir um resumo das práticas recomendadas para ativar o escalonador automático de cluster no seu cluster:
- Use o HPA ou o VPA para escalonar automaticamente suas cargas de trabalho.
- Verifique se você está seguindo as práticas recomendadas descritas no escalonador automático do pod escolhido.
- Dimensione o aplicativo corretamente definindo solicitações e limites de recursos adequados ou use o VPA.
- Defina um PDB para seus aplicativos.
- Defina o PDB para pods do sistema que podem bloquear a redução. Por exemplo,
kube-dns. Para evitar interrupções temporárias no cluster, não defina o PDB para pods do sistema que têm apenas uma réplica (comometrics-server). - Execute pods de curta duração e pods que possam ser reiniciados em pools de nós separados, para que os pods de longa duração não bloqueiem a redução.
- Evite o provisionamento extra configurando os nós ociosos no cluster. Para isso, é preciso entender qual é a capacidade mínima (para muitas empresas, ela ocorre durante à noite) e definir o número mínimo de nós nos pools para suportar essa capacidade.
- Se você precisar de capacidade extra para lidar com solicitações durante picos, use pods de pausa, discutidos em escalonador automático e provisionamento alto.
Para mais informações, consulte Como fazer o escalonamento automático de um cluster.
Provisionamento automático de nós
O provisionamento automático de nós (NAP) é um mecanismo do escalonador automático de cluster que adiciona automaticamente novos pools de nós, além de gerenciar o tamanho deles em nome do usuário. Sem o provisionamento automático do nós, o GKE considera a inicialização de novos nós somente a partir do conjunto de pools de nós criados pelo usuário. Com esse recurso, o GKE pode criar e excluir novos pools de nós automaticamente.
O provisionamento automático de nós tende a reduzir o desperdício de recursos criando dinamicamente pools de nós que se adaptam melhor às cargas de trabalho programadas. No entanto, a latência do escalonamento automático pode ser um pouco mais alta quando é necessário criar novos pools de nós. Se as cargas de trabalho forem resilientes à reinicialização acidental de nós e à perda de capacidade, é possível reduzir ainda mais os custos configurando a tolerância de VMs Spot no pod.
Veja a seguir as práticas recomendadas para ativar o provisionamento automático de nós:
- Siga todas as práticas recomendadas do escalonador automático de cluster.
- Defina tamanhos de recursos mínimos e máximos para evitar que o NAP faça alterações significativas no cluster quando o aplicativo não estiver recebendo tráfego.
- Ao usar o escalonador automático horizontal de pods para exibir cargas de trabalho, considere reservar um buffer de utilização de destino um pouco maior, já que o NAP pode aumentar a latência do escalonamento automático em alguns casos.
Para mais informações, consulte Como usar o provisionamento automático de nós e Recursos não compatíveis.
Escalonador automático e provisionamento em excesso
Para controlar seus custos, recomendamos que você ative o escalonador automático de acordo com as seções anteriores. Nenhuma configuração se encaixa em todos os cenários possíveis, então você precisa ajustar as configurações da carga de trabalho para garantir que os escalonadores automáticos respondam corretamente ao aumento do tráfego.
No entanto, conforme observado na seção Escalonador automático horizontal de pods, os escalonamentos podem levar algum tempo devido ao provisionamento de infraestrutura. Para visualizar essa diferença no tempo e possíveis cenários de aumento de escala, considere a imagem a seguir.
Quando seu cluster tem espaço suficiente para implantar novos pods, um dos cenários de escalonamento vertical de carga de trabalho é acionado. Ou seja, se um nó atual nunca tiver implantado o aplicativo, ele precisará fazer o download das imagens de contêiner antes de iniciar o pod (cenário 1). No entanto, se o mesmo nó precisar iniciar uma nova réplica de pod do aplicativo, o tempo total de escalonamento diminui, porque não é necessário fazer o download da imagem (cenário 2).
Quando seu cluster não tem espaço suficiente para implantar novos pods, um dos cenários de infraestrutura vertical e de carga de trabalho é acionado. Isso significa que o escalonador automático de cluster precisa provisionar novos nós e iniciar o software necessário antes de abordar o aplicativo (cenário 1). Se você usar o provisionamento automático de nós, dependendo da carga de trabalho programada, novos pools de nós poderão ser necessários. Nessa situação, o tempo total de escalonamento aumenta porque o escalonador automático de cluster precisa provisionar nós e pools de nós (cenário 2).
Para cenários em que a nova infraestrutura é necessária, não sobrecarregue muito o cluster. Isso significa que você precisa provisionar em excesso, mas apenas para reservar o buffer necessário para lidar com as solicitações de pico esperadas durante os escalonamentos verticais.
Há duas estratégias principais para esse tipo de provisionamento em excesso:
Ajuste o destino de utilização do HPA. A equação a seguir é uma maneira simples e segura de encontrar um bom destino de CPU:
(1 - buff)/(1 + perc)
- buff é um buffer de segurança que pode ser definido para evitar que a CPU atinja 100%. Essa variável é útil porque alcançar 100% de CPU significa que a latência de processamento de solicitação é muito maior que a normal.
- perc é a porcentagem de crescimento do tráfego que você espera em dois ou três minutos.
Por exemplo, se você espera um crescimento de 30% nas solicitações e não quer atingir 100% da CPU definindo um buffer de segurança de 10%, sua fórmula seria assim:
(1 - 0.1)/(1 + 0.3) = 0,69
Configure a pausa de pods. Não é possível configurar o escalonador automático de cluster para processar os nós antecipadamente. Nesse caso, defina uma meta de utilização do HPA para fornecer um buffer que ajude a gerenciar picos de carga. No entanto, se você espera que ocorram vários burst, configurar uma meta de utilização de um HPA pode não ser suficiente ou pode ficar muito caro.
Uma solução alternativa para esse problema é usar pods de pausa. Pods de pausa são implantações de baixa prioridade que não fazem nada, mas reservam espaço no cluster. Sempre que um pod de alta prioridade for programado, os pods de pausa são removidos e o pod de alta prioridade imediatamente ocorre. Os pods de pausa removidos são reprogramados. Se não houver espaço no cluster, o escalonador automático de cluster gera novos nós para ajustá-los. É uma prática recomendada ter apenas um único pod de pausa por nó. Por exemplo, se você estiver usando quatro nós de CPU, configure a solicitação da CPU dos pods de pausa com aproximadamente 3200m.
Escolher o tipo de máquina certo
Além do escalonamento automático, outras configurações podem ajudar você a executar aplicativos do Kubernetes otimizados para custos no GKE. Nesta seção, você verá como escolher o tipo de máquina certo.
VMs spot
As VMs do Spot são instâncias de VM do Compute Engine que não oferecem garantias de disponibilidade. As VMs do Spot são até 91% mais baratas que as VMs padrão do Compute Engine, mas recomendamos que você as utilize com cautela nos clusters do GKE. As VMs do Spot no GKE são mais adequadas para executar jobs em lote ou tolerantes a falhas que sejam menos suscetíveis à natureza efêmera e sem garantia das VMs Spot. As cargas de trabalho com estado e de veiculação não podem usar VMs spot, a menos que você prepare o sistema e a arquitetura para processar as restrições das VMs spot.
Seja qual for o tipo de carga de trabalho, preste atenção às seguintes restrições:
- O orçamento de interrupção de pods pode não ser respeitado porque as VMs do Spot podem ser encerradas inadvertidamente.
- Não há garantia de que seus pods serão encerrados corretamente quando a preempção do nó ignora o período de carência do pod.
- Pode levar vários minutos para que o GKE detecte que o nó foi interrompido, e que os pods não estão mais em execução, o que atrasa a reprogramação dos pods em um novo nó.
A partir do GKE v1.20, o encerramento de nó otimizado é ativado por padrão para notificar as cargas de trabalho em execução.
As VMs do Spot não têm disponibilidade garantida, o que significa que elas podem ser facilmente armazenadas em algumas regiões. Para superar essa limitação, recomendamos que você defina um pool de nós de backup sem VMs Spot. O escalonador automático de cluster dá preferência às VMs Spot porque ele é otimizado para o custo da infraestrutura.
Para mais informações, consulte Executar cargas de trabalho tolerantes a falhas a custos mais baixos com VMs Spot, Executar cargas de trabalho tolerantes a falhas a custos mais baixos em pods do Spot e Executar aplicativos da Web no GKE usando VMs do Spot com custo otimizado.
Tipos de máquina E2
Tipos de máquina E2 (VMs E2) são VMs com custo otimizado que oferecem 31% de economia em comparação com tipos de máquina N1. As VMs E2 são adequadas para uma ampla variedade de cargas de trabalho, incluindo servidores da Web, microsserviços, aplicativos essenciais para os negócios, bancos de dados pequenos e médios e ambientes de desenvolvimento.
Para receber mais informações sobre VMs E2 e como elas podem ser comparadas com outros tipos de máquinas do Google Cloud, consulte Gerenciamento de recursos dinâmicos orientados por desempenho em VMs E2 e Tipos de máquina.
Selecionar a região apropriada
Quando o custo é uma restrição, em que você executa casos nos clusters do GKE. Devido a muitos fatores, o custo varia por região de computação. Portanto, execute a carga de trabalho com a opção mais cara, mas onde a latência não afeta seu cliente. Se a carga de trabalho exigir a cópia de dados de uma região para outra, por exemplo, para executar um job em lote, também será preciso considerar o custo da transferência desses dados.
Para mais informações sobre como escolher a região certa, consulte Práticas recomendadas para a seleção de regiões do Compute Engine.
Inscrever-se para descontos por uso contínuo
Se você pretende permanecer com o Google Cloud por alguns anos, recomendamos a compra de descontos por compromisso de uso para garantir preços com grande descontos para o uso da VM. Ao assinar um contrato de compromisso de uso, você compra recursos de computação por um preço com desconto (até 70% de desconto) em troca de pagar por esses recursos por um ou três anos. Se você não tiver certeza de quanto recurso será confirmado, confira seu uso mínimo de computação (por exemplo, durante a noite) e confirme o pagamento desse valor.
Para mais informações sobre preços por uso contínuo para diferentes tipos de máquina, consulte Preços de instâncias de VM.
Analisar pequenos clusters de desenvolvimento
Para pequenos clusters de desenvolvimento em que é necessário minimizar os custos, considere o uso de clusters do Autopilot. Com clusters nesse modo de operação, você não é cobrado por pods de sistema, custos de sistema operacional ou cargas de trabalho não programadas.
Revisar suas estratégias de geração de registros e monitoramento
Se você usa o Cloud Logging e o Cloud Monitoring para fornecer observabilidade nos aplicativos e na infraestrutura, você paga somente pelo que você usa. No entanto, quanto mais a infraestrutura e os aplicativos forem registrados, e quanto mais você mantiver esses registros, mais pagará por eles. Da mesma forma, quanto mais métricas externas e personalizadas você tiver, maiores serão seus custos.
Revisar o tráfego de saída entre regiões em clusters regionais e de várias zonas
Os tipos de clusters do GKE disponíveis são de zona única, multizonais e regionais. Devido à alta disponibilidade de nós nas zonas, os clusters regionais e localizados em várias zonas são adequados para ambientes de produção. No entanto, você é cobrado pelo tráfego de saída entre as zonas. Para ambientes de produção, recomendamos que você monitore a carga de tráfego entre zonas e melhore suas APIs para minimizá-la. Considere também usar configurações de afinidade e antiafinidade entre pods para localizar pods 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 maneira sugerida de monitorar esse tráfego é ativar a Medição de uso do GKE e o agente de saída da rede, que está desativado por padrão.
Em ambientes de não produção, a prática recomendada para economizar custos é implantar clusters de zona única.
Preparar o ambiente para se adequar ao tipo de carga de trabalho
As empresas têm requisitos de custo e disponibilidade diferentes. As cargas de trabalho delas podem ser divididas em cargas de trabalho de veiculação, que precisam responder rapidamente a bursts ou picos, e cargas de trabalho em lote, que geralmente se preocupam com o trabalho a ser feito. Embora as cargas de trabalho de disponibilização exijam uma pequena latência de escalonamento vertical, as carga de trabalho em lote são mais tolerantes à latência. As diferentes expectativas para esses tipos de carga de trabalho tornam a escolha de diferentes métodos de economia de custos mais flexível.
Cargas de trabalho em lote
Como as cargas de trabalho em lote estão voltadas para o trabalho, elas permitem economizar custos no GKE porque as cargas de trabalho normalmente são tolerantes a alguma latência no momento da inicialização do job. Essa tolerância dá espaço ao escalonador automático do Cluster para ativar novos nós somente quando os jobs são programados e eliminá-los quando os jobs forem concluídos.
A primeira prática recomendada é separar cargas de trabalho em lote em pools de nós diferentes usando rótulos e seletores, além de taints e tolerâncias. A lógica é a seguinte:
- O escalonador automático de cluster pode excluir nós vazios mais rapidamente quando não precisa reiniciar os pods. À medida que os jobs em lote são concluídos, o cluster acelera o processo de redução se a carga de trabalho estiver em execução em nós dedicados que estão vazios. Para melhorar ainda mais a velocidade de redução de escala, configure o perfil de otimização de utilização da CA.
- Alguns pods não podem ser reiniciados, portanto, bloqueiam permanentemente a redução dos nós. Esses pods que incluem os pods do sistema precisam ser executados em pools de nós diferentes para que não afetem a redução.
A segunda prática recomendada é usar o provisionamento automático de nós a fim de criar automaticamente pools de nós dedicados para jobs com um taint ou tolerância correspondentes. Assim, é possível separar muitas cargas de trabalho diferentes sem precisar configurar todos esses diferentes pools de nós.
Recomendamos que você use VMs spot somente se executar jobs tolerantes a falhas que sejam menos suscetíveis a essa natureza efêmera e de não garantia de VMs spot.
Como disponibilizar cargas de trabalho
Ao contrário das cargas de trabalho em lote, a disponibilização de cargas de trabalho precisa responder o mais rápido possível a bursts ou picos. Esses aumentos repentinos no tráfego podem ser resultado de muitos fatores, como comerciais de TV, eventos em grande escala, como a Black Friday, ou notícias de última hora. O aplicativo precisa estar preparado para lidar com isso.
Problemas ao lidar com esses picos costumam estar relacionados a um ou mais dos seguintes motivos:
- Aplicativos que não estão prontos para serem executados no Kubernetes. Por exemplo, apps com tamanhos de imagem grandes, tempos de inicialização lentos ou configurações que não sejam ideais para o Kubernetes.
- Aplicativos que dependem da infraestrutura que leva tempo para serem provisionados, como GPUs.
- Os escalonadores automáticos e o provisionamento em excesso não estão definidos adequadamente.
Preparar aplicativos do Kubernetes baseados na nuvem
Algumas das práticas recomendadas nesta seção podem economizar dinheiro. No entanto, como a maioria dessas práticas destina-se a fazer com que seu aplicativo funcione de maneira confiável com os escalonadores automáticos, recomendamos que você as implemente.
Compreender a capacidade do aplicativo
Ao planejar a capacidade do aplicativo, saiba quantas solicitações simultâneas seu aplicativo pode manipular, a quantidade de CPU e memória necessárias e como ele responde sob carga pesada. A maioria das equipes não conhece essas capacidades. Por isso, recomendamos que você teste o comportamento do seu aplicativo sob pressão. Tente isolar uma única réplica de pod de aplicativo com escalonamento automático desativado e execute os testes que simulam uma carga de uso real. Isso ajuda você a entender a capacidade por pod. Em seguida, recomendamos configurar o escalonador automático de cluster, as solicitações e os limites de recursos e o HPA ou VPA. Em seguida, force o aplicativo novamente, mas com mais força, para simular bursts ou picos repentinos.
Idealmente, para eliminar problemas de latência, esses testes precisam ser executados na mesma região ou zona em que o aplicativo está sendo executado no Google Cloud. É possível usar a ferramenta de sua preferência para esses testes, seja um script criado por você ou uma ferramenta de desempenho mais avançada, como o Apache Benchmark, o JMeter ou o Locust.
Para um exemplo de como executar testes, consulte Teste de carga distribuída usando o Google Kubernetes Engine.
Verificar se o aplicativo pode crescer vertical e horizontalmente
Garanta que seu aplicativo possa crescer e reduzir. Isso significa que você pode optar por processar aumentos de tráfego adicionando mais CPU e memória ou mais réplicas de pod. Isso dá a você a flexibilidade para testar melhor o que é mais adequado ao seu aplicativo, seja uma configuração diferente do escalonador automático ou um tamanho de nó diferente. Infelizmente, alguns aplicativos têm uma linha de execução ou são limitados por um número fixo de workers ou subprocessos que tornam esse experimento impossível sem uma refatoração completa da arquitetura.
Definir solicitações e limites de recursos adequados
Ao compreender a capacidade do aplicativo, é possível determinar o que será configurado nos recursos do contêiner.
Os recursos
no Kubernetes são definidos principalmente como CPU e memória (RAM). Você configura a CPU ou
a memória como a quantidade necessária para executar o aplicativo usando a solicitação
spec.containers[].resources.requests.<cpu|memory> e configura o limite
usando a solicitação spec.containers[].resources.limits.<cpu|memory>.
Quando as solicitações de recursos são definidas corretamente, o programador do Kubernetes pode usá-las para decidir em qual nó colocar o pod. Isso garante que os pods sejam colocados em nós que possam fazer com que funcionem normalmente, para você ter mais estabilidade e menos desperdício de recursos. Além disso, definir limites de recursos ajuda a garantir que esses aplicativos nunca usem toda a infraestrutura subjacente disponível fornecida pelos nós de computação.
Uma boa prática para definir os recursos de contêiner é usar a mesma quantidade de memória para solicitações e limites e um limite de CPU maior ou ilimitado. Esta implantação é usada 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 é baseado em como funciona o
processamento de recursos fora do Kubernetes. Em resumo, quando os recursos de computação se esgotam, os nós ficam instáveis. Para
evitar essa situação,
kubelet
monitora e evita a privação total desses recursos
classificando os pods que consomem recursos.
Quando a CPU é interrompida, esses pods podem ser limitados a solicitações.
No entanto, como a memória é um recurso incompactável, quando a memória é esgotada, o pod precisa ser removido. Para evitar que os pods sejam removidos e, consequentemente, estabilizar o ambiente, é preciso definir a memória solicitada como limite de memória.
Também é possível usar o VPA no modo de recomendação para ajudar a determinar o uso de CPU e da memória em um determinado aplicativo. Como o VPA fornece essas recomendações com base no uso do aplicativo, recomendamos que você o ative em um ambiente semelhante à produção para enfrentar tráfego real. Em seguida, o status do VPA gerará um relatório com as solicitações e os limites de recursos sugeridos, que você pode especificar de forma estática no manifesto de implantação. Se seu aplicativo já define o HPA, consulte Como misturar HPA e VPA.
Verificar se o contêiner está o mais enxuto possível
Quando você executa contêineres no Kubernetes, o aplicativo pode iniciar e parar a qualquer momento. Por isso, é importante seguir estas práticas recomendadas:
Tenha a menor imagem possível. É uma prática recomendada ter imagens pequenas, já que cada vez que o escalonador automático de clusters provisiona um novo nó, ele precisa fazer o download das imagens que serão executadas nele. Quanto menor a imagem, mais rápido será o download do nó.
Iniciar o aplicativo o mais rápido possível. Alguns aplicativos podem levar minutos para serem iniciados devido ao carregamento de classe, do armazenamento em cache e assim por diante. Quando um pod requer uma inicialização longa, as solicitações dos clientes podem falhar enquanto o aplicativo é inicializado.
Considere estas duas práticas ao projetar seu sistema, especialmente se você estiver esperando bursts ou picos. Ter uma imagem pequena e uma inicialização rápida ajuda a reduzir a latência de escalonamento vertical. Consequentemente, você pode processar melhor os aumentos de tráfego sem se preocupar muito com a instabilidade. Essas práticas funcionam melhor com as práticas recomendadas de escalonamento automático discutidas no escalonamento automático do GKE.
Adicionar um orçamento de interrupção de pod ao aplicativo
O orçamento de interrupção de pods (PDB) limita o número de pods que podem ser removidos simultaneamente de uma interrupção voluntária. Isso significa que o orçamento de interrupção definido é respeitado em lançamentos, upgrades de nós e em qualquer atividade de escalonamento automático. No entanto, esse orçamento não pode ser garantido quando algo involuntário acontece, como falhas de hardware, pânico do kernel ou no caso de uma pessoa ter excluído uma VM por engano.
Quando o PDB é respeitado durante a fase de compactação do escalonador automático de clusters, é uma prática recomendada definir um orçamento de interrupção de pod para cada aplicativo. Dessa forma, é possível controlar o número mínimo de réplicas necessárias para oferecer suporte à carga a qualquer momento, incluindo quando a CA está diminuindo o cluster.
Para mais informações, consulte Como especificar um orçamento de interrupção para seu aplicativo.
Definir sondagens significativas de prontidão e atividade para seu aplicativo
Definir sondagens significativas garante que o aplicativo receba tráfego somente quando estiver em execução e pronto para aceitar tráfego. O GKE usa sondagens de prontidão para determinar quando adicionar ou remover pods de balanceadores de carga. O GKE usa sondagens de ativação para determinar quando reiniciar seus pods.
A sondagem de ativação é útil para informar ao Kubernetes que um determinado pod não pode progredir, por exemplo, quando um estado de impasse é detectado. Essa sondagem é útil para informar ao Kubernetes que seu aplicativo não está pronto para receber tráfego, por exemplo, ao carregar dados de cache grandes na inicialização.
Para garantir o ciclo de vida correto do seu aplicativo durante as atividades de escalonamento vertical, é importante fazer o seguinte:
- Definir a sondagem de preparo para todos os seus contêineres.
- Se seu aplicativo depende de um cache para ser carregado na inicialização, a sondagem precisa estar pronta quando o cache estiver totalmente carregado.
- Se o aplicativo puder começar a ser veiculado imediatamente, uma boa implementação de sondagem padrão pode ser a mais simples possível, por exemplo, um endpoint HTTP que retorna um código de status 200.
- Se você implementar uma sondagem mais avançada, como verificar se o pool de conexões tem recursos disponíveis, verifique se a taxa de erro não aumenta em comparação com uma implementação mais simples.
- Nunca faça nenhuma lógica de sondagem acessar outros serviços. Ela pode comprometer o ciclo de vida do pod, caso esses serviços não respondam prontamente.
Para mais informações, consulte Configurar a ativação, prontidão e inicialização.
Verificar se os aplicativos estão sendo encerrados de acordo com as expectativas do Kubernetes
Os escalonadores automáticos ajudam você a responder aos picos, ativando novos pods e nós e excluindo-os quando os picos terminarem. Isso significa que, para evitar erros durante a veiculação dos pods, é preciso estar preparado para uma inicialização rápida ou uma desativação otimizada.
Como o Kubernetes atualiza de maneira assíncrona os endpoints e os balanceadores de carga, é importante seguir estas práticas recomendadas para garantir os desligamentos sem interrupções:
- Não pare de aceitar novas solicitações logo após
SIGTERM. Não é preciso parar o aplicativo imediatamente. Em vez disso, conclua todas as solicitações que estão em andamento e continue ouvindo as conexões recebidas que chegam após o início do encerramento do pod. Pode levar algum tempo para que o Kubernetes atualize todos os balanceadores de carga e kube-proxies. Se o aplicativo for encerrado antes da atualização, algumas solicitações poderão causar erros no lado do cliente. - Se o aplicativo não seguir a prática anterior, use o hook
preStop. A maioria dos programas não deixa de aceitar solicitações imediatamente. No entanto, se você estiver usando um código de terceiros ou gerenciando um sistema que não tem controle, como o nginx, o hookpreStopé uma boa opção para acionar o desligamento sem modificar o aplicativo. Uma estratégia comum é executar no hookpreStopa suspensão de alguns segundos para adiar oSIGTERM. Isso dá ao Kubernetes mais tempo para concluir o processo de exclusão do pod e reduz os erros de conexão no lado do cliente. - Utiliza o SIGTERM para limpeza. Se o aplicativo precisar ser limpo ou tiver um estado na memória que precise ser mantido antes do encerramento do processo, agora é a hora de fazer isso. Diferentes linguagens de programação têm maneiras diferentes de capturar esse sinal. Portanto, encontre a maneira correta na sua linguagem.
- Configure
terminationGracePeriodSecondspara atender às necessidades do seu aplicativo. Alguns aplicativos precisam de mais do que os 30 segundos padrão para serem concluídos. Nesse caso, especifiqueterminationGracePeriodSeconds. Valores altos podem aumentar o tempo para upgrades e implementações de nós, e assim por diante. Valores baixos podem não proporcionar tempo suficiente para que o Kubernetes conclua o processo de encerramento do pod. De qualquer forma, recomendamos que você defina o período de encerramento do aplicativo para menos de 10 minutos, porque o Escalonador automático de cluster o respeita apenas por 10 minutos. - Se o aplicativo usar balanceamento de carga nativo de contêiner, comece a falhar a sondagem de prontidão quando receber um SIGTERM. Essa ação sinaliza diretamente os balanceadores de carga para interromper o encaminhamento de novas solicitações para o pod de back-end. Dependendo da disputa entre a configuração da verificação de integridade e a programação do endpoint, o pod de back-end pode ser retirado de tráfego mais cedo.
Para mais informações, consulte Práticas recomendadas do Kubernetes: encerrar com carência.
Configurar o NodeLocal DNSCache
O DNS gerenciado pelo GKE é implementado por kube-dns, um complemento implantado em todos os clusters do GKE. Quando você executa aplicativos com base em DNS, a configuração kube-dns-autoscaler padrão, que ajusta o número de réplicas de kube-dns com base no número de nós e núcleos no cluster, pode não ser o suficiente. Nesse cenário, as consultas DNS podem ficar lentas ou expirar. Para atenuar esse problema, as empresas estão acostumadas a
ajustar o
ConfigMap kube-dns-autoscaler
para aumentar o número de réplicas kube-dns nos clusters. Essa estratégia pode funcionar conforme o esperado, mas aumenta o uso de recursos e o custo total do GKE.
Outra alternativa mais econômica e escalonável é configurar o
NodeLocal DNSCache
no cluster. O NodeLocal DNSCache é um complemento opcional do GKE que melhora a latência de busca DNS, torna os tempos de busca DNS mais consistentes e reduz o número de consultas DNS para kube-dns executando um cache de DNS em cada nó do cluster.
Para mais informações, consulte Como configurar o NodeLocal DNSCache.
Usar o balanceamento de carga nativo de contêiner por meio da Entrada
Balanceamento de carga nativo de contêiner permite que os balanceadores de carga segmentem os pods do Kubernetes diretamente e distribuam o tráfego aos pods por igual usando um modelo de dados chamado Grupo de endpoints de rede (NEG). Essa abordagem melhora o desempenho da rede, aumenta a visibilidade, ativa os recursos avançados de balanceamento de carga e permite o uso do Cloud Service Mesh, o plano de controle de tráfego totalmente gerenciado do Google Cloud para a malha serviço.
Devido a esses benefícios, o balanceamento de carga nativo de contêiner é a solução recomendada para balanceamento de carga por meio da Entrada. Quando os NEGs são usados com a Entrada do GKE, o controlador da Entrada facilita a criação de todos os aspectos do balanceador de carga L7. Isso inclui a criação de endereço IP virtual, regras de encaminhamento, verificações de integridade, regras de firewall e muito mais.
O balanceamento de carga nativo de contêiner se torna ainda mais importante ao usar o escalonador automático de cluster. Para balanceadores de carga que não são NEG, durante uma redução de escala, a programação de balanceamento de carga e a diminuição da conexão podem não ser totalmente concluídas antes que o escalonador automático de cluster encerre as instâncias de nó. Isso pode interromper as conexões em andamento que fluem pelo nó mesmo quando os pods de back-end não estiverem localizados nele.
O balanceamento de carga nativo de contêiner é ativado por padrão nos Serviços quando todas as condições a seguir são verdadeiras:
- Os serviços foram criados nos clusters do GKE 1.17.6-gke.7 e superior.
- Se você estiver usando clusters nativos de VPC.
- Se você não estiver usando uma VPC compartilhada.
- Se você não estiver usando a política de rede do GKE.
Para mais informações, consulte a documentação do entrada do GKE e Como usar o balanceamento de carga nativo de contêiner.
Considerar o uso de repetições com espera exponencial
Nas arquiteturas de microsserviços em exibição no Kubernetes, podem ocorrer falhas temporárias por vários motivos, como:
- Um grande pico que acionou um aumento de escala
- Falhas na rede
- As conexões caíram devido a pods não serem encerrados
- As VMs spot são encerradas acidentalmente
- Aplicativos que atingem os limites de classificação
Esses problemas são temporários, e você pode atenuá-los chamando o serviço novamente após um atraso. No entanto, para evitar sobrecarregar o serviço de destino com solicitações, é importante executar essas chamadas usando uma espera exponencial.
Para facilitar esse padrão de repetição, muitas bibliotecas atuais implementam a lógica de novo teste exponencial. Você pode usar sua biblioteca de preferência ou escrever seu próprio código. Se você usar o Istio ou o Cloud Service Mesh (ASM), poderá optar pelo mecanismo nova tentativa no nível do proxy, que executa novas tentativas de forma transparente para você.
É importante planejar seu aplicativo para aceitar novas tentativas de chamada de serviço, por exemplo, para evitar a inserção de informações já inseridas. Considere que uma cadeia de novas tentativas pode afetar a latência do usuário final, o que pode expirar se não for planejada corretamente.
Monitorar o ambiente e aplicar configurações e práticas de otimização de custos
Em muitas empresas de médio e grande porte, uma equipe de infraestrutura e plataforma centralizada geralmente é responsável por criar, manter e monitorar clusters do Kubernetes para toda a empresa. Isso representa uma forte necessidade de ter responsabilidade de uso de recursos e garantir que todas as equipes estejam seguindo as políticas da empresa. Esta seção aborda opções para monitorar e aplicar práticas relacionadas a custos.
Observar os clusters do GKE e as recomendações
É possível verificar a utilização de recursos em um cluster do Kubernetes examinando os contêineres, pods e serviços, além das características do cluster geral. Há muitas maneiras de realizar essa tarefa, mas a abordagem inicial recomendada é observar seus clusters do GKE por meio do painel do Monitoring. Assim, você terá dados de série temporal de como o cluster está sendo usado, permitindo agregar e abranger desde infraestrutura, cargas de trabalho e serviços.
Embora esse seja um bom ponto de partida, o Google Cloud oferece outras opções, por exemplo:
No console do Google Cloud, na página Clusters do GKE, consulte a coluna Notificações. Se você tiver um alto desperdício de recursos em um cluster, a IU fornecerá uma dica das informações gerais alocadas ou solicitadas.
No console do Google Cloud, na página Recomendações, procure cards de recomendações de Economias de custo.
Para mais detalhes, consulte Como observar os clusters do GKE e Introdução ao Hub de recomendação.
Ativar a medição de uso do GKE
Para uma abordagem mais flexível que permita observar os detalhamentos de custos, use a medição de uso do GKE. Com a medição de uso do GKE, é possível ver os perfis de uso dos clusters do GKE separados por namespaces e rótulos. Ela rastreia as informações sobre as solicitações e o consumo de recursos das cargas de trabalho do cluster, como CPU, GPU, TPU, memória, armazenamento e saída de rede opcional.
A medição de uso do GKE ajuda a entender a estrutura de custos geral dos clusters do GKE, qual equipe ou aplicativo gasta mais, qual ambiente ou componente levou a um pico repentino no uso ou nos custos e qual equipe está sendo desperdiçada. Ao comparar solicitações de recursos com a utilização real, é possível entender quais cargas de trabalho estão sendo pouco provisionadas ou provisionadas em excesso.
Você pode aproveitar os modelos padrão do Looker Studio ou dar um passo além e personalizar os painéis de acordo com suas necessidades organizacionais. Para mais informações sobre a medição de uso do GKE e os pré-requisitos, consulte Noções básicas sobre o uso de recursos do cluster.
Entender como funciona o Metrics Server e como monitorá-lo
O Metrics Server é a origem das métricas de recursos do contêiner para os pipelines de escalonamento automático integrados ao GKE. O Metrics Server recupera métricas de kubelets e as expõe por meio da API Metrics do Kubernetes. O HPA e o VPA usam essas métricas para determinar quando acionar o escalonamento automático.
Para a integridade do escalonamento automático do GKE, você precisa ter um Metrics Server íntegro. Com a implantação metrics-server do GKE, um assistente de redimensionamento é instalado, o que faz o contêiner do Metrics Server crescer verticalmente adicionando ou removendo a CPU e a memória de acordo com a contagem do nó do cluster. A atualização no local dos pods ainda não é compatível com o Kubernetes. Por isso, o assistente precisa reiniciar o pod metrics-server para aplicar os novos recursos necessários.
Embora a reinicialização aconteça rapidamente, a latência total para os escalonadores automáticos percebe que eles precisam executar alguma ação pode ser ligeiramente aumentada após um redimensionamento de metrics-server. Para evitar reinicializações frequentes do Metrics Server em clusters em constante mudança, a partir do GKE 1.15.11-gke.9, o assistente presta suporte a atrasos de redimensionamento.
Siga estas práticas recomendadas ao usar o Metric Server:
- Escolha a versão do GKE compatível com atrasos de redimensionamento
metrics-server. Confirme se o arquivo YAML de implantaçãometrics-servertem a configuraçãoscale-down-delayno contêinermetrics-server-nanny. - Monitore a implantação de
metrics-server. Se o Metrics Server estiver inativo, significa que nenhum escalonamento automático está funcionando. Você quer que os serviços de monitoramento de alta prioridade monitorem essa implantação. - Siga as práticas recomendadas discutidas no escalonamento automático do GKE.
Usar as cotas de recursos do Kubernetes
Em clusters multilocatários, equipes diferentes normalmente são responsáveis por aplicativos implantados em namespaces diferentes. Para uma plataforma centralizada e um grupo de infraestrutura, é importante que uma equipe não use mais recursos do que o necessário. Ignorar todos os recursos de computação do cluster ou até mesmo acionar muitos escalonamentos verticais pode aumentar seus custos.
Para solucionar esse problema, use as cotas de recursos. As cotas de recursos gerenciam a quantidade de recursos usada pelos objetos em um namespace. É possível defini-las em termos de computação (CPU e memória) e recursos de armazenamento ou nos termos das contagens de objetos. Com as cotas de recursos, é possível garantir que nenhum locatário use mais recursos do cluster do que a parcela atribuída a ele.
Para mais informações, consulte Configurar cotas de memória e CPU para um namespace.
Considere usar o Controlador de Políticas do GKE Enterprise
O Controlador de Política do GKE Enterprise é um controlador de admissão dinâmico do Kubernetes que verifica, audita e aplica a conformidade de seus clusters com políticas relacionadas à segurança, regulamentações ou regras de negócios arbitrários. O Policy Controller usa restrições para aplicar a conformidade dos clusters. Por exemplo, é possível instalar restrições no cluster para muitas das práticas recomendadas discutidas na seção Como preparar o aplicativo do Kubernetes baseado na nuvem. Dessa forma, as implantações serão rejeitadas se não seguirem estritamente suas práticas do Kubernetes. A aplicação dessas regras ajuda a evitar picos de custos inesperados e reduzir as chances de haver instabilidade da carga de trabalho durante o escalonamento automático.
Para mais informações sobre como aplicar e escrever suas próprias regras, consulte Como criar restrições e Como escrever um modelo de restrição. Se você não é um cliente do GKE Enterprise, considere usar o Gatekeeper, o software de código aberto em que o Controlador de Políticas é baseado.
Projetar seu pipeline de CI/CD para aplicar práticas de economia de custo
O Controlador de Políticas do GKE Enterprise ajuda a evitar a implantação de software não compatível no cluster do GKE. No entanto, recomendamos que você aplique essas restrições de política no início do ciclo de desenvolvimento, seja em verificações de pré-confirmação, verificações de solicitação de envio, fluxos de trabalho de entrega ou qualquer etapa que faça sentido no ambiente. Essa prática permite que você encontre e corrija erros de configuração rapidamente e ajuda a entender em que você precisa prestar atenção na criação de proteções.
Considere também usar funções kpt no pipeline de CI/CD para validar se os arquivos de configuração do Kubernetes estão em conformidade com as restrições aplicadas pelo Controlador de Políticas do GKE Enterprise e para estimar o uso de recursos ou o custo de implantação. Dessa forma, você pode interromper o pipeline quando um problema relacionado ao custo é detectado. Ou você pode criar um processo de aprovação de implantação diferente para configurações que, por exemplo, aumentam o número de réplicas.
Para mais informações, consulte Como usar o Controlador de Políticas em um pipeline de CI e, para ver um exemplo completo de uma plataforma de entrega, consulte CI/CD moderno com o GKE Enterprise.
Disseminar a cultura de economia de custos
Muitas organizações criam abstrações e plataformas para ocultar a complexidade da infraestrutura. Essa é uma prática comum nas empresas que estão migrando os serviços de máquinas virtuais para o Kubernetes. Ás vezes, essas empresas permitem que os desenvolvedores configurem os próprios aplicativos na produção. No entanto, não é incomum ver desenvolvedores que nunca tocaram em um cluster do Kubernetes.
As práticas recomendadas nesta seção não significam que você deve parar de fazer abstrações. Em vez disso, elas ajudam a visualizar seus gastos no Google Cloud e a treinar seus desenvolvedores e operadores na infraestrutura. Para fazer isso, crie incentivos e programas de aprendizado em que é possível usar classes tradicionais ou on-line, grupos de discussão, análises de pares, programação de pares, CI/CD e gama de economias, entre outros. Por exemplo, no mundo do Kubernetes, é importante entender o impacto de um aplicativo de imagem de 3 GB, uma sondagem de preparo ausente ou uma configuração incorreta de HPA.
Por fim, como mostrado na pesquisa DORA do Google, os recursos da cultura são alguns dos principais fatores que impulsionam melhor desempenho organizacional, menos retrabalho, menos estresse e etc. A economia de custos não é diferente. Conceder aos funcionários acesso aos gastos que realizaram faz com que fiquem mais alinhados com os objetivos e as restrições da empresa.
Resumo das práticas recomendadas
Na tabela a seguir, resumimos as práticas recomendadas neste documento.
A seguir
- Encontre recomendações de design e práticas recomendadas para otimizar o custo de cargas de trabalho do Google Cloud no Framework de arquitetura do Google Cloud: otimização de custos.
- Para saber como economizar dinheiro durante a noite ou em outros momentos em que o uso for menor, consulte o tutorial Como reduzir custos reduzindo os clusters do GKE fora do horário de pico.
- Para saber mais sobre o uso de VMs spot, consulte o tutorial Executar aplicativos da Web no GKE usando VMs spot com custo otimizado.
- Para entender como economizar dinheiro na geração de registros e no monitoramento, consulte Otimizar custo: Operações do Cloud.
- Para reduzir custos no Google Cloud em geral, consulte Noções básicas sobre a otimização de custos.
- Para uma discussão mais ampla sobre escalonabilidade, consulte Padrões para aplicativos escalonáveis e resilientes.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.
- Saiba mais sobre Como executar um aplicativo do GKE em VMs do Spot com nós sob demanda como substituto.