Backend

Utilizando Serverless com Knative no Kubernetes

Knative é uma plataforma que fornece uma coleção de componentes que estendem o Kubernetes, com foco no gerenciamento de serviços em nuvem. Sua principal característica é permitir um ambiente serverless no Kubernetes.

Serverless

Em uma tradução literal “sem servidor”, é uma arquitetura que permite a criação de serviços sem nos preocuparmos com a infraestrutura das aplicações. Claro, ainda é necessário um servidor para executar nossos serviços, mas com essa abordagem não precisamos nos preocupar com manutenção do servidor, provisionamento de máquinas, uso de CPU e memória.

Quais os benefícios do Serverless?

O maior benefício desse tipo de arquitetura é o Auto Scaling, que permite o aumento da capacidade de processamento do serviço, escalando mais recursos conforme o consumo do serviço aumenta e zerando após utilização.

Redução de custos

Como o termo ‘serverless’ sugere, enquanto seu serviço não é executado, ele fica desligado, e durante esse período não temos despesas com ele – somente é pago por uso, solucionando o problema que ocorre com servidores que estão sempre ligados.

Voltando para o Knative…

Em um cluster Kubernetes, para um serviço estar disponível é necessário que sempre exista pelo menos um pod do serviço executando no ambiente. Já com Knative isso não é necessário, já que ele mesmo se encarrega de dimensionar automaticamente os pods dentro do cluster, possibilitando um ambiente serverless para nossos serviços. Assim promove uma melhor utilização de recursos e redução de custos.

O que ele faz?

Knative fornece um endpoint virtual para cada serviço publicado. Quando acontece uma chamada para esses endpoints, ele verifica se existem pods suficientes para atender a demanda de requisições.

Atualmente o Knative conta com 3 componentes: Build, Serving e Eventing.

Vamos fazer uma breve análise em como Knative funciona:

  • Build: responsável por criar e manter os containers a partir do código fonte.
  • Serving: responsável por publicar e disponibilizar aplicações web serverless, (conforme descrevemos logo acima).
  • Eventing: responsável por consumir e publicar eventos assim vinculando aplicações serverless e fontes de evento.

Serving

O Knative Serving é composto por um conjunto de objetos que são utilizados para definir e controlar como como a aplicação deverá se comportar no cluster.

  • Configuration: onde é salvo o estado desejado do serviço, nele é armazenado o código e a configuração de deploy.
  • Revision: local onde fica armazenado todo histórico de mudanças do serviço. Qualquer mudança que ocorra no arquivo de configuração gera uma nova revision.
  • Route: controla o tráfego de chamada para as revisões especificas, podendo usar blue/green deploy para controle de tráfego.
  • Service: gerencia todo ciclo de vida do serviço, responsável por gerenciar quando necessário escalar um novo pod devido a demanda de uso, também gera uma nova revision sempre que ocorre um novo deploy da aplicação.

Auto scaling

Atualmente Knative suporta dois tipos de implementações para controle de escalonamento: Knative Pod Autoscaler (KPA) e Kubernetes Horizontal Pod Autoscaler (HPA).

  • Knative Pod Autoscaler (KPA): Pacote nativo do Knative Service e habilitado por default na instalação. Suporta escalonamento para zero réplicas e suporta escalonamento baseado em requests por segundos (RPS) ou requests simultâneos (concurrency)
  • Horizontal Pod Autoscaler (HPA): Para habilitar o HPA é necessário instalar o pacote após a instalação do Knative Serving. Ele não suporta escalonamento para zero réplicas e suporta escalonamento baseado em RPS, concurrency e utilização de CPU

Knative usa por padrão a métrica de requests simultâneos e a cada 100 chamadas simultâneas escalona um novo pod.

Demo

Nesta demo, vamos criar um simples serviço em GO para dizer “Hello word” e testar o escalonamento (para este exemplo, usamos o minikube como cluster).

Nesse momento nosso serviço está publicado, porém sem nenhuma replica pois ainda não recebeu nenhuma request.

Conclusão

O Knative tem a proposta de incluir um contexto serverless no cluster Kubernetes e podemos tirar muitas vantagens do seu uso, como redução de custos quando o serviço não estiver em utilização, escalabilidade conforme a demanda de processamento, mas também é preciso alguns pontos de atenção: se o serviço tem um tempo de startup elevado não é recomendado usar a opção scale-to-zero pois na primeira chamada ele precisará subir o serviço para então responder, e isso pode resultar em falha na comunicação.

%d blogueiros gostam disto: