Os pods podem ser criados como objetos autônomos ou como parte de um conjunto de réplicas escalonável ou uma implantação. Cada um dos dois últimos objetos é usado para implantar não apenas um pod, mas vários deles. O objetivo aqui é que os frutos podem ser fungíveis se um tiver muito tráfego, dois mais podem surgir e assumir o fardo extra. No entanto, é importante observar aqui que tanto o conjunto de réplicas quanto os objetos de implantação têm um número codificado de réplicas de pod que pretendem executar.

Se a contagem de réplicas for definida para 100 e a demanda for muito pequena, mesmo assim, os 100 pods estarão funcionando. Isso resulta em desperdício de recursos de CPU e memória. Sim, oferece confiabilidade, no sentido de que, se um nó falhar e os pods dentro dele morrerem, o controlador do conjunto de réplicas tentará trazer de volta o número de pods para 100, gerando pods em outros nós. O aplicativo permanece online.

Em um sentido mais abstrato, o conjunto de réplicas tentaria alcançar um Estado desejado do cluster e olharia para o Estado atual e descobrir como pode atingir o estado desejado.

No entanto, gostaríamos de algo um pouco mais sensível à demanda do mundo real. Entrar Autoescalador de pod horizontal. É função do autoescalador horizontal de pods escalonar o aplicativo quando houver necessidade e, em seguida, reduzi-lo quando a carga de trabalho cair.

Por que usar um autoescalador de pod horizontal?

Como o nome sugere, este componente escalaria seu aplicativo automaticamente. Na nuvem, isso pode realmente ajudar a reduzir os recursos de computação e memória pelos quais você será cobrado. Como o autoescalador é sensível à utilização de recursos, quando vê que muitos pods estão parados, ele reduz o aplicativo e quando a demanda nesses pods aumenta, ele dimensiona o aplicativo criando novos pods e a carga é distribuída para Essa.

Pode poupar tempo valioso e recursos de computação. Você não terá que se preocupar com qual deve ser a contagem de réplicas para seus pods ao escrever uma implantação, o autoescalador gerenciará isso para você.

Configuração inicial

O primeiro e mais importante requisito seria ter um cluster Kubernetes em execução. Use o Katacoda Playground, que é perfeito para experimentar e aprender sobre o Kubernetes. A próxima coisa que você precisaria é um servidor de métrica.

Este complemento para seu sistema Kubernetes (namespace do sistema kube) reuniria métricas como CPU e uso de memória de duas perspectivas diferentes:

1. Recurso usado por cada pod
2. Recurso consumido em cada nó

As métricas de ambas as perspectivas são cruciais para ajudar o autoescalador a decidir qual deve ser o próximo movimento. Para adicionar um servidor de métrica ao cluster Kubernetes, siga este guia. Agora estamos prontos para ver o autoescalador horizontal de pod em ação.

Usando o autoescalador

Para ver o funcionamento do autoescalador, precisamos de um aplicativo de teste. Vamos criar um servidor php-apache simples e expô-lo como um serviço.

$ kubectl run php-apache --image = k8s.gcr.io / hpa-example --requests = cpu = 200m --expose
--porta = 80

A imagem usada aqui é uma das imagens de amostra fornecidas pelo projeto Kubernetes. Ele executa algumas tarefas intensivas da CPU e torna o processo muito mais aparente ao fazer isso.

Para fazer o escalonamento automático dessa implantação, precisamos informar ao autoescalador quais são os números mínimo e máximo de pods que permitiremos e a porcentagem de CPU que eles podem usar. Existem muitos outros fatores que você pode considerar, como memória, armazenamento e rede também.

$ kubectl autoscale deployments / php-apache --cpu-percent = 50 --min = 1 --max = 10

No estado atual, uma vez que ninguém está consumindo este serviço, será preferível manter o valor mínimo. Você pode verificar o estado de todas as implantações com escalonamento automático no namespace padrão executando:

$ kubectl get hpa
NOME REFERÊNCIA TARGETS MINPODS MAXPODS REPLICAS AGE
Implantação php-apache / php-apache 0% / 50% 1 10 1 2m

Gerando carga e testando o recurso Autoscale

Você pode ver que o número de réplicas ainda é apenas uma e a carga da CPU é insignificantemente baixa. Podemos criar carga adicional e ver como o autoescalador responde a ela. O serviço que expõe nossos pods php-apache não é exposto ao mundo exterior, portanto, criaremos um pod temporário e abriremos uma sessão de shell interativa nesse pod.

Isso nos permitirá comunicar com todos os serviços disponíveis no cluster, incluindo o serviço php-apache.

$ kubectl run -i --tty busybox --image = busybox --restart = Nunca - sh
/ #

Você notará que o prompt mudará indicando que estamos dentro deste contêiner. Vamos agora tentar colocar um pouco de carga em nosso serviço, fazendo solicitações repetidamente. No novo prompt, vamos executar o seguinte loop while:

/ # enquanto verdadeiro; do wget -q -O- http: // php-apache.padrão.svc.grupo.local; feito

Abra um novo terminal, já que não podemos deixar esse loop terminar ainda. Ao inspecionar o autoescalador, você verá a utilização da CPU e, ao listar os pods, verá que agora há várias instâncias do servidor php-apache,

$ kubectl get hpa
NOME REFERÊNCIA TARGETS MINPODS MAXPODS REPLICAS AGE
Implantação php-apache / php-apache 121% / 50% 1 10 4 1h
 
$ kubectl get pods
NOME PRONTO STATUS REINICIA IDADE
busybox 1/1 Running 0 6m
php-apache-8699449574-7qwxd 1/1 Executando 0 28s
php-apache-8699449574-c9v54 1/1 Executando 0 10h
php-apache-8699449574-h9s5f 1/1 Executando 0 28s
php-apache-8699449574-sg4hz 1/1 Executando 0 28s

Encerre o loop while e o número de pods diminuirá para um em alguns minutos.

Conclusão

Essa é uma demonstração simples do autoescalador horizontal de pods. Lembre-se de ter um servidor de métricas funcional para o seu cluster e, ao criar uma implantação, mantenha a contagem de réplicas em 1. O autoescalador horizontal do pod cuidará do resto.