Prácticas recomendadas para actualizar clústeres de Google Distributed Cloud

En este documento se describen las prácticas recomendadas y los aspectos que se deben tener en cuenta para actualizar Google Distributed Cloud. Aprenderás a prepararte para las actualizaciones de clústeres y las prácticas recomendadas que debes seguir antes de la actualización. Estas prácticas recomendadas ayudan a reducir los riesgos asociados a las actualizaciones de clústeres.

Si tienes varios entornos, como pruebas, desarrollo y producción, te recomendamos que empieces por el menos crítico, como pruebas, y que verifiques la funcionalidad de la actualización. Después de verificar que la actualización se ha realizado correctamente, pasa al siguiente entorno. Repite este proceso hasta que actualices tus entornos de producción. Este enfoque te permite pasar de un punto crítico a otro y verificar que la actualización y tus cargas de trabajo se ejecutan correctamente.

Lista de comprobación de la actualización

Para que el proceso de actualización sea lo más fluido posible, revisa y completa las siguientes comprobaciones antes de empezar a actualizar tus clústeres:

Planificar la actualización

Las actualizaciones pueden ser molestas. Antes de iniciar la actualización, planifica cuidadosamente el proceso para asegurarte de que tu entorno y tus aplicaciones estén listos. También es posible que tengas que programar la actualización fuera del horario de apertura habitual, cuando el tráfico sea menor.

Estimar el tiempo necesario y planificar una ventana de mantenimiento

De forma predeterminada, todos los grupos de nodos se actualizan en paralelo. Sin embargo, en cada grupo de nodos, los nodos se actualizan de forma secuencial, ya que cada nodo debe vaciarse y volver a crearse. Por lo tanto, el tiempo total de una actualización depende del número de nodos del grupo de nodos más grande. Para calcular una estimación aproximada del tiempo de actualización, multiplica 15 minutos por el número de nodos del grupo de nodos más grande. Por ejemplo, si tienes 10 nodos en el mayor grupo, el tiempo total de actualización sería de unos 15 * 10 = 150 minutos o 2,5 horas.

Hay varias formas de reducir el tiempo de actualización y facilitar la planificación y la programación de las actualizaciones:

  • En la versión 1.28 y posteriores, puedes acelerar una actualización configurando el valor de maxSurge para grupos de nodos concretos. Cuando actualizas nodos con maxSurge, varios nodos se actualizan al mismo tiempo que se tarda en actualizar un solo nodo.

  • Si tus clústeres tienen la versión 1.16 o una posterior, puedes saltarte una versión secundaria al actualizar los grupos de nodos. Si se realiza una actualización de versión omitida, el tiempo que se tarda en actualizar secuencialmente los grupos de nodos dos versiones se reduce a la mitad. Además, las actualizaciones de versiones omitidas te permiten aumentar el tiempo entre las actualizaciones necesarias para mantenerte en una versión compatible. Reducir el número de actualizaciones disminuye las interrupciones de la carga de trabajo y el tiempo de verificación. Para obtener más información, consulta Saltar una versión al actualizar grupos de nodos.

  • Puedes actualizar el plano de control de un clúster de usuarios por separado de los grupos de nodos. Esta flexibilidad puede ayudarte a planificar varias ventanas de mantenimiento más cortas en lugar de una larga para actualizar todo el clúster. Para obtener más información, consulta Actualizar grupos de nodos.

Crear una copia de seguridad del clúster de usuarios y del clúster de administrador

Antes de iniciar una actualización, crea una copia de seguridad de tus clústeres de usuarios y de administradores.

Una copia de seguridad de un clúster de usuarios es una instantánea del almacén etcd del clúster de usuarios. El almacén etcd contiene todos los objetos de Kubernetes y los objetos personalizados necesarios para gestionar el estado del clúster. La instantánea contiene los datos necesarios para recrear los componentes y las cargas de trabajo del clúster. Para obtener más información, consulta cómo crear una copia de seguridad de un clúster de usuario.

Con Google Distributed Cloud versión 1.8 y posteriores, puedes configurar copias de seguridad automáticas con clusterBackup.datastore en el archivo de configuración del clúster de administrador. Para habilitar esta función en un clúster, edita el archivo de configuración del clúster de administrador y añade el campo clusterBackup.datastore. A continuación, ejecuta gkectl update admin.

Una vez habilitado clusterBackup.datastore, se crea automáticamente una copia de seguridad de tu clúster de administrador en etcd en el almacén de datos de vSphere configurado. Este proceso de copia de seguridad se repite cada vez que se produce un cambio en el clúster de administrador. Cuando inicias una actualización de clúster, se ejecuta una tarea de copia de seguridad antes de actualizar el clúster.

Si tienes problemas y quieres restaurar un clúster de administrador a partir de su copia de seguridad, consulta Crear y restaurar una copia de seguridad de un clúster de administrador con gkectl.

Revisar el uso de PodDisruptionBudgets

En Kubernetes, los PodDisruptionBudgets (PDBs) pueden ayudar a evitar tiempos de inactividad o interrupciones no deseados de las aplicaciones. Los PDBs indican al programador que mantenga siempre un número de pods en ejecución mientras que otros pods pueden fallar. Este comportamiento es una forma útil de proporcionar disponibilidad de aplicaciones.

  1. Para comprobar qué PDBs están configurados en tu clúster, usa el comando kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Sustituye KUBECONFIG por el nombre de tu archivo kubeconfig.

    En el siguiente ejemplo de salida se muestran los PDBs istio-ingress, istiod y kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

En la tabla anterior, cada PDB especifica que siempre debe haber al menos un Pod disponible. Esta disponibilidad es fundamental durante las actualizaciones, cuando los nodos se vacían.

Comprueba si hay PDBs que no se pueden cumplir. Por ejemplo, puedes definir una disponibilidad mínima de 1 cuando la implementación solo tenga una réplica. En este ejemplo, la operación de drenaje se interrumpe porque el controlador de recursos no puede satisfacer el PDB.

Para asegurarte de que los PDBs no interfieran en el procedimiento de actualización, comprueba todos los PDBs de un clúster determinado antes de iniciar la actualización. Es posible que tengas que coordinarte con los equipos de desarrollo y los propietarios de las aplicaciones para cambiar o inhabilitar temporalmente los PDBs durante una actualización del clúster.

Google Distributed Cloud ejecuta una comprobación previa al vuelo durante el proceso de actualización para advertir sobre los PDBs. Sin embargo, también debes verificar manualmente los archivos PDB para asegurarte de que la actualización se realice correctamente. Para obtener más información sobre los PDBs, consulta Specifying a Disruption Budget for your Application (Especificar un presupuesto de interrupción para tu aplicación).

Revisa las direcciones IP disponibles

Las siguientes consideraciones sobre las direcciones IP se aplican a las actualizaciones de clústeres de usuarios y clústeres de administradores que no son de alta disponibilidad:

  • El proceso de actualización del clúster crea un nodo nuevo y agota los recursos antes de eliminar el nodo antiguo. Te recomendamos que siempre tengas N+1 direcciones IP para el clúster, donde N es el número de nodos del clúster. Esta recomendación solo se aplica a los clústeres de administrador que no tienen alta disponibilidad (que solo tienen un nodo de plano de control) y a los clústeres de usuario.

  • Cuando se usan direcciones IP estáticas, las direcciones IP necesarias deben figurar en los archivos de bloques de IP.

    • Cuando actualices clústeres de administradores que no sean de alta disponibilidad, añade la dirección IP adicional al archivo de bloque de IPs que utilice el clúster de administradores. La ruta a este archivo debe especificarse en el campo network.ipMode.ipBlockFilePath del archivo de configuración del clúster de administrador.
    • Cuando actualices clústeres de usuarios, añade la dirección IP adicional al archivo IP block que utilice el clúster de usuarios. La ruta a este archivo debe especificarse en el campo network.ipMode.ipBlockFilePath del archivo de configuración del clúster de usuarios.

  • Si usas DHCP, asegúrate de que las nuevas VMs puedan obtener concesiones de IP adicionales en la subred correspondiente durante una actualización.

    Si necesitas añadir direcciones IP, actualiza el archivo de bloqueo de IPs y, a continuación, ejecuta el comando gkectl update. Para obtener más información, consulta el artículo Planificar las direcciones IP.

  • Si usas direcciones IP estáticas y quieres acelerar el proceso de actualización del clúster de usuarios, incluye suficientes direcciones IP en tu archivo de bloque de IP para que cada grupo de nodos pueda tener una dirección IP adicional disponible. Este enfoque permite que el proceso acelere el procedimiento de adición y eliminación de máquinas virtuales, ya que se realiza por cada grupo de nodos.

    Aunque este enfoque es una buena opción para acelerar las actualizaciones de los clústeres de usuarios, ten en cuenta la disponibilidad de recursos y el rendimiento de tu entorno de vSphere antes de continuar.

  • Si solo hay una IP de reserva para todo el clúster de usuarios, esta limitación ralentiza el proceso de actualización a una sola VM a la vez, incluso cuando se utilizan varios grupos de nodos.

Los clústeres de administrador de alta disponibilidad no requieren N+1 direcciones IP para las actualizaciones. Los tres nodos del plano de control de un clúster de administración de alta disponibilidad se vuelven a crear uno a uno, lo que garantiza que no se necesiten direcciones IP adicionales.

Consultar la utilización del clúster

Asegúrate de que los pods se puedan evacuar cuando se agote el nodo y de que haya suficientes recursos en el clúster que se va a actualizar para gestionar la actualización. Para comprobar el uso de recursos actual del clúster, puedes usar paneles de control personalizados en Google Cloud Observability o directamente en el clúster mediante comandos como kubectl top nodes.

Los comandos que ejecutas en el clúster te muestran una instantánea del uso actual de los recursos del clúster. Los paneles de control pueden ofrecer una vista más detallada de los recursos que se consumen a lo largo del tiempo. Estos datos de uso de recursos pueden ayudar a determinar cuándo una actualización causaría las menores interrupciones posibles, por ejemplo, durante los fines de semana o por las noches, en función de la carga de trabajo y los casos de uso.

El momento de la actualización del clúster de administradores puede ser menos importante que el de los clústeres de usuarios, ya que la actualización de un clúster de administradores no suele provocar tiempos de inactividad de las aplicaciones. Sin embargo, sigue siendo importante comprobar si hay recursos libres en vSphere antes de empezar a actualizar un clúster de administradores. Además, actualizar el clúster de administrador puede conllevar algún riesgo, por lo que se recomienda hacerlo durante los periodos de uso menos activos, cuando el acceso de gestión al clúster sea menos crítico.

Para obtener más información, consulta qué servicios se ven afectados durante una actualización de clúster.

Comprobar la utilización de vSphere

Comprueba que haya suficientes recursos en la infraestructura de vSphere subyacente. Para comprobar el uso de estos recursos, selecciona un clúster en vCenter y consulta la pestaña Resumen.

La pestaña de resumen muestra el consumo general de memoria, CPU y almacenamiento de todo el clúster. Como las actualizaciones de Google Distributed Cloud requieren recursos adicionales, también debes comprobar si el clúster puede gestionar estas solicitudes de recursos adicionales.

Por lo general, tu clúster de vSphere debe poder admitir los siguientes recursos adicionales:

  • +1 VM por actualización del clúster de administrador
  • +1 VM por grupo de nodos por actualización de clúster de usuarios

Por ejemplo, supongamos que un clúster de usuarios tiene 3 grupos de nodos y que cada grupo de nodos tiene nodos que usan 8 vCPUs y 32 GB de RAM o más. Como la actualización se realiza en paralelo en los 3 grupos de nodos de forma predeterminada, el procedimiento de actualización consume los siguientes recursos adicionales para los 3 nodos de aumento adicionales:

  • 24 vCPUs
  • 96 GB de RAM
  • Espacio en disco de la VM + 96 GB de vSwap

El proceso de actualización crea máquinas virtuales mediante la operación de clonación de vSphere. La clonación de varias máquinas virtuales a partir de una plantilla puede ejercer presión sobre el sistema de almacenamiento subyacente en forma de aumento de las operaciones de E/S. La actualización puede ralentizarse considerablemente si el subsistema de almacenamiento subyacente no puede proporcionar un rendimiento suficiente durante la actualización.

Aunque vSphere se ha diseñado para que se usen los recursos simultáneamente y tiene mecanismos para proporcionar recursos, incluso cuando se han asignado en exceso, te recomendamos que no asignes memoria de VM en exceso. El exceso de asignación de memoria puede provocar graves problemas de rendimiento que afecten a todo el clúster, ya que vSphere proporciona la "RAM que falta" intercambiando páginas con el almacén de datos. Este comportamiento puede provocar problemas durante la actualización de un clúster y afectar al rendimiento de otras máquinas virtuales que se estén ejecutando en el clúster de vSphere.

Si los recursos disponibles ya son escasos, apaga las máquinas virtuales que no necesites para cumplir estos requisitos adicionales y evitar que el rendimiento se vea afectado.

Comprobar el estado y la configuración del clúster

Ejecuta las siguientes herramientas en todos los clústeres antes de la actualización:

  • El comando gkectl diagnose: gkectl diagnose asegura que todos los clústeres estén en buen estado. El comando ejecuta comprobaciones avanzadas, como identificar nodos que no están configurados correctamente o que tienen pods que están en un estado bloqueado. Si el comando gkectl diagnose muestra una advertencia Cluster unhealthy, soluciona los problemas antes de intentar actualizar. Para obtener más información, consulta Diagnosticar problemas de clústeres.

  • La herramienta previa a la actualización: además de comprobar el estado y la configuración del clúster, esta herramienta busca posibles problemas conocidos que podrían producirse durante una actualización del clúster.

Además, cuando actualices los clústeres de usuarios a la versión 1.29 o a una posterior, te recomendamos que ejecutes el comando gkectl upgrade cluster con la marca --dry-run. La marca --dry-run ejecuta comprobaciones previas, pero no inicia el proceso de actualización. Aunque las versiones anteriores de Google Distributed Cloud ejecutan comprobaciones previas, no se pueden ejecutar por separado de la actualización. Si añades la marca --dry-run, podrás encontrar y solucionar cualquier problema que detecten las comprobaciones previas en tu clúster de usuarios antes de la actualización.

Usar implementaciones para minimizar las interrupciones de las aplicaciones

Como los nodos deben vaciarse durante las actualizaciones, las actualizaciones de clústeres pueden provocar interrupciones en las aplicaciones. Al drenar los nodos, todos los pods en ejecución deben cerrarse y reiniciarse en los nodos restantes del clúster.

Si es posible, tus aplicaciones deben usar Deployments. Con este enfoque, las aplicaciones se diseñan para gestionar las interrupciones. El impacto debería ser mínimo en las implementaciones que tengan varias réplicas. Puedes actualizar tu clúster si las aplicaciones no usan implementaciones.

También hay reglas para las implementaciones que aseguran que siempre se ejecute un número determinado de réplicas. Estas reglas se conocen como PodDisruptionBudgets (PDBs). Los PDBs te permiten limitar las interrupciones de una carga de trabajo cuando sus pods deben reprogramarse por algún motivo, como actualizaciones o mantenimiento en los nodos del clúster, y es importante comprobarlos antes de una actualización.

Usar un par de balanceadores de carga de alta disponibilidad

Si usas Seesaw como balanceador de carga en un clúster, los balanceadores de carga se actualizan automáticamente cuando actualizas el clúster. Esta actualización puede provocar una interrupción del servicio. Para reducir el impacto de una actualización y un posible fallo del balanceador de carga, puedes usar un par de alta disponibilidad. En esta configuración, el sistema crea y configura dos VMs de balanceador de carga para que se pueda producir una conmutación por error al otro par.

Para aumentar la disponibilidad del servicio (es decir, del servidor de la API de Kubernetes), te recomendamos que utilices siempre un par de alta disponibilidad delante del clúster de administrador. Para obtener más información sobre Seesaw y su configuración de alta disponibilidad, consulta la documentación de la versión 1.16 Balanceo de carga agrupado con Seesaw.

Para evitar que se interrumpa el servicio durante una actualización con un par de alta disponibilidad, el clúster inicia una conmutación por error antes de crear la nueva VM de balanceador de carga. Si un clúster de usuarios solo usa una instancia de balanceador de carga, se producirá una interrupción del servicio hasta que se complete la actualización del balanceador de carga.

Te recomendamos que tengas un par de balanceadores de carga de alta disponibilidad si el propio clúster de usuarios también está configurado para ser de alta disponibilidad. En esta serie de prácticas recomendadas se da por hecho que un clúster de usuario de alta disponibilidad usa un par de balanceadores de carga de alta disponibilidad.

Si usas MetalLB como balanceador de carga agrupado, no es necesario que hagas ninguna configuración previa a la actualización. El balanceador de carga se actualiza durante el proceso de actualización del clúster.

Decidir cómo actualizar cada clúster de usuarios

En la versión 1.14 y posteriores, puedes actualizar un clúster de usuarios en su totalidad (es decir, puedes actualizar el plano de control y todos los grupos de nodos del clúster) o puedes actualizar el plano de control del clúster de usuarios y dejar los grupos de nodos en la versión actual. Para obtener información sobre por qué puede ser conveniente actualizar el plano de control por separado, consulta Actualizaciones de clústeres de usuario.

En un entorno de varios clústeres, haz un seguimiento de los clústeres de usuarios que se han actualizado y registra su número de versión. Si decides actualizar el plano de control y los grupos de nodos por separado, anota la versión del plano de control y de cada grupo de nodos de cada clúster.

Consultar las versiones de los clústeres de usuarios y de administradores

gkectl

  • Para comprobar la versión de los clústeres de usuarios, sigue estos pasos:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig de tu clúster de administrador.

  • Para comprobar la versión de los clústeres de administradores, sigue estos pasos:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

CLI de gcloud

En los clústeres registrados en la API GKE On-Prem, puedes usar la gcloud CLI para obtener las versiones de los clústeres de usuario, los grupos de nodos del clúster de usuario y los clústeres de administrador.

  1. Asegúrate de que tienes la versión más reciente de la CLI de gcloud. Actualiza los componentes de gcloud CLI si es necesario:

    gcloud components update

  2. Ejecuta los siguientes comandos para comprobar las versiones:

  • Para comprobar la versión de los clústeres de usuarios, sigue estos pasos:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Sustituye PROJECT_ID por el ID del proyecto host de la flota.

    Si define --location=-, se mostrarán todos los clústeres de todas las regiones. Si necesita reducir el ámbito de la lista, asigne a --location la región que especificó al registrar el clúster.

    El resultado del comando incluye la versión del clúster.

  • Para comprobar la versión de los clústeres de administradores, sigue estos pasos:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Comprueba la versión de los nodos del clúster:

Puedes usar kubectl para obtener la versión de los nodos del clúster, pero kubectl devuelve la versión de Kubernetes. Para obtener la versión de Google Distributed Cloud correspondiente a una versión de Kubernetes, consulta Control de versiones.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig de tu clúster de usuario.

Comprobar si es necesario rotar los certificados de CA

Durante una actualización, los certificados de hoja se rotan, pero los certificados de CA no. Debes rotar manualmente tus certificados de AC al menos una vez cada cinco años. Para obtener más información, consulta los artículos Rotar autoridades de certificación de clústeres de usuarios y Rotar certificados de AC de clústeres de administradores.

Diferencias entre los tipos de clústeres

Hay dos tipos de clústeres:

  • Clúster de usuarios
  • Clúster de administradores

En función de cómo crees un clúster de usuarios, puede contener nodos de trabajador y nodos de plano de control (Controlplane V2) o solo nodos de trabajador (kubeception). Con kubeception, el plano de control de un clúster de usuarios se ejecuta en uno o varios nodos de un clúster de administrador. En ambos casos, en la versión 1.14 y posteriores, puedes actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos que ejecutan tus cargas de trabajo.

Efectos de las actualizaciones de clústeres de usuarios y de clústeres de administradores

El procedimiento de actualización de Google Distributed Cloud implica un proceso de drenaje de nodos que elimina todos los pods de un nodo. El proceso crea una VM para cada nodo de trabajador drenado y la añade al clúster. Los nodos de trabajador drenados se eliminan del inventario de VMware. Durante este proceso, se detendrá cualquier carga de trabajo que se ejecute en estos nodos y se reiniciará en otros nodos disponibles del clúster.

En función de la arquitectura elegida para la carga de trabajo, este procedimiento puede afectar a la disponibilidad de una aplicación. Para no sobrecargar los recursos del clúster, Google Distributed Cloud actualiza los nodos de uno en uno.

Interrupción del clúster de usuarios

En la siguiente tabla se describe el impacto de una actualización in situ de un clúster de usuarios:

Función Clúster de administradores Clúster de usuarios sin alta disponibilidad Clúster de usuarios de alta disponibilidad
Acceso a la API de Kubernetes No se ve afectado No se ve afectado No se ve afectado
Cargas de trabajo de los usuarios No se ve afectado No se ve afectado No se ve afectado
PodDisruptionBudgets* No se ve afectado No se ve afectado No se ve afectado
Nodo del plano de control No se ve afectado A quién afecta No se ve afectado
Adaptador automático de pods (VMware) No se ve afectado No se ve afectado No se ve afectado
Reparación automática No se ve afectado No se ve afectado No se ve afectado
Escalado automático de nodos (VMware) No se ve afectado No se ve afectado No se ve afectado
Autoescalado de pods horizontal A quién afecta A quién afecta No se ve afectado
  • * : los archivos PDB pueden provocar que la actualización falle o se detenga.
  • Afectado: se notará una interrupción del servicio durante la actualización hasta que esta finalice.
  • Sin efecto: puede producirse una interrupción del servicio durante un periodo muy breve, pero es casi imperceptible.

Los nodos del plano de control del clúster de usuario, tanto si se ejecutan en el clúster de administrador (kubeception) como en el propio clúster de usuario (Controlplane V2), no ejecutan ninguna carga de trabajo de usuario. Durante una actualización, estos nodos del plano de control se vacían y, a continuación, se actualizan.

En entornos con planos de control de alta disponibilidad, la actualización del plano de control de un clúster de usuario no interrumpe las cargas de trabajo de los usuarios. En un entorno de alta disponibilidad, la actualización de un clúster de administradores no interrumpe las cargas de trabajo de los usuarios. En el caso de los clústeres de usuarios que usan Controlplane V2, actualizar solo el plano de control no interrumpe las cargas de trabajo de los usuarios.

Durante una actualización en un entorno de plano de control que no es de alta disponibilidad, el plano de control no puede controlar las acciones de escalado, recuperación o despliegue de pods. Durante la breve interrupción del plano de control que se produce durante la actualización, las cargas de trabajo de los usuarios pueden verse afectadas si se encuentran en un estado de escalado, implementación o recuperación. Esto significa que las implementaciones fallarán durante una actualización en un entorno que no sea de alta disponibilidad.

Para mejorar la disponibilidad y reducir las interrupciones de los clústeres de usuarios de producción durante las actualizaciones, te recomendamos que uses tres nodos del plano de control (modo de alta disponibilidad).

Interrupción del clúster de administrador

En la siguiente tabla se describe el impacto de una actualización in situ de un clúster de administrador:

Función Clúster de administradores Clúster de usuarios sin alta disponibilidad Clúster de usuarios de alta disponibilidad
Acceso a la API de Kubernetes A quién afecta A quién afecta No se ve afectado
Cargas de trabajo de los usuarios No se ve afectado No se ve afectado No se ve afectado
Nodo del plano de control A quién afecta A quién afecta No se ve afectado
Herramienta de adaptación dinámica de pods A quién afecta A quién afecta No se ve afectado
Taller de automóviles A quién afecta A quién afecta No se ve afectado
Autoescalado de nodos A quién afecta A quién afecta No se ve afectado
Autoescalado de pods horizontal A quién afecta A quién afecta No se ve afectado
  • Afectado: se notará una interrupción del servicio durante la actualización hasta que esta finalice.
  • Sin efecto: puede producirse una interrupción del servicio durante un periodo muy breve, pero es casi imperceptible.

Siguientes pasos