Implemente a ferramenta de redimensionamento automático no GKE

O modelo de implementação do Google Kubernetes Engine (GKE) é uma boa escolha para equipas independentes que querem autogerir a infraestrutura e a configuração dos seus próprios escaladores automáticos no Kubernetes.

Este documento faz parte de uma série que também inclui:

Esta série destina-se a equipas de TI, operações e engenharia de fiabilidade do site (SRE) que querem reduzir as despesas gerais operacionais e otimizar o custo das implementações do Spanner.

A implementação do GKE tem as seguintes vantagens e desvantagens:

Vantagens:

  • Baseado no Kubernetes: para equipas que podem não conseguir usar serviços como as funções do Cloud Run, a implementação no Kubernetes permite a utilização do redimensionador automático.
  • Configuração: o controlo sobre os parâmetros do programador pertence à equipa proprietária da instância do Spanner, o que lhe confere os privilégios mais elevados para adaptar o escalador automático às suas necessidades.

Desvantagens:

  • Infraestrutura: em comparação com a conceção das funções do Cloud Run, são necessários alguns serviços e infraestruturas de longa duração.
  • Manutenção: como cada equipa é responsável pela configuração e pela infraestrutura do escalador automático, pode ser difícil garantir que todos os escaladores automáticos da empresa seguem as mesmas diretrizes de atualização.
  • Auditoria: devido ao elevado nível de controlo de cada equipa, uma auditoria centralizada pode tornar-se mais complexa.

Esta página apresenta duas formas de implementar o autoscaler no GKE com base nos seus requisitos:

  • Uma topologia de implementação dissociada. O modelo de implementação dissociado tem a vantagem de poder atribuir autorizações individuais aos componentes Poller e Scaler para que sejam executados como contas de serviço separadas. Isto significa que tem flexibilidade para gerir e dimensionar os dois componentes de acordo com as suas necessidades. No entanto, este modelo de implementação requer que o componente Scaler seja implementado como um serviço de execução prolongada, que consome recursos.
  • Uma topologia de implementação unificada. O modelo de implementação unificado tem a vantagem de que os componentes Poller e Scaler podem ser implementados como um único pod, que é executado como uma tarefa cron do Kubernetes. Quando os dois componentes são implementados como um único pod, não existem componentes de execução prolongada e apenas é necessária uma única conta de serviço.

Para a maioria dos exemplos de utilização, recomendamos o modelo de implementação unificado.

Configuração

A ferramenta de escala automática gere instâncias do Spanner através da configuração definida num Kubernetes ConfigMap. Se forem necessárias várias instâncias do Spanner com o mesmo intervalo, recomendamos que as configure no mesmo ConfigMap. Segue-se um exemplo de uma configuração em que duas instâncias do Spanner são geridas com uma configuração:

apiVersion: v1
kind: ConfigMap
metadata:
  name: autoscaler-config
  namespace: spanner-autoscaler
data:
  autoscaler-config.yaml: |
    ---
    - projectId: spanner-autoscaler-test
      instanceId: spanner-scaling-linear
      units: NODES
      minSize: 5
      maxSize: 30
      scalingMethod: LINEAR
    - projectId: spanner-autoscaler-test
      instanceId: spanner-scaling-threshold
      units: PROCESSING_UNITS
      minSize: 100
      maxSize: 3000
      metrics:
      - name: high_priority_cpu
        regional_threshold: 40
        regional_margin: 3

Uma instância pode ter uma configuração do escalador automático com o método linear para operações normais e também ter outra configuração do escalador automático com o método direto para cargas de trabalho em lote planeadas. Veja a lista completa de opções de configuração no ficheiro Poller README.

Implemente no GKE

Para saber como implementar o escalador automático no GKE no modelo de implementação dissociado ou unificado, consulte o guia passo a passo para a implementação do GKE.

O que se segue?