View a markdown version of this page

Comparación de la capacidad de EKS para ACK con ACK autoadministrados - Amazon EKS
Diferencias con respecto a ACK ascendentesRuta de migraciónVersión preliminar de los controladores y la promoción automáticaSiguientes pasos

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.

Etiquetas de sesión: la capacidad administrada establece automáticamente etiquetas de sesión en todas las solicitudes de API de AWS, lo que permite un control de acceso detallado y auditoría. Las etiquetas incluyen eks:eks-capability-arn, eks:kubernetes-namespace y eks:kubernetes-api-group. Esto difiere de ACK autoadministrado, que no establece estas etiquetas de forma predeterminada. Consulte Configuración de los permisos de ACK para obtener más información sobre el uso de etiquetas de sesión en las políticas de IAM.

Etiquetas de recursos: la capacidad aplica etiquetas predeterminadas diferentes a los recursos de AWS en comparación con ACK autoadministrado. La capacidad utiliza etiquetas con prefijo eks: (como eks:kubernetes-namespace, eks:eks-capability-arn) en lugar de las etiquetas services.k8s.aws/ utilizadas por ACK autoadministrado. Consulte Consideraciones sobre ACK para EKS para ver la lista completa de etiquetas de recursos predeterminadas.

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. La capacidad solo admite controladores y recursos que están disponibles de forma general (GA) en el ACK ascendente. La capacidad no incluye los controladores que estén en una versión preliminar ascendente. Con el tiempo, el estado de un controlador puede cambiar de versión preliminar a GA ascendente y, entonces, la capacidad puede empezar a administrarlo automáticamente. Si ejecuta un controlador de versión preliminar autoadministrado junto con la capacidad, consulte Versión preliminar de los controladores y la promoción automática antes de la migración.

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

Ruta de migración

Puede migrar de ACK autoadministrado a la capacidad administrada con una interrupción mínima de los recursos de AWS. La migración se basa en la elección de líder de Kubernetes: el controlador autoadministrado y la capacidad compiten por el mismo arrendamiento, por lo que solo uno de ellos concilia un recurso determinado en cualquier momento. Para que funcione, ambos deben compartir un arrendamiento en el mismo espacio de nombres. La capacidad no toma forzosamente el arrendamiento de un controlador autoadministrado en ejecución, por lo que puede controlar cuándo se produce la transferencia mediante la reducción vertical del controlador autoadministrado.

importante

Antes de empezar, conceda al rol de capacidad de IAM permisos equivalentes a los permisos que utilizan sus controladores autoadministrados actualmente. La capacidad se autentica con un rol de capacidad específico a través de la entidad principal del servicio capabilities.eks.amazonaws.com, en lugar de hacerlo mediante el mecanismo que utilizan los controladores autoadministrados actualmente, como IRSA o Pod Identity de EKS (consulte Configuración de los permisos de ACK). Si al rol de la capacidad le faltan permisos, la capacidad adopta sus recursos. A continuación, no logra conciliarlos y registra los errores AccessDenied.

Complete los siguientes pasos para la migración. Los pasos utilizan el controlador de S3 (ack-s3-controller) como ejemplo. Repítalos para cada controlador de ACK autoadministrado que desee migrar a la capacidad, pero sustituya antes el nombre del controlador correspondiente y el gráfico de Helm.

nota

