

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Scalabilità degli ambienti Beanstalk Cluster
<a name="configuring-cluster-scaling"></a>

Un ambiente Beanstalk Cluster si ridimensiona modificando il numero di repliche dell'applicazione in esecuzione. * * Una replica è una copia in esecuzione dell'immagine del contenitore. Amazon EKS fornisce la capacità di nodo necessaria a tali repliche e aggiunge o rimuove nodi per adattarli, in modo da dimensionare l'applicazione anziché un parco di istanze.

Questa è la principale differenza rispetto a Beanstalk Standard, che ridimensiona un gruppo Auto Scaling di istanze Amazon EC2. I `aws:autoscaling:*` namespace non si applicano a un ambiente Beanstalk Cluster. Il ridimensionamento viene invece configurato tramite il namespace e i relativi namespace secondari. `aws:elasticbeanstalk:eks:environment:autoscaling` Per ogni opzione e i relativi valori accettati, consulta. [Opzioni di configurazione per ambienti Beanstalk Cluster](command-options-general-eks.md)

## Impostazione dei limiti della replica
<a name="configuring-cluster-scaling-replicas"></a>

Due opzioni limitano il numero di repliche: `min-replica` e`max-replica`, entrambe nel `aws:elasticbeanstalk:eks:environment:autoscaling` namespace. Elastic Beanstalk mantiene il conteggio delle repliche tra di loro.

Imposta entrambe le opzioni sullo stesso valore per eseguire un numero fisso di repliche. Imposta `max-replica` un valore più alto di `min-replica` per consentire all'ambiente di scalare tra i due. Un ambiente esegue sempre almeno una replica, perché `min-replica` accetta `1` come valore più basso.

```
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=2 \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=20
```

## In che modo Elastic Beanstalk decide quando scalare
<a name="configuring-cluster-scaling-triggers"></a>

Entro questi limiti, uno o più * trigger * determinano il numero di repliche. Elastic Beanstalk valuta i trigger in base all'intervallo impostato. `polling-interval` Quando i trigger smettono di segnalare l'attività, Elastic Beanstalk attende il periodo `cooldown-period` impostato prima di ridimensionare nuovamente l'ambiente, il che evita una breve pausa prima di rimuovere le repliche che stanno per essere nuovamente necessarie.

Se non si configura alcun trigger, l'ambiente si ridimensiona in base all'utilizzo della CPU delle relative repliche. Le sezioni rimanenti descrivono i trigger che è invece possibile configurare.

## Scalabilità della CPU o della memoria
<a name="configuring-cluster-scaling-cpu-memory"></a>

Per scalare in base alle risorse consumate dalle repliche, impostate un tipo di metrica e un valore target nel namespace. `aws:elasticbeanstalk:eks:environment:autoscaling:trigger` Elastic Beanstalk aggiunge o rimuove le repliche per mantenere l'ambiente vicino all'obiettivo impostato.
+ Per CPU, set e. `cpu-metric-type` `cpu-value`
+ Per la memoria, imposta `memory-metric-type` e`memory-value`.

Un tipo di metrica `Utilization` considera il valore come una percentuale di ciò che la replica riserva tramite le `memory` opzioni `cpu` and, quindi a `cpu-value` si `75` rivolge al 75 percento della CPU riservata. Un tipo di metrica `AverageValue` considera il valore come un importo assoluto per replica.

È possibile impostare sia la CPU che il trigger di memoria su un ambiente.

```
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-metric-type,Value=Utilization \
        Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-value,Value=75
```

## Ridimensionamento in base a una pianificazione
<a name="configuring-cluster-scaling-schedule"></a>

Per eseguire un numero selezionato di repliche durante una finestra temporale ricorrente, imposta `cron` e `scaler-type` descrivi la finestra in`scaler-metadata`, che accetta un oggetto JSON con quattro campi.


| Campo | Description | 
| --- | --- | 
| timezone | Il fuso orario in cui è espressa la finestra, come un nome di fuso orario IANA comeUTC,, o. America/New\_York Asia/Tokyo | 
| start | Quando la finestra si apre, come espressione cron a cinque campi (minuto, ora, giorno del mese, mese, giorno della settimana). | 
| end | Quando la finestra si chiude, nello stesso formato. | 
| desiredReplicas | Il numero di repliche da eseguire mentre la finestra è aperta. Scegli un valore entro i tuoi min-replica limiti. max-replica | 

Fuori dalla finestra, l'ambiente ritorna a`min-replica`. L'esempio seguente esegue cinque repliche durante le ore lavorative dei giorni feriali in UTC:

```
$ cat schedule.json
[
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-type",
    "Value": "cron"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-metadata",
    "Value": "{\"timezone\":\"UTC\",\"start\":\"0 8 * * 1-5\",\"end\":\"0 18 * * 1-5\",\"desiredReplicas\":\"5\"}"
  }
]
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings file://schedule.json
```

