Actualiza GKE On-Prem

En esta página, se explica cómo actualizar GKE On-Prem.

Para actualizar GKE On-Prem, debes actualizar la estación de trabajo de administrador. Luego, actualiza los clústeres.

Antes de comenzar

Además, lee las siguientes consideraciones:

Información sobre el 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.

Actualización secuencial

GKE On-Prem admite la actualización secuencial, lo que significa que el clúster que quieres actualizar debe tener la versión anterior inmediata del parche.

No puedes actualizar los clústeres directamente a la versión más reciente si tienen una versión anterior a la recién mencionada. Si esto sucede, debes actualizar el clúster a cada versión del parche de forma secuencial, hasta llegar a la más reciente.

Ejemplo

Si deseas actualizar a la versión 1.1.0, y la estación de trabajo de administrador y los clústeres de usuario ejecutan la versión 1.0.1 anterior:

  • 1.0.1 (versión más antigua)
  • 1.0.2
  • 1.1.0 (última versión)

Debes realizar la actualización secuencial a la versión 1.0.2 y, luego, a la versión 1.1.0 mediante los siguientes pasos:

  1. Actualiza la estación de trabajo de administrador de 1.0.1 a 1.0.2.
  2. Actualiza los clústeres de 1.0.1 a 1.0.2.
  3. Actualiza la estación de trabajo de administrador de 1.0.2 a 1.1.0
  4. Actualiza los clústeres de 1.0.2 a 1.1.0.

Crea una copia de seguridad del archivo de configuración de GKE On-Prem y de tus archivos de kubeconfig

Cuando actualizas la estación de trabajo de administrador, Terraform borra la VM de la estación de trabajo de administrador y la reemplaza por una actualizada.

Antes de realizar la actualización de la estación de trabajo de administrador, primero debes crear una copia de seguridad del archivo de configuración de GKE On-Prem y de los archivos kubeconfig de los clústeres. Con el comando gkectl create cluster, se crean los archivos kubeconfig para el clúster de administrador ([ADMIN_CLUSTER_KUBECONFIG]) y el clúster de usuario ([USER_CLUSTER_KUBECONFIG]). Consulta un ejemplo en la instalación básica. Después de actualizar la estación de trabajo de administrador, copia esos mismos archivos a la estación de trabajo de administrador actualizada.

Actualiza la estación de trabajo de administrador

Debes usarás Terraform para actualizar la estación de trabajo de administrador.

La estación de trabajo de administrador actualizada incluye las siguientes entidades en la misma versión que el archivo Open Virtualization Appliance (OVA) de la estación de trabajo de administrador:

  • gkectl
  • paquete completo

Descarga el archivo OVA

En Descargas, descarga el archivo OVA de la estación de trabajo de administrador para la versión a la que actualizas.

Para descargar el archivo OVA más reciente, ejecuta el siguiente comando:

gsutil cp gs://gke-on-prem-release/admin-appliance/1.3.2-gke.1/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.{ova,ova.1.sig} ~/

Importa el archivo OVA a vSphere y márcalo como una plantilla de VM

En las siguientes secciones, harás lo siguiente:

  1. Crear algunas variables que declaren elementos de vCenter Server y del entorno de vSphere
  2. Importar el OVA de la estación de trabajo de administrador a vSphere y marcarlo como una plantilla de VM

Crea variables para govc

Antes de importar el OVA de la estación de trabajo de administrador a vSphere, debes proporcionar a govc algunas variables que declaren los elementos de vCenter Server y el entorno de vSphere:

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Puedes elegir usar el grupo de recursos predeterminado de vSphere o crear el tuyo:

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

Donde:

  • [VCENTER_SERVER_ADDRESS] es la dirección IP o el nombre de host de vCenter Server.
  • [VCENTER_SERVER_USERNAME] es el nombre de usuario de una cuenta que contiene la función de administrador o privilegios equivalentes en vCenter Server.
  • [VCENTER_SERVER_PASSWORD] es la contraseña de la cuenta de vCenter Server.
  • [VSPHERE_DATASTORE] es el nombre del almacén de datos que configuraste en el entorno de vSphere.
  • [VSPHERE_DATACENTER] es el nombre del centro de datos que configuraste en el entorno de vSphere.
  • [VSPHERE_CLUSTER] es el nombre del clúster que configuraste en el entorno de vSphere.
    • Para usar un grupo de recursos no predeterminado,
  • [VSPHERE_RESOURCE_POOL] es el nombre del grupo de recursos que configuraste en el entorno de vSphere.

Importa el OVA a vSphere: Interruptor estándar

Si usas un interruptor estándar vSphere, importa el archivo OVA a vSphere mediante este comando:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Importa el archivo OVA a vSphere: Interruptor distribuido

