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à.
# Piano dati EKS
Per utilizzare applicazioni ad alta disponibilità e resilienza, è necessario un piano dati ad alta disponibilità e resilienza. Un piano dati elastico garantisce che Kubernetes possa scalare e correggere automaticamente le tue applicazioni. Un piano dati resiliente è costituito da due o più nodi di lavoro, può crescere e ridursi con il carico di lavoro e ripristinarsi automaticamente in caso di guasti.
[Hai diverse scelte per i nodi di lavoro con EKS: [nodi gestiti in modalità automatica EKS](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), [istanze EC2 e Fargate](https://docs.aws.amazon.com/eks/latest/userguide/worker.html).](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)
EKS Auto Mode offre il percorso più semplice verso un piano dati resiliente. Auto Mode estende la gestione AWS dei cluster Kubernetes oltre il cluster stesso, per consentire ad AWS di configurare e gestire anche l'infrastruttura che consente il funzionamento regolare dei carichi di lavoro. La modalità automatica ridimensiona automaticamente il piano dati verso l'alto o verso il basso man mano che Kubernetes ridimensiona i pod e lavora per garantire continuamente che i nodi del cluster siano dimensionati in modo appropriato ed economico per i carichi di lavoro attualmente in esecuzione.
[Se scegli le istanze EC2, puoi gestire tu stesso i nodi di lavoro o utilizzare i gruppi di nodi gestiti da EKS.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) Puoi avere un cluster con una combinazione di modalità automatica, nodi di lavoro gestiti e autogestiti e Fargate.
Fargate esegue ogni Pod in un ambiente di elaborazione isolato. Ogni Pod in esecuzione su Fargate ha il proprio nodo di lavoro. Fargate ridimensiona automaticamente il piano dati come Kubernetes ridimensiona i pod. [È possibile scalare sia il piano dati che il carico di lavoro utilizzando l'autoscaler a pod orizzontale.](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)
[Il modo preferito per scalare i nodi di lavoro EC2 (se non si utilizza la modalità automatica EKS, che viene eseguita automaticamente da AWS) è utilizzare i gruppi [Karpenter](https://karpenter.sh/), [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) o EC2 Auto Scaling.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)
## Raccomandazioni
### Distribuisci i nodi di lavoro e i carichi di lavoro su più AZs
Puoi proteggere i tuoi carichi di lavoro dai guasti in una singola AZ eseguendo nodi di lavoro e Pods in più aree. AZs È possibile controllare l'AZ in cui vengono creati i nodi di lavoro utilizzando le sottoreti in cui vengono creati i nodi.
Il metodo consigliato per distribuire i pod AZs consiste nell'utilizzare [Topology Spread](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#spread-constraints-for-pods) Constraints for Pods. Le funzionalità di scalabilità automatica come EKS Auto Mode e Karpenter sono consapevoli dei vincoli di diffusione della topologia e avvieranno automaticamente i nodi nella posizione corretta per consentire il rispetto dei vincoli imposti. AZs
La distribuzione riportata di seguito distribuisce i pod, se possibile, lasciando che funzionino comunque in caso contrario AZs :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 3
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
topologySpreadConstraints:
- maxSkew: 1
whenUnsatisfiable: ScheduleAnyway
topologyKey: topology.kubernetes.io/zone
labelSelector:
matchLabels:
app: web-server
containers:
- name: web-app
image: nginx
resources:
requests:
cpu: 1
```
**Nota**
`kube-scheduler`è a conoscenza dei domini di topologia solo tramite nodi che esistono con tali etichette. Se la distribuzione di cui sopra viene distribuita in un cluster con nodi in una sola zona, tutti i pod verranno programmati su quei nodi poiché `kube-scheduler` non sono a conoscenza delle altre zone. Affinché questa distribuzione della topologia funzioni come previsto con lo scheduler, i nodi devono già esistere in tutte le zone. La `minDomains` proprietà dei vincoli di diffusione della topologia viene utilizzata per comunicare allo scheduler il numero di domini idonei, anche se è in esecuzione un nodo per evitare questo problema.
**avvertimento**
L'impostazione `whenUnsatisfiable` su `DoNotSchedule` farà sì che i pod non siano programmabili se il vincolo di diffusione della topologia non può essere soddisfatto. Dovrebbe essere impostato solo se è preferibile che i pod non vengano eseguiti invece di violare il vincolo di diffusione della topologia.
Nelle versioni precedenti di Kubernetes, puoi utilizzare le regole di antiaffinità dei pod per pianificare i pod su più pod. AZs *Il manifesto riportato di seguito indica allo scheduler di Kubernetes di preferire la pianificazione dei pod in modo distinto.* AZs
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
labels:
app: web-server
spec:
replicas: 4
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-server
topologyKey: failure-domain.beta.kubernetes.io/zone
weight: 100
containers:
- name: web-app
image: nginx
```
**avvertimento**
Non è necessario che i pod siano pianificati in AZs modo distinto, altrimenti il numero di pod in una distribuzione non supererà mai il numero di. AZs
### Garantisci la possibilità di avviare nodi in ogni AZ quando usi i volumi EBS
Se utilizzi Amazon EBS per fornire volumi persistenti, devi assicurarti che i pod e il volume EBS associato si trovino nella stessa zona di disponibilità. Un pod non può accedere ai volumi persistenti supportati da EBS che si trovano in una AZ diversa. Lo [scheduler Kubernetes sa in quale AZ si trova un nodo](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) di lavoro dalle etichette che si trovano sul nodo e pianificherà sempre un Pod che richiede un volume EBS nella stessa AZ del volume. Tuttavia, se non ci sono nodi di lavoro disponibili nell'AZ in cui si trova il volume, il Pod non può essere pianificato.
Se utilizzi EKS Auto Mode o Karpenter, dovrai assicurarti di NodeClass selezionare le sottoreti in ogni AZ. Se si utilizzano i gruppi di nodi gestiti, è necessario assicurarsi di disporre di un gruppo di nodi in ogni AZ.
Una funzionalità di storage EBS è integrata in EKS Auto Mode, ma se si utilizza Karpenter o Managed Node Groups, sarà necessario installare anche [EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html).
### Usa EKS Auto Mode per gestire i nodi di lavoro
EKS Auto Mode semplifica la gestione EKS fornendo cluster pronti per la produzione con un sovraccarico operativo minimo. La modalità automatica è responsabile dell'aumento o della riduzione del numero di nodi a seconda dei pod in esecuzione nel cluster. I nodi vengono aggiornati automaticamente con patch e correzioni software, e gli aggiornamenti vengono eseguiti in base alle impostazioni di [NodePool](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption)interruzione configurate e ai Pod Disruption Budgets.
### Esegui il Node Monitoring Agent
Il [Node Monitoring Agent](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html) monitora e reagisce ai problemi di integrità dei nodi pubblicando gli eventi Kubernetes e aggiornando le condizioni di stato sui nodi. Il Node Monitoring Agent è incluso nei nodi EKS Auto Mode e può essere installato come componente aggiuntivo EKS per i nodi che non sono gestiti da Auto Mode.
EKS Auto Mode, Managed Node Groups e Karpenter hanno tutti la capacità di rilevare le condizioni fatali dei nodi segnalate dall'agente di monitoraggio dei nodi e di ripararli automaticamente quando si verificano tali condizioni.
### Implementazione del QoS
Per le applicazioni critiche, prendi in considerazione la definizione di `requests` = `limits` per il contenitore nel Pod. Ciò garantirà che il contenitore non venga ucciso se un altro Pod richiede risorse.
È consigliabile implementare limiti di CPU e memoria per tutti i contenitori in quanto impedisce che un contenitore consumi inavvertitamente risorse di sistema influendo sulla disponibilità di altri processi co-localizzati.
### Configura e dimensiona le risorse per tutti i carichi di lavoro Requests/Limits
Alcune indicazioni generali possono essere applicate al dimensionamento delle richieste di risorse e ai limiti per i carichi di lavoro:
+ Non specificare limiti di risorse sulla CPU. In assenza di limiti, la richiesta influisce sulla [quantità di tempo relativo alla CPU utilizzata dai container](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run). Ciò consente ai carichi di lavoro di utilizzare l'intera CPU senza limiti artificiali o carenze.
+ Per le risorse diverse dalla CPU, configuring `requests` = `limits` fornisce il comportamento più prevedibile. Se\$1 `requests` [=`limits`, inoltre, il [QOS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes) del container è stato ridotto da Guaranteed a Burstable, il che rende più probabile lo sfratto in caso di pressione dei nodi.](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+ Per le risorse diverse dalla CPU, non specificare un limite molto più grande della richiesta. Quanto più grandi `limits` sono le dimensioni configurate rispetto a`requests`, tanto più è probabile che i nodi vengano sovraccaricati, con conseguenti alte probabilità di interruzione del carico di lavoro.
+ [Le richieste di dimensioni corrette sono particolarmente importanti quando si utilizza una soluzione di auto-scaling dei nodi [come](https://aws.github.io/aws-eks-best-practices/karpenter/) Karpenter o Cluster. AutoScaler](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/) Questi strumenti esaminano le richieste di carico di lavoro per determinare il numero e la dimensione dei nodi da fornire. Se le tue richieste sono troppo piccole e con limiti più elevati, potresti scoprire che i carichi di lavoro vengono eliminati o l'OOM bloccato se sono stati raggruppati in un nodo ristretto.
Determinare le richieste di risorse può essere difficile, ma strumenti come [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) possono aiutarvi a «dimensionare correttamente» le richieste osservando l'utilizzo delle risorse del contenitore in fase di esecuzione. Altri strumenti che possono essere utili per determinare le dimensioni delle richieste includono:
+ [Riccioli d'oro](https://github.com/FairwindsOps/goldilocks)
+ [Parca](https://www.parca.dev/)
+ [Profiler](https://prodfiler.com/)
+ [rg](https://mhausenblas.info/right-size-guide/)
### Configura le quote di risorse per i namespace
I namespace sono concepiti per l'uso negli ambienti con molti utenti distribuiti su più team o progetti. Forniscono un ambito per i nomi e sono un modo per dividere le risorse del cluster tra più team, progetti e carichi di lavoro. È possibile limitare il consumo aggregato di risorse in un namespace. L'[https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/)oggetto può limitare la quantità di oggetti che possono essere creati in un namespace per tipo, nonché la quantità totale di risorse di elaborazione che possono essere consumate dalle risorse di quel progetto. È possibile limitare la somma totale di risorse di archiviazione and/or (CPU e memoria) che possono essere richieste in un determinato spazio dei nomi.
Se la quota di risorse è abilitata per uno spazio dei nomi per risorse di calcolo come CPU e memoria, gli utenti devono specificare le richieste o i limiti per ogni contenitore in tale spazio dei nomi.
Prendi in considerazione la possibilità di configurare le quote per ogni namespace. Prendi in considerazione l'utilizzo `LimitRanges` per applicare automaticamente limiti preconfigurati ai contenitori all'interno di un namespace.
### Limita l'utilizzo delle risorse del contenitore all'interno di un namespace
Le quote di risorse aiutano a limitare la quantità di risorse che un namespace può utilizzare. L'[`LimitRange`oggetto](https://kubernetes.io/docs/concepts/policy/limit-range/) può aiutarti a implementare le risorse minime e massime richieste da un contenitore. Utilizzando `LimitRange` you puoi impostare una richiesta e dei limiti predefiniti per i contenitori, il che è utile se l'impostazione dei limiti delle risorse di elaborazione non è una pratica standard nell'organizzazione. Come suggerisce il nome, `LimitRange` può imporre l'utilizzo minimo e massimo delle risorse di calcolo per Pod o Container in un namespace. Inoltre, applica la richiesta di archiviazione minima e massima per in un namespace. PersistentVolumeClaim
Valuta la possibilità di `ResourceQuota` utilizzarlo insieme `LimitRange` a per imporre limiti a livello di contenitore e namespace. L'impostazione di questi limiti garantirà che un contenitore o un namespace non influiscano sulle risorse utilizzate dagli altri tenant del cluster.
### Usa NodeLocal DNSCache
È possibile migliorare le prestazioni del Cluster DNS [NodeLocalDNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)eseguendo. Questa funzionalità esegue un agente di caching DNS sui nodi del cluster come. DaemonSet Tutti i pod utilizzano l'agente di caching DNS in esecuzione sul nodo per la risoluzione dei nomi anziché utilizzare Service. `kube-dns` Questa funzionalità è inclusa automaticamente in EKS Auto Mode.
### Configurare CoredNS con scalabilità automatica
Un altro metodo per migliorare le prestazioni del Cluster DNS consiste nell'abilitare l'[auto-scaling](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html) integrato dei CoredNS Pods.
Questa funzionalità monitora continuamente lo stato del cluster, incluso il numero di nodi e core della CPU. Sulla base di tali informazioni, il controller adatterà dinamicamente il numero di repliche dell’implementazione CoreDNS in un cluster EKS.