Comparación de la capacidad de EKS para ACK con ACK autoadministrados - Amazon EKS

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Comparación de la capacidad de EKS para ACK con ACK autoadministrados

La capacidad de EKS para ACK proporciona la misma funcionalidad que los controladores ACK autoadministrados, pero con importantes ventajas operativas. Para obtener una comparación general entre las capacidades de EKS y las soluciones autoadministradas, consulte Consideraciones sobre las capacidades de EKS. Este tema se centra en las diferencias específicas de ACK.

Diferencias con respecto a ACK ascendentes

La capacidad de EKS para ACK se basa en los controladores ACK ascendentes, pero difiere en la integración de IAM.

Rol de capacidad de IAM: la capacidad utiliza un rol de IAM dedicado con una política de confianza que permite la entidad principal del servicio de capabilities.eks.amazonaws.com, pero no IRSA (roles de IAM para cuentas de servicio). Puede adjuntar las políticas de IAM directamente al rol de capacidad sin necesidad de crear ni anotar cuentas de servicio de Kubernetes ni configurar los proveedores de OIDC. Una práctica recomendada para los casos de uso de producción es configurar los permisos del servicio mediante IAMRoleSelector. Consulte Configuración de los permisos de ACK para obtener más detalles.

Compatibilidad de recursos: los recursos personalizados de ACK funcionan de forma idéntica a los ACK ascendentes sin que se produzcan cambios en los archivos YAML de los recursos de ACK. La capacidad utiliza las mismas API y CRD de Kubernetes, por lo que herramientas como kubectl funcionan de la misma manera. Se admiten todos los controladores y recursos de GA de ACK ascendentes.

Para obtener la documentación completa de ACK y las guías específicas del servicio, consulte la documentación de ACK.

Ruta de migración

Puede migrar de ACK autoadministrados a la capacidad administrada sin tiempo de inactividad:

  1. Actualice el controlador de ACK autoadministrados para utilizar kube-system en las asignaciones de elección de líderes, por ejemplo:

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

    De este modo, se traslada la asignación del controlador a kube-system, lo que permite que la capacidad administrada se coordine con él.

  2. Cree la capacidad ACK en el clúster (consulte Creación de una capacidad de ACK).

  3. La capacidad administrada reconoce los recursos de AWS administrados por ACK existentes y se encarga de la conciliación.

  4. Reduzca verticalmente o elimine de forma gradual las implementaciones de controladores autoadministrados:

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

Este enfoque permite que ambos controladores coexistan de forma segura durante la migración. La capacidad administrada adopta automáticamente los recursos que antes administraban los controladores autoadministrados, lo que garantiza una conciliación continua sin conflictos.

Siguientes pasos