Schaal van nul naar nul in Kubernetes: een diepgaande blik op Elasti

Elasti is een innovatieve open-source oplossing die is ontworpen om het resourcegebruik van Kubernetes te optimaliseren door services in staat te stellen tijdens inactiviteit naar nul te schalen en op verzoek weer op te schalen. Elasti is gebouwd met een architectuur van twee componenten — een Kubernetes-controller en een request resolver — en beheert naadloos de beschikbaarheid van services terwijl de kosten worden geminimaliseerd. Dit artikel is bedoeld als een technische gids voor de architectuur, installatie en operationele stromen, zodat u Elasti effectief kunt integreren en uitbreiden in uw Kubernetes-omgevingen.

💡Deze functie is inbegrepen in de autoscaling suite van Truefoundry. Raadpleeg de documentatie voor meer informatie.

Het landschap van schalen naar nul

Hoewel Kubernetes robuuste schaalmogelijkheden biedt via HPA en oplossingen zoals KEDA, blijft schalen naar nul replica's een uitdaging. Bestaande benaderingen vallen over het algemeen in twee categorieën:

1. Natieve KEDA Scaling - Hoewel KEDA deployments naar nul kan schalen met behulp van event-metrics, ontstaat hierdoor een tijdsbestek waarin inkomende verzoeken verloren kunnen gaan tijdens de koudestartperiode van het opschalen.
2. Full-Service Meshes (bijv. Knative) - Bieden uitgebreide mogelijkheden voor schalen naar nul, maar vereisen aanzienlijke architecturale wijzigingen en brengen een hoge operationele overhead met zich mee.
3. HTTP Proxies (bijv. KEDA HTTP Add-on) - Onderhouden permanente proxylagen die latentie introduceren, zelfs nadat services zijn opgeschaald.

Waarom Elasti?

Elasti is gemaakt om deze beperkingen aan te pakken met drie belangrijke ontwerpdoelen:

1. Lichtgewicht integratie - Werkt met bestaande deployments/services zonder code-wijzigingen.
2. Nul proxy-overhead - Verlaat het verzoekpad zodra services zijn opgeschaald.
3. Kostengeoptimaliseerd schalen - Echte schaal naar nul zonder altijd-actieve componenten te onderhouden.

Hoe het werkt

Elasti bestaat uit twee kerncomponenten die samenwerken om het schalen van services te beheren:

Controller (Operator):‍

• Monitort ElastiService-resources in uw Kubernetes-cluster.
• Schaalt services dynamisch tussen 0 en 1 op basis van real-time verkeersmetrieken.

Resolver:

• Fungeert als een proxy om inkomende verzoeken te onderscheppen wanneer de service is teruggeschaald.
• Zet deze verzoeken in een wachtrij en stelt de controller op de hoogte om de service weer op te schalen, zodat er geen verzoek verloren gaat.

Steady-state verzoekstroom naar services

In deze modus worden alle verzoeken rechtstreeks afgehandeld door de service pods. De Elasti resolver komt niet in het verzoekpad. De Elasti controller blijft prometheus bevragen met de geconfigureerde query en vergelijkt het resultaat met de drempelwaarde om te zien of de service kan worden teruggeschaald.

Terugschalen naar 0 wanneer er geen verzoeken zijn

Als de query van prometheus een waarde retourneert die lager is dan de drempelwaarde, zal Elasti de service terugschalen naar 0. Voordat het naar 0 schaalt, omleidt het de verzoeken om te worden doorgestuurd naar de Elasti resolver en wijzigt het vervolgens de Rollout/deployment naar 0 replica's. Vervolgens pauzeert het ook Keda (als Keda wordt gebruikt) om te voorkomen dat het de service opschaalt, aangezien Keda is geconfigureerd met minReplicas op 1.

Opschalen vanaf 0 wanneer het eerste verzoek binnenkomt.

Aangezien de service is teruggeschaald naar 0, komen alle verzoeken aan bij de Elasti resolver. Wanneer het eerste verzoek binnenkomt, zal Elasti de service opschalen naar de geconfigureerde minTargetReplicas. Vervolgens hervat het Keda om door te gaan met autoscaling voor het geval er een plotselinge piek in verzoeken is. Het wijzigt ook de service om te verwijzen naar de werkelijke service pods zodra de pod actief is. De verzoeken die bij ElastiResolver binnenkwamen, worden tot 6 minuten lang opnieuw geprobeerd en het antwoord wordt teruggestuurd naar de client. Als de pod er langer dan 6 minuten over doet om actief te worden, wordt het verzoek verworpen.

Aan de slag

Een eenvoudige applicatie implementeren met Elasti

1. Een lokaal cluster maken

minikube start


of

kind create cluster --name elasti-demo

of

‍
Maak een lokaal cluster met Docker Desktop

2. Prometheus instellen

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 --namespace monitoring \
 --create-namespace \
 --set alertmanager.enabled=false \
 --set grafana.enabled=false \
 --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false

Installeer en configureer prometheus in de monitoring namespace

Prometheus zal worden gebruikt om metrieken van nginx ingress te lezen, die vervolgens door elasti worden gebruikt om metrieken op te vragen waaraan het beslist wanneer een service van en naar nul moet worden geschaald.

3. Nginx ingress instellen

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
 --namespace ingress-nginx \
 --set controller.metrics.enabled=true \
 --set controller.metrics.serviceMonitor.enabled=true \
 --create-namespace

Implementeert een nginx controller in de ingress-nginx namespace

