GSP768

Visão geral

O Google Kubernetes Engine tem soluções horizontais e verticais para escalonar automaticamente os pods e a infraestrutura. Quando o assunto é otimização de custos, essas ferramentas são muito úteis para que as cargas de trabalho sejam executadas com máxima eficiência e você pague apenas pelo que usar.

Neste laboratório, você vai configurar e observar os escalonamentos automáticos horizontal e vertical no nível do pod e também o escalonador automático de clusters (solução de infraestrutura horizontal) e o provisionamento automático de nós (solução de infraestrutura vertical) no nível do nó. Primeiro, você vai usar essas ferramentas de escalonamento automático para poupar o máximo de recursos possível e reduzir o tamanho do cluster durante um período de baixa demanda. Depois, você vai aumentar as demandas do cluster e observar como o escalonamento automático mantém a disponibilidade.

Conteúdo

• Reduzir o número de réplicas de uma implantação com o escalonador automático horizontal de pods
• Diminuir a solicitação de CPU de uma implantação com o escalonador automático vertical de pods
• Reduzir o número de nós usados no cluster com o escalonador automático de clusters
• Criar automaticamente um pool de nós otimizado para cargas de trabalho com o provisionamento automático de nós
• Testar o comportamento do escalonamento automático em um pico de demanda
• Aumentar o provisionamento do cluster com pods de pausa

Configuração e requisitos

Antes de clicar no botão Start Lab

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

• Acesso a um navegador de Internet padrão (recomendamos o Chrome).

Observação: para executar este laboratório, use o modo de navegação anônima ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.

Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você verá o seguinte:

   • O botão Abrir Console do Cloud
   • Tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações se forem necessárias

2. Clique em Abrir Console do Google. O laboratório ativa recursos e depois abre outra guia com a página Fazer login.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Caso seja preciso, copie o Nome de usuário no painel Detalhes do laboratório e cole esse nome na caixa de diálogo Fazer login. Clique em Avançar.

4. Copie a Senha no painel Detalhes do laboratório e a cole na caixa de diálogo Olá. Clique em Avançar.

   Importante: você precisa usar as credenciais do painel à esquerda. Não use suas credenciais do Google Cloud Ensina. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

5. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do GCP vai ser aberto nesta guia.

Observação: para ver uma lista dos produtos e serviços do Google Cloud, clique no Menu de navegação no canto superior esquerdo.

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.

Depois de se conectar, vai notar que sua conta já está autenticada, e que o projeto está configurado com seu PROJECT_ID. A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

2. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

3. Clique em Autorizar.

4. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = <project_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

Provisione o ambiente de teste

1. Defina sua zona padrão como :

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. Execute o seguinte comando para criar um cluster de três nós na zona :

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

Para demonstrar o escalonamento automático horizontal de pods, este laboratório usa uma imagem Docker personalizada com base na imagem do php-apache. Ela define uma página index.php que executa alguns cálculos com uso intensivo da CPU. Você vai monitorar uma implantação dessa imagem.

3. Crie um manifesto para a implantação do php-apache:

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache EOF

4. Aplique o manifesto criado ao cluster:

kubectl apply -f php-apache.yaml

Clique em Verificar meu progresso para conferir se você executou a tarefa. Provisione o ambiente de teste.

Tarefa 1: use o escalonamento automático horizontal de pods

O Escalonamento automático horizontal de pods muda a forma da carga de trabalho do Kubernetes, aumentando ou diminuindo automaticamente o número de pods em resposta ao consumo de memória ou CPU da carga de trabalho ou às métricas personalizadas informadas no Kubernetes ou às métricas externas fora do cluster.

1. No Cloud Shell, execute este comando para inspecionar as implantações do cluster:

kubectl get deployment

A implantação do php-apache vai aparecer com 3/3 pods em execução:

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s Observação: se você não encontrar três pods disponíveis, aguarde um minuto até que eles sejam criados e use o comando anterior outra vez. Se 1/1 pod estiver disponível, é provável que terá passado tempo suficiente para o escalonamento vertical da sua implantação ser reduzido.

2. Aplique o escalonamento automático horizontal à implantação do php-apache:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Clique em Verificar meu progresso para conferir se você executou a tarefa. Use o escalonamento automático horizontal de pods.

O comando autoscale configura um escalonador automático horizontal de pods (HPA) que mantém de uma a 10 réplicas dos pods controladas pela implantação do php-apache. A sinalização cpu-percent especifica 50% como a meta média de utilização da CPU solicitada em todos os pods. O HPA ajusta o número de réplicas (via implantação) para manter uma utilização média da CPU de 50% em todos os pods.

3. Verifique o status atual do seu escalonador automático horizontal de pods:

kubectl get hpa

Na coluna Destinos, você vai encontrar 1%/50%.

Isso significa que os pods da sua implantação estão em 1% do uso médio desejado da CPU. Isso é esperado porque o app php-apache não está recebendo tráfego no momento.

Observação: se aparecer <unknown>/50%, aguarde um minuto e execute o comando kubectl get hpa de novo. O HPA ainda não criou uma avaliação.

Além disso, observe a coluna Replicas. No início, o valor será 3. Esse número será alterado pelo escalonador automático à medida que o número de pods necessários mudar.

Nesse caso, o escalonador automático reduz o escalonamento vertical da implantação até o número mínimo de pods indicado quando você executa o comando autoscale. O Escalonamento automático horizontal de pods leva de 5 a 10 minutos e requer o desligamento ou a inicialização de novos pods, dependendo de como está escalonando.

Vá para a próxima etapa do laboratório. Você vai inspecionar os resultados do escalonador automático mais adiante.

Observação: embora você esteja usando cpu-percent como a métrica desejada do escalonador automático neste laboratório, o HPA permite a definição de métricas personalizadas para escalonar seus pods com base em outras métricas úteis capturadas nos registros.

Tarefa 2: mude o tamanho com o escalonamento automático vertical de pods

Com o Escalonamento automático vertical de pods, você não precisa se preocupar com os valores a serem especificados para as solicitações de memória e CPU de um contêiner. O escalonador automático (VPA, na sigla em inglês) pode recomendar valores para as solicitações e os limites de CPU e memória ou atualizar os valores automaticamente.

Observação: o escalonamento automático vertical de pods não deve ser usado com o horizontal na CPU ou na memória. Os dois tentarão responder às mudanças na demanda das mesmas métricas e vão entrar em conflito. No entanto, o VPA na CPU ou na memória pode ser usado com o HPA em métricas personalizadas para evitar sobreposição.

O Escalonamento automático vertical de pods já foi ativado no cluster scaling-demo.

1. Para verificar isso, execute:

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

A resposta será enabled: true.

Observação: o escalonamento automático vertical de pods pode ser ativado em um cluster com gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling

Para demonstrar o VPA, implante o app hello-server.

2. Aplique a implantação do hello-server ao seu cluster:

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. Verifique se a implantação foi criada:

kubectl get deployment hello-server

4. Atribua uma solicitação de recurso de CPU de 450m à implantação:

kubectl set resources deployment hello-server --requests=cpu=450m

5. Em seguida, execute este comando para inspecionar as especificidades dos pods de hello-server do contêiner:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• Na resposta, encontre Requests. Observe que esse pod está solicitando a CPU 450m que você atribuiu.

6. Agora crie um manifesto no seu escalonador automático vertical de pods:

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

O exemplo acima gera um manifesto para um VPA destinado à implantação do hello-server com uma política de atualização Off. Um VPA pode ter uma destas três políticas de atualização, que são úteis dependendo do seu aplicativo:

• Off: nesta política, o VPA gera recomendações com base em dados históricos que você pode aplicar manualmente.
• Initial: as recomendações do VPA serão usadas para criar novos pods uma vez e não mudarão o tamanho deles.
• Auto: os pods serão excluídos e recriados regularmente para corresponder ao tamanho das recomendações.

7. Aplique o manifesto para hello-vpa:

kubectl apply -f hello-vpa.yaml

8. Aguarde um minuto e visualize o VerticalPodAutoscaler:

kubectl describe vpa hello-server-vpa

Localize "Container Recommendations" no final da resposta. Se não aparecer, aguarde um pouco mais e tente executar o comando anterior novamente. Quando aparecer, você verá vários tipos de recomendação, cada um com valores de CPU e memória:

• Lower Bound: é o número do limite inferior que o VPA procura para acionar um redimensionamento. Se a utilização do seu pod ficar abaixo disso, o VPA excluirá o pod e reduzirá o escalonamento vertical dele.
• Target: é o valor que o VPA usará ao redimensionar o pod.
• Uncapped Target: se nenhuma capacidade mínima ou máxima for atribuída ao VPA, essa será a meta de utilização para ele.
• Uncapped Target: é o número do limite superior que o VPA procura para acionar um redimensionamento. Se a utilização do seu pod ultrapassar esse valor, o VPA excluirá e escalonará o pod verticalmente.

Você perceberá que o VPA recomenda que a solicitação de CPU para esse contêiner seja definida como 25m, em vez do valor 100m anterior, além de sugerir um volume de memória a ser solicitado. No momento, essas recomendações podem ser aplicadas manualmente à implantação do hello-server.

Observação: o escalonamento automático vertical de pods baseia as recomendações nos dados históricos do contêiner. Na prática, recomendamos aguardar pelo menos 24 horas para coletar os dados de recomendação antes de aplicar qualquer mudança.

9. Para acompanhar o VPA e os efeitos dele neste laboratório, mude a política de atualização hello-vpa para Auto e observe o escalonamento.

10. Atualize o manifesto para definir a política como Auto e aplique a configuração:

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

Para redimensionar um pod, o escalonador automático vertical de pods precisa excluir e recriar o pod com o novo tamanho. Por padrão, para evitar inatividade, o VPA não excluirá nem redimensionará o último pod ativo. Por isso, você precisará de pelo menos duas réplicas para ver o VPA fazer mudanças.

11. Faça o escalonamento da implantação de hello-server para duas réplicas:

kubectl scale deployment hello-server --replicas=2

12. Agora confira os pods:

kubectl get pods -w

13. Aguarde até aparecerem os pods de hello-server-xxx no status terminating ou pending (ou acesse Kubernetes Engine > Cargas de trabalho):

Esse é um sinal de que o VPA está excluindo e redimensionando seus pods. Depois de ver isso, pressione Ctrl + c para sair do comando.

Clique em Verificar meu progresso para conferir se você executou a tarefa. Mude o tamanho com o escalonamento automático vertical de pods.

Tarefa 3: resultados do HPA

Neste momento, o escalonador automático horizontal de pods provavelmente terá reduzido o escalonamento vertical da implantação do php-apache.

1. Execute este comando para verificar o HPA:

kubectl get hpa

• Observe a coluna Replicas. Repare que o escalonamento vertical da sua implantação do php-apache foi reduzido a um pod.

Observação: se ainda aparecerem três réplicas para a implantação do php-apache, aguarde mais alguns minutos até o escalonador automático agir.

• O HPA aproveita que o app está inativo e remove todos os recursos não utilizados. Além disso, se o app php-apache tivesse mais demanda, ele seria escalonado novamente de acordo com a carga.

Observação: se você se preocupa com a disponibilidade do seu aplicativo, deixe um buffer um pouco maior como o número mínimo de pods para que o escalonador automático horizontal de pods considere o tempo necessário para escalonar.

Isso é extremamente útil para a otimização de custos. Um escalonador automático bem ajustado mantém a alta disponibilidade do seu aplicativo, e você só paga pelos recursos necessários para manter essa disponibilidade em qualquer demanda.

Tarefa 4: resultados do VPA

O VPA deve ter redimensionado seus pods na implantação do hello-server.

1. Inspecione seus pods:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. Encontre o campo Requests:.

• O escalonador automático vertical de pods recriou os pods com as respectivas metas de utilização. Agora ele deve solicitar um volume menor de CPU e uma determinada quantidade de memória:

