Autoskalning av lodrät podd i Azure Kubernetes Service (AKS)

Artikel
12/09/2023

Den här artikeln innehåller en översikt över VPA (Vertical Pod Autoscaler) i Azure Kubernetes Service (AKS), som baseras på öppen källkod Kubernetes-versionen. När den konfigureras anger den automatiskt resursbegäranden och begränsningar för containrar per arbetsbelastning baserat på tidigare användning. VPA frigör cpu och minne för de andra poddarna och hjälper till att effektivt utnyttja AKS-klustret.

Lodrät automatisk skalning av poddar ger rekommendationer för resursanvändning över tid. Om du vill hantera plötsliga ökningar av resursanvändningen använder du horizontal pod autoscaler, som skalar antalet poddrepliker efter behov.

Förmåner

Vertikal podd autoskalning ger följande fördelar:

Den analyserar och justerar processor- och minnesresurser så att de passar dina program. VPA ansvarar inte bara för att skala upp, utan även för att skala ned baserat på deras resursanvändning över tid.
En podd tas bort om den behöver ändra sina resursbegäranden om skalningsläget är inställt på automatisk eller återskapad.
Ange cpu- och minnesbegränsningar för enskilda containrar genom att ange en resursprincip
Säkerställer att noder har rätt resurser för poddschemaläggning
Konfigurerbar loggning av eventuella justeringar av processor- eller minnesresurser som gjorts
Förbättra användningen av klusterresurser och frigör cpu och minne för andra poddar.

Begränsningar

Autoskalning av lodrät podd stöder högst 1 000 poddar som är associerade med VerticalPodAutoscaler objekt per kluster.
VPA kan rekommendera fler resurser än vad som är tillgängligt i klustret. Därför förhindrar detta att podden tilldelas till en nod och körs, eftersom noden inte har tillräckligt med resurser. Du kan övervinna den här begränsningen genom att ange LimitRange till maximalt tillgängliga resurser per namnområde, vilket säkerställer att poddar inte ber om fler resurser än vad som anges. Dessutom kan du ange maximalt antal tillåtna resursrekommendationer per podd i ett VerticalPodAutoscaler objekt. Tänk på att VPA inte helt kan lösa ett problem med otillräcklig nodresurs. Gränsintervallet är fast, men nodresursanvändningen ändras dynamiskt.
Vi rekommenderar inte att du använder vertikal podd autoskalning med horisontell podd autoskalning, som skalar baserat på samma cpu- och minnesanvändningsmått.
VPA Recommender lagrar endast upp till åtta dagars historiska data.
VPA stöder inte JVM-baserade arbetsbelastningar på grund av begränsad insyn i den faktiska minnesanvändningen för arbetsbelastningen.
Det rekommenderas inte eller stöds inte att köra din egen implementering av VPA tillsammans med den här hanterade implementeringen av VPA. Det finns stöd för att ha en extra eller anpassad rekommenderare.
AKS Windows-containrar stöds inte.

Innan du börjar

AKS-klustret kör Kubernetes version 1.24 och senare.
Azure CLI version 2.52.0 eller senare har installerats och konfigurerats. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.
kubectl ska vara anslutet till klustret som du vill installera VPA.

VPA-översikt

API-objekt

Autoskalning av lodrät podd är en API-resurs i api-gruppen För automatisk skalning av Kubernetes. Den version som stöds är 0.11 och senare och finns på lagringsplatsen för Autoskalning av Kubernetes.

VPA-objektet består av tre komponenter:

Rekommenderare – den övervakar den aktuella och tidigare resursförbrukningen och tillhandahåller, baserat på den, rekommenderade värden för containrarnas cpu- och minnesbegäranden/-gränser. Rekommenderaren övervakar måtthistoriken, OOM-händelser (Out of Memory) och VPA-distributionsspecifikationen och föreslår rättvisa begäranden. Genom att tillhandahålla en korrekt konfiguration av resursbegäran och begränsningar höjs och sänks gränserna.
Updater – den kontrollerar vilken av de hanterade poddarna som har rätt resurser och dödar dem om inte så att de kan återskapas av sina kontrollanter med de uppdaterade begärandena.
VPA-antagningskontrollant – den anger rätt resursbegäranden på nya poddar (antingen skapade eller återskapade av deras kontrollant på grund av Updater-aktiviteten).

VPA-antagningskontrollant

VPA-antagningskontrollant är en binär som registrerar sig som en webbhook för muterande antagning. När varje podd har skapats hämtar den en begäran från apiservern och utvärderar om det finns en matchande VPA-konfiguration eller hittar en motsvarande och använder den aktuella rekommendationen för att ange resursbegäranden i podden.

