**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à.
# Funzionalità EKS
**Suggerimento**
[Inizia: [Crea funzionalità ACK \$1 Crea funzionalità](create-ack-capability.md)[Argo CD \$1 Crea](create-argocd-capability.md) funzionalità kro](create-kro-capability.md)
Amazon EKS Capabilities è un set stratificato di funzionalità di cluster completamente gestite che aiutano ad accelerare la velocità degli sviluppatori e a ridurre la complessità della creazione e della scalabilità con Kubernetes. EKS Capabilities sono funzionalità native di Kubernetes per la distribuzione continua dichiarativa, la gestione delle risorse e la creazione e l'orchestrazione AWS delle risorse Kubernetes, tutte completamente gestite da. AWS Con EKS Capabilities, puoi concentrarti maggiormente sulla creazione e sulla scalabilità dei tuoi carichi di lavoro, alleggerendo il carico operativo di questi servizi di piattaforma fondamentali. AWS Queste funzionalità vengono eseguite all'interno di EKS anziché nei cluster, eliminando la necessità di installare, mantenere e scalare i componenti critici della piattaforma sui nodi di lavoro.
Per iniziare, puoi creare una o più funzionalità EKS su un cluster EKS nuovo o esistente. Per fare ciò, puoi usare la AWS CLI, EKS Console di gestione AWS APIs, eksctl o i tuoi strumenti preferiti. infrastructure-as-code Sebbene le funzionalità EKS siano progettate per funzionare insieme, sono risorse cloud indipendenti che puoi scegliere in base al tuo caso d'uso e ai tuoi requisiti.
Tutte le versioni di Kubernetes supportate da EKS sono supportate per EKS Capabilities.
**Nota**
Le funzionalità EKS sono disponibili in tutte le regioni AWS commerciali in cui è disponibile Amazon EKS. Per un elenco delle regioni supportate, consulta gli [endpoint e le quote di Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) nella Guida AWS generale.
## Funzionalità disponibili
### AWS Controller per Kubernetes (ACK)
ACK consente la gestione delle AWS risorse utilizzando Kubernetes APIs, consentendoti di creare e gestire bucket S3, database RDS, ruoli IAM e altre risorse utilizzando risorse personalizzate Kubernetes. AWS ACK riconcilia continuamente lo stato desiderato con lo stato effettivo in cui si trova AWS, correggendo eventuali variazioni nel tempo per mantenere il sistema integro e le risorse configurate come specificato. Puoi gestire AWS le risorse insieme ai carichi di lavoro Kubernetes utilizzando gli stessi strumenti e flussi di lavoro, con supporto per più di 50 AWS servizi tra cui S3, RDS, DynamoDB e Lambda. ACK supporta la gestione delle risorse tra account e regioni, abilitando complesse architetture di gestione di sistemi multi-account e multi-cluster. ACK supporta risorse di sola lettura e adozione in sola lettura, facilitando la migrazione da altre infrastrutture come strumenti di codice ai sistemi basati su Kubernetes.
[Scopri di più su ACK →](ack.md)
### Argo CD
Argo CD GitOps implementa una distribuzione continua basata sulle applicazioni, utilizzando i repository Git come fonte di verità per i carichi di lavoro e lo stato del sistema. Argo CD sincronizza automaticamente le risorse delle applicazioni con i cluster dai repository Git, rilevando e correggendo le deviazioni per garantire che le applicazioni distribuite corrispondano allo stato desiderato. È possibile distribuire e gestire applicazioni su più cluster da una singola istanza Argo CD, con la distribuzione automatizzata dai repository Git ogni volta che vengono apportate modifiche. L'uso combinato di Argo CD e ACK fornisce un GitOps sistema di base, che semplifica la gestione delle dipendenze dei carichi di lavoro e supporta la progettazione di interi sistemi, inclusa la gestione di cluster e infrastrutture su larga scala. Argo CD si integra con AWS Identity Center per l'autenticazione e l'autorizzazione e fornisce un'interfaccia utente Argo ospitata per visualizzare lo stato di integrità e di implementazione delle applicazioni.
[Scopri di più su Argo CD →](argocd.md)
### kro (Kube Resource Orchestrator)
kro ti consente di creare Kubernetes personalizzati APIs che compongono più risorse in astrazioni di livello superiore, permettendo ai team della piattaforma di definire modelli riutilizzabili per combinazioni di risorse comuni: elementi costitutivi del cloud. Con kro, puoi comporre sia Kubernetes che AWS le risorse in astrazioni unificate, utilizzando una sintassi semplice per abilitare configurazioni dinamiche e logica condizionata. kro consente ai team della piattaforma di fornire funzionalità self-service con guardrail appropriati, consentendo agli sviluppatori di fornire infrastrutture complesse utilizzando infrastrutture semplici e appositamente create APIs mantenendo gli standard organizzativi e le migliori pratiche. le risorse kro sono semplicemente risorse Kubernetes e sono specificate in Kubernetes Manifest test che possono essere archiviati in Git o inviati a OCI- registri compatibili come Amazon ECR per un'ampia distribuzione organizzativa.
[Scopri di più su kro →](kro.md)
## Vantaggi delle funzionalità EKS
Le funzionalità EKS sono completamente gestite da AWS, eliminando la necessità di installazione, manutenzione e scalabilità dei servizi cluster di base. AWS gestisce le patch di sicurezza, gli aggiornamenti e la gestione operativa, permettendo ai team di concentrarsi sulla creazione AWS anziché sulle operazioni del cluster. A differenza dei tradizionali componenti aggiuntivi di Kubernetes che consumano risorse del cluster, le funzionalità vengono eseguite in EKS anziché sui nodi di lavoro. Ciò consente di liberare capacità e risorse del cluster per i carichi di lavoro, riducendo al minimo l'onere operativo della gestione dei controller interni al cluster e di altri componenti della piattaforma.
Con EKS Capabilities, puoi gestire distribuzioni, AWS risorse Kubernetes personalizzate e composizioni utilizzando Kubernetes nativi e strumenti come. APIs `kubectl` Tutte le funzionalità operano nel contesto dei cluster, rilevando e correggendo automaticamente le variazioni di configurazione nelle risorse applicative e dell'infrastruttura cloud. È possibile distribuire e gestire le risorse su più cluster, AWS account e regioni da un unico punto di controllo, semplificando le operazioni in ambienti complessi e distribuiti.
Le funzionalità EKS sono progettate per i GitOps flussi di lavoro e forniscono infrastrutture dichiarative e con controllo della versione e una gestione delle applicazioni. Le modifiche fluiscono da Git attraverso il sistema, fornendo audit trail, funzionalità di rollback e flussi di lavoro di collaborazione che si integrano con le pratiche di sviluppo esistenti. Questo approccio nativo di Kubernetes significa che non è necessario utilizzare più strumenti o gestire infrastructure-as-code sistemi esterni ai cluster e che esiste un'unica fonte di verità a cui fare riferimento. Lo stato desiderato, definito nella configurazione dichiarativa di Kubernetes con controllo della versione, viene applicato continuamente in tutto l'ambiente.
## Prezzi
Con EKS Capabilities, non sono previsti impegni anticipati o commissioni minime. Ti viene addebitato un costo per ogni risorsa di capacità per ogni ora in cui è attiva sul tuo cluster Amazon EKS. Le risorse Kubernetes specifiche gestite da EKS Capabilities vengono inoltre fatturate su base oraria.
Per informazioni aggiornate sui prezzi, consulta la [pagina dei prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/).
**Suggerimento**
È possibile utilizzare AWS Cost Explorer e Cost and Usage Reports per tenere traccia dei costi delle funzionalità separatamente dagli altri addebiti EKS. È possibile etichettare le funzionalità con il nome del cluster, il tipo di funzionalità e altri dettagli ai fini dell'allocazione dei costi.
## Come funzionano le funzionalità EKS
Ogni funzionalità è una AWS risorsa che crei sul tuo cluster EKS. Una volta creata, la funzionalità viene eseguita in EKS ed è completamente gestita da AWS.
**Nota**
È possibile creare una risorsa di funzionalità di ogni tipo (Argo CD, ACK e kro) per un determinato cluster. Non è possibile creare risorse con funzionalità multiple dello stesso tipo sullo stesso cluster.
Interagisci con le funzionalità del tuo cluster utilizzando Kubernetes APIs e strumenti standard:
+ Utilizzalo per `kubectl` applicare risorse personalizzate Kubernetes
+ Usa gli archivi Git come fonte di verità per GitOps i flussi di lavoro
Alcune funzionalità supportano strumenti aggiuntivi. Esempio:
+ Usa la CLI di Argo CD per configurare e gestire repository e cluster con le funzionalità di Argo CD
+ Utilizzate l'interfaccia utente di Argo CD per visualizzare e gestire le applicazioni gestite dalla funzionalità Argo CD
Le funzionalità sono progettate per funzionare insieme, ma sono indipendenti e completamente attivabili. È possibile abilitare una, due o tutte e tre le funzionalità in base alle proprie esigenze e aggiornare la configurazione man mano che i requisiti evolvono.
Tutti i tipi di EKS Compute sono supportati per l'uso con EKS Capabilities. Per ulteriori informazioni, consulta [Gestire le risorse di elaborazione utilizzando i nodi](eks-compute.md).
Per la configurazione di sicurezza e i dettagli sui ruoli IAM, consulta[Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md). Per i modelli di architettura multi-cluster, vedi[Considerazioni sulle funzionalità EKS](capabilities-considerations.md).
## Casi di utilizzo comune
**GitOps per applicazioni e infrastruttura**
Usa Argo CD per distribuire applicazioni e componenti operativi e ACK per gestire le configurazioni dei cluster e fornire l'infrastruttura, entrambi dai repository Git. L'intero stack (applicazioni, database, storage e rete) è definito come codice e distribuito automaticamente.
Esempio: un team di sviluppo invia modifiche a Git. Argo CD distribuisce l'applicazione aggiornata e ACK fornisce un nuovo database RDS con la configurazione corretta. Tutte le modifiche sono verificabili, reversibili e coerenti in tutti gli ambienti.
**Progettazione della piattaforma con self-service**
Usa kro per creare risorse personalizzate APIs che compongono risorse ACK e Kubernetes. I team della piattaforma definiscono i modelli approvati con guardrail. I team addetti alle applicazioni utilizzano soluzioni semplici e di alto livello APIs per fornire stack completi.
Esempio: un team della piattaforma crea un'API "WebApplication" che fornisce un bucket Deployment, Service, Ingress e S3. Gli sviluppatori utilizzano questa API senza dover comprendere la complessità o le autorizzazioni sottostanti. AWS
**Gestione delle applicazioni multi-cluster**
Usa Argo CD per distribuire applicazioni su più cluster EKS in diverse regioni o account. Gestisci tutte le implementazioni da una singola istanza Argo CD con policy e flussi di lavoro coerenti.
Esempio: distribuisci la stessa applicazione in cluster di sviluppo, gestione temporanea e produzione in più regioni. Argo CD assicura che ogni ambiente rimanga sincronizzato con il ramo Git corrispondente.
**Gestione multi-cluster**
Usa ACK per definire e fornire i cluster EKS, kro per personalizzare le configurazioni dei cluster con standard organizzativi e Argo CD per gestire il ciclo di vita e la configurazione dei cluster. Ciò consente la gestione dei end-to-end cluster dalla creazione fino alle operazioni in corso.
Esempio: definire i cluster EKS utilizzando ACK e kro per fornire e gestire l'infrastruttura dei cluster, definire gli standard organizzativi per il networking, le politiche di sicurezza, i componenti aggiuntivi e altre configurazioni. Usa Argo CD per creare e gestire continuamente cluster, configurazioni e aggiornamenti delle versioni di Kubernetes in tutta la tua flotta sfruttando standard coerenti e la gestione automatizzata del ciclo di vita.
**Migrazioni e modernizzazione**
Semplifica la migrazione a EKS con il provisioning delle risorse cloud e i flussi di lavoro nativi. GitOps Usa ACK per adottare AWS le risorse esistenti senza ricrearle e Argo CD per rendere operative le distribuzioni dei carichi di lavoro da Git.
Esempio: un team che esegue la migrazione EC2 da EKS adotta i database RDS e i bucket S3 esistenti utilizzando ACK, quindi utilizza Argo CD per distribuire applicazioni containerizzate da Git. Il percorso di migrazione è chiaro e le operazioni sono standardizzate sin dal primo giorno.
**Account e Bootstrapping regionale**
Automatizza l'implementazione dell'infrastruttura tra account e regioni utilizzando insieme Argo CD e ACK. Definisci la tua infrastruttura come codice in Git e lascia che siano le funzionalità a gestire l'implementazione e la gestione.
Esempio: un team della piattaforma gestisce repository Git che definiscono configurazioni di account standard, ruoli IAMVPCs, istanze RDS e stack di monitoraggio. Argo CD implementa automaticamente queste configurazioni su nuovi account e regioni, garantendo la coerenza e riducendo i tempi di configurazione manuale da giorni a minuti.
# Lavorare con le risorse di capacità
Questo argomento descrive le operazioni comuni per la gestione delle risorse funzionali per tutti i tipi di capacità.
## Risorse di funzionalità EKS
Le funzionalità EKS sono AWS risorse che abilitano funzionalità gestite sul tuo cluster Amazon EKS. Le funzionalità vengono eseguite in EKS, eliminando la necessità di installare e gestire controller e altri componenti operativi sui nodi di lavoro. Le funzionalità vengono create per uno specifico cluster EKS e rimangono associate a quel cluster per l'intero ciclo di vita.
Ogni risorsa funzionale ha:
+ Un nome univoco all'interno del cluster
+ Un tipo di funzionalità (ACK, ARGOCD o KRO)
+ Un Amazon Resource Name (ARN), che specifica sia il nome che il tipo
+ Un ruolo IAM basato sulla capacità
+ Uno stato che indica il suo stato attuale
+ Configurazione, generica e specifica per il tipo di funzionalità
## Comprensione dello stato delle capacità
Le risorse di capacità hanno uno stato che indica il loro stato attuale. È possibile visualizzare lo stato e l'integrità delle funzionalità nella console EKS o utilizzando la AWS CLI.
**Console**:
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster.
1. Scegli la scheda **Capacità** per visualizzare lo stato di tutte le funzionalità.
1. Per informazioni dettagliate sullo stato di salute, scegli la scheda **Osservabilità**, quindi **Monitor cluster**, quindi la scheda **Capacità**.
** AWS CLI:**
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-capability-name
```
### Stati delle capacità
**CREAZIONE: La** funzionalità è in fase di configurazione. Puoi allontanarti dalla console: la funzionalità continuerà a creare in background.
**ATTIVA**: La funzionalità è attiva e pronta per l'uso. Se le risorse non funzionano come previsto, controlla lo stato delle risorse e le autorizzazioni IAM. Per ulteriori informazioni, consulta [Risoluzione dei problemi delle funzionalità EKS](capabilities-troubleshooting.md).
**AGGIORNAMENTO**: vengono applicate le modifiche alla configurazione. Attendi che lo stato ritorni a`ACTIVE`.
**ELIMINAZIONE**: la funzionalità viene rimossa dal cluster.
**CREATE\$1FAILED**: l'installazione ha rilevato un errore. Le cause più comuni includono:
+ La politica di fiducia dei ruoli IAM è errata o mancante
+ Il ruolo IAM non esiste o non è accessibile
+ Problemi di accesso al cluster
+ Parametri di configurazione non validi
Consulta la sezione relativa allo stato delle funzionalità per dettagli specifici sugli errori.
**UPDATE\$1FAILED: aggiornamento della configurazione non riuscito**. Controlla la sezione sullo stato delle funzionalità per i dettagli e verifica le autorizzazioni IAM.
**Suggerimento**
Per una guida dettagliata alla risoluzione dei problemi, consulta:
[Risoluzione dei problemi delle funzionalità EKS](capabilities-troubleshooting.md)- Risoluzione dei problemi generali relativi alle funzionalità
[Risolvi i problemi relativi alle funzionalità ACK](ack-troubleshooting.md)- Problemi specifici dell'ACK
[Risolvi i problemi relativi alle funzionalità di Argo CD](argocd-troubleshooting.md)- Problemi specifici di Argo CD
[Risolvi i problemi relativi alle funzionalità kro](kro-troubleshooting.md)- problemi specifici per kro
## Crea funzionalità
Per creare una funzionalità sul tuo cluster, consulta i seguenti argomenti:
+ [Crea una funzionalità ACK](create-ack-capability.md)— Crea una funzionalità ACK per gestire AWS le risorse utilizzando Kubernetes APIs
+ [Crea una funzionalità Argo CD](create-argocd-capability.md)— Crea una funzionalità Argo CD per la distribuzione continua GitOps
+ [Crea una funzionalità kro](create-kro-capability.md)— Crea una funzionalità kro per la composizione e l'orchestrazione delle risorse
## Elenca le funzionalità
È possibile elencare tutte le risorse funzionali presenti in un cluster.
### Console
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Funzionalità**.
1. Visualizza le risorse relative alle funzionalità in **Funzionalità gestite**.
### AWS CLI
Usa il `list-capabilities` comando per visualizzare tutte le funzionalità del tuo cluster. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.
```
aws eks list-capabilities \
--region region-code \
--cluster-name my-cluster
```
```
{
"capabilities": [
{
"capabilityName": "my-ack",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"type": "ACK",
"status": "ACTIVE",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-kro",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/kro/my-kro/abc123",
"type": "KRO",
"status": "ACTIVE",
"version": "v0.6.3",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-argocd",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/argocd/my-argocd/abc123",
"type": "ARGOCD",
"status": "ACTIVE",
"version": "3.1.8-eks-1",
"createdAt": "2025-11-21T08:22:28.486000-05:00",
"modifiedAt": "2025-11-21T08:22:28.486000-05:00"
}
]
}
```
## Descrivi una funzionalità
Ottieni informazioni dettagliate su una funzionalità specifica, inclusi la configurazione e lo stato.
### Console
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Funzionalità**.
1. Scegli la funzionalità che desideri visualizzare in **Funzionalità gestite**.
1. Visualizza i dettagli delle funzionalità, tra cui lo stato, la configurazione e l'ora di creazione.
### AWS CLI
Utilizzate il `describe-capability` comando per visualizzare informazioni dettagliate. Sostituisci *region-code* con la AWS regione in cui si trova il cluster, sostituisci *my-cluster* con il nome del cluster e sostituisci *capability-name* con il nome della funzionalità (ack, argocd o kro).
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
**Output di esempio:**
```
{
"capability": {
"capabilityName": "my-ack",
"capabilityArn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"clusterName": "my-cluster",
"type": "ACK",
"roleArn": "arn:aws:iam::111122223333:role/AmazonEKSCapabilityACKRole",
"status": "ACTIVE",
"configuration": {},
"tags": {},
"health": {
"issues": []
},
"createdAt": "2025-11-19T17:11:30.242000-05:00",
"modifiedAt": "2025-11-19T17:11:30.242000-05:00",
"deletePropagationPolicy": "RETAIN"
}
}
```
## Aggiorna la configurazione di una funzionalità
È possibile aggiornare alcuni aspetti della configurazione di una funzionalità dopo la creazione. Le opzioni di configurazione specifiche variano in base al tipo di funzionalità.
**Nota**
Le risorse di funzionalità EKS sono completamente gestite, comprese le patch e gli aggiornamenti delle versioni. L'aggiornamento di una funzionalità aggiornerà la configurazione delle risorse e non comporterà aggiornamenti di versione dei componenti delle funzionalità gestite.
### AWS CLI
Usa il `update-capability` comando per modificare una funzionalità:
```
aws eks update-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/NewCapabilityRole
```
**Nota**
Non tutte le proprietà delle funzionalità possono essere aggiornate dopo la creazione. Fate riferimento alla documentazione specifica sulle funzionalità per i dettagli su cosa è possibile modificare.
## Eliminare una funzionalità
Quando non è più necessaria una funzionalità nel cluster, è possibile eliminare la risorsa relativa alla capacità.
**Importante**
**Eliminare le risorse del cluster prima di eliminare la funzionalità.**
L'eliminazione di una risorsa di capacità non elimina automaticamente le risorse create tramite tale funzionalità:
Tutte le Kubernetes Custom Resource Definitions (CRDs) rimangono installate nel cluster.
Le risorse ACK rimangono nel cluster e le AWS risorse corrispondenti rimangono nel tuo account
Le applicazioni Argo CD e le relative risorse Kubernetes rimangono nel cluster
kro ResourceGraphDefinitions e le istanze rimangono nel cluster
È necessario eliminare queste risorse prima di eliminare la funzionalità per evitare risorse orfane.
Facoltativamente, puoi scegliere di conservare AWS le risorse associate alle risorse ACK Kubernetes. [Consulta](ack-considerations.md) le considerazioni su ACK
### Console
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Funzionalità**.
1. Seleziona la funzionalità che desideri eliminare dall'elenco delle **funzionalità gestite**.
1. Scegli la **funzionalità Elimina**.
1. Nella finestra di dialogo di conferma, digita il nome della funzionalità per confermare l'eliminazione.
1. Scegli **Elimina**.
### AWS CLI
Usa il `delete-capability` comando per eliminare una risorsa di funzionalità:
Sostituisci *region-code* con la AWS regione in cui si trova il cluster, sostituisci *my-cluster* con il nome del cluster e sostituisci *capability-name* con il nome della funzionalità da eliminare.
```
aws eks delete-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
## Fasi successive
+ [Capability: risorse Kubernetes](capability-kubernetes-resources.md)— Scopri le risorse Kubernetes fornite da ciascun tipo di funzionalità
+ [Concetti ACK](ack-concepts.md)— Comprendi i concetti e il ciclo di vita delle risorse di ACK
+ [Lavorare con Argo CD](working-with-argocd.md)— Utilizzo delle funzionalità di Argo CD per i flussi di lavoro GitOps
+ [concetti kro](kro-concepts.md)— Comprendi i concetti kro e la composizione delle risorse
# Capability: risorse Kubernetes
Dopo aver abilitato una funzionalità sul cluster, molto spesso interagirai con essa creando e gestendo risorse personalizzate Kubernetes nel cluster. Ogni funzionalità fornisce il proprio set di definizioni di risorse personalizzate (CRDs) che estendono l'API Kubernetes con funzionalità specifiche per funzionalità.
## Risorse Argo CD
Quando abiliti la funzionalità Argo CD, puoi creare e gestire le seguenti risorse Kubernetes:
**Applicazione**
Definisce una distribuzione da un repository Git a un cluster di destinazione. `Application`le risorse specificano il repository di origine, lo spazio dei nomi di destinazione e la politica di sincronizzazione. È possibile creare fino a 1000 `Application` risorse per istanza con funzionalità Argo CD.
**ApplicationSet**
Genera più `Application` risorse a partire da modelli, abilitando implementazioni multi-cluster e multiambiente. `ApplicationSet`le risorse utilizzano i generatori per creare `Application` risorse in modo dinamico sulla base di elenchi di cluster, directory Git o altre fonti.
**AppProject**
Fornisce il raggruppamento logico e il controllo degli accessi alle risorse. `Application` `AppProject`le risorse definiscono quali repository, cluster e namespace possono essere utilizzati dalle `Application` risorse, abilitando limiti di multi-tenancy e sicurezza.
`Application`Risorsa di esempio:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo
targetRevision: main
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: production
```
Per ulteriori informazioni sulle risorse e sui concetti di Argo CD, vedere[Concetti di Argo CD](argocd-concepts.md).
## risorse kro
Quando abiliti la funzionalità kro, puoi creare e gestire le seguenti risorse Kubernetes:
**ResourceGraphDefinition (RGD)**
Definisce un'API personalizzata che compone più Kubernetes e AWS risorse in un'astrazione di livello superiore. I team della piattaforma creano `ResourceGraphDefinition` risorse per fornire modelli riutilizzabili con guardrail.
**Istanze di risorse personalizzate**
Dopo aver creato una `ResourceGraphDefinition` risorsa, puoi creare istanze dell'API personalizzata definita da`ResourceGraphDefinition`. kro crea e gestisce automaticamente le risorse specificate in. `ResourceGraphDefinition`
Risorsa di esempio`ResourceGraphDefinition`:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
# ... deployment spec
- id: service
template:
apiVersion: v1
kind: Service
# ... service spec
```
Istanza di `WebApplication` esempio:
```
apiVersion: v1alpha1
kind: WebApplication
metadata:
name: my-web-app
namespace: default
spec:
name: my-web-app
replicas: 3
```
Quando applichi questa istanza, kro crea automaticamente `Service` le risorse `Deployment` e definite in. `ResourceGraphDefinition`
Per ulteriori informazioni sulle risorse e sui concetti di kro, consulta. [concetti kro](kro-concepts.md)
## Risorse ACK
Quando abiliti la funzionalità ACK, puoi creare e gestire AWS risorse utilizzando risorse personalizzate Kubernetes. ACK ne fornisce oltre 200 CRDs per più di 50 AWS servizi, consentendoti di definire AWS le risorse insieme ai carichi di lavoro Kubernetes e di gestire risorse di infrastruttura dedicate con Kubernetes. AWS
Esempi di risorse ACK:
**Bucket S3**
`Bucket`le risorse creano e gestiscono bucket Amazon S3 con politiche di controllo delle versioni, crittografia e ciclo di vita.
**RDS DBInstance**
`DBInstance`fornitura di risorse e gestione di istanze di database Amazon RDS con backup automatici e finestre di manutenzione.
**Tabella DynamoDB**
`Table`le risorse creano e gestiscono tabelle DynamoDB con capacità fornita o su richiesta.
**Ruolo IAM**
`Role`le risorse definiscono i ruoli IAM con policy di fiducia e policy di autorizzazione per l'accesso ai servizi. AWS
**Funzione Lambda**
`Function`le risorse creano e gestiscono funzioni Lambda con configurazione di codice, runtime e ruolo di esecuzione.
Esempio di specificazione di una `Bucket` risorsa:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-app-bucket
spec:
name: my-unique-bucket-name-12345
versioning:
status: Enabled
encryption:
rules:
- applyServerSideEncryptionByDefault:
sseAlgorithm: AES256
```
Per ulteriori informazioni sulle risorse e sui concetti di ACK, vedere[Concetti ACK](ack-concepts.md).
## Limiti delle risorse
Le funzionalità EKS hanno i seguenti limiti di risorse:
**Limiti di utilizzo di Argo CD**:
+ Massimo 1000 `Application` risorse per istanza con funzionalità Argo CD
+ Massimo 100 cluster remoti configurati per istanza con funzionalità Argo CD
Limiti di **configurazione delle risorse**:
+ Massimo 150 risorse Kubernetes per `Application` risorsa in Argo CD
+ Massimo 64 risorse Kubernetes per mese `ResourceGraphDefinition`
**Nota**
Questi limiti si applicano al numero di risorse gestite da ciascuna istanza di funzionalità. Se hai bisogno di limiti più elevati, puoi distribuire funzionalità su più cluster.
## Fasi successive
Per le attività specifiche relative alle funzionalità e la configurazione avanzata, consulta i seguenti argomenti:
+ [Concetti ACK](ack-concepts.md)— Comprendi i concetti e il ciclo di vita delle risorse di ACK
+ [Lavorare con Argo CD](working-with-argocd.md)— Utilizzo delle funzionalità di Argo CD per i flussi di lavoro GitOps
+ [concetti kro](kro-concepts.md)— Comprendi i concetti kro e la composizione delle risorse
# 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](capabilities-security.md)
## 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](https://aws.amazon.com/eks/pricing/).
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](ack-comparison.md)
+ [Confronto tra la funzionalità EKS per Argo CD e Argo CD autogestita](argocd-comparison.md)
+ [Confronto tra EKS Capability for kro e kro autogestito](kro-comparison.md)
# Implementa AWS risorse da Kubernetes con AWS Controllers for Kubernetes (ACK)
AWS Controllers for Kubernetes (ACK) ti consente di definire e gestire le risorse di servizio direttamente da Kubernetes. AWS Con AWS Controllers for Kubernetes (ACK), puoi gestire le risorse dei carichi di lavoro e l'infrastruttura cloud utilizzando le risorse personalizzate di Kubernetes, insieme ai carichi di lavoro delle applicazioni utilizzando Kubernetes e strumenti familiari. APIs
Con EKS Capabilities, ACK è completamente gestito da, eliminando la necessità di installare AWS, mantenere e scalare i controller ACK sui cluster.
## Come funziona ACK
ACK traduce le specifiche delle risorse personalizzate di Kubernetes in chiamate API. AWS Quando crei, aggiorni o elimini una risorsa personalizzata Kubernetes che rappresenta una risorsa di AWS servizio, ACK effettua le chiamate AWS API necessarie per creare, aggiornare o eliminare la risorsa. AWS
Ogni AWS risorsa supportata da ACK ha una propria definizione di risorsa personalizzata (CRD) che definisce lo schema dell'API Kubernetes per specificarne la configurazione. Ad esempio, ACK fornisce CRDs S3 tra cui bucket, bucket policy e altre risorse S3.
ACK riconcilia continuamente lo stato delle AWS risorse con lo stato desiderato definito nelle risorse personalizzate Kubernetes. Se una risorsa si discosta dallo stato desiderato, ACK lo rileva e intraprende azioni correttive per riportarla all'allineamento. Le modifiche alle risorse Kubernetes si riflettono immediatamente sullo stato della AWS risorsa, mentre il rilevamento passivo della deriva e la correzione delle modifiche alle AWS risorse a monte possono richiedere fino a 10 ore (il periodo di risincronizzazione), ma in genere avvengono molto prima.
**Esempio di manifesto delle risorse di S3 Bucket**
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-ack-bucket
spec:
name: my-unique-bucket-name
```
Quando applichi questa risorsa personalizzata al tuo cluster, ACK crea un bucket Amazon S3 nel tuo account se non esiste ancora. Le modifiche successive a questa risorsa, ad esempio la specificazione di un livello di storage non predefinito o l'aggiunta di una policy, verranno applicate alla risorsa S3 in. AWS Quando questa risorsa viene eliminata dal cluster, il bucket S3 in AWS viene eliminato per impostazione predefinita.
## Vantaggi di ACK
ACK offre la gestione AWS delle risorse nativa di Kubernetes, che consente di gestire AWS le risorse utilizzando gli stessi Kubernetes APIs e gli stessi strumenti utilizzati per le applicazioni. Questo approccio unificato semplifica il flusso di lavoro di gestione dell'infrastruttura eliminando la necessità di passare da uno strumento all'altro o di apprendere sistemi separati. infrastructure-as-code Definisci AWS le tue risorse in modo dichiarativo nei manifesti di Kubernetes, abilitando i GitOps flussi di lavoro e l'infrastruttura come pratiche di codice che si integrano perfettamente con i processi di sviluppo esistenti.
ACK riconcilia continuamente lo stato desiderato delle AWS risorse con il loro stato effettivo, correggendo le deviazioni e garantendo la coerenza nell'intera infrastruttura. Questa riconciliazione continua significa che le out-of-band modifiche imperative alle AWS risorse vengono ripristinate automaticamente in modo che corrispondano alla configurazione dichiarata, mantenendo l'integrità dell'infrastruttura sotto forma di codice. È possibile configurare ACK per gestire le risorse su più AWS account e regioni, abilitando architetture multi-account complesse senza strumenti aggiuntivi.
Per le organizzazioni che migrano da altri strumenti di gestione dell'infrastruttura, ACK supporta l'adozione delle risorse, permettendo di affidare AWS le risorse esistenti alla gestione ACK senza doverle ricreare. ACK fornisce anche risorse di sola lettura per l'osservazione AWS delle risorse senza accesso alle modifiche e annotazioni per conservare facoltativamente le AWS risorse anche quando la risorsa Kubernetes viene eliminata dal cluster.
Per saperne di più e iniziare a usare EKS Capability for ACK, consulta e. [Concetti ACK](ack-concepts.md) [Considerazioni ACK per EKS](ack-considerations.md)
## AWS Servizi supportati
ACK supporta un'ampia gamma di AWS servizi, tra cui, a titolo esemplificativo ma non esaustivo:
+ Amazon EC2
+ Simple Storage Service (Amazon S3)
+ Amazon RDS
+ Amazon DynamoDB
+ Amazon ElastiCache
+ Amazon EKS
+ Amazon SQS
+ Amazon SNS
+ AWS Lambda
+ AWS IAM
Tutti i AWS servizi elencati come Generally Available upstream sono supportati da EKS Capability for ACK. Per ulteriori informazioni, consulta l'[elenco completo dei AWS servizi supportati](https://aws-controllers-k8s.github.io/community/docs/community/services/).
## Integrazione con altre funzionalità gestite da EKS
ACK si integra con altre funzionalità gestite da EKS.
+ **Argo CD**: utilizza Argo CD per gestire l'implementazione delle risorse ACK su più cluster, abilitando i flussi di GitOps lavoro per la tua infrastruttura. AWS
+ ACK estende i vantaggi dell' GitOps abbinamento con ArgoCD, ma ACK non richiede l'integrazione con git.
+ **kro (Kube Resource Orchestrator)**: Usa kro per comporre risorse complesse a partire da risorse ACK, creando astrazioni di livello superiore che semplificano la gestione delle risorse.
+ Puoi creare risorse composite personalizzate con kro che definiscono sia le risorse che le risorse Kubernetes. AWS I membri del team possono utilizzare queste risorse personalizzate per distribuire rapidamente applicazioni complesse.
## Guida introduttiva a ACK
Per iniziare a usare EKS Capability for ACK:
1. Crea e configura un ruolo di capacità IAM con le autorizzazioni necessarie affinché ACK gestisca AWS le risorse per tuo conto.
1. [Crea una risorsa con funzionalità ACK](create-ack-capability.md) sul tuo cluster EKS tramite la AWS console, la AWS CLI o la tua infrastruttura preferita come strumento di codice.
1. Applica le risorse personalizzate Kubernetes al tuo cluster per iniziare a gestire le tue risorse in Kubernetes. AWS
# Crea una funzionalità ACK
Questo capitolo spiega come creare una funzionalità ACK sul tuo cluster Amazon EKS.
## Prerequisiti
Prima di creare una funzionalità ACK, assicurati di avere:
+ Cluster Amazon EKS
+ Un ruolo di capacità IAM con autorizzazioni per ACK per gestire le AWS risorse
+ Autorizzazioni IAM sufficienti per creare risorse di funzionalità sui cluster EKS
+ Lo strumento CLI appropriato installato e configurato o l'accesso alla console EKS
Per istruzioni sulla creazione dello IAM Capability Role, consulta[Funzionalità Amazon EKS, ruolo IAM](capability-role.md).
**Importante**
ACK è una funzionalità di gestione dell'infrastruttura che consente di creare, modificare ed eliminare AWS risorse. Si tratta di una funzionalità amministrativa che deve essere controllata con attenzione. Chiunque sia autorizzato a creare risorse Kubernetes nel tuo cluster può creare risorse in modo efficace tramite ACK, fatte salve AWS le autorizzazioni IAM Capability Role. Il ruolo IAM Capability che fornisci determina quali AWS risorse ACK può creare e gestire. Per indicazioni sulla creazione di un ruolo appropriato con autorizzazioni con privilegi minimi, consulta e. [Funzionalità Amazon EKS, ruolo IAM](capability-role.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
## Scegli il tuo strumento
È possibile creare una funzionalità ACK utilizzando Console di gestione AWS, AWS CLI o eksctl:
+ [Creare una funzionalità ACK utilizzando la console](ack-create-console.md)- Usa la console per un'esperienza guidata
+ [Crea una funzionalità ACK utilizzando la AWS CLI](ack-create-cli.md)- Usa la AWS CLI per lo scripting e l'automazione
+ [Crea una funzionalità ACK usando eksctl](ack-create-eksctl.md)- Usa eksctl per un'esperienza nativa di Kubernetes
## Cosa succede quando si crea una funzionalità ACK
Quando crei una funzionalità ACK:
1. EKS crea il servizio di funzionalità ACK e lo configura per monitorare e gestire le risorse nel cluster
1. Le definizioni di risorse personalizzate (CRDs) sono installate nel cluster
1. Viene creata automaticamente una voce di accesso per il tuo IAM Capability Role con policy di accesso specifiche per ciascuna funzionalità che concedono le autorizzazioni Kubernetes di base (vedi) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
1. La funzionalità presuppone lo IAM Capability Role fornito dall'utente
1. ACK inizia a controllare le proprie risorse personalizzate nel cluster
1. Lo stato della capacità cambia da `CREATING` a `ACTIVE`
Una volta attivo, è possibile creare risorse ACK personalizzate nel cluster per gestire AWS le risorse.
**Nota**
La voce di accesso creata automaticamente include la voce `AmazonEKSACKPolicy` che concede le autorizzazioni ACK per la gestione AWS delle risorse. Alcune risorse ACK che fanno riferimento ai segreti di Kubernetes (come i database RDS con password) richiedono politiche di accesso aggiuntive. Per ulteriori informazioni sulle voci di accesso e su come configurare autorizzazioni aggiuntive, consulta. [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
## Fasi successive
Dopo aver creato la funzionalità ACK:
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e inizia a usare le AWS risorse
+ [Concetti ACK](ack-concepts.md)- Scopri la riconciliazione, le esportazioni sul campo e i modelli di adozione delle risorse
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM e i modelli multi-account
# Creare una funzionalità ACK utilizzando la console
Questo argomento descrive come creare una funzionalità AWS Controllers for Kubernetes (ACK) utilizzando. Console di gestione AWS
## Crea la funzionalità ACK
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Funzionalità**.
1. Nella barra di navigazione a sinistra, scegli ** AWS Controllers for Kubernetes** (ACK).
1. Scegli la funzionalità **Crea AWS controller per Kubernetes**.
1. **Per IAM Capability Role:**
+ Se disponi già di un IAM Capability Role, selezionalo dal menu a discesa
+ Se devi creare un ruolo, scegli **Crea ruolo di amministratore**
Questo apre la console IAM in una nuova scheda con la policy di fiducia precompilata e la policy `AdministratorAccess` gestita. Se preferisci, puoi deselezionare questa policy e aggiungere altre autorizzazioni.
Dopo aver creato il ruolo, torna alla console EKS e il ruolo verrà selezionato automaticamente.
**Importante**
La `AdministratorAccess` politica suggerita concede ampie autorizzazioni e ha lo scopo di semplificare l'avvio. Per uso in produzione, sostituiscila con una politica personalizzata che conceda solo le autorizzazioni necessarie per i AWS servizi specifici che intendi gestire con ACK. Per indicazioni sulla creazione di politiche con privilegi minimi, consulta e. [Configurare le autorizzazioni ACK](ack-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
1. Scegli **Create** (Crea).
Inizia il processo di creazione delle capacità.
## Verifica che la funzionalità sia attiva
1. Nella scheda **Funzionalità**, visualizza lo stato della capacità ACK.
1. Attendi che lo stato cambi da `CREATING` a`ACTIVE`.
1. Una volta attiva, la funzionalità è pronta per l'uso.
Per informazioni sullo stato delle funzionalità e sulla risoluzione dei problemi, vedere[Lavorare con le risorse di capacità](working-with-capabilities.md).
## Verifica che siano disponibili risorse personalizzate
Dopo che la funzionalità è attiva, verifica che le risorse personalizzate ACK siano disponibili nel cluster.
**Utilizzo della console**
1. Accedi al tuo cluster nella console Amazon EKS
1. Scegli la scheda **Risorse**
1. Scegli **Estensioni**
1. Scegliere **CustomResourceDefinitions**
Dovresti vedere una serie di AWS risorse CRDs elencate.
**Usare kubectl**
```
kubectl api-resources | grep services.k8s.aws
```
Dovresti vedere un certo numero di risorse APIs elencate. AWS
**Nota**
La funzionalità di AWS Controllers for Kubernetes installerà una serie di risorse CRDs per una varietà di risorse. AWS
## Fasi successive
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e inizia
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM per altri servizi AWS
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa di funzionalità ACK
# Crea una funzionalità ACK utilizzando la AWS CLI
Questo argomento descrive come creare una funzionalità AWS Controllers for Kubernetes (ACK) utilizzando la CLI. AWS
## Prerequisiti
+ ** AWS CLI**: versione `2.12.3` o successiva. Per verificare la tua versione, `aws --version` esegui. Per ulteriori informazioni, consulta la Guida per l'utente all'[installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nell'interfaccia a riga di AWS comando.
+ **`kubectl`**— Uno strumento da riga di comando per lavorare con i cluster Kubernetes. Per ulteriori informazioni, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md).
## Fase 1: creazione di un ruolo IAM Capability
Crea un file di policy di fiducia:
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crea il ruolo IAM:
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Allega la policy `AdministratorAccess` gestita al ruolo:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**Importante**
La `AdministratorAccess` politica suggerita concede ampie autorizzazioni e ha lo scopo di semplificare l'avvio. Per uso in produzione, sostituiscila con una politica personalizzata che conceda solo le autorizzazioni necessarie per i AWS servizi specifici che intendi gestire con ACK. Per indicazioni sulla creazione di politiche con privilegi minimi, consulta e. [Configurare le autorizzazioni ACK](ack-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
## Fase 2: Creare la funzionalità ACK
Crea la risorsa di funzionalità ACK sul tuo cluster. Sostituiscila *region-code* con la AWS regione in cui si trova il cluster e sostituiscila *my-cluster* con il nome del cluster.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--delete-propagation-policy RETAIN
```
Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva poiché EKS crea l'infrastruttura e i componenti di funzionalità richiesti. EKS installerà le Kubernetes Custom Resource Definitions relative a questa funzionalità nel cluster non appena viene creata.
**Nota**
Se ricevi un errore che indica che il cluster non esiste o non disponi delle autorizzazioni, verifica:
Il nome del cluster è corretto
La tua AWS CLI è configurata per la regione corretta
Disponi delle autorizzazioni IAM richieste
## Fase 3: Verifica che la funzionalità sia attiva
Attendi che la funzionalità diventi attiva. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--query 'capability.status' \
--output text
```
La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`. Non continuare con il passaggio successivo fino a quando lo stato non sarà raggiunto`ACTIVE`.
Puoi anche visualizzare i dettagli completi delle funzionalità:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
```
## Fase 4: Verifica della disponibilità di risorse personalizzate
Dopo che la funzionalità è attiva, verifica che le risorse personalizzate ACK siano disponibili nel cluster:
```
kubectl api-resources | grep services.k8s.aws
```
Dovresti vedere un certo numero di AWS risorse APIs elencate.
**Nota**
La funzionalità di AWS Controllers for Kubernetes installerà una serie di risorse CRDs per una varietà di risorse. AWS
## Fasi successive
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e inizia
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM per altri servizi AWS
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa di funzionalità ACK
# Crea una funzionalità ACK usando eksctl
Questo argomento descrive come creare una funzionalità AWS Controllers for Kubernetes (ACK) usando eksctl.
**Nota**
I passaggi seguenti richiedono la versione eksctl o successiva. `0.220.0` Per verificare la tua versione, esegui. `eksctl version`
## Fase 1: Creare un ruolo di capacità IAM
Crea un file di policy di fiducia:
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crea il ruolo IAM:
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Allega la policy `AdministratorAccess` gestita al ruolo:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**Importante**
La `AdministratorAccess` politica suggerita concede ampie autorizzazioni e ha lo scopo di semplificare l'avvio. Per uso in produzione, sostituiscila con una politica personalizzata che conceda solo le autorizzazioni necessarie per i AWS servizi specifici che intendi gestire con ACK. Per indicazioni sulla creazione di politiche con privilegi minimi, consulta e. [Configurare le autorizzazioni ACK](ack-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
**Importante**
Questa politica concede le autorizzazioni per la gestione dei bucket S3 con`"Resource": "*"`, che consente le operazioni su tutti i bucket S3.
Per uso in produzione: \$1 Limita il `Resource` campo a bucket ARNs o modelli di nomi specifici \$1 Usa le chiavi di condizione IAM per limitare l'accesso tramite tag di risorsa \$1 Concedi solo le autorizzazioni minime necessarie per il tuo caso d'uso
Per altri AWS servizi, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
Collegare la policy al ruolo:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ACKS3Policy
```
## Fase 2: Creare la funzionalità ACK
Crea la funzionalità ACK usando eksctl. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e *my-cluster* sostituiscilo con il nome del cluster.
```
eksctl create capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--ack-service-controllers s3
```
**Nota**
La `--ack-service-controllers` bandiera è facoltativa. Se omesso, ACK abilita tutti i controller disponibili. Per prestazioni e sicurezza migliori, valuta la possibilità di abilitare solo i controller di cui hai bisogno. Puoi specificare più controller: `--ack-service-controllers s3,rds,dynamodb`
Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva.
## Fase 3: Verificare che la funzionalità sia attiva
Verifica lo stato della capacità:
```
eksctl get capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack
```
La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`.
## Fase 4: Verifica della disponibilità di risorse personalizzate
Dopo che la funzionalità è attiva, verifica che le risorse personalizzate ACK siano disponibili nel cluster:
```
kubectl api-resources | grep services.k8s.aws
```
Dovresti vedere un certo numero di AWS risorse APIs elencate.
**Nota**
La funzionalità di AWS Controllers for Kubernetes installerà una serie di risorse CRDs per una varietà di risorse. AWS
## Fasi successive
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e inizia
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM per altri servizi AWS
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa di funzionalità ACK
# Concetti ACK
ACK gestisce AWS le risorse tramite Kubernetes APIs riconciliando continuamente lo stato desiderato nei manifesti con lo stato effettivo in cui si trovano. AWS Quando crei o aggiorni una risorsa personalizzata Kubernetes, ACK effettua le chiamate AWS API necessarie per creare o modificare la AWS risorsa corrispondente, quindi la monitora per rilevare eventuali variazioni e aggiorna lo stato di Kubernetes in modo che rifletta lo stato corrente. Questo approccio consente di gestire l'infrastruttura utilizzando strumenti e flussi di lavoro Kubernetes familiari, mantenendo al contempo la coerenza tra il cluster e. AWS
Questo argomento spiega i concetti fondamentali alla base del modo in cui ACK gestisce AWS le risorse tramite Kubernetes. APIs
## Guida introduttiva a ACK
Dopo aver creato la funzionalità ACK (vedi[Crea una funzionalità ACK](create-ack-capability.md)), puoi iniziare a gestire AWS le risorse utilizzando i manifest Kubernetes nel tuo cluster.
Ad esempio, crea questo manifesto del bucket S3 in, scegliendo il tuo nome di bucket `bucket.yaml` univoco.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-test-bucket
namespace: default
spec:
name: my-unique-bucket-name-12345
```
Applica il manifesto:
```
kubectl apply -f bucket.yaml
```
Controlla lo stato:
```
kubectl get bucket my-test-bucket
kubectl describe bucket my-test-bucket
```
Verifica che il bucket sia stato creato in AWS:
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Elimina la risorsa Kubernetes:
```
kubectl delete bucket my-test-bucket
```
Verifica che il bucket sia stato eliminato da: AWS
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Il bucket non dovrebbe più apparire nell'elenco, a dimostrazione del fatto che ACK gestisce l'intero ciclo di vita delle risorse. AWS
Per ulteriori informazioni su come iniziare a usare ACK, consulta [Getting](https://aws-controllers-k8s.github.io/community/docs/user-docs/getting-started/) Started with ACK.
## Ciclo di vita delle risorse e riconciliazione
ACK utilizza un ciclo di riconciliazione continuo per garantire che le AWS risorse corrispondano allo stato desiderato definito nei manifesti di Kubernetes.
**Come funziona la riconciliazione:**
1. Crei o aggiorni una risorsa personalizzata Kubernetes (ad esempio, un bucket S3)
1. ACK rileva la modifica e confronta lo stato desiderato con lo stato effettivo in AWS
1. Se sono diversi, ACK effettua chiamate AWS API per riconciliare la differenza
1. ACK aggiorna lo stato delle risorse in Kubernetes in modo che rifletta lo stato corrente
1. Il ciclo si ripete continuamente, in genere ogni poche ore
La riconciliazione viene attivata quando si crea una nuova risorsa Kubernetes, si aggiorna una risorsa esistente o quando ACK rileva una deviazione `spec` dovuta a modifiche manuali apportate all'esterno di ACK. AWS Inoltre, ACK esegue una riconciliazione periodica con un periodo di risincronizzazione di 10 ore. Le modifiche alle risorse Kubernetes innescano la riconciliazione immediata, mentre il rilevamento passivo della deriva delle modifiche alle risorse upstream avviene durante la risincronizzazione periodica. AWS
Quando si esegue l'esempio introduttivo riportato sopra, ACK esegue questi passaggi:
1. Controlla se il bucket esiste in AWS
1. In caso contrario, chiama `s3:CreateBucket`
1. Aggiorna lo stato di Kubernetes con l'ARN e lo stato del bucket
1. Continua il monitoraggio della deriva
Per saperne di più su come funziona ACK, consulta ACK [Reconciliation](https://aws-controllers-k8s.github.io/community/docs/user-docs/reconciliation/).
## Condizioni di status
Le risorse ACK utilizzano le condizioni di stato per comunicare il proprio stato. La comprensione di queste condizioni consente di risolvere i problemi e comprendere lo stato delle risorse.
+ **Pronta**: indica che la risorsa è pronta per essere consumata (condizione Kubernetes standardizzata).
+ **ACK. ResourceSynced**: Indica che le specifiche della risorsa corrispondono allo stato della AWS risorsa.
+ **ack.Terminal**: indica che si è verificato un errore irreversibile.
+ **ACK.Adopted**: indica che la risorsa è stata adottata da una risorsa esistente anziché creata nuova. AWS
+ **ACK.Recoverable: indica un errore recuperabile** che può essere risolto senza aggiornare le specifiche.
+ **ACK.advisory: fornisce informazioni consultive sulla risorsa.**
+ **ACK. LateInitialized**: Indica se l'inizializzazione tardiva dei campi è completa.
+ **ACK. ReferencesResolved**: Indica se tutti `AWSResourceReference` i campi sono stati risolti.
+ **ACK. IAMRoleSelezionato**: indica se è stato selezionato un IAMRole selettore per gestire questa risorsa.
Verifica lo stato della risorsa:
```
# Check if resource is ready
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Check for terminal errors
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="ACK.Terminal")]}'
```
Esempio di stato:
```
status:
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.ResourceSynced
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.Terminal
status: "True"
ackResourceMetadata:
arn: arn:aws:s3:::my-unique-bucket-name
ownerAccountID: "111122223333"
region: us-west-2
```
Per ulteriori informazioni sullo stato e le condizioni ACK, consulta [le Condizioni ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/conditions/).
## Politiche di cancellazione
La politica di eliminazione di ACK controlla cosa succede alle AWS risorse quando elimini la risorsa Kubernetes.
**Elimina (impostazione predefinita)**
La AWS risorsa viene eliminata quando elimini la risorsa Kubernetes: questo è il comportamento predefinito.
```
# No annotation needed - this is the default
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: temp-bucket
spec:
name: temporary-bucket
```
L'eliminazione di questa risorsa elimina il bucket S3. AWS
**Mantenimento**
La AWS risorsa viene conservata quando elimini la risorsa Kubernetes:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: important-bucket
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
name: production-data-bucket
```
L'eliminazione di questa risorsa la rimuove da Kubernetes ma lascia il bucket S3 attivo. AWS
La `retain` policy è utile per i database di produzione che dovrebbero durare più a lungo della risorsa Kubernetes, per le risorse condivise utilizzate da più applicazioni, per le risorse con dati importanti che non devono essere eliminati accidentalmente o per la gestione temporanea di ACK in cui si adotta una risorsa, la si configura e poi la si rimette alla gestione manuale.
[Per ulteriori informazioni sulla politica di eliminazione ACK, consulta ACK Deletion Policy.](https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/)
## Adozione delle risorse
L'adozione consente di affidare AWS le risorse esistenti alla gestione ACK senza doverle ricreare.
Quando usare l'adozione:
+ Migrazione dell'infrastruttura esistente alla gestione ACK
+ Ripristino di risorse orfane in caso di eliminazione accidentale di AWS risorse in Kubernetes
+ Importazione di risorse create da altri strumenti (, Terraform) CloudFormation
Come funziona l'adozione:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Quando crei questa risorsa:
1. ACK verifica se esiste un bucket con quel nome in AWS
1. Se trovato, ACK lo adotta (nessuna chiamata API da creare)
1. ACK legge la configurazione corrente da AWS
1. ACK aggiorna lo stato di Kubernetes in modo che rifletta lo stato effettivo
1. Gli aggiornamenti futuri riconciliano normalmente la risorsa
Una volta adottate, le risorse vengono gestite come qualsiasi altra risorsa ACK e l'eliminazione della risorsa Kubernetes comporterà l'eliminazione della risorsa, a meno che non si utilizzi la politica AWS di eliminazione. `retain`
Quando si adottano risorse, la AWS risorsa deve già esistere e ACK necessita delle autorizzazioni di lettura per scoprirla. La `adopt-or-create` politica adotta la risorsa se esiste o la crea se non esiste. Ciò è utile quando si desidera un flusso di lavoro dichiarativo che funzioni indipendentemente dall'esistenza o meno della risorsa.
Per ulteriori informazioni sull'adozione delle risorse ACK, consulta [ACK Resource Adoption](https://aws-controllers-k8s.github.io/community/docs/user-docs/adopted-resource/).
## Risorse tra account e regioni
ACK può gestire le risorse in diversi AWS account e regioni da un singolo cluster.
**Annotazioni di risorse interregionali**
È possibile specificare la regione di una AWS risorsa utilizzando un'annotazione:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: eu-bucket
annotations:
services.k8s.aws/region: eu-west-1
spec:
name: my-eu-bucket
```
Puoi anche specificare la regione di tutte le AWS risorse create in un determinato namespace:
**Annotazioni dello spazio dei nomi**
Imposta una regione predefinita per tutte le risorse in un namespace:
```
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
services.k8s.aws/default-region: us-west-2
```
Le risorse create in questo namespace utilizzano questa regione a meno che non vengano sovrascritte da un'annotazione a livello di risorsa.
**Più account**
Usa IAM Role Selectors per mappare ruoli IAM specifici ai namespace:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: target-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
Le risorse create nello spazio dei nomi mappato utilizzano automaticamente il ruolo specificato.
Per ulteriori informazioni sugli IAM Role Selectors, consulta [ACK](https://aws-controllers-k8s.github.io/docs/guides/cross-account) Cross-Account Resource Management. Per i dettagli sulla configurazione tra account, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
## Gestione degli errori e comportamento dei nuovi tentativi
ACK gestisce automaticamente gli errori transitori e riprova le operazioni non riuscite.
Strategia di riprova:
+ Gli errori transitori (limitazione della velocità, problemi temporanei di servizio, autorizzazioni insufficienti) attivano nuovi tentativi automatici
+ Il backoff esponenziale impedisce il sovraccarico AWS APIs
+ Il numero massimo di tentativi di riprova varia in base al tipo di errore
+ Gli errori permanenti (parametri non validi, conflitti tra nomi di risorse) non riprovano
Controlla lo stato delle risorse per i dettagli degli errori utilizzando: `kubectl describe`
```
kubectl describe bucket my-bucket
```
Cerca le condizioni di stato con messaggi di errore, gli eventi che mostrano i recenti tentativi di riconciliazione e il `message` campo nelle condizioni di stato che spiegano gli errori. Gli errori più comuni includono autorizzazioni IAM insufficienti, conflitti tra i nomi delle risorse, valori di configurazione non validi nelle AWS quote di servizio e il `spec` superamento delle quote di servizio. AWS
Per la risoluzione degli errori più comuni, consulta. [Risolvi i problemi relativi alle funzionalità ACK](ack-troubleshooting.md)
## Composizione delle risorse con kro
Per comporre e connettere più risorse ACK insieme, usa EKS Capability for kro (Kube Resource Orchestrator). kro fornisce un modo dichiarativo per definire gruppi di risorse, passando la configurazione tra le risorse per gestire semplicemente modelli di infrastruttura complessi.
Per esempi dettagliati di creazione di composizioni di risorse personalizzate con risorse ACK, vedi [concetti kro](kro-concepts.md)
## Fasi successive
+ [Considerazioni ACK per EKS](ack-considerations.md)- Modelli e strategie di integrazione specifici per EKS
# Configurare le autorizzazioni ACK
ACK richiede le autorizzazioni IAM per creare e gestire AWS risorse per tuo conto. Questo argomento spiega come IAM collabora con ACK e fornisce indicazioni sulla configurazione delle autorizzazioni per diversi casi d'uso.
## Come funziona IAM con ACK
ACK utilizza i ruoli IAM per autenticarsi con le tue risorse AWS ed eseguire azioni sulle tue risorse. Esistono due modi per fornire le autorizzazioni a ACK:
**Ruolo di capacità**: il ruolo IAM fornito durante la creazione della funzionalità ACK. Questo ruolo viene utilizzato di default per tutte le operazioni ACK.
**Selettori di ruolo IAM**: ruoli IAM aggiuntivi che possono essere mappati su namespace o risorse specifici. Questi ruoli hanno la precedenza sul ruolo di capacità per le risorse che rientrano nel loro ambito.
Quando ACK deve creare o gestire una risorsa, determina quale ruolo IAM utilizzare:
1. Controlla se un IAMRole selettore corrisponde allo spazio dei nomi della risorsa
1. Se viene trovata una corrispondenza, assumi quel ruolo IAM
1. Altrimenti, usa il ruolo Capability
Questo approccio consente una gestione flessibile delle autorizzazioni, da semplici configurazioni a ruolo singolo a configurazioni complesse con più account e più team.
## Guida introduttiva: configurazione semplice delle autorizzazioni
Per casi di sviluppo, test o semplici casi d'uso, puoi aggiungere tutte le autorizzazioni di servizio necessarie direttamente al Capability Role.
Questo approccio funziona bene quando:
+ Stai iniziando con ACK
+ Tutte le risorse si trovano nello stesso AWS account
+ Un unico team gestisce tutte le risorse ACK
+ Ti fidi che tutti gli utenti ACK abbiano le stesse autorizzazioni
## Best practice di produzione: IAM Role Selectors
Per gli ambienti di produzione, utilizza IAM Role Selectors per implementare l'accesso con privilegi minimi e l'isolamento a livello di namespace.
Quando si utilizza IAM Role Selectors, il Capability Role necessita solo delle autorizzazioni per assumere i ruoli specifici del servizio. `sts:AssumeRole` `sts:TagSession` Non è necessario aggiungere alcuna autorizzazione di AWS servizio (come S3 o RDS) al Capability Role stesso: tali autorizzazioni vengono concesse ai singoli ruoli IAM assunti dal Capability Role.
**Scelta tra modelli di autorizzazione:**
Utilizza **le autorizzazioni dirette** (aggiungendo le autorizzazioni di servizio al ruolo Capability) quando:
+ Stai iniziando e desideri la configurazione più semplice
+ Tutte le risorse si trovano nello stesso account del cluster
+ Hai requisiti di autorizzazione amministrativi a livello di cluster
+ Tutti i team possono condividere le stesse autorizzazioni
Usa **IAM Role Selectors quando**:
+ Gestione delle risorse su più account AWS
+ Team o namespace diversi richiedono autorizzazioni diverse
+ È necessario un controllo granulare degli accessi per namespace
+ Vuoi seguire le pratiche di sicurezza con privilegi minimi
Puoi iniziare con autorizzazioni dirette e migrare a IAM Role Selectors in un secondo momento, man mano che le tue esigenze crescono.
**Perché utilizzare IAM Role Selectors in produzione:**
+ **Privilegio minimo**: ogni namespace ottiene solo le autorizzazioni di cui ha bisogno
+ **Isolamento del team**: il team A non può utilizzare accidentalmente le autorizzazioni del team B
+ **Controllo più semplice**: mappatura chiara di quale namespace utilizza quale ruolo
+ **Supporto per più account**: necessario per la gestione delle risorse in più account
+ **Separazione delle preoccupazioni**: servizi o ambienti diversi utilizzano ruoli diversi
### Configurazione di base di IAM Role Selector
**Fase 1: Creare un ruolo IAM specifico per il servizio**
Crea un ruolo IAM con autorizzazioni per servizi specifici: AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
```
Configura la policy di fiducia per consentire al Capability Role di assumerla:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
**Fase 2: concedere AssumeRole l'autorizzazione a Capability Role**
Aggiungi l'autorizzazione al ruolo di capacità per assumere il ruolo specifico del servizio:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
}
]
}
```
**Fase 3: Creare un selettore IAMRole**
Mappa il ruolo IAM su un namespace:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: s3-namespace-config
spec:
arn: arn:aws:iam::111122223333:role/ACK-S3-Role
namespaceSelector:
names:
- s3-resources
```
**Fase 4: Creare risorse nello spazio dei nomi mappato**
Le risorse nello spazio dei `s3-resources` nomi utilizzano automaticamente il ruolo specificato:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: s3-resources
spec:
name: my-production-bucket
```
## Gestione di più account
Usa IAM Role Selectors per gestire le risorse su più AWS account.
**Fase 1: Creare un ruolo IAM per più account**
Nell'account di destinazione (444455556666), crea un ruolo che si fidi del ruolo di capacità dell'account di origine:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
Assegna autorizzazioni specifiche del servizio a questo ruolo.
**Passaggio 2: concedere l'autorizzazione AssumeRole **
Nell'account di origine (111122223333), consenti al ruolo Capability di assumere il ruolo dell'account di destinazione:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
}
]
}
```
**Fase 3: Creare un selettore IAMRole**
Mappa il ruolo tra account diversi su un namespace:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: production-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
**Fase 4: Creare risorse**
Le risorse nel `production` namespace vengono create nell'account di destinazione:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: production
spec:
name: my-cross-account-bucket
```
## Tag di sessione
La funzionalità EKS ACK imposta automaticamente i tag di sessione su tutte le richieste AWS API. Questi tag consentono il controllo e la verifica granulari degli accessi identificando l'origine di ogni richiesta.
### Tag di sessione disponibili
I seguenti tag di sessione sono inclusi in ogni chiamata AWS API effettuata da ACK:
| Chiave del tag | Description |
| --- | --- |
| `eks:eks-capability-arn` | L'ARN della capacità EKS che effettua la richiesta |
| `eks:kubernetes-namespace` | Lo spazio dei nomi Kubernetes della risorsa gestita |
| `eks:kubernetes-api-group` | Il gruppo di API Kubernetes della risorsa (ad esempio,) `s3.services.k8s.aws` |
### Utilizzo dei tag di sessione per il controllo degli accessi
Puoi utilizzare questi tag di sessione nelle condizioni delle policy IAM per limitare le risorse che ACK può gestire. Ciò fornisce un ulteriore livello di sicurezza oltre ai selettori di ruolo IAM basati su namespace.
**Esempio: limita in base allo spazio dei nomi**
Consenti a ACK di creare bucket S3 solo quando la richiesta proviene dal namespace: `production`
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:kubernetes-namespace": "production"
}
}
}
]
}
```
**Esempio: limita per capacità**
Consenti azioni solo da una funzionalità ACK specifica:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
}
}
}
]
}
```
**Nota**
I tag di sessione sono diversi da ACK autogestiti, che non imposta questi tag per impostazione predefinita. Ciò consente un controllo degli accessi più granulare con la funzionalità gestita.
## Modelli avanzati di IAM Role Selector
[Per una configurazione avanzata che include selettori di etichette, mappatura dei ruoli specifici delle risorse ed esempi aggiuntivi, consulta la documentazione ACK IRSA.](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/)
## Fasi successive
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti e il ciclo di vita delle risorse di ACK
+ [Concetti ACK](ack-concepts.md)- Scopri le politiche di adozione ed eliminazione delle risorse
+ [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)- Comprendi le migliori pratiche di sicurezza per quanto riguarda le funzionalità
# Considerazioni ACK per EKS
Questo argomento tratta importanti considerazioni sull'utilizzo di EKS Capability for ACK, tra cui la configurazione IAM, i modelli multi-account e l'integrazione con altre funzionalità EKS.
## Modelli di configurazione IAM
La funzionalità ACK utilizza un IAM Capability Role con AWS cui eseguire l'autenticazione. Scegli il modello IAM giusto in base alle tue esigenze.
### Semplice: ruolo a capacità singola
Per casi di sviluppo, test o semplici casi d'uso, concedi tutte le autorizzazioni necessarie direttamente al Capability Role.
**Quando usare**:
+ Guida introduttiva a ACK
+ Implementazioni con un solo account
+ Tutte le risorse sono gestite da un unico team
+ Ambienti di sviluppo e test
**Esempio**: aggiungi le autorizzazioni S3 e RDS al tuo Capability Role con condizioni di etichettatura delle risorse:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
},
{
"Effect": "Allow",
"Action": ["rds:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
},
}
}
]
}
```
Questo esempio limita le operazioni S3 e RDS a regioni specifiche e richiede che le risorse RDS abbiano un tag. `ManagedBy: ACK`
### Produzione: IAM Role Selectors
Per gli ambienti di produzione, utilizza IAM Role Selectors per implementare l'accesso con privilegi minimi e l'isolamento a livello di namespace.
**Quando usare:**
+ Ambienti di produzione
+ Cluster con più team
+ Gestione delle risorse su più account
+ Requisiti di sicurezza con privilegi minimi
+ Servizi diversi richiedono autorizzazioni diverse
**Vantaggi**:
+ Ogni namespace ottiene solo le autorizzazioni necessarie
+ Isolamento del team: il team A non può utilizzare le autorizzazioni del team B
+ Controllo e conformità più semplici
+ Necessario per la gestione delle risorse tra account
Per una configurazione dettagliata di IAM Role Selector, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
## Integrazione con altre funzionalità EKS
### GitOps con Argo CD
Usa il CD EKS Capability for Argo per distribuire risorse ACK dai repository Git, abilitando GitOps flussi di lavoro per la gestione dell'infrastruttura.
**Considerazioni:**
+ Archivia le risorse ACK insieme ai manifesti delle applicazioni per end-to-end GitOps
+ Organizza per ambiente, servizio o tipo di risorsa in base alla struttura del tuo team
+ Usa la sincronizzazione automatica di Argo CD per una riconciliazione continua
+ Abilita la potatura per rimuovere automaticamente le risorse eliminate
+ Prendi in considerazione hub-and-spoke i modelli per la gestione dell'infrastruttura multicluster
GitOps fornisce audit trail, funzionalità di rollback e gestione dichiarativa dell'infrastruttura. Per ulteriori informazioni su Argo CD, vedere. [Lavorare con Argo CD](working-with-argocd.md)
### Composizione delle risorse con kro
Usa EKS Capability for kro (Kube Resource Orchestrator) per comporre più risorse ACK in astrazioni di livello superiore e personalizzate. APIs
**Quando usare kro** con ACK:
+ Crea modelli riutilizzabili per stack di infrastruttura comuni (database \$1 backup \$1 monitoraggio)
+ Crea piattaforme self-service semplificate per i team applicativi APIs
+ Gestisci le dipendenze delle risorse e passa i valori tra le risorse (funzione ARN a Lambda del bucket S3)
+ Standardizza le configurazioni dell'infrastruttura tra i team
+ Riduci la complessità nascondendo i dettagli di implementazione dietro risorse personalizzate
**Modelli di esempio**:
+ Stack di applicazioni: bucket S3\$1coda SQS\$1configurazione delle notifiche
+ Configurazione del database: istanza RDS \$1 gruppo di parametri \$1 gruppo di sicurezza \$1 segreti
+ Rete: VPC \$1 sottoreti \$1 tabelle di routing \$1 gruppi di sicurezza
kro gestisce l'ordinamento delle dipendenze, la propagazione dello stato e la gestione del ciclo di vita per le risorse composte. Per ulteriori informazioni su kro, consulta. [concetti kro](kro-concepts.md)
## Organizzazione delle risorse
Organizza le risorse ACK utilizzando i namespace e i tag delle AWS risorse Kubernetes per migliorare la gestione, il controllo degli accessi e il monitoraggio dei costi.
### Organizzazione dei namespace
Usa gli spazi dei nomi Kubernetes per separare logicamente le risorse ACK per ambiente (produzione, gestione temporanea, sviluppo), team (piattaforma, dati, ML) o applicazione.
**Vantaggi:**
+ RBAC con ambito namespace per il controllo degli accessi
+ Imposta le regioni predefinite per namespace utilizzando le annotazioni
+ Gestione e pulizia delle risorse più semplici
+ Separazione logica in linea con la struttura organizzativa
### Aggiunta di tag alle risorse
La funzionalità EKS ACK applica automaticamente i tag predefiniti a tutte le AWS risorse che crea. Questi tag differiscono dagli ACK autogestiti e offrono una tracciabilità avanzata.
**Tag predefiniti applicati dalla funzionalità:**
| Tag Key | Description |
| --- | --- |
| `eks:controller-version` | La versione del controller ACK |
| `eks:kubernetes-namespace` | Lo spazio dei nomi Kubernetes della risorsa ACK |
| `eks:kubernetes-resource-name` | Il nome della risorsa Kubernetes |
| `eks:kubernetes-api-group` | Il gruppo di API Kubernetes (ad esempio,) `s3.services.k8s.aws` |
| `eks:eks-capability-arn` | L'ARN della funzionalità EKS ACK |
**Nota**
ACK autogestito utilizza diversi tag predefiniti: `services.k8s.aws/controller-version` e. `services.k8s.aws/namespace` I tag della funzionalità utilizzano il `eks:` prefisso per garantire la coerenza con altre funzionalità EKS.
**Tag aggiuntivi consigliati:**
Aggiungi tag personalizzati per l'allocazione dei costi, il monitoraggio della proprietà e per scopi organizzativi:
+ Ambiente (produzione, allestimento, sviluppo)
+ Proprietà del team o del reparto
+ Centro di costo per l'allocazione della fatturazione
+ Nome dell'applicazione o del servizio
## Migrazione da altri Infrastructure-as-code strumenti
Molte organizzazioni stanno trovando valore nella standardizzazione su Kubernetes oltre all'orchestrazione dei carichi di lavoro. La migrazione dell'infrastruttura e della gestione AWS delle risorse verso ACK consente di standardizzare la gestione dell'infrastruttura utilizzando Kubernetes insieme ai carichi di lavoro delle applicazioni. APIs
**Vantaggi della standardizzazione su Kubernetes per l'infrastruttura**:
+ **Un'unica fonte di verità**: gestisci sia le applicazioni che l'infrastruttura in Kubernetes, abilitando una pratica end-to-end GitOps
+ **Strumenti unificati: i** team utilizzano le risorse e gli strumenti Kubernetes anziché apprendere più strumenti e framework
+ **Riconciliazione coerente: ACK riconcilia** continuamente le AWS risorse come fa Kubernetes per i carichi di lavoro, rilevando e correggendo le deviazioni rispetto agli strumenti imperativi
+ **Composizioni native**: con kro e ACK insieme, puoi fare riferimento alle risorse direttamente nelle applicazioni e nei manifesti delle risorse, passando stringhe di connessione e tra AWS le risorse ARNs
+ **Operazioni semplificate**: un unico piano di controllo per implementazioni, rollback e osservabilità sull'intero sistema
ACK supporta l'adozione AWS delle risorse esistenti senza ricrearle, abilitando la migrazione senza tempi di inattività da Terraform o da CloudFormation risorse esterne al cluster.
**Adotta una risorsa esistente**:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Una volta adottata, la risorsa viene gestita da ACK e può essere aggiornata tramite i manifesti di Kubernetes. È possibile migrare in modo incrementale, adottando le risorse necessarie e mantenendo gli strumenti IaC esistenti per altre risorse.
ACK supporta anche risorse di sola lettura. Per le risorse gestite da altri team o strumenti a cui desideri fare riferimento ma non modificare, combina l'adozione con la politica di `retain` eliminazione e concedi solo le autorizzazioni IAM di lettura. Ciò consente alle applicazioni di scoprire l'infrastruttura condivisa (ruoli IAMVPCs, chiavi KMS) tramite APIs Kubernetes senza rischiare modifiche.
Per ulteriori informazioni sull'adozione delle risorse, consulta. [Concetti ACK](ack-concepts.md)
## Politiche di eliminazione
Le politiche di eliminazione controllano cosa succede alle AWS risorse quando elimini la risorsa Kubernetes corrispondente. Scegli la politica giusta in base al ciclo di vita delle risorse e ai tuoi requisiti operativi.
### Elimina (impostazione predefinita)
La AWS risorsa viene eliminata quando elimini la risorsa Kubernetes. Ciò mantiene la coerenza tra il cluster e AWS garantisce che le risorse non si accumulino.
**Quando usare delete**:
+ Ambienti di sviluppo e test in cui la pulizia è importante
+ Risorse temporanee legate al ciclo di vita delle applicazioni (database di test, bucket temporanei)
+ Risorse che non dovrebbero durare più a lungo dell'applicazione (code SQS, cluster) ElastiCache
+ Ottimizzazione dei costi: ripulisci automaticamente le risorse inutilizzate
+ Ambienti gestiti GitOps in cui la rimozione delle risorse da Git dovrebbe eliminare l'infrastruttura
La politica di eliminazione predefinita è in linea con il modello dichiarativo di Kubernetes: ciò che è nel cluster corrisponde a ciò che esiste in. AWS
### Mantenimento
La AWS risorsa viene conservata quando elimini la risorsa Kubernetes. Ciò protegge i dati critici e consente alle risorse di sopravvivere più a lungo della loro rappresentazione in Kubernetes.
**Quando usare Retain**:
+ Database di produzione con dati critici che devono sopravvivere alle modifiche dei cluster
+ Bucket di storage a lungo termine con requisiti di conformità o di controllo
+ Risorse condivise utilizzate da più applicazioni o team
+ Risorse in fase di migrazione verso diversi strumenti di gestione
+ Scenari di disaster recovery in cui si desidera preservare l'infrastruttura
+ Risorse con dipendenze complesse che richiedono uno smantellamento accurato
```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
name: production-db
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
dbInstanceIdentifier: prod-db
# ... configuration
```
**Importante**
Le risorse conservate continuano a comportare AWS costi e devono essere eliminate manualmente quando non sono più necessarie. AWS Utilizza l'etichettatura delle risorse per tenere traccia delle risorse conservate per la pulizia.
Per ulteriori informazioni sulle politiche di eliminazione, vedere. [Concetti ACK](ack-concepts.md)
## Documentazione upstream
Per informazioni dettagliate sull'uso di ACK:
+ [Guida all'uso di ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/) - Creazione e gestione delle risorse
+ [Riferimento all'API ACK](https://aws-controllers-k8s.github.io/community/reference/): documentazione API completa per tutti i servizi
+ [Documentazione ACK - Documentazione](https://aws-controllers-k8s.github.io/community/docs/) completa per l'utente
## Fasi successive
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM e i modelli multiaccount
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e il ciclo di vita delle risorse
+ [Risolvi i problemi relativi alle funzionalità ACK](ack-troubleshooting.md)- Risolvi i problemi ACK
+ [Lavorare con Argo CD](working-with-argocd.md)- Implementa le risorse ACK con GitOps
+ [concetti kro](kro-concepts.md)- Componi le risorse ACK in astrazioni di livello superiore
# Risolvi i problemi relativi alle funzionalità ACK
Questo argomento fornisce linee guida per la risoluzione dei problemi relativi a EKS Capability for ACK, compresi i controlli dello stato delle funzionalità, la verifica dello stato delle risorse e i problemi di autorizzazione IAM.
**Nota**
Le funzionalità EKS sono completamente gestite e eseguite all'esterno del cluster. Non hai accesso ai log dei controller o ai namespace dei controller. La risoluzione dei problemi si concentra sullo stato delle funzionalità, sullo stato delle risorse e sulla configurazione IAM.
## Le funzionalità sono ATTIVE ma le risorse non vengono create
Se la tua funzionalità ACK mostra `ACTIVE` lo stato ma le risorse non vengono create AWS, controlla lo stato della capacità, lo stato delle risorse e le autorizzazioni IAM.
**Verifica lo stato delle funzionalità:**
È possibile visualizzare i problemi relativi allo stato e allo stato delle funzionalità nella console EKS o utilizzando la AWS CLI.
**Console**:
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster.
1. Scegli la scheda **Osservabilità**.
1. Scegli **Monitora cluster**.
1. Scegli la scheda **Capacità** per visualizzare lo stato e lo stato di tutte le funzionalità.
** AWS CLI:**
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
# Look for issues in the health section
```
Cause comuni:
+ **Autorizzazioni IAM mancanti**: al Capability Role mancano le autorizzazioni per il servizio AWS
+ **Namespace errato**: risorse create nello spazio dei nomi senza un selettore appropriato IAMRole
+ **Specifiche della risorsa non valide: controlla le condizioni di stato delle risorse per verificare la presenza** di errori di convalida
+ **Limitazione delle API: AWS vengono raggiunti i limiti di velocità delle** API
+ Webhook di **ammissione: webhook** di ammissione che impediscono al controller di correggere lo stato delle risorse
**Controlla lo stato delle risorse:**
```
# Describe the resource to see conditions and events
kubectl describe bucket my-bucket -n default
# Look for status conditions
kubectl get bucket my-bucket -n default -o jsonpath='{.status.conditions}'
# View resource events
kubectl get events --field-selector involvedObject.name=my-bucket -n default
```
**Verifica le autorizzazioni IAM**:
```
# View the Capability Role's policies
aws iam list-attached-role-policies --role-name my-ack-capability-role
aws iam list-role-policies --role-name my-ack-capability-role
# Get specific policy details
aws iam get-role-policy --role-name my-ack-capability-role --policy-name policy-name
```
## Risorse create in AWS Kubernetes ma non visualizzate
ACK tiene traccia solo delle risorse create tramite i manifesti di Kubernetes. Per gestire le AWS risorse esistenti con ACK, utilizza la funzionalità di adozione.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Per ulteriori informazioni sull'adozione delle risorse, consulta[Concetti ACK](ack-concepts.md).
## Risorse per più account non create
Se non vengono create risorse in un AWS account di destinazione quando utilizzi IAM Role Selectors, verifica la relazione di fiducia e la configurazione di IAMRole Selector.
**Verifica la relazione di fiducia**:
```
# Check the trust policy in the target account role
aws iam get-role --role-name cross-account-ack-role --query 'Role.AssumeRolePolicyDocument'
```
La politica di fiducia deve consentire al ruolo di capacità dell'account di origine di assumerla.
**Conferma la configurazione IAMRole del selettore**:
```
# List IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Describe specific selector
kubectl describe iamroleselector my-selector
```
**Verifica l'allineamento dello spazio dei nomi:**
IAMRoleI selettori sono risorse con ambito cluster ma hanno come target namespace specifici. Assicurati che le tue risorse ACK si trovino in uno spazio dei nomi che corrisponda al selettore dello spazio dei nomi di Selector: IAMRole
```
# Check resource namespace
kubectl get bucket my-cross-account-bucket -n production
# List all IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Check which namespace the selector targets
kubectl get iamroleselector my-selector -o jsonpath='{.spec.namespaceSelector}'
```
** IAMRoleControlla** la condizione selezionata:
Verifica che il IAMRole selettore sia stato abbinato correttamente alla tua risorsa controllando la `ACK.IAMRoleSelected` condizione:
```
# Check if IAMRoleSelector was matched
kubectl get bucket my-cross-account-bucket -n production -o jsonpath='{.status.conditions[?(@.type=="ACK.IAMRoleSelected")]}'
```
Se la condizione è presente `False` o manca, il IAMRole selettore dello spazio dei nomi del selettore non corrisponde allo spazio dei nomi della risorsa. Verifica che il selettore corrisponda alle etichette dello spazio dei nomi della risorsa. `namespaceSelector`
**Verifica le autorizzazioni di Capability** Role:
I requisiti `sts:AssumeRole` e le `sts:TagSession` autorizzazioni del ruolo Capability Role per il ruolo dell'account di destinazione:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::[.replaceable]`444455556666`:role/[.replaceable]`cross-account-ack-role`"
}
]
}
```
Per una configurazione dettagliata tra account, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
## Fasi successive
+ [Considerazioni ACK per EKS](ack-considerations.md)- Considerazioni e best practice relative a ACK
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM e i modelli multiaccount
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti di ACK e il ciclo di vita delle risorse
+ [Risoluzione dei problemi delle funzionalità EKS](capabilities-troubleshooting.md)- Guida generale alla risoluzione dei problemi relativi alle funzionalità
# Confronto tra la funzionalità EKS per ACK e l'ACK autogestito
EKS Capability for ACK offre le stesse funzionalità dei controller ACK autogestiti, ma con vantaggi operativi significativi. Per un confronto generale tra EKS Capabilities e soluzioni autogestite, vedi. [Considerazioni sulle funzionalità EKS](capabilities-considerations.md) Questo argomento si concentra sulle differenze specifiche di ACK.
## Differenze rispetto all'ACK upstream
EKS Capability for ACK si basa sui controller ACK upstream ma si differenzia nell'integrazione IAM.
**IAM Capability** Role: la funzionalità utilizza un ruolo IAM dedicato con una policy di fiducia che consente il `capabilities.eks.amazonaws.com` service principal, non l'IRSA (IAM Roles for Service Accounts). Puoi collegare le policy IAM direttamente al Capability Role senza la necessità di creare o annotare gli account di servizio Kubernetes o configurare i provider OIDC. Una best practice per i casi d'uso in produzione consiste nel configurare le autorizzazioni di servizio utilizzando. `IAMRoleSelector` Per ulteriori dettagli, consulta [Configurare le autorizzazioni ACK](ack-permissions.md).
**Tag di sessione**: la funzionalità gestita imposta automaticamente i tag di sessione su tutte le richieste AWS API, abilitando il controllo e il controllo granulari degli accessi. I tag includono`eks:eks-capability-arn`, e. `eks:kubernetes-namespace` `eks:kubernetes-api-group` Ciò differisce dall'ACK autogestito, che non imposta questi tag per impostazione predefinita. [Configurare le autorizzazioni ACK](ack-permissions.md)Per ulteriori informazioni sull'utilizzo dei tag di sessione nelle policy IAM, consulta la sezione.
**Tag delle risorse**: la funzionalità applica tag predefiniti diversi alle AWS risorse rispetto a ACK autogestiti. La funzionalità utilizza tag con `eks:` prefisso (ad esempio`eks:kubernetes-namespace`,`eks:eks-capability-arn`) anziché i `services.k8s.aws/` tag utilizzati dall'ACK autogestito. Consulta [Considerazioni ACK per EKS](ack-considerations.md) l'elenco completo dei tag di risorsa predefiniti.
**Compatibilità delle risorse**: le risorse personalizzate ACK funzionano in modo identico a quelle di ACK upstream senza modifiche ai file YAML delle risorse ACK. La funzionalità utilizza lo stesso Kubernetes APIs e CRDs quindi gli strumenti funzionano allo stesso modo. `kubectl` Sono supportati tutti i controller e le risorse GA dell'UPstream ACK.
[Per la documentazione completa di ACK e le guide specifiche per i servizi, consulta la documentazione ACK.](https://aws-controllers-k8s.github.io/community/)
## Percorso di migrazione
È possibile migrare da ACK autogestito alla funzionalità gestita senza tempi di inattività:
1. Aggiorna il controller ACK autogestito `kube-system` per utilizzarlo per i contratti di locazione elettorali per i leader, ad esempio:
```
helm upgrade --install ack-s3-controller \
oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
--namespace ack-system \
--set leaderElection.namespace=kube-system
```
In questo modo il contratto di locazione del controllore viene spostato in avanti`kube-system`, permettendo alla capacità gestita di coordinarsi con esso.
1. Crea la funzionalità ACK sul tuo cluster (vedi[Crea una funzionalità ACK](create-ack-capability.md))
1. La funzionalità gestita riconosce le AWS risorse esistenti gestite da ACK e si occupa della riconciliazione
1. Ridimensiona o rimuovi gradualmente le implementazioni di controller autogestiti:
```
helm uninstall ack-s3-controller --namespace ack-system
```
Questo approccio consente a entrambi i controller di coesistere in modo sicuro durante la migrazione. La funzionalità gestita adotta automaticamente le risorse precedentemente gestite da controller autogestiti, garantendo una riconciliazione continua senza conflitti.
## Fasi successive
+ [Crea una funzionalità ACK](create-ack-capability.md)- Creazione di una risorsa con funzionalità ACK
+ [Concetti ACK](ack-concepts.md)- Comprendi i concetti e il ciclo di vita delle risorse ACK
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura IAM e autorizzazioni
# Implementazione continua con Argo CD
Argo CD è uno strumento dichiarativo e di distribuzione GitOps continua per Kubernetes. Con Argo CD, puoi automatizzare l'implementazione e la gestione del ciclo di vita delle tue applicazioni su più cluster e ambienti. Argo CD supporta diversi tipi di sorgenti tra cui repository Git, registri Helm (HTTP e OCI) e immagini OCI, offrendo flessibilità alle organizzazioni con diversi requisiti di sicurezza e conformità.
Con EKS Capabilities, Argo CD è completamente gestito da AWS, eliminando la necessità di installare, mantenere e scalare i controller Argo CD e le loro dipendenze dai cluster.
## Come funziona Argo CD
Argo CD segue GitOps lo schema, in cui la fonte dell'applicazione (repository Git, registro Helm o immagine OCI) è la fonte di verità per definire lo stato dell'applicazione desiderato. Quando si crea una `Application` risorsa Argo CD, si specifica l'origine contenente i manifesti dell'applicazione e il cluster e lo spazio dei nomi Kubernetes di destinazione. Argo CD monitora continuamente sia la sorgente che lo stato live nel cluster, sincronizzando automaticamente qualsiasi modifica per garantire che lo stato del cluster corrisponda allo stato desiderato.
**Nota**
Con EKS Capability for Argo CD, il software Argo CD viene eseguito nel piano di AWS controllo, non sui nodi di lavoro. Ciò significa che i nodi di lavoro non hanno bisogno dell'accesso diretto ai repository Git o ai registri Helm: la funzionalità gestisce l'accesso all'origine dall'account. AWS
Argo CD fornisce tre tipi di risorse principali:
+ **Applicazione**: definisce una distribuzione da un repository Git a un cluster di destinazione
+ **ApplicationSet**: genera più applicazioni da modelli per distribuzioni multi-cluster
+ **AppProject**: Fornisce il raggruppamento logico e il controllo degli accessi per le applicazioni
**Esempio: creazione di un'applicazione Argo CD**
L'esempio seguente mostra come creare una risorsa Argo CD`Application`:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
```
**Nota**
Usalo `destination.name` con il nome del cluster che hai usato durante la registrazione del cluster (come `in-cluster` per il cluster locale). Il `destination.server` campo funziona anche con il cluster EKS ARNs, ma si consiglia di utilizzare i nomi dei cluster per una migliore leggibilità.
## Vantaggi di Argo CD
Argo CD implementa un GitOps flusso di lavoro in cui si definiscono le configurazioni delle applicazioni nei repository Git e Argo CD sincronizza automaticamente le applicazioni in modo che corrispondano allo stato desiderato. Questo approccio incentrato su Git fornisce un audit trail completo di tutte le modifiche, consente facili rollback e si integra naturalmente con i processi di revisione e approvazione del codice esistenti. Argo CD rileva e riconcilia automaticamente la deriva tra lo stato desiderato in Git e lo stato effettivo nei cluster, assicurando che le distribuzioni rimangano coerenti con la configurazione dichiarata.
Con Argo CD, è possibile distribuire e gestire applicazioni su più cluster da una singola istanza Argo CD, semplificando le operazioni in ambienti multi-cluster e multiregione. L'interfaccia utente di Argo CD offre funzionalità di visualizzazione e monitoraggio, che consentono di visualizzare lo stato di implementazione, l'integrità e la cronologia delle applicazioni. L'interfaccia utente si integra con AWS Identity Center (precedentemente AWS SSO) per un'autenticazione e un'autorizzazione senza interruzioni, consentendoti di controllare l'accesso utilizzando l'infrastruttura di gestione delle identità esistente.
Come parte di EKS Managed Capabilities, Argo CD è completamente gestito da AWS, eliminando la necessità di installare, configurare e mantenere l'infrastruttura Argo CD. AWS gestisce la scalabilità, l'applicazione di patch e la gestione operativa, permettendo ai team di concentrarsi sulla distribuzione delle applicazioni piuttosto che sulla manutenzione degli strumenti.
## Integrazione con Identity Center AWS
EKS Managed Capabilities fornisce l'integrazione diretta tra Argo CD e AWS Identity Center, consentendo l'autenticazione e l'autorizzazione senza interruzioni per gli utenti. Quando abiliti la funzionalità Argo CD, puoi configurare l'integrazione di AWS Identity Center per mappare i gruppi e gli utenti di Identity Center ai ruoli RBAC di Argo CD, consentendoti di controllare chi può accedere e gestire le applicazioni in Argo CD.
## Integrazione con altre funzionalità gestite da EKS
Argo CD si integra con altre funzionalità gestite da EKS.
+ ** AWS Controller for Kubernetes (ACK)**: utilizza Argo CD per gestire l'implementazione delle risorse ACK su più cluster, abilitando i flussi di lavoro per la tua infrastruttura. GitOps AWS
+ **kro (Kube Resource Orchestrator)**: usa Argo CD per distribuire composizioni kro su più cluster, abilitando una composizione coerente delle risorse in tutto il tuo ambiente Kubernetes.
## Guida introduttiva ad Argo CD
Per iniziare a usare il CD EKS Capability for Argo:
1. Crea e configura un IAM Capability Role con le autorizzazioni necessarie per consentire ad Argo CD di accedere ai tuoi sorgenti e gestire le applicazioni.
1. [Crea una risorsa con funzionalità Argo CD](create-argocd-capability.md) sul tuo cluster EKS tramite la AWS console, la AWS CLI o la tua infrastruttura preferita come strumento di codice.
1. Configura l'accesso al repository e registra i cluster per la distribuzione delle applicazioni.
1. Crea risorse applicative per distribuire le tue applicazioni dalle tue fonti dichiarative.
# Crea una funzionalità Argo CD
Questo argomento spiega come creare una funzionalità Argo CD sul tuo cluster Amazon EKS.
## Prerequisiti
Prima di creare una funzionalità Argo CD, assicurati di avere:
+ Un cluster Amazon EKS esistente che esegue una versione di Kubernetes supportata (sono supportate tutte le versioni con supporto standard ed esteso)
+ ** AWS Identity Center configurato**: necessario per l'autenticazione Argo CD (gli utenti locali non sono supportati)
+ Un ruolo di capacità IAM con autorizzazioni per Argo CD
+ Autorizzazioni IAM sufficienti per creare risorse di funzionalità sui cluster EKS
+ `kubectl`configurato per comunicare con il cluster
+ (Opzionale) L'Argo CD CLI è stata installata per una più semplice gestione di cluster e repository
+ (Per CLI/EksCtl) Lo strumento CLI appropriato installato e configurato
Per istruzioni sulla creazione dello IAM Capability Role, consulta. [Funzionalità Amazon EKS, ruolo IAM](capability-role.md) Per la configurazione di Identity Center, consulta [Guida introduttiva a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html).
**Importante**
Il ruolo di capacità IAM fornito determina a quali AWS risorse Argo CD può accedere. Ciò include l'accesso al repository Git tramite CodeConnections e i segreti in Secrets Manager. Per indicazioni sulla creazione di un ruolo appropriato con autorizzazioni con privilegi minimi, consulta e. [Funzionalità Amazon EKS, ruolo IAM](capability-role.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
## Scegli il tuo strumento
È possibile creare una funzionalità Argo CD utilizzando la Console di gestione AWS AWS CLI o eksctl:
+ [Crea una funzionalità Argo CD utilizzando la console](argocd-create-console.md)- Usa la console per un'esperienza guidata
+ [Crea una funzionalità Argo CD utilizzando la CLI AWS](argocd-create-cli.md)- Usa la AWS CLI per lo scripting e l'automazione
+ [Crea una funzionalità Argo CD usando eksctl](argocd-create-eksctl.md)- Usa eksctl per un'esperienza nativa di Kubernetes
## Cosa succede quando si crea una funzionalità Argo CD
Quando create una funzionalità Argo CD:
1. EKS crea il servizio di funzionalità Argo CD nel piano di controllo AWS
1. Le definizioni di risorse personalizzate (CRDs) sono installate nel cluster
1. Viene creata automaticamente una voce di accesso per il tuo IAM Capability Role con policy di accesso specifiche per ciascuna funzionalità che concedono le autorizzazioni Kubernetes di base (vedi) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
1. Argo CD inizia a cercare le sue risorse personalizzate (Applicazioni,,) ApplicationSets AppProjects
1. Lo stato della funzionalità cambia da a `CREATING` `ACTIVE`
1. L'interfaccia utente di Argo CD diventa accessibile tramite il relativo URL
Una volta attiva, potete creare applicazioni Argo CD nel cluster da distribuire dalle vostre fonti dichiarative.
**Nota**
La voce di accesso creata automaticamente non concede le autorizzazioni per distribuire applicazioni nei cluster. Per distribuire le applicazioni, è necessario configurare autorizzazioni Kubernetes RBAC aggiuntive per ogni cluster di destinazione. Vedi [Registra i cluster di destinazione](argocd-register-clusters.md) per i dettagli sulla registrazione dei cluster e sulla configurazione dell'accesso.
## Fasi successive
Dopo aver creato la funzionalità Argo CD:
+ [Concetti di Argo CD](argocd-concepts.md)- Scopri GitOps i principi, le politiche di sincronizzazione e i modelli multicluster
+ [Lavorare con Argo CD](working-with-argocd.md)- Configura l'accesso al repository, registra i cluster di destinazione e crea applicazioni
+ [Considerazioni su Argo CD](argocd-considerations.md)- Esplora i modelli di architettura multicluster e la configurazione avanzata
# Crea una funzionalità Argo CD utilizzando la console
Questo argomento descrive come creare una funzionalità Argo CD utilizzando. Console di gestione AWS
## Prerequisiti
+ ** AWS Identity Center configurato**: Argo CD richiede AWS Identity Center per l'autenticazione. Gli utenti locali non sono supportati. Se non hai configurato AWS Identity Center, consulta [Guida introduttiva a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) per creare un'istanza di Identity Center e [Aggiungi utenti](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) e [Aggiungi gruppi](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) per creare utenti e gruppi per l'accesso ad Argo CD.
## Crea la funzionalità Argo CD
1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.
1. Scegli la scheda **Funzionalità**.
1. Nella barra di navigazione a sinistra, scegli **Argo CD**.
1. Scegli la **funzionalità Create Argo CD**.
1. Per **IAM Capability Role**:
+ Se disponi già di un IAM Capability Role, selezionalo dal menu a discesa
+ Se devi creare un ruolo, scegli **Crea ruolo Argo CD**
Questo apre la console IAM in una nuova scheda con policy di fiducia precompilate e accesso completo in lettura a Secrets Manager. Per impostazione predefinita, non vengono aggiunte altre autorizzazioni, ma è possibile aggiungerle se necessario. Se prevedi di utilizzare CodeCommit repository o altri AWS servizi, aggiungi le autorizzazioni appropriate prima di creare il ruolo.
Dopo aver creato il ruolo, torna alla console EKS e il ruolo verrà selezionato automaticamente.
**Nota**
Se prevedi di utilizzare le integrazioni opzionali con AWS Secrets Manager o AWS CodeConnections, dovrai aggiungere le autorizzazioni al ruolo. Per esempi di policy IAM e linee guida alla configurazione, consulta [Gestisci i segreti delle applicazioni con AWS Secrets Manager](integration-secrets-manager.md) e. [Connect ai repository Git con AWS CodeConnections](integration-codeconnections.md)
1. Configura AWS l'integrazione con Identity Center:
1. Seleziona **Abilita AWS l'integrazione con Identity Center**.
1. Scegli la tua istanza di Identity Center dal menu a discesa.
1. Configura le mappature dei ruoli per RBAC assegnando utenti o gruppi ai ruoli di Argo CD (ADMIN, EDITOR o VIEWER)
1. Scegli **Create** (Crea).
Inizia il processo di creazione delle funzionalità.
## Verifica che la funzionalità sia attiva
1. Nella scheda **Funzionalità**, visualizza lo stato delle funzionalità di Argo CD.
1. Attendi che lo stato cambi da `CREATING` a`ACTIVE`.
1. Una volta attiva, la funzionalità è pronta per l'uso.
Per informazioni sullo stato delle funzionalità e sulla risoluzione dei problemi, vedere[Lavorare con le risorse di capacità](working-with-capabilities.md).
## Accedere all'interfaccia utente di Argo CD
Dopo che la funzionalità è attiva, puoi accedere all'interfaccia utente di Argo CD:
1. Nella pagina delle funzionalità di Argo CD, scegliete **Open Argo** CD UI.
1. L'interfaccia utente di Argo CD si apre in una nuova scheda del browser.
1. Ora puoi creare applicazioni e gestire le distribuzioni tramite l'interfaccia utente.
## Fasi successive
+ [Lavorare con Argo CD](working-with-argocd.md)- Configura gli archivi, registra i cluster e crea applicazioni
+ [Considerazioni su Argo CD](argocd-considerations.md)- Architettura multicluster e configurazione avanzata
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestite le risorse relative alle funzionalità di Argo CD
# Crea una funzionalità Argo CD utilizzando la CLI AWS
Questo argomento descrive come creare una funzionalità Argo CD utilizzando la AWS CLI.
## Prerequisiti
+ ** AWS CLI**: versione `2.12.3` o successiva. Per verificare la tua versione, `aws --version` esegui. Per ulteriori informazioni, consulta la Guida per l'utente all'[installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nell'interfaccia a riga di AWS comando.
+ **`kubectl`**— Uno strumento da riga di comando per lavorare con i cluster Kubernetes. Per ulteriori informazioni, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md).
+ ** AWS Identity Center configurato**: Argo CD richiede AWS Identity Center per l'autenticazione. Gli utenti locali non sono supportati. Se non hai configurato AWS Identity Center, consulta [Guida introduttiva a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) per creare un'istanza di Identity Center e [Aggiungi utenti](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) e [Aggiungi gruppi](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) per creare utenti e gruppi per l'accesso ad Argo CD.
## Fase 1: Creare un ruolo di capacità IAM
Crea un file di policy di fiducia:
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crea il ruolo IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**Nota**
Se prevedi di utilizzare le integrazioni opzionali con AWS Secrets Manager o AWS CodeConnections, dovrai aggiungere le autorizzazioni al ruolo. Per esempi di policy IAM e indicazioni sulla configurazione, consulta [Gestisci i segreti delle applicazioni con AWS Secrets Manager](integration-secrets-manager.md) e. [Connect ai repository Git con AWS CodeConnections](integration-codeconnections.md)
## Fase 2: Creare la funzionalità Argo CD
Crea la risorsa di funzionalità Argo CD sul tuo cluster.
Innanzitutto, imposta le variabili di ambiente per la configurazione del tuo Identity Center:
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
Crea la funzionalità con l'integrazione di Identity Center. Sostituisci *region-code* con la AWS regione in cui si trova il cluster, *my-cluster* con il nome del cluster e *idc-region-code* con il codice regionale in cui è stato configurato lo IAM Identity Center:
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva poiché EKS crea l'infrastruttura e i componenti di funzionalità richiesti. EKS installerà le Kubernetes Custom Resource Definitions relative a questa funzionalità nel cluster non appena viene creata.
**Nota**
Se ricevi un errore che indica che il cluster non esiste o non disponi delle autorizzazioni, verifica:
Il nome del cluster è corretto
La tua AWS CLI è configurata per la regione corretta
Disponi delle autorizzazioni IAM richieste
## Fase 3: Verifica che la funzionalità sia attiva
Attendi che la funzionalità diventi attiva. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e *my-cluster* con il nome del cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`. Non continuare con il passaggio successivo fino a quando lo stato non sarà raggiunto`ACTIVE`.
Puoi anche visualizzare i dettagli completi delle funzionalità:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## Fase 4: Verifica della disponibilità di risorse personalizzate
Dopo che la funzionalità è attiva, verificate che le risorse personalizzate di Argo CD siano disponibili nel cluster:
```
kubectl api-resources | grep argoproj.io
```
Dovresti vedere i tipi `Application` di `ApplicationSet` risorse elencati.
## Fasi successive
+ [Lavorare con Argo CD](working-with-argocd.md)- Configura i repository, registra i cluster e crea applicazioni
+ [Considerazioni su Argo CD](argocd-considerations.md)- Architettura multicluster e configurazione avanzata
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa di funzionalità Argo CD
# Crea una funzionalità Argo CD usando eksctl
Questo argomento descrive come creare una funzionalità Argo CD usando eksctl.
**Nota**
I seguenti passaggi richiedono la versione eksctl o successiva. `0.220.0` Per verificare la tua versione, esegui. `eksctl version`
## Fase 1: Creare un ruolo di capacità IAM
Crea un file di policy di fiducia:
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crea il ruolo IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**Nota**
Per questa configurazione di base, non sono necessarie politiche IAM aggiuntive. Se prevedi di utilizzare Secrets Manager per le credenziali del repository oppure CodeConnections, dovrai aggiungere le autorizzazioni al ruolo. Per esempi di policy IAM e linee guida alla configurazione, consulta e. [Gestisci i segreti delle applicazioni con AWS Secrets Manager](integration-secrets-manager.md) [Connect ai repository Git con AWS CodeConnections](integration-codeconnections.md)
## Fase 2: Ottieni la configurazione del tuo AWS Identity Center
Ottieni l'ARN e l'ID utente dell'istanza di Identity Center per la configurazione RBAC:
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
Prendi nota di questi valori: ti serviranno nel passaggio successivo.
## Fase 3: Creare un file di configurazione eksctl
Crea un archivio denominato `argocd-capability.yaml` con i seguenti contenuti. Sostituisci i valori segnaposto con il nome del cluster, la regione del cluster, l'ARN del ruolo IAM, l'ARN dell'istanza di Identity Center, la regione dell'Identity Center e l'ID utente:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**Nota**
È possibile aggiungere più utenti o gruppi alle mappature RBAC. Per i gruppi, usa `type: SSO_GROUP` e fornisci l'ID del gruppo. I ruoli disponibili sono `ADMIN``EDITOR`, e`VIEWER`.
## Fase 4: Creare la funzionalità Argo CD
Applica il file di configurazione:
```
eksctl create capability -f argocd-capability.yaml
```
Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva.
## Fase 5: Verificare che la funzionalità sia attiva
Verifica lo stato della capacità. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`.
## Fase 6: Verifica della disponibilità di risorse personalizzate
Dopo che la funzionalità è attiva, verificate che le risorse personalizzate di Argo CD siano disponibili nel cluster:
```
kubectl api-resources | grep argoproj.io
```
Dovresti vedere i tipi `Application` di `ApplicationSet` risorse elencati.
## Fasi successive
+ [Lavorare con Argo CD](working-with-argocd.md)- Scopri come creare e gestire applicazioni Argo CD
+ [Considerazioni su Argo CD](argocd-considerations.md)- Configura SSO e accesso multicluster
+ [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa di funzionalità Argo CD
# Concetti di Argo CD
Argo CD implementa GitOps trattando Git come l'unica fonte di verità per le implementazioni delle applicazioni. Questo argomento illustra un esempio pratico, quindi spiega i concetti fondamentali da comprendere quando si lavora con il CD EKS Capability for Argo.
## Guida introduttiva ad Argo CD
Dopo aver creato la funzionalità Argo CD (vedi[Crea una funzionalità Argo CD](create-argocd-capability.md)), puoi iniziare a distribuire le applicazioni. Questo esempio illustra la registrazione di un cluster e la creazione di un'applicazione.
### Fase 1: configurazione
**Registra il tuo cluster** (richiesto)
Registra il cluster in cui desideri distribuire le applicazioni. Per questo esempio, registreremo lo stesso cluster su cui è in esecuzione Argo CD (potete usare il nome `in-cluster` per motivi di compatibilità con la maggior parte degli esempi di Argo CD):
```
# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
--name my-cluster \
--query 'cluster.arn' \
--output text)
# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
--aws-cluster-name $CLUSTER_ARN \
--name in-cluster \
--project default
```
**Nota**
Per informazioni sulla configurazione dell'Argo CD CLI per funzionare con la funzionalità Argo CD in EKS, vedere. [Utilizzo dell'Argo CD CLI con funzionalità gestite](argocd-comparison.md#argocd-cli-configuration)
In alternativa, registra il cluster utilizzando un Kubernetes Secret (vedi per i dettagli). [Registra i cluster di destinazione](argocd-register-clusters.md)
**Configura l'accesso al repository (opzionale)**
Questo esempio utilizza un GitHub archivio pubblico, quindi non è richiesta alcuna configurazione del repository. Per gli archivi privati, configura l'accesso utilizzando AWS Secrets Manager o Kubernetes Secrets (vedi [Configurare l'accesso al repository](argocd-configure-repositories.md) per i dettagli). CodeConnections
Per AWS i servizi (grafici ECR for Helm e CodeCommit) CodeConnections, puoi farvi riferimento direttamente nelle risorse dell'applicazione senza creare un repository. Il Capability Role deve disporre delle autorizzazioni IAM richieste. Per informazioni dettagliate, vedi [Configurare l'accesso al repository](argocd-configure-repositories.md).
### Fase 2: crea un'applicazione
Crea questo manifesto dell'applicazione in`my-app.yaml`:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
Applica l'applicazione:
```
kubectl apply -f my-app.yaml
```
Dopo aver applicato questa applicazione, Argo CD: 1. Sincronizza l'applicazione da Git al tuo cluster (distribuzione iniziale) 2. Monitora il repository Git per le modifiche 3. Sincronizza automaticamente le modifiche successive al cluster 4. Rileva e corregge qualsiasi deriva dallo stato desiderato 5. Fornisce lo stato di salute e la cronologia di sincronizzazione nell'interfaccia utente
Visualizza lo stato dell'applicazione:
```
kubectl get application guestbook -n argocd
```
È inoltre possibile visualizzare l'applicazione utilizzando la CLI di Argo CD o l'interfaccia utente di Argo CD (accessibile dalla console EKS nella scheda Capacità del cluster).
**Nota**
Quando si utilizza l'Argo CD CLI con la funzionalità gestita, specificare le applicazioni con il prefisso dello spazio dei nomi:. `argocd app get argocd/guestbook`
**Nota**
Usa il nome del cluster in `destination.name` (il nome che hai usato durante la registrazione del cluster). La funzionalità gestita non supporta l'impostazione predefinita locale all'interno del cluster ()`kubernetes.default.svc`.
## Concetti principali
### GitOps principi e tipi di fonti
Argo CD implementa GitOps, in cui la fonte dell'applicazione è l'unica fonte attendibile per le implementazioni:
+ **Dichiarativo**: lo stato desiderato viene dichiarato utilizzando i manifesti YAML, i grafici Helm o gli overlay Kustomize
+ **Versionato: ogni modifica viene tracciata con un audit trail completo**
+ **Automatizzato**: Argo CD monitora continuamente le sorgenti e sincronizza automaticamente le modifiche
+ **Riparazione automatica:** rileva e corregge lo scostamento tra lo stato desiderato e quello effettivo del cluster
**Tipi di sorgenti supportati:**
+ **Archivi Git** - GitHub GitLab, Bitbucket, CodeCommit (HTTPS, SSH o) CodeConnections
+ Registri **Helm: registri** HTTP (simili) e registri OCI (simili) `https://aws.github.io/eks-charts` `public.ecr.aws`
+ **Immagini OCI: immagini** dei contenitori contenenti manifesti o grafici Helm (come) `oci://registry-1.docker.io/user/my-app`
Questa flessibilità consente alle organizzazioni di scegliere fonti che soddisfino i propri requisiti di sicurezza e conformità. Ad esempio, le organizzazioni che limitano l'accesso a Git dai cluster possono utilizzare ECR per i grafici Helm o le immagini OCI.
Per ulteriori informazioni, consultate [Application Sources nella documentazione](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/) del CD Argo.
### Sincronizzazione e riconciliazione
Argo CD monitora continuamente le sorgenti e i cluster per rilevare e correggere le differenze:
1. Esamina le fonti delle modifiche (impostazione predefinita: ogni 6 minuti)
1. Confronta lo stato desiderato con lo stato del cluster
1. Contrassegna le applicazioni come o `Synced` `OutOfSync`
1. Sincronizza automaticamente le modifiche (se configurate) o attende l'approvazione manuale
1. Monitora lo stato delle risorse dopo la sincronizzazione
**Le onde di sincronizzazione controllano** l'ordine di creazione delle risorse utilizzando le annotazioni:
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
Le risorse vengono applicate in ordine ondulatorio (partendo dai numeri più bassi, inclusi i numeri negativi come`-1`). Wave `0` è l'impostazione predefinita se non specificata. Ciò consente di creare dipendenze come i namespace (wave) prima delle distribuzioni (wave`-1`) prima dei servizi (wave`0`). `1`
**La riparazione automatica annulla automaticamente le modifiche manuali:**
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**Nota**
La funzionalità gestita utilizza il tracciamento delle risorse basato sulle annotazioni (non basato su etichette) per una migliore compatibilità con le convenzioni Kubernetes e altri strumenti.
[Per informazioni dettagliate sulle fasi di sincronizzazione, gli hook e i pattern avanzati, consulta la documentazione di sincronizzazione con Argo CD.](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/)
### Integrità dell'applicazione
Argo CD monitora lo stato di tutte le risorse dell'applicazione:
**Stati di salute** ****: \$1 Integro: tutte le risorse funzionano come previsto \$1 In corso di **avanzamento** - Risorse in fase di creazione o aggiornamento \$1 **Degradate** - Alcune risorse non integre (pod bloccati, processi non riusciti) \$1 **Sospesa - Applicazione intenzionalmente sospesa** \$1 Mancante - Risorse definite in Git non presenti nel cluster****
Argo CD include controlli di integrità integrati per le risorse Kubernetes più comuni (implementazioni, lavori, ecc.) e supporta controlli di integrità personalizzati per. StatefulSets CRDs
Lo stato dell'applicazione è determinato da tutte le sue risorse: se una risorsa lo è, l'applicazione sì. `Degraded` `Degraded`
Per ulteriori informazioni, consultate [Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) nella documentazione del CD Argo.
### Schemi multicluster
Argo CD supporta due modelli di implementazione principali:
**H ub-and-spoke** - Esegui Argo CD su un cluster di gestione dedicato che viene distribuito su più cluster di carichi di lavoro: \$1 Controllo e visibilità centralizzati \$1 Policy coerenti su tutti i cluster \$1 Un'istanza Argo CD da gestire \$1 Chiara separazione tra piano di controllo e carichi di lavoro
Per **cluster**: esegui Argo CD su ogni cluster, gestendo solo le applicazioni del cluster: \$1 Separazione del cluster (un errore non influisce sugli altri) \$1 Rete più semplice (nessuna comunicazione tra cluster) \$1 Configurazione iniziale più semplice (nessuna registrazione del cluster)
Scegliete tra hub-and-spoke i team di piattaforma che gestiscono più cluster o per i team indipendenti per i cluster o quando i cluster devono essere completamente isolati.
Per una configurazione multi-cluster dettagliata, consulta. [Considerazioni su Argo CD](argocd-considerations.md)
### Progetti
I progetti forniscono il raggruppamento logico e il controllo degli accessi per le applicazioni:
+ **Restrizioni all'origine**: limita i repository Git che possono essere utilizzati
+ **Restrizioni sulla destinazione**: limita i cluster e i namespace a cui è possibile rivolgersi
+ **Restrizioni alle risorse**: limita i tipi di risorse Kubernetes che possono essere distribuiti
+ **Integrazione RBAC**: mappa i progetti all'utente e al gruppo di Identity Center AWS IDs
Le applicazioni appartengono a un singolo progetto. Se non specificato, usano il `default` progetto, che di default non ha restrizioni. Per uso in produzione, modificate il `default` progetto per limitare l'accesso e creare nuovi progetti con le restrizioni appropriate.
Per la configurazione del progetto e i modelli RBAC, vedere. [Configurare le autorizzazioni di Argo CD](argocd-permissions.md)
### Opzioni di sincronizzazione
Ottimizza il comportamento di sincronizzazione con opzioni comuni:
+ `CreateNamespace=true`- Crea automaticamente lo spazio dei nomi di destinazione
+ `ServerSideApply=true`- Utilizza server-side apply per una migliore risoluzione dei conflitti
+ `SkipDryRunOnMissingResource=true`- Salta il dry run quando CRDs non esistono ancora (utile per le istanze kro)
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
Per un elenco completo delle opzioni di sincronizzazione, consultate la documentazione sulle opzioni di sincronizzazione di [Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/).
## Fasi successive
+ [Configurare l'accesso al repository](argocd-configure-repositories.md)- Configura l'accesso al repository Git
+ [Registra i cluster di destinazione](argocd-register-clusters.md)- Registra i cluster di destinazione per la distribuzione
+ [Crea applicazioni](argocd-create-application.md)- Crea la tua prima applicazione
+ [Considerazioni su Argo CD](argocd-considerations.md)- Modelli specifici di EKS, integrazione con Identity Center e configurazione multicluster
+ Documentazione [su Argo CD - Documentazione](https://argo-cd.readthedocs.io/en/stable/) completa su Argo CD, inclusi hook di sincronizzazione, controlli di integrità e modelli avanzati
# Configurare le autorizzazioni di Argo CD
La funzionalità gestita da Argo CD si integra con AWS Identity Center per l'autenticazione e utilizza ruoli RBAC integrati per l'autorizzazione. Questo argomento spiega come configurare le autorizzazioni per utenti e team.
## Come funzionano le autorizzazioni con Argo CD
La funzionalità Argo CD utilizza AWS Identity Center per l'autenticazione e fornisce tre ruoli RBAC integrati per l'autorizzazione.
Quando un utente accede ad Argo CD:
1. Si autenticano tramite AWS Identity Center (che può essere collegato al vostro provider di identità aziendale)
1. AWS Identity Center fornisce informazioni su utenti e gruppi su Argo CD
1. Argo CD associa utenti e gruppi ai ruoli RBAC in base alla configurazione
1. Gli utenti vedono solo le applicazioni e le risorse a cui hanno il permesso di accedere
## Ruoli RBAC integrati
La funzionalità Argo CD offre tre ruoli integrati che è possibile associare agli utenti e ai gruppi di AWS Identity Center. Si tratta di **ruoli con ambito globale** che controllano l'accesso alle risorse di Argo CD come progetti, cluster e repository.
**Importante**
I ruoli globali controllano l'accesso ad Argo CD stesso, non a risorse relative al progetto come le Applicazioni. Gli utenti di EDITOR e VIEWER non possono visualizzare o gestire le applicazioni per impostazione predefinita: hanno bisogno di ruoli di progetto per accedere alle risorse relative al progetto. [Ruoli del progetto e accesso all'ambito del progetto](#project-roles)Per i dettagli sulla concessione dell'accesso alle applicazioni e ad altre risorse relative al progetto, consulta la sezione.
**AMMINISTRATORE**
Accesso completo a tutte le risorse e le impostazioni di Argo CD:
+ Crea, aggiorna ed elimina applicazioni e ApplicationSets in qualsiasi progetto
+ Gestisci la configurazione di Argo CD
+ Registra e gestisci i cluster di destinazione della distribuzione
+ Configura l'accesso al repository
+ Crea e gestisci progetti
+ Visualizza lo stato e la cronologia di tutte le candidature
+ Elenca e accedi a tutti i cluster e gli archivi
**EDITOR**
Può aggiornare i progetti e configurare i ruoli del progetto, ma non può modificare le impostazioni globali di Argo CD:
+ Aggiorna progetti esistenti (non può creare o eliminare progetti)
+ Configura i ruoli e le autorizzazioni del progetto
+ Visualizza chiavi e certificati GPG
+ Impossibile modificare la configurazione globale di Argo CD
+ Non è possibile gestire direttamente cluster o repository
+ Non è possibile visualizzare o gestire le applicazioni senza ruoli di progetto
**VISUALIZZATORE**
Accesso in sola lettura alle risorse del CD Argo:
+ Visualizza le configurazioni del progetto
+ Elenca tutti i progetti (inclusi i progetti a cui l'utente non è assegnato)
+ Visualizza chiavi e certificati GPG
+ Impossibile elencare cluster o repository
+ Impossibile apportare modifiche
+ Non è possibile visualizzare o gestire le applicazioni senza ruoli di progetto
**Nota**
Per concedere agli utenti EDITOR o VIEWER l'accesso alle applicazioni, un ADMIN o EDITOR deve creare ruoli di progetto che associano i gruppi di Identity Center a autorizzazioni specifiche all'interno di un progetto.
## Ruoli del progetto e accesso all'ambito del progetto
I ruoli globali (ADMIN, EDITOR, VIEWER) controllano l'accesso allo stesso Argo CD. I ruoli del progetto controllano l'accesso alle risorse e alle funzionalità all'interno di un progetto specifico, tra cui:
+ **Risorse**: applicazioni ApplicationSets, credenziali del repository, credenziali del cluster
+ **Funzionalità**: accesso ai log, accesso esecutivo ai pod delle applicazioni
**Comprensione del modello di autorizzazione a due livelli**:
+ **Ambito globale**: i ruoli predefiniti determinano cosa possono fare gli utenti con progetti, cluster, repository e impostazioni del CD Argo
+ **Ambito del progetto**: i ruoli del progetto determinano ciò che gli utenti possono fare con le risorse e le funzionalità all'interno di un progetto specifico
Ciò significa che:
+ Gli utenti ADMIN possono accedere a tutte le risorse e le funzionalità del progetto senza configurazioni aggiuntive
+ Agli utenti EDITOR e VIEWER devono essere concessi ruoli di progetto per accedere alle risorse e alle funzionalità del progetto
+ Gli utenti di EDITOR possono creare ruoli di progetto per concedere a se stessi e ad altri l'accesso all'interno di progetti che possono aggiornare
**Esempio di flusso di lavoro**:
1. Un ADMIN associa un gruppo Identity Center al ruolo EDITOR a livello globale
1. Un AMMINISTRATORE crea un progetto per un team
1. L'EDITOR configura i ruoli del progetto all'interno di quel progetto per concedere ai membri del team l'accesso alle risorse relative al progetto
1. I membri del team (che possono avere il ruolo globale VIEWER) possono ora visualizzare e gestire le applicazioni in quel progetto in base alle autorizzazioni relative al ruolo di progetto
Per i dettagli sulla configurazione dei ruoli del progetto, consulta. [Controllo degli accessi basato su progetti](#_project_based_access_control)
## Configurare le mappature dei ruoli
Associa gli utenti e i gruppi di AWS Identity Center ai ruoli di Argo CD durante la creazione o l'aggiornamento della funzionalità.
**Esempio di mappatura dei ruoli:**
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**Nota**
I nomi dei ruoli fanno distinzione tra maiuscole e minuscole e devono essere maiuscole (ADMIN, EDITOR, VIEWER).
**Importante**
L'integrazione di EKS Capabilities con AWS Identity Center supporta fino a 1.000 identità per funzionalità Argo CD. Un'identità può essere un utente o un gruppo.
**Aggiorna le mappature dei ruoli**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## Utilizzo dell'account amministratore
L'account amministratore è progettato per la configurazione iniziale e le attività amministrative come la registrazione di cluster e la configurazione dei repository.
**Quando l'account amministratore è appropriato**:
+ Configurazione e configurazione delle funzionalità iniziali
+ Sviluppo individuale o dimostrazioni rapide
+ Attività amministrative (registrazione del cluster, configurazione del repository, creazione di progetti)
**Procedure consigliate per l'account amministratore**:
+ Non affidare i token dell'account al controllo delle versioni
+ Ruota immediatamente i token se esposti
+ Limita l'utilizzo dei token dell'account alle attività di configurazione e amministrative
+ Imposta tempi di scadenza brevi (massimo 12 ore)
+ È possibile creare solo 5 token di account alla volta
**Quando utilizzare invece l'accesso basato su progetti**:
+ Ambienti di sviluppo condivisi con più utenti
+ Qualsiasi ambiente che assomigli alla produzione
+ Quando hai bisogno di audit trail che indichino chi ha eseguito le azioni
+ Quando è necessario imporre restrizioni sulle risorse o limiti di accesso
Per ambienti di produzione e scenari multiutente, utilizza il controllo degli accessi basato su progetti con ruoli RBAC dedicati mappati ai gruppi di Identity Center. AWS
## Controllo degli accessi basato su progetti
Usa Argo CD Projects (AppProject) per fornire un controllo granulare degli accessi e l'isolamento delle risorse per i team.
**Importante**
Prima di assegnare utenti o gruppi a ruoli specifici del progetto, è necessario mapparli a un ruolo globale di Argo CD (ADMIN, EDITOR o VIEWER) nella configurazione delle funzionalità. Gli utenti non possono accedere ad Argo CD senza una mappatura globale dei ruoli, anche se sono assegnati a ruoli di progetto.
Prendi in considerazione la possibilità di associare gli utenti al ruolo VIEWER a livello globale, quindi concedi autorizzazioni aggiuntive tramite ruoli specifici del progetto. Ciò fornisce un accesso di base e consente al contempo un controllo granulare a livello di progetto.
I progetti forniscono:
+ **Restrizioni all'origine**: limita i repository Git che possono essere utilizzati
+ **Restrizioni sulla destinazione**: limita i cluster e i namespace a cui è possibile rivolgersi
+ **Restrizioni sulle risorse**: limita i tipi di risorse Kubernetes che possono essere distribuiti
+ **Integrazione RBAC**: mappa i progetti ai gruppi di AWS Identity Center o ai ruoli di Argo CD
**Esempio di progetto per** l'isolamento del team:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### Namespace di origine
Quando si utilizza la funzionalità EKS Argo CD, il `spec.sourceNamespaces` campo è obbligatorio nelle definizioni. AppProject Questo campo specifica quale spazio dei nomi può contenere applicazioni o ApplicationSets che fanno riferimento a questo progetto.
**Importante**
La funzionalità EKS Argo CD supporta solo un singolo spazio dei nomi per le applicazioni e, in genere, lo spazio ApplicationSets dei nomi specificato durante la creazione della funzionalità. `argocd` Ciò differisce dal CD open source Argo che supporta più namespace.
**AppProject configurazione**
Tutti AppProjects devono includere lo spazio dei nomi configurato della funzionalità in: `sourceNamespaces`
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**Nota**
Se ometti lo spazio dei nomi della funzionalità da`sourceNamespaces`, le applicazioni o ApplicationSets in tale spazio dei nomi non possono fare riferimento a questo progetto, con conseguenti errori di distribuzione.
**Assegna** utenti ai progetti:
I ruoli di progetto garantiscono agli utenti EDITOR e VIEWER l'accesso alle risorse del progetto (applicazioni ApplicationSets, repository e credenziali del cluster) e alle funzionalità (log, exec). Senza ruoli di progetto, questi utenti non possono accedere a queste risorse anche se dispongono di un accesso globale ai ruoli.
Gli utenti ADMIN hanno accesso a tutte le applicazioni senza bisogno di ruoli di progetto.
**Esempio: concessione dell'accesso all'applicazione ai membri del team**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**Nota**
Includi ruoli `clusters, get, *, allow` nel progetto per consentire agli utenti di visualizzare i nomi dei cluster nell'interfaccia utente. Senza questa autorizzazione, il cluster di destinazione viene visualizzato come «sconosciuto».
**Comprensione delle politiche relative ai ruoli del progetto**:
Il formato della politica è: `p, proj::, , ,