Este documento ajuda você a navegar pela documentação do Google Kubernetes Engine (GKE) para encontrar diretrizes e recomendações de otimização de custos. O GKE oferece recursos abrangentes de escalonamento automático e programação que podem ser usados para minimizar o custo do cluster e manter a estabilidade do aplicativo.
Para uma visão geral consolidada de todas as práticas recomendadas do GKE, consulte Práticas recomendadas para o GKE.Você já precisa conhecer os seguintes tópicos:
Visão geral
Ao implementar o GKE, é preciso considerar diferentes aspectos técnicos para se alinhar aos requisitos de aplicativos e negócios. Além de definir rede, segurança, armazenamento e outros aspectos técnicos, é preciso avaliar custo e desempenho para atender às necessidades da empresa. Em vez de tratar custo e desempenho como entidades distintas, é preciso integrá-los desde os estágios iniciais do planejamento da infraestrutura para definir uma relação unificada que determine a confiabilidade e os gastos com a nuvem. Baixo custo e alta confiabilidade são esperados, mas, à medida que você escala, a complexidade de gerenciar essa compensação aumenta.
Para conseguir baixo custo e estabilidade do aplicativo, defina ou ajuste os seguintes recursos do GKE:
- Configuração do GKE
- Configuração da carga de trabalho
- Valor de referência e visibilidade de custos
Usar o Autopilot do GKE
Para pequenos ambientes de sandbox ou desenvolvimento, selecione clusters do Autopilot. No Autopilot, o GKE gerencia os nós de forma dinâmica, e você só recebe cobranças pela capacidade de pod solicitada, o que ajuda a evitar cobranças de VM, sistema operacional do nó e sobrecarga do sistema.
Para mais informações, consulte a visão geral do Autopilot do GKE.
Entenda como o escalonamento automático funciona
Os controladores de escalonamento automático do GKE ajustam dinamicamente os recursos à medida que as solicitações de tráfego mudam.
Adicionar e remover pods com base em métricas de utilização
Um HorizontalPodAutoscaler (HPA) adiciona e remove pods com base em métricas personalizadas ou de CPU.
Para entender e configurar o escalonamento automático horizontal de pods, consulte a seguinte documentação do GKE:
- Conceitos de escalonamento automático horizontal de pods
- Configurar o escalonamento automático horizontal de pods
- Ver eventos do escalonador automático horizontal de pods
- Expor métricas de aplicativos personalizados para escalonamento automático
Configure um limite de utilização desejada (por exemplo, 70% ou 80%) para manter um buffer que processe picos de tráfego enquanto outros pods de réplica são iniciados.
Escalonar seus pods com base em métricas de utilização
Use o VerticalPodAutoscaler (VPA) para dimensionar dinamicamente as solicitações de CPU e memória do contêiner para cargas de trabalho que não usam o escalonamento automático horizontal de pods ou quando as cargas de trabalho de pico são desconhecidas.
Para entender e configurar o escalonamento automático vertical de pods, consulte a seguinte documentação do GKE:
- Conceitos do escalonamento automático vertical de pods
- Escalonar solicitações e limites de recursos de contêiner
Mantenha o VPA no modo Off (somente recomendação) por pelo menos 24 horas (idealmente uma semana) em ambientes semelhantes aos de produção para capturar padrões de tráfego representativos. Para evitar ajustes de dimensionamento irregulares, especifique limites mínimos e máximos explícitos no objeto VerticalPodAutoscaler antes de ativar os modos Initial ou Auto.
Automatizar o escalonamento da infraestrutura usando o escalonador automático de cluster
Para escalonar os nós de computação subjacentes com base na simulação de programação ativa em vez de cargas de métricas, ative o escalonador automático de cluster nos pools de nós do GKE Standard. Especifique os parâmetros mínimos de nós para oferecer suporte à capacidade básica noturna.
Sempre configure um objeto PodDisruptionBudget (PDB) para pods de sistema e de aplicativo. Essa configuração ajuda a garantir que o escalonador automático de cluster não cause interrupções acidentais no serviço ao consolidar ou reduzir pools de nós subutilizados.
Para entender e configurar o escalonador automático de cluster, consulte a seguinte documentação do GKE:
- Sobre cluster do GKE do GKE
- Como fazer o escalonamento automático de um cluster
- Visualizar eventos do escalonador automático de clusters
Implante pools de nós dinâmicos usando a criação automática de pool de nós
Ative a criação automática de pool de nós para gerar automaticamente pools de nós personalizados do GKE com formatos, contagens de CPU ou limites de memória que se ajustam precisamente aos parâmetros de programação de pods pendentes. Esse recurso minimiza os recursos restantes em nós grandes demais.
Para entender e configurar a criação automática de pool de nós, consulte a seguinte documentação do GKE:
Lista de verificação do escalonamento automático
Características da infraestrutura
Alinhe o hardware, a localização e as regras de rede do nó do cluster com as prioridades de otimização de custos.
Selecionar os tipos de máquina apropriados
Selecione os tipos de máquina adequados para seu cluster com base na localização dos usuários e dos dados que o cluster precisa acessar.
Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.
Implantar cargas de trabalho tolerantes a falhas em VMs do Spot
Use VMs spot para executar cargas de trabalho sem estado, tolerantes a falhas ou em lote com um desconto de até 91% em comparação com as instâncias de VM sob demanda.
Para mais informações, consulte a seguinte documentação do GKE:
- Conceitos de VMs spot
- Executar cargas de trabalho tolerantes a falhas a custos menores com as VMs do Spot
- Execute cargas de trabalho tolerantes a falhas a custos menores em pods do Spot
Mapear famílias de máquinas eficientes e configurações do sistema operacional
Personalize as configurações de máquina do pool de nós com perfis de instância econômicos (por exemplo, arquiteturas de VM E2).
Para mais informações sobre como dimensionar nós, configurar tempos de preempção de VM spot e configurar configurações de kernel, consulte Sobre pools de nós.
Selecionar a região apropriada
Quando a latência não afeta seus usuários, execute cargas de trabalho de cluster em regiões do Compute Engine com custos operacionais mais baixos.
Para mais informações, consulte Práticas recomendadas para a seleção de regiões do Compute Engine.
Inscrever-se no CUD
Compre descontos por compromisso de uso (CUDs) para garantir preços com grandes descontos (até 70%) nos recursos de computação básicos por um período de um ou três anos.
Para mais informações, consulte Descontos por compromisso de uso com base em recursos.
Considerar os custos de rede
Os clusters regionais e multizonais do GKE melhoram a confiabilidade dos aplicativos, mas podem gerar custos internos de saída de rede entre zonas.
Para minimizar e controlar os custos de rede, considere o seguinte:
- Transferências de dados entre zonas:embora os clusters regionais aumentem a disponibilidade ao distribuir cargas de trabalho entre zonas, há custos associados aos dados transferidos entre elas.
Para mais informações, consulte Todos os preços de rede.
Implantar clusters de zona única para ambientes que não sejam de produção
Em ambientes de não produção, para evitar cobranças de rede entre zonas e reduzir a sobrecarga de VMs, implante clusters de zona única em vez de clusters regionais ou multizonais.
Para mais informações, consulte Sobre as opções de configuração de clusters.
Otimizar caminhos de resolução de DNS do cluster e tráfego de entrada
Para otimizar a resolução de DNS do cluster e o tráfego de entrada, é possível implantar o NodeLocal DNSCache e os grupos de endpoints de rede (NEGs).
Ao executar cargas de trabalho pesadas de DNS, o NodeLocal DNSCache executa um daemon DNS local em cada nó. Essa configuração evita que cargas de consultas altas esgotem o CoreDNS, eliminando a necessidade de escalonar o CoreDNS e reduzindo os custos gerais do GKE.
Para o tráfego de entrada, o balanceamento de carga nativo de contêineres por NEGs roteia o tráfego diretamente para endereços IP de pod em vez de grupos de instâncias. Esse roteamento direto facilita o redirecionamento de tráfego sem problemas durante as ações de escalonamento de pods.
Para mais informações, consulte:
- Configurar o NodeLocal DNSCache
- Visão geral do balanceamento de carga nativo de contêiner
- Configurar o Ingress para balanceadores de carga de aplicativo externos
Aplicar cotas de recursos por namespace
Implante objetos ResourceQuota padrão do Kubernetes por namespace em clusters multitenant para bloquear os limites de forma de CPU e memória e evitar que equipes individuais programem cargas de trabalho não compatíveis que gerem custos de computação inesperados.
Para mais informações, consulte Namespaces na documentação do Kubernetes.
Implementar auditorias do Controlador de Políticas
Implante o Controlador de Políticas para auditar e aplicar dinamicamente a conformidade do cluster com os padrões corporativos. O Controlador de Políticas usa controle de admissão para rejeitar recursos mal configurados.
Para ver mais informações, consulte os seguintes tópicos:
Bloquear manifestos não compatíveis em pipelines de CI/CD
Valide a conformidade com a política de custos no início do ciclo de vida de desenvolvimento.
Integre scripts de validação (como a análise de kpt) em verificações de pré-commit ou
pull-request para auditar e bloquear manifestos não compatíveis antes que eles cheguem ao
cluster.
Para mais informações, consulte Validar apps em relação às políticas da empresa em um pipeline de CI.
Lista de verificação de infraestrutura
Otimização de aplicativos e cargas de trabalho
Configure suas cargas de trabalho para usar recursos de maneira eficiente e reduzir a sobrecarga operacional.
Especificar solicitações e limites de memória correspondentes
Especifique solicitações precisas de CPU e memória do contêiner antes da implantação. Para a CPU, configure solicitações para atender aos objetivos de nível de serviço (SLOs), mas deixe os limites irrestritos. Para memória, verifique se a alocação solicitada corresponde ao limite de memória.
Para mais informações, consulte Redimensionar recursos de CPU e memória atribuídos a contêineres na documentação do Kubernetes.
Acelerar os tempos de inicialização do contêiner
Deixe as imagens de contêiner o menor possível para minimizar os tempos de download.
Configurar PDBs
Especifique um objeto PodDisruptionBudget (PDB) para réplicas de aplicativos e limite interrupções voluntárias e garanta a estabilidade quando o GKE reduzir a escala ou quando ocorrerem upgrades de nós.
Para mais informações, consulte Como especificar um orçamento de interrupção para seu aplicativo.
Definir sondagens significativas de prontidão e atividade
Configure sondagens de atividade e prontidão para todos os contêineres e garanta que o GKE roteie o tráfego apenas para pods prontos e reinicie instâncias com falha, evitando a perda de tráfego durante o escalonamento automático.
Para mais informações, consulte Configurar sondagens de atividade, prontidão e inicialização.
Configurar o encerramento automático do aplicativo
Prepare os contêineres para o encerramento normal ouvindo o sinal SIGTERM,
finalizando as solicitações em andamento antes de sair ou configurando
hooks preStop.
Para mais informações, consulte Encerramento e encerramento completo de VMs preemptivas.
Implementar repetições com espera exponencial
Implemente novas tentativas de espera exponencial no nível do aplicativo ou da malha de serviço para lidar com falhas temporárias ou possíveis remoções de VM spot.
Para mais informações, consulte Retries (em inglês) na documentação do Istio.
Lista de verificação de otimização de aplicativos e cargas de trabalho
Valor de referência e visibilidade de custos
Para otimizar os custos, primeiro você precisa ter visibilidade dos gastos do GKE e de como eles são alocados. Essa visibilidade ajuda você a atribuir custos às equipes e unidades de negócios que os geram.
A documentação do GKE a seguir descreve como estabelecer visibilidade detalhada do faturamento, do consumo de recursos e das métricas de linha de base do GKE.
Ativar a alocação de custos do GKE
Ative a alocação de custos do GKE para ter visibilidade dos pedidos de recursos da carga de trabalho e dos custos associados. A alocação de custos atribui os custos do cluster a namespaces e rótulos do Kubernetes das suas cargas de trabalho.
Exporte esses detalhes para o BigQuery para analisar os dados no Cloud Billing. Use essa análise para identificar quais cargas de trabalho causam picos de faturamento, fazem estornos e otimizam solicitações de recursos.
Para mais informações, consulte Receber insights importantes sobre gastos para sua alocação de recursos do GKE e custos de cluster.
Analisar os volumes de ingestão de registros e métricas
Ativar o Cloud Logging e o Cloud Monitoring para seus clusters gera custos. Grandes volumes de ingestão de registros e métrica personalizada podem resultar em cobranças inesperadas. Audite centralmente quais níveis de registro e métricas personalizadas são ingeridos.
Para mais informações sobre como resolver problemas de uso excessivo da API Logging ou de tempos limite de gravação de registros, consulte:
Monitorar a integridade do Metrics Server
Monitore a integridade da implantação do Metrics Server, porque os controladores de escalonamento automático integrados do GKE dependem dele para recuperar métricas de CPU e memória.
Para mais informações, consulte Resolver problemas do escalonamento automático horizontal de pods.
Incentivar uma cultura de economia de custos
Dê aos desenvolvedores acesso a painéis de gastos na nuvem e estabeleça um treinamento de FinOps para alinhar as decisões arquitetônicas com os orçamentos de custos comerciais.
Para mais informações sobre a cultura de eficiência de custos organizacionais, consulte Disseminar a cultura de economia de custos.
Lista de verificação de visibilidade e valor de referência de custo
A seguir
Para mais informações sobre os princípios arquitetônicos e a cultura organizacional necessários para a eficiência de custos, consulte Práticas recomendadas para executar aplicativos do Kubernetes otimizados para custo no GKE.