Ett fristående jobb körs utanför VPA-antagningskontrollanten, med namnet overlay-vpa-cert-webhook-check. overlay-vpa-cert-webhook-check Används för att skapa och förnya certifikaten och registrera VPA-antagningskontrollanten som en MutatingWebhookConfiguration.

För hög tillgänglighet har AKS stöd för två antagningskontrollantrepliker.

VPA-objektåtgärdslägen

En lodrät autoskalningsresurs för poddar infogas för varje styrenhet som du vill ha automatiskt beräknade resurskrav. Det här är oftast en distribution. Det finns fyra lägen där de virtuella certifikatutfärdarna fungerar:

Auto – VPA tilldelar resursbegäranden när podden skapas och uppdaterar befintliga poddar med hjälp av önskad uppdateringsmekanism. Auto Är för närvarande likvärdigt med Recreate, och är också standardläget. När den kostnadsfria omstartsuppdateringen ("på plats") av poddbegäranden är tillgänglig kan den användas som önskad uppdateringsmekanism i Auto läget. När du använder Recreate läget avlägsnar VPA en podd om den behöver ändra sina resursbegäranden. Det kan leda till att poddarna startas om samtidigt, vilket orsakar inkonsekvenser i programmet. Du kan begränsa omstarter och upprätthålla konsekvens i den här situationen med hjälp av en PodDisruptionBudget.
Recreate – VPA tilldelar resursbegäranden när podden skapas samt uppdaterar befintliga poddar genom att avlägsna dem när de begärda resurserna skiljer sig avsevärt från den nya rekommendationen (med respekt för podduppelåsningsbudgeten, om den definieras). Det här läget bör användas sällan, bara om du behöver se till att poddarna startas om när resursbegäran ändras. Annars Auto är läget att föredra, vilket kan dra nytta av omstartsfria uppdateringar när de är tillgängliga.
Initial – VPA tilldelar endast resursbegäranden när podden skapas och ändras aldrig efteråt.
Off – VPA ändrar inte automatiskt resurskraven för poddarna. Rekommendationerna beräknas och kan inspekteras i VPA-objektet.

Distributionsmönster under programutveckling

Ett vanligt distributionsmönster som rekommenderas för dig om du inte är bekant med VPA är att utföra följande steg under programutvecklingen för att identifiera dess unika resursanvändningsegenskaper, testa VPA för att verifiera att det fungerar korrekt och testa tillsammans med andra Kubernetes-komponenter för att optimera resursanvändningen i klustret.

Ställ in UpdateMode = "Off" i produktionsklustret och kör VPA i rekommendationsläge så att du kan testa och bekanta dig med VPA. UpdateMode = "Off" kan undvika att införa en felkonfiguration som kan orsaka ett avbrott.
Etablera observerbarhet först genom att samla in telemetri för faktisk resursanvändning under en viss tidsperiod. Detta hjälper dig att förstå beteendet och tecken på symtom eller problem från container- och poddresurser som påverkas av de arbetsbelastningar som körs på dem.
Bekanta dig med övervakningsdata för att förstå prestandaegenskaperna. Baserat på den här insikten anger du önskade begäranden/gränser i enlighet med detta och sedan i nästa distribution eller uppgradering
Ange updateMode värdet till Auto, Recreateeller Initial beroende på dina krav.

Distribuera, uppgradera eller inaktivera VPA i ett kluster

I det här avsnittet distribuerar, uppgraderar eller inaktiverar du autoskalning av lodrät podd i klustret.

