

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

# Confronto tra la funzionalità EKS per ACK e l'ACK autogestito
<a name="ack-comparison"></a>

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
<a name="_differences_from_upstream_ack"></a>

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
<a name="_migration_path"></a>

È 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
<a name="_next_steps"></a>
+  [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