Requests: cpu: 25m memory: 262144k Observação: se você ainda receber uma solicitação de CPU de 450m para qualquer um dos pods, defina manualmente o recurso de CPU para o destino com este comando: kubectl set resources deployment hello-server --requests=cpu=25m Às vezes, o VPA no modo automático pode demorar muito ou definir valores imprecisos de limites superiores ou inferiores, sem tempo para coletar dados precisos. Para não perder tempo no laboratório, use a recomendação como se ela estivesse no modo "Off".

Nesse caso, o VPA se torna uma ferramenta excelente para otimizar a utilização de recursos e, na verdade, reduzir custos. A solicitação original de 400m de CPU era maior do que a necessidade do contêiner. Ao ajustar a solicitação para o valor 25m recomendado, você usa menos CPU do pool de nós, possivelmente a ponto de exigir o provisionamento de menos nós no cluster.

Com a política de atualização "Auto", o VPA continuaria excluindo e redimensionando os pods da implantação do hello-server durante todo o ciclo de vida. Ele poderia escalonar os pods verticalmente com solicitações maiores para gerenciar o tráfego pesado, depois reduzi-los durante uma inatividade. Isso pode ser ótimo para lidar com os aumentos constantes de demanda do seu aplicativo, mas corre o risco de perder disponibilidade durante picos intensos.

Dependendo do aplicativo, geralmente é mais seguro usar o VPA com a política de atualização Off e seguir as recomendações conforme necessário para otimizar o uso de recursos e maximizar a disponibilidade do cluster.

Nas próximas seções, você vai aprender a otimizar ainda mais a utilização de recursos com o escalonador automático de clusters e o provisionamento automático de nós.

Tarefa 5: escalonador automático de clusters

O escalonador automático de clusters foi projetado para adicionar ou remover nós com base na demanda. O escalonador automático de clusters adiciona nós ao pool para atender a uma alta demanda. Quando a demanda é baixa, ele reduz o escalonamento do cluster removendo nós. Dessa forma, é possível manter a alta disponibilidade do cluster e, ao mesmo tempo, minimizar os custos supérfluos associados a máquinas adicionais.

1. Ative o escalonamento automático para seu cluster:

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

Esse processo leva alguns minutos.

Ao escalonar um cluster, a decisão de quando remover um nó está relacionada à otimização do uso ou à disponibilidade de recursos. Remover nós subutilizados melhora o uso do cluster, mas talvez novas cargas de trabalho precisem esperar que os recursos sejam provisionados novamente antes de serem executadas.

Ao tomar essas decisões, especifique qual perfil de escalonamento automático deve ser usado. Os perfis disponíveis no momento são:

• Balanced: o perfil padrão.
• Optimize-utilization: prioriza a otimização do uso em vez de manter recursos extras no cluster. Quando selecionado, o escalonador automático de clusters reduz o escalonamento vertical de forma mais agressiva. Ele pode remover mais nós com mais rapidez. Esse perfil foi otimizado para uso com cargas de trabalho em lote que não são suscetíveis à latência de inicialização.

2. Mude para o perfil optimize-utilization para observar todos os efeitos do escalonamento:

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. Com o escalonamento automático ativado, observe seu cluster no console do Cloud. Clique nas três barras na parte superior esquerda para abrir o Menu de navegação.

4. No Menu de navegação, selecione Kubernetes Engine > Clusters.

5. Na página Clusters, selecione o cluster scaling-demo.

6. Na página desse cluster, selecione a guia Nós.

7. Observe a visão geral da utilização de recursos dos três nós.

Observação: seus números podem ser diferentes dos mostrados na figura. O Kubernetes não provisiona nem atribui recursos sempre da mesma forma.

Se você combinar os valores de CPU requested e CPU allocatable para os três nós, os totais serão 1555m e 2820m, respectivamente. Isso significa que há um total de 1265m CPUs disponíveis em todo o cluster. Isso é maior do que o que pode ser fornecido por um nó.

Para otimizar a utilização, a carga de trabalho da demanda atual pode ser consolidada em dois nós, em vez de três. No entanto, o escalonamento vertical do cluster ainda não foi reduzido automaticamente. Isso se deve aos pods do sistema distribuídos no cluster.

