Considerazioni sulle funzionalità EKS

Questo argomento tratta importanti considerazioni sull'utilizzo di EKS Capabilities, tra cui la progettazione del controllo degli accessi, la scelta tra EKS Capabilities e soluzioni autogestite, i modelli architettonici per le implementazioni multi-cluster e le migliori pratiche operative.

Capability, ruoli IAM e Kubernetes RBAC

Ogni risorsa di funzionalità EKS ha un ruolo IAM con funzionalità configurate. Il ruolo di capacità viene utilizzato per concedere le autorizzazioni di AWS servizio alle funzionalità EKS di agire per conto dell'utente. Ad esempio, per utilizzare EKS Capability for ACK per gestire i bucket Amazon S3, concederai le autorizzazioni amministrative di S3 Bucket alla funzionalità, consentendole di creare e gestire i bucket.

Una volta configurata la funzionalità, le risorse S3 in AWS possono essere create e gestite con risorse personalizzate Kubernetes nel cluster. Kubernetes RBAC è il meccanismo di controllo degli accessi all'interno del cluster che consente di determinare quali utenti e gruppi possono creare e gestire tali risorse personalizzate. Ad esempio, concedi a utenti e gruppi Kubernetes RBAC specifici le autorizzazioni per creare e gestire risorse nei namespace di tua scelta. Bucket

In questo modo, IAM e Kubernetes RBAC sono due parti del sistema di controllo degli accessi che regola le autorizzazioni relative alle funzionalità e alle risorse EKS. end-to-end È importante progettare la giusta combinazione di autorizzazioni IAM e policy di accesso RBAC per il tuo caso d'uso.

Per ulteriori informazioni sulla capacità, i ruoli IAM e le autorizzazioni Kubernetes, consulta. Considerazioni sulla sicurezza per EKS Capabilities

Modelli di architettura multicluster

Quando distribuisci funzionalità su più cluster, considera questi modelli architettonici comuni:

Hub and Spoke con gestione centralizzata

Esegui tutte e tre le funzionalità in un cluster gestito centralmente per orchestrare i carichi di lavoro e gestire l'infrastruttura cloud su più cluster di carichi di lavoro.

• Argo CD sul cluster di gestione distribuisce applicazioni su cluster di carico di lavoro in diverse regioni o account

• ACK sul cluster di gestione fornisce AWS risorse (RDS, S3, IAM) per tutti i cluster

• kro sul cluster di gestione crea astrazioni di piattaforma portatili che funzionano su tutti i cluster

Questo modello centralizza il carico di lavoro e la gestione dell'infrastruttura cloud e può semplificare le operazioni per le organizzazioni che gestiscono molti cluster.

Decentralizzato GitOps

I carichi di lavoro e l'infrastruttura cloud sono gestiti dalle funzionalità dello stesso cluster in cui vengono eseguiti i carichi di lavoro.

• Argo CD gestisce le risorse delle applicazioni sul cluster locale.

• Le risorse ACK vengono utilizzate per esigenze di cluster e carichi di lavoro.

• Le astrazioni della piattaforma kro vengono installate e orchestrano le risorse locali.

Questo modello decentralizza le operazioni, con i team che gestiscono i propri servizi di piattaforma dedicati in uno o più cluster.

Hub and Spoke con implementazione ACK ibrida

Combina modelli centralizzati e decentralizzati, con implementazioni di applicazioni centralizzate e gestione delle risorse in base all'ambito e alla proprietà.

• Cluster di hub:

  • Argo CD gestisce le GitOps implementazioni nel cluster locale e in tutti i cluster di carichi di lavoro remoti

  • ACK viene utilizzato nel cluster di gestione per le risorse con ambito amministrativo (database di produzione, ruoli IAM,) VPCs

  • kro viene utilizzato nel cluster di gestione per le astrazioni riutilizzabili della piattaforma

