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

Questo argomento tratta importanti considerazioni sull'utilizzo di EKS Capability 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 personalizzati APIs che semplificano la gestione delle risorse complesse.

Usa kro quando hai bisogno di:

  • Crea piattaforme self-service semplificate per i team applicativi APIs

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

Schemi 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 (RGDs) che definiscono la personalizzazione APIs.

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 RGDs

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 RGDs senza la necessità di comprenderne 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 RGDs

Vantaggi:

  • I team utilizzano strumenti semplici e di alto livello APIs

  • 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: EC2 istanza + volumi EBS + profilo di istanza IAM

kro gestisce l'ordine delle dipendenze, passa i valori tra le risorse (come le stringhe di connessione) ARNs 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 entrambe le RGDs 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 le istanze che le istanze per le RGDs organizzazioni più piccole

Considerazioni:

  • Implementa RGDs prima delle istanze (le onde di sincronizzazione di Argo CD possono esserti utili)

  • 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

Organizzando ResourceGraphDefinitions

RGDs Organizza per scopo, complessità e proprietà.

Per scopo:

  • Infrastruttura: stack di database, rete, archiviazione

  • Applicazione: app Web APIs, lavori 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 RGDs per: platform- app-

Strategia del namespace:

  • RGDs sono con ambito cluster (non con namespace)

  • Le istanze hanno uno spazio dei nomi

  • Usa i selettori dello spazio dei nomi per controllare dove è possibile creare le istanze RGDs

Controllo delle versioni e aggiornamenti

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

Aggiornamenti RGD:

  • Modifiche continue: 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 il vecchio con annotazioni, comunica la cronologia della migrazione RGDs

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 RGDs prima dell'implementazione in produzione.

Strategie di convalida:

  • Convalida dello schema: kro convalida automaticamente la struttura RGD

  • Istanze dry-run: 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