Semplifica la gestione dell’elaborazione con AWS Fargate

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 e Instradare il traffico di applicazioni e HTTP con Application Load Balancer.

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.

Puoi utilizzare Adjust pod resources with Vertical Pod Autoscaler per impostare la dimensione corretta iniziale della CPU e la memoria per i Pod Fargate, quindi utilizza Scale pod deployments with Horizontal Pod Autoscaler 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 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.

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. È 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.

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. 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.

Il plug-in CNI di Amazon VPC per Amazon EKS è installato sui nodi Fargate. Non puoi utilizzare Alternate CNI plugins for Amazon EKS clusters 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 è 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