En esta página, se proporciona una descripción general del proceso de actualización y la información sobre la desviación de versión que debería ayudarte a planificar el orden en el que actualizas los clústeres en un entorno de varios clústeres. Para obtener información de planificación más detallada, incluida una lista de tareas para ayudarte a planificar la actualización, consulta Prácticas recomendadas para la actualización.
Secuencia de actualización
Las actualizaciones in situ a partir de la versión 1.7 siempre deben seguir una secuencia de actualización específica:
Actualiza la estación de trabajo de administrador. Te recomendamos que lo hagas incluso si planeas usar la consola de Google Cloud, Google Cloud CLI o Terraform para actualizar los clústeres de usuario.
Actualiza los clústeres de usuario, uno a la vez. En la versión 1.14 y en las posteriores, puedes actualizar de forma opcional el plano de control de un clúster de usuario por separado de los grupos de nodos en el clúster de usuario. Para obtener información sobre por qué es posible que quieras hacer esto, consulta Actualizaciones del clúster de usuario.
Una vez que todos los grupos de nodos de un clúster de usuario tengan la misma versión que el plano de control del clúster de usuario, este se habrá actualizado por completo.
Un clúster de administrador no puede tener una versión secundaria posterior que cualquiera de los clústeres de usuario que administra. Si alguno de tus clústeres de usuario tiene la misma versión secundaria que el clúster de administrador, no podrás actualizarlo.
Cuando todos los clústeres de usuario tengan al menos una versión secundaria posterior a la del clúster de administrador, puedes actualizar el clúster de administrador de forma opcional.
La distorsión de la versión y las reglas de versión para las actualizaciones cambiaron en la versión 1.28 y versiones posteriores. Para obtener más información, consulta Desfase de versiones.
Actualizaciones de clústeres de usuario
Cuando actualizas clústeres de usuario, puedes optar por actualizar el clúster de usuario en su totalidad (lo que significa que puedes actualizar el plano de control y todos los grupos de nodos en el clúster) o puedes actualizar el plano de control del clúster de usuario y dejar los grupos de nodos en la versión actual. El enfoque que adoptes dependerá de varios factores, como los siguientes:
- El entorno (producción o no producción) en el que se encuentra el clúster
- La duración del período de mantenimiento
- Es la versión del clúster de usuarios.
Por ejemplo, en un entorno de desarrollo, es posible que desees mantener el proceso sencillo y actualizar el plano de control del clúster de usuario y todos los grupos de nodos. Sin embargo, en un entorno de producción con un período de mantenimiento corto, es posible que desees actualizar solo el plano de control, ya que eso lleva menos tiempo y, con planos de control de alta disponibilidad (HA), la actualización del plano de control no debería interrumpir las cargas de trabajo de los usuarios. Cuando el plano de control esté en la versión 1.28 o una posterior, puedes omitir una versión menor cuando actualices los grupos de nodos.
La actualización de los grupos de nodos por separado del plano de control es compatible con los grupos de nodos de Ubuntu y COS, pero no con los de Windows.
Actualiza grupos de nodos de forma selectiva
En ciertas situaciones, es posible que desees actualizar algunos, pero no todos los grupos de nodos de un clúster de usuarios. Por ejemplo, después de actualizar el plano de control, podrías actualizar un grupo de nodos que tenga poco tráfico o ejecute tus cargas de trabajo menos críticas. Una vez que te convenzas de que tus cargas de trabajo se ejecutan correctamente en la versión nueva, puedes actualizar grupos de nodos adicionales, hasta que, finalmente, se actualicen todos.
Elige una herramienta para actualizar los clústeres de usuario
Google Distributed Cloud te ofrece una variedad de herramientas para actualizar clústeres de usuarios.
La herramienta de línea de comandos
gkectl, que ejecutas en tu estación de trabajo de administrador Antes de la actualización, debes modificar el archivo de configuración del clúster de usuario para establecer la versión de destino del plano de control del clúster y, de manera opcional, para los grupos de nodos. Especificas este archivo en la línea de comandos paragkectl.La consola de Google Cloud, Google Cloud CLI o Terraform que puedes ejecutar desde cualquier computadora que tenga conectividad de red a la API de GKE On-Prem. Estas herramientas estándar son clientes de la API de GKE On-Prem, que se ejecuta en la infraestructura de Google Cloud.
Puedes usar Terraform para la actualización solo si creaste el clúster de usuarios con Terraform.
Si tu clúster de usuario se creó con
gkectl, el clúster debe estar inscrito en la API de GKE On-Prem para usar la consola o gcloud CLI para la actualización. En la versión 1.16 y versiones posteriores, los clústeres creados congkectlse inscriben en la API de GKE On-Prem de forma predeterminada. En el caso de los clústeres creados en versiones anteriores, puedes inscribir el clúster después de crearlo.Incluso si decides usar
gkectlpara la actualización, te recomendamos que inscribas el clúster en la API de GKE On-Prem para obtener información sobre los clústeres con la consola o gcloud CLI.
La herramienta que uses dependerá de cómo planees actualizar los clústeres de usuario:
Actualiza el clúster en su totalidad: Puedes usar
gkectl, la consola de Google Cloud, Google Cloud CLI o Terraform para actualizar un clúster de usuario (el plano de control junto con todos los grupos de nodos).Actualiza solo el plano de control: Puedes usar
gkectl, gcloud CLI o Terraform para actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos. La consola no admite la actualización solo del plano de control.Actualiza grupos de nodos de forma selectiva después de actualizar el plano de control: Puedes usar
gkectl, gcloud CLI o Terraform para actualizar grupos de nodos específicos después de actualizar el plano de control.Actualiza el plano de control y uno o más grupos de nodos al mismo tiempo: Solo
gkectladmite este caso de uso.
Actualizaciones del clúster de administrador
Cuando el plano de control y los grupos de nodos de todos los clústeres de usuario tengan al menos una versión secundaria posterior a la del clúster de administrador, puedes actualizar el clúster de administrador de forma opcional. Solo gkectl admite la actualización de clústeres de administrador. Los clientes de la API de GKE On-Prem no admiten la actualización de clústeres de administrador.
Sesgo de versiones
La desviación de versión es la diferencia en las versiones secundarias entre un clúster de administrador y sus clústeres de usuario administrados. En las siguientes secciones, la versión del clúster de usuario hace referencia a la versión del plano de control y los grupos de nodos juntos, en su totalidad.
Además, la desviación de versión es la diferencia en las versiones secundarias entre el plano de control de un clúster de usuario y los grupos de nodos en el clúster de usuario.
En un entorno de varios clústeres, comprender el sesgo de versiones compatibles y las reglas de versiones para las actualizaciones puede ayudarte a planificar el orden en el que actualizas los clústeres.
Desfase de versiones de clústeres de administrador y de usuario
Un clúster de administrador puede administrar clústeres de usuario que se encuentran en diferentes versiones. Esta función te permite actualizar una flota de clústeres de usuario según un programa que funcione para tu organización.
1.29 y versiones más altas
La desviación de versión es la misma que en la 1.28. En la versión 1.29, esta función pasó a la etapa de disponibilidad general.
En la versión 1.29 y versiones posteriores, los clústeres de usuario pueden tener hasta 2 versiones secundarias superiores a las de su clúster de administrador. Por ejemplo, si un clúster de administrador está en la versión 1.28, los clústeres de usuario que administra pueden estar en la versión 1.28, 1.29 o 1.30.
En términos generales, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden estar en 1.n, 1.n+1 o 1.n+2. Los clústeres de usuario en 1.n+2 no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador se actualice a, al menos, una versión secundaria.
1.28
En la versión 1.28, los clústeres de usuario pueden tener hasta 2 versiones secundarias superiores que su clúster de administrador. Por ejemplo, si un clúster de administrador está en la versión 1.15, los clústeres de usuario que administra ese clúster de administrador pueden estar en la versión 1.15, 1.16 o 1.28. Los clústeres de usuario en la versión 1.28 no se pueden actualizar a la versión 1.29 hasta que el clúster de administrador se actualice a, al menos, la versión 1.16.
1.16 y versiones más bajas
En la versión 1.16 y versiones anteriores, los clústeres de usuario solo pueden ser 1 versión secundaria superior a su clúster de administrador. Por ejemplo, si un clúster de administrador está en la versión 1.15, los clústeres de usuario que administra pueden estar en la versión 1.15 o 1.16.
En términos generales, si 1.n es la versión secundaria del clúster de administrador, los clústeres de usuario pueden estar en 1.n o 1.n+1. Los clústeres de usuario no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador tenga la misma versión secundaria que el clúster de usuario.
Desfase de versión del plano de control del clúster de usuario y del grupo de nodos
1.29 y versiones más altas
La desviación de versión es la misma que en la 1.28. En la versión 1.29, esta función pasó a la etapa de disponibilidad general.
En la versión 1.29 y versiones posteriores, el plano de control de un clúster de usuario puede ser de hasta 2 versiones secundarias más recientes que los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en la versión 1.30, los grupos de nodos del clúster pueden estar en la versión 1.28, 1.29 o 1.30.
En términos generales, si 1.n es la versión secundaria de un plano de control del clúster de usuario, los grupos de nodos del clúster pueden estar en 1.n, 1.n-1 o 1.n-2.
Los planos de control de los clústeres de usuario no se pueden actualizar a la siguiente versión menor hasta que todos los grupos de nodos estén en 1.n o 1.n-1.
1.28
En la versión 1.28, el plano de control de un clúster de usuario puede ser de hasta 2 versiones secundarias más recientes que los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en 1.28, los grupos de nodos del clúster pueden estar en 1.15, 1.16 o 1.28. Los planos de control de los clústeres de usuario no se pueden actualizar a la versión 1.29 hasta que todos los grupos de nodos estén en 1.28 o 1.16.
1.16 y versiones más bajas
En la versión 1.16 y versiones anteriores, el plano de control de un clúster de usuario solo puede ser 1 versión secundaria superior a los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en la versión 1.16, los grupos de nodos del clúster pueden estar en la versión 1.15 o 1.16.
En términos generales, si 1.n es la versión secundaria de un plano de control de clúster de usuario, los grupos de nodos del clúster pueden estar en 1.n o 1.n-1. Los clústeres de usuario no se pueden actualizar a la siguiente versión secundaria hasta que todos los grupos de nodos tengan la misma versión secundaria que el plano de control.
Reglas de versión para las actualizaciones del plano de control del clúster de administrador y del clúster de usuario
Las reglas de versión para los clústeres de administrador y las actualizaciones del plano de control del clúster de usuario son las mismas. Puedes actualizar directamente a cualquier versión que se encuentre en la misma versión secundaria o en la próxima versión secundaria. Por ejemplo, puedes actualizar de la versión 1.30.0 a la 1.30.1 o de la versión 1.29.1 a la 1.30.0. Las versiones de los parches no afectan las reglas de la versión de actualización.
Si quieres actualizar a una versión que no forma parte de la próxima versión secundaria, debes actualizar a través de una versión de cada actualización secundaria entre tu versión actual y la deseada. No se admite omitir una versión menor. Por ejemplo, si quieres actualizar de la versión 1.28.x a la versión 1.30.x, no puedes hacerlo directamente. Primero debes actualizar de la versión 1.28.x a la 1.29.x y, luego, a la 1.30.x.
En términos generales, solo se admiten actualizaciones de 1.n a 1.n+1 para las actualizaciones de clústeres de administrador y las actualizaciones del plano de control de clústeres de usuario.
Reglas de versión para actualizaciones de grupos de nodos
En la versión 1.28 y en las posteriores, puedes omitir una versión secundaria cuando actualices un grupo de nodos en un clúster de usuario. Por ejemplo, si el plano de control de un clúster de usuario está en la versión 1.30 y un grupo de nodos está en la versión 1.28, puedes omitir la versión 1.29 y actualizar el grupo de nodos directamente a la versión 1.30. Las versiones de los parches no afectan las reglas de versión de actualización.
En términos generales, si el plano de control de un clúster de usuario está en 1.n, puedes actualizar los grupos de nodos que están en 1.n-2 directamente a 1.n. Omitir una versión inferior cuando se actualizan los grupos de nodos podría reducir la cantidad de tiempo que se tarda en realizar dos actualizaciones de grupos de nodos (para actualizar de 1.n-2 a 1.n-1 y, luego, a 1.n). Esta es otra razón por la que podrías preferir actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos que se ejecutan en él.
Actualizaciones de versiones de parches
Te recomendamos actualizar a la versión de parche más reciente siempre que sea posible para garantizar que los clústeres tengan las correcciones de seguridad más recientes. Las versiones de parches no afectan el sesgo de versión ni las reglas de actualización. Para una versión secundaria determinada, puedes actualizar a cualquier versión de parche superior. Es decir, puedes actualizar un clúster de la versión 1.30.X a la versión 1.30.Y siempre que Y sea mayor que X. Por ejemplo, puedes actualizar de 1.29.0 a 1.29.1 y actualizar de 1.29.1 a 1.29.3.
¿Qué sigue?
Revisa las prácticas recomendadas para la actualización y crea un plan para actualizar tus clústeres.