• Cluster Spoke:

  • I carichi di lavoro sono gestiti tramite Argo CD sul cluster di hub centralizzato

  • ACK viene utilizzato localmente per le risorse relative ai carichi di lavoro (bucket S3, istanze, code SQS) ElastiCache

  • kro viene utilizzato localmente per la composizione delle risorse e i modelli di blocchi costitutivi

Questo modello separa le preoccupazioni: i team di piattaforma gestiscono l'infrastruttura critica centralmente sui cluster di gestione, includendo facoltativamente i cluster di carichi di lavoro, mentre i team applicativi specificano e gestiscono le risorse cloud insieme ai carichi di lavoro.

Scelta di un pattern

Considerate questi fattori nella scelta di un'architettura:

• Struttura organizzativa: i team di piattaforma centralizzati preferiscono modelli di hub; i team decentralizzati possono preferire funzionalità per cluster

• Ambito delle risorse: le risorse con ambito amministrativo (database, IAM) spesso traggono vantaggio dalla gestione centralizzata; le risorse dei carichi di lavoro (bucket, code) possono essere gestite localmente

• Self-service: i team di piattaforma centralizzati possono creare e distribuire risorse prescrittive personalizzate per consentire un self-service sicuro delle risorse cloud per le esigenze di carichi di lavoro comuni

• Gestione della flotta di cluster: i cluster di gestione centralizzati forniscono un piano di controllo di proprietà del cliente per la gestione della flotta dei cluster EKS, insieme ad altre risorse destinate all'amministrazione

• Requisiti di conformità: alcune organizzazioni richiedono un controllo centralizzato per l'audit e la governance

• Complessità operativa: un minor numero di istanze di funzionalità semplifica le operazioni ma può creare colli di bottiglia

Nota

Puoi iniziare con uno schema ed evolvere verso un altro man mano che la tua piattaforma matura. Le funzionalità sono indipendenti: puoi distribuirle in modo diverso tra i cluster in base alle tue esigenze.

Confronto tra le funzionalità EKS e le soluzioni autogestite

EKS Capabilities offre esperienze completamente gestite per i più diffusi strumenti e controller Kubernetes eseguiti in EKS. Ciò si differenzia dalle soluzioni autogestite, che vengono installate e utilizzate nel cluster.

Principali differenze

Implementazione e gestione

AWS gestisce completamente EKS Capabilities senza che sia richiesta l'installazione, la configurazione o la manutenzione dei componenti software. AWS installa e gestisce automaticamente tutte le Kubernetes Custom Resource Definitions (CRDs) richieste nel cluster.

Con le soluzioni autogestite, puoi installare e configurare il software del cluster utilizzando Helm charts, kubectl o altri operatori. Hai il pieno controllo sul ciclo di vita del software e sulla configurazione di runtime delle tue soluzioni autogestite, fornendo personalizzazioni a qualsiasi livello della soluzione.

Operazioni e manutenzione

AWS gestisce l'applicazione di patch e altre operazioni del ciclo di vita del software per EKS Capabilities, con aggiornamenti automatici e patch di sicurezza. EKS Capabilities è integrato con AWS funzionalità per configurazioni semplificate, offre elevata disponibilità e tolleranza ai guasti integrate ed elimina la risoluzione dei problemi all'interno del cluster dei carichi di lavoro dei controller.

Le soluzioni autogestite richiedono il monitoraggio dello stato e dei registri dei componenti, l'applicazione di patch di sicurezza e aggiornamenti delle versioni, la configurazione dell'alta disponibilità con più repliche e budget per le interruzioni dei pod, la risoluzione dei problemi e la risoluzione dei problemi relativi al carico di lavoro dei controller e la gestione di release e versioni. Avete il pieno controllo sulle vostre implementazioni, ma ciò richiede spesso soluzioni su misura per l'accesso privato ai cluster e altre integrazioni che devono essere in linea con gli standard organizzativi e i requisiti di conformità in materia di sicurezza.

Consumo di risorse