De controller zal worden gebruikt om verkeer naar onze demo httpbin-service te routeren.

4. Elasti instellen:

helm repo add elasti https://charts.truefoundry.com/elasti
helm repo update
helm install elasti oci://tfy.jfrog.io/tfy-helm/elasti \
 --namespace elasti --create-namespace


Elasti installeren met helm in namespace elasti

Zodra Elasti is geïnstalleerd, zou u de twee belangrijkste componenten moeten zien draaien:

• Controller/Operator: Beheert het overschakelen van verkeer en het schalen door metrieken te monitoren.
• Resolver: Onderschept inkomende verzoeken, zet ze in de wachtrij en fungeert als proxy.

Bekijk values.yaml voor meer geavanceerde configuraties en om alle configuratie-opties in het helm values-bestand te zien.

5. Implementeer een demo-applicatie

kubectl create namespace elasti-demo
kubectl apply -n elasti-demo -f \
https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-application.yaml

Een httpbin-service implementeren in de elasti-demo namespace

Deze httpbin-service zal worden gebruikt om te demonstreren hoe u een service kunt configureren om verkeer via elasti af te handelen.

6. Een ElastiService Resource maken:

Maak een yaml-bestand met de volgende configuratie voor een ElastiService.

apiVersion: elasti.truefoundry.com/v1alpha1
kind: ElastiService
metadata:
 name: httpbin-elasti
 namespace: elasti-demo
spec:
 minTargetReplicas: 1
 service: httpbin
 cooldownPeriod: 5
 scaleTargetRef:
   apiVersion: apps/v1
   kind: deployments
   name: httpbin
 triggers:
   - type: prometheus
     metadata:
       query: sum(rate(nginx_ingress_controller_nginx_process_requests_total[1m])) or vector(0)
       serverAddress: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090
       threshold: "0.5"

demo-elasti-service.yaml

Zodra het bestand is gemaakt, past u de ElastiService toe

kubectl apply -f https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-elastiService.yaml

Enkele belangrijke velden in de CRD-specificatie zijn:

• minTargetReplicas: Minimale replica's om te starten wanneer het eerste verzoek binnenkomt.
• cooldownPeriod: Minimale tijd (in seconden) om te wachten na het opschalen voordat terugschalen wordt overwogen.
• triggers: Lijst van voorwaarden die bepalen wanneer moet worden teruggeschaald (ondersteunt momenteel alleen Prometheus-metrieken).
• scaleTargetRef:  Referentie naar het schaaldoel, vergelijkbaar met het doel dat wordt gebruikt in HorizontalPodAutoscaler.

Raadpleeg deze documentatie voor meer informatie en voor het configureren van een ElastiService voor uw specifieke use case.

De installatie testen

Met deze stappen beschikt u nu over:

• Ingress nginx die draait als uw Ingress controller.
• Prometheus geconfigureerd om metrieken te verzamelen (inclusief die van Ingress NGINX).
• httpbin geïmplementeerd en toegankelijk via een Ingress-route.

Deze configuratie helpt u om real-world routeringsscenario's te testen en de prestaties en metrieken van uw ingress-verkeer te monitoren.

Om deze installatie te testen, kunt u verzoeken sturen naar de nginx load balancer en de pods van onze demo-service monitoren.

kubectl port-forward svc/nginx-ingress-nginx-controller \
 -n ingress-nginx 8080:80


Port forward naar de nginx controller

kubectl get pods -n elasti-demo -w


Start een watch op de httpbin-service

Nu kunt u een verzoek sturen naar http://localhost:8080/httpbin en kunt u zien dat de service door elasti wordt opgeschaald naar 1 replica.

curl -v http://localhost:8080/httpbin

Stuur een verzoek naar de httpbin-service

De service wordt vervolgens weer teruggeschaald nadat er gedurende het aantal seconden dat is opgegeven in de ElastiService (in dit geval 5 seconden) geen activiteit is geweest cooldownPeriod.

Elasti deïnstallen

Om Elasti te deïnstallen, moet u eerst alle geïnstalleerde ElastiServices verwijderen. Verwijder daarna simpelweg het installatiebestand.

kubectl delete elastiservices --all
helm uninstall elasti -n elasti
kubectl delete namespace elasti

^{Vergelijkingen}

Functievergelijkingstabel:

Wanneer kiezen voor Elasti

Elasti is de beste keuze wanneer u:

• Mogelijkheden voor schalen naar nul moet toevoegen aan bestaande HTTP-services
• Wilt garanderen dat er geen verzoeken verloren gaan tijdens schaaloperaties
• De voorkeur geeft aan een lichtgewicht oplossing met minimale configuratie
• Integratie nodig hebt met bestaande autoscalers (HPA/KEDA)

Tot slot

Elasti is ontwikkeld uit de noodzaak om een specifieke uitdaging in Kubernetes aan te pakken: het implementeren van echt schalen naar nul zonder de integriteit van verzoeken op te offeren of overmatige overhead te veroorzaken. Deze oplossing ondersteunt natieve autoscaling met HPA en KEDA, wat ervoor zorgt dat bestaande serviceconfiguraties ongewijzigd blijven terwijl een efficiënt resourcegebruik wordt bereikt.

Door deze tool open-source te maken, willen we een robuuste oplossing bieden voor omgevingen die echte schaal naar nul, nul verlies van verzoeken en een minimale operationele footprint vereisen.

We verwelkomen bijdragen en feedback van de community — bekijk de ontwikkelingsdocumentatie voor meer details.