Uso de HPA e CA para dimensionamento automático de cargas de trabalho e nós
Cenários de aplicações
A melhor maneira de lidar com o aumento do tráfego é ajustar automaticamente o número de máquinas com base no volume de tráfego ou no uso de recursos, o que é chamado de dimensionamento.
Ao implementar aplicações em pods, você pode configurar os recursos solicitados e os limites de recursos para os pods a fim de evitar o uso ilimitado de recursos durante os horários de pico. No entanto, depois que o limite superior for atingido, poderá ocorrer um erro de aplicação. O dimensionamento de pods pode resolver esse problema com eficiência. Se o uso de recursos no nó aumentar até certo ponto, os pods adicionados recentemente não poderão ser agendados para esse nó. Nesse caso, o CCE adicionará nós de acordo.
Solução
As duas principais políticas de dimensionamento automático são HPA (Dimensionamento automático de pod horizontal) e CA (Dimensionamento automático de cluster). HPA é para dimensionamento automático de carga de trabalho e CA é para dimensionamento automático de nós.
HPA e CA trabalham juntos. O HPA requer recursos de cluster suficientes para o dimensionamento bem-sucedido. Quando os recursos do cluster são insuficientes, o CA é necessário para adicionar nós. Se o HPA reduzir as cargas de trabalho, o cluster terá um grande número de recursos ociosos. Nesse caso, o CA precisa liberar nós para evitar desperdício de recursos.
O uso do HPA e CA pode implementar facilmente o dimensionamento automático na maioria dos cenários. Além disso, o processo de dimensionamento de nós e pods pode ser facilmente observado.
Esta seção usa um exemplo para descrever o processo de dimensionamento automático usando as políticas de HPA e CA juntas.
Preparativos
- Crie um cluster com um nó. O nó deve ter 2 núcleos de vCPUs e 4 GiB de memória, ou uma especificação superior, bem como um EIP para permitir o acesso externo. Se nenhum EIP estiver vinculado ao nó durante a criação do nó, você poderá vincular um manualmente no console do ECS após a criação do nó.
- Instale complementos para o cluster.
- autoscaler: complemento de dimensionamento de nós
- metrics-server: um agregador de dados de uso de recursos em um cluster do Kubernetes. Ele pode coletar dados de medição dos principais recursos do Kubernetes, como pods, nós, contêineres e serviços.
- Faça logon no nó de cluster e execute uma aplicação com uso intensivo de computação. Quando um usuário envia uma solicitação, o resultado precisa ser calculado antes de ser retornado ao usuário.
- Crie um arquivo PHP chamado index.php para calcular a raiz quadrada da solicitação 1.000.000 de vezes antes de retornar OK!.
vi index.php
O conteúdo do arquivo é o seguinte:<?php $x = 0.0001; for ($i = 0; $i <= 1000000; $i++) { $x += sqrt($x); } echo "OK!"; ?> - Compile um arquivo Dockerfile para criar uma imagem.
vi Dockerfile
O conteúdo é o seguinte:FROM php:5-apache COPY index.php /var/www/html/index.php RUN chmod a+rx index.php
- Execute o seguinte comando para criar uma imagem chamada hpa-example com a tag latest.
docker build -t hpa-example:latest .
- (Opcional) Faça logon no console do SWR, escolha Organizations no painel de navegação e clique em Create Organization no canto superior direito.
Pule esta etapa se você já tiver uma organização.
- No painel de navegação, escolha My Images e clique em Upload Through Client. Na página exibida, clique em Generate a temporary login command e clique em
para copiar o comando. - Execute o comando de logon copiado na etapa anterior no nó do cluster. Se o logon for bem-sucedido, a mensagem "Login Succeeded" será exibida.
- Marque a imagem hpa-example.
docker tag {Image name 1:Tag 1}/{Image repository address}/{Organization name}/{Image name 2:Tag 2}
- {Image name 1:Tag 1}: nome e tag da imagem local a ser carregada.
- {Image repository address}: o nome de domínio no final do comando de logon no comando de logon. Ele pode ser obtido no console do SWR.
- {Organization name}: nome da organização criada.
- {Image name 2:Tag 2}: nome e tag da imagem desejada a serem exibidos no console do SWR.
O seguinte é um exemplo:
docker tag hpa-example:latest swr.ap-southeast-1.myhuaweicloud.com/cloud-develop/hpa-example:latest
- Envie a imagem para o repositório de imagens.
docker push {Image repository address}/{Organization name}/{Image name 2:Tag 2}
O seguinte é um exemplo:
docker push swr.ap-southeast-1.myhuaweicloud.com/cloud-develop/hpa-example:latest
As informações a seguir serão retornadas após um envio bem-sucedido:
6d6b9812c8ae: Pushed ... fe4c16cbf7a4: Pushed latest: digest: sha256:eb7e3bbd*** size: **
Para visualizar a imagem enviada, acesse o console do SWR e atualize a página My Images.
- Crie um arquivo PHP chamado index.php para calcular a raiz quadrada da solicitação 1.000.000 de vezes antes de retornar OK!.
Criação de um pool de nós e de uma política de dimensionamento de nós
- Faça logon no console do CCE, acesse o cluster criado, clique em Nodes à esquerda, clique na guia Node Pools e clique em Create Node Pool no canto superior direito.
- Configure o pool de nós.
- Nodes: defina como 1, indicando que um nó é criado por padrão quando um pool de nós é criado.
- Specifications: 2 vCPUs | 4 GiB
Mantenha os padrões para outros parâmetros. Para obter detalhes, consulte Criação de um pool de nós.
- Localize a linha que contém o pool de nós recentemente criado e clique em Auto Scaling no canto superior direito. Para obter detalhes, consulte Criação de uma política de dimensionamento de nós.
Se o complemento CCE Cluster Autoscaler não estiver instalado no cluster, instale-o primeiro. Para obter detalhes, consulte CCE Cluster Autoscaler.
- Automatic scale-out: se essa função estiver ativada, os nós em um pool de nós serão adicionados automaticamente com base na carga do cluster.
- Customized scale-out rules.: clique em Add Rule. Na caixa de diálogo exibida, configure os parâmetros. Se a taxa de alocação de CPU for maior que 70%, um nó será adicionado a cada pool de nós associado. Uma política de dimensionamento de nós precisa ser associada a um pool de nós. Vários pools de nós podem ser associados. Quando você precisar dimensionar nós, o nó com especificações adequadas será adicionado ou reduzido do pool de nós com base no princípio do desperdício mínimo.
- Automatic scale-in: se essa função estiver ativada, os nós em um pool de nós serão excluídos automaticamente com base na carga do cluster. Por exemplo, acione a redução quando a utilização de recursos do nó for inferior a 50%.
- AS Configuration: modifique o intervalo de quantidade de nós. Durante o dimensionamento automático, o número de nós em um pool de nós está sempre dentro do intervalo de quantidade configurado.
- AS Object: ative o dimensionamento automático para especificações de nós em um pool de nós.
- Clique em OK.
Criação de uma carga de trabalho
Use a imagem hpa-example para criar um Deployment com uma réplica. O caminho da imagem está relacionado à organização carregada no repositório SWR e precisa ser substituído pelo valor real.
kind: Deployment apiVersion: apps/v1 metadata: name: hpa-example spec: replicas: 1 selector: matchLabels: app: hpa-example template: metadata: labels: app: hpa-example spec: containers: - name: container-1 image: 'hpa-example:latest' # Replace it with the address of the image you uploaded to SWR. resources: limits: # The value of limits must be the same as that of requests to prevent flapping during scaling. cpu: 500m memory: 200Mi requests: cpu: 500m memory: 200Mi imagePullSecrets: - name: default-secret
Em seguida, crie um Serviço de NodePort para a carga de trabalho para que a carga de trabalho possa ser acessada de redes externas.
Para permitir acesso externo aos Serviços de NodePort, aloque um EIP para o nó no cluster. Após a alocação, sincronize os dados do nó. Para obter detalhes, consulte Sincronização de dados com servidores em nuvem. Se o nó já estiver vinculado a um EIP, você não precisará criar um.
Como alternativa, você pode criar um Serviço com um balanceador de carga do ELB para acesso externo. Para obter detalhes, consulte Uso do kubectl para criar um serviço (criação automática de um balanceador de carga).
kind: Service
apiVersion: v1
metadata:
name: hpa-example
spec:
ports:
- name: cce-service-0
protocol: TCP
port: 80
targetPort: 80
nodePort: 31144
selector:
app: hpa-example
type: NodePort
Criação de uma política de HPA
Crie uma política HPA. Conforme mostrado abaixo, a política está associada à carga de trabalho hpa-example e o uso da CPU de destino é de 50%.
Há duas outras anotações. Uma anotação define os limites da CPU, indicando que o dimensionamento não é realizado quando o uso da CPU está entre 30% e 70% para evitar o impacto causado por pequenas flutuações. A outra é a janela de tempo de dimensionamento, indicando que, depois que a política for executada com sucesso, uma operação de dimensionamento não será acionada novamente nesse intervalo de resfriamento para evitar o impacto causado pela flutuação de curto prazo.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-policy
annotations:
extendedhpa.metrics: '[{"type":"Resource","name":"cpu","targetType":"Utilization","targetRange":{"low":"30","high":"70"}}]'
extendedhpa.option: '{"downscaleWindow":"5m","upscaleWindow":"3m"}'
spec:
scaleTargetRef:
kind: Deployment
name: hpa-example
apiVersion: apps/v1
minReplicas: 1
maxReplicas: 100
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
Configure os parâmetros da seguinte forma se você estiver usando o console.
Observação do processo de dimensionamento automático
- Verifique o status do nó do cluster. No exemplo a seguir, há dois nós.
# kubectl get node NAME STATUS ROLES AGE VERSION 192.168.0.183 Ready <none> 2m20s v1.17.9-r0-CCE21.1.1.3.B001-17.36.8 192.168.0.26 Ready <none> 55m v1.17.9-r0-CCE21.1.1.3.B001-17.36.8
Verifique a política de HPA. O uso da CPU da carga de trabalho de destino é de 0%.
# kubectl get hpa hpa-policy NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-policy Deployment/hpa-example 0%/50% 1 100 1 4m
- Execute o seguinte comando para acessar a carga de trabalho. No comando a seguir, {ip:port} indica o endereço de acesso da carga de trabalho, que pode ser consultado na página de detalhes da carga de trabalho.
while true;do wget -q -O- http://{ip:port}; done
Se nenhum EIP for exibido, o nó de cluster não foi atribuído a nenhum EIP. Aloque um, vincule ao nó e sincronize os dados do nó. Para obter detalhes, consulte Sincronização de dados com servidores em nuvem.
Observe o processo de dimensionamento da carga de trabalho.
# kubectl get hpa hpa-policy --watch NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-policy Deployment/hpa-example 0%/50% 1 100 1 4m hpa-policy Deployment/hpa-example 190%/50% 1 100 1 4m23s hpa-policy Deployment/hpa-example 190%/50% 1 100 4 4m31s hpa-policy Deployment/hpa-example 200%/50% 1 100 4 5m16s hpa-policy Deployment/hpa-example 200%/50% 1 100 4 6m16s hpa-policy Deployment/hpa-example 85%/50% 1 100 4 7m16s hpa-policy Deployment/hpa-example 81%/50% 1 100 4 8m16s hpa-policy Deployment/hpa-example 81%/50% 1 100 7 8m31s hpa-policy Deployment/hpa-example 57%/50% 1 100 7 9m16s hpa-policy Deployment/hpa-example 51%/50% 1 100 7 10m hpa-policy Deployment/hpa-example 58%/50% 1 100 7 11mVocê pode ver que o uso da CPU da carga de trabalho é de 190% em 4m23s, o que excede o valor de destino. Nesse caso, o dimensionamento é acionado para expandir a carga de trabalho para quatro réplicas/pods. Nos vários minutos seguintes, o uso da CPU não diminui até 7m16s. Isso ocorre porque os novos pods podem não ser criados com sucesso. A causa possível é que os recursos são insuficientes e os pods estão no estado pendente. Durante esse período, os nós estão sendo expandidos.
Aos 7m16s, o uso da CPU diminui, indicando que os pods foram criados com sucesso e começam a suportar tráfego. O uso da CPU diminui para 81% a 8m, ainda maior do que o valor de destino (50%) e o alto limite (70%). Portanto, 7 pods são adicionados a 9m16s e o uso da CPU diminui para 51%, o que está dentro do intervalo de 30% a 70%. A partir de então, o número de pods permanece 7.
Na saída a seguir, você pode ver o processo de dimensionamento da carga de trabalho e a hora em que a política HPA entra em vigor.
# kubectl describe deploy hpa-example ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set hpa-example-79dd795485 to 1 Normal ScalingReplicaSet 20m deployment-controller Scaled up replica set hpa-example-79dd795485 to 4 Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set hpa-example-79dd795485 to 7 # kubectl describe hpa hpa-policy ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 20m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 16m horizontal-pod-autoscaler New size: 7; reason: cpu resource utilization (percentage of request) above target
Verifique o número de nós. A saída a seguir mostra que dois nós foram adicionados.
# kubectl get node NAME STATUS ROLES AGE VERSION 192.168.0.120 Ready <none> 3m5s v1.17.9-r0-CCE21.1.1.3.B001-17.36.8 192.168.0.136 Ready <none> 6m58s v1.17.9-r0-CCE21.1.1.3.B001-17.36.8 192.168.0.183 Ready <none> 18m v1.17.9-r0-CCE21.1.1.3.B001-17.36.8 192.168.0.26 Ready <none> 71m v1.17.9-r0-CCE21.1.1.3.B001-17.36.8
Você também pode visualizar o histórico de dimensionamento no console. Por exemplo, a política de CA é executada uma vez quando a taxa de alocação de CPU no cluster é maior que 70% e o número de nós no pool de nós é aumentado de 2 para 3. O novo nó é adicionado automaticamente pelo autoscaler com base no estado pendente dos pods na fase inicial do HPA.
O processo de dimensionamento do nó é o seguinte:
- Depois que o número de pods muda para 4, os pods ficam no estado Pendente devido a recursos insuficientes. Como resultado, a política de expansão padrão do complemento autoscaler é acionada e o número de nós é aumentado em um.
- A expansão do segundo nó é acionada porque a taxa de alocação de CPU no cluster é superior a 70%. Como resultado, o número de nós aumenta em um, que é registrado no histórico de dimensionamento no console. O dimensionamento com base na taxa de alocação garante que o cluster tenha recursos suficientes.
- Pare de acessar a carga de trabalho e verifique o número de pods.
# kubectl get hpa hpa-policy --watch NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-policy Deployment/hpa-example 50%/50% 1 100 7 12m hpa-policy Deployment/hpa-example 21%/50% 1 100 7 13m hpa-policy Deployment/hpa-example 0%/50% 1 100 7 14m hpa-policy Deployment/hpa-example 0%/50% 1 100 7 18m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 18m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 19m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 19m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 19m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 19m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 23m hpa-policy Deployment/hpa-example 0%/50% 1 100 3 23m hpa-policy Deployment/hpa-example 0%/50% 1 100 1 23m
Você pode ver que o uso da CPU é de 21% a 13m. O número de pods é reduzido para 3 a 18m e depois para 1 a 23m.
Na saída a seguir, você pode ver o processo de dimensionamento da carga de trabalho e a hora em que a política HPA entra em vigor.
# kubectl describe deploy hpa-example ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set hpa-example-79dd795485 to 1 Normal ScalingReplicaSet 20m deployment-controller Scaled up replica set hpa-example-79dd795485 to 4 Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set hpa-example-79dd795485 to 7 Normal ScalingReplicaSet 6m28s deployment-controller Scaled down replica set hpa-example-79dd795485 to 3 Normal ScalingReplicaSet 72s deployment-controller Scaled down replica set hpa-example-79dd795485 to 1 # kubectl describe hpa hpa-policy ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 20m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 16m horizontal-pod-autoscaler New size: 7; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 6m45s horizontal-pod-autoscaler New size: 3; reason: All metrics below target Normal SuccessfulRescale 90s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
Você também pode exibir o histórico de execução da política HPA no console. Aguarde até que um nó seja reduzido.
A razão pela qual os outros dois nós no pool de nós não são reduzidos é que ambos têm pods no namespace do sistema kube (e esses pods não são criados por DaemonSets). Para obter detalhes, consulte Mecanismos de dimensionamento de nós.
Resumo
O uso do HPA e CA pode implementar facilmente o dimensionamento automático na maioria dos cenários. Além disso, o processo de dimensionamento de nós e pods pode ser facilmente observado.
