Cómo omitir una versión cuando actualizas grupos de nodos

Las actualizaciones de omisión de versión te permiten omitir una versión secundaria cuando actualizas grupos de nodo trabajador después de actualizar el plano de control del clúster de usuario, lo que reduce la cantidad de ciclos de vaciado y reinicio de nodos. Por ejemplo, si un grupo de nodo trabajador está en la versión 1.29, puedes actualizar el plano de control del clúster de usuario a la versión 1.30 y, luego, a la 1.31, y, luego, actualizar el grupo de nodo trabajador directamente de la versión 1.29 a la 1.31. Esta capacidad es compatible con clústeres avanzados y no avanzados, excepto en los clústeres avanzados de la versión 1.31 y el software de Google Distributed Cloud solo para las versiones de VMware anteriores a la 1.28.

Antes de comenzar, asegúrate de estar familiarizado con la Descripción general de la actualización, las Reglas de versión de actualización, las Prácticas recomendadas para la actualización y la Actualización de un clúster.

Limitaciones

Las siguientes son limitaciones de las actualizaciones de omisión de versión:

  • Las actualizaciones de omisión de versión son compatibles con los grupos de nodos de Ubuntu y Container-Optimized OS, pero no con los de Windows.

  • Versión 1.31: Esta función no está disponible en clústeres avanzados.

  • Versión 1.32 y posteriores: Esta función está disponible en clústeres avanzados.

  • Los grupos de nodos del balanceador de cargas (grupos de nodos con enableLoadBalancer: true) no admiten actualizaciones de omisión de versión ni sesgo de versión. La versión de un grupo de nodos del balanceador de cargas debe coincidir con la versión del clúster.

  • Debido a las restricciones de Kubernetes, el plano de control de un clúster de usuario se debe actualizar una versión secundaria a la vez. Sin embargo, ten en cuenta que actualizar solo el plano de control lleva mucho menos tiempo y es menos riesgoso que actualizar los grupos de nodos en los que se ejecutan tus cargas de trabajo.

Beneficios de las actualizaciones con omisión de versiones

En esta sección, se describen algunos beneficios de usar las actualizaciones con omisión de versiones.

Es más fácil mantener tus clústeres en una versión compatible

Cada cuatro meses, se lanza una nueva versión secundaria de Google Distributed Cloud, y cada versión secundaria tiene un período de asistencia de un año. Para que tus clústeres permanezcan dentro de la ventana de asistencia, debes realizar una actualización de versión secundaria aproximadamente cada cuatro meses, como se muestra a continuación:

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar
1.14 Actualización
1.15 Actualización
1.16 Actualización
1.28 Actualización
1.29 Actualización

Este requisito impone desafíos cuando necesitas un período de validación largo para verificar una versión secundaria nueva y un período de mantenimiento corto para actualizar tus clústeres a la versión secundaria nueva. Para superar estos desafíos, puedes usar una actualización de omisión de versión, que permite que tus clústeres permanezcan dentro del período admitido actualizando un clúster cada ocho meses en lugar de cada cuatro. En la siguiente tabla, se muestra cómo omitir la actualización de la versión 1.15 significa que solo actualizas después de ocho meses en lugar de cuatro.

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar

Abr

May

Jun

Jul

Ago

Sep

Oct

Nov

Dic

Ene

Feb

Mar
1.14 Actualización
1.15
1.16 Actualización
1.28
1.29

Omitir una versión secundaria cuando actualizas tus grupos de nodos reduce la cantidad de actualizaciones necesarias para mantenerte en una versión compatible. Además, no necesitas calificar la versión secundaria omitida, ya que el plano de control solo la usa de forma temporal.

Período de mantenimiento más corto

Con una actualización de omisión de versión, no necesitas ampliar el período de mantenimiento. Omitir una versión secundaria cuando se actualizan los grupos de nodos lleva la misma cantidad de tiempo que actualizar los grupos de nodos a la siguiente versión secundaria, ya que cada nodo de un grupo de nodos se vacía y se vuelve a crear una vez. Por lo tanto, una actualización con omisión de versión ahorra tiempo en general y reduce la interrupción de la carga de trabajo.

Resumen