Si usas un interruptor distribuido vSphere, importa el OVA a vSphere mediante este comando, en el que [YOUR_DISTRIBUTED_PORT_GROUP_NAME] es el nombre del grupo de puertos distribuido:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Configura la variable de plantilla de Terraform para la VM de la nueva estación de trabajo de administrador

En el archivo TFVARS de la estación de trabajo de administrador, configura vm_template a la versión a la que actualizas. El valor de vm_template se ve de la siguiente manera, en la que [VERSION] es la versión del archivo OVA:

gke-on-prem-admin-appliance-vsphere-[VERSION]

Usa Terraform para actualizar la estación de trabajo de administrador

Para actualizar la estación de trabajo de administrador, ejecuta el siguiente comando. Este comando borra la VM de la estación de trabajo de administrador actual y la reemplaza por una VM actualizada:

terraform init && terraform apply -auto-approve -input=false

Conéctate a la estación de trabajo de administrador

Ejecuta el siguiente comando para establecer una conexión SSH a la estación de trabajo de administrador:

ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

Copia la configuración de copia de seguridad y los archivos de kubeconfig

Antes, creaste una copia de seguridad del archivo de configuración de GKE On-Prem y de los archivos kubeconfig de los clústeres. Ahora, debes volver a copiar esos archivos a la estación de trabajo de administrador actualizada.

Actualiza clústeres

Después de actualizar la estación de trabajo de administrador y conectarte a ella, sigue estos pasos:

Verifica que haya suficientes direcciones IP disponibles

Antes de realizar la actualización, asegúrate de tener suficientes direcciones IP disponibles para los clústeres.

DHCP

Durante una actualización, GKE On-Prem crea un nodo temporal en el clúster de administrador y en cada clúster de usuario asociado. Asegúrate de que el servidor DHCP pueda proporcionar suficientes direcciones IP para estos nodos temporales. Si deseas obtener más información, consulta Direcciones IP necesarias para clústeres de administrador y de usuario.

IP estáticas

Durante una actualización, GKE On-Prem crea un nodo temporal en el clúster de administrador y en cada clúster de usuario asociado. Para el clúster de administrador y cada uno de los clústeres de usuario, verifica que hayas reservado suficientes direcciones IP. Para cada clúster, debes haber reservado al menos una dirección IP más que la cantidad de nodos del clúster. Para obtener más información, consulta Configura direcciones IP estáticas.

Determina la cantidad de nodos en el clúster de administrador:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

En el comando anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta del archivo kubeconfig del clúster de administrador.

A continuación, observa las direcciones reservadas para el clúster de administrador:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

En la salida, en el campo reservedAddresses, puedes observar la cantidad de direcciones IP que se reservaron para los nodos del clúster de administrador. Por ejemplo, en la siguiente salida, se muestra que hay cinco direcciones IP reservadas para los nodos del clúster de administrador:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Las direcciones IP reservadas deben ser al menos una más que la cantidad de nodos en el clúster de administrador. Si este no es el caso, puedes editar el objeto de clúster para reservar una dirección adicional.

Abre el objeto de clúster para editar:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

En reservedAddresses, agrega un bloque adicional que tenga gateway, hostname, ip y netmask.

Realiza el mismo procedimiento para cada uno de los clústeres de usuario.

Para determinar la cantidad de nodos en un clúster de usuario, haz lo siguiente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

En el ejemplo anterior, se ilustra lo siguiente: [USER_CLUSTER_KUBECONFIG] is the path of your user cluster's kubeconfig file.

Si deseas ver las direcciones reservadas para un clúster de usuario, haz lo siguiente:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