O cluster executa várias implantações no namespace do kube-system para que os vários serviços do GKE funcionem, como geração de registros, monitoramento, escalonamento automático etc.

8. Para verificar, execute este comando no Cloud Shell:

kubectl get deployment -n kube-system

Por padrão, a maioria dos pods do sistema dessas implantações impede que o escalonador automático de clusters as deixe completamente off-line para reprogramá-las. Geralmente isso é desejado porque muitos desses pods coletam dados usados em outras implantações e serviços. Por exemplo, ficar temporariamente indisponível em metrics-agent pode causar uma lacuna nos dados coletados para o VPA e o HPA, ou o pod fluentd pode causar uma lacuna nos registros da nuvem.

Neste laboratório, você aplicará orçamentos de interrupção aos pods do kube-system para permitir que o escalonador automático de clusters os reprograme com segurança em outro nó. Com isso, você terá espaço suficiente para reduzir o cluster.

Os orçamentos de interrupção de pod (PDB) definem como o Kubernetes deve lidar com interrupções, como upgrades, remoções de pods, falta de recursos etc. Em PDBs, é possível especificar o número max-unavailable e/ou o min-available dos pods que uma implantação precisa ter.

9. Execute estes comandos para criar os orçamentos de interrupção (PDBs, na sigla em inglês) para cada pod do kube-system:

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

Clique em Verificar meu progresso para conferir se você executou a tarefa. Escalonador automático de clusters.

Em cada um desses comandos, você seleciona um pod de implantação do kube-system diferente com base em um rótulo definido na criação dele, especificando que pode haver um pod indisponível em cada uma dessas implantações. Assim, o escalonador automático poderá reprogramar os pods do sistema.

Com os PDBs em vigor, o cluster reduz o escalonamento vertical de três para dois nós em um ou dois minutos.

10. Execute novamente este comando no Cloud Shell até ficar com apenas dois nós:

kubectl get nodes

No console do Cloud, atualize a guia Nós do cluster scaling-demo para inspecionar como seus recursos foram empacotados:

Você configurou a automação que reduziu o escalonamento do cluster de três para dois nós.

Pensando nos custos, como resultado da redução do escalonamento vertical do pool de nós, você pagará por menos máquinas durante os períodos de baixa demanda no cluster. Esse escalonamento poderia ser ainda mais significativo se você estivesse flutuando dos períodos de alta demanda para os de baixa demanda durante o dia.

É importante observar que, enquanto o escalonador automático de clusters removeu um nó desnecessário, o Escalonamento automático vertical de pods e o Escalonamento automático horizontal de pods ajudaram a reduzir a demanda de CPU o suficiente para que o nó não fosse mais necessário. Combinar essas ferramentas é uma ótima maneira de otimizar os custos gerais e o uso de recursos.

Portanto, o escalonador automático de clusters adiciona e remove nós em resposta aos pods que precisam ser programados. No entanto, o GKE tem outro recurso para escalonar verticalmente, chamado de provisionamento automático de nós.

Tarefa 6: provisionamento automático de nós

O provisionamento automático de nós (NAP, na sigla em inglês) adiciona pools de nós dimensionados para atender à demanda. Sem o provisionamento automático de nós, o escalonador automático de clusters só cria nós nos pools especificados, o que significa que os novos nós têm o mesmo tipo de máquina que os outros nós do pool. Isso é perfeito para otimizar o uso de recursos para cargas de trabalho em lote e outros aplicativos que não precisam de escalonamento extremo, já que a criação de um pool de nós otimizado especificamente para seu caso de uso pode levar mais tempo do que apenas adicionar nós a um pool.

• Ative o provisionamento automático de nós:

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

No comando, especifique os números mínimo e máximo para os recursos de CPU e memória. Isso vale para todo o cluster.

O NAP pode levar um pouco de tempo, e é provável que não vai criar um pool de nós para o cluster scaling-demo no estado atual.

Nas próximas seções, você vai aumentar a demanda para o cluster e observar as ações dos seus escalonadores automáticos, além do NAP.

