Prácticas recomendadas para las actualizaciones de clústeres de GKE en VMware

En este documento, se describen las prácticas recomendadas y las consideraciones para actualizar GKE en VMware. Aprenderás a prepararte para las actualizaciones del clúster y conocerás las prácticas recomendadas que debes seguir antes de la actualización. Estas prácticas recomendadas ayudan a reducir los riesgos asociados con las actualizaciones de los clústeres.

Si tienes varios entornos, como prueba, desarrollo y producción, te recomendamos que comiences con el entorno menos crítico, como test, y que verifiques la funcionalidad de actualización. Después de verificar que la actualización se realizó de forma correcta, continúa con el siguiente entorno. Repite este proceso hasta que actualices los entornos de producción. Este enfoque te permite pasar de un punto crítico al siguiente y verificar que la actualización y tus cargas de trabajo se ejecuten de forma correcta.

Lista de tareas de actualización

Para que el proceso de actualización sea lo más sencillo posible, revisa y completa las siguientes verificaciones antes de comenzar a actualizar los clústeres:

Planifica la actualización

Las actualizaciones pueden ser invasivas. Antes de iniciar la actualización, planifica con cuidado para asegurarte de que el entorno y las aplicaciones estén listos.

Estima el compromiso de tiempo y planifica un período de mantenimiento

De forma predeterminada, todos los grupos de nodos se actualizan en paralelo, pero dentro de cada grupo de nodos, los nodos se actualizan de forma secuencial. Por lo tanto, el tiempo total de una actualización depende de la cantidad de nodos en el grupo de nodos más grande. Para calcular una estimación aproximada del tiempo de actualización, usa 15 minutos × la cantidad de nodos en el grupo de nodos más grande. Por ejemplo, si tienes 10 nodos en el grupo más grande, el tiempo total de actualización sería de unos 150 minutos.

En la versión 1.28 y en versiones posteriores, puedes acelerar una actualización si estableces el valor de maxSurge para los grupos de nodos individuales.

Crea una copia de seguridad del clúster de usuario y administrador

Antes de iniciar la actualización, crea una copia de seguridad de los clústeres de usuario y de administrador.

Una copia de seguridad de un clúster de usuario es una instantánea del depósito de etcd del clúster de usuario. El almacén de etcd contiene todos los objetos de Kubernetes y los objetos personalizados necesarios para administrar el estado del clúster. La instantánea contiene los datos necesarios para volver a crear los componentes y las cargas de trabajo del clúster. Para obtener más información, consulta cómo crear una copia de seguridad de un clúster de usuario.

Con GKE on VMware versión 1.8 y posteriores, puedes configurar una copia de seguridad automática con clusterBackup.datastore en el archivo de configuración del clúster de administrador. Para habilitar esta función en un clúster existente, edita el archivo de configuración del clúster de administrador, agrega el campo clusterBackup.datastore y, luego, ejecuta gkectl update admin.

Después de habilitar clusterBackup.datastore, se crea una copia de seguridad de tu clúster de administrador de forma automática en etcd en el almacén de datos de vSphere configurado. Este proceso de copia de seguridad se repite cada vez que hay un cambio en el clúster de administrador. Cuando inicias la actualización de un clúster, se ejecuta una tarea de copia de seguridad antes de actualizarlo.

Para restablecer un clúster de administrador a partir de su copia de seguridad si tienes problemas, consulta Crea una copia de seguridad y restablece un clúster de administrador con gkectl.

Revisa el uso de PodDisruptionBudgets

En Kubernetes, PodDisruptionBudgets (PDB) puede ayudar a evitar interrupciones o tiempos de inactividad no deseados de la aplicación. Los PDB le indican al programador que siempre mantenga una cantidad de Pods en ejecución mientras que otros Pods podrían estar fallando. Este comportamiento es una forma útil de garantizar la disponibilidad de las aplicaciones.

  1. Para verificar qué PDB están configurados en tu clúster, usa el comando kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Reemplaza KUBECONFIG por el nombre de tu archivo kubeconfig.

    En el siguiente resultado de ejemplo, se muestran los PDB con los nombres istio-ingress, istiod y kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

En la tabla anterior, cada PDB especifica que al menos un Pod debe estar siempre disponible. Esta disponibilidad se vuelve crítica durante las actualizaciones cuando se agotan los nodos.

