AWS Fargate - Amazon EKS

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

AWS Fargate

Importante

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

In questa sezione viene illustrato l'uso di Amazon EKS per eseguire i Pods Kubernetes su 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 vengono definiti nell'ambito del cluster Amazon EKS. Amazon EKS si integra Kubernetes con Fargate utilizzando controller creati utilizzando il modello upstream ed estensibile fornito AWS da. Kubernetes Questi controller vengono eseguiti nell'ambito del piano di controllo Kubernetes gestito da Amazon EKS e sono responsabili della pianificazione dei Pods Kubernetes nativi su 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.

In questa sezione sono descritti i diversi componenti dei Pods in esecuzione su Fargate e sono riportate considerazioni speciali per l'utilizzo di Fargate con Amazon EKS.

AWS Fargate considerazioni

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 isolamento. 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, consultare Creazione di un Network Load Balancer e Bilanciamento del carico di applicazione su Amazon EKS.

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

  • Le GPU non sono attualmente disponibili su Fargate.

  • I pod che funzionano su Fargate sono supportati solo su sottoreti private (con accesso AWS gateway NAT ai servizi, ma non un percorso diretto verso un Internet Gateway), quindi il VPC del cluster deve disporre di sottoreti private. Per i cluster senza accesso Internet in uscita, consulta Requisiti dei cluster privati.

  • Puoi utilizzare Vertical Pod Autoscaler per impostare la dimensione corretta iniziale della CPU e la memoria per i Pods Fargate, quindi utilizzare il comando Horizontal Pod Autoscaler per scalare quei Pods. Se desideri che il Vertical Pod Autoscaler implementi nuovamente in automatico i Pods su Fargate con combinazioni di CPU e memoria maggiori, imposta la modalità per il Vertical Pod Autoscaler su Auto o Recreate per garantire il corretto funzionamento. Per ulteriori informazioni, consulta la documentazione di 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 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'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 è 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 Aggiunta di blocchi CIDR IPv4 a un VP.

  • Il servizio metadati dell'istanza Amazon EC2 (IMDS) non è disponibile per i Pods implementati sui nodi Fargate. Se disponi di Pods distribuiti in Fargate che necessitano di credenziali IAM, assegnale ai Podsutilizzando Ruoli IAM per gli account di servizio. Se i Pods hanno bisogno di accedere ad altre informazioni disponibili tramite IMDS, bisogna eseguire la codifica fissa di queste informazioni nelle specifiche del 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.

  • Periodicamente, Amazon EKS deve applicare patch ai Pods per garantire che siano sicuri. 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 Applicazione di patch del sistema operativo Fargate.

  • Il plug-in CNI di Amazon VPC PER Amazon EKS è installato sui nodi Fargate. Non puoi utilizzare Plugin CNI compatibili alternativi con nodi Fargate.

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

  • Non puoi montare volumi Amazon EBS su Fargate Pods.

  • 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 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 i dati correlati 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