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à.
# Multi-tenancy per ambienti Beanstalk Cluster
Gli ambienti Beanstalk Cluster che utilizzano le stesse sottoreti vengono eseguiti sullo stesso cluster Amazon EKS, quindi condividono l'infrastruttura di elaborazione. Elastic Beanstalk li separa su quel cluster condiviso: l'applicazione di ogni ambiente viene eseguita nella propria partizione del cluster ed Elastic Beanstalk blocca il traffico di rete tra gli ambienti per impostazione predefinita. Questo argomento descrive la separazione che si ottiene, come ampliarla o restringerla e quali requisiti un cluster condiviso non può soddisfare.
L'isolamento tra gli ambienti Beanstalk Cluster ha due dimensioni indipendenti. L'isolamento della rete controlla quali ambienti possono inviare traffico all'applicazione di un ambiente. L'isolamento di calcolo controlla se le repliche delle applicazioni di un ambiente condividono i nodi con altri ambienti. È possibile configurare l'una senza l'altra.
## Scelta di un limite di isolamento
Decidi quanto deve essere forte il confine di un ambiente prima di crearlo, perché la scelta viene effettuata tramite le sottoreti che assegni e non puoi modificare le sottoreti di un ambiente esistente. Sono disponibili due limiti che corrispondono ai due modelli multi-tenancy documentati da Amazon EKS.
| Limite | Come ottenerlo | Cosa separa |
| --- | --- | --- |
| Cluster condiviso (soft multi-tenancy) | Crea gli ambienti con lo stesso set di sottoreti. Questa è l'impostazione predefinita quando gli ambienti condividono una configurazione VPC. | L'applicazione di ogni ambiente viene eseguita nella propria partizione del cluster con il traffico di rete tra gli ambienti bloccato per impostazione predefinita. Gli ambienti condividono il cluster stesso e condividono i nodi a meno che non si configurino nodi dedicati. |
| Cluster separati (hard multi-tenancy) | Crea ambienti con diversi set di sottoreti. Elastic Beanstalk crea quindi un cluster separato per ogni set. | Niente è condiviso. I cluster separati hanno piani di controllo separati, nodi separati e nessun percorso di rete tra le applicazioni in esecuzione su di essi. |
Un cluster condiviso fornisce una separazione logica tra gli ambienti, imposta dalla configurazione che Elastic Beanstalk applica al cluster. Un cluster separato fornisce la separazione dell'infrastruttura. Amazon EKS documenta il cluster come il costrutto che fornisce un solido limite di sicurezza, perché un carico di lavoro che ha ottenuto l'accesso a un nodo potrebbe raggiungere le credenziali e i dati di qualsiasi altra cosa in esecuzione su quel nodo. La separazione logica all'interno di un cluster è soft multi-tenancy; un cluster per ogni tenant è una soluzione multi-tenancy rigida. Per una guida generale, consulta la sezione [ Tenant isolation ](https://docs.aws.amazon.com/eks/latest/best-practices/tenant-isolation.html) nella Amazon EKS Best Practices Guide. * *
**Importante**
Utilizza set di subnet separati, e quindi cluster separati, quando gli ambienti eseguono carichi di lavoro che non devono condividere l'infrastruttura. Gli esempi includono ambienti che appartengono a diversi clienti finali dell'azienda, ambienti che eseguono codice non controllato e ambienti che rientrano nell'ambito di un regime di conformità che richiede la separazione dell'infrastruttura. I controlli descritti nel resto di questo argomento separano gli ambienti su un cluster condiviso, ma non rendono un cluster condiviso equivalente a cluster separati.
I cluster separati costano di più e utilizzano la capacità in modo meno efficiente, poiché ogni cluster viene fatturato separatamente e i nodi non possono essere condivisi tra i cluster. Un cluster condiviso è la scelta giusta per gli ambienti gestiti da un team e gestiti congiuntamente, come i servizi che costituiscono una singola applicazione. Separare la produzione dallo sviluppo è un motivo comune per utilizzare set di sottoreti diversi anche quando nulla lo richiede. Per sapere come Elastic Beanstalk raggruppa gli ambienti in cluster, consulta. [Raggruppamento degli ambienti](beanstalk-cluster-concepts.md#beanstalk-cluster-clusters-sharing) Per le impostazioni stesse della sottorete, vedere. [Configurazione della rete per ambienti Beanstalk Cluster](configuring-cluster-networking.md)
## Isolamento della rete su un cluster condiviso
Per impostazione predefinita, Elastic Beanstalk blocca il traffico di rete tra gli ambienti Beanstalk Cluster su un cluster condiviso. Non è richiesta alcuna configurazione per ottenere questo risultato e non esiste alcuna opzione che lo disattivi. Le repliche delle applicazioni di un ambiente non possono ricevere traffico dalle copie delle applicazioni di un altro ambiente su nessuna porta a meno che non lo si autorizzi con una delle opzioni in questa sezione.
Elastic Beanstalk consente ai propri componenti operativi di raggiungere l'applicazione, in modo che i report sullo stato di salute, la raccolta dei log e il ridimensionamento basato su metriche continuino a funzionare.
Il traffico che raggiunge un ambiente tramite il relativo sistema di bilanciamento del carico non viene influenzato. Il blocco si applica al traffico inviato dalle repliche delle applicazioni di un ambiente direttamente a quelle di un altro, non al traffico che arriva dall'esterno del cluster. Le richieste che raggiungono l'applicazione tramite il relativo Application Load Balancer vengono consegnate normalmente, incluse le richieste che un altro ambiente invia all'endpoint pubblico di tale sistema di bilanciamento del carico.
### Consentire agli ambienti di comunicare
Tre opzioni nel `aws:elasticbeanstalk:eks:environment` namespace consentono il traffico tra ambienti su un cluster condiviso. Ciascuna richiede un elenco separato da virgole. I nomi sono limitati ai caratteri`a-z`, `A-Z``0-9`, e`-`; devono iniziare con una lettera e contenere da 4 a 40 caratteri. La modifica di uno di essi non interrompe l'ambiente.
| Opzione | Effetto | Usalo quando |
| --- | --- | --- |
| ingress-groups | Unisce l'ambiente a uno o più gruppi denominati. Ogni ambiente di un gruppo può inviare traffico a tutti gli altri ambienti di quel gruppo, in entrambe le direzioni. Un ambiente può appartenere a più di un gruppo. | Un insieme di ambienti deve richiamarsi l'un l'altro, ad esempio i servizi di un'applicazione. |
| ingress-allowlist-environments | Consente agli ambienti denominati di inviare traffico a questo ambiente. L'autorizzazione è unidirezionale: assegnare un nome a un ambiente qui non consente a quest'ambiente di chiamarlo. | Un ambiente serve un'API interna chiamata da altri ambienti specifici. |
| ingress-allowlist-groups | Consente a tutti gli ambienti dei gruppi indicati di inviare traffico a questo ambiente, in una sola direzione, senza unirsi a tali gruppi. | Un ambiente serve un gruppo di chiamanti che già condividono un gruppo e non devono in cambio accedervi. |
Impostato `ingress-groups` su ogni ambiente che si unisce al gruppo; l'appartenenza al gruppo non viene configurata da un'unica posizione. Un ambiente lascia un gruppo quando si rimuove il gruppo dal suo `ingress-groups` valore o si chiude l'ambiente. Imposta le opzioni della lista consentita sull'ambiente che * riceve * il traffico, nominando i chiamanti che desideri autorizzare.
I due meccanismi si combinano. Un ambiente può entrare a far parte di un gruppo per i servizi con cui collabora come peer e inserire separatamente un chiamante che deve raggiungerlo in una sola direzione. Per informazioni su come impostare le opzioni di configurazione in un ambiente, vedere. [Opzioni di configurazione](command-options.md)
L'autorizzazione del traffico non configura il rilevamento. L'applicazione deve comunque sapere quale indirizzo chiamare, che voi fornite nello stesso modo in cui fornite qualsiasi altra impostazione, tramite una proprietà di ambiente. Elastic Beanstalk non inserisce gli indirizzi degli ambienti consentiti.
## Nodi dedicati per un ambiente
Per impostazione predefinita, Elastic Beanstalk pianifica le repliche delle applicazioni da qualsiasi ambiente sulla capacità del nodo condiviso del cluster, in modo che le copie provenienti da ambienti diversi possano essere eseguite sullo stesso nodo. Per mantenere le repliche delle applicazioni di un ambiente su nodi che nessun altro ambiente utilizza, imposta l'`node-pool`opzione nel `aws:elasticbeanstalk:eks:environment` namespace con un nome a tua scelta.
Elastic Beanstalk riserva quindi un set di nodi con quel nome e pianifica solo le repliche delle applicazioni da ambienti con lo stesso valore su di essi. `node-pool` Gli ambienti che non impostano alcun valore o un valore diverso non possono essere collocati su tali nodi.
**Importante**
Gli ambienti che condividono un `node-pool` valore condividono i nodi tra loro. Per assegnare a un singolo ambiente nodi che nient'altro utilizza, assegnagli un valore che nessun altro ambiente utilizza.
La modifica `node-pool` riavvia le repliche delle applicazioni dell'ambiente in modo che Elastic Beanstalk possa riprogrammarle sui nodi corretti. I nodi dedicati riducono inoltre l'effetto dell'uso delle risorse di un ambiente su un altro, poiché gli ambienti non competono più per la CPU e la memoria dello stesso nodo. I nodi dedicati sono indipendenti dall'isolamento della rete: gli ambienti possono essere eseguiti su nodi separati e avere comunque la possibilità di comunicare, oppure condividere nodi ed essere bloccati dalla comunicazione.
`node-pool`Riservati a un requisito che riguarda specificamente la capacità dei nodi. Se il tuo obiettivo è separare gli ambienti l'uno dall'altro, assegnare loro sottoreti diverse è più semplice e separa sia il cluster che i nodi.
## Cosa non separa un cluster condiviso
Comprendi questi limiti prima di collocare ambienti con requisiti di sicurezza o conformità diversi sullo stesso cluster. Ciascuno di essi è una conseguenza degli ambienti che condividono un cluster e ciascuno viene rimosso assegnando agli ambienti sottoreti diverse in modo che Elastic Beanstalk crei cluster separati.
+ **Il traffico in uscita non è limitato. ** La separazione predefinita blocca il traffico in arrivo in un ambiente. Non limita i punti in cui l'applicazione di un ambiente può inviare traffico. Un'applicazione può raggiungere qualsiasi destinazione consentita dalla sua configurazione di rete e dalle sue autorizzazioni IAM, inclusi Internet e altri AWS servizi. Non esiste alcuna opzione che limiti il traffico in uscita da un ambiente Beanstalk Cluster.
+ **Il piano di controllo del cluster è condiviso. ** Ogni ambiente del cluster è servito da un piano di controllo Amazon EKS e la sua versione Kubernetes è fissa per tutta la durata del cluster. Elastic Beanstalk gestisce il piano di controllo e non è configurabile, ma non è duplicato per ambiente.
+ **I nodi sono condivisi a meno che non si configurino nodi dedicati. ** In `node-pool` caso contrario, le repliche delle applicazioni provenienti da ambienti diversi vengono eseguite sugli stessi nodi e utilizzano la stessa CPU e memoria. Elastic Beanstalk non riserva la capacità dei nodi per ambiente.
+ **Cluster-wide i guasti influiscono su tutti gli ambienti del cluster. ** Se Elastic Beanstalk interrompe la gestione di un cluster perché la sua infrastruttura non corrisponde più alla configurazione prevista, gli aggiornamenti falliscono per ogni ambiente di quel cluster fino a quando la deriva non viene risolta. Il ripristino avviene per cluster anziché per ambiente: ripristina la modifica che l'ha provocata ed Elastic Beanstalk riprenderà a gestire il cluster e tutti i suoi ambienti. Consulta [Deriva della configurazione del cluster](beanstalk-cluster-concepts.md#beanstalk-cluster-clusters-drift).
Application-level le protezioni sono di tua responsabilità in entrambi i confini. La separazione della rete tra gli ambienti non autentica i chiamanti, crittografa il traffico tra gli ambienti o limita le operazioni eseguite da un'applicazione con le credenziali in suo possesso. Assegna a ciascun ambiente il proprio ruolo di applicazione in modo che AWS le relative autorizzazioni siano limitate ad esso e considera il traffico consentito tra gli ambienti come traffico che l'applicazione deve ancora autorizzare. Consulta [Autorizzazioni dell'applicazione](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-application).
## Abbinamento di un requisito a un controllo
| Requisito | Controllo |
| --- | --- |
| Gli ambienti non devono condividere l'infrastruttura | Creali con diversi set di sottoreti, in modo che Elastic Beanstalk crei un cluster separato per ciascuna. Decidi questo prima di creare gli ambienti; non puoi modificare le sottoreti in seguito. |
| Gli ambienti non devono raggiungersi tramite la rete | Nessuna configurazione. Questa è l'impostazione predefinita in un cluster condiviso. |
| Un insieme di ambienti deve chiamarsi l'un l'altro | ingress-groupsImpostato sullo stesso nome di gruppo per ciascuno di essi. |
| Un ambiente deve accettare chiamate da altri specifici, ma non viceversa | Imposta ingress-allowlist-environmentsingress-allowlist-groups, o, sull'ambiente che riceve il traffico. |
| Le repliche delle applicazioni di un ambiente non devono condividere i nodi con altri ambienti | node-poolImpostato su un valore che nessun altro ambiente utilizza. |
| Il traffico in uscita di un ambiente deve essere limitato | Non disponibile tramite un'opzione di configurazione. Limitalo nell'applicazione o tramite la configurazione di rete delle sottoreti assegnate all'ambiente. |