La ejecución de un controlador autoadministrado junto con la capacidad está pensada como un estado temporal durante la migración, no como una configuración a largo plazo. Mientras estén en ejecución, una interrupción por parte de cualquiera de ellos (como la implementación de una capacidad o una actualización del controlador autoadministrado) puede anular el arrendamiento y permitir que el otro la adquiera, lo que provocaría que la conciliación cambiara inesperadamente entre ambos. Complete la migración de cada controlador en lugar de ejecutarla de forma autoadministrada junto con la capacidad de forma indefinida.

  1. Habilite la elección de líder en el controlador de ACK autoadministrado y traslade el arrendamiento 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

    Debe establecer ambos valores. En los gráficos de Helm de ACK, el indicador --leader-election-namespace solo se aplica cuando leaderElection.enabled sea true y la elección de líder está desactivada de forma predeterminada. Establecer leaderElection.namespace solo no tiene ningún efecto. El controlador continúa funcionando sin arrendamiento y ambos controladores concilian los mismos recursos al mismo tiempo una vez creada la capacidad. Esto se aplica a todos los gráficos de controladores de servicios de ACK, no solo S3.

    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 de ACK en el clúster (consulte Creación de una capacidad de ACK). La capacidad se pone en marcha y compite por el arrendamiento, pero el controlador autoadministrado aún lo conserva. El controlador autoadministrado continúa conciliando los recursos y la capacidad espera el liderazgo en lugar de forzar una adquisición.

  3. Cuando lo tenga todo listo para iniciar la migración, escale el controlador autoadministrado a cero réplicas. Esto libera el arrendamiento para que la capacidad pueda adquirir el liderazgo y ocuparse de la conciliación:

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

    Después de reducir verticalmente el controlador autoadministrado, la capacidad adquiere el arrendamiento y comienza la conciliación, normalmente en poco tiempo. Escalar verticalmente el controlador autoadministrado no le devuelve el arrendamiento, ya que la capacidad continúa manteniendo y renovando el arrendamiento. Para devolver la conciliación al controlador autoadministrado, escálelo verticalmente hasta incluir al menos una réplica y, a continuación, elimine la capacidad de ACK. Después de eliminar la capacidad, el controlador autoadministrado vuelve a adquirir el arrendamiento y reanuda la conciliación.

    Tras su adopción, la capacidad aplica sus propias etiquetas de recursos predeterminadas (con el prefijo eks:) en lugar de las etiquetas services.k8s.aws/ utilizadas por el ACK autoadministrado (consulte Consideraciones sobre ACK para EKS). Espere un conjunto único de llamadas a la API de etiquetado en los recursos adoptados y actualice cualquier herramienta de asignación de costos o de políticas que use el prefijo de etiqueta services.k8s.aws/.

  4. Verifique que el estado de la capacidad sea correcto y que se haya hecho cargo de la conciliación de los recursos. Confirme que los recursos notifiquen una condición Synced de True y que la capacidad no registre errores AccessDenied.

  5. Una vez que haya confirmado que la capacidad administra los recursos correctamente, retire el controlador autoadministrado:

    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 los recursos que antes administraban los controladores autoadministrados después de liberar el arrendamiento, lo que garantiza una conciliación continua sin conflictos.

Versión preliminar de los controladores y la promoción automática

La capacidad solo admite controladores de GA en el ACK ascendente. Un controlador que se encuentra en versión preliminar actualmente puede pasar a GA ascendente más adelante. Cuando eso sucede, la capacidad comienza a administrar ese controlador automáticamente, sin que sea necesario que haga nada.

Esto supone un riesgo si ejecuta un controlador de versión preliminar autoadministrado en un clúster que también utiliza la capacidad para otros controladores. Puede ejecutar el controlador de versión preliminar como una réplica única con la elección de líder deshabilitada, ya que no hay otro controlador con el que coordinarse. Cuando el controlador se pase a GA, la capacidad comienza a administrarlo. En ese momento, dos conciliadores actúan sobre los mismos recursos sin un arrendamiento compartido que los coordine. Los pasos de migración se diseñaron para evitar el mismo conflicto de conciliación doble que el resultado. Ambos conciliadores emiten llamadas a la API AWS en competencia y escriben actualizaciones contradictorias en el estado del recurso personalizado.

Para evitarlo, antes de ejecutar un controlador de versión preliminar autoadministrado junto con la capacidad.

  • Habilite la elección de líder en el controlador de versión preliminar autoadministrado y dirija el arrendamiento a kube-system con la misma configuración leaderElection.enabled=true y leaderElection.namespace=kube-system que se muestra en los pasos de migración. De este modo, se garantiza que, si el controlador se promueve y la capacidad se hace cargo de él, los dos se coordinen mediante un arrendamiento compartido en lugar de conciliarse en paralelo.

  • Haga un seguimiento del estado de GA ascendente de todos los controladores de versión preliminar de los que dependa y planifique migrarlos según la ruta de migración cuando se promuevan. Puede comprobar el estado actual de cada controlador en la página de servicios de ACK del sitio web de ACK.

Siguientes pasos