EKS Capabilities viene eseguito in EKS e all'esterno dei cluster, liberando risorse dei nodi e delle risorse del cluster. Le funzionalità non utilizzano risorse del carico di lavoro del cluster, non consumano CPU o memoria sui nodi di lavoro, scalano automaticamente e hanno un impatto minimo sulla pianificazione della capacità del cluster.

Le soluzioni autogestite eseguono controller e altri componenti sui nodi di lavoro, consumando direttamente le risorse dei nodi di lavoro, il cluster IPs e altre risorse del cluster. La gestione dei servizi cluster richiede la pianificazione della capacità per i relativi carichi di lavoro e richiede la pianificazione e la configurazione delle richieste e dei limiti delle risorse per gestire i requisiti di scalabilità e alta disponibilità.

Supporto funzionalità

Essendo funzionalità di servizio completamente gestite, EKS Capabilities sono per loro natura convincenti rispetto alle soluzioni autogestite. Sebbene le funzionalità supportino la maggior parte delle funzionalità e dei casi d'uso, vi sarà una differenza nella copertura rispetto alle soluzioni autogestite.

Con le soluzioni autogestite, puoi controllare completamente la configurazione, le funzionalità opzionali e altri aspetti della funzionalità del tuo software. È possibile scegliere di eseguire immagini personalizzate, personalizzare tutti gli aspetti della configurazione e controllare completamente la funzionalità della soluzione autogestita.

Considerazioni sui costi

Ogni risorsa di funzionalità EKS ha un costo orario correlato, che varia in base al tipo di funzionalità. Le risorse del cluster gestite dalla funzionalità hanno inoltre un costo orario associato ai rispettivi prezzi. Per ulteriori informazioni, consultare Prezzi di Amazon EKS.

Le soluzioni autogestite non hanno costi diretti legati agli AWS addebiti, ma pagano per le risorse di elaborazione del cluster utilizzate dai controller e dai relativi carichi di lavoro. Oltre al consumo di risorse di nodi e cluster, il costo totale di proprietà delle soluzioni autogestite include i costi operativi e le spese di manutenzione, risoluzione dei problemi e supporto.

Scelta tra EKS Capabilities e soluzioni autogestite

EKS Capabilities Prendete in considerazione questa scelta quando desiderate ridurre il sovraccarico operativo e concentrarvi sul valore differenziato del software e dei sistemi, piuttosto che sulle operazioni della piattaforma in cluster per requisiti fondamentali. Utilizzate EKS Capabilities quando desiderate ridurre al minimo l'onere operativo delle patch di sicurezza e della gestione del ciclo di vita del software, liberare risorse di nodi e cluster per i carichi di lavoro delle applicazioni, semplificare la configurazione e la gestione della sicurezza e beneficiare della copertura di supporto. AWS Le funzionalità EKS sono ideali per la maggior parte dei casi d'uso in produzione e rappresentano l'approccio consigliato per le nuove implementazioni.

Soluzioni autogestite Prendi in considerazione questa scelta quando hai bisogno di versioni specifiche dell'API di risorsa Kubernetes, build di controller personalizzate, se disponi di automazione e strumenti esistenti basati su implementazioni autogestite o hai bisogno di una personalizzazione approfondita delle configurazioni di runtime dei controller. Le soluzioni autogestite offrono flessibilità per casi d'uso specializzati e hai il controllo completo sulla configurazione di implementazione e runtime.

Nota

EKS Capabilities può coesistere nel cluster con soluzioni autogestite ed è possibile effettuare migrazioni graduali.

Confronti specifici per funzionalità

Per confronti dettagliati, tra cui funzionalità specifiche delle funzionalità, differenze a monte e percorsi di migrazione, consulta:

• Confronto tra la funzionalità EKS per ACK e l'ACK autogestito

• Confronto tra la funzionalità EKS per Argo CD e Argo CD autogestita

• Confronto tra EKS Capability for kro e kro autogestito