Conceito - Implantar aplicativo
Antes de implantar seu aplicativo no Kubernetes, vamos analisar as implantações do Kubernetes e discutir suas limitações em nosso cenário.
O que são implantações do Kubernetes?
Uma implantação do Kubernetes é uma evolução dos pods. As implantações envolvem os pods em um objeto inteligente que permite a expansão. Você pode facilmente duplicar e dimensionar seu aplicativo para suportar mais carga sem a necessidade de configurar regras de rede complexas.
As implantações permitem que você atualize seus aplicativos sem tempo de inatividade apenas alterando a tag de imagem. A atualização de uma implantação desativa os aplicativos on-line um a um e os substitui pela versão mais recente, em vez de excluir todos os aplicativos e criar novos, o que significa que a implantação pode atualizar os pods dentro dele sem efeito visível na disponibilidade.
Embora haja muitos benefícios em usar implantações em pods, elas não são capazes de lidar adequadamente com nosso cenário.
Esse cenário envolve um aplicativo controlado por eventos que recebe um grande número de eventos em vários momentos. Sem um objeto KEDA Scaler ou HPA, você precisaria ajustar manualmente o número de réplicas para processar o número de eventos e reduzir a implantação quando a carga voltar ao normal.
Exemplo de manifesto de implantação
Aqui está um trecho de exemplo do nosso manifesto de implantação:
apiVersion: apps/v1
kind: Deployment
metadata:
name: contoso-microservice
spec:
replicas: 10 # Tells K8S the number of pods needed to process the Redis list items
selector: # Define the wrapping strategy
matchLabels: # Match all pods with the defined labels
app: contoso-microservice # Labels follow the `name: value` template
template: # Template of the pod inside the deployment
metadata:
labels:
app: contoso-microservice
spec:
containers:
- image: mcr.microsoft.com/mslearn/samples/redis-client:latest
name: contoso-microservice
No manifesto de amostra, replicas é definido como 10, que é o maior número que podemos definir para as réplicas necessárias disponíveis para processar o número de pico de eventos. No entanto, isso faz com que o aplicativo consuma muitos recursos fora dos horários de pico, o que pode privar outras implantações dentro do cluster.
Uma solução é usar um HPA autônomo para monitorar o uso da CPU dos pods, o que é uma opção melhor do que o dimensionamento manual em ambas as direções. No entanto, a HPA não se concentra no número de eventos recebidos na lista Redis.
A melhor solução é usar o KEDA e um escalador Redis para consultar a lista e determinar se mais ou menos pods são necessários para processar os eventos.