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. Para obtener información de planificación más detallada, incluida una lista de tareas que te ayude a planificar la actualización, consulta Prácticas recomendadas de actualización.
Secuencia de actualización
Las actualizaciones in situ 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 en versiones posteriores, tienes la opción de actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos del clúster de usuario. Para obtener información sobre por qué querrías hacer esto, consulta Actualizaciones del clúster de usuario.
Una vez que todos los grupos de nodos de un clúster de usuario están en 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 la de los clústeres de usuario que administra. Si alguno de los clústeres de usuario se encuentra en 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 al clúster de administrador, tienes la opción de actualizar el clúster de administrador.
El sesgo de versión y las reglas de versión 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 de los clústeres de usuario
Cuando actualizas los clústeres de usuario, puedes actualizar el clúster de usuario como un clúster completo (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 elijas depende de varios factores, como los siguientes:
- 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.
- Es 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 porque eso 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 desde el 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 grupos de nodos en un clúster de usuario, pero no todos. Por ejemplo, después de actualizar el plano de control, puedes actualizar un grupo de nodos que tenga poco tráfico 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
GKE en VMware te ofrece una variedad de herramientas para actualizar clústeres de usuario.
La herramienta de línea de comandos de
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 a fin de establecer la versión de destino para el plano de control del clúster y, de forma opcional, para 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, este debe estar inscrito en la API de GKE On-Prem para usar la consola o gcloud CLI en la actualización. En la versión 1.16 y en las posteriores, los clústeres creados mediantegkectlse 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, es posible que quieras inscribir el clúster en la API de GKE On-Prem a fin de obtener información sobre los clústeres con la consola o la CLI de gcloud.
La herramienta que uses dependerá de cómo planeas actualizar los clústeres de usuario:
Actualiza el clúster completo: 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 de forma selectiva los grupos de nodos 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 que se actualice 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
Si el plano de control y los grupos de nodos de todos los clústeres de usuario son al menos una versión secundaria posterior que el clúster de administrador, tienes la opción de actualizar el clúster de administrador. 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 versión
El sesgo de versiones es la diferencia en 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 conjunto.
Además, el sesgo 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 del clúster de usuario.
En un entorno de varios clústeres, comprender el sesgo de versiones compatibles y las reglas de versión para actualizaciones puede ayudarte a planificar el orden en el que actualizas los clústeres.
Sesgo de versiones del clúster de administrador y de usuario
Un clúster de administrador puede administrar clústeres de usuario que se encuentren 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.16 y anteriores
En la versión 1.16 y en versiones anteriores, los clústeres de usuario solo pueden ser 1 versión secundaria posterior a su clúster de administrador. Por ejemplo, si un clúster de administrador está en 1.15, los clústeres de usuario que administra 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.
1.28 y posteriores
En la versión 1.28 y posteriores, los clústeres de usuario pueden ser hasta 2 versiones secundarias posteriores que sus clústeres de administrador. Por ejemplo, si un clúster de administrador está en 1.15, los clústeres de usuario que administra ese clúster de administrador pueden estar en 1.15, 1.16 o 1.28 (1.28 es la versión que sigue a 1.16 en la alineación de la versión con GKE).
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 de 1.n+2 no se pueden actualizar a la siguiente versión secundaria hasta que el clúster de administrador se actualice al menos una versión secundaria.
Sesgo de versiones del plano de control del clúster de usuario y del grupo de nodos
1.16 y anteriores
En la versión 1.16 y en versiones anteriores, el plano de control de un clúster de usuario solo puede ser 1 versión secundaria posterior a 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 del clúster pueden estar en 1.15 o 1.16. En términos generales, si 1.n es la versión secundaria del plano de control de un 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 estén en la misma versión secundaria que el plano de control.
1.28 y posteriores
En la versión 1.28 y posteriores, el plano de control de un clúster de usuario puede ser hasta 2 versiones secundarias posteriores 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 del clúster pueden estar en 1.15, 1.16 o 1.28. En términos generales, si 1.n es la versión secundaria del plano de control de un 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 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.
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 siguiente. Por ejemplo, puedes actualizar de 1.28.0 a 1.28.1 o de 1.16.1 a 1.28.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 una versión de cada versión secundaria entre la actual y la de destino. No se admite omitir una versión secundaria. Por ejemplo, si quieres actualizar de la versión 1.15.x a la versión 1.28.x, no puedes actualizar directamente. Primero debes actualizar de 1.15.x a 1.16.x y, luego, a 1.28.x.
En términos generales, solo las actualizaciones de 1.n a 1.n+1 son compatibles con las actualizaciones del clúster de administrador y 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.28 y un grupo de nodos está en 1.15, puedes omitir 1.16 y actualizar el grupo de nodos directamente a 1.28. Las versiones de parche no afectan las reglas de la versión de actualización.
En términos generales, si un plano de control del clúster de usuario se encuentra en 1.n, puedes actualizar los grupos de nodos que están en 1.n-2 directamente a 1.n. Omitir una versión secundaria cuando se actualizan grupos de nodos puede reducir la cantidad de tiempo que realizar dos actualizaciones de grupos de nodos (para actualizar de 1.n-2 a 1.n-1 y, luego, a 1.n). Este es otro motivo por el que quizás 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 más reciente del parche 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 de parche superior. Es decir, puedes actualizar un clúster de la versión 1.28.X a la versión 1.28.Y siempre que Y sea superior a X. Por ejemplo, puedes actualizar de 1.16.0 a 1.16.1 y actualizar de 1.16.1 a 1.16.3.
¿Qué sigue?
Revisa las prácticas recomendadas de actualización y crea un plan para actualizar tus clústeres.