Clique em Verificar meu progresso para conferir se você executou a tarefa. Provisionamento automático de nós.

Tarefa 7: teste com uma demanda maior

Até agora, você analisou como o HPA, o VPA e o escalonador automático de clusters podem economizar recursos e reduzir custos quando seu aplicativo está com baixa demanda. Agora você vai ver como essas ferramentas lidam com a disponibilidade para uma maior demanda.

1. Abra uma nova guia no Cloud Shell pressionando o ícone +:

2. Na nova guia, execute este comando para enviar um loop infinito de consultas ao serviço php-apache:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3. Volte para a guia original do Cloud Shell.

4. Em cerca de um minuto, você verá a carga de CPU mais alta no HPA executando:

kubectl get hpa

Aguarde e execute o comando de novo até aparecer a meta acima de 100%.

5. Agora monitore como o cluster lida com o aumento de carga executando periodicamente este comando:

kubectl get deployment php-apache

Para monitorar o cluster, atualize a guia Nós no console do Cloud.

Depois de um tempo, algumas coisas vão acontecer.

• Primeiro, a implantação do php-apache será escalonada automaticamente pelo HPA para processar o aumento de carga.
• Depois, o escalonador automático de clusters precisará provisionar novos nós para atender ao aumento da demanda.
• Por fim, o provisionamento automático de nós criará um pool de nós otimizado para as solicitações de CPU e memória das cargas de trabalho do cluster. Nesse caso, ele deve ser um pool de nós com muita CPU e pouca memória porque o teste de carga está ultrapassando os limites da CPU.

Aguarde até que a implantação do php-apache seja escalonada em até sete réplicas, e a guia de nós fique parecida com esta:

6. Volte para a guia Cloud Shell na qual você executou o teste de carga e cancele-o pressionando Ctrl + c. Agora o cluster vai reduzir o escalonamento vertical à medida que a demanda diminuir.

O cluster foi escalonado verticalmente de maneira eficiente para atender a uma demanda mais alta. No entanto, observe o tempo que levou para lidar com esse aumento na demanda. Para muitos aplicativos, a perda de disponibilidade durante o provisionamento de novos recursos pode ser um problema.

Tarefa 8: otimize cargas maiores

Ao escalonar verticalmente para cargas maiores, o Escalonamento automático horizontal de pods vai adicionar novos pods. Já o Escalonamento automático vertical de pods vai redimensioná-los de acordo com as configurações. Se houver espaço em um nó atual, talvez seja possível pular a imagem e começar a executar o aplicativo em um novo pod imediatamente. Se você estiver trabalhando com um nó que não tenha implantado o aplicativo antes, um pouco de tempo poderá ser adicionado caso seja necessário fazer o download das imagens do contêiner antes de executá-lo.

Portanto, se você não tiver espaço suficiente nos nós e estiver usando o escalonador automático de clusters, isso poderá demorar ainda mais. Agora ele precisa provisionar um novo nó, configurá-lo, fazer o download da imagem e iniciar os pods. Se o provisionamento automático de nós criar um novo pool de nós como no cluster, haverá ainda mais tempo conforme você provisionar o novo pool de nós para depois executar as mesmas etapas para o novo nó.

Observação: na prática, é importante garantir que seu aplicativo esteja usando as menores imagens de contêiner possíveis. Imagens menores melhoram o tempo de inicialização a frio de um pod. Afinal, quanto menor a imagem, mais rápido será o download quando o escalonador automático provisionar um novo nó para o cluster. Além disso, imagens maiores podem causar tempos de inicialização mais longos do pod, resultando em baixo desempenho ao provisionar novos nós durante picos de tráfego.

Para lidar com essas diferentes latências para o escalonamento automático, convém provisionar um pouco a mais para que haja menos pressão nos seus aplicativos durante o escalonamento automático. Isso é muito importante para a otimização de custos, porque você não quer pagar por mais recursos do que precisa, mas também não quer que o desempenho dos aplicativos seja prejudicado.

Para descobrir quanto provisionar a mais, use esta fórmula:

Como um exemplo, pense na utilização da CPU para o cluster. É melhor ela não atingir 100%, então você pode escolher um buffer de 15% para manter uma distância segura. A variável de tráfego na fórmula é a porcentagem do aumento de tráfego estimado nos próximos dois a três minutos. No teste de carga que você executou anteriormente, 0% a 150% foi um exemplo de crescimento extremo. Por isso, imagine um crescimento de tráfego médio de 30%.

Com esses números, você pode calcular um buffer de segurança de aproximadamente 65%. Isso significa que convém você provisionar a mais seus recursos em cerca de 65% para lidar com aumentos de escalonamento e minimizar problemas.

Uma estratégia eficiente para aumentar o provisionamento de um cluster com escalonamento automático de clusters é usar pods de pausa.

Pods de pausa são implantações de baixa prioridade que podem ser removidas e substituídas por implantações de alta prioridade. Isso significa que você pode criar pods de baixa prioridade que não fazem nada, exceto reserva de espaço de buffer. Quando o pod de maior prioridade precisa de espaço, os pods de pausa são removidos e reprogramados para outro nó, ou um novo nó, e o pod de maior prioridade tem o espaço de que precisa para ser programado rapidamente.

1. Crie um manifesto para um pod de pausa:

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. Aplique o manifesto ao cluster:

kubectl apply -f pause-pod.yaml

3. Aguarde um minuto e atualize a guia Nós do cluster scaling-demo.

Observe a criação do novo nó, provavelmente em um novo pool, para se ajustar ao pod de pausa recém-criado. Se você executar o teste de carga novamente, quando precisar de um nó extra para a implantação do php-apache, ele poderá ser programado no nó com o pod de pausa enquanto o pod de pausa estiver em execução em um novo nó. Isso é excelente porque os pods de pausa fictícios permitem que o cluster provisione um novo nó com antecedência para que o aplicativo real possa ser escalonado com mais rapidez. Se você esperar maior tráfego, poderá adicionar mais pods de pausa. No entanto, a prática recomendada é não adicionar mais de um pod de pausa por nó.

Clique em Verificar meu progresso para conferir se você executou a tarefa. Otimize cargas maiores.

Parabéns!

Você configurou um cluster para fazer escalonamentos automáticos vertical e horizontal com base na demanda. O Escalonamento automático horizontal de pods e o Escalonamento automático vertical de pods fornecem soluções para escalonar automaticamente as implantações do cluster, enquanto o escalonador automático de clusters e o provisionamento automático de nós fornecem soluções para o escalonamento automático da infraestrutura do cluster.

Como sempre, o uso de cada ferramenta vai depender da sua carga de trabalho. Com o uso cuidadoso de escalonadores automáticos, você maximiza a disponibilidade quando precisa e paga apenas o necessário em momentos de baixa demanda. Ao pensar nos custos, você vai otimizar o uso de recursos e economizar dinheiro.

Termine o curso

Este laboratório autoguiado faz parte da Quest Optimize Costs for Google Kubernetes Engine. O curso é uma série de laboratórios relacionados que formam um programa de aprendizado. Ao concluir este curso, você ganha um selo como reconhecimento da sua conquista. É possível publicar os selos e incluir um link para eles no seu currículo on-line ou nas redes sociais. Inscreva-se nesta Quest e receba o crédito de conclusão na mesma hora. Consulte o catálogo do Google Cloud Ensina para conferir todas as Quests disponíveis.

Comece o próximo laboratório

Continue o curso com o GKE Workload Optimization ou confira os laboratórios do "Google Cloud Ensina":

• Como gerenciar um cluster multilocatário do GKE com namespaces
• Conheça a otimização de custos para máquinas virtuais do GKE

Próximas etapas / Saiba mais

• Práticas recomendadas para executar aplicativos do Kubernetes otimizados para custo no GKE: ajuste o escalonamento automático do GKE
• Documentos do escalonador automático de clusters
• Documentos do escalonador automático horizontal de pods
• Documentação do escalonador automático vertical de pods

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 20 de setembro de 2023

Laboratório testado em 20 de setembro de 2023

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.