**Contribuisci a migliorare questa pagina** 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à. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. 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à. # Semplifica la gestione dell’elaborazione con AWS Fargate In questo argomento viene illustrato l’utilizzo di Amazon EKS per eseguire i pod Kubernetes su AWS Fargate. Fargate è una tecnologia che fornisce capacità di calcolo on demand e di dimensioni adeguate per i [container](https://aws.amazon.com/what-are-containers). Con Fargate, non devi effettuare personalmente il provisioning, la configurazione o il dimensionamento dei gruppi di macchine virtuali per eseguire i container. Non devi inoltre scegliere i tipi di server, decidere quando dimensionare i gruppi di nodi oppure ottimizzare l’impacchettamento dei cluster. Puoi controllare quali pod sono avviati su Fargate e come vengono eseguiti con [profili Fargate](fargate-profile.md). I profili Fargate sono definiti come parte del cluster Amazon EKS. Amazon EKS integra Kubernetes con Fargate tramite l’utilizzo di controller creati da AWS utilizzando il modello upstream ed estensibile fornito da Kubernetes. Questi controller vengono eseguiti come parte del piano di controllo di Kubernetes gestito da Amazon EKS e sono responsabili della pianificazione dei pod Kubernetes nativo su Fargate. I controller Fargate includono un nuovo pianificazione che viene eseguito insieme al pianificatore di default di Kubernetes, oltre a diversi controller di ammissione mutanti e convalidanti. Quando avvii un pod che soddisfa i criteri per l’esecuzione su Fargate, i controller Fargate in esecuzione nel cluster riconoscono, aggiornano e pianificano il pod su Fargate. Questo argomento descrive i diversi componenti di pod in esecuzione su Fargate, e illustra considerazioni speciali per l’utilizzo di Fargate con Amazon EKS. ## Considerazioni su AWS Fargate Di seguito sono elencati alcuni punti da considerare sull’uso di Fargate in Amazon EKS. + Ogni pod in esecuzione su Fargate ha un proprio limite di calcolo. Non condividono il kernel sottostante, le risorse CPU, le risorse di memoria o l’interfaccia di rete elastica con un altro pod. + I Network Load Balancer e gli Application Load Balancer (ALB) possono essere utilizzati solo con Fargate con destinazioni IP. Per ulteriori informazioni, consulta [Creazione di un Network Load Balancer](network-load-balancing.md#network-load-balancer) e [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md). + I servizi esposti Fargate vengono eseguiti solo in modalità IP di tipo destinazione e non in modalità IP del nodo. Il modo consigliato per verificare la connettività da un servizio in esecuzione su un nodo gestito e da un servizio in esecuzione su Fargate è quello di connettersi tramite il nome del servizio. + Nel momento in cui sono programmati per l’esecuzione su Fargate, i pod devono corrispondere a un profilo Fargate. I pod che non corrispondono a un profilo Fargate potrebbero rimanere bloccati nello stato `Pending`. Se esiste un profilo Fargate corrispondente, puoi eliminare i pod in sospeso creati per riprogrammarli su Fargate. + I Daemonset non sono supportati su Fargate. Se l’applicazione richiede un daemon, riconfigura quel daemon per essere eseguito nei pod come container sidecar. + I container privilegiati non sono supportati su Fargate. + I pod in esecuzione su Fargate non possono specificare `HostPort` o `HostNetwork` nel manifesto del pod. + Per i pod Fargate, il valore di default per il limite soft `nofile` e `nproc` è 1.024, mentre per il limite hard è 65.535. + Le GPU non sono attualmente disponibili su Fargate. + I pod in esecuzione su Fargate sono supportati solo su sottoreti private (con un accesso NAT gateway ai servizi AWS, ma senza routing diretto a un Gateway Internet), pertanto il VPC del cluster deve disporre di sottoreti private disponibili. Per i cluster senza accesso Internet in uscita, consulta [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md). + Puoi utilizzare [Adjust pod resources with Vertical Pod Autoscaler](vertical-pod-autoscaler.md) per impostare la dimensione corretta iniziale della CPU e la memoria per i Pod Fargate, quindi utilizza [Scale pod deployments with Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) per scalare quei Pod. Se desideri che il Vertical Pod Autoscaler ridistribuisca automaticamente i pod su Fargate con combinazioni di CPU e memoria più grandi, imposta la modalità per il Vertical Pod Autoscaler su `Auto` o `Recreate` r per garantire la corretta funzionalità. Per ulteriori informazioni, consulta la documentazione [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) su GitHub. + La risoluzione DNS e i nomi host DNS devono essere abilitati per il VPC. Per ulteriori informazioni, consulta [Visualizzazione e aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating). + Amazon EKS Fargate aggiunge una difesa approfondita per le applicazioni Kubernetes isolando ogni pod all’interno di una macchina virtuale (VM). Questo limite VM impedisce l’accesso alle risorse basate su host utilizzate da altri pod in caso di evasione da un container, un metodo comune per attaccare le applicazioni containerizzate e ottenere l’accesso a risorse esterne al container. L’utilizzo di Amazon EKS non modifica le tue responsabilità ai sensi del [modello di responsabilità condivisa](security.md). È necessario considerare attentamente la configurazione dei controlli di sicurezza e gestione del cluster. Il modo più sicuro per isolare un’applicazione è sempre quello di eseguirla in un cluster separato. + I profili Fargate supportano la specificazione di sottoreti da blocchi CIDR secondari del VPC. È possibile specificare un blocco CIDR secondario. Ciò è necessario perché in una sottorete è disponibile un numero limitato di indirizzi IP. Di conseguenza, nel cluster puoi creare un numero limitato di pod. L’uso di sottoreti diverse per i pod ti consente di aumentare il numero di indirizzi IP disponibili. Per ulteriori informazioni, consulta [Aggiunta di blocchi CIDR IPv4 a un VPC.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize) + Il servizio di metadati di istanza (IMDS) Amazon EC2 non è disponibile per i pod distribuiti ai nodi Fargate. Se disponi di pod distribuiti in Fargate che necessitano di credenziali IAM, assegnali ai pod utilizzando i [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md). Se i pod hanno bisogno di accedere ad altre informazioni disponibili tramite IMDS, devi eseguire la codifica fissa di queste informazioni nelle specifiche del pod. Ciò include la Regione AWS o la zona di disponibilità in cui viene implementato un pod. + Non puoi implementare i pod Fargate in AWS Outposts, AWS Wavelength o AWS nelle zone locali. + Periodicamente, Amazon EKS deve applicare patch ai Pod Fargate per garantire che siano sicuri. Gli aggiornamenti vengono effettuati in modo da avere il minor impatto possibile. Tuttavia, se i pod non vengono espulsi con successo, a volte è necessario eliminarli. Di seguito sono riportate le azioni che è possibile intraprendere per ridurre al minimo le interruzioni. Per ulteriori informazioni, consulta [Imposta azioni per gli eventi relativi all’applicazione di patch del sistema operativo AWS Fargate](fargate-pod-patching.md). + Il [plug-in CNI di Amazon VPC per Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) è installato sui nodi Fargate. Non puoi utilizzare [Alternate CNI plugins for Amazon EKS clusters](alternate-cni-plugins.md) con i nodi Fargate. + Un pod in esecuzione su Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver. Non puoi utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma puoi usare quello statico. + Amazon EKS non supporta Fargate Spot. + Non puoi montare volumi Amazon EBS sui pod Fargate. + Puoi eseguire il controller Amazon EBS CSI sui nodi Fargate, ma sul nodo Amazon EBS CSI DaemonSet può essere eseguito solo su istanze Amazon EC2. + Dopo che un [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) è stato contrassegnato `Completed` o `Failed`, i pod creati normalmente continuano a esistere. Questo comportamento ti consente di visualizzare i tuoi log e risultati, ma con Fargate dovrai sostenere dei costi se non ripulisci il processo in seguito. Per eliminare automaticamente i pod correlati dopo il completamento o un errore di un processo, puoi specificare un periodo di tempo utilizzando il controller time-to-live (TTL). L’esempio seguente mostra la specifica di `.spec.ttlSecondsAfterFinished` nel manifesto del processo. ``` apiVersion: batch/v1 kind: Job metadata: name: busybox spec: template: spec: containers: - name: busybox image: busybox command: ["/bin/sh", "-c", "sleep 10"] restartPolicy: Never ttlSecondsAfterFinished: 60 # <-- TTL controller ``` ## Tabella di confronto Fargate | Criteri | AWS Fargate | | --- | --- | | Si può implementare in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | No | | Si può implementare in una [Zona locale AWS](local-zones.md) | No | | Può eseguire container che richiedono Windows | No | | Può eseguire container che richiedono Linux | Sì | | Può eseguire carichi di lavoro che richiedono il chip Inferentia | No | | Può eseguire carichi di lavoro che richiedono una GPU | No | | Può eseguire carichi di lavoro che richiedono processori Arm | No | | Può eseguire AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | No | | I pod condividono un ambiente di runtime del kernel con altri pod | No: ogni pod ha un kernel dedicato | | I pod condividono risorse di CPU, memoria, archiviazione e rete con altri pod. | No: ogni pod dispone di risorse dedicate e può essere ridimensionato in modo indipendente per massimizzare l’utilizzo delle risorse. | | I pod possono utilizzare più hardware e memoria rispetto alle specifiche dei pod | No: il pod può essere comunque reimplementato utilizzando una vCPU e una configurazione di memoria più grandi. | | È necessario implementare e gestire le istanze Amazon EC2 | No | | È necessario proteggere, mantenere e applicare patch al sistema operativo delle istanze Amazon EC2 | No | | Può fornire argomenti di bootstrap all’implementazione di un nodo, come argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. | No | | Può assegnare indirizzi IP ai pod da un intervallo CIDR diverso rispetto all’indirizzo IP assegnato al nodo. | No | | Puoi eseguire SSH nel nodo | No: non esiste un sistema operativo host del nodo su cui eseguire il SSH. | | Puoi implementare un’AMI personalizzata nei nodi | No | | Può implementare una CNI personalizzata nei nodi | No | | É necessario aggiornare l’AMI del nodo per conto proprio | No | | È necessario aggiornare la versione del nodo Kubernetes per conto proprio | No: non sei tu a gestire i nodi. | | Può utilizzare lo spazio di archiviazione Amazon EBS con i pod | No | | Può utilizzare lo spazio di archiviazione di Amazon EFS con i pod | [Sì](efs-csi.md) | | Può utilizzare lo spazio di archiviazione Amazon FSx per Lustre con i pod | No | | Può utilizzare Network Load Balancer per i servizi | Sì, quando si utilizza [Create a network load balancer](network-load-balancing.md#network-load-balancer) | | I pod possono essere eseguiti in una sottorete pubblica | No | | Può assegnare diversi gruppi di sicurezza VPC a singoli pod | Sì | | Può eseguire Kubernetes DaemonSets | No | | Supporto `HostPort` e `HostNetwork` nel manifesto pod | No | | Disponibilità nelle regioni AWS | [Alcune regioni supportate da Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Può eseguire container su host dedicati Amazon EC2 | No | | Prezzi | Costo di una singola configurazione di memoria Fargate e CPU. Ogni pod ha il rispettivo costo. Per ulteriori informazioni, consulta [Prezzi di Fargate AWS](https://aws.amazon.com/fargate/pricing/). | # Inizia a usare AWS Fargate per il tuo cluster Questo argomento descrive come iniziare a eseguire Pods su AWS Fargate con il tuo cluster Amazon EKS. Se limiti l'accesso all'endpoint pubblico del cluster utilizzando blocchi CIDR, consigliamo di abilitare anche l'accesso agli endpoint privati. In questo modo i pod Fargate possono comunicare con il cluster. Senza l'endpoint privato abilitato, i blocchi CIDR specificati per l'accesso pubblico devono includere le origini di uscita dal VPC. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md). **Prerequisito** Un cluster esistente. Se si dispone già di un cluster Amazon EKS, consultare la pagina [Nozioni di base su Amazon EKS](getting-started.md). ## Fase 1: assicurarsi che i nodi esistenti possano comunicare con i pod Fargate Se si utilizza un nuovo cluster senza nodi o un cluster con solo gruppi di nodi gestiti (consultare [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)), è possibile passare a [Fase 2: creare un ruolo di esecuzione del pod Fargate](#fargate-sg-pod-execution-role). Supponiamo di lavorare con un cluster esistente che dispone già di nodi associati. Assicurarsi che i pod su questi nodi possano comunicare liberamente con i pod in esecuzione su Fargate. I pod in esecuzione su Fargate vengono configurati automaticamente per utilizzare il gruppo di sicurezza del cluster per il cluster a cui sono associati. È necessario assicurarsi che eventuali i nodi esistenti nel cluster possano inviare e ricevere traffico da e verso il gruppo di sicurezza del cluster. I gruppi di nodi gestiti vengono configurati automaticamente per utilizzare anche il gruppo di sicurezza del cluster, quindi non è necessario modificarli o verificare questa compatibilità (consultare [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)). Per i gruppi di nodi esistenti che sono stati creati con `eksctl` o i AWS CloudFormation modelli gestiti di Amazon EKS, puoi aggiungere manualmente il gruppo di sicurezza del cluster ai nodi. In alternativa, è possibile modificare il modello di avvio del gruppo Auto Scaling per il gruppo di nodi per collegare il gruppo di sicurezza cluster alle istanze. Per ulteriori informazioni, consultare [Changing an instance’s security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) nella *Guida per l’utente di Amazon VPC*. Puoi verificare la presenza di un gruppo di sicurezza per il Console di gestione AWS tuo cluster nella sezione **Rete** relativa al cluster. In alternativa, è possibile eseguire questa operazione utilizzando il seguente AWS comando CLI. Se utilizzi questo comando, sostituisci `` con il nome del cluster. ``` aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId ``` ## Fase 2: creare un ruolo di esecuzione del pod Fargate Quando il cluster crea Pod su AWS Fargate, i componenti che girano sull'infrastruttura Fargate devono effettuare chiamate AWS APIs per conto dell'utente. Il ruolo di esecuzione del pod Amazon EKS fornisce le autorizzazioni IAM per eseguire questa operazione. Per creare un ruolo di esecuzione di AWS Fargate Pod, vedere. [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md) **Nota** Se il cluster è stato creato con `eksctl` utilizzando l’opzione `--fargate`, dispone già di un ruolo di esecuzione del pod disponibile nella console IAM con il modello `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL`. Allo stesso modo, se si utilizza `eksctl` per creare i profili Fargate, `eksctl` crea il ruolo di esecuzione del pod se non ne esiste già uno. ## Fase 3: creare un profilo Fargate per il cluster Prima di poter pianificare i pod in esecuzione su Fargate nel cluster, sarà necessario definire un profilo Fargate che specifichi i pod che utilizzano Fargate al momento dell’avvio. Per ulteriori informazioni, consulta [Definisci quali pod utilizzano AWS Fargate durante l’avvio](fargate-profile.md). **Nota** Se il cluster è stato creato con `eksctl` utilizzando l’opzione `--fargate`, allora un profilo Fargate è già stato creato per il cluster con selettori per tutti i pod nei namespace `kube-system` e `default`. Utilizza la procedura seguente per creare profili Fargate per gli altri namespace con cui desideri utilizzare Fargate. È possibile creare un profilo Fargate utilizzando uno di questi due strumenti: + [`eksctl`](#eksctl_fargate_profile_create) + [Console di gestione AWS](#console_fargate_profile_create) ### `eksctl` Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente: ``` eksctl version ``` Per istruzioni sull'installazione o sull'aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`. **Per creare un profilo Fargate con `eksctl`** Crea il tuo profilo Fargate con il seguente comando `eksctl`, sostituendo ogni `` con i valori in tuo possesso. È necessario specificare un namespace. Tuttavia, l’opzione `--labels` non è obbligatoria. ``` eksctl create fargateprofile \ --cluster \ --name \ --namespace \ --labels ``` È possibile utilizzare determinati caratteri jolly per `` e etichette ``. Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards). ### Console di gestione AWS **Creazione di un profilo Fargate con Console di gestione AWS ** 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Scegli il cluster per cui creare un profilo Fargate. 1. Scegli la scheda **Calcolo**. 1. Nella sezione **Profili Fargate**, scegli **Aggiungi profilo Fargate**. 1. Nella pagina **Configura il profilo Fargate**, procedi come segue: 1. In **Nome**, inserisci un nome per il profilo Fargate. Il nome deve essere univoco. 1. Come **Ruolo di esecuzione pod**, scegliere il ruolo di esecuzione del pod da utilizzare con il profilo Fargate. Vengono visualizzati solo i ruoli IAM con il principale del servizio `eks-fargate-pods.amazonaws.com`. Se non vedi alcun ruolo nell’elenco, è necessario crearne uno. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). 1. Modifica le **sottoreti** selezionate in base alle esigenze. **Nota** Solo le sottoreti private sono supportate per i pod in esecuzione su Fargate. 1. In **Tag**, puoi facoltativamente aggiungere tag al tuo profilo Fargate. Questi tag non si propagano ad altre risorse associate al profilo come i pod. 1. Scegli **Next (Successivo)**. 1. Nella pagina **Configura selezione pod**, procedi come segue: 1. In **Namespace**, inserisci un namespace che corrisponda ai pod. + È possibile utilizzare namespace specifici da abbinare, ad esempio `kube-system` o `default`. + È possibile utilizzare determinati caratteri jolly (ad esempio, `prod-*`) per abbinare più namespace (ad esempio, `prod-deployment` e `prod-test`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards). 1. (Facoltativo) Aggiungere etichette Kubernetes al selettore. In particolare, aggiungerle al selettore con cui i pod nel namespace specificato devono corrispondere. + È possibile aggiungere l’etichetta `infrastructure: fargate` al selettore in modo che solo i pod nel namespace specificato che hanno anche l’etichetta Kubernetes `infrastructure: fargate` corrispondano al selettore. + È possibile utilizzare determinati caratteri jolly (ad esempio, `key?: value?`) per abbinare più namespace (ad esempio, `keya: valuea` e `keyb: valueb`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards). 1. Scegli **Next (Successivo)**. 1. Nella pagina **Rivedi e crea**, controlla le informazioni relative al profilo Fargate e scegli **Crea**. ## Fase 4: aggiornare CoreDNS Per impostazione predefinita, CoredNS è configurato per l'esecuzione sull' EC2 infrastruttura Amazon su cluster Amazon EKS. Se si desidera *solo* eseguire i pod su Fargate nel cluster, seguire la procedura riportata di seguito. **Nota** Se è stato creato il cluster `eksctl` utilizzando l'opzione `--fargate` è possibile passare a [Fasi successive](#fargate-gs-next-steps). 1. Creare un profilo Fargate per CoreDNS con il seguente comando. Sostituiscilo `` con il nome del cluster, `<111122223333>` con l'ID dell'account, `` con il nome del ruolo di esecuzione del Pod e `<000000000000000a>` `<000000000000000c>` con le sottoreti IDs private. `<000000000000000b>` Se non si dispone di un ruolo di esecuzione del pod, è necessario prima crearne uno (consultare [Fase 2: creare un ruolo di esecuzione del pod Fargate](#fargate-sg-pod-execution-role)). **Importante** L’ARN del ruolo non può includere un [percorso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) diverso da `/`. Ad esempio, se il nome del ruolo è `development/apps/AmazonEKSFargatePodExecutionRole`, è necessario modificarlo in `AmazonEKSFargatePodExecutionRole` quando si specifica l'ARN per tale ruolo. Il formato dell'ARN del ruolo deve essere ` arn:aws: iam::<111122223333>:role/`. ``` aws eks create-fargate-profile \ --fargate-profile-name coredns \ --cluster-name \ --pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \ --selectors namespace=kube-system,labels={k8s-app=kube-dns} \ --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c> ``` 1. Attivare un rollout dell’implementazione `coredns`. ``` kubectl rollout restart -n kube-system deployment coredns ``` ## Fasi successive + Puoi avviare la migrazione delle applicazioni esistenti per l'esecuzione su Fargate con il seguente flusso di lavoro. 1. [Creazione di un profilo Fargate](fargate-profile.md#create-fargate-profile) che corrisponda al namespace Kubernetes e alle etichette Kubernetes dell’applicazione. 1. Eliminare e creare nuovamente tutti i pod esistenti in modo che siano programmati su Fargate. Modificare `` e `` per aggiornare i pod specifici. ``` kubectl rollout restart -n deployment ``` + Implementare [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) per permettere l’esecuzione di oggetti Ingress per i pod in esecuzione su Fargate. + È possibile utilizzare [Regolazione delle risorse del pod con Vertical Pod Autoscaler](vertical-pod-autoscaler.md) per impostare la dimensione corretta iniziale della CPU e la memoria per i pod Fargate, quindi utilizzare il comando [Scalare le implementazioni dei pod con Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) per scalare tali pod. Se si desidera che il Vertical Pod Autoscaler implementi di nuovo automaticamente i pod su Fargate con combinazioni di CPU e memoria più grandi, impostare la modalità del Vertical Pod Autoscaler su `Auto` o `Recreate`. Ciò garantisce una corretta funzionalità. Per ulteriori informazioni, consulta la documentazione di [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) su GitHub. + Ora puoi impostare il collector [AWS Distro per OpenTelemetry](https://aws.amazon.com/otel) (ADOT) per il monitoraggio delle applicazioni seguendo [queste istruzioni](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html). # Definisci quali pod utilizzano AWS Fargate durante l’avvio Prima di programmare i pod su Fargate nel cluster, devi definire almeno un profilo Fargate che specifichi i pod utilizzati da Fargate al momento dell’avvio. Come amministratore, puoi utilizzare il profilo Fargate per dichiarare quali pod vengono eseguiti su Fargate. Puoi farlo attraverso i selettori del profilo. Puoi aggiungere fino a cinque selettori a ogni profilo. Ogni selettore deve contenere uno spazio dei nomi. Il selettore può includere anche etichette. Il campo etichetta è costituito da più coppie chiave-valore facoltative. I pod che corrispondono ai selettori sono programmati su Fargate. I pod vengono abbinati utilizzando uno spazio dei nomi e le etichette specificate nel selettore. Se un selettore di namespace è definito senza etichette, Amazon EKS tenterà di pianificare tutti i pod che vengono eseguiti in tale namespace su Fargate utilizzando il profilo. Se un pod da programmare corrisponde a uno dei selettori nel profilo Fargate, allora quel pod viene programmato su Fargate. Se un pod corrisponde a più profili Fargate, puoi specificare quale profilo viene utilizzato dal pod aggiungendo la seguente etichetta Kubernetes alla specifica del pod: `eks.amazonaws.com/fargate-profile: my-fargate-profile`. Il pod deve corrispondere a un selettore in quel profilo per essere pianificato su Fargate. Le regole di affinità/anti-affinità Kubernetes non si applicano e non sono necessarie con i pod Fargate di Amazon EKS. Quando crei un profilo Fargate, devi specificare il ruolo di esecuzione di un pod. Questo ruolo di esecuzione è per i componenti Amazon EKS che vengono eseguiti su infrastruttura Fargate utilizzando il profilo. Viene aggiunto al [controllo di accesso basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) del cluster di Kubernetes per l’autorizzazione. Ciò consente a `kubelet` in esecuzione sull’infrastruttura Fargate di registrarsi con il cluster Amazon EKS in modo che possa essere visualizzato nel cluster come nodo. Il ruolo di esecuzione del pod fornisce anche le autorizzazioni IAM per l’infrastruttura Fargate per consentire l’accesso in lettura ai repository di immagini di Amazon ECR. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). I profili Fargate non possono essere modificati. Tuttavia, è possibile creare un nuovo profilo aggiornato per sostituire un profilo esistente e quindi eliminare l’originale. **Nota** Qualsiasi pod in esecuzione utilizzando un profilo Fargate viene arrestato e messo in sospeso quando il profilo viene eliminato. Se tutti i profili in un cluster sono nello stato `DELETING`, è necessario attendere che tale profilo Fargate finisca l’eliminazione prima di poter creare altri profili in tale cluster. **Nota** Attualmente, Fargate non supporta [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) di Kubernetes. Amazon EKS e Fargate cercano di implementare i pod su ciascuna delle sottoreti definite nel profilo Fargate. Tuttavia, potresti ritrovarti con una diffusione irregolare. Se devi avere una diffusione uniforme, usa due profili Fargate. Anche la diffusione è importante in scenari in cui desideri implementare due repliche e non vuoi tempi di inattività. È consigliabile che ogni profilo abbia una sola sottorete. ## Componenti del profilo Fargate Un profilo Fargate contiene i componenti elencati di seguito. **Ruolo di esecuzione del pod** Quando il cluster crea pod su AWS Fargate, il `kubelet` in esecuzione sull’infrastruttura di Fargate deve effettuare chiamate ad API AWS per tuo conto. Ad esempio, deve effettuare chiamate per estrarre le immagini del container da Amazon ECR. Il ruolo di esecuzione del pod Amazon EKS fornisce le autorizzazioni IAM per eseguire questa operazione. Quando crei un profilo Fargate, devi specificare il ruolo di esecuzione di un pod da utilizzare col tuo pod. Questo ruolo viene aggiunto al [controllo di accesso basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) del cluster di Kubernetes per l’autorizzazione. Ciò consente a `kubelet` in esecuzione sull’infrastruttura Fargate di registrarsi con il cluster Amazon EKS in modo che possa essere visualizzato nel cluster come nodo. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). **Sottoreti** Gli ID delle sottoreti per avviare i pod che utilizzano questo profilo. A questo momento, ai pod in esecuzione su Fargate non vengono assegnati indirizzi IP pubblici. Di conseguenza, in virtù di questo parametro, sono accettate solo le sottoreti private senza routing diretto a un gateway Internet. **Selettori** I selettori da abbinare ai pod per utilizzare questo profilo Fargate. È possibile specificare fino a cinque selettori in un profilo Fargate. I selettori hanno le seguenti componenti: + **Spazio dei nomi**: specifica uno spazio dei nomi per un selettore. Il selettore corrisponde solo ai pod che vengono creati in questo namespace. Tuttavia, è possibile creare più selettori per rivolgersi a più spazi dei nomi. + **Etichette**: è possibile specificare facoltativamente le etichette Kubernetes che corrispondono al selettore. Il selettore corrisponde solo ai pod che hanno tutte le etichette specificate nel selettore. ## Wildcard del profilo di Fargate Oltre ai caratteri consentiti da Kubernetes, puoi utilizzare `*` e `?` nei criteri di selezione per namespace, chiavi di etichette e valori di etichette: + `*` rappresenta nessuno, uno o più caratteri. Ad esempio, `prod*` può rappresentare `prod` e `prod-metrics`. + `?` rappresenta un singolo carattere (ad esempio, `value?` può rappresentare `valuea`). Tuttavia, non può rappresentare `value` e `value-a`, perché `?` può rappresentare solo un carattere. Questi caratteri jolly possono essere usati in qualsiasi posizione e in combinazione (ad esempio, `prod*`, `*dev`, e `frontend*?`). Altri caratteri jolly e forme di corrispondenza del modello, come le espressioni regolari, non sono supportati. Se sono presenti più profili corrispondenti per il namespace e le etichette nelle specifiche del pod, Fargate seleziona il profilo in base all’ordinamento alfanumerico e al nome del profilo. Ad esempio, se entrambi i profili A (con il nome `beta-workload`) e il profilo B (con il nome `prod-workload`) hanno dei selettori corrispondenti per i pod da avviare, Fargate sceglie il profilo A (`beta-workload`) per i pod. I pod hanno etichette con il profilo A sui pod (ad esempio, `eks.amazonaws.com/fargate-profile=beta-workload`). Se desideri eseguire la migrazione dei pod Fargate esistenti su nuovi profili che utilizzano caratteri jolly, puoi farlo in due modi: + Crea un nuovo profilo con i selettori corrispondenti, quindi elimina i vecchi profili. I pod etichettati con vecchi profili vengono riprogrammati con nuovi profili corrispondenti. + Se desideri eseguire la migrazione dei carichi di lavoro ma non hai la certezza di quali siano le etichette Fargate su ogni pod Fargate, puoi utilizzare il seguente metodo. Crea un nuovo profilo con un nome che ordina in ordine alfanumerico per primo tra i profili dello stesso cluster. Quindi, ricicla i pod Fargate che devono essere migrati a nuovi profili. ## Creazione di un profilo Fargate Questa sezione descrive come creare un profilo Fargate. Devi inoltre aver creato un ruolo di esecuzione del pod da utilizzare per il profilo Fargate. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). I pod in esecuzione su Fargate sono supportati solo su sottoreti private con un accesso [NAT gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) ai servizi AWS, ma senza una route diretta a un gateway Internet. In questo modo il VPC del cluster deve avere sottoreti private disponibili. Puoi creare un profilo con ciò che segue: + [`eksctl`](#eksctl_create_a_fargate_profile) + [Console di gestione AWS](#console_create_a_fargate_profile) ## `eksctl` **Creazione di un profilo Fargate con `eksctl` ** Crea il tuo profilo Fargate con il seguente comando `eksctl`, sostituendo ogni valore di esempio con i valori in tuo possesso. Devi specificare un namespace. Tuttavia, l’opzione `--labels` non è obbligatoria. ``` eksctl create fargateprofile \ --cluster my-cluster \ --name my-fargate-profile \ --namespace my-kubernetes-namespace \ --labels key=value ``` È possibile utilizzare determinati caratteri jolly per `my-kubernetes-namespace` e etichette `key=value`. Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards). ## Console di gestione AWS **Creazione di un profilo Fargate con Console di gestione AWS ** 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Scegli il cluster per cui creare un profilo Fargate. 1. Scegli la scheda **Calcolo**. 1. Nella sezione **Profili Fargate**, scegli **Aggiungi profilo Fargate**. 1. Nella pagina **Configure Fargate profile** (Configura profilo Fargate), procedere come segue: 1. In **Nome**, inserisci un nome univoco per il profilo Fargate, ad esempio `my-profile`. 1. Per il **ruolo di esecuzione del pod**, scegli il ruolo di esecuzione del pod da utilizzare con il profilo Fargate. Vengono visualizzati solo i ruoli IAM con il principale del servizio `eks-fargate-pods.amazonaws.com`. Se non vedi alcun ruolo nell’elenco, è necessario crearne uno. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). 1. Modifica le **sottoreti** selezionate in base alle esigenze. **Nota** Solo le sottoreti private sono supportate per i pod in esecuzione su Fargate. 1. In **Tag**, puoi facoltativamente aggiungere tag al tuo profilo Fargate. Questi tag non si propagano ad altre risorse associate al profilo, ad esempio i suoi pod. 1. Scegli **Next (Successivo)**. 1. Nella pagina **Configura selezione pod**, procedi come segue: 1. In **Namespace**, inserisci uno spazio dei nomi che corrisponda ai pod. + È possibile utilizzare spazi dei nomi specifici da abbinare, ad esempio `kube-system` o `default`. + È possibile utilizzare determinati caratteri jolly (ad esempio, `prod-*`) per abbinare più spazi dei nomi (ad esempio, `prod-deployment` e `prod-test`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards). 1. (Facoltativo) Aggiungere etichette Kubernetes al selettore. In particolare, aggiungile al selettore a cui devono corrispondere i pod nel namespace specificato. + Puoi aggiungere l’etichetta `infrastructure: fargate` al selettore in modo che solo i pod nel namespace specificato che hanno anche l’etichetta Kubernetes `infrastructure: fargate` corrispondano al selettore. + È possibile utilizzare determinati caratteri jolly (ad esempio, `key?: value?`) per abbinare più spazi dei nomi (ad esempio, `keya: valuea` e `keyb: valueb`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards). 1. Scegli **Next (Successivo)**. 1. Nella pagina **Rivedi e crea**, controlla le informazioni relative al profilo Fargate e scegli **Crea**. # Eliminare un profilo Fargate Questo argomento descrive come eliminare un profilo Fargate. Quando si elimina un profilo Fargate, eventuali pod pianificati su Fargate con tale profilo vengono eliminati. Se tali pod corrispondono a un altro profilo Fargate, vengono pianificati su Fargate con quel profilo. Se non corrispondono più a nessun profilo Fargate, non saranno pianificati su Fargate e potrebbero rimanere in sospeso. Solo un profilo Fargate in un cluster alla volta può essere nello stato `DELETING`. Devi attendere il completamento dell'eliminazione di un profilo Fargate prima di poter eliminare altri profili nel cluster. Ѐ possibile eliminare un profilo con uno qualsiasi dei seguenti strumenti: + [`eksctl`](#eksctl_delete_a_fargate_profile) + [Console di gestione AWS](#console_delete_a_fargate_profile) + [CLI AWS](#awscli_delete_a_fargate_profile) ## `eksctl` **Eliminare un profilo Fargate con `eksctl`** Utilizza il comando seguente per eliminare un profilo da un cluster. Sostituire ogni *valore di esempio* con i propri valori. ``` eksctl delete fargateprofile --name my-profile --cluster my-cluster ``` ## Console di gestione AWS **Eliminare un profilo Fargate con Console di gestione AWS** 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Nel pannello di navigazione a sinistra, seleziona **Cluster**. Nell'elenco dei cluster, scegli il cluster da cui desideri eliminare il profilo Fargate. 1. Scegli la scheda **Calcolo**. 1. Scegli il profilo Fargate da eliminare e quindi **Elimina**. 1. Nella pagina **Elimina profilo Fargate**, digita il nome del profilo e scegli **Elimina**. ## CLI AWS **Eliminare un profilo Fargate con AWS CLI** Utilizza il comando seguente per eliminare un profilo da un cluster. Sostituire ogni *valore di esempio* con i propri valori. ``` aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster ``` # Comprendere i dettagli di configurazione dei pod di Fargate Questa sezione descrive alcuni dei dettagli di configurazione dei pod unici per l’esecuzione dei pod Kubernetes su AWS Fargate. ## Memoria e CPU del pod Kubernetes ti consente di definire le richieste, una quantità minima di risorse vCPU e di memoria allocate a ciascun container in un pod. I pod sono programmati da Kubernetes per garantire che almeno le risorse richieste per ciascun pod siano disponibili nella risorsa di calcolo. Per ulteriori informazioni, consulta [Gestione risorse di calcolo per container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) nella documentazione su Kubernetes. **Nota** Poiché Amazon EKS Fargate esegue solo un pod per nodo, lo scenario di espulsione dei pod in caso di meno risorse non si verifica. Tutti i pod Amazon EKS Fargate funzionano con priorità garantita, quindi la CPU e la memoria richieste devono essere uguali al limite per tutti i container. Per ulteriori informazioni, consulta [Gestire la qualità di servizio per i pod](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) nella documentazione di Kubernetes. Quando i pod sono programmati su Fargate, le prenotazioni di vCPU e memoria all’interno della specifica del pod determinano la quantità di CPU e memoria per effettuare il provisioning per il pod. + La richiesta massima di qualsiasi container Init viene utilizzata per determinare i requisiti di memoria e vCPU della richiesta Init. + Le richieste per tutti i container con esecuzione prolungata vengono aggiunte per determinare i requisiti di memoria e vCPU della richiesta con esecuzione prolungata. + Il valore maggiore tra i due valori sopra indicati viene scelto per la richiesta di vCPU e memoria da utilizzare per il pod. + Fargate aggiunge 256 MB alla prenotazione di memoria di ogni pod per i componenti Kubernetes richiesti (`kubelet`, `kube-proxy` e `containerd`). Fargate arrotonda alla configurazione di calcolo mostrata di seguito che corrisponde più strettamente alla somma delle richieste di vCPU e di memoria, al fine di garantire che i pod abbiano sempre le risorse necessarie per la loro esecuzione. Se non specifichi una combinazione di vCPU e memoria, viene utilizzata la combinazione più piccola disponibile (.25 vCPU e 0,5 GB di memoria). La tabella seguente mostra le combinazioni di vCPU e memoria disponibili per i pod in esecuzione su Fargate. | Valore vCPU | Valore memoria | | --- | --- | | .25 vCPU | 0,5 GB, 1 GB, 2 GB | | .5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB | | 1 vCPU | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | | 2 vCPU | Tra 4 GB e 16 GB in incrementi di 1 GB | | 4 vCPU | Tra 8 GB e 30 GB in incrementi di 1 GB | | 8 vCPU | Tra 16 GB e 60 GB in incrementi di 4 GB | | 16 vCPU | Tra 32 GB e 120 GB in incrementi di 8 GB | La memoria aggiuntiva riservata ai componenti Kubernetes può causare un’attività Fargate con più vCPUs di quelle richieste per il provisioning. Ad esempio, una richiesta per 1 vCPU e 8 GB di memoria avrà 256 MB aggiunti alla richiesta di memoria e fornirà un’attività Fargate di 2 vCPU e 9 GB di memoria, poiché non è disponibile alcuna attività con 1 vCPU e 9 GB di memoria. Non vi è alcuna correlazione tra la dimensione del pod in esecuzione su Fargate e quella del nodo riportata da Kubernetes con `kubectl get nodes`. La dimensione del nodo riportata è spesso maggiore della capacità del pod. Puoi verificare la capacità del pod utilizzando il comando seguente. Sostituisci *default* con il namespace del pod e *pod-name* con il nome dello stesso. ``` kubectl describe pod --namespace default pod-name ``` Di seguito viene riportato un output di esempio: ``` [...] annotations: CapacityProvisioned: 0.25vCPU 0.5GB [...] ``` L’annotazione `CapacityProvisioned` rappresenta la capacità del pod applicata e determina il costo del pod in esecuzione su Fargate. Per informazioni sui prezzi di queste configurazioni di calcolo, vedi [Prezzi Fargate AWS](https://aws.amazon.com/fargate/pricing/). ## Archiviazione in Fargate Un pod in esecuzione su Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver. Non puoi utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma puoi usare quello statico. Per ulteriori informazioni, consulta [Driver CSI per Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) su GitHub. Una volta fornito, ciascun pod in esecuzione su Fargate riceve uno storage temporaneo predefinito di 20 GiB. Questo tipo di archiviazione viene eliminato dopo che un pod si ferma. Per i nuovi pod avviati su Fargate, la crittografia del volume di archiviazione temporanea è abilitata per impostazione predefinita. L’archiviazione del pod effimero viene crittografata con un algoritmo di crittografia AES-256 utilizzando chiavi gestite da Fargate AWS. **Nota** Lo storage utilizzabile predefinito per i pod Amazon EKS che funzionano su Fargate sono inferiori a 20 GiB. Questo perché parte dello spazio viene utilizzato da `kubelet` e altri moduli Kubernetes che vengono caricati all’interno del pod. Puoi aumentare la quantità totale di storage temporaneo fino a un massimo di 175 GiB. Per configurare la dimensione con Kubernetes, specifica le richieste della risorsa `ephemeral-storage` per ogni container in un pod. Quando Kubernetes pianifica i pod, garantisce che la somma delle richieste di risorse per ciascun pod sia inferiore alla capacità dell’attività Fargate. Per ulteriori informazioni, consulta [Gestione delle risorse per pod e container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) nella documentazione di Kubernetes. Amazon EKS Fargate fornisce un maggiore spazio di archiviazione temporaneo di quello richiesto ai fini dell’utilizzo del sistema. Ad esempio, una richiesta di 100 GiB fornirà un’attività Fargate con 115 GiB di storage temporaneo. # Imposta azioni per gli eventi relativi all’applicazione di patch del sistema operativo AWS Fargate Amazon EKS applica periodicamente delle patch al sistema operativo per i nodi AWS Fargate al fine di garantirne la sicurezza. Come parte del processo di applicazione delle patch, ricicliamo i nodi per installare le patch del sistema operativo. Gli aggiornamenti vengono effettuati in modo da avere il minore impatto possibile sui servizi. Tuttavia, se i pod non vengono espulsi con successo, a volte è necessario eliminarli. Di seguito sono riportate le azioni che è possibile intraprendere per ridurre al minimo le potenziali interruzioni: + Imposta i budget di interruzione dei pod (PDB) appropriati per limitare il numero di pod inattivi. + Crea regole di Amazon EventBridge per gestire le espulsioni non riuscite prima che i pod vengano eliminati. + Riavvia manualmente i pod interessati prima della data di espulsione indicata nella notifica ricevuta. + Crea una configurazione di notifica in Notifiche utente di AWS. Amazon EKS lavora a stretto contatto con la community di Kubernetes per rendere disponibili le correzioni dei bug e le patch di sicurezza il più rapidamente possibile. L’avvio di tutti i pod Fargate avviene con la versione più recente della patch di Kubernetes, disponibile da Amazon EKS per la versione di Kubernetes del cluster. Se disponi di un pod con una patch di una versione precedente, Amazon EKS potrebbe riciclarlo per aggiornarlo alla versione più recente. Ciò consente di applicare ai pod gli aggiornamenti per la sicurezza più recenti, in modo da ridurre i rischi nel caso in cui si verifichi una problematica di tipo [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE). Quando il sistema operativo AWS Fargate viene aggiornato, Amazon EKS ti invia una notifica che include le risorse interessate e la data delle prossime espulsioni dei pod. Se la data di espulsione fornita è scomoda, hai la possibilità di riavviare manualmente i pod interessati prima della data di espulsione indicata nella notifica. Tutti i pod creati prima della data di ricezione della notifica sono soggetti a espulsione. Per ulteriori istruzioni su come riavviare manualmente i pod, consulta [Kubernetes Documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart). Per limitare il numero di pod inattivi durante il riciclo degli stessi, puoi impostare i budget di interruzione dei pod (PDB). Con questa opzione è possibile specificare la disponibilità minima in base ai requisiti di ciascuna applicazione e consentire, allo stesso tempo, l’esecuzione di aggiornamenti. La disponibilità minima del PDB deve essere inferiore al 100%. Per ulteriori informazioni, consulta [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) nella documentazione di Kubernetes. Amazon EKS utilizza l’[API di espulsione](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) per interrompere in modo sicuro il pod rispettando i budget di interruzione dei pod impostati per l’applicazione. I pod vengono espulsi dalla zona di disponibilità per ridurre al minimo l’impatto. Se l’espulsione ha esito positivo, il nuovo pod riceve la patch più recente e non sono richieste ulteriori operazioni. Se l’espulsione di un pod ha esito negativo, Amazon EKS invia al tuo account un evento con dettagli relativi al pod in cui si è verificato l’errore. È possibile intraprendere alcune azioni in merito al messaggio prima del periodo di interruzione programmato, che varia in base all’urgenza della patch. Quando è il momento, Amazon EKS proverà a espellere nuovamente i pod. Questa volta, tuttavia, se l’espulsione ha esito negativo non viene inviato un nuovo evento Se l’espulsione continua a non riuscire, i pod esistenti verranno eliminati periodicamente in modo che i nuovi pod possano disporre della patch più recente. L’esempio seguente mostra un evento ricevuto in caso di espulsione del pod che non riesce. Il messaggio contiene dettagli sul cluster, il nome del pod, il namespace del pod, il profilo Fargate e il periodo di interruzione pianificato. ``` { "version": "0", "id": "12345678-90ab-cdef-0123-4567890abcde", "detail-type": "EKS Fargate Pod Scheduled Termination", "source": "aws.eks", "account": "111122223333", "time": "2021-06-27T12:52:44Z", "region": "region-code", "resources": [ "default/my-database-deployment" ], "detail": { "clusterName": "my-cluster", "fargateProfileName": "my-fargate-profile", "podName": "my-pod-name", "podNamespace": "default", "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget", "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]" } } ``` L’associazione di molteplici PDB a un singolo pod può causare un evento di errore di espulsione. Questo evento restituisce il messaggio di errore seguente. ``` "evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support", ``` È possibile creare un’azione desiderata in base a questo evento. Ad esempio, puoi modificare il budget di interruzione dei pod (PDB) per controllare il modo in cui i pod vengono espulsi. Più specificamente, supponi di iniziare con un PDB che specifica la percentuale di destinazione dei pod disponibili. Prima che i pod vengano terminati in modo forzato durante un aggiornamento, puoi regolare il PDB su una percentuale di pod differente. Per ricevere questo evento, devi creare una regola di Amazon EventBridge nell’account AWS e nella Regione AWS a cui appartiene il cluster. La regola deve utilizzare il **modello personalizzato** seguente. Per ulteriori informazioni, consulta la sezione [Creazione di regole Amazon EventBridge che reagiscono agli eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) nella *Guida per l’utente di Amazon EventBridge*. ``` { "source": ["aws.eks"], "detail-type": ["EKS Fargate Pod Scheduled Termination"] } ``` L’evento può essere configurato per acquisire un obiettivo adeguato impostato dall’utente. Per un elenco completo delle destinazioni disponibili, consulta [Destinazioni di Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) nella *Guida per l’utente di Amazon EventBridge*. Inoltre puoi creare una configurazione di notifica in Notifiche utente AWS. Quando usi Console di gestione AWS per creare la notifica, sotto la voce **Regole degli eventi** scegli **Elastic Kubernetes Service (EKS)** per il **Nome di servizio AWS** e **Arresto programmato di EKS Fargate pod** per il **Tipo di evento**. Per ulteriori informazioni, consulta [Guida introduttiva alle Notifiche utente AWS](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) nella Guida per l’utente delle Notifiche utente AWS. Consulta [Domande frequenti: Avviso di espulsione di un Fargate Pod](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) in *AWS re:Post* per le domande frequenti riguardo alle espulsioni dei pod EKS. # Raccogli le AWS metriche dell'app Fargate e dell'utilizzo Puoi raccogliere metriche di sistema e metriche di CloudWatch utilizzo per AWS Fargate. ## Parametri di applicazione Per le applicazioni in esecuzione su Amazon EKS e AWS Fargate, puoi utilizzare AWS Distro for OpenTelemetry (ADOT). ADOT ti consente di raccogliere i parametri di sistema e inviarli ai dashboard di Container Insights. CloudWatch Per iniziare a usare ADOT per le applicazioni in esecuzione su Fargate, [consultate CloudWatch Using Container Insights AWS with Distro OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) for nella documentazione ADOT. ## Parametri di utilizzo Puoi utilizzare le metriche di CloudWatch utilizzo per fornire visibilità sull'utilizzo delle risorse da parte del tuo account. Utilizza queste metriche per visualizzare l'utilizzo corrente del servizio su CloudWatch grafici e dashboard. AWS Le metriche di utilizzo di Fargate corrispondono alle AWS quote di servizio. È possibile configurare gli allarmi che avvisano quando l'uso si avvicina a una quota di servizio. Per ulteriori informazioni sulle quote di servizio per Fargate, consulta [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md). AWS Fargate pubblica le seguenti metriche nel namespace. ` AWS/Usage` | Metrica | Description | | --- | --- | | `ResourceCount` | Il numero totale delle risorse specificate in esecuzione nell'account. La risorsa è definita dalle dimensioni associate attraverso il parametro. | Le seguenti dimensioni vengono utilizzate per perfezionare le metriche di utilizzo pubblicate da AWS Fargate. | Dimensione | Description | | --- | --- | | `Service` | Il nome del AWS servizio che contiene la risorsa. Per le metriche di utilizzo di AWS Fargate, il valore per questa dimensione è. `Fargate` | | `Type` | Il tipo di entità che viene segnalato. Attualmente, l'unico valore valido per le metriche di utilizzo di AWS Fargate è. `Resource` | | `Resource` | Il tipo di risorsa in esecuzione. Attualmente, AWS Fargate restituisce informazioni sull'utilizzo di Fargate On-Demand. Il valore della risorsa per l'utilizzo on demand di Fargate è `OnDemand`. [NOTA] ==== L’utilizzo di Fargate On-Demand combina i pod Amazon EKS utilizzando Fargate, le attività Amazon ECS che utilizzano il tipo di avvio di Fargate e le attività Amazon ECS che usano il provider di capacità `FARGATE`. ==== | | `Class` | La classe della risorsa monitorata. Attualmente, AWS Fargate non utilizza la dimensione classe. | ### Creazione di un CloudWatch allarme per monitorare le metriche di utilizzo delle risorse di Fargate AWS Fargate fornisce metriche di CloudWatch utilizzo che corrispondono alle quote di AWS servizio per l'utilizzo delle risorse Fargate On-Demand. Nella console Service Quotas (Quote di Servizio) è possibile visualizzare l'utilizzo in un grafico. È inoltre possibile configurare gli allarmi che avvisano quando l'uso si avvicina a una quota di servizio. Per ulteriori informazioni, consulta [Raccogli le AWS metriche dell'app Fargate e dell'utilizzo](#monitoring-fargate-usage). Utilizzate i seguenti passaggi per creare un CloudWatch allarme basato sulle metriche di utilizzo delle risorse di Fargate. 1. Apri la console Service Quotas all'indirizzo. https://console.aws.amazon.com/servicequotas/ 1. Nel riquadro di navigazione a sinistra, scegli ** AWS servizi**. 1. Dall'elenco dei ** AWS servizi**, cerca e seleziona ** AWS Fargate**. 1. Nell'elenco **Service Quotas**, seleziona la quota di utilizzo Fargate per cui desideri creare un allarme. 1. Nella sezione CloudWatch Allarmi Amazon, scegli **Crea**. 1. Per **Soglia di allarme**, scegli la percentuale del valore della quota applicata che desideri impostare come valore per l'allarme. 1. Per **Nome allarme**, immetti un nome per l'allarme e quindi scegli **Crea**. # Avviare la registrazione di log AWS Fargate per il cluster Amazon EKS su Fargate offre un router di registro integrato basato su Fluent Bit. Ciò significa che non viene eseguito esplicitamente un container Fluent Bit come sidecar, ma è Amazon a eseguirlo. Tutto quello che devi fare è configurare il router di log. La configurazione avviene attraverso un `ConfigMap` dedicato che deve soddisfare i seguenti criteri: + Deve essere denominato `aws-logging` + Creato in uno spazio dei nomi dedicato denominato `aws-observability` + Non può contenere più di 5.300 caratteri. Una volta creato `ConfigMap`, Amazon EKS su Fargate lo rileva in automatico e lo utilizza per configurare il router di log. Fargate utilizza una versione di AWS per Fluent Bit, una distribuzione upstream conforme di Fluent Bit gestita da AWS. Per ulteriori informazioni, consultare [AWS per Fluent Bit](https://github.com/aws/aws-for-fluent-bit) su GitHub. Il router di log consente di utilizzare la vasta gamma di servizi AWS per l'analisi e per l'archiviazione dei log. È possibile trasmettere i registri da Fargate direttamente ad Amazon CloudWatch, un servizio OpenSearch di Amazon. È possibile trasmettere i log anche a destinazioni come [Amazon S3](https://aws.amazon.com/s3/) e [flusso di dati Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/), così come a strumenti partner tramite [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). + Un profilo Fargate esistente che specifichi un namespace Kubernetes esistente in cui si implementano i pod Fargate. Per ulteriori informazioni, consulta [Fase 3: creare un profilo Fargate per il cluster](fargate-getting-started.md#fargate-gs-create-profile). + Un ruolo di esecuzione del pod Fargate esistente. Per ulteriori informazioni, consulta [Fase 2: creare un ruolo di esecuzione del pod Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role). ## Configurazione del router di log **Importante** Affinché i log vengano pubblicati correttamente, deve essere possibile accedere alla rete dal VPC in cui si trova il cluster alla destinazione dei log. Ciò riguarda principalmente gli utenti che personalizzano le regole di uscita per il VPC. Per ulteriori informazioni sull’utilizzo di CloudWatch, consultare la pagina [Using CloudWatch Logs with interface VPC endpoints](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) della *Guida per l’utente di Amazon CloudWatch Logs*. Nelle fasi seguenti, sostituire ogni *valore di esempio* con i propri valori. 1. Creare uno spazio dei nomi Kubernetes dedicato denominato `aws-observability`. 1. Salva nel tuo computer i seguenti contenuti in un file denominato `aws-observability-namespace.yaml`. Il valore per `name` deve essere `aws-observability` e l'etichetta `aws-observability: enabled` è obbligatoria. ``` kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled ``` 1. Crea lo spazio dei nomi. ``` kubectl apply -f aws-observability-namespace.yaml ``` 1. Crea una `ConfigMap` con valore dei dati `Fluent Conf` per spedire i log del container verso una destinazione. Fluent Conf è Fluent Bit, un linguaggio di configurazione del processore di log veloce e leggero che viene utilizzato per instradare i log del container verso una destinazione di log selezionata. Per ulteriori informazioni, consultare [File di configurazione](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) nella documentazione di Fluent Bit. **Importante** In una `Fluent Conf` tipica, le sezioni principali incluse sono `Service`, `Input`, `Filter` e `Output`. Tuttavia, il router di log di Fargate accetta solo: Le sezioni `Filter` e `Output`. Una sezione `Parser`. Se fornisci altre sezioni, queste verranno rifiutate. Il router di log Fargate gestisce le sezioni `Service` e `Input`. Ha la sezione `Input` seguente, che non può essere modificata e non è necessaria in `ConfigMap`. Tuttavia, è possibile ricavarne informazioni, ad esempio il limite del buffer di memoria e il tag applicato per i log. ``` [INPUT] Name tail Buffer_Max_Size 66KB DB /var/log/flb_kube.db Mem_Buf_Limit 45MB Path /var/log/containers/*.log Read_From_Head On Refresh_Interval 10 Rotate_Wait 30 Skip_Long_Lines On Tag kube.* ``` Quando crei la `ConfigMap`, ricorda le seguenti regole utilizzate da Fargate per convalidare i campi: + `[FILTER]`, `[OUTPUT]`, e `[PARSER]` dovrebbero essere specificati sotto ogni chiave corrispondente. Ad esempio: `[FILTER]` deve essere in `filters.conf`. È possibile avere uno o più `[FILTER]` in `filters.conf`. Anche le sezioni `[OUTPUT]` e `[PARSER]` dovrebbero essere specificate sotto le chiavi corrispondenti. Specificando più sezioni `[OUTPUT]`, è possibile instradare i registritha a destinazioni diverse contemporaneamente. + Fargate convalida le chiavi richieste per ogni sezione. `Name` e `match` sono necessari per ogni `[FILTER]` e `[OUTPUT]`. `Name` e `format` sono necessari per ogni `[PARSER]`. Le chiavi non fanno distinzione tra maiuscole e minuscole. + Variabili di ambiente come `${ENV_VAR}` non sono ammesse in `ConfigMap`. + La rientranza deve essere la stessa sia per la direttiva che per la coppia chiave-valore all'interno di ogni `filters.conf`, `output.conf` e `parsers.conf`. Le coppie chiave-valore devono essere rientranti piuttosto che direttive. + Fargate effettua la convalida in base ai seguenti filtri supportati: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify` e `kubernetes`. + Fargate effettua la convalida in base al seguente output supportato: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs`, e `kinesis`. + In `ConfigMap` deve essere fornito almeno un plugin `Output` supportato per abilitare la registrazione di log. `Filter` e `Parser` non sono necessari per abilitarla. È possibile anche eseguire Fluent Bit su Amazon EC2 utilizzando la configurazione desiderata per risolvere eventuali problemi derivanti dalla convalida. Crea il `ConfigMap` utilizzando uno degli esempi seguenti. **Importante** La registrazione di log Fargate di Amazon EKS non supporta la configurazione dinamica di `ConfigMap`. Eventuali modifiche a `ConfigMap` vengono applicate solo ai nuovi pod. Le modifiche non vengono applicate ai pod esistenti. Crea un `ConfigMap` utilizzando l'esempio per la destinazione di log desiderata. **Nota** Puoi anche utilizzare Flusso di dati Amazon Kinesis come destinazione dei log. Se utilizzi Flusso di dati Kinesis, assicurati che al ruolo di esecuzione del pod sia stata concessa l'autorizzazione `kinesis:PutRecords`. Per ulteriori informazioni, consulta la sezione [Permissions](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) relativa a flusso di dati Amazon Kinesis in *Fluent Bit: Official Manual*. **Example** ------ #### [ CloudWatch ] Quando utilizzi CloudWatch, hai a disposizione due opzioni di output: + [Un plug-in di output scritto in C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) + [Un plug-in di output scritto in Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) Nell'esempio seguente viene illustrato come utilizzare il plug-in `cloudwatch_logs` per inviare i log a CloudWatch. 1. Salva i contenuti seguenti in un file denominato `aws-logging-cloudwatch-configmap.yaml`. Sostituire *region-code* con la Regione AWS in cui si trova il cluster. I parametri in `[OUTPUT]` sono obbligatori. ``` kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch. filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio [FILTER] Name kubernetes Match kube.* Merge_Log On Keep_Log Off Buffer_Size 0 Kube_Meta_Cache_TTL 300s output.conf: | [OUTPUT] Name cloudwatch_logs Match kube.* region region-code log_group_name my-logs log_stream_prefix from-fluent-bit- log_retention_days 60 auto_create_group true parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?