Un ambiente richiede una pianificazione. Per variare il numero di repliche in più finestre, ad esempio una diversa pianificazione del fine settimana, combina la pianificazione con un altro trigger come descritto in[Combinazione di trigger](#configuring-cluster-scaling-combining).

**Nota**  
Le impostazioni vengono inserite in un file perché un `scaler-metadata` valore è esso stesso un documento JSON. Per i moduli AWS CLI accettati`--option-settings`, vedi [ Utilizzo della sintassi abbreviata in. AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-shorthand.html)

## Ridimensionamento di una metrica dal tuo endpoint
<a name="configuring-cluster-scaling-metrics-api"></a>

Per scalare in base a un valore impostato dai report del servizio, ad esempio la profondità della coda o il conteggio dei lavori in corso. `scaler-type` `metrics-api` Elastic Beanstalk legge un endpoint HTTP fornito dall'utente e lo ridimensiona in base al numero che vi trova. Descrivi l'endpoint in. `scaler-metadata`


| Campo | Description | 
| --- | --- | 
| url | L'endpoint letto da Elastic Beanstalk. | 
| valueLocation | Dove si trova il numero nella risposta JSON, come percorso punteggiato. Per il corpo di una risposta di{"data":{"result":[{"value":"500"}]}}, la posizione è. data.result.0.value | 
| targetValue | La quantità che una replica dovrebbe gestire. | 

Elastic Beanstalk divide il valore riportato per `targetValue` e lo arrotonda per ottenere il numero di repliche, quindi mantiene tale conteggio entro i limiti della replica. Con un `targetValue` of`100`, un valore riportato di richiede cinque repliche. `500`

È possibile puntare il trigger verso il proprio ambiente. Poiché l'URL dell'ambiente è noto solo dopo il suo avvio, è necessario impostarlo `url` in un aggiornamento anziché in fase di creazione.

L'esempio seguente si adatta alla profondità riportata dall'applicazione, con una replica ogni 100 unità di lavoro segnalate:

```
$ cat trigger.json
[
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-type",
    "Value": "metrics-api"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
    "OptionName": "scaler-metadata",
    "Value": "{\"url\":\"https://{{my-service.example.com}}/queue-depth\",\"valueLocation\":\"data.result.0.value\",\"targetValue\":\"100\"}"
  }
]
$ aws elasticbeanstalk update-environment \
    --environment-name {{my-cluster-env}} \
    --option-settings file://trigger.json
```

### Autenticazione sull'endpoint
<a name="configuring-cluster-scaling-metrics-api-auth"></a>

Se l'endpoint richiede delle credenziali, memorizzale in un AWS Secrets Manager segreto e `scaler-auth-secret` impostale sull'ARN del segreto. Puoi impostarlo solo quando lo è. `scaler-type` `metrics-api` `scaler-auth-mode`Imposta lo schema previsto dal tuo endpoint. Il valore del segreto è un oggetto JSON le cui chiavi dipendono da quello schema.


| Modalità di autenticazione | Chiavi obbligatorie nel segreto | 
| --- | --- | 
| bearer, l'impostazione predefinita | token | 
| basic | username e password | 
| apiKey | apiKey | 
| tls | ca, cert e key | 

Imposta anche l'`application-role`opzione dell'ambiente. Elastic Beanstalk monta le credenziali nelle repliche tramite la Pod Identity dell'ambiente, che esiste solo se è impostata. `application-role` Senza di esso, il montaggio fallisce e le repliche non si avviano. Un trigger di pianificazione non lo richiede, così come un endpoint di metriche che non richiede credenziali.

Il ruolo * applicativo dell'ambiente * legge il segreto, quindi assegnatelo entrambi `secretsmanager:GetSecretValue` e inserite l'`secretsmanager:DescribeSecret`ARN del segreto. Elastic Beanstalk aggiorna le credenziali in base a una pianificazione e l'aggiornamento verifica la versione corrente del segreto, quindi un ambiente concesso si `GetSecretValue` avvia solo normalmente e poi fallisce a ogni aggiornamento successivo. Per i ruoli utilizzati da un ambiente Beanstalk Cluster, vedere. [Autorizzazioni per Beanstalk Cluster](beanstalk-cluster-permissions.md)

Questo segreto è separato dall'`secrets`opzione che fornisce i segreti all'applicazione. La modifica del valore di `scaler-auth-secret` sostituisce le repliche dell'ambiente, poiché le credenziali vengono montate all'avvio di una replica.

## Combinazione di trigger
<a name="configuring-cluster-scaling-combining"></a>

Un ambiente utilizza un trigger basato sugli eventi, una pianificazione o una metrica degli endpoint, `scaler-type` e `scaler-metadata` descrive un singolo trigger. Può portare i trigger della CPU e della memoria insieme a quello.

Vale la pena conoscere due comportamenti prima di combinarli:
+ L'impostazione `scaler-type` sostituisce il ridimensionamento predefinito della CPU descritto in. [In che modo Elastic Beanstalk decide quando scalare](#configuring-cluster-scaling-triggers) Per mantenere il ridimensionamento anche sulla CPU, imposta `cpu-metric-type` e in modo esplicito. `cpu-value`
+ Quando si applica più di un trigger, vince il numero di repliche più alto. Una pianificazione che richiede cinque repliche e un trigger della CPU che ne richiede tre ne produce cinque.

L'associazione di una pianificazione a un trigger della CPU è una combinazione comune: nella pianificazione viene riportato il numero di repliche previsto durante le ore di punta e il trigger della CPU rimane disponibile per il resto del tempo.

## Osservare la scalabilità dell'ambiente
<a name="configuring-cluster-scaling-watching"></a>

La pagina di monitoraggio dell'ambiente nella console Elastic Beanstalk mostra un ** grafico del conteggio delle repliche delle ** applicazioni, che riporta le repliche eseguite nell'ambiente nel tempo. Il confronto con i ** grafici della ** CPU (core) ** e ** della memoria (byte) mostra se un trigger mantiene il suo obiettivo. Per lo stato e le metriche riportate da un ambiente Beanstalk Cluster, vedere. [Monitoraggio degli ambienti Beanstalk Cluster](monitoring-cluster-environments.md)

Elastic Beanstalk registra un evento ambientale quando modifica un'impostazione di ridimensionamento, quindi il flusso di eventi dell'ambiente mostra quando una modifica di ridimensionamento ha avuto effetto.