En esta página, se explica cómo actualizar los clústeres de administrador y de usuario de una versión de parche de GKE On-Prem a la siguiente versión de parche superior. Para obtener más información sobre las versiones disponibles, consulta Versiones.
También consulta lo siguiente:
Descripción general
GKE On-Prem admite la actualización secuencial. Por ejemplo, supongamos que estas son las únicas versiones que existen:
- 1.0.10
- 1.0.X, en el que X viene después de .10
- 1.0.Y, en el que Y viene después de X
En este caso, 1.0.Y es la versión más reciente. Para actualizar un clúster de la versión 1.0.10 a 1.0.Y, debes seguir estos pasos:
- Actualiza el clúster de 1.0.10 a 1.0.X.
- Luego, actualiza el clúster de 1.0.X a 1.0.Y.
Antes de comenzar
Para establecer una conexión SSH a tu estación de trabajo de administrador, haz lo siguiente:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
Autoriza a
gcloud
para que acceda a Google Cloud:gcloud auth login
Activa la cuenta de servicio de acceso:
gcloud auth activate-service-account --project [PROJECT_ID] \ --key-file [ACCESS_KEY_FILE]
Donde:
- [PROJECT_ID] es el ID del proyecto.
- [ACCESS_KEY_FILE] es la ruta de acceso al archivo de claves JSON para tu cuenta de servicio de acceso, como
/home/ubuntu/access.json
.
Actualiza a la versión 1.0.2
En la versión 1.0.2-gke.3, se agregaron los siguientes campos de OIDC (usercluster.oidc
). Estos campos permiten acceder a un clúster desde la consola de Google Cloud:
- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Si no quieres acceder a un clúster desde la consola de Google Cloud, pero deseas usar OIDC, puedes pasar valores de marcador de posición para estos campos:
oidc: kubectlredirecturl: "redirect.invalid" clientsecret: "secret" usehttpproxy: "false"
Determina la situación de actualización de tus clústeres
Antes de actualizar tu clúster, decide cuál de estas situaciones es relevante para la versión a la que quieres actualizar:
Situación | Acción necesaria | Notas |
---|---|---|
La versión no tiene actualizaciones de seguridad. |
|
|
La versión tiene actualizaciones de seguridad. |
|
Solo debes actualizar tu estación de trabajo de administrador si la versión nueva tiene actualizaciones de seguridad. Cuando se actualiza la estación de trabajo de administrador, se incluye la versión más reciente de gkectl y el paquete. |
Determina la versión de la plataforma
A fin de actualizar los clústeres, debes determinar la versión de la plataforma para ellos:
Desde la documentación
Consulta Versiones.
Desde el paquete
Ejecuta el siguiente comando para extraer el paquete a un directorio temporal:
tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]
Revisa los archivos YAML extraídos para tener una idea general del contenido del paquete.
En particular, abre gke-onprem-vsphere-[VERSION]-images.yaml
. Observa el campo osimages
. Puedes ver la versión de la plataforma de GKE en el nombre del archivo de imagen del SO. Por ejemplo, en la siguiente imagen de SO, puedes ver que la versión de la plataforma de GKE es 1.12.7-gke.19
.
osImages: admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"
Modifica el archivo de configuración
En tu VM de la estación de trabajo de administrador, edita el archivo de configuración. Configura los valores de gkeplatformversion
y bundlepath
. Por ejemplo:
gkeplatformversion: 1.12.7-gke.19 bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz
Cómo ejecutar gkectl prepare
Ejecuta el siguiente comando:
gkectl prepare --config [CONFIG_FILE]
El comando gkectl prepare
realiza las siguientes tareas:
Si es necesario, copia una nueva imagen de SO de nodo en el entorno de vSphere y marca la imagen de SO como una plantilla.
Envía imágenes de Docker actualizadas, especificadas en el conjunto nuevo, a tu registro privado de Docker, si configuraste una.
Actualiza tus clústeres
Para actualizar un clúster de usuario, tu clúster de administrador debe tener una versión igual o superior a la de la versión de destino de la actualización del clúster de usuario. Si la versión de tu clúster de administrador es inferior, deberás actualizarlo antes que al clúster de usuario.
Clúster del administrador
Ejecuta el siguiente comando:
gkectl upgrade admin \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE]
En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster del administrador y [CONFIG_FILE] es el archivo de configuración GKE On-Prem que usas para realizar la actualización.
Clúster de usuario
Ejecuta el siguiente comando:
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE] \ --cluster-name [CLUSTER_NAME]
En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador, [CLUSTER_NAME] es el nombre del clúster de usuario que actualizas y [CONFIG_FILE] es el archivo de configuración GKE On-Prem que usas para realizar la actualización.
Acerca del tiempo de inactividad durante las actualizaciones
Recurso | Descripción |
---|---|
Clúster de administrador | Cuando un clúster de administrador está inactivo, los planos de control y las cargas de trabajo en los clústeres de usuario continúan ejecutándose, a menos que se vean afectados por una falla que causó el tiempo de inactividad. |
Plano de control del clúster de usuario | Por lo general, no es probable que se produzcan tiempos de inactividad perceptibles en los planos de control del clúster de usuario. Sin embargo, las conexiones de larga duración al servidor de la API de Kubernetes podrían fallar y tendrían que restablecerse. En esos casos, el emisor de la API debe volver a intentarlo hasta que se establezca una conexión. En el peor de los casos, puede haber hasta un minuto de tiempo de inactividad durante una actualización. |
Nodos del clúster de usuario | Si una actualización requiere un cambio en los nodos del clúster de usuario, GKE On-Prem los vuelve a crear de forma progresiva y reprograma los Pods que se ejecutan en estos nodos. Puedes evitar el impacto en tus cargas de trabajo; para ello, configura PodDisruptionBudgets y reglas de antiafinidad adecuados. |
Problemas conocidos
- Por el momento, la actualización de los clústeres puede causar interrupciones o tiempo de inactividad para las cargas de trabajo que usan PodDisruptionBudgets (PDB).
Soluciona problemas
Para obtener más información, consulta Soluciona problemas.
Se crearon nodos nuevos, pero no en buen estado
- Síntomas
Los nodos nuevos no se registran en el plano de control del clúster de usuario cuando usan el modo de balanceo de cargas manual.
- Causas posibles
Es posible que la validación de Ingress en nodos esté habilitada y que bloquee el proceso de inicio de los nodos.
- Solución
Para inhabilitar la validación, ejecuta este comando:
kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge
Diagnostica problemas de clústeres mediante gkectl
Usa los comandos gkectl diagnose
para identificar los problemas de clústeres y compartir la información de un clúster con Google. Consulta Diagnostica problemas de clústeres.
Comportamiento de registro predeterminado
Para gkectl
y gkeadm
, basta con usar la configuración de registro predeterminada:
-
De forma predeterminada, las entradas de registro se guardan de la siguiente manera:
-
Para
gkectl
, el archivo de registro predeterminado es/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
y el archivo está vinculado con un symlink con el archivologs/gkectl-$(date).log
en el directorio local en el que ejecutasgkectl
. -
Para
gkeadm
, el archivo de registro predeterminado eslogs/gkeadm-$(date).log
en el directorio local en el que ejecutasgkeadm
.
-
Para
- Todas las entradas de registro se guardan en el archivo de registro, incluso si no se imprimen en la terminal (cuando
--alsologtostderr
esfalse
). - El nivel de verbosidad
-v5
(predeterminado) cubre todas las entradas de registro que necesita el equipo de asistencia al cliente. - El archivo de registro también contiene el comando ejecutado y el mensaje de error.
Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.
Especifica una ubicación no predeterminada para el archivo de registro
A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl
, usa la marca --log_file
. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.
A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm
, usa la marca --log_file
.
Ubica los registros de la API de clúster en el clúster de administrador
Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes intentar depurarla mediante la inspección de los registros de los controladores de la API de clúster en el clúster de administrador:
Encuentra el nombre del Pod de controladores de la API de clúster en el espacio de nombres
kube-system
, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abre los registros del Pod, en los que [POD_NAME] es el nombre del Pod. De manera opcional, usa
grep
o una herramienta similar para buscar errores:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager