[Nota do editor: esta é uma das diversas postagens sobre as novas possibilidades oferecidas pelo Kubernetes 1.10. Para ver todos os detalhes, clique aqui.]

 Muitos clientes do Kubernetes Engine, principalmente empresas, precisam fazer o escalonamento automático dos ambientes não só se acordo com o uso de CPU, mas também com coisas como tamanho da fila ou conexões permanentes simultâneas. No Kubernetes Engine 1.9, começamos a adicionar recursos para resolver esse problema e, hoje, com a mais recente versão beta do Horizontal Pod Autoscaler (HPA) no Kubernetes Engine 1.10, você passa a poder configurar suas implementações para se dimensionarem no sentido horizontal de várias formas diferentes.

Para ajudar você a entender melhor as diversas opções de escalonamento horizontal, temos aqui a Barbara, engenheira de DevOps que trabalha em uma multinacional de transmissão de vídeo. A Barbara executa seu ambiente no Kubernetes Engine, incluindo os microsserviços abaixo:
  • Um serviço de transcodificação de vídeo que processa vídeos recém-publicados.
  • Uma fila do Google Cloud Pub/Sub para a lista de vídeos que o serviço de transcodificação precisa processar
  • Um front-end de exibição do vídeo que transmite os vídeos para os usuários
Um diagrama superficial do aplicativo da Barbara.

Para ter certeza de cumprir o acordo de nível de serviço quanto à latência no processamento dos carregamentos (que a empresa dela define como tempo total de viagem do arquivo carregado), a Barbara configura o serviço de transcodificação de forma a se dimensionar horizontalmente com base no tamanho da fila, adicionando réplicas quando há mais vídeos para processar e removendo outras (e economizando) quando a fila é menor. No Kubernetes Engine 1.10, ela faz isso usando o novo tipo de métrica "External" para configurar o Horizontal Pod Autoscaler. Leia mais sobre o assunto aqui.

apiVersion: autoscaling/v2beta1                                                 
kind: HorizontalPodAutoscaler                                                   
metadata:                                                                       
  name: transcoding-worker                                                                    
  namespace: video                                                            
spec:                                                                           
  minReplicas: 1                                                                
  maxReplicas: 20                                                                
  metrics:                                                                      
  - external:                                                                      
      metricName: pubsub.googleapis.com|subscription|num_undelivered_messages   
      metricSelector:                                                           
        matchLabels:                                                            
          resource.labels.subscription_id: transcoder_subscription                            
      targetAverageValue: "10"                                                   
    type: External                                                              
  scaleTargetRef:                                                               
    apiVersion: apps/v1                                              
    kind: Deployment                                                            
    name: transcoding-worker
Para gerenciar as reduções de escala da forma certa, a Barbara também não deixa de usar períodos de carência para o encerramento de pods longos o suficiente para que as transcodificações já em andamento nos pods sejam concluídas. Ela também programa seu aplicativo para parar de processar novos itens da fila quando receber o sinal de encerramento SIGTERM do Kubernetes Engine.
Um diagrama geral do aplicativo da Barbara mostrando o gargalo de escalonamento.

Quando os vídeos são transcodificados, a Barbara precisa garantir uma experiência de visualização excelente para os usuários. Ela identifica o gargalo do front-end de exibição: o número de conexões permanentes simultâneas que uma única réplica consegue gerenciar. Cada um dos pods já expõe o número atual de conexões abertas, assim ela configura o objeto HPA para manter o valor médio de conexões abertas por pod em um nível confortável. Para fazer isso, ela usa o tipo de métrica personalizada "Pods".

apiVersion: autoscaling/v2beta1                                                 
kind: HorizontalPodAutoscaler                                                   
metadata:                                                                       
  name: frontend                                                                    
  namespace: video                                                            
spec:                                                                           
  minReplicas: 4                                                                
  maxReplicas: 40                                                                
  metrics:  
  - type: Pods
    pods:
      metricName: open_connections
      targetAverageValue: 100                                                                                                                            
  scaleTargetRef:                                                               
    apiVersion: apps/v1                                              
    kind: Deployment                                                            
    name: frontend
Para dimensionar com base no número de conexões permanentes simultâneas da forma desejada, a Barbara também usa sondas de prontidão de forma que possíveis pods saturados sejam removidos temporariamente do serviço até que a situação melhore. Ela também garante que o cliente transmissor possa se recuperar rapidamente se o pod de exibição atual tiver as dimensões reduzidas.

Um ponto importante aqui é que os pods dela expõem a métrica "open_connections" como um ponto de extremidade do Prometheus a monitorar. A Barbara usa o secundário (sidecar) "prometheus-to-sd" para disponibilizar essas métricas no Stackdriver. Para fazer isso, ela adiciona o YAML a seguir à configuração de implantação do front-end. Se quiser ver mais formas de exportar métricas e usá-las no escalonamento automático, clique aqui.

containers:
  ...
  - name: prometheus-to-sd
    image: gcr.io/google-containers/prometheus-to-sd:v0.2.6
    command:
    - /monitor
    - --source=:http://localhost:8080
    - --stackdriver-prefix=custom.googleapis.com
    - --pod-id=$(POD_ID)
    - --namespace-id=$(POD_NAMESPACE)
    env:
    - name: POD_ID
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.uid
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
Recentemente, a empresa da Barbara lançou um novo recurso: a transmissão de vídeos ao vivo. Isso gera um novo gargalo ao front-end de exibição. Agora, o front-end precisa transcodificar alguns fluxos em tempo real, o que consome muitos recursos da CPU e reduz o número de conexões que uma única réplica consegue gerenciar.
Um diagrama geral do aplicativo da Barbara que mostra o novo gargalo devido à transcodificação ativa em tempo real da CPU.
Para resolver isso, a Barbara usa um recurso do Horizontal Pod Autoscaler para dimensionar de acordo com diversas métricas ao mesmo tempo (nesse caso, o número de conexões permanentes e o consumo de CPU). O HPA seleciona o maior sinal dos dois, que é usado para ativar o escalonamento automático:

apiVersion: autoscaling/v2beta1                                                 
kind: HorizontalPodAutoscaler                                                   
metadata:                                                                       
  name: frontend                                                                    
  namespace: video                                                            
spec:                                                                           
  minReplicas: 4                                                                
  maxReplicas: 40                                                                
  metrics:  
  - type: Pods
    pods:
      metricName: open_connections
      targetAverageValue: 100
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 60                                                                                                                        
  scaleTargetRef:                                                               
    apiVersion: apps/v1                                              
    kind: Deployment                                                            
    name: frontend
Esses são só alguns dos cenários em que o HPA no Kubernetes pode ajudar bastante.

Faça um test drive

Experimente o Kubernetes Engine hoje mesmo com a nossa versão experimental generosa (12 meses grátis) de US$ 300 em créditos. Processe um cluster (ou vários) e veja a diferença de executar o Kubernetes no Google Cloud, a nuvem feita para contêineres. E não deixe de voltar aqui para ver novas postagens sobre como usar o Cluster Autoscaler e o Horizontal Pod Autoscaler juntos para extrair o máximo do Kubernetes Engine.