Tutorial do NGINX: Reduza a latência do Kubernetes com dimensionamento automático
Este tutorial é um dos quatro que colocam em prática conceitos do Microservices de março de 2022: Rede Kubernetes :
- Reduza a latência do Kubernetes com dimensionamento automático (este post)
- Proteja as APIs do Kubernetes com limitação de taxa
- Proteja os aplicativos do Kubernetes contra injeção de SQL
- Melhore o tempo de atividade e a resiliência com uma implantação Canary
Quer orientação detalhada sobre como usar o NGINX para ainda mais casos de uso de rede Kubernetes? Baixe nosso e-book gratuito, Gerenciando o tráfego do Kubernetes com NGINX: Um guia prático .
Sua organização criou um aplicativo no Kubernetes e agora ele está se tornando popular! Você passou de apenas alguns visitantes para centenas (e às vezes milhares) por dia. Mas há um problema... o aumento do tráfego está atingindo um gargalo, causando latência e tempos limite para seus clientes. Se você não puder melhorar a experiência, as pessoas deixarão de usar o aplicativo.
Você – o corajoso engenheiro do Kubernetes – tem uma solução. Você implanta um controlador Ingress para rotear o tráfego e configura uma política de dimensionamento automático para que o número de pods do controlador Ingress se expanda e contraia instantaneamente para corresponder às flutuações do tráfego. Agora, seus pods controladores do Ingress lidam perfeitamente com picos de tráfego – “Adeus, latência!” – e reduzem a escala para conservar recursos quando o tráfego diminui – “Olá, economia de custos!” Muito bem, você.
Visão geral do laboratório e do tutorial
Este blog acompanha o laboratório da Unidade 1 de Microsserviços de março de 2022 – Arquitetura de clusters do Kubernetes para sites de alto tráfego , demonstrando como usar o NGINX Ingress Controller para expor um aplicativo e, em seguida, dimensionar automaticamente os pods do Ingress Controller em resposta ao alto tráfego.
Para executar o tutorial, você precisa de uma máquina com:
- 2 CPUs ou mais
- 2 GB de memória livre
- 20 GB de espaço livre em disco
- Conexão de internet
- Gerenciador de contêiner ou máquina virtual, como Docker, Hyperkit, Hyper‑V, KVM, Parallels, Podman, VirtualBox ou VMware Fusion/Workstation
- minikube instalado
- Leme instalado
- Uma configuração que permite iniciar uma janela do navegador. Se isso não for possível, você precisa descobrir como acessar os serviços relevantes por meio de um navegador.
Para aproveitar ao máximo o laboratório e o tutorial, recomendamos que antes de começar você:
Assista à gravação da visão geral conceitual transmitida ao vivo
Revise os blogs de fundo
Assista ao resumo em vídeo de 20 minutos do laboratório:
Este tutorial usa estas tecnologias:
- Controlador de entrada NGINX (baseado em NGINX Open Source)
- Leme
- KEDA
- Gafanhoto
- minicube
- Podinfo
- Prometeu
As instruções para cada desafio incluem o texto completo dos arquivos YAML usados para configurar os aplicativos. Você também pode copiar o texto do nosso repositório GitHub . Um link para o GitHub é fornecido junto com o texto de cada arquivo YAML.
Este tutorial inclui quatro desafios:
- Configurar um aplicativo simples em um cluster Kubernetes
- Use o NGINX Ingress Controller para rotear o tráfego para o aplicativo
- Gerar e monitorar tráfego
- Controlador de entrada NGINX de dimensionamento automático
Desafio 1: Configurar um aplicativo simples em um cluster Kubernetes
Neste desafio, você cria um cluster minikube e instala o Podinfo como um aplicativo de exemplo.
Crie um cluster Minikube
Crie um cluster minikube . Após alguns segundos, uma mensagem confirma que a implantação foi bem-sucedida.
$ minikube start 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
Instale o aplicativo Podinfo
Podinfo é um “aplicativo web feito com Go que demonstra as melhores práticas de execução de microsserviços no Kubernetes”. Estamos usando-o como um aplicativo de exemplo devido ao seu tamanho reduzido.
Usando o editor de texto de sua escolha, crie um arquivo YAML chamado 1-deployment.yaml com o seguinte conteúdo (ou copie do GitHub ). Ele define uma implantação com uma única réplica e um serviço.
apiVersion: apps/v1 kind: Deployment metadata: name: podinfo spec: selector: matchLabels: app: podinfo template: metadata: labels: app: podinfo spec: containers: - name: podinfo image: stefanprodan/podinfo ports: - containerPort: 9898 --- apiVersion: v1 kind: Service metadata: name: podinfo spec: ports: - port: 80 targetPort: 9898 nodePort: 30001 selector: app: podinfo type: LoadBalancerImplante o aplicativo:
$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo created service/podinfo createdConfirme se o pod Podinfo foi implantado, conforme indicado pelo valor
Em execuçãona colunaSTATUS.$ kubectl get podsNAME READY STATUS RESTARTS AGE podinfo-5d76864686-rd2s5 1/1 Running 0 3m38sAbra o Podinfo em um navegador. As saudações da página podinfo indicam que o Podinfo está em execução.
$ minikube service podinfo
Desafio 2: Use o NGINX Ingress Controller para rotear o tráfego para o aplicativo
Neste desafio, você implanta o NGINX Ingress Controller e o configura para rotear o tráfego para o aplicativo Podinfo .
Implantar o NGINX Ingress Controller
A maneira mais rápida de instalar o NGINX Ingress Controller é com o Helm .
Adicione o repositório NGINX ao Helm:
$ helm repo add nginx-stable https://helm.nginx.com/stableBaixe e instale o NGINX Open Source‑based NGINX Ingress Controller , que é mantido pela F5 NGINX. A linha final de saída confirma a instalação bem-sucedida.
$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 NAME: main LAST DEPLOYED: Tue Mar 15 09:49:17 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The NGINX Ingress Controller has been installed.Confirme se o pod do NGINX Ingress Controller foi implantado, conforme indicado pelo valor
Em execuçãona colunaSTATUS(para legibilidade, a saída é distribuída em duas linhas).$ kubectl get podsNAME READY STATUS ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 Running ... podinfo-5d76864686-fjncl 1/1 Running ... ... RESTARTS AGE ... 0 18s ... 0 2m36s
Direcione o tráfego para seu aplicativo
Usando o editor de texto de sua escolha, crie um arquivo YAML chamado 2-ingress.yaml com o seguinte conteúdo (ou copie do GitHub ). Ele define o manifesto do Ingress necessário para rotear o tráfego para o Podinfo.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: podinfo spec: ingressClassName: nginx rules: - host: "example.com" http: paths: - backend: service: name: podinfo port: number: 80 path: / pathType: PrefixImplante o recurso Ingress:
$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo created
Desafio 3: Gerar e monitorar tráfego
Neste desafio, você observa o desempenho do NGINX Ingress Controller sob diferentes cargas de tráfego. Como etapas preparatórias, você lista as métricas disponíveis no NGINX Ingress Controller, implanta o Prometheus e instala o Locust . Em seguida, use o Locust para simular um aumento no tráfego e monitorar o efeito no desempenho no Prometheus.
Como você já descobriu, um controlador Ingress é um pod comum do Kubernetes que agrupa um proxy reverso (no nosso caso, NGINX) com algum código para integração com o Kubernetes. Se seu aplicativo receber muito tráfego, provavelmente você precisará aumentar o número de réplicas de pod do NGINX Ingress Controller para evitar a latência causada quando o NGINX Ingress Controller fica sobrecarregado.
Listar as métricas disponíveis
Para saber quando e quanto dimensionar, você precisa de informações precisas sobre o desempenho do NGINX Ingress Controller. Neste tutorial, a métrica NGINX usada para determinar quando dimensionar é o número de conexões ativas ( nginx_connections_active ). Aqui você verifica se o seu NGINX Ingress Controller rastreia essa métrica.
O NGINX Ingress Controller expõe várias métricas : 8 métricas com o modelo baseado em NGINX Open Source que estamos usando neste tutorial e mais de 80 métricas com o modelo baseado em NGINX Plus .
Obtenha o endereço IP do pod do NGINX Ingress Controller para que você possa consultar sua lista de métricas. O endereço aparece no campo
IPe aqui está172.17.0.4. (Para legibilidade, as colunasRESTARTSeAGEsão omitidas e a saída é distribuída em duas linhas.)$ kubectl get pods -o wide NAME READY STATUS ... main-nginx-ingress-779b74bb8b-6hdwx 1/1 Running ... podinfo-5d76864686-nl8ws 1/1 Running ... ... IP NODE NOMINATED NODE READINESS GATES ... 172.17.0.4 minikube <none> <none> ... 172.17.0.3 minikube <none> <none>Crie um pod BusyBox temporário com um shell em um host dentro do cluster Kubernetes:
$ kubectl run -ti --rm=true busybox --image=busyboxIf you don't see a command prompt, try pressing enter. / #Liste as métricas geradas pelo seu NGINX Ingress Controller e verifique se ele inclui
nginx_connections_active. Para<endereço_IP>substitua o valor do Passo 1./# wget -qO- <IP_address>:9113/metricsSaia do shell para retornar ao servidor Kubernetes.
/# exit
Implantar Prometheus
Agora que você sabe que seu NGINX Ingress Controller rastreia a métrica nginx_connections_active , você precisa de uma ferramenta para coletar (“raspar”) as métricas – este tutorial usa o Prometheus .
Quanto ao NGINX Ingress Controller, o Helm é a maneira mais rápida de instalar o Prometheus.
Adicione o repositório Prometheus ao Helm:
$ helm repo add prometheus-community https://prometheus-community.github.io/helm-chartsBaixe e instale o Prometheus:
$ helm install prometheus prometheus-community/prometheus \ --set server.service.type=NodePort --set server.service.nodePort=30010Verifique a instalação, que geralmente leva até 60 segundos para ser concluída. No exemplo de saída a seguir, o comando de verificação foi executado apenas alguns segundos após o comando
helminstalle, portanto, vemos a instalação em andamento, comContainerCreatingrelatado no campoSTATUSpara alguns pods do Prometheus. A instalação estará concluída quando todos os pods tiverem o statusEm execução. (A saída é distribuída em duas linhas para maior legibilidade.)$ kubectl get podsNAME READY ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 ... podinfo-5d76864686-fjncl 1/1 ... prometheus-alertmanager-d6d94cf4b-85ww5 0/2 ... prometheus-kube-state-metrics-7cd8f95cb-86hhs 0/1 ... prometheus-node-exporter-gqxfz 1/1 ... prometheus-pushgateway-56745d8d8b-qnwcb 0/1 ... prometheus-server-b78c9449f-kwhzp 0/2 ... ... STATUS RESTARTS AGE ... Running 0 3m23s ... Running 0 5m41s ... ContainerCreating 0 7s ... Running 0 7s ... Running 0 7s ... ContainerCreating 0 7s ... ContainerCreating 0 7sAbra o Prometheus. Em um ambiente minikube, execute o seguinte comando, que abre o painel do Prometheus no seu navegador padrão.
$ minikube service prometheus-serverUma página como a seguinte confirma que o servidor está funcionando.
Digite
nginx_ingress_nginx_connections_activena barra de pesquisa para ver o valor atual da métrica de conexões ativas. Você vê uma conexão ativa, o que faz sentido porque você implantou um pod do NGINX Ingress Controller.
Instalar Locust
Na próxima seção, você usará o Locust , uma ferramenta de teste de carga de código aberto, para simular um aumento de tráfego e poder observar o desempenho do NGINX Ingress Controller no Prometheus. Aqui você implanta o Locust.
Usando o editor de texto de sua escolha, crie um arquivo YAML chamado 3-locust.yaml com o seguinte conteúdo (ou copie do GitHub ). Os objetos de implantação e serviço definem o pod Locust. O objeto ConfigMap define um script chamado locustfile.py que gera solicitações a serem enviadas ao pod, completas com os cabeçalhos corretos.
apiVersion: v1 kind: ConfigMap metadata: name: locust-script data: locustfile.py: |- from locust import HttpUser, task, between class QuickstartUser(HttpUser): wait_time = between(0.7, 1.3) @task def hello_world(self): self.client.get("/", headers={"Host": "example.com"}) --- apiVersion: apps/v1 kind: Deployment metadata: name: locust spec: selector: matchLabels: app: locust template: metadata: labels: app: locust spec: containers: - name: locust image: locustio/locust ports: - containerPort: 8089 volumeMounts: - mountPath: /home/locust name: locust-script volumes: - name: locust-script configMap: name: locust-script --- apiVersion: v1 kind: Service metadata: name: locust spec: ports: - port: 8089 targetPort: 8089 nodePort: 30015 selector: app: locust type: LoadBalancerImplantar Locust:
$ kubectl apply -f 3-locust.yaml configmap/locust-script created deployment.apps/locust created service/locust created
Simule um aumento de tráfego e observe o efeito no desempenho
Abra o Locust em um navegador.
$ minikube service locust
Insira os seguintes valores nos campos:
- Número de usuários – 1000
- Taxa de spawn – 10
- Anfitrião – http://main-nginx-ingress
Clique no botão Iniciar swarming para enviar tráfego para o aplicativo Podinfo.
Retorne ao painel do Prometheus para ver como o NGINX Ingress Controller responde. Talvez seja necessário executar uma nova consulta para
nginx_ingress_nginx_connections_activepara ver alguma alteração.Conforme mostrado na saída de tela a seguir, o pod único do NGINX Ingress Controller tem dificuldade para processar o tráfego aumentado sem latência, pois um grande número de conexões é estabelecido. O gráfico do Prometheus revela que cerca de 100 conexões ativas por pod do NGINX Ingress Controller é o ponto crítico para um pico de latência. Você pode usar essas informações para determinar quando precisa aumentar o número de pods do NGINX Ingress Controller para evitar aumento de latência.
Desafio 4: Controlador de entrada NGINX de dimensionamento automático
No desafio final, você cria uma configuração que dimensiona automaticamente os recursos conforme o volume de tráfego aumenta. O tutorial usa o KEDA para dimensionamento automático, então primeiro você o instala e cria uma política que define quando e como o dimensionamento ocorre. Assim como no Desafio 3, você usa o Locust para simular um aumento de tráfego e o Prometheus para observar o desempenho do NGINX Ingress Controller quando o dimensionamento automático está habilitado.
Instalar KEDA
KEDA , um autoescalador orientado a eventos do Kubernetes, integra um servidor de métricas (o componente que armazena e transforma métricas para o Kubernetes) e pode consumir métricas diretamente do Prometheus (assim como de outras ferramentas). Ele cria um Horizontal Pod Autoscaler (HPA) com essas métricas, conecta as métricas coletadas pelo Prometheus e as envia ao Kubernetes.
Assim como no NGINX Ingress Controller e no Prometheus, o tutorial usa o Helm para instalar o KEDA.
Adicione KEDA ao repositório Helm:
$ helm repo add kedacore https://kedacore.github.io/charts "kedacore" has been added to your repositoriesInstalar KEDA:
$ helm install keda kedacore/keda NAME: keda NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: NoneVerifique se o KEDA está sendo executado como dois pods. (Para maior legibilidade, alguns valores na coluna
NOMEforam encurtados. Além disso, a colunaRESTARTSé omitida; o valor é0para todos os pods.)$ kubectl get pods NAME READY STATUS AGE keda-operator-8644dcdb79-492x5 1/1 Running 59s keda-operator-metrics-apiserver-66d... 1/1 Running 59s locust-77c699c94d-dvb5n 1/1 Running 8m59s main-nginx-ingress-779b74bb8b-v7ggw 1/1 Running 48m podinfo-5d76864686-c98rb 1/1 Running 50m prometheus-alertmanager-d6d94cf4b-8... 2/2 Running 37m prometheus-kube-state-metrics-7cd8f... 1/1 Running 37m prometheus-node-exporter-j4qf4 1/1 Running 37m prometheus-pushgateway-56745d8d8b-9n4nl 1/1 Running 37m prometheus-server-b78c9449f-6ktn9 2/2 Running 37m
Crie uma política de dimensionamento automático
Agora use a definição de recurso personalizado (CRD) do KEDA ScaledObject para definir os parâmetros que determinam como o NGINX Ingress Controller é dimensionado. A seguinte configuração:
- Aciona o dimensionamento automático com base no valor da métrica
nginx_connections_activecoletada pelo Prometheus - Implanta um novo pod quando os pods existentes atingem 100 conexões ativas cada
- Dimensiona automaticamente os pods do NGINX Ingress Controller de um único pod para até 20 pods
Execute os seguintes passos:
Usando o editor de texto de sua escolha, crie um arquivo YAML chamado 4-scaled-object.yaml com o seguinte conteúdo (ou copie do GitHub ). Ele define um KEDA
ScaledObject.apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nginx-scale spec: scaleTargetRef: kind: Deployment name: main-nginx-ingress minReplicaCount: 1 maxReplicaCount: 20 cooldownPeriod: 30 pollingInterval: 1 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server metricName: nginx_connections_active_keda query: | sum(avg_over_time(nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m])) threshold: "100"Implante o
ScaledObject:$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale created
Simule um aumento de tráfego e observe o efeito do dimensionamento automático no desempenho
Para realmente testar a eficácia do dimensionamento automático, você dobra o número de conexões em comparação ao Desafio 3.
Retorne ao servidor Locust no seu navegador. Insira os seguintes valores nos campos e clique no botão Iniciar enxameação :
- Número de usuários – 2000
- Taxa de spawn – 10
- Anfitrião – http://main-nginx-ingress
Retorne aos painéis do Prometheus e do Locust. A caixa rosa abaixo do gráfico do Prometheus representa o número de pods do NGINX Ingress Controller aumentando e diminuindo.
Retorne ao seu terminal e inspecione manualmente o KEDA HPA. O campo
REPLICASna saída mostra o número atual de réplicas de pod implantadas. (A saída é distribuída em duas linhas para maior legibilidade.)$ kubectl get hpa NAME REFERENCE ... keda-hpa-nginx-scale Deployment/main-nginx-ingress ... ... TARGETS MINPODS MAXPODS REPLICAS AGE ... 101500m/100 (avg) 1 20 10 2m45s
Próximos passos
Há uma limitação potencial quando você baseia o dimensionamento automático apenas no número de conexões ativas. Se (mesmo com dimensionamento) o NGINX Ingress Controller ficar tão ocupado que precise descartar conexões, o dimensionador automático verá menos conexões ativas, interpretará isso como um sinal de que as solicitações foram recusadas e reduzirá o número de réplicas. Isso pode piorar o desempenho, mas aproveitar uma combinação de métricas pode garantir que isso não aconteça. Por exemplo, nginxplus_connections_dropped (disponível com o NGINX Ingress Controller baseado no NGINX Plus) rastreia essas conexões de cliente descartadas.
Para experimentar o NGINX Ingress Controller com NGINX Plus e NGINX App Protect, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .
Para testar o NGINX Ingress Controller com o NGINX Open Source, você pode obter o código-fonte da versão ou baixar um contêiner pré-criado do DockerHub .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."