Estrategias de actualización de nodos

En esta página se describen las estrategias de actualización de nodos que puedes usar con tus clústeres de Google Kubernetes Engine (GKE).

En los clústeres de GKE Standard, puedes configurar una de las siguientes estrategias de actualización de nodos para cada grupo de nodos:

  • Actualizaciones de picos: los nodos se actualizan en una ventana de tiempo. Puedes controlar cuántos nodos se pueden actualizar a la vez y cómo afectan las actualizaciones a las cargas de trabajo.
  • Actualizaciones azul-verde: los nodos actuales se mantienen disponibles para revertir los cambios mientras se validan las cargas de trabajo en la nueva configuración de nodos.

GKE elige las siguientes estrategias para estos casos concretos:

  • En los clústeres de Autopilot, GKE usa actualizaciones de picos. Para obtener más información, consulta la sección Actualizaciones de picos de la página Actualizaciones de clústeres de Autopilot.
  • En el caso de los nodos de inicio flexible, que usan Dynamic Workload Scheduler, GKE utiliza actualizaciones de corta duración. Flex-start con aprovisionamiento en cola admite nuevas marcas que forman parte del lanzamiento de la vista previa de flex-start.

Si eliges una estrategia de actualización para tu grupo de nodos de clúster estándar, puedes seleccionar el proceso que mejor se adapte a tus necesidades en cuanto a velocidad, interrupción de la carga de trabajo, mitigación de riesgos y optimización de costes. Para obtener más información sobre qué estrategia de actualización de nodos es la adecuada para tu entorno, consulta Elegir actualizaciones de oleada y Elegir actualizaciones azul-verde.

Con ambas estrategias, puedes configurar los ajustes de actualización para optimizar el proceso en función de las necesidades de tu entorno. Para obtener más información, consulta Configurar la estrategia de actualización que hayas elegido. Asegúrate de que tienes suficiente cuota, disponibilidad de recursos o capacidad de reserva para actualizar los nodos con la estrategia que elijas. Para obtener más información, consulta Asegurar recursos para las actualizaciones de nodos.

Sobreaprovisionamiento para actualizaciones

Las actualizaciones de oleada son la estrategia de actualización predeterminada y la más adecuada para las aplicaciones que pueden gestionar cambios incrementales. Las actualizaciones de oleada usan un método de actualización gradual de los nodos en un orden indefinido. Encuentra el equilibrio óptimo entre velocidad e interrupción para tu entorno eligiendo cuántos nodos nuevos y de aumento se pueden crear con maxSurge y cuántos nodos se pueden interrumpir a la vez con maxUnavailable.

Las actualizaciones de picos también funcionan con la herramienta de ajuste automático de escala de clústeres para evitar cambios en los nodos que se están actualizando.

Elegir actualizaciones de picos de demanda para tu entorno

Si la optimización de costes es importante para ti y tu carga de trabajo puede tolerar que se cierre en menos de 60 minutos, te recomendamos que elijas las actualizaciones de picos de uso para tus grupos de nodos.

Las actualizaciones de aumento son óptimas en los siguientes casos:

  • Si quieres optimizar la velocidad de las actualizaciones.
  • Si las cargas de trabajo toleran mejor las interrupciones, en cuyo caso se acepta una finalización correcta de hasta 60 minutos.
  • Si quieres controlar los costes minimizando la creación de nodos.

Cuándo usa GKE las actualizaciones de aumento

Si está habilitada, GKE usa las actualizaciones de picos cuando se producen los siguientes tipos de cambios:

Otros cambios, como aplicar actualizaciones a las etiquetas y los taints de los nodos de los grupos de nodos existentes, no usan actualizaciones de oleada, ya que no requieren recrear los nodos.

Información sobre los ajustes de sobreaprovisionamiento para actualizaciones

Usa los ajustes de actualización de picos para seleccionar el equilibrio adecuado entre velocidad e interrupción de tu grupo de nodos durante el mantenimiento del clúster. Puedes cambiar el número de nodos que GKE intenta actualizar a la vez modificando los parámetros de actualización simultánea de un grupo de nodos Estándar.

