En esta página, se proporciona una descripción general del proceso de actualización y la información del sesgo de versiones que debería ayudarte a planificar el orden en el que actualizas los clústeres en un entorno de varios clústeres. Si deseas obtener información de planificación más detallada, incluida una lista de tareas para planificar la actualización, consulta Prácticas recomendadas de actualización.
Secuencia de actualización
Las actualizaciones locales desde 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 posteriores, puedes actualizar de manera 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é te recomendamos hacer esto, consulta Actualizaciones del clúster de usuario.
Una vez que todos los grupos de nodos de un clúster de usuario tienen la misma versión que el plano de control del clúster de usuario, este se actualiza por completo.
Un clúster de administrador no puede estar en una versión secundaria posterior a ninguno de los clústeres de usuario que administra. Si alguno de los clústeres de usuario tiene la misma versión secundaria que el clúster de administrador, no podrás actualizar el clúster de administrador.
Cuando todos los clústeres de usuario son al menos una versión secundaria posterior al clúster de administrador, puedes actualizar el clúster de administrador de manera opcional.
El sesgo de versiones y las reglas de versiones para las actualizaciones cambiaron en la versión 1.28 y en versiones posteriores. Para obtener más información, consulta Sesgo de versiones.
Actualizaciones del clúster de usuario
Cuando actualizas clústeres de usuario, puedes elegir actualizar el clúster de usuario como un todo (lo que significa que 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 usuario y dejar los grupos de nodos en la versión actual. El enfoque que adoptes depende de varios factores, entre los que se incluyen los siguientes:
- Es el entorno (de producción o no producción) en el que se encuentra el clúster.
- La duración del período de mantenimiento.
- La versión del clúster de usuario.
Por ejemplo, en un entorno de desarrollo, es posible que desees mantener el proceso simple 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 esto lleva menos tiempo y, con los planos de control de alta disponibilidad (HA), la actualización del plano de control no debería interrumpir las cargas de trabajo del usuario. Cuando el plano de control está en la versión 1.28 o superior, puedes omitir una versión secundaria cuando actualizas los grupos de nodos.
La actualización de grupos de nodos por separado del plano de control es compatible con los grupos de nodos de Ubuntu y COS, pero no con los grupos de nodos de Windows.
Actualiza los 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 usuario. Por ejemplo, después de actualizar el plano de control, podrías actualizar un grupo de nodos que tenga tráfico ligero o que ejecute las cargas de trabajo menos críticas. Una vez que estés convencido de que tus cargas de trabajo se ejecutan de forma correcta en la versión nueva, puedes actualizar grupos de nodos adicionales, hasta que, finalmente, todos los grupos de nodos se actualicen.
Elige una herramienta para actualizar los clústeres de usuario
Google Distributed Cloud te ofrece una variedad de herramientas para actualizar clústeres de usuario.
La herramienta de línea de comandos
gkectl, que ejecutas en la estación de trabajo de administrador Antes de la actualización, modifica 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 forma opcional, de los grupos de nodos. Debes especificar 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 usuario con Terraform.
Si el clúster de usuario se creó con
gkectl, el clúster debe estar inscrito en la API de GKE On-Prem si quieres usar la consola o lagcloud CLIud para la actualización. En la versión 1.16 y posteriores, los clústeres creados congkectlestán inscritos 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 su creación.Incluso si decides usar
gkectlpara la actualización, es posible que desees inscribir el clúster en la API de GKE On-Prem para obtener información sobre los clústeres con la consola o la CLI de gcloud.
La herramienta que uses depende de cómo planeas 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 los 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
gkectles compatible con este caso práctico.
Actualizaciones del clúster de administrador
Cuando el plano de control y los grupos de nodos en todos los clústeres de usuario son al menos una versión secundaria posterior que el clúster de administrador, puedes actualizar el clúster de administrador de manera 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
El sesgo de versiones 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 en conjunto.
Además, el sesgo de versiones 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 y las reglas de versión compatibles con las actualizaciones puede ayudarte a planificar el orden en el que actualizas los clústeres.
Sesgo de versiones de clústeres de administrador y usuario
Un clúster de administrador puede administrar clústeres de usuario que tienen versiones diferentes. Esta función te permite actualizar una flota de clústeres de usuario según un programa adecuado para tu organización.
1.29 y posteriores
El sesgo de versiones es el mismo que en la versión 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 posteriores, los clústeres de usuario pueden tener hasta 2 versiones secundarias superiores a las del clúster de administrador. Por ejemplo, si un clúster de administrador está en 1.16, los clústeres de usuario administrados por ese clúster de administrador pueden estar en 1.16, 1.28 o 1.29.
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 al menos a una versión secundaria.
1.28
En la versión 1.28, los clústeres de usuario pueden tener hasta 2 versiones secundarias superiores a las del clúster de administrador. Por ejemplo, si un clúster de administrador está en 1.15, los clústeres de usuario administrados por ese clúster de administrador pueden estar en 1.15, 1.16 o 1.28. Los clústeres de usuario en 1.28 no se pueden actualizar a 1.29 hasta que el clúster de administrador se actualice a, al menos, 1.16.
1.16 y anteriores
En la versión 1.16 y anteriores, los clústeres de usuario solo pueden ser 1 versión secundaria superior que el clúster de administrador. Por ejemplo, si un clúster de administrador está en 1.15, los clústeres de usuario administrados por ese clúster de administrador pueden estar en 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 esté en la misma versión secundaria que el clúster de usuario.
Sesgo de versiones del grupo de nodos y el plano de control del clúster de usuario
1.29 y posteriores
El sesgo de versiones es el mismo que en la versión 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 posteriores, el plano de control de un clúster de usuario puede ser de hasta 2 versiones secundarias superiores a los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en 1.29, los grupos de nodos del clúster pueden estar en 1.16, 1.28 o 1.29.
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 en el clúster pueden estar en 1.n, 1.n-1 o 1.n-2.
Los planos de control del clúster de usuario no se pueden actualizar a la siguiente versión secundaria 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 hasta 2 versiones secundarias superiores a 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 en el clúster pueden estar en 1.15, 1.16 o 1.28. Los planos de control del clúster 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 anteriores
En la versión 1.16 y anteriores, el plano de control de un clúster de usuario solo puede ser 1 versión secundaria superior que los grupos de nodos del clúster. Por ejemplo, si el plano de control de un clúster de usuario está en 1.16, los grupos de nodos en el clúster pueden estar en 1.15 o 1.16.
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 en el 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 estén en la misma versión secundaria que el plano de control.
Reglas de la versión para las actualizaciones del clúster de administrador y del plano de control del clúster de usuario
Las reglas de versiones 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 siguiente. Por ejemplo, puedes actualizar de 1.29.0 a 1.29.1, o de 1.28.1 a 1.29.0. Las versiones de parche no afectan las reglas de las versiones de actualización.
Si actualizas 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 versión secundaria entre la versión actual y la versión objetivo. No se admite omitir una versión secundaria. Por ejemplo, si deseas actualizar de la versión 1.16.x a la versión 1.29.x, no puedes realizar la actualización directamente. Primero debes actualizar de 1.16.x a 1.28.x y, luego, a 1.29.x.
En general, solo se admiten las actualizaciones de 1.n a 1.n+1 para las actualizaciones del clúster de administrador y las actualizaciones del plano de control del clúster de usuario.
Reglas de versión para actualizaciones de grupos de nodos
En la versión 1.28 y posteriores, puedes omitir una versión secundaria cuando actualizas un grupo de nodos en un clúster de usuario. Por ejemplo, si un plano de control del clúster de usuario está en 1.29 y un grupo de nodos en 1.16, puedes omitir 1.28 y actualizar el grupo de nodos directamente a 1.29. Las versiones de parche no afectan las reglas de las versiones de actualización.
En términos generales, si un plano de control del 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. Omisión de una versión secundaria cuando se actualizan grupos de nodos puede reducir la cantidad de tiempo que realizar dos actualizaciones del grupo 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 es posible que prefieras actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos que se ejecutan en el clúster de usuario.
Actualizaciones de versiones de parches
Te recomendamos que actualices a la versión del parche más reciente siempre que sea posible para asegurarte de que los clústeres tengan las correcciones de seguridad más recientes. Las versiones de parche no afectan el sesgo de versiones ni las reglas de actualización. Para una versión secundaria determinada, puedes actualizar a cualquier versión del parche superior. Es decir, puedes actualizar un clúster de la versión 1.29.X a la versión 1.29.Y siempre que Y sea mayor que X. Por ejemplo, puedes actualizar de 1.28.0 a 1.28.1 y actualizar de 1.28.1 a 1.28.3.
¿Qué sigue?
Revisa las Prácticas recomendadas de actualización y crea un plan para actualizar tus clústeres.