View a markdown version of this page

Confronto tra la capacità EKS per ACK e l'ACK autogestito - Amazon EKS
Differenze rispetto all'ACK upstreamPercorso di migrazioneController di anteprima e promozione automaticaFasi successive

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 su che si trova 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 capacità EKS per ACK e l'ACK autogestito

L'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, vedere. Considerazioni sulle funzionalità EKS Questo argomento si concentra sulle ACK-specific differenze.

Differenze rispetto all'ACK upstream

L'EKS Capability for ACK si basa sui controller ACK upstream ma differisce nell'integrazione IAM.

Ruolo di capacità IAM: la funzionalità utilizza un ruolo IAM dedicato con una politica di fiducia che consente l'entità del capabilities.eks.amazonaws.com servizio, non l'IRSA (ruoli IAM per gli account di servizio). È possibile allegare le policy IAM direttamente al Capability Role senza dover 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 del 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, consentendo un controllo e un controllo granulari degli accessi. I tag includonoeks:eks-capability-arn,, e. eks:kubernetes-namespace eks:kubernetes-api-group Ciò è diverso dall'ACK autogestito, che non imposta questi tag per impostazione predefinita. Configurare le autorizzazioni ACKPer informazioni dettagliate sull'uso dei tag di sessione nelle policy IAM, consulta.

Tag delle risorse: la funzionalità applica tag predefiniti diversi alle AWS risorse rispetto agli 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. Considerazioni ACK per EKSPer l'elenco completo dei tag delle risorse predefiniti, vedere.

Compatibilità delle risorse: le risorse personalizzate ACK funzionano in modo identico all'ACK originale senza modifiche ai file YAML delle risorse ACK. La funzionalità utilizza le stesse API e CRD di Kubernetes, quindi strumenti come questo funzionano allo stesso modo. kubectl La funzionalità supporta solo i controller e le risorse generalmente disponibili (GA) nell'ACK upstream. La funzionalità non include i controller che sono in anteprima a monte. Lo stato di un controller può cambiare da anteprima a GA upstream nel tempo e la funzionalità può quindi iniziare a gestirlo automaticamente. Se oltre a questa funzionalità utilizzi un controller di anteprima autogestito, verificalo Controller di anteprima e promozione automatica prima di eseguire la migrazione.

Per la documentazione completa di ACK e le guide specifiche sui servizi, consultate la documentazione ACK sul sito Web ACK.

Percorso di migrazione

È possibile migrare dall'ACK autogestito alla funzionalità gestita con un'interruzione minima delle risorse. AWS La migrazione si basa sull'elezione del leader di Kubernetes: il controller autogestito e la funzionalità si contendono lo stesso contratto di locazione, quindi solo uno di essi riconcilia una determinata risorsa in qualsiasi momento. Affinché ciò funzioni, entrambi devono condividere un contratto di locazione nello stesso namespace. La funzionalità non richiede necessariamente il leasing di un controller autogestito funzionante, pertanto è possibile controllare quando avviene il passaggio di consegne ridimensionando il controller autogestito.

Importante

Prima di iniziare, concedi allo IAM Capability Role le autorizzazioni equivalenti alle autorizzazioni utilizzate oggi dai controller autogestiti. La funzionalità si autentica con un Capability Role dedicato tramite il capabilities.eks.amazonaws.com service principal, anziché tramite il meccanismo attualmente utilizzato dai controller autogestiti, come IRSA o EKS Pod Identity (vedi). Configurare le autorizzazioni ACK Se al Capability Role mancano le autorizzazioni, la funzionalità adotta le tue risorse. Quindi non riesce a riconciliarle e registra gli errori. AccessDenied

Completa i passaggi seguenti per eseguire la migrazione. I passaggi utilizzano il controller S3 (ack-s3-controller) come esempio. Ripetili per ogni controller ACK autogestito che desideri migrare alla funzionalità, sostituendo il nome del controller e il diagramma Helm corrispondenti.

Nota

L'esecuzione di un controller autogestito insieme alla funzionalità è intesa come uno stato temporaneo durante la migrazione, non come una configurazione a lungo termine. Mentre entrambi sono in funzione, un'interruzione su entrambi i lati (ad esempio l'implementazione di una funzionalità o un aggiornamento del controller autogestito) può annullare il contratto di locazione e consentire all'altra parte di acquisirlo, provocando il passaggio inaspettato della riconciliazione tra i due. Completa la migrazione per ciascun controller anziché eseguirlo in modalità autogestita insieme alla funzionalità a tempo indeterminato.

  1. Abilita l'elezione del leader sul tuo controller ACK autogestito e trasferisci il contratto di locazione a: kube-system

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.enabled=true \
  --set leaderElection.namespace=kube-system

    È necessario impostare entrambi i valori. Nei grafici ACK Helm, il --leader-election-namespace flag viene applicato solo quando leaderElection.enabled lo è e l'elezione dei leader è disabilitata per impostazione predefinita. true L'impostazione leaderElection.namespace da sola non ha alcun effetto. Il controller continua a funzionare senza un contratto di leasing ed entrambi i controller riconciliano le stesse risorse contemporaneamente dopo la creazione della funzionalità. Questo vale per ogni grafico dei controller di servizio ACK, non solo per S3.

    Ciò sposta il contratto di locazione del controller akube-system, consentendo alla capacità gestita di coordinarsi con esso.

  2. Crea la funzionalità ACK sul tuo cluster (vediCrea una funzionalità ACK). La funzionalità viene avviata e richiede il contratto di locazione, ma il controller autogestito la detiene comunque. Il controller autogestito continua a riconciliare le risorse e la capacità attende la leadership anziché forzare l'acquisizione.

  3. Quando sei pronto per iniziare la migrazione, ridimensiona il controller autogestito fino a zero repliche. Questo rilascia il contratto di locazione in modo che la capacità possa acquisire la leadership e assumere il controllo della riconciliazione:

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    Dopo aver ridimensionato il controller autogestito, la funzionalità acquisisce il contratto di locazione e inizia la riconciliazione, in genere entro breve tempo. La scalabilità del backup del controller autogestito non comporta la restituzione del contratto di leasing, poiché la funzionalità continua a mantenere e rinnovare il contratto di leasing. Per ripristinare la riconciliazione con il controller autogestito, ridimensionalo fino ad almeno una replica e quindi elimina la funzionalità ACK. Dopo aver eliminato la funzionalità, il controller autogestito riacquista il leasing e riprende la riconciliazione.

    Una volta adottata, la funzionalità applica i propri tag di risorsa predefiniti (con eks: prefisso) al posto dei tag utilizzati dall'ACK autogestito (vedere). services.k8s.aws/ Considerazioni ACK per EKS Aspettatevi un set una tantum di chiamate API di tagging alle risorse adottate e aggiornate qualsiasi strumento di allocazione dei costi o policy che inserisca il prefisso del tag. services.k8s.aws/

  4. Verifica che la funzionalità sia valida e che abbia provveduto alla riconciliazione delle tue risorse. Verificate che le risorse segnalino una Synced condizione True e che la funzionalità non stia registrando errori. AccessDenied

  5. Dopo aver verificato che la funzionalità sta gestendo correttamente le risorse, rimuovi il controller autogestito:

    helm uninstall ack-s3-controller --namespace ack-system

Questo approccio consente a entrambi i controller di coesistere in sicurezza durante la migrazione. La funzionalità gestita adotta risorse precedentemente gestite da controller autogestiti dopo il rilascio del contratto di locazione, garantendo una riconciliazione continua senza conflitti.

Controller di anteprima e promozione automatica

La funzionalità supporta solo i controller GA nell'ACK upstream. Un controller che è in anteprima oggi può essere promosso a GA upstream in un secondo momento. Quando ciò accade, la funzionalità inizia a gestire il controller automaticamente, senza alcuna azione da parte dell'utente.

Ciò comporta un rischio se si esegue un controller di anteprima autogestito su un cluster che utilizza la funzionalità anche per altri controller. È possibile eseguire il controller di anteprima come una singola replica con l'elezione del leader disattivata, poiché non c'è nessun altro controller con cui coordinarsi. Quando il controller viene promosso a GA, la funzionalità inizia a gestirlo. A quel punto, due riconciliatori agiscono sulle stesse risorse senza un contratto di locazione condiviso per coordinarle. Il risultato è lo stesso conflitto di doppia riconciliazione che le fasi di migrazione sono progettate per prevenire. Entrambi i riconciliatori emettono chiamate AWS API concorrenti e scrivono aggiornamenti in conflitto sullo stato delle risorse personalizzate.

Per evitare questo problema, prima di eseguire un controller di anteprima autogestito insieme alla funzionalità:

  • Attivate l'elezione del leader sul controller di anteprima autogestito e indicatene il leasingkube-system, utilizzando le stesse leaderElection.namespace=kube-system impostazioni leaderElection.enabled=true e le impostazioni mostrate nelle fasi di migrazione. In questo modo, se il controller viene promosso e la funzionalità lo sostituisce, i due sistemi si coordinino tramite un contratto di locazione condiviso anziché riconciliarsi in parallelo.

  • Tieni traccia dello stato GA a monte di tutti i controller di anteprima da cui dipendi e pianifica di migrarli seguendo il percorso di migrazione quando verranno promossi. Puoi controllare lo stato corrente di ciascun controller nella pagina dei servizi ACK sul sito Web ACK.

Fasi successive