Verifica si hay PDB que no se puedan entregar. Por ejemplo, puedes establecer una disponibilidad mínima de 1 cuando el objeto Deployment solo tenga 1 réplica. En este ejemplo, la operación de vaciado se interrumpe porque el controlador de recursos no puede satisfacer el PDB.

Para asegurarte de que los PDB no interfieran en el procedimiento de actualización, verifica todos los PDB de un clúster determinado antes de iniciar la actualización. Es posible que debas coordinar con los equipos de desarrollo y los propietarios de las aplicaciones para cambiar o inhabilitar de forma temporal los PDB durante una actualización del clúster.

GKE en VMware ejecuta una verificación previa durante el proceso de actualización para advertir sobre los PDB. Sin embargo, también debes verificar de forma manual los PDB para garantizar una experiencia de actualización sin problemas. Para obtener más información sobre los PDB, consulta Especifica un presupuesto de interrupción para tu aplicación.

Revisa las direcciones IP disponibles

Las siguientes consideraciones de dirección IP se aplican durante las actualizaciones del clúster:

  • El proceso de actualización del clúster crea un nodo nuevo y desvía los recursos antes de borrar el anterior. Te recomendamos que siempre tengas direcciones IP N + 1 para el clúster de administrador o de usuario, en las que N es la cantidad de nodos en el clúster.
  • Cuando usas direcciones IP estáticas, las direcciones IP obligatorias deben aparecer en los archivos de bloques de IP.
  • Si usas DHCP, asegúrate de que las VM nuevas puedan obtener asignaciones de IP adicionales en la subred deseada durante una actualización.
    • Si necesitas agregar direcciones IP, actualiza el archivo de bloque de IP y, luego, ejecuta el comando gkectl update. Para obtener más información, consulta Planifica las direcciones IP.
  • Si usas direcciones IP estáticas y deseas acelerar el proceso de actualización del clúster de usuario, enumera suficientes direcciones IP en tu archivo de bloque de IP para que cada grupo de nodos pueda tener una dirección IP adicional disponible. Este enfoque permite que el proceso acelere el procedimiento de adición y eliminación de VM, ya que se realiza por grupo de nodos.
    • Aunque este enfoque es una buena opción para acelerar las actualizaciones del clúster de usuario, ten en cuenta la disponibilidad de recursos y rendimiento del entorno de vSphere antes de continuar.
  • Si solo hay una IP libre para todo el clúster de usuario, esta limitación ralentiza el proceso de actualización a solo una VM a la vez, incluso cuando se usan varios grupos de nodos.

Verifica el uso del clúster

Asegúrate de que los Pods se puedan evacuar cuando se desvíe el nodo y que haya suficientes recursos en el clúster que se está actualizando para administrar la actualización. Para verificar el uso actual de los recursos del clúster, puedes usar paneles personalizados en la observabilidad de Google Cloud o directamente en el clúster con comandos como kubectl top nodes.

Los comandos que ejecutas en el clúster te muestran una instantánea del uso actual de los recursos del clúster. Los paneles pueden proporcionar una vista más detallada de los recursos que se consumen con el tiempo. Estos datos de uso de recursos pueden ayudar a indicar cuándo una actualización causaría la menor interrupción, por ejemplo, durante los fines de semana o las noches, según la carga de trabajo en ejecución y los casos de uso.

El tiempo de actualización del clúster de administrador puede ser menos crítico que para los clústeres de usuario, ya que la actualización del clúster de administrador no suele generar tiempo de inactividad en la aplicación. Sin embargo, sigue siendo importante verificar los recursos gratuitos en vSphere antes de comenzar una actualización del clúster de administrador. Además, la actualización del clúster de administrador puede implicar algún riesgo y, por lo tanto, se recomienda durante períodos de uso menos activos cuando el acceso de administración al clúster es menos crítico.

Para obtener más información, consulta qué servicios se ven afectados durante la actualización de un clúster.

Verifica el uso de vSphere

Verifica que haya suficientes recursos en la infraestructura de vSphere subyacente. Para verificar el uso de este recurso, selecciona un clúster en vCenter y revisa la pestaña Resumen.

En la pestaña de resumen, se muestra el consumo general de memoria, CPU y almacenamiento de todo el clúster. Debido a que las actualizaciones de GKE en VMware demandan recursos adicionales, también debes verificar si el clúster puede manejar estas solicitudes de recursos adicionales.