El comportamiento de la actualización de Surge se determina mediante los ajustes maxSurge y maxUnavailable, que determinan cuántos nodos se actualizan al mismo tiempo en una ventana de actualización gradual con los pasos descritos.

maxSurge: GKE crea un nuevo nodo de aumento antes de eliminar uno que ya exista

Define maxSurge para elegir el número máximo de nodos adicionales de aumento que se pueden añadir al grupo de nodos durante una actualización por zona, lo que aumenta la probabilidad de que las cargas de trabajo que se ejecutan en el nodo actual puedan migrar a un nuevo nodo inmediatamente. El valor predeterminado es 1. Para actualizar un nodo, GKE sigue estos pasos:

  1. Aprovisiona un nuevo nodo.
  2. Espera a que el nuevo nodo esté listo.
  3. Acordonar el nodo.
  4. Drena el nodo actual, respetando PodDisruptionBudget y GracefulTerminationPeriod durante un máximo de una hora. Al cabo de una hora, se expulsarán de forma forzosa los pods restantes para que se pueda continuar con la actualización.
  5. Elimina el nodo que ya tienes.

Para que GKE cree nodos de aumento, tu proyecto debe tener los recursos necesarios para crear nodos adicionales de forma temporal. Si no tienes capacidad adicional, GKE no empezará a actualizar un nodo hasta que los recursos estén disponibles. Para obtener más información, consulta Recursos para las actualizaciones de picos de demanda.

maxUnavailable: GKE inhabilita un nodo para volver a crearlo

Define maxUnavailable para elegir el número máximo de nodos que pueden no estar disponibles simultáneamente durante una actualización por zona. El valor predeterminado es cero. Es posible que las cargas de trabajo que se ejecutan en el nodo actual tengan que esperar a que se actualice el nodo, si no hay otros nodos con capacidad. Para actualizar un nodo, GKE sigue estos pasos:

  1. Acordonar el nodo.
  2. Drena el nodo actual, respetando los ajustes de PodDisruptionBudget y GracefulTerminationPeriod durante un máximo de una hora. Al cabo de una hora, se expulsarán de forma forzosa los pods restantes para que se pueda continuar con la actualización.
  3. Vuelve a crear el nodo con la nueva configuración.
  4. Espera a que el nodo esté listo.
  5. Desactiva el acordonamiento del nodo actualizado.

Cuando GKE vuelve a crear el nodo, libera temporalmente la capacidad del nodo si no procede de una reserva. Esto significa que, si la capacidad es limitada, corres el riesgo de perder la capacidad actual. Por lo tanto, si tu entorno tiene recursos limitados, utiliza este ajuste solo si usas nodos reservados. Para obtener más información, consulta Actualizar en un entorno con recursos limitados.

Ejemplo de uso de los ajustes de maxSurge y maxUnavailable

Por ejemplo, un clúster de GKE tiene un grupo de nodos de una sola zona con 5 nodos y la siguiente configuración de actualización gradual: maxSurge=2;maxUnavailable=1.

Durante una actualización de aumento con este grupo de nodos, en una ventana de tiempo, GKE crea dos nodos actualizados y afecta a un nodo como máximo a la vez. GKE elimina como máximo tres nodos después de que los nodos actualizados estén listos. Durante el proceso de actualización, el grupo de nodos incluirá entre cuatro y siete nodos.

Consideraciones sobre los ajustes de sobreaprovisionamiento para actualizaciones

Ten en cuenta la siguiente información antes de configurar los ajustes de actualización de subida de tensión:

Ajustar la configuración de la actualización de subida de tensión para equilibrar la velocidad y las interrupciones

En la siguiente tabla se describen cuatro perfiles de actualización diferentes como ejemplos para ayudarte a entender las distintas configuraciones:

Descripción Configuración Caso práctico habitual
Equilibrado (predeterminado), más lento, pero menos disruptivo maxSurge=1 maxUnavailable=0 Mayoría de cargas de trabajo
Rápido, sin recursos de aumento, el más disruptivo maxSurge=0 maxUnavailable=20 Grupos de nodos grandes después de que las tareas se hayan ejecutado hasta completarse
Rápido, con la mayoría de los recursos de aumento y menos disruptivo maxSurge=20 maxUnavailable=0 Grupos de nodos grandes
La más lenta, disruptiva y sin recursos de aumento maxSurge=0 maxUnavailable=1 Grupo de nodos con limitaciones de recursos y reserva

Equilibrado (predeterminado)

La forma más sencilla de aprovechar las actualizaciones de picos es usar la configuración predeterminada, maxSurge=1;maxUnavailable=0. Con esta configuración, las actualizaciones se realizan lentamente, ya que solo se añade un nodo de pico a la vez, lo que significa que solo se actualiza un nodo a la vez. Los pods pueden reiniciarse inmediatamente en el nuevo nodo de sobrecarga. Esta configuración solo requiere que los recursos creen temporalmente un nodo nuevo.

Rápido y sin recursos adicionales

Si tienes un grupo de nodos grande y tu carga de trabajo no es sensible a las interrupciones (por ejemplo, un trabajo por lotes que se ha completado), usa la siguiente configuración para maximizar la velocidad sin usar recursos adicionales: maxSurge=0;maxUnavailable=20. Esta configuración no activa nodos de sobrecarga adicionales y permite actualizar 20 nodos al mismo tiempo.

Rápido y menos disruptivo

Si tu carga de trabajo es sensible a las interrupciones y ya has configurado PodDisruptionBudgets (PDB) y no usas externalTrafficPolicy: Local, que no funciona con el drenaje de nodos en paralelo, puedes aumentar la velocidad de la actualización con maxSurge=20;maxUnavailable=0. Esta configuración actualiza 20 nodos en paralelo, mientras que el PDB limita el número de pods que se pueden vaciar en un momento dado. Aunque las configuraciones de los PDBs pueden variar, si creas un PDB con maxUnavailable=1 para una o varias cargas de trabajo que se ejecuten en el grupo de nodos, solo se podrá desalojar un Pod de esas cargas de trabajo a la vez, lo que limitará el paralelismo de toda la actualización. Esta configuración requiere que los recursos creen temporalmente 20 nodos.

Lento, pero sin recursos de aumento

Si no puedes usar ningún recurso adicional, puedes usar maxSurge=0;maxUnavailable=1 para recrear los nodos de uno en uno.

Controlar una actualización con compensación en curso

Con las actualizaciones de sobrecarga, mientras se lleva a cabo una actualización, puedes usar comandos para ejercer cierto control sobre ella. Para tener más control sobre el proceso de actualización, te recomendamos que uses las actualizaciones azul-verde.

Cancelar (pausar) una actualización con compensación

Puedes cancelar una actualización de subida de tensión en curso en cualquier momento durante el proceso de actualización. Si cancelas la actualización, se pausará y GKE dejará de actualizar los nodos nuevos, pero no se revertirá automáticamente la actualización de los nodos que ya se hayan actualizado. Después de cancelar una actualización, puedes reanudarla o restaurar la versión anterior.

Cuando cancelas una actualización, GKE hace lo siguiente con cada uno de los nodos:

  • Los nodos que hayan iniciado la actualización la completarán.
  • Los nodos que no hayan iniciado la actualización no se actualizarán.
  • Los nodos que ya hayan completado la actualización correctamente no se verán afectados y no se revertirán.

Esto significa que el grupo de nodos puede acabar en un estado en el que los nodos ejecuten dos versiones diferentes. Si las actualizaciones automáticas están habilitadas en el grupo de nodos, se puede programar otra actualización automática para el grupo de nodos, lo que actualizaría los nodos restantes del grupo que ejecutan la versión anterior.

Consulta cómo cancelar una actualización de un grupo de nodos.

Reanudar una actualización con compensación

Si se ha cancelado una actualización de un grupo de nodos y se ha completado parcialmente, puedes reanudarla para completar el proceso de actualización del grupo de nodos. De esta forma, se actualizarán los nodos restantes que no se hayan actualizado en la operación original. Consulta cómo reanudar una actualización de un grupo de nodos.

Restaurar una actualización con compensación

Si un grupo de nodos se actualiza parcialmente, puedes restaurarlo para que vuelva a su estado anterior. No puedes revertir los grupos de nodos después de que se hayan actualizado correctamente. Los nodos que no hayan iniciado una actualización no se verán afectados. Consulta cómo revertir una actualización de un grupo de nodos.