En resumen, una actualización con omisión de versión proporciona los siguientes beneficios:

  • Actualiza los clústeres a una versión compatible: Google Distributed Cloud admite las tres versiones secundarias más recientes. Si tus clústeres están en una versión no compatible, según la versión del clúster, omitir una versión secundaria cuando actualizas los grupos de nodos podría llevar tus clústeres a una versión compatible con menos actualizaciones.

  • Ahorra tiempo: Omitir una versión secundaria cuando actualizas grupos de nodos toma la misma cantidad de tiempo que actualizar los grupos de nodos a la siguiente versión secundaria. Por lo tanto, una actualización de omisión de versión tarda aproximadamente la mitad del tiempo que actualizar los grupos de nodos dos veces. Del mismo modo, con una actualización de omisión de versión, solo tienes un período de validación, en comparación con los dos de las actualizaciones normales.

  • Reduce las interrupciones: Los períodos más largos entre las actualizaciones y el menor tiempo dedicado a actualizar y validar implican que tus cargas de trabajo se ejecutan durante más tiempo con menos interrupciones.

Controla las versiones del plano de control y del grupo de nodos durante una actualización

En el archivo de configuración del clúster de usuario, el campo nodePools[i].gkeOnPremVersion permite que un grupo de nodos específico use una versión diferente de la del campo gkeOnPremVersion de nivel superior. Si cambias el valor del campo nodePools[i].gkeOnPremVersion, controlas cuándo se actualiza un grupo de nodos cuando ejecutas gkectl upgrade cluster. Si no incluyes nodePools[i].gkeOnPremVersion en el archivo de configuración o si estableces el campo en una cadena vacía, los grupos de nodos se actualizan a la misma versión de destino que especificas en gkeOnPremVersion.

Secuencia de actualización con omisión de versiones

La secuencia en la que actualizas los clústeres de administrador y de usuario depende de la versión del clúster a la que actualizas, que se conoce como la versión de destino:

1.32 y versiones posteriores

Usa esta secuencia si la versión de destino es 1.32 o posterior. Supongamos que el plano de control del clúster de usuario y todos los grupos de nodos están en la versión secundaria 1.N. En general, la actualización del clúster de 1.N a 1.N+2 con una actualización de omisión de versión funciona de la siguiente manera:

  1. Actualiza el clúster de administrador de la versión 1.N a una versión intermedia, 1.N+1.
  2. Actualiza el clúster de administrador de la versión intermedia, 1.N+1 a la versión de destino 1.N+2.
  3. Actualiza solo el plano de control del clúster de usuario de la versión de origen, 1.N, a una versión intermedia, 1.N+1. Deja los grupos de nodos en la versión de origen. La versión intermedia es necesaria porque el plano de control debe actualizarse una versión secundaria a la vez.
  4. Actualiza el plano de control y los grupos de nodos a la versión de destino, 1.N+2.

1.31

Usa esta secuencia especial si el clúster de usuario está en la versión 1.29, lo que significa que la versión de destino es la 1.31. Cuando un clúster de usuario está en la versión 1.29, un clúster de administrador que lo administra podría estar en la versión 1.16, 1.28 o 1.29.

  1. Si tu clúster de administrador está en la versión 1.16, actualízalo a la 1.28.
  2. Si tu clúster de administrador tiene la versión 1.28, actualízalo a la 1.29.
  3. Actualiza solo el plano de control del clúster de usuario de la versión de origen, 1.29, a una versión intermedia, 1.30. Deja los grupos de nodos en la versión de origen. La versión intermedia 1.30 es necesaria porque el plano de control debe actualizarse una versión secundaria a la vez.
  4. Actualiza el clúster de administrador de la versión 1.29 a la versión intermedia, 1.30.
  5. Actualiza el clúster de administrador a la versión de destino, 1.31.
  6. Actualiza el plano de control del clúster de usuario y los grupos de nodos a la versión de destino, 1.31.

1.30 y versiones más bajas

Usa esta secuencia si la versión de destino es 1.30 o anterior.

Supongamos que el plano de control del clúster de usuario y todos los grupos de nodos están en la versión secundaria 1.N. En general, la actualización del clúster de 1.N a 1.N+2 con una actualización de omisión de versión funciona de la siguiente manera:

  1. Actualiza solo el plano de control de la versión de origen, 1.N, a una versión intermedia 1.N+1. Deja los grupos de nodos en la versión de origen. La versión intermedia es necesaria porque el plano de control debe actualizarse una versión secundaria a la vez.
  2. Actualiza el plano de control y los grupos de nodos a la versión de destino 1.N+2.

Realiza una actualización con omisión de versiones

En esta sección, se proporcionan los pasos para realizar una actualización de omisión de versión.

Antes de comenzar

  1. Asegúrate de que la versión actual (la versión de origen) del clúster sea la 1.16 o una posterior. Asegúrate de verificar la versión del plano de control (gkeOnPremVersion) y todos los grupos de nodos (nodePools[i].gkeOnPremVersion).

  2. En la versión 1.29 y posteriores, las verificaciones previas del servidor están habilitadas de forma predeterminada. Asegúrate de revisar tus reglas de firewall para realizar los cambios necesarios.

  3. Para actualizar a la versión 1.28 y posteriores, debes habilitar kubernetesmetadata.googleapis.com y otorgar el rol de Identity and Access Management (IAM) de kubernetesmetadata.publisher a la cuenta de servicio de supervisión y registro. Para obtener más información, consulta Requisitos de la API de Google y de IAM.

Realiza la actualización

1.32 y versiones posteriores

Usa esta secuencia si la versión de destino es la 1.32 o una posterior.

Antes de comenzar, asegúrate de que tu clúster de administrador tenga, al menos, la misma versión secundaria (1.N) que tu clúster de usuario. Si tu clúster de usuario está en la versión 1.30 y tu clúster de administrador está en la versión 1.28 o 1.29, actualiza tu clúster de administrador una versión secundaria a la vez hasta que alcance la versión 1.30. Si ya actualizaste tu clúster de administrador a 1.N+1 o 1.N+2, por ejemplo, mientras actualizabas otro clúster de usuario, omite los pasos de actualización del clúster de administrador completados.

  1. Define la versión de origen (1.N), la versión intermedia (1.N+1) y la versión de destino (1.N+2) en las siguientes variables de marcador de posición. Especifica los números de versión completos con el formato X.Y.Z-gke.N, como 1.34.1000-gke.111:

    Descripción Versión
    Obtén la versión actual del clúster de usuario. Esta es la versión de origen (1.N). SOURCE_VERSION
    Selecciona una versión intermedia (1.N+1). INTERMEDIATE_VERSION
    Selecciona el parche recomendado de la versión secundaria de destino (1.N+2). TARGET_VERSION

  2. Actualiza la estación de trabajo de administrador y el clúster de administrador de la versión de origen (1.N) a la versión intermedia (1.N+1):

    1. Actualiza tu estación de trabajo de administrador a la versión intermedia, INTERMEDIATE_VERSION, y espera a que la actualización se complete correctamente.

    2. Importa las imágenes de SO del paquete intermedio a vSphere:

      gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

      Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.

    3. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en el paquete intermedio:

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

    4. Actualiza el clúster de administrador a la versión intermedia:

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

      Reemplaza ADMIN_CLUSTER_CONFIG_FILE por la ruta de acceso al archivo de configuración del clúster de administrador.

  3. Actualiza la estación de trabajo de administrador y el clúster de administrador de la versión intermedia (1.N+1) a la versión de destino (1.N+2):

    1. Actualiza tu estación de trabajo de administrador a la versión de destino, TARGET_VERSION, y espera a que la actualización se complete correctamente.

    2. Importa las imágenes de SO del paquete de destino a vSphere:

      gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    3. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en el paquete de destino:

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

    4. Actualiza el clúster de administrador a la versión de destino:

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  4. Actualiza solo el plano de control del clúster de usuario de la versión de origen (1.N) a la versión intermedia (1.N+1):

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión intermedia, INTERMEDIATE_VERSION.

      • Establece todas las versiones del grupo de nodo trabajador en nodePools[i].gkeOnPremVersion en la versión de origen, SOURCE_VERSION. Si tu clúster tiene grupos de nodos de balanceador de cargas (enableLoadBalancer: true), establece su campo gkeOnPremVersion en una cadena vacía ("") para que se actualicen con el plano de control.

      Después de actualizar el archivo de configuración, se verá similar al siguiente ejemplo:

      gkeOnPremVersion: INTERMEDIATE_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields

    2. Actualiza el plano de control del clúster de usuario:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Reemplaza USER_CLUSTER_CONFIG_FILE por la ruta de acceso al archivo de configuración del clúster de usuario.

  5. Actualiza el plano de control del clúster de usuario y los grupos de nodo trabajador a la versión de destino (1.N+2):

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión de destino, TARGET_VERSION.

      • Establece nodePools[i].gkeOnPremVersion para cada grupo de nodos en una cadena vacía ("").

      Después de actualizar el archivo de configuración, se verá similar al siguiente ejemplo:

      gkeOnPremVersion: TARGET_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: ""
  # Omitted fields

    2. Actualiza el plano de control y los grupos de nodos del clúster de usuario:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

1.31

Usa esta secuencia especial si el clúster de usuario está en la versión 1.29, lo que significa que la versión de destino es la 1.31. Esta secuencia es necesaria porque las reglas de versión cambiaron en la versión 1.31.

