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

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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

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 includonoeks: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 ACKPer 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 esempioeks:kubernetes-namespace,eks:eks-capability-arn) anziché i services.k8s.aws/ tag utilizzati dall'ACK autogestito. Consulta Considerazioni ACK per EKS 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.

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 avantikube-system, permettendo alla capacità gestita di coordinarsi con esso.

  2. Crea la funzionalità ACK sul tuo cluster (vediCrea una funzionalità ACK)

  3. La funzionalità gestita riconosce le AWS risorse esistenti gestite da ACK e si occupa della riconciliazione

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