Om du vill aktivera VPA i ett nytt kluster använder du --enable-vpa parametern med kommandot az aks create .
```
az aks create ---name myAKSCluster --resource-group myResourceGroup --enable-vpa
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.
Om du vill aktivera VPA i ett befintligt kluster kan du använda --enable-vpa kommandot med kommandot [https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-update].
```
az aks update --name myAKSCluster --resource-group myResourceGroup --enable-vpa 
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.
Om du vill inaktivera VPA i ett befintligt kluster kan du använda --disable-vpa kommandot med kommandot [https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-update].
```
az aks update --name myAKSCluster --resource-group myResourceGroup --disable-vpa
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.
Om du vill kontrollera att poddarna för lodrät podd autoskalning har skapats använder du kommandot kubectl get .

kubectl get pods --name kube-system

Utdata från kommandot innehåller följande resultat som är specifika för VPA-poddarna. Poddarna ska visa statusen körs .

NAME                                        READY   STATUS    RESTARTS   AGE
vpa-admission-controller-7867874bc5-vjfxk   1/1     Running   0          41m
vpa-recommender-5fd94767fb-ggjr2            1/1     Running   0          41m
vpa-updater-56f9bfc96f-jgq2g                1/1     Running   0          41m

Testa installationen av Vertical Pod Autoscaler

Följande steg skapar en distribution med två poddar, var och en kör en enda container som begär 100 millicores och försöker använda något över 500 millicores. Dessutom skapas en VPA-konfiguration som pekar på distributionen. VPA observerar poddarnas beteende och efter ungefär fem minuter uppdateras de med en högre CPU-begäran.

Skapa en fil med namnet hamster.yaml och kopiera i följande manifest i exemplet Vertical Pod Autoscaler från GitHub-lagringsplatsen kubernetes/autoscaler .
Distribuera exemplet hamster.yaml Vertical Pod Autoscaler med kommandot kubectl apply och ange namnet på YAML-manifestet:
```
kubectl apply -f hamster.yaml
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.

Kör följande kubectl get-kommando för att hämta poddarna från hamsterexempelprogrammet:

kubectl get pods -l app=hamster

Exempelutdata liknar följande:

hamster-78f9dcdd4c-hf7gk   1/1     Running   0          24s
hamster-78f9dcdd4c-j9mc7   1/1     Running   0          24s

Använd kommandot kubectl describe på en av poddarna för att visa dess CPU- och minnesreservation. Ersätt "exampleID" med ett av de podd-ID:t som returnerades i dina utdata från föregående steg.
```
kubectl describe pod hamster-exampleID
```
Exempelutdata är ett kodfragment av informationen om klustret:
```
 hamster:
    Container ID:  containerd://
    Image:         k8s.gcr.io/ubuntu-slim:0.1
    Image ID:      sha256:
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
    Args:
      -c
      while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done
    State:          Running
      Started:      Wed, 28 Sep 2022 15:06:14 -0400
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:        100m
      memory:     50Mi
    Environment:  <none>
```
Podden har 100 millicpu och 50 Mibibyte minne reserverat i det här exemplet. För det här exempelprogrammet behöver podden mindre än 100 millicpu för att köras, så det finns ingen tillgänglig processorkapacitet. Poddarna reserverar också mycket mindre minne än vad som behövs. Distributionen Vertical Pod Autoscaler vpa-recommender analyserar poddarna som är värd för hamsterprogrammet för att se om kraven på processor och minne är lämpliga. Om justeringar behövs startar vpa-updater om poddarna med uppdaterade värden.
Vänta tills vpa-updatern startar en ny hamsterpodd, vilket bör ta några minuter. Du kan övervaka poddarna med kommandot kubectl get .
```
kubectl get --watch pods -l app=hamster
```
När en ny hamsterpodd startas beskriver du podden som kör kommandot kubectl describe och visar de uppdaterade cpu- och minnesreservationerna.
```
kubectl describe pod hamster-<exampleID>
```
Exempelutdata är ett kodfragment av informationen som beskriver podden:
```
State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>
```
I föregående utdata kan du se att CPU-reservationen ökade till 587 millicpu, vilket är över fem gånger det ursprungliga värdet. Minnet ökade till 262 144 kilobyte, vilket är cirka 250 Mibibyte, eller fem gånger det ursprungliga värdet. Den här podden var underbetonad och Autoskalning av lodrät podd korrigerade uppskattningen med ett mycket mer lämpligt värde.

Om du vill visa uppdaterade rekommendationer från VPA kör du kommandot kubectl describe för att beskriva information om hamster-vpa-resursen.

kubectl describe vpa/hamster-vpa

Exempelutdata är ett kodfragment av informationen om resursanvändningen:

 State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>

Ange Pod Autoscaler-begäranden

Autoskalning av lodrät podd använder VerticalPodAutoscaler objektet för att automatiskt ange resursbegäranden på poddar när updateMode har angetts till auto. Du kan ange ett annat värde beroende på dina krav och testning. I det här exemplet är updateMode inställt på Recreate.

Aktivera VPA för klustret genom att köra följande kommando. Ersätt klusternamnet myAKSCluster med namnet på ditt AKS-kluster och ersätt myResourceGroup med namnet på den resursgrupp som klustret finns i.
```
az aks update --name myAKSCluster --resource-group myResourceGroup --enable-vpa
```

Skapa en fil med namnet azure-autodeploy.yamloch kopiera i följande manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vpa-auto-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vpa-auto-deployment
  template:
    metadata:
      labels:
        app: vpa-auto-deployment
    spec:
      containers:
      - name: mycontainer
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
        resources:
          requests:
            cpu: 100m
            memory: 50Mi
        command: ["/bin/sh"]
        args: ["-c", "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"]

Det här manifestet beskriver en distribution som har två poddar. Varje podd har en container som begär 100 milliCPU och 50 MiB minne.

Skapa podden med kommandot kubectl create , som du ser i följande exempel:
```
kubectl create -f azure-autodeploy.yaml
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.

Kör följande kubectl get-kommando för att hämta poddarna:

kubectl get pods

Utdata liknar följande exempel som visar poddarnas namn och status:

NAME                                   READY   STATUS    RESTARTS   AGE
vpa-auto-deployment-54465fb978-kchc5   1/1     Running   0          52s
vpa-auto-deployment-54465fb978--namehtmj   1/1     Running   0          52s

Skapa en fil med namnet azure-vpa-auto.yamloch kopiera i följande manifest som beskriver en VerticalPodAutoscaler:
```
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-auto
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       vpa-auto-deployment
  updatePolicy:
    updateMode: "Recreate"
```
Värdet targetRef.name anger att alla poddar som styrs av en distribution med namnet vpa-auto-deployment tillhör VerticalPodAutoscaler. Värdet updateModeRecreate för innebär att den lodräta autoskalningsstyrenheten för poddar kan ta bort en podd, justera CPU- och minnesbegäranden och sedan skapa en ny podd.
Tillämpa manifestet på klustret med hjälp av kommandot kubectl apply :
```
kubectl create -f azure-vpa-auto.yaml
```

Vänta några minuter och visa de poddar som körs igen genom att köra följande kubectl get-kommando :

kubectl get pods

Utdata liknar följande exempel som visar att poddnamnen har ändrats och status för poddarna:

NAME                                   READY   STATUS    RESTARTS   AGE
vpa-auto-deployment-54465fb978-qbhc4   1/1     Running   0          2m49s
vpa-auto-deployment-54465fb978-vbj68   1/1     Running   0          109s

Få detaljerad information om en av dina poddar som körs med hjälp av kommandot Kubectl get . Ersätt podName med namnet på en av dina poddar som du hämtade i föregående steg.

kubectl get pod podName --output yaml

Utdata liknar följande exempel, som visar att den lodräta autoskalningsstyrenheten för poddar har ökat minnesbegäran till 262144k och CPU-begäran till 25 milliCPU.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    vpaObservedContainers: mycontainer
    vpaUpdates: 'Pod resources updated by vpa-auto: container 0: cpu request, memory
      request'
  creationTimestamp: "2022-09-29T16:44:37Z"
  generateName: vpa-auto-deployment-54465fb978-
  labels:
    app: vpa-auto-deployment

spec:
  containers:
  - args:
    - -c
    - while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done
    command:
    - /bin/sh
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    imagePullPolicy: IfNotPresent
    name: mycontainer
    resources:
      requests:
        cpu: 25m
        memory: 262144k

Om du vill få detaljerad information om autoskalning av lodrät podd och dess rekommendationer för processor och minne använder du kommandot kubectl get :
```
kubectl get vpa vpa-auto --output yaml
```
Utdata liknar följande exempel:
```
 recommendation:
  containerRecommendations:
  - containerName: mycontainer
    lowerBound:
      cpu: 25m
      memory: 262144k
    target:
      cpu: 25m
      memory: 262144k
    uncappedTarget:
      cpu: 25m
      memory: 262144k
    upperBound:
      cpu: 230m
      memory: 262144k
```
Resultatet visar target att attributet anger att för att containern ska köras optimalt behöver den inte ändra cpu- eller minnesmålet. Dina resultat kan variera där rekommendationen för mål-CPU och minne är högre.

Autoskalning av lodrät podd använder attributen lowerBound och upperBound för att avgöra om en podd ska tas bort och ersättas med en ny podd. Om en podd har begäranden som är mindre än den nedre gränsen eller större än den övre gränsen, tar autoskalningsenheten lodrät podd bort podden och ersätter den med en podd som uppfyller målattributet.

Extrarekommendator för lodrät podd autoskalning

I VPA är en av kärnkomponenterna rekommenderaren. Den ger rekommendationer för resursanvändning baserat på resursförbrukning i realtid. AKS distribuerar en rekommenderare när ett kluster aktiverar VPA. Du kan distribuera en anpassad rekommenderare eller en extra rekommendationer med samma avbildning som standardvärdet. Fördelen med att ha en anpassad rekommenderare är att du kan anpassa rekommendationslogik. Med en extra rekommenderare kan du partitionera virtuella vpn-enheter till flera rekommenderare om det finns många VPA-objekt.

Följande exempel är en extra rekommendation som du tillämpar på ditt befintliga AKS-kluster. Sedan konfigurerar du VPA-objektet så att det använder den extra rekommenderaren.

Skapa en fil med namnet extra_recommender.yaml och kopiera i följande manifest:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: extra-recommender 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      app: extra-recommender 
  template: 
    metadata: 
      labels: 
        app: extra-recommender 
    spec: 
      serviceAccountName: vpa-recommender 
      securityContext: 
        runAsNonRoot: true 
        runAsUser: 65534 # nobody 
      containers: 
      - name: recommender 
        image: registry.k8s.io/autoscaling/vpa-recommender:0.13.0 
        imagePullPolicy: Always 
        args: 
          - --recommender--nameame=extra-recommender 
        resources: 
          limits: 
            cpu: 200m 
            memory: 1000Mi 
          requests: 
            cpu: 50m 
            memory: 500Mi 
        ports: 
        - name: prometheus 
          containerPort: 8942

Distribuera exemplet extra-recomender.yaml Vertical Pod Autoscaler med kommandot kubectl apply och ange namnet på YAML-manifestet.
```
kubectl apply -f extra-recommender.yaml 
```
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.

Skapa en fil med namnet hamnster_extra_recommender.yaml och kopiera i följande manifest:

apiVersion: "autoscaling.k8s.io/v1" 
kind: VerticalPodAutoscaler 
metadata: 
  name: hamster-vpa 
spec: 
  recommenders:  
    - name: 'extra-recommender' 
  targetRef: 
    apiVersion: "apps/v1" 
    kind: Deployment 
    name: hamster 
  updatePolicy: 
    updateMode: "Auto" 
  resourcePolicy: 
    containerPolicies: 
      - containerName: '*' 
        minAllowed: 
          cpu: 100m 
          memory: 50Mi 
        maxAllowed: 
          cpu: 1 
          memory: 500Mi 
        controlledResources: ["cpu", "memory"] 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: hamster 
spec: 
  selector: 
    matchLabels: 
      app: hamster 
  replicas: 2 
  template: 
    metadata: 
      labels: 
        app: hamster 
    spec: 
      securityContext: 
        runAsNonRoot: true 
        runAsUser: 65534 # nobody 
      containers: 
        - name: hamster 
          image: k8s.gcr.io/ubuntu-slim:0.1 
          resources: 
            requests: 
              cpu: 100m 
              memory: 50Mi 
          command: ["/bin/sh"] 
          args: 
            - "-c" 
            - "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"

Om memory inte anges i controlledResourcessvarar inte rekommenderaren på OOM-händelser. I det här fallet ställer du bara in CPU i controlledValues. controlledValues låter dig välja om du vill uppdatera containerns resursbegäranden efter RequestsOnly alternativ, eller både resursbegäranden och begränsningar med hjälp av RequestsAndLimits alternativet. Standardvärdet är RequestsAndLimits. Om du använder RequestsAndLimits alternativet beräknas begäranden baserat på den faktiska användningen och gränserna beräknas baserat på den aktuella poddens förhållande för begäran och gräns.

Om du till exempel börjar med en podd som begär 2 processorer och begränsar till 4 processorer, anger VPA alltid gränsen till dubbelt så mycket som begäranden. Samma princip gäller för minnet. När du använder RequestsAndLimits läget kan det fungera som en skiss för dina första begäranden och begränsningar för programresurser.

Du kan förenkla VPA-objektet med hjälp av autoläge och beräkningsrekommendationer för både CPU och minne.

hamster_extra-recomender.yaml Distribuera exemplet med kommandot kubectl apply och ange namnet på DITT YAML-manifest.
```
kubectl apply -f hamster_customized_recommender.yaml
```
Vänta tills vpa-updatern startar en ny hamsterpodd, vilket bör ta några minuter. Du kan övervaka poddarna med kommandot kubectl get .
```
kubectl get --watch pods -l app=hamster
```

När en ny hamsterpodd startas beskriver du podden som kör kommandot kubectl describe och visar de uppdaterade cpu- och minnesreservationerna.

kubectl describe pod hamster-<exampleID>

Exempelutdata är ett kodfragment av informationen som beskriver podden:

State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>