Cuando un clúster de usuario está en la versión 1.29, un clúster de administrador que lo administra podría estar en la versión 1.16, 1.28 o 1.29.

  1. Si tu clúster de administrador tiene la versión 1.16, sigue los pasos para actualizar la estación de trabajo de administrador y actualizar el clúster de administrador a la versión 1.28.

  2. Si tu clúster de administrador tiene la versión 1.28, sigue los pasos para actualizar la estación de trabajo de administrador y actualizar el clúster de administrador a la versión 1.29.

  3. Para ahorrar espacio en tu estación de trabajo de administrador, quita los paquetes descargados:

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Cuando el clúster de administrador y todos los clústeres de usuario estén en la versión 1.29, puedes iniciar la actualización de la versión omitida.

  1. Define la versión de origen (1.29), una versión intermedia (1.30) y la versión de destino (1.31) en las siguientes variables de marcador de posición. Todas las versiones deben ser el número de versión completo con el formato x.y.z-gke.N, como 1.29.700-gke.110.

    Versión
    Obtén la versión 1.29 del clúster de usuario actual. Esta es la versión de origen. SOURCE_VERSION
    Elige una versión 1.30 intermedia. INTERMEDIATE_VERSION
    Elige la versión de destino 1.31. Selecciona el parche recomendado de la versión secundaria 1.31. TARGET_VERSION

  2. Actualiza tu estación de trabajo de administrador a la versión intermedia 1.30, INTERMEDIATE_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  3. Instala el paquete correspondiente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Actualiza la estación de trabajo de administrador otra vez, pero esta vez a la versión 1.31 de destino, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  5. Instala el paquete correspondiente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Actualiza solo el plano de control del clúster de usuario a la versión intermedia de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión intermedia, INTERMEDIATE_VERSION.

      • Establece todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion en la versión de origen, SOURCE_VERSION.

      Después de actualizar el archivo de configuración, debería verse similar al siguiente:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Actualiza el plano de control:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Reemplaza USER_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de usuario.

  7. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en la versión intermedia 1.30 del paquete:

    bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. Actualiza el clúster de administrador a la versión intermedia 1.30:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. Establece el campo bundlePath en el archivo de configuración del clúster de administrador en la versión 1.31 de destino del paquete:

    bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Actualiza el clúster de administrador a la versión 1.31 de destino:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión de destino, TARGET_VERSION.

      • Establece todos los nodePools[i].gkeOnPremVersion en una cadena vacía.

      Después de actualizar el archivo de configuración, debería verse similar al siguiente:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Actualiza el plano de control y los grupos de nodos:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

1.30 y versiones más bajas

Usa esta secuencia si la versión de destino es 1.30 o anterior.

  1. Define la versión de origen (1.N), la versión intermedia (1.N+1) y la versión de destino (1.N+2) en las siguientes variables de marcador de posición. Todas las versiones deben ser el número de versión completo con el formato x.y.z-gke.N, como 1.16.11-gke.25.

    Versión
    Obtén la versión actual del clúster. Esta es la versión de origen (1.N). SOURCE_VERSION
    Elige una versión intermedia (1.N+1). INTERMEDIATE_VERSION
    Elige la versión de destino (1.N+2). Selecciona el parche recomendado de la versión secundaria de destino. TARGET_VERSION

  2. Actualiza tu estación de trabajo de administrador a la versión intermedia, INTERMEDIATE_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  3. Instala el paquete correspondiente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

  4. Actualiza tu estación de trabajo de administrador otra vez, pero esta vez a la versión de destino, TARGET_VERSION. Espera a que aparezca un mensaje que indique que la actualización se realizó correctamente.

  5. Instala el paquete correspondiente:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Actualiza solo el plano de control a la versión intermedia de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión intermedia, INTERMEDIATE_VERSION.

      • Establece todas las versiones del grupo de nodos en nodePools[i].gkeOnPremVersion en la versión de origen, SOURCE_VERSION.

      Después de actualizar el archivo de configuración, debería verse similar al siguiente:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Actualiza el plano de control:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Reemplaza USER_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de usuario.

  7. Actualiza el plano de control y los grupos de nodos a la versión de destino de la siguiente manera:

    1. Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

      • Establece el campo gkeOnPremVersion en la versión de destino, TARGET_VERSION.

      • Establece todos los nodePools[i].gkeOnPremVersion en una cadena vacía.

      Después de actualizar el archivo de configuración, debería verse similar al siguiente:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Actualiza el plano de control y los grupos de nodos:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

Si no tienes otros clústeres de usuario para actualizar, quita los paquetes de tu estación de trabajo de administrador para ahorrar espacio:

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

¿Qué sigue?