Scalabilità automatica verticale dei pod nel servizio Azure Kubernetes (AKS)

Articolo
03/22/2024

Questo articolo offre una panoramica di Vertical Pod Autoscaler (VPA) nel servizio Azure Kubernetes (AKS), basato sulla versione open source di Kubernetes. Una volta configurato, imposta automaticamente le richieste di risorse e i limiti sui contenitori per ogni di lavoro in base all'utilizzo passato. VPA libera CPU e memoria per gli altri pod e contribuisce a rendere effettivo l'utilizzo del cluster del servizio Azure Kubernetes.

La scalabilità automatica verticale dei pod offre raccomandazioni per l'utilizzo delle risorse nel tempo. Per gestire gli aumenti improvvisi dell'utilizzo delle risorse, usare Horizontal Pod Autoscaler, che ridimensiona il numero di repliche pod in base alle esigenze.

Vantaggi

Vertical Pod Autoscaler offre i vantaggi seguenti:

Analizza e regola le risorse del processore e della memoria, in modo da dimensionare correttamente le applicazioni. VPA non è responsabile solo dell'aumento, ma anche della riduzione delle risorse in base all'uso nel tempo.
Un pod viene rimosso se deve modificare le richieste di risorse, se la modalità di ridimensionamento è impostata su autoo recreate.
Imposta vincoli di CPU e memoria per singoli contenitori specificando un criterio di risorsa
Assicura che i nodi dispongano di risorse corrette per la pianificazione dei pod
Registrazione configurabile di eventuali modifiche apportate alle risorse del processore o della memoria
Migliora l'utilizzo delle risorse del cluster e libera CPU e memoria per altri pod.

Limiti

La scalabilità automatica verticale dei pod supporta un massimo di 1.000 pod associati a VerticalPodAutoscaler oggetti per cluster.
VPA potrebbe suggerire più risorse rispetto a quelle disponibili nel cluster. Di conseguenza, ciò impedisce che il pod venga assegnato a un nodo ed eseguito, perché il nodo non dispone di risorse sufficienti. È possibile superare questa limitazione impostando LimitRange sul numero massimo di risorse disponibili per spazio dei nomi, che garantisce che i pod non richiedano più risorse di quanto specificato. Inoltre, è possibile impostare le raccomandazioni di risorse massime consentite per pod in un oggetto VerticalPodAutoscaler. VPA non può superare completamente un problema di risorse nodo insufficienti. L'intervallo del limite è fisso, ma l'utilizzo delle risorse del nodo viene modificato in modo dinamico.
Non è consigliabile utilizzare VPA (Vertical Pod Autoscaler) con Horizontal Pod Autoscaler, che ridimensiona in base alle stesse metriche di utilizzo di CPU e memoria.
Il modulo di raccomandazione VPA archivia solo fino a otto giorni di dati cronologici.
VPA non supporta carichi di lavoro basati su JVM a causa di una visibilità limitata sull'utilizzo effettivo della memoria del carico di lavoro.
Non è consigliabile o supportato eseguire la propria implementazione di VPA insieme a questa implementazione gestita di VPA. È tuttavia supportato avere un modulo di raccomandazione aggiuntivo o personalizzato.
I contenitori Windows del servizio Azure Kubernetes non sono supportati.

Operazioni preliminari

Il cluster del servizio Azure Kubernetes esegue Kubernetes versione 1.24 e successive.
L'Interfaccia della riga di comando di Azure versione 2.52.0 o successiva è installata e configurata. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
kubectl deve essere connesso al cluster su cui si vuole installare VPA.

Panoramica di VPA

Oggetto API

Vertical Pod Autoscaler è una risorsa API del gruppo di API di scalabilità automatica Kubernetes. La versione supportata è la versione 0.11 e successiva ed è disponibile nel repository di scalabilità automatica Kubernetes.

L'oggetto VPA è costituito da tre componenti:

Modulo di raccomandazione: monitora l'utilizzo attuale e passato delle risorse e, in base a esso, specifica i valori consigliati per le richieste e i limiti di cpu e memoria dei contenitori. Il modulo di raccomandazione monitora la cronologia delle metriche, gli eventi OOM (Out of Memory) e la specifica di distribuzione VPA e suggerisce le richieste corrette. Offrendo una configurazione corretta di richieste di risorse e limiti, i limiti vengono aumentati e ridotti.
Strumento di aggiornamento: controlla su quali pod gestiti sono impostate le risorse corrette e, in caso contrario, le elimina, in modo che possano essere ricreate dai controller con le richieste aggiornate.
Controller di ammissione VPA: imposta le richieste di risorse corrette sui nuovi pod (creati o ricreati dal controller a causa dell'attività dello strumento di aggiornamento).

Controller di ammissione VPA

Il controller di ammissione VPA è un binario che viene registrato come webhook di ammissione in mutazione. Con ogni pod creato, ottiene una richiesta dal server api e valuta se è presente una configurazione VPA corrispondente oppure Individua una configurazione corrispondente e usa la raccomandazione corrente per impostare le richieste di risorse nel pod.

Un processo autonomo viene eseguito all'esterno del controller di ammissione VPA, denominato overlay-vpa-cert-webhook-check. Il processo overlay-vpa-cert-webhook-check viene usato per creare e rinnovare i certificati e registrare il controller di ammissione VPA come MutatingWebhookConfiguration.

Per la disponibilità elevata, il servizio Azure Kubernetes supporta due repliche del controller di ammissione.

Modalità operative dell'oggetto VPA

Una risorsa Vertical Pod Autoscaler viene inserita per ogni controller in cui si desidera che i requisiti delle risorse vengano calcolati automaticamente. Si tratta in genere di una distribuzione. Esistono quattro modalità in cui operano le risorse VPA:

Auto: VPA assegna le richieste di risorse durante la creazione del pod e aggiorna i pod esistenti usando il meccanismo di aggiornamento preferito. Attualmente, Auto equivale a Recreateed è anche la modalità predefinita. Dopo il riavvio gratuito ("sul posto") è disponibile l'aggiornamento delle richieste di pod, che può essere usato come meccanismo di aggiornamento preferito dalla modalità Auto. Quando si usa la modalità Recreate, VPA rimuove un pod se deve modificare le richieste di risorse. Ciò può causare il riavvio di tutti i pod contemporaneamente, determinando incoerenze dell'applicazione. È possibile limitare i riavvii e mantenere la coerenza in questa situazione usando un PodDisruptionBudget.
Recreate: VPA assegna le richieste di risorse durante la creazione del pod e aggiorna i pod esistenti, rimuovendoli quando le risorse richieste differiscono in modo significativo rispetto alla nuova raccomandazione (rispettando il budget per l'interruzione dei pod, se definito). Questa modalità deve essere usata raramente, solo se è necessario assicurarsi che i pod vengano riavviati ogni volta che la richiesta di risorsa cambia. In caso contrario, è preferibile la modalità Auto, che può sfruttare gli aggiornamenti senza riavvio una volta disponibili.
Initial: VPA assegna le richieste di risorse solo durante la creazione dei pod e non cambia mai in seguito.
Off: VPA non modifica automaticamente i requisiti di risorse dei pod. Le raccomandazioni vengono calcolate e possono essere esaminate nell'oggetto VPA.

Modello di distribuzione durante lo sviluppo di applicazioni

Un modello di distribuzione comune consigliato se non si ha familiarità con VPA consiste nell'eseguire i passaggi seguenti durante lo sviluppo di applicazioni per identificare le caratteristiche di utilizzo univoco delle risorse, testare VPA per verificare che funzioni correttamente e testare nello stesso tempo altri componenti Kubernetes per ottimizzare l'utilizzo delle risorse del cluster.

Impostare UpdateMode = "Off" nel cluster di produzione ed eseguire VPA in modalità di raccomandazione per testare e acquisire familiarità con VPA. UpdateMode = "Off" può evitare di introdurre una configurazione errata che può causare un'interruzione.
Stabilire prima l'osservabilità raccogliendo i dati di telemetria effettivi sull'utilizzo delle risorse in un determinato periodo di tempo. Ciò consente di comprendere il comportamento e i segni di sintomi o problemi derivanti dalle risorse contenitore e pod influenzati dai carichi di lavoro in esecuzione.
Acquisire familiarità con i dati di monitoraggio per comprendere le caratteristiche delle prestazioni. In base a queste informazioni dettagliate, impostare le richieste e i limiti desiderati e quindi nella distribuzione o nell'aggiornamento successivo
Impostare il valore updateMode su Auto, Recreate o Initial a seconda delle esigenze.

Distribuire, aggiornare o disabilitare VPA in un cluster

In questa sezione viene illustrato come distribuire, aggiornare o disabilitare VPA nel cluster.

Per abilitare VPA in un nuovo cluster, usare il parametro --enable-vpa con il comando az aks create .
```
az aks create \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --enable-vpa \
    --generate-ssh-keys
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.
Facoltativamente, per abilitare VPA in un cluster esistente, usare --enable-vpa con il comando [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 
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.
Facoltativamente, per disabilitare VPA in un cluster esistente, usare --disable-vpa con il comando [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
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.
Per verificare che i pod VPA siano stati creati correttamente, usare il comando kubectl get.

kubectl get pods --name kube-system

L'output del comando include i risultati seguenti specifici per i pod VPA. I pod devono presentare uno stato in esecuzione.

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

Testare l'installazione di Vertical Pod Autoscaler

I passaggi seguenti consentono di creare una distribuzione con due pod, ognuno dei quali esegue un singolo contenitore che richiede 100 millicore e tenta di utilizzare un numero di millicore leggermente superiore a 500. Viene anche creata una configurazione VPA, che punta alla distribuzione. VPA osserva il comportamento dei pod e, dopo circa cinque minuti, i pod vengono aggiornati con una richiesta di CPU più elevata.

Creare un file denominato hamster.yaml e copiare il seguente manifesto dell'esempio di VPA dal repository GitHub kubernetes/autoscaler.
Distribuire l'esempio di VPA hamster.yaml usando il comando kubectl apply e specificare il nome del manifesto YAML:
```
kubectl apply -f hamster.yaml
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

Eseguire il comando kubectl get seguente per ottenere i pod dall'applicazione di esempio di hamster:

kubectl get pods -l app=hamster

L'output di esempio sarà simile al seguente:

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

Usare il comando kubectl describe su uno dei pod per visualizzare la relativa prenotazione di CPU e memoria. Sostituire "exampleID" con uno degli ID pod restituiti nell'output del passaggio precedente.
```
kubectl describe pod hamster-exampleID
```
L'output di esempio è un frammento di informazioni sul cluster:
```
 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>
```
In questo esempio il pod ha 100 millicpu e 50 Mibibyte di memoria riservata. Per questa applicazione di esempio, il pod richiede meno di 100 millicpu per l'esecuzione, quindi non è disponibile alcuna capacità di CPU. I pod, inoltre, riservano una quantità di memoria molto inferiore a quella necessaria. La distribuzione vpa-recommender di VPA analizza i pod che ospitano l'applicazione hamster per verificare se i requisiti di CPU e memoria sono appropriati. Se sono necessarie modifiche, vpa-updater riavvia i pod con valori aggiornati.
Attendere che vpa-updater avvii un nuovo pod di hamster, operazione che dovrebbe richiedere alcuni minuti. È possibile monitorare i pod usando il comando kubectl get.
```
kubectl get --watch pods -l app=hamster
```
Quando viene avviato un nuovo pod di hamster, descrivere il pod che esegue il comando kubectl describe e visualizzare le prenotazioni di CPU e memoria aggiornate.
```
kubectl describe pod hamster-<exampleID>
```
L'output di esempio è un frammento di informazioni che descrivono il pod:
```
State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>
```
Nell'output precedente è possibile notare che la prenotazione di CPU ha raggiunto 587 millicpu, ovvero più di cinque volte il valore originale. La memoria ha raggiunto 262.144 kilobyte, ovvero circa 250 Mibibyte o cinque volte il valore originale. Questo pod non aveva risorse sufficienti e il Vertical Pod Autoscaler ha corretto la stima con un valore molto più appropriato.
Per visualizzare le raccomandazioni aggiornate da VPA, eseguire il comando kubectl describe per descrivere le informazioni sulle risorse hamster-vpa.
```
kubectl describe vpa/hamster-vpa
```
L'output di esempio è un frammento di informazioni sull'utilizzo delle risorse:
```
 State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>
```

Impostare le richieste di Pod Autoscaler

La scalabilità automatica verticale dei pod usa l'oggetto VerticalPodAutoscaler per impostare automaticamente le richieste di risorse nei pod quando updateMode è impostato su Auto. È possibile impostare un valore diverso a seconda delle esigenze e dei test. In questo esempio updateMode è impostato su Recreate.

Per abilitare VPA per il cluster, eseguire questo comando. Sostituire il nome del cluster myAKSCluster con il nome del cluster del servizio Azure Kubernetes e sostituire myResourceGroup con il nome del gruppo di risorse in cui è ospitato il cluster.
```
az aks update --name myAKSCluster --resource-group myResourceGroup --enable-vpa
```

Creare un file denominato azure-autodeploy.yaml e copiarlo nel manifesto seguente.

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"]

Questo manifesto descrive una distribuzione con due pod. Ogni pod ha un contenitore che richiede 100 milliCPU e 50 MiB di memoria.

Creare il pod con il comando kubectl create, come illustrato nell'esempio seguente:
```
kubectl create -f azure-autodeploy.yaml
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

Eseguire il comando kubectl get seguente per ottenere i pod:

kubectl get pods

L'output è simile all'esempio seguente che mostra il nome e lo stato dei pod:

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

Creare un file denominato azure-vpa-auto.yaml e copiarlo nel manifesto seguente che descrive un 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"
```
Il valore targetRef.name specifica che qualsiasi pod controllato da una distribuzione denominata vpa-auto-deployment appartiene a VerticalPodAutoscaler. Il valore updateMode di Recreate indica che il controller VPA può eliminare un pod, regolare le richieste di CPU e memoria e quindi creare un nuovo pod.
Applicare il manifesto al cluster usando il comando kubectl apply:
```
kubectl create -f azure-vpa-auto.yaml
```

Attendere alcuni minuti e visualizzare di nuovo i pod in esecuzione tramite il comando kubectl get:

kubectl get pods

L'output è simile all'esempio seguente che mostra i nomi dei pod che sono stati modificati e lo stato dei pod:

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

Ottenere informazioni dettagliate su uno dei pod in esecuzione usando il comando Kubectl get. Sostituire podName con il nome di uno dei pod recuperati nel passaggio precedente.

kubectl get pod podName --output yaml

L'output è simile all'esempio seguente, che mostra che il controller Vertical Pod Autoscaler ha aumentato la richiesta di memoria a 262144k e la richiesta di CPU a 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

Per ottenere informazioni dettagliate su Vertical Pod Autoscaler e le relative raccomandazioni per CPU e memoria, usare il comando kubectl get:
```
kubectl get vpa vpa-auto --output yaml
```
L'output sarà simile al seguente esempio:
```
 recommendation:
  containerRecommendations:
  - containerName: mycontainer
    lowerBound:
      cpu: 25m
      memory: 262144k
    target:
      cpu: 25m
      memory: 262144k
    uncappedTarget:
      cpu: 25m
      memory: 262144k
    upperBound:
      cpu: 230m
      memory: 262144k
```
I risultati mostrano che l'attributo target specifica che per l'esecuzione ottimale del contenitore non è necessario modificare la CPU o la memoria di destinazione. I risultati possono variare in base alla raccomandazione di CPU e memoria di destinazione più elevata.

Vertical Pod Autoscaler usa gli attributi lowerBound e upperBound per decidere se eliminare un pod e sostituirlo con un nuovo pod. Se un pod ha richieste minori del limite inferiore o maggiori del limite superiore, Vertical Pod Autoscaler elimina il pod e lo sostituisce con un pod che soddisfa l'attributo di destinazione.

Modulo di raccomandazione aggiuntivo per Vertical Pod Autoscaler

In VPA, uno dei componenti principali è il modulo di raccomandazione. Offre raccomandazioni per l'utilizzo delle risorse in base all'utilizzo delle risorse in tempo reale. Il servizio Azure Kubernetes distribuisce un modulo di raccomandazione quando un cluster abilita VPA. È possibile distribuire un modulo di raccomandazione personalizzato o un modulo di raccomandazione aggiuntivo con la stessa immagine del modulo predefinito. Il vantaggio di avere un modulo di raccomandazione personalizzato sta nel fatto che è possibile personalizzare la logica di raccomandazione. Con un modulo di raccomandazione aggiuntivo, è possibile partizionare gli oggetti VPA su più moduli di raccomandazione, se sono presenti molti oggetti VPA.

L'esempio seguente è un modulo di raccomandazione aggiuntivo da applicare al cluster del servizio Azure Kubernetes esistente. Configurare quindi l'oggetto VPA in modo da usare il modulo di raccomandazione consigliato.

Creare un file denominato extra_recommender.yaml e copiarlo nel manifesto seguente:

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

Distribuire l'esempio di VPA extra-recomender.yaml usando il comando kubectl apply e specificare il nome del manifesto YAML.
```
kubectl apply -f extra-recommender.yaml 
```
Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

Creare un file denominato hamnster_extra_recommender.yaml e copiarlo nel manifesto seguente:

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"

Se memory non è specificato in controlledResources, il modulo di raccomandazione non risponde agli eventi OOM. In questo caso, si imposta la CPU solo in controlledValues. controlledValues consente di scegliere se aggiornare le richieste di risorse del contenitore in base all'opzione RequestsOnly oppure sia le richieste di risorse che i limiti usando l'opzione RequestsAndLimits. Il valore predefinito è RequestsAndLimits. Se si usa l'opzione RequestsAndLimits, le richieste vengono calcolate in base all'utilizzo effettivo e i limiti vengono calcolati in base al rapporto tra le richieste e i limiti del pod corrente.

Ad esempio, se si inizia con un pod che richiede 2 CPU e ha un limite di 4 CPU, VPA imposta sempre il limite in modo che sia il doppio delle richieste. Lo stesso principio si applica alla memoria. Quando si usa la modalità RequestsAndLimits, questa può servire come modello per le richieste e i limiti iniziali delle risorse dell'applicazione.

È possibile semplificare l'oggetto VPA usando la modalità Auto e le raccomandazioni di calcolo per CPU e memoria.

Distribuire l'esempio hamster_extra-recomender.yaml usando il comando kubectl apply e specificare il nome del manifesto YAML.
```
kubectl apply -f hamster_customized_recommender.yaml
```
Attendere che vpa-updater avvii un nuovo pod di hamster, operazione che dovrebbe richiedere alcuni minuti. È possibile monitorare i pod usando il comando kubectl get.
```
kubectl get --watch pods -l app=hamster
```
Quando viene avviato un nuovo pod di hamster, descrivere il pod che esegue il comando kubectl describe e visualizzare le prenotazioni di CPU e memoria aggiornate.
```
kubectl describe pod hamster-<exampleID>
```
L'output di esempio è un frammento di informazioni che descrivono il pod:
```
State:          Running
  Started:      Wed, 28 Sep 2022 15:09:51 -0400
Ready:          True
Restart Count:  0
Requests:
  cpu:        587m
  memory:     262144k
Environment:  <none>
```

Per visualizzare le raccomandazioni aggiornate da VPA, eseguire il comando kubectl describe per descrivere le informazioni sulle risorse hamster-vpa.

kubectl describe vpa/hamster-vpa

L'output di esempio è un frammento di informazioni sull'utilizzo delle risorse:

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

Risoluzione dei problemi

Per diagnosticare i problemi relativi all'installazione di VPA, seguire questa procedura.

Controllare se tutti i componenti di sistema sono in esecuzione usando il comando seguente:
```
kubectl --namespace=kube-system get pods|grep vpa
```

L'output dovrebbe elencare tre pod: modulo di raccomandazione, strumento di aggiornamento e controller di ammissione, tutti con lo stato di Running.

Verificare se i componenti di sistema registrano errori. Per ognuno dei pod restituiti dal comando precedente, eseguire il comando seguente:
```
kubectl --namespace=kube-system logs [pod name] | grep -e '^E[0-9]\{4\}'
```
Verificare che la definizione di risorsa personalizzata sia stata creata eseguendo il comando seguente:
```
kubectl get customresourcedefinition | grep verticalpodautoscalers
```

Passaggi successivi

Questo articolo ha illustrato come ridimensionare automaticamente l'utilizzo delle risorse, ad esempio CPU e memoria, dei nodi del cluster in base ai requisiti dell'applicazione.

È anche possibile usare il componente di scalabilità automatica orizzontale dei pod per regolare automaticamente il numero di pod che eseguono l'applicazione. Per istruzioni sull'uso del componente di scalabilità automatica orizzontale dei pod, vedere Ridimensionare le applicazioni nel servizio Azure Kubernetes.
Per altre informazioni sulle definizioni per gli oggetti VPA correlati, vedere Vertical Pod Autoscaler [Informazioni di riferimento sulle API].

Condividi tramite