Como regla general, el clúster de vSphere debe ser compatible con los siguientes recursos adicionales:

  • Más de 1 VM por actualización de clúster de administrador
  • +1 VM por grupo de nodos por actualización del clúster de usuario

Por ejemplo, supongamos que un clúster de usuario tiene 3 grupos de nodos en los que cada uno tiene nodos que usan 8 CPU virtuales y 32 GB o más de RAM. Debido a que la actualización se realiza en paralelo para los 3 grupos de nodos de forma predeterminada, el procedimiento de actualización consume los siguientes recursos adicionales para los 3 nodos de aumento adicionales:

  • 24 CPU virtuales
  • 256 GB de RAM
  • Espacio en el disco de la VM + 256 GB de vSwap

El proceso de actualización crea VMs con la operación de clonación de vSphere. La clonación de varias VM desde una plantilla puede generar estrés en el sistema de almacenamiento subyacente en forma de operaciones de E/S crecientes. La actualización puede ralentizarse en gran medida si el subsistema de almacenamiento subyacente no puede proporcionar un rendimiento suficiente durante una actualización.

Si bien vSphere está diseñado para el uso simultáneo de recursos y tiene mecanismos para proporcionar recursos, incluso cuando hay un exceso de compromiso, te recomendamos que no superes el compromiso de la memoria de la VM. El exceso de compromiso de memoria puede generar impactos graves en el rendimiento que afecten a todo el clúster, ya que vSphere proporciona la “RAM faltante” debido al intercambio de páginas en el almacén de datos. Este comportamiento puede causar problemas durante la actualización de un clúster y causar impactos en el rendimiento en otras VM en ejecución en el clúster de vSphere.

Si los recursos disponibles ya son escasos, apaga las VM innecesarias para satisfacer estos requisitos adicionales y evitar un posible impacto en el rendimiento.

Verifica el estado y la configuración del clúster

Ejecuta las siguientes herramientas en todos los clústeres antes de la actualización:

  • El comando gkectl diagnose: gkectl diagnose garantiza que todos los clústeres estén en buen estado. El comando ejecuta verificaciones avanzadas, por ejemplo, para identificar los nodos que no están configurados correctamente o que tienen Pods que están atascados.

  • La herramienta previa a la actualización: además de verificar el estado y la configuración del clúster, la herramienta busca posibles problemas conocidos que puedan ocurrir durante una actualización del clúster.

Aunque el comando gkectl upgrade ejecuta comprobaciones preliminares y detiene el proceso de actualización si estas no se realizan de forma correcta, las comprobaciones preliminares están allí para proteger los clústeres de cualquier posible daño. Te recomendamos que uses las herramientas para identificar y solucionar problemas antes de la actualización, en lugar de depender de las comprobaciones preliminares.

Si el comando gkectl diagnose muestra una advertencia Cluster unhealthy, corrige los problemas antes de intentar una actualización.

Para obtener más información, consulta Diagnostica problemas de clústeres.

Usa objetos Deployment para minimizar la interrupción de las aplicaciones

Dado que los nodos deben vaciarse durante las actualizaciones, las actualizaciones del clúster pueden provocar interrupciones en la aplicación. Vaciar los nodos significa que todos los Pods en ejecución deben cerrarse y reiniciarse en los nodos restantes del clúster.

Si es posible, tus aplicaciones deben usar objetos Deployment. Con este enfoque, las aplicaciones están diseñadas para controlar interrupciones. El impacto debe ser mínimo en los objetos Deployment que tienen varias réplicas. Aún puedes actualizar el clúster si las aplicaciones no usan objetos Deployment.

También hay reglas para las implementaciones que garanticen que una cantidad establecida de réplicas siempre se siga ejecutando. Estas reglas se conocen como PodDisruptionBudgets (PDB). Los PDB te permiten limitar la interrupción de una carga de trabajo cuando sus Pods deben reprogramarse por algún motivo, como actualizaciones o mantenimiento en los nodos del clúster, y es importante verificarlos antes de una actualización.

Usa un par de balanceador de cargas de alta disponibilidad

Si usas Seesaw como balanceador de cargas en un clúster, los balanceadores de cargas se actualizan automáticamente cuando actualizas el clúster. Esta actualización puede causar una interrupción del servicio. Para reducir el impacto de una actualización y una eventual falla del balanceador de cargas, puedes usar un par de alta disponibilidad (par de HA). En esta configuración, el sistema crea y configura dos VM del balanceador de cargas para que se pueda realizar una conmutación por error al otro intercambio de tráfico.

Para aumentar la disponibilidad del servicio (es decir, al servidor de la API de Kubernetes), te recomendamos que siempre uses un par de alta disponibilidad frente al clúster de administrador. Para obtener más información sobre Seesaw y su configuración de alta disponibilidad, consulta Balanceo de cargas en paquetes con Seesaw.

Para evitar una interrupción del servicio durante una actualización con un par de HA, el clúster inicia una conmutación por error antes de crear la nueva VM del balanceador de cargas. Si un clúster de usuario solo usa una instancia de balanceador de cargas, se produce una interrupción del servicio hasta que se complete la actualización del balanceador de cargas.

Te recomendamos que tengas un par de balanceador de cargas con alta disponibilidad si el clúster de usuario en sí también está configurado para tener alta disponibilidad. En esta serie de prácticas recomendadas, se supone que un clúster de usuario con alta disponibilidad usa un par de balanceador de cargas con alta disponibilidad.

Cuando la versión 1.11 o 1.12 de GKE en VMware usa MetalLB como un balanceador de cargas en paquetes, no se requiere una configuración previa a la actualización. El balanceador de cargas se actualiza durante el proceso de actualización del clúster.

Decide cómo actualizar cada clúster de usuario

