Conceito – Implantar o aplicativo

Concluído

Antes de você implantar seu aplicativo no Kubernetes, vamos examinar as Implantações do Kubernetes e conversar sobre suas limitações no nosso cenário.

O que são as Implantações do Kubernetes?

Uma Implantação do Kubernetes é uma evolução dos pods. As implantações encapsulam os pods em um objeto inteligente que permite seu escalonamento horizontal. Você pode duplicar e escalar o seu aplicativo com facilidade para dar suporte a 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. Atualizar uma Implantação desativa os aplicativos online 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 dela sem nenhum efeito visível sobre a disponibilidade.

Embora existam muitos benefícios de seu uso, as Implantações por meio de pods não são capazes de lidar adequadamente com o nosso cenário.

Esse cenário envolve um aplicativo impulsionado por eventos que recebe um grande número de eventos em vários momentos. Sem um objeto Dimensionador KEDA ou HPA, você precisaria ajustar o número de réplicas manualmente para processar o número de eventos e reduzir verticalmente a Implantação quando a carga retorna ao normal.

Amostra de manifesto de Implantação

Aqui temos uma amostra de snippet de código 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

Na amostra de manifesto, o número de replicas está definido como 10, que é o número mais alto que podemos definir para as réplicas necessárias disponíveis para processar o número máximo de eventos. No entanto, isso faz com que o aplicativo consuma muitos recursos durante períodos sem pico, o que poderá deixar outras Implantações à míngua dentro do cluster.

Uma solução é usar um HPA autônomo para monitorar o uso da CPU dos pods, que é uma opção melhor do que escalonar manualmente em ambas as direções. No entanto, o HPA não se concentra no número de eventos recebidos na lista do Redis.

A melhor opção é usar o KEDA e um dimensionador do Redis para consultar a lista e determinar se mais ou menos pods são necessários para processar os eventos.