View a markdown version of this page

considerazioni kro per EKS - Amazon EKS

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

considerazioni kro per EKS

Esamina le considerazioni importanti sull'utilizzo della funzionalità gestita EKS per kro, tra cui quando utilizzare la composizione delle risorse, i modelli RBAC e l'integrazione con altre funzionalità EKS.

Quando usare kro

kro è progettato per creare modelli di infrastruttura riutilizzabili e API personalizzate che semplificano la gestione complessa delle risorse.

Usa kro quando devi:

  • Crea piattaforme self-service con API semplificate per i team applicativi

  • Standardizza i modelli di infrastruttura tra i team (database, backup e monitoraggio)

  • Gestisci le dipendenze delle risorse e trasferisci i valori tra le risorse

  • Crea astrazioni personalizzate che nascondono la complessità dell'implementazione

  • Componi più risorse ACK in blocchi costitutivi di livello superiore

  • Abilita i GitOps flussi di lavoro per stack di infrastrutture complessi

Non usare kro quando:

  • Gestione di risorse semplici e autonome (usa direttamente le risorse ACK o Kubernetes)

  • È necessaria una logica di runtime dinamica (kro è dichiarativo, non imperativo)

  • Le risorse non hanno dipendenze o configurazioni condivise

kro eccelle nella creazione di «percorsi asfaltati», schemi ponderati e riutilizzabili che consentono ai team di implementare correttamente infrastrutture complesse.

Modelli RBAC

kro consente la separazione delle preoccupazioni tra i team della piattaforma che creano le istanze ResourceGraphDefinitions e i team delle applicazioni che creano le istanze.

Responsabilità del team di piattaforma

I team della piattaforma creano e gestiscono ResourceGraphDefinitions (RGD) che definiscono API personalizzate.

Autorizzazioni necessarie:

  • Crea, aggiorna, elimina ResourceGraphDefinitions

  • Gestisci i tipi di risorse sottostanti (implementazioni, servizi, risorse ACK)

  • Accesso a tutti i namespace in cui verranno utilizzati gli RGD

Esempio ClusterRole per il team della piattaforma:

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: platform-kro-admin rules: - apiGroups: ["kro.run"] resources: ["resourcegraphdefinitions"] verbs: ["*"] - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list", "watch"]

Per una configurazione RBAC dettagliata, vedere. Configura le autorizzazioni kro

Responsabilità del team di applicazione

I team applicativi creano istanze di risorse personalizzate definite da RGD senza dover comprendere la complessità sottostante.

Autorizzazioni necessarie:

  • Creare, aggiornare ed eliminare istanze di risorse personalizzate

  • Accesso in lettura al loro namespace

  • Nessun accesso alle risorse sottostanti o agli RGD

Vantaggi:

  • I team utilizzano API semplici e di alto livello

  • I team della piattaforma controllano i dettagli dell'implementazione

  • Riduzione del rischio di errori di configurazione

  • Onboarding più rapido per i nuovi membri del team

Integrazione con altre funzionalità EKS

Composizione di risorse ACK

kro è particolarmente potente se combinato con ACK per creare modelli di infrastruttura.

Schemi comuni:

  • Applicazione con archiviazione: bucket S3+coda SQS+configurazione delle notifiche

  • Stack di database: istanza RDS + gruppo di parametri + gruppo di sicurezza + segreto Secrets Manager

  • Rete: VPC + sottoreti + tabelle di routing + gruppi di sicurezza + gateway NAT

  • Elaborazione con storage: istanza EC2 + volumi EBS + profilo di istanza IAM

kro gestisce l'ordine delle dipendenze, passa i valori tra le risorse (come ARN e stringhe di connessione) e gestisce l'intero ciclo di vita come una singola unità.

Per esempi di composizione di risorse ACK, vedi. Concetti ACK

GitOps con Argo CD

Usa il CD EKS Capability for Argo per distribuire sia RGD che istanze dai repository Git.

Organizzazione del repository:

  • Repo della piattaforma: contiene contenuti ResourceGraphDefinitions gestiti dal team della piattaforma

  • Repo di applicazioni: contengono istanze di risorse personalizzate gestite dai team delle app

  • Repo condiviso: contiene sia RGD che istanze per organizzazioni più piccole

Considerazioni:

  • Implementa gli RGD prima delle istanze (le onde di sincronizzazione di Argo CD possono aiutarti)

  • Utilizzate progetti Argo CD separati per i team di piattaforme e applicazioni

  • Il team della piattaforma controlla l'accesso al repository RGD

  • I team applicativi hanno accesso in sola lettura alle definizioni RGD

Per ulteriori informazioni su Argo CD, vedere. Lavorare con Argo CD

Organizzare ResourceGraphDefinitions

Organizza gli RGD per scopo, complessità e proprietà.

Per scopo:

  • Infrastruttura: stack di database, rete, archiviazione

  • Applicazione: app Web, API, processi in batch

  • Piattaforma: servizi condivisi, monitoraggio, registrazione

Per complessità:

  • Semplice: 2-3 risorse con dipendenze minime

  • Moderato: 5-10 risorse con alcune dipendenze

  • Complesso: più di 10 risorse con dipendenze complesse

Convenzioni di denominazione:

  • Usa nomi descrittivi:, webapp-with-database s3-notification-queue

  • Includi la versione nel nome per annullare le modifiche: webapp-v2

  • Usa prefissi coerenti per gli RGD correlati:, platform- app-

Strategia del namespace:

  • Gli RGD sono con ambito cluster (non con namespace)

  • Le istanze hanno un namespace

  • Usa i selettori di namespace negli RGD per controllare dove è possibile creare le istanze

Controllo delle versioni e aggiornamenti

Piano per l'evoluzione di RGD e la migrazione delle istanze.

Aggiornamenti RGD:

  • Non-breaking modifiche: aggiorna RGD in atto (aggiungi campi opzionali, nuove risorse con IncludeWhen)

  • Ultime modifiche: crea un nuovo RGD con un nome diverso (webapp-v2)

  • Deprecazione: contrassegna i vecchi RGD con annotazioni, comunica la cronologia della migrazione

Migrazione delle istanze:

  • Crea nuove istanze con RGD aggiornato

  • Convalida il corretto funzionamento delle nuove istanze

  • Elimina le vecchie istanze

  • kro gestisce automaticamente gli aggiornamenti delle risorse sottostanti

Migliori pratiche:

  • Verifica innanzitutto le modifiche RGD in ambienti non di produzione

  • Usa il controllo semantico delle versioni nei nomi RGD per le modifiche principali

  • Modifiche di interruzione dei documenti e percorsi di migrazione

  • Fornisci esempi di migrazione per i team applicativi

Convalida e test

Convalida gli RGD prima di passare alla produzione.

Strategie di convalida:

  • Convalida dello schema: kro convalida automaticamente la struttura RGD

  • Dry-run istanze: crea istanze di test nei namespace di sviluppo

  • Test di integrazione: verifica che le risorse composte funzionino insieme

  • Applicazione delle politiche: utilizza i controller di ammissione per far rispettare gli standard organizzativi

Problemi comuni da testare:

  • Dipendenze e ordinamento delle risorse

  • Scambio di valore tra risorse (espressioni CEL)

  • Inclusione condizionale delle risorse (includeWhen)

  • Propagazione dello stato dalle risorse sottostanti

  • Autorizzazioni RBAC, ad esempio la creazione

Documentazione upstream

Per informazioni dettagliate sull'uso di kro:

Fasi successive