En la versión 1.14 y posteriores, puedes optar por actualizar un clúster de usuario en su totalidad (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. Para obtener información sobre por qué es posible que desees actualizar el plano de control por separado, consulta Actualizaciones del clúster de usuario.

En un entorno de varios clústeres, realiza un seguimiento de los clústeres de usuario que se actualizaron y registra su número de versión. Si decides actualizar el plano de control y los grupos de nodos por separado, registra la versión del plano de control y cada grupo de nodos en cada clúster.

Verifica las versiones de los clústeres de usuario y administrador

gkectl

  • Para verificar la versión de los clústeres de usuario, haz lo siguiente:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

  • Para verificar la versión de los clústeres de administrador, haz lo siguiente:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

Para los clústeres que están inscritos en la API de GKE On-Prem, puedes usar gcloud CLI para obtener las versiones de los clústeres de usuario, los grupos de nodos del clúster de usuario y los clústeres de administrador.

  1. Asegúrate de tener la versión más reciente de la CLI de gcloud. Si es necesario, actualiza los componentes de gcloud CLI:

    gcloud components update

  2. Ejecuta los siguientes comandos para verificar las versiones:

  • Para verificar la versión de los clústeres de usuario, haz lo siguiente:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Reemplaza PROJECT_ID. El ID del proyecto del proyecto host de la flota.

    Cuando configuras --location=-, significa que se enumeran todos los clústeres en todas las regiones. Si necesitas reducir el alcance de la lista, establece --location en la región que especificaste cuando inscribiste el clúster.

    El resultado del comando incluye la versión del clúster.

  • Para verificar la versión de los clústeres de administrador, haz lo siguiente:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Verifica la versión de los nodos del clúster:

Puedes usar kubectl para obtener la versión de los nodos del clúster, pero kubectl muestra la versión de Kubernetes. A fin de obtener la versión correspondiente de GKE en VMware para una versión de Kubernetes, consulta el Historial de versiones.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.

Comprueba si se deben rotar los certificados de la AC

Durante una actualización, se rotan los certificados de hoja, pero no los certificados de la AC. Debes rotar manualmente tus certificados de la AC al menos una vez cada cinco años. Para obtener más información, consulta Rota las autoridades certificadoras del clúster de usuario y Rota los certificados de la AC del clúster de administrador.

Diferencias entre los tipos de clústeres

Existen dos tipos diferentes de clústeres:

  • Clúster de usuario
  • Clúster de administrador

Según cómo crees un clúster de usuario, puede contener nodos trabajadores y nodos del plano de control (Plano de control V2) o solo nodos trabajadores (kubeception). Con kubeception, el plano de control de un clúster de usuario se ejecuta en uno o más nodos de un clúster de administrador. En ambos casos, a partir de la versión 1.14, puedes actualizar el plano de control de un clúster de usuario por separado de los grupos de nodos que ejecutan tus cargas de trabajo.

Efectos diferentes del clúster de usuario en comparación con las actualizaciones de los clústeres de administrador

El procedimiento de actualización de GKE en VMware implica un proceso de vaciado de nodos que quita todos los Pods de un nodo. El proceso crea una VM nueva para cada nodo trabajador desviado y la agrega al clúster. Luego, los nodos trabajadores vaciados se quitan del inventario de VMware. Durante este proceso, cualquier carga de trabajo que se ejecute en estos nodos se detiene y se reinicia en otros nodos disponibles en el clúster.

Según la arquitectura elegida para la carga de trabajo, este procedimiento puede tener un impacto en la disponibilidad de una aplicación. Para evitar una carga excesiva en las capacidades de los recursos del clúster, GKE en VMware actualiza un nodo a la vez.

Interrupción del clúster de usuario

En la siguiente tabla, se describe el impacto de una actualización in situ del clúster de usuario:

Función Clúster de administrador Clúster de usuario sin alta disponibilidad Clúster de usuario con alta disponibilidad
Acceso a la API de Kubernetes No afectado No afectado No afectado
Cargas de trabajo del usuario No afectado No afectado No afectado
PodDisruptionBudgets* No afectado No afectado No afectado
Nodo del plano de control No afectado Afectado No afectado
Escalador automático de Pods (VMware) No afectado No afectado No afectado
Reparación automática No afectado No afectado No afectado
Ajuste de escala automático de nodos (VMware) No afectado No afectado No afectado
Ajuste automático de escala horizontal de Pods Afectado Afectado No afectado
  • * : Los PDB pueden hacer que la actualización falle o se detenga.
  • Afectado: Una interrupción del servicio durante la actualización es notable hasta que esta finaliza.
  • No afectado: Puede ocurrir una interrupción del servicio durante un período muy breve, pero es casi imperceptible.

Los nodos del plano de control del clúster de usuario, ya sea que se ejecuten en el clúster de administrador (kubeception) o en el clúster de usuario en sí (el plano de control V2), no ejecutan ninguna carga de trabajo del usuario. Durante una actualización, estos nodos del plano de control se desvían y, luego, se actualizan según corresponda.

En entornos con planos de control de alta disponibilidad (HA), la actualización del plano de control de un clúster de usuario no interrumpe las cargas de trabajo del usuario. En un entorno de alta disponibilidad, la actualización de un clúster de administrador no interrumpe las cargas de trabajo del usuario. En el caso de los clústeres de usuario que usan Controlplane V2, la actualización solo del plano de control no interrumpe las cargas de trabajo del usuario.

Durante una actualización en un entorno de plano de control sin alta disponibilidad, el plano de control no puede controlar las acciones de escalamiento de Pods, recuperación o implementación. Durante la breve interrupción del plano de control durante la actualización, las cargas de trabajo del usuario pueden verse afectadas si se encuentran en un estado de escalamiento, implementación o recuperación. Esto significa que los lanzamientos fallarán durante una actualización en un entorno sin alta disponibilidad.

Para mejorar la disponibilidad y reducir la interrupción de los clústeres de usuario de producción durante las actualizaciones, te recomendamos que uses tres nodos del plano de control (modo de alta disponibilidad).

Interrupción del clúster de administrador

En la siguiente tabla, se describe el impacto de una actualización local del clúster de administrador:

Función Clúster de administrador Clúster de usuario sin alta disponibilidad Clúster de usuario con alta disponibilidad
Acceso a la API de Kubernetes Afectado Afectado No afectado
Cargas de trabajo del usuario No afectado No afectado No afectado
Nodo del plano de control Afectado Afectado No afectado
Escalador automático de Pods Afectado Afectado No afectado
Reparación automática Afectado Afectado No afectado
Ajuste de escala automático de nodos Afectado Afectado No afectado
Ajuste automático de escala horizontal de Pods Afectado Afectado No afectado
  • Afectado: Una interrupción del servicio durante la actualización es notable hasta que esta finaliza.
  • No afectado: Puede ocurrir una interrupción del servicio durante un período muy breve, pero es casi imperceptible.

¿Qué sigue?