Semplifica la gestione dell'elaborazione con AWS Fargate - Amazon EKS

Aiutaci a migliorare questa pagina

Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.

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

Importante

AWS Fargate con Amazon non EKS è disponibile negli AWS GovCloud Stati Uniti orientali e AWS GovCloud negli Stati Uniti occidentali.

In questo argomento viene descritto l'utilizzo di Amazon EKS per l'esecuzione KubernetesPods. AWS Fargate Fargate è una tecnologia che fornisce capacità di calcolo on demand e di dimensioni adeguate per i container. Con Fargate, non è più necessario effettuare personalmente il provisioning, la configurazione o il dimensionamento dei gruppi di macchine virtuali per eseguire i container. Viene anche eliminata la necessità di scegliere i tipi di server, di decidere quando dimensionare i gruppi di nodi o di ottimizzare l'impacchettamento dei cluster.

Puoi controllare quali Pods sono avviati su Fargate e come vengono eseguiti con i profili Fargate. I profili Fargate sono definiti come parte del tuo cluster AmazonEKS. Amazon EKS si integra Kubernetes con Fargate utilizzando controller creati utilizzando il modello upstream ed estensibile fornito AWS da. Kubernetes Questi controller funzionano come parte del piano di Kubernetes controllo EKS gestito da Amazon e sono responsabili della pianificazione nativa su Kubernetes Pods Fargate. I controller Fargate includono un nuovo pianificatore che viene eseguito insieme al pianificatore predefinito di Kubernetes, oltre a diversi controller di ammissione mutanti e convalidanti. Quando si avvia 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 Pods che vengono eseguiti su Fargate e richiama considerazioni speciali sull'utilizzo di Fargate con Amazon. EKS

AWS Fargate considerazioni

Ecco alcuni aspetti da considerare sull'utilizzo di Fargate su Amazon. EKS

  • Ogni Pod in esecuzione su Fargate ha un proprio limite di isolamento. Non condividono il kernel sottostante, CPU le risorse, le risorse di memoria o l'elastic network interface con altriPod.

  • Network Load Balancer e Application Load Balancers (ALBs) possono essere utilizzati con Fargate solo con destinazioni IP. Per ulteriori informazioni, consulta Creazione di un Network Load Balancer e Instrada l'applicazione e HTTP il traffico con Application Load Balancers.

  • 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 Pods in sospeso creati per riprogrammarli su Fargate.

  • I Daemonset non sono supportati su Fargate. Se l'applicazione richiede un daemon, bisogna riconfigurare quel daemon per essere eseguito come container sidecar nei Pods .

  • I container privilegiati non sono supportati su Fargate.

  • I pod in esecuzione su Fargate non possono specificare HostPort o HostNetwork nel manifesto Pod.

  • Per i Pods Fargate, Il limite flessibile predefinito di nofile e nproc è 1024 mentre il limite rigido è 65535.

  • GPUsal momento non sono disponibili su Fargate.

  • I pod che funzionano su Fargate sono supportati solo su sottoreti private (NATcon accesso gateway AWS ai servizi, ma non un percorso diretto verso un Internet Gateway), quindi nel cluster VPC devono essere disponibili sottoreti private. Per i cluster senza accesso Internet in uscita, consulta Implementa cluster privati con accesso limitato a Internet.

  • È possibile utilizzare il Modifica le risorse del pod con Vertical Pod Autoscaler per impostare la dimensione iniziale CPU e la memoria corrette per FargatePods, quindi utilizzare il Implementazione scalabile dei pod con Horizontal Pod Autoscaler per ridimensionarle. Pods Se desideri che Vertical Pod Autoscaler venga ridistribuito automaticamente su Pods Fargate con combinazioni CPU più grandi e di memoria, imposta la modalità per Vertical Pod Autoscaler su una delle due o per garantire la corretta funzionalità. Auto Recreate Per ulteriori informazioni, consulta la documentazione di Vertical Pod Autoscaler su GitHub.

  • DNSla risoluzione e i nomi host devono essere abilitati per il tuo. DNS VPC Per ulteriori informazioni, consulta Visualizzazione e aggiornamento del DNS supporto per VPC.

  • Amazon EKS Fargate aggiunge defense-in-depth Kubernetes applicazioni 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'uso di Amazon EKS non modifica le tue responsabilità nell'ambito del modello di responsabilità condivisa. È 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 secondari. VPC CIDR Potresti voler specificare un blocco secondario. CIDR Ciò è necessario perché in una sottorete è disponibile un numero limitato di indirizzi IP. Di conseguenza, nel cluster è possibile creare un numero limitato di Pods. L'uso di sottoreti diverse per i Pods consente di aumentare il numero di indirizzi IP disponibili. Per ulteriori informazioni, consulta Aggiungere IPv4 CIDR blocchi a unVPC.

  • Il servizio di metadati delle EC2 istanze Amazon (IMDS) non è disponibile per coloro Pods che vengono distribuiti sui nodi Fargate. Se avete Pods installato su Fargate delle credenziali che IAM richiedono credenziali, assegnatele al vostro utilizzo. Pods Ruoli IAM per gli account di servizio Se hai Pods bisogno di accedere ad altre informazioni disponibili tramiteIMDS, devi codificare queste informazioni secondo le tue specifiche. Pod Ciò include la Regione AWS o la zona di disponibilità in cui Pod viene distribuito a.

  • Non puoi distribuire Pods Fargate su AWS Wavelength, o AWS Outposts Local AWS Zones.

  • Amazon EKS deve applicare periodicamente patch a Fargate Pods per tenerli al sicuro. Gli aggiornamenti vengono effettuati in modo da ridurre l'impatto, ma in alcuni casi i Pods devono essere eliminati se non vengono espulsi correttamente. Di seguito sono riportate le azioni che è possibile intraprendere per ridurre al minimo le interruzioni. Per ulteriori informazioni, consulta Imposta azioni per gli eventi di patching del AWS Fargate sistema operativo.

  • Il VPCCNIplug-in Amazon per Amazon EKS è installato sui nodi Fargate. Non puoi utilizzare CNIPlugin alternativi per i cluster Amazon EKS con nodi Fargate.

  • Una versione Pod in esecuzione su Fargate monta automaticamente un file system AmazonEFS. Non è possibile utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma è possibile utilizzare il provisioning statico.

  • Non puoi montare EBS volumi Amazon su Pods Fargate.

  • Puoi eseguire il EBS CSI controller Amazon sui nodi Fargate, ma il EBS CSI nodo Amazon DaemonSet può essere eseguito solo su istanze AmazonEC2.

  • Dopo che un Job Kubernetes è stato contrassegnato Completed o Failed, i Pods creati dal Job 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 Job in seguito.

    Per eliminare automaticamente il file correlato Pods dopo un Job completamento o un errore, 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 Job.

    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