Donde:

  • [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig del clúster de administrador.

  • [USER_CLUSTER_NAME] es el nombre del clúster de usuario.

Para editar el objeto de clúster de un clúster de usuario, sigue estos pasos:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

Modifica el archivo de configuración

En la VM de estación de trabajo de administrador, edita el archivo de configuración que usaste para crear los clústeres de administrador y de usuario. Configura el valor de bundlepath, en el que [VERSION] es la versión de GKE On-Prem en la que actualizas los clústeres:

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

Información sobre las funciones habilitadas de forma automática

Una versión nueva de GKE On-Prem puede incluir funciones nuevas o compatibilidad con funciones específicas de VMware vSphere. A veces, la actualización a una versión de GKE On-Prem habilita de forma automática esas funciones. Aprenderás sobre las funciones nuevas en las notas de la versión de GKE On-Prem. A veces, las funciones nuevas se muestran en el archivo de configuración de GKE On-Prem.

Inhabilita las funciones nuevas a través del archivo de configuración

Si necesitas inhabilitar una función nueva que se habilita de forma automática en una versión de GKE On-Prem nueva y que controla el archivo de configuración, realiza los siguientes pasos antes de actualizar el clúster:

  1. Desde la estación de trabajo de administrador actualizada, crea un archivo de configuración nuevo con un nombre diferente al del archivo de configuración actual:

    gkectl create-config --config [CONFIG_NAME]

  2. Abre el archivo de configuración nuevo y el campo de la función. Cierra el archivo.

  3. Abre el archivo de configuración actual y agrega el campo de la función nueva en la especificación correspondiente.

  4. Proporciona un valor false o equivalente para el campo.

  5. Guarda el archivo de configuración. Continúa con la actualización de los clústeres.

Siempre debes revisar las notas de la versión antes de actualizar los clústeres. No puedes cambiar de forma declarativa la configuración de un clúster existente después de actualizarlo.

Ejecuta gkectl prepare

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, al registro privado de Docker, si configuraste uno.

Para realizar las tareas anteriores, ejecuta el siguiente comando:

gkectl prepare --config [CONFIG_FILE] [FLAGS]

Donde:

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem que usas para realizar la actualización.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

Actualiza el clúster de administrador

Ejecuta el siguiente comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
[FLAGS]

Donde:

  • [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador.

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem que usas para realizar la actualización.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

Actualiza el clúster de usuario

Para actualizar un clúster de usuario, el clúster de administrador debe actualizarse a la versión deseada, o una superior, antes de actualizar el clúster de usuario.

gkectl

Desde la estación de trabajo de administrador, ejecuta el siguiente comando:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
[FLAGS]

Donde:

  • [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador.

  • [CLUSTER_NAME] es el nombre del clúster de usuario que estás actualizando.

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem que usas para realizar la actualización.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

Console

Puedes elegir registrar los clústeres de usuario con la consola de Google Cloud durante la instalación o después de crearlos. Puedes ver o acceder a los clústeres registrados de GKE On-Prem y los clústeres de Google Kubernetes Engine desde el menú de GKE de la consola de Google Cloud.

Cuando hay una actualización disponible para los clústeres de usuario de GKE On-Prem, aparece una notificación en la consola de Google Cloud. Si haces clic en esta notificación, se muestra una lista de las versiones disponibles y un comando de gkectl que puedes ejecutar para actualizar el clúster:

  1. Visita el menú de GKE en la consola de Google Cloud.

    Visita el menú de GKE.

  2. En la columna Notificaciones del clúster de usuario, haz clic en Actualización disponible, si está disponible.

  3. Copia el comando gkectl upgrade cluster.

  4. Desde la estación de trabajo de administrador, ejecuta el comando gkectl upgrade cluster, en el que [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 de GKE On-Prem que usas para realizar la actualización.

Reanuda una actualización

Si la actualización de un clúster de usuario se interrumpe después de que el clúster de administrador se actualiza de forma correcta, puedes reanudar la actualización del clúster de usuario si ejecutas el mismo comando de actualización con la marca --skip-validation-all:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
--skip-validation-all

Información sobre cómo reanudar una actualización de clúster de administrador

No debes interrumpir la actualización de un clúster de administrador. Por el momento, las actualizaciones del clúster de administrador no siempre se pueden reanudar. Si por algún motivo se interrumpe la actualización de un clúster de administrador, debes comunicarte con el equipo de asistencia para obtener ayuda.

Problemas conocidos

Los siguientes problemas conocidos afectan a la actualización de los clústeres.

Versión 1.1.0-gke.6, 1.2.0-gke.6: se quitó el campo stackdriver.proxyconfigsecretname

El campo stackdriver.proxyconfigsecretname se quitó en la versión 1.1.0-gke.6. Las comprobaciones previas de GKE On-Prem mostrarán un error si el campo está presente en el archivo de configuración.

Para solucionar este problema, antes de actualizar a 1.2.0-gke.6, borra el campo proxyconfigsecretname del archivo de configuración.

Stackdriver hace referencia a la versión anterior

Antes de la versión 1.2.0-gke.6, un problema conocido evita que Stackdriver actualice la configuración después de las actualizaciones del clúster. Stackdriver todavía hace referencia a una versión anterior, lo que evita que Stackdriver reciba las funciones más recientes de su canalización de telemetría. Este problema puede dificultar que Atención al cliente de Google solucione los problemas de los clústeres.

Después de actualizar los clústeres a 1.2.0-gke.6, ejecuta el siguiente comando en los clústeres de administrador y usuario:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

En el ejemplo anterior, [KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster.

Interrupción de las cargas de trabajo con PodDisruptionBudgets

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).

Versión 1.2.0-gke.6: Prometheus y Grafana se inhabilitan después de la actualización

En los clústeres de usuario, Prometheus y Grafana se inhabilitan de forma automática durante la actualización. Sin embargo, los datos y las métricas de configuración no se pierden. En los clústeres de administrador, Prometheus y Grafana permanecen habilitados.

Para obtener instrucciones, consulta las notas de la versión de GKE On-Prem.

Versión 1.1.2-gke.0: Los nodos del clúster de usuario borrados no se quitan del almacén de datos de vSAN

Para obtener instrucciones, consulta las notas de la versión de GKE On-Prem.

Versión 1.1.1-gke.2: Se puede borrar el disco de datos en la carpeta del almacén de datos de vSAN

Si usas un almacén de datos de vSAN, debes crear una carpeta en la que puedas guardar el VMDK. Un problema conocido requiere que proporciones la ruta de acceso de identificador único universal (UUID) de la carpeta, en lugar de su ruta de acceso de archivo, a vcenter.datadisk. Esta incompatibilidad puede hacer que las actualizaciones fallen.

Para obtener instrucciones, consulta las notas de la versión de GKE On-Prem.

Actualización a la versión 1.1.0-gke.6 desde la versión 1.0.2-gke.3: Error de OIDC

Los clústeres de las versiones 1.0.11, 1.0.1-gke.5 y 1.0.2-gke.3 que tienen OpenID Connect (OIDC) configurado no se pueden actualizar a la versión 1.1.0-gke.6. Este problema se solucionó en la versión 1.1.1-gke.2.

Si configuraste un clúster de versión 1.0.11, 1.0.1-gke.5 o 1.0.2-gke.3 con OIDC durante la instalación, no puedes actualizarlo. En su lugar, debes crear clústeres nuevos.

Actualiza la versión 1.0.11 a la versión 1.0.2-gke.3

La versión 1.0.2-gke.3 presenta 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 deseas usar OIDC, el campo clientsecret es obligatorio incluso si no deseas acceder a un clúster desde la consola de Google Cloud. A fin de usar OIDC, es posible que debas proporcionar un valor de marcador de posición para clientsecret:

oidc:
  clientsecret: "secret"

El proceso de actualización de los nodos falla

Si tienes objetos PodDisruptionBudget configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment o la HorizontalPodAutoscaler a fin de permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten ninguna interrupción, haz lo siguiente:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Apéndice

Acerca de las reglas de DRS de VMware habilitadas en la versión 1.1.0-gke.6

A partir de la versión 1.1.0-gke.6, GKE On-Prem crea de forma automática reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos del clúster de usuario, de modo que se distribuyan en al menos tres hosts físicos de tu centro de datos. A partir de la versión 1.1.0-gke.6, esta función se habilita de forma automática para clústeres nuevos y existentes.

Antes de realizar la actualización, asegúrate de que el entorno de vSphere cumpla con las siguientes condiciones:

  • DRS de VMware debe estar habilitado. Para el DRS de VMware, se requiere la edición de licencia de vSphere Enterprise Plus. Para aprender a habilitar el DRS, consulta Enabling VMware DRS in a cluster (Habilita el DRS de VMware en un clúster).
  • La cuenta de usuario de vSphere proporcionada en el campo vcenter debe tener el permiso Host.Inventory.EditCluster.
  • Debe haber al menos tres hosts físicos disponibles.

Inhabilita DRS de VMware antes de actualizar a 1.1.0-gke.6

Si no deseas habilitar esta función para los clústeres de usuario existentes, por ejemplo, si no tienes suficientes hosts que admitan la función, realiza los siguientes pasos antes de actualizar los clústeres de usuario:

  1. Abre el archivo de configuración de GKE On-Prem existente.
  2. En la especificación usercluster, agrega el campo antiaffinitygroups: 
    usercluster:
      ...
      antiaffinitygroups:
        enabled: false
  3. Guarda el archivo.
  4. Usa el archivo de configuración para actualizar. Tus clústeres están actualizados, pero la función no está habilitada.

Situación de actualización alternativa

Si los parches de seguridad, como las vulnerabilidades y riesgos comunes (CVE), no existen para la versión de la estación de trabajo de administrador, puedes usar el método alternativo a fin de actualizar GKE On-Prem. El método alternativo solo actualiza gkectl y los clústeres de usuario. No debes actualizar la estación de trabajo de administrador en esta situación. Por lo tanto, solo debes usar este método alternativo después de que se apliquen todas las actualizaciones de seguridad a la estación de trabajo de administrador existente.

  1. Actualiza los componentes de Google Cloud CLI: gcloud components update.
  2. Descarga y, luego, instala la herramienta de gkectl más reciente.
  3. Descarga el paquete.
  4. Actualiza los clústeres de usuario.

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.

Ejecuta comandos de gkectl de forma detallada

-v5

Registra errores de gkectl en stderr

--alsologtostderr

Ubica los registros de gkectl en la estación de trabajo de administrador

Incluso si no pasas las marcas de depuración, puedes ver los registros de gkectl en el siguiente directorio de la estación de trabajo de administrador:

/home/ubuntu/.config/gke-on-prem/logs

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:

  1. 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

  2. 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