Si quieres volver a la versión anterior de un grupo de nodos después de haber completado la actualización, consulta Volver a una versión anterior de un grupo de nodos.

Actualizaciones azul-verde

Las actualizaciones azul-verde son una estrategia de actualización alternativa a la estrategia de actualización de picos predeterminada. Con las actualizaciones azul-verde, GKE primero crea un nuevo conjunto de recursos de nodo (nodos "verdes") con la nueva configuración de nodo antes de desalojar las cargas de trabajo de los recursos originales (nodos "azules"). GKE conserva los recursos "azules", si es necesario, para revertir las cargas de trabajo hasta que se cumpla el tiempo de permanencia. Puedes ajustar el ritmo de las actualizaciones y el tiempo de permanencia en función de las necesidades de tu entorno.

Con esta estrategia, tienes más control sobre el proceso de actualización. Si es necesario, puedes revertir una actualización en curso, ya que el entorno original se mantiene durante la actualización. Sin embargo, esta estrategia de actualización también requiere más recursos. Como el entorno original se replica, el grupo de nodos usa el doble de recursos durante la actualización.

Elegir actualizaciones azul-verde para tu entorno

Si tienes cargas de trabajo de producción de alta disponibilidad que necesitas poder revertir rápidamente en caso de que la carga de trabajo no tolere la actualización y se pueda aceptar un aumento temporal de los costes, te recomendamos que elijas las actualizaciones azul-verde para tus grupos de nodos.

Las actualizaciones azul-verde son óptimas en los siguientes casos:

  • Si quieres una implementación gradual en la que la mitigación de riesgos sea lo más importante y necesites una finalización gradual de más de 60 minutos.
  • si tus cargas de trabajo toleran menos las interrupciones.
  • Si se acepta un aumento temporal de los costes debido a un mayor uso de los recursos.

Cuándo usa GKE las actualizaciones azul-verde

En el caso de los nodos de GKE, hay diferentes tipos de cambios de configuración que requieren que se vuelvan a crear los nodos. Si está habilitada, GKE usa actualizaciones azul-verde cuando se producen los siguientes tipos de cambios:

Las actualizaciones de Surge se usarán para cualquier otra función que requiera que se vuelvan a crear los nodos. Para obtener más información, consulta Cuándo se usan las actualizaciones de aumento.

Fases de las actualizaciones azul-verde

Con las actualizaciones azul-verde, puedes personalizar y controlar el proceso de las siguientes formas:

En esta sección se explican las fases del proceso de actualización. Puedes usar los ajustes de actualización para configurar cómo funcionan las fases y los comandos para controlar el proceso de actualización.

Fase 1: Crear un grupo verde

En esta fase, se crea un nuevo conjunto de grupos de instancias gestionadas (MIGs), conocido como el grupo "verde", para cada zona del grupo de destino con la nueva configuración de nodos (nueva versión o tipo de imagen).

Se comprobará la Quota antes de empezar a aprovisionar nuevos recursos verdes.

En esta fase, el escalador automático de clústeres de los MIGs originales (conocido como el grupo azul) dejará de aumentar o reducir la escala. El grupo verde solo puede aumentar en esta fase.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, la actualización se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. En esta fase, si revierte la versión, se eliminará el grupo verde.

Fase 2: Cordon blue pool

En esta fase, todos los nodos originales del grupo azul (los MIGs) se acordonarán (se marcarán como no programables). Las cargas de trabajo que ya tengas seguirán ejecutándose, pero las nuevas no se programarán en los nodos actuales.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, la actualización se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. En esta fase, la reversión desactivará el acordonamiento de la piscina azul y eliminará la verde.

Fase 3: Drenar el grupo azul

En esta fase, los nodos originales del grupo azul (MIGs) se vaciarán por lotes. Cuando Kubernetes anula un nodo, se envían solicitudes de desalojo a todos los pods que se ejecutan en el nodo. Los pódcasts se reprogramarán. Los pods que tengan infracciones de PodDisruptionBudget o un valor de terminationGracePeriodSeconds largo durante el drenaje se eliminarán en la fase Eliminar grupo azul cuando se elimine el nodo. Puedes usar BATCH_SOAK_DURATION y NODE_POOL_SOAK_DURATION, que se describen aquí y en la siguiente sección, para ampliar el periodo antes de que se eliminen los pods.

