Nesta página, explicaremos como usar o escalonamento automático horizontal de pods para escalonar automaticamente uma implantação usando diferentes tipos de métricas. Use as mesmas diretrizes de configuração de HorizontalPodAutoscaler
para qualquer objeto de implantação escalonável.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
Versões da API para objetos HorizontalPodAutoscaler
Quando você usa o Console do Google Cloud, os objetos HorizontalPodAutoscaler
são criados usando a API autoscaling/v2
.
Quando você usa kubectl
para criar ou visualizar informações sobre um escalonador automático horizontal de pods, é possível especificar a API autoscaling/v1
ou autoscaling/v2
.
apiVersion: autoscaling/v1
é o padrão e permite fazer o escalonamento automático com base apenas na utilização da CPU. Para fazer o escalonamento automático com base em outras métricas, o uso deapiVersion: autoscaling/v2
é recomendado. O exemplo em Criar a implantação de exemplo usaapiVersion: autoscaling/v1
.Recomenda-se usar
apiVersion: autoscaling/v2
para criar novos objetosHorizontalPodAutoscaler
. Isso permite fazer o escalonamento automático com base em várias métricas, incluindo métricas personalizadas ou externas. Todos os outros exemplos nesta página usamapiVersion: autoscaling/v2
.
Para verificar quais versões da API são compatíveis, use o comando kubectl api-versions
.
É possível especificar qual API será usada quando você visualizar detalhes sobre um escalonador automático horizontal de pods que usa apiVersion: autoscaling/v2
.
Crie a implantação de exemplo
Antes de criar um escalonador automático horizontal de pods, crie a carga de trabalho que ele monitora. Os exemplos nesta página aplicam configurações diferentes do Escalonador automático horizontal de pods à implantação nginx
a seguir. Outros exemplos mostram um escalonador automático horizontal de pods com base na utilização de recursos, na
métrica personalizada ou externa e em várias métricas.
Salve o seguinte em um arquivo chamado nginx.yaml
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
resources:
# You must specify requests for CPU to autoscale
# based on CPU utilization
requests:
cpu: "250m"
Este manifesto especifica um valor para solicitações de CPU. Se desejar fazer escalonamento automático com base na utilização de um recurso, como uma porcentagem, especifique solicitações para esse recurso. Se você não especificar solicitações, será possível fazer escalonamento automático com base apenas no valor absoluto da utilização do recurso, como milliCPUs para a utilização da CPU.
Para criar a implantação, aplique o manifesto nginx.yaml
:
kubectl apply -f nginx.yaml
A implantação tem spec.replicas
definido como 3, então três pods são implantados.
É possível verificar isso usando o comando kubectl get deployment nginx
.
Cada um dos exemplos nesta página aplica um Escalonador automático horizontal de pods a um exemplo de implantação nginx.
Escalonamento automático com base na utilização de recursos
Este exemplo cria um objeto HorizontalPodAutoscaler
para escalonamento automático da
implantação nginx
quando a utilização da CPU ultrapassar 50% e garante que sempre haja, no mínimo, uma réplica e, no máximo, dez réplicas.
É possível criar um escalonador automático horizontal de pods que segmente a CPU usando o Console do Google Cloud, o comando kubectl apply
ou, somente para uma média da CPU, o comando kubectl autoscale
.
Console
Acesse a página Cargas de trabalho no console do Google Cloud.
Clique no nome da implantação
nginx
.Clique em list Ações > Escalonamento automático.
Especifique os seguintes valores:
- Número mínimo de réplicas: 1
- Número máximo de réplicas: 10
- Métrica de escalonamento automático: CPU
- Destino: 50
- Unidade: %
Clique em Concluído.
Clique em Escalonamento automático.
kubectl apply
Salve o seguinte manifesto YAML como um arquivo chamado nginx-hpa.yaml
:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
Para criar o HPA, aplique o manifesto usando o seguinte comando:
kubectl apply -f nginx-hpa.yaml
kubectl autoscale
Para criar um objeto HorizontalPodAutoscaler
que segmenta somente a utilização média da CPU, é possível usar o comando kubectl autoscale
:
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10
Para ver uma lista de escalonadores automáticos de pods horizontal no cluster, use o seguinte comando:
kubectl get hpa
O resultado será assim:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 3 61s
Para detalhes sobre o escalonador automático horizontal de pods, use o Console do Google Cloud ou o comando kubectl
.
Console
Acesse a página Cargas de trabalho no console do Google Cloud.
Clique no nome da implantação
nginx
.Veja a configuração do escalonador automático horizontal de pods na seção Autoescalador.
Veja mais detalhes sobre eventos de escalonamento automático na guia Eventos.
kubectl get
Para mais detalhes sobre o escalonador automático horizontal de pods, use kubectl get hpa
com a sinalização -o yaml
. O campo status
contém informações sobre o número atual de
réplicas e todos os eventos recentes de escalonamento automático.
kubectl get hpa nginx -o yaml
O resultado será assim:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
annotations:
autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
HPA was able to successfully calculate a replica count from cpu resource utilization
(percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
desired count is within the acceptable range"}]'
autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
creationTimestamp: "2019-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
targetCPUUtilizationPercentage: 50
status:
currentCPUUtilizationPercentage: 0
currentReplicas: 3
desiredReplicas: 3
Antes de seguir os outros exemplos desta página, exclua o HPA:
kubectl delete hpa nginx
Quando você exclui um escalonador automático horizontal de pods, o número de réplicas da implantação permanece o mesmo. Uma implantação não volta automaticamente ao estado anterior à aplicação do escalonador automático do pod horizontal.
Saiba mais sobre como excluir um escalonador automático horizontal de pods.
Como fazer escalonamento automático com base no tráfego do balanceador de carga
O escalonamento automático baseado em tráfego é um recurso do GKE que integra sinais de utilização de tráfego de balanceadores de carga para escalonar automaticamente os pods.
Usar o tráfego como um sinal de escalonamento automático pode ser útil, porque o tráfego é um indicador principal de carga que é complementar à CPU e à memória. A integração incorporada no GKE garante que a configuração seja fácil e que o escalonamento automático reaja rapidamente aos picos de tráfego para atender à demanda.
O escalonamento automático baseado em tráfego é ativado pelo controlador de gateway e seus recursos de gerenciamento de tráfego global. Para saber mais, consulte Escalonamento automático baseado em tráfego.
O escalonamento automático com base no tráfego do balanceador de carga está disponível apenas para cargas de trabalho do Gateway.
Requisitos
O escalonamento automático baseado em tráfego tem os seguintes requisitos:
- Compatível com as versões 1.22 e posteriores do GKE.
- API Gateway ativada no cluster do GKE.
- Compatível com tráfego que passa pelos balanceadores de carga implantados usando a API Gateway e um destes GatewayClasses:
gke-l7-global-external-managed
,gke-l7-regional-external-managed
,gke-l7-rilb
ougke-l7-gxlb
.
Limitações
O escalonamento automático baseado em tráfego tem as seguintes limitações:
- Não é compatível com o GatewayClass de vários clusters (
gke-l7-global-external-managed-mc
,gke-l7-regional-external-managed-mc
,gke-l7-rilb-mc
egke-l7-gxlb-mc
). - Não é compatível com tráfego usando os Serviços do tipo
ClusterIP
ouLoadBalancer
. - O HPA, a implantação (ou outro recurso de destino) e o serviço configurados para usar o escalonamento automático com base no tráfego precisam ter correspondência exata entre eles.
Implantar o escalonamento automático baseado em tráfego
O exercício a seguir usa o HorizontalPodAutoscaler
para fazer o escalonamento automático da implantação store-autoscale
com base no tráfego recebido. Um
gateway aceita o tráfego
de entrada da Internet para os pods. O escalonador automático compara sinais de tráfego
do gateway com a
capacidade de tráfego por pod
configurada no recurso de serviço store-autoscale
. Ao gerar tráfego para o gateway, você influencia o número de pods implantados.
Veja no diagrama a seguir como o escalonamento automático baseado em tráfego funciona:
Para implantar o escalonamento automático baseado em tráfego, execute as seguintes etapas:
Para clusters padrão, confirme se as GatewayClasses estão instaladas no cluster. Para clusters do Autopilot, as GatewayClasses são instaladas por padrão.
kubectl get gatewayclass
A saída confirma que os recursos do GatewayClass do GKE estão prontos para uso no cluster:
NAME CONTROLLER ACCEPTED AGE gke-l7-global-external-managed networking.gke.io/gateway True 16h gke-l7-regional-external-managed networking.gke.io/gateway True 16h gke-l7-gxlb networking.gke.io/gateway True 16h gke-l7-rilb networking.gke.io/gateway True 16h
Se você não encontrar essa saída, ative a API Gateway no cluster do GKE.
Implante o aplicativo de amostra e o balanceador de carga de gateway no cluster:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml
O aplicativo de amostra cria:
- Uma implantação com duas réplicas.
- Uma capacidade do serviço com
max-rate-per-endpoint
definido como10
. Enquanto esse recurso estiver em Visualização, use uma anotação no serviço. Quando esse recurso estiver disponível para todos os usuários, a política de serviço substituirá a anotação. Para saber mais sobre os recursos de gateway, consulte Recursos de GatewayClass. - Um gateway externo para acessar o aplicativo na Internet. Para saber mais sobre como usar balanceadores de carga de gateway, consulte Como implantar gateways.
- Uma HTTPRoute que corresponde a todo o tráfego e a envia para o
serviço
store-autoscale
.
A capacidade do serviço é um elemento essencial ao usar o escalonamento automático baseado em tráfego, porque determina a quantidade de tráfego por pod que aciona um evento de escalonamento automático. Ela é configurada para a capacidade do serviço usando a anotação
networking.gke.io/max-rate-per-endpoint
, que define o tráfego máximo que um serviço precisa receber em solicitações por segundo, por pod. A capacidade do serviço é específica do seu aplicativo. Para mais informações, consulte Como determinar a capacidade do seu serviço.Salve o seguinte manifesto como
hpa.yaml
:apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: store-autoscale spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: store-autoscale minReplicas: 1 maxReplicas: 10 metrics: - type: Object object: describedObject: kind: Service name: store-autoscale metric: name: "autoscaling.googleapis.com|gclb-capacity-utilization" target: averageValue: 70 type: AverageValue
Este manifesto descreve um
HorizontalPodAutoscaler
com as seguintes propriedades:minReplicas
emaxReplicas
: define os números mínimo e máximo de réplicas para esta implantação. Nesta configuração, o número de pods pode ser escalonado de 1 a 10 réplicas.describedObject.name: store-autoscale
: a referência ao serviçostore-autoscale
que define a capacidade do tráfego.scaleTargetRef.name: store-autoscale
: a referência à implantaçãostore-autoscale
que define o recurso que é dimensionado pelo Escalonador automático do pod horizontal.averageValue: 70
: valor médio desejado de utilização da capacidade. Isso dá ao Escalonador automático horizontal de pods uma margem de crescimento para que os pods em execução possam processar o tráfego excessivo enquanto novos pods estão sendo criados.
O Escalonador automático horizontal de pods resulta no seguinte comportamento de tráfego:
- O número de pods é ajustado entre 1 e 10 réplicas para alcançar
70% da taxa máxima por endpoint. Isso resulta em 7 RPS por pod quando
max-rate-per-endpoint=10
. - Com mais de 7 RPS por pod, o escalonamento vertical dos pods é feito até atingir o máximo de 10 réplicas ou até que o tráfego médio seja de 7 RPS por pod.
- Se o tráfego for reduzido, os pods serão reduzidos a uma taxa razoável usando o algoritmo do Escalonador automático horizontal de pods.
Também é possível implantar um gerador de tráfego para validar o comportamento de escalonamento automático baseado em tráfego.
Com 30 RPS, a implantação é escalonada para 5 réplicas para que cada réplica receba 6 RPS de tráfego, o que seria 60% de utilização por pod. Isso está abaixo da meta de utilização de 70%, portanto, os pods são dimensionados adequadamente. Dependendo das flutuações de tráfego, o número de réplicas com escalonamento automático também pode flutuar. Para uma descrição mais detalhada de como o número de réplicas é calculado, consulte Comportamento do escalonamento automático.
Como fazer escalonamento automático com base em uma métrica personalizada ou externa
Para criar autoescaladores de pods horizontais para métricas personalizadas e externas, consulte Otimizar o escalonamento automático de pods com base em métricas.
Como fazer escalonamento automático com base em várias métricas
Neste exemplo, um autoescalador de pod horizontal é criado com escalonamento automático com base na utilização da CPU e em uma métrica personalizada chamada packets_per_second
.
Se você seguiu o exemplo anterior e ainda tem um escalonador automático horizontal de pods chamado nginx
, exclua-o antes de seguir este exemplo.
Este exemplo requer apiVersion: autoscaling/v2
. Para mais informações sobre as APIs disponíveis, consulte Versões da API para objetos HorizontalPodAutoscaler
.
Salve este manifesto YAML como um arquivo chamado nginx-multiple.yaml
:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- type: Resource
resource:
name: memory
target:
type: AverageValue
averageValue: 100Mi
# Uncomment these lines if you create the custom packets_per_second metric and
# configure your app to export the metric.
# - type: Pods
# pods:
# metric:
# name: packets_per_second
# target:
# type: AverageValue
# averageValue: 100
Aplique o manifesto YAML:
kubectl apply -f nginx-multiple.yaml
Quando criado, o escalonador automático horizontal de pods monitora a implantação de nginx
para a utilização média da CPU e da memória e, caso tenha removido a marca de comentário, a métrica packets_per_second
personalizada. O escalonador automático horizontal de pods faz o escalonamento automático da implantação com base na métrica que tem o valor que criaria o maior evento de escalonamento automático.
Como visualizar detalhes de um escalonador automático horizontal de pods
Para visualizar a configuração e as estatísticas do escalonador automático horizontal de pods, use o seguinte comando:
kubectl describe hpa HPA_NAME
Substitua HPA_NAME
pelo nome do objeto HorizontalPodAutoscaler
.
Se o autoescalador de pod horizontal usar apiVersion: autoscaling/v2
e for baseado em várias métricas, o comando kubectl describe hpa
mostrará apenas a métrica da CPU. Para ver
todas as métricas, use o seguinte comando:
kubectl describe hpa.v2.autoscaling HPA_NAME
Substitua HPA_NAME
pelo nome do objeto HorizontalPodAutoscaler
.
O status atual de cada escalonador automático horizontal de pods é mostrado no campo Conditions
, e os eventos de escalonamento automático são listados no campo Events
.
A resposta será semelhante a:
Name: nginx
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp: Tue, 05 May 2020 20:07:11 +0000
Reference: Deployment/nginx
Metrics: ( current / target )
resource memory on pods: 2220032 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale recommended size matches current size
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
Como excluir um escalonador automático horizontal de pods
É possível excluir um escalonador automático horizontal de pods usando o Console do Google Cloud ou o comando kubectl delete
.
Console
Para excluir o escalonador automático horizontal de pods nginx
, siga estas etapas:
Acesse a página Cargas de trabalho no console do Google Cloud.
Clique no nome da implantação
nginx
.Clique em list Ações > Escalonamento automático.
Clique em Excluir.
kubectl delete
Para excluir o escalonador automático horizontal de pods nginx
, use o seguinte comando:
kubectl delete hpa nginx
Quando você exclui um escalonador automático horizontal de pods, a implantação (ou outro objeto de implantação) permanece com o escalonamento existente e não reverte para o número de réplicas no manifesto original da implantação. Para escalonar manualmente a implantação para três pods um outra vez, é possível usar o comando kubectl scale
:
kubectl scale deployment nginx --replicas=3
Limpeza
Exclua o escalonador automático horizontal de pods, se ainda não tiver feito isso:
kubectl delete hpa nginx
Exclua a implantação
nginx
:kubectl delete deployment nginx
Opcionalmente, exclua o cluster.
Solução de problemas
Esta seção mostra as etapas de solução de problemas usando o escalonamento automático horizontal de pods.
O Escalonador automático horizontal de pods mostra o erro unable to fetch pod metrics for pod
Quando você configura um Escalonador automático horizontal de pods, talvez haja mensagens de aviso como estas:
unable to fetch pod metrics for pod
É normal que essa mensagem apareça quando o servidor de métricas é iniciado. No entanto, se você continuar a ver os avisos e perceber que os pods não estão sendo escalonados para a carga de trabalho, verifique se você tem solicitações de recursos especificadas para cada contêiner na sua carga de trabalho. Para usar limites percentuais de uso de recursos com escalonamento automático de pod horizontal, você precisa configurar as solicitações desse recurso para cada contêiner em execução em cada pod da carga de trabalho. Caso contrário, o Escalonador automático horizontal de pods não poderá fazer os cálculos necessários e não reagirá às ações relacionadas a essa métrica.
O Escalonador automático horizontal de pods mostra o evento multiple services selecting the same target of...
O Escalonador automático horizontal de pods mostra o erro multiple services selecting the same target of <hpa>: <services>
quando detecta que você está usando o escalonamento automático com base no tráfego com vários serviços associados
à meta do Escalonador automático horizontal de pods (normalmente uma implantação).
O escalonamento automático com base no tráfego só oferece suporte a configurações em que exatamente um serviço está associado ao recurso escalonado automaticamente. Consulte Como fazer escalonamento automático com base no tráfego do balanceador de carga. A mensagem de erro indica os serviços encontrados.
Para resolver o problema, verifique se apenas um serviço está associado ao Escalonador automático horizontal de pods.
A seguir
- Saiba mais sobre o escalonamento automático horizontal de pods.
- Saiba mais sobre o Escalonamento automático vertical de pods.
- Saiba mais sobre o escalonamento automático multidimensional de pods.
- Saiba mais sobre implantações de escalonamento automático com métricas personalizadas.
- Saiba como atribuir recursos da CPU a contêineres e pods.
- Saiba como atribuir recursos de memória a contêineres e pods.