Servicios de Amazon ECS

Puede utilizar un servicio de Amazon ECS para ejecutar y mantener un número determinado de instancias de una definición de tarea de manera simultánea en un clúster de Amazon ECS. Si una de las tareas falla o se detiene, el programador de servicios de Amazon ECS lanza otra instancia de su definición de tarea para sustituirla. Esto ayuda a mantener el número deseado de tareas en el servicio.

También puede ejecutar el servicio detrás de un equilibrador de carga. El balanceador de carga distribuye el tráfico entre las tareas que están asociadas al servicio.

Conceptos del programador de servicio

Se recomienda utilizar el programador de servicios para los servicios y aplicaciones sin estado de larga duración. El programador de servicios garantiza el cumplimiento de la estrategia de programación especificada y reprograma las tareas cuando alguna de ellas falla. Por ejemplo, si falla la infraestructura subyacente, el programador de servicios puede reprogramar una tarea. Puede utilizar estrategias de ubicación de tareas y restricciones para personalizar el modo en que el programador ubica y termina las tareas. Si se detiene una tarea de un servicio, el programador lanza una nueva tarea para sustituirla. Este proceso continúa hasta que el servicio alcanza el número deseado de tareas en función de la estrategia de programación que utiliza el servicio. La estrategia de programación del servicio también se denomina tipo de servicio.

El programador de servicios también reemplaza las tareas que se determina que están en mal estado después de que se produzca un error en una comprobación de estado del contenedor o en una comprobación de estado del grupo objetivo del equilibrador de cargas. Este reemplazo depende de los parámetros de definición del servicio maximumPercent y desiredCount. Si una tarea está marcada como en mal estado, el programador de servicios iniciará primero una tarea de reemplazo. Si la tarea de reemplazo tiene un estado de HEALTHY, el programador de servicios puede detener la tarea en mal estado. Si la tarea de reemplazo tiene un estado de UNHEALTHY, el programador detendrá la tarea de reemplazo en mal estado o la tarea existente en mal estado para igualar el recuento total de tareas en desiredCount. Si el parámetro maximumPercent impide que el programador inicie primero una tarea de reemplazo, detendrá las tareas en mal estado de forma aleatoria de una en una para liberar capacidad y, a continuación, iniciará una tarea de reemplazo. El proceso de inicio y parada continúa hasta que todas las tareas en mal estado se sustituyan por tareas en buen estado. Una vez que se hayan reemplazado todas las tareas en mal estado y solo se estén ejecutando las tareas en buen estado, si el recuento total de tareas supera el límite de desiredCount, las tareas en buen estado se detienen aleatoriamente hasta que el recuento total de tareas sea igual a desiredCount. Para obtener más información sobre maximumPercent y desiredCount, consulte Parámetros de definición de servicios.

nota

Este comportamiento no se aplica a las tareas que ejecutan y mantienen los servicios que utilizan el tipo de implementación de actualizaciones continuas. Durante una actualización continua, el programador de servicios primero detiene las tareas en mal estado y, a continuación, inicia las tareas de reemplazo.

El programador de servicios incluye una lógica que limita la frecuencia con la que se reinician las tareas si estas fallan de forma repetida Si una tarea se detiene sin haber entrado en estado RUNNING, el programador de servicios comienza a ralentizar los intentos de lanzamiento y envía un mensaje de evento de servicio. Este comportamiento impide que se utilicen recursos innecesarios para tareas fallidas antes de poder resolver el problema. Una vez que el servicio de actualiza, el programador de servicios retoma el comportamiento normal de programación. Para obtener más información, consulte Lógica de aceleración del servicio Amazon ECS y Mensajes de eventos de servicio.

Existen dos estrategias del programador de servicio:

• REPLICA: la estrategia de programación de réplicas sitúa y mantiene en el clúster el número de tareas deseado. De forma predeterminada, el programador de servicio distribuye las tareas en zonas de disponibilidad. Puede utilizar estrategias y restricciones de ubicación de tareas para personalizar las decisiones de ubicación de las tareas. Para obtener más información, consulte Réplica.

• DAEMON: la estrategia de programación del daemon implementa exactamente una tarea en cada instancia de contenedor activa que cumpla todas las restricciones de ubicación de tareas que se especifiquen para el clúster. Cuando se utiliza esta estrategia, no es necesario especificar un número deseado de tareas, ni una estrategia de ubicación de tareas ni utilizar políticas de Auto Scaling de servicios. Para obtener más información, consulte Daemon.

  nota

  Las tareas de Fargate no admiten la estrategia de programación de DAEMON.

Daemon

La estrategia de programación de daemons implementa exactamente una tarea en cada instancia de contenedor activa que cumpla todas las restricciones de ubicación de tareas especificadas en el clúster. El programador de servicios también evalúa las restricciones de ubicación de las tareas en ejecución y detiene las tareas que no cumplen las restricciones de ubicación. Cuando se utiliza esta estrategia, no es necesario especificar un número deseado de tareas, una estrategia de ubicación de tareas o utilizar políticas de Auto Scaling de Servicios.

Amazon ECS reserva los recursos de computación de la instancia de contenedor, incluido CPU, memoria e interfaces de red, para las tareas del daemon. Cuando se lanza un servicio daemon en un clúster con otros servicios de réplica, Amazon ECS prioriza la tarea del daemon. Esto significa que la tarea del daemon es la primera en lanzarse en las instancias y la última en detenerse. Esta estrategia garantiza que las tareas de réplica pendientes no utilicen esos recursos y estén disponibles para las tareas del daemon.

El programador de servicios del daemon no ubica tareas en las instancias que tienen el estado DRAINING. Si una instancia de contenedor cambia al estado DRAINING, las tareas del daemon que incluya se detienen. El programador de servicios garantiza que las tareas de daemon sean las últimas en detenerse una vez que se hayan detenido todas las tareas de réplica. El programador de servicios también monitorea cuándo se agregan nuevas instancias de contenedor al clúster y agrega las tareas de daemon en ellas.

Si se especifica una configuración de implementación, el porcentaje máximo del parámetro debe ser 100. El valor predeterminado de un servicio daemon maximumPercent es del 200%. El valor predeterminado de minimumHealthyPercent para un servicio del daemon es del 0 %.

Debe reiniciar el servicio cuando cambie las restricciones de ubicación del servicio del daemon. Amazon ECS actualiza de forma dinámica los recursos reservados en instancias aptas para la tarea del daemon. Para las instancias existentes, el programador intenta ubicar la tarea en la instancia.

Una nueva implementación se inicia cuando hay un cambio en el tamaño de la tarea o en la reserva de recursos del contenedor en la definición de la tarea. Amazon ECS recoge las reservas de memoria y CPU actualizadas para el daemon y, a continuación, bloquea esa capacidad para la tarea del daemon.

Si no hay recursos suficientes para cualquiera de los casos anteriores, ocurre lo siguiente:

• Se produce un error en la ubicación de la tarea.

• Se genera un CloudWatch evento.

• Amazon ECS continúa intentando programar la tarea en la instancia a la espera de que los recursos estén disponibles.

• Amazon ECS libera todas las instancias reservadas que ya no cumplan con los criterios de restricción de ubicación y detiene las tareas de daemon correspondientes.

La estrategia de programación de daemon se puede utilizar en los siguientes casos:

• Ejecución de contenedores de aplicaciones

• Ejecución de contenedores de soporte para tareas de registro, monitoreo y seguimiento

Las tareas que utilizan el tipo de lanzamiento de Fargate o los tipos de controlador de implementación CODE_DEPLOY o EXTERNAL no admiten la estrategia de programación del daemon.

Cuando el programador de servicios detiene las tareas en ejecución, intenta mantener un balance entre las zonas de disponibilidad del clúster. El programador utiliza la siguiente lógica:

• Si se ha definido una estrategia de ubicación, utilice esta estrategia para seleccionar las tareas que deben terminar. Por ejemplo, si un servicio tiene definida una estrategia de distribución de zonas de disponibilidad, se seleccionará una tarea que deje a las demás tareas con la mejor distribución.

• Si no hay ninguna estrategia de ubicación definida, mantenga el equilibrio entre las zonas de disponibilidad de su clúster con la siguiente lógica:

  • Ordene las instancias de contenedor válidas. Dé prioridad a las instancias que tienen el mayor número de tareas en ejecución para este servicio en su respectiva zona de disponibilidad. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen dos cada una, las instancias de contenedor en la zona B o C se consideran óptimas para terminación.

  • Detenga la tarea en una instancia de contenedor en una zona de disponibilidad óptima en función de los pasos anteriores. Priorice las instancias de contenedores con el mayor número de tareas en ejecución para este servicio.

Réplica

La estrategia de programación de réplicas sitúa y mantiene en el clúster el número de tareas deseado.

En el caso de un servicio que ejecuta tareas en Fargate, cuando el programador de servicios lanza nuevas tareas o deja de ejecutarlas, el programador de servicios hace lo mejor para mantener un equilibrio entre las zonas de disponibilidad. No es necesario especificar estrategias ni restricciones de ubicación de tareas.

Al crear un servicio que ejecuta tareas en instancias EC2, tiene la opción de especificar estrategias y restricciones de ubicación de tareas a fin de personalizar las decisiones de ubicación de tareas. Si no se especifican estrategias o restricciones de ubicación de tareas, el programador de servicios repartirá las tareas de forma predeterminada entre las zonas de disponibilidad. El programador de servicios utiliza la siguiente lógica:

• Determina cuál de las instancias de contenedor de su clúster puede admitir la definición de la tarea de su servicio (por ejemplo, la CPU, la memoria, los puertos y los atributos de la instancia de contenedor requeridos).

• Determina qué instancias de contenedor satisfacen las restricciones de ubicación definidas para el servicio.

• Si tiene un servicio de réplica que depende de un servicio de daemon (por ejemplo, una tarea del enrutador del registro de daemon que debe estar ejecutándose antes de que las tareas puedan utilizar el registro), cree una restricción de ubicación de tareas que garantice que las tareas del servicio de daemon se coloquen en la instancia de EC2 antes que las tareas del servicio de réplica. Para obtener más información, consulte Ejemplo de restricciones de ubicación de tareas en Amazon ECS.

• Cuando hay una estrategia de ubicación definida, utilice esa estrategia para seleccionar una instancia entre los candidatos restantes.

• Si no hay ninguna estrategia de ubicación definida, utilice la siguiente lógica para equilibrar las tareas entre las zonas de disponibilidad de su clúster:

  • Ordena las instancias de contenedor válidas. Da prioridad a las instancias que tienen el menor número de tareas en ejecución para este servicio en su respectiva zona de disponibilidad. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen cero cada una, las instancias de contenedor válidas en la zona B o C se consideran óptimas para colocación.

  • Ubica la nueva tarea de servicio en una instancia de contenedor válida en una zona de disponibilidad óptima en función de los pasos anteriores. Favorece las instancias de contenedores con el menor número de tareas en ejecución para este servicio.

Conceptos adicionales del servicio

• Si lo desea, puede ejecutar su servicio detrás de un balanceador de carga. Para obtener más información, consulte Distribuya el tráfico del servicio Amazon ECS mediante el equilibrio de carga.

• Opcionalmente puede especificar una configuración de implementación del servicio. Se inicia una implementación mediante la actualización de la definición de tareas de un servicio. Durante una implementación, el programador de servicio utiliza los parámetros porcentaje mínimo en buen estado y porcentaje máximo para determinar la estrategia de implementación. Para obtener más información, consulte Parámetros de definición de servicio.

• También puede optar por configurar el servicio para que utilice la detección de servicios de Amazon ECS. La detección de servicios utiliza las API de AWS Cloud Map asignación automática de nombres para administrar las entradas de DNS para las tareas del servicio. Esto hace que se puedan detectar desde la VPC. Para obtener más información, consulte Detección de servicios.

• Cuando se elimina un servicio, si todavía hay tareas en ejecución que requieren limpieza, el estado del servicio pasa de ACTIVE a DRAINING y deja de estar visible en la consola o en la operación de la API de ListServices. Después de que todas las tareas pasen al estado STOPPING o STOPPED, el estado del servicio cambia de DRAINING a INACTIVE. Los servicios con el estado DRAINING o INACTIVE se pueden ver mediante la operación de la API DescribeServices. Sin embargo, en el futuro, es posible que los servicios con el estado INACTIVE se limpien y se eliminen del registro de Amazon ECS y que las llamadas a DescribeServices en esos servicios generen un error ServiceNotFoundException.

• El tiempo de incorporación es un periodo que transcurre después de que la nueva versión del servicio se escala horizontalmente y la versión anterior se reduce horizontalmente, durante el cual Amazon ECS sigue monitoreando la alarma asociada a la implementación. Amazon ECS calcula este periodo en función de la configuración de alarma asociada a la implementación.

  El tiempo de inactividad solo se aplica cuando se utilizan CloudWatch alarmas para detectar errores de implementación. Para obtener más información, consulte Métodos de detección de errores.