Puedes controlar el tamaño de los lotes con cualquiera de los siguientes ajustes:

  • BATCH_NODE_COUNT: el número absoluto de nodos que se van a vaciar en un lote.
  • BATCH_PERCENT: porcentaje de nodos que se van a vaciar en un lote, expresado como un decimal entre 0 y 1, ambos incluidos. GKE redondea a la baja al porcentaje de nodos más cercano, con un valor mínimo de 1 nodo, si el porcentaje no es un número entero de nodos.

Si alguno de estos ajustes se establece en cero, GKE omite esta fase y pasa a la fase Soak node pool (Grupo de nodos de prueba).

Además, puedes controlar el tiempo que se empapa cada lote con BATCH_SOAK_DURATION. Esta duración se define en segundos y el valor predeterminado es cero segundos.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, la actualización se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. Si el lote anterior ya se ha agotado y reanudas la actualización, es posible que el siguiente lote de nodos se procese inmediatamente sin respetar el BATCH_SOAK_DURATION de ese lote. Si vuelves a la versión anterior en esta fase, se detendrá el vaciado del grupo azul y se quitará la valla. Las cargas de trabajo se pueden reprogramar en el grupo azul (no es seguro) y el grupo verde se vacía y se elimina.

Fase 4: Poner a prueba el grupo de nodos

Esta fase se utiliza para que verifiques el estado de la carga de trabajo después de que se hayan vaciado los nodos del grupo azul.

El tiempo de permanencia se define con NODE_POOL_SOAK_DURATION, en segundos. De forma predeterminada, se establece en una hora (3600 segundos). Si la duración total de la prueba alcanza los 7 días (604.800 segundos), se iniciará inmediatamente la fase de eliminación del grupo azul.

La duración total de la prueba de resistencia es la suma de NODE_POOL_SOAK_DURATION más BATCH_SOAK_DURATION multiplicado por el número de lotes, que se determina mediante BATCH_NODE_COUNT o BATCH_PERCENT.

En esta fase, puedes completar la actualización y saltarte el tiempo de prueba restante completando la actualización. De esta forma, se iniciará inmediatamente el proceso de eliminación de los nodos del grupo azul.

Si es necesario, puedes cancelar la actualización. Cuando cancelas una actualización azul-verde, la actualización se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla.

En esta fase, la herramienta de escalado automático de clústeres puede aumentar o reducir la escala del grupo verde con normalidad.

Fase 5: Eliminar el grupo azul

Una vez transcurrido el tiempo de remojo, los nodos del grupo azul se eliminarán del grupo de destino. Esta fase no se puede pausar. Además, en esta fase no se usa la expulsión, sino que se intenta eliminar los pods. A diferencia del desalojo, la eliminación no respeta los PDBs y elimina los pods de forma forzosa. La eliminación limita la duración de un pódcast a terminationGracePeriodSeconds minutos. Después de este último intento de eliminar los pods restantes, los nodos del grupo azul se eliminan del grupo de nodos.

Cuando finalice esta fase, tu grupo de nodos solo tendrá nodos nuevos con la configuración actualizada (versión o tipo de imagen).

Cómo funciona la herramienta de ajuste automático de escala de clústeres con las actualizaciones azul-verde

Durante las fases de una actualización azul-verde, el grupo "azul" original no se amplía ni se reduce. Cuando se crea el nuevo grupo "verde", solo se puede aumentar su tamaño hasta la fase del grupo de nodos de prueba, en la que se puede aumentar o reducir. Si se revierte una actualización, el grupo "azul" original puede aumentar su capacidad durante este proceso si se necesita más.

Controlar una actualización azul-verde en curso

Con las actualizaciones azul-verde, mientras se lleva a cabo una actualización, puedes usar comandos para controlarla. De esta forma, tendrás un alto nivel de control sobre el proceso por si, por ejemplo, determinas que tus cargas de trabajo deben volver a la configuración de nodo anterior.

Cancelar (pausar) una actualización azul-verde

Si cancelas una actualización azul-verde, la pausarás en la fase en la que se encuentre. Este comando se puede usar en todas las fases, excepto en la fase de eliminación del grupo azul. Cuando se cancele, el grupo de nodos se pausará en un estado intermedio en función de la fase en la que se haya emitido la solicitud.

Consulta cómo cancelar una actualización de un pool de nodos.

Una vez cancelada la actualización, puedes elegir entre dos opciones: reanudar o restaurar la versión anterior.

Reanudar una actualización azul-verde

Si has determinado que se puede continuar con la actualización, puedes reanudarla.

Si reanudas el proceso, la actualización continuará en la fase intermedia en la que se pausó. Para saber cómo reanudar la actualización de un grupo de nodos, consulta Reanudar la actualización de un grupo de nodos.

Revertir una actualización azul-verde

Si has determinado que la actualización no debe continuar y quieres restaurar el grupo de nodos a su estado original, puedes revertir el proceso. Para saber cómo revertir una actualización de un grupo de nodos, consulta Revertir una actualización de un grupo de nodos.

Con el flujo de trabajo de reversión, el proceso se invierte para devolver el grupo de nodos a su estado original. Se quitará el cordón de la piscina azul para que se puedan reprogramar las cargas de trabajo en ella. Durante este proceso, la herramienta de ajuste automático de escala del clúster puede aumentar la escala del grupo azul según sea necesario. La piscina verde se vaciará y se eliminará.

Si quieres volver a la versión anterior de un grupo de nodos después de haber completado la actualización, consulta Volver a una versión anterior de un grupo de nodos.

Completar una actualización azul-verde

Durante la fase de prueba, puedes completar una actualización si has determinado que la carga de trabajo no necesita más validación en la nueva configuración de nodos y que se pueden quitar los nodos antiguos. Si completas una actualización, se omitirá el resto de la fase de prueba de resistencia y se pasará a la fase de eliminación del grupo azul.

Para obtener más información sobre cómo usar el comando complete, consulta Completar una actualización de un grupo de nodos azul-verde.

Mejoras de corta duración (solo con inicio flexible y aprovisionamiento en cola)

Las actualizaciones de corta duración son una estrategia de actualización de nodos que se usa exclusivamente con nodos flex-start y nodos que usan el aprovisionamiento en cola (con 1.32.2-gke.1652000 o versiones posteriores), ambos basados en Dynamic Workload Scheduler. Para obtener más información sobre los nodos que usan actualizaciones de corta duración, consulta Información sobre la disponibilidad de las GPUs con Dynamic Workload Scheduler.

GKE usa la estrategia de actualización de corta duración para los grupos de nodos y los grupos de nodos estándar de los clústeres de Autopilot.

Con esta estrategia, GKE actualiza estos nodos de tiempo de ejecución limitados sin interrumpir las cargas de trabajo. La estrategia funciona de la siguiente manera:

  1. Los nodos que ya tengas se ejecutarán hasta que se les asigne prioridad.
  2. Los nodos nuevos usan la nueva configuración de nodos.
  3. En un plazo máximo de siete días, los nodos pasarán de ejecutar la configuración actual a ejecutar la nueva.

GKE configura automáticamente esta estrategia para los nodos de inicio flexible. Esta estrategia no tiene ajustes de configuración.

Cuándo usa GKE actualizaciones de corta duración

GKE configura automáticamente los nodos de inicio flexible para que usen actualizaciones de corta duración. Los nodos que solo usan el aprovisionamiento en cola, pero que se ejecutan en clústeres con la versión 1.32.2-gke.1652000 de GKE o una posterior, también usan actualizaciones de corta duración.

En los grupos de nodos y los grupos de nodos de Autopilot que usan actualizaciones de corta duración, GKE usa esta estrategia en situaciones en las que, de lo contrario, se usarían actualizaciones de aumento. Además de las actualizaciones de nodos (cambios de versión), GKE usa actualizaciones de corta duración para otros tipos de actualizaciones de nodos, de forma similar a como se usan las actualizaciones de aumento. Para obtener más información, consulta Cuándo se usan las actualizaciones de aumento.

Siguientes pasos