Prácticas recomendadas para las actualizaciones de clústeres de Google Distributed Cloud

En este documento, se describen las prácticas recomendadas y las consideraciones para actualizar Google Distributed Cloud. Aprenderás a prepararte para las actualizaciones de clústeres y a 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 clústeres.

Si tienes varios entornos, por ejemplo, de prueba, desarrollo y producción, te recomendamos que comiences con el entorno menos crítico, como el de prueba, y 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 tus 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 perjudiciales. Antes de comenzar la actualización, planifica con cuidado para asegurarte de que el entorno y las aplicaciones estén listos y en preparación.

Calcula 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 manera 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. Si quieres calcular una estimación aproximada del tiempo de actualización, usa 15 minutos x 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 de actualización total sería de unos 150 minutos.

En la versión 1.28 y en las posteriores, puedes acelerar una actualización; para ello, configura el valor de maxSurge para los grupos de nodos individuales.

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

Antes de comenzar una 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. En el depósito de etcd, están todos los objetos de Kubernetes y los objetos personalizados necesarios para administrar el estado del clúster. En esta instantánea, están 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 la versión 1.8 y posteriores de Google Distributed Cloud, puedes configurar la 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 automáticamente 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 una actualización del clúster, se ejecuta una tarea de copia de seguridad antes de actualizar el clúster.

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

Revisa el uso de PodDisruptionBudgets

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

  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 llamados 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 siempre debe estar disponible. Esta disponibilidad se vuelve fundamental durante las actualizaciones cuando se vacían los nodos.

Verifica si hay PDB que no se pueden completar. Por ejemplo, puedes establecer una disponibilidad mínima de 1, cuando el objeto Deployment solo presenta 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 en un clúster determinado antes de comenzar la actualización. Es posible que debas coordinar con los equipos de desarrollo y los propietarios de aplicaciones para cambiar o inhabilitar de forma temporal los PDB durante una actualización del clúster.

Google Distributed Cloud ejecuta una comprobación preliminar durante el proceso de actualización para advertir sobre los PDB. Sin embargo, también debes verificar los PDB de forma manual para garantizar una experiencia de actualización fluida. Si deseas obtener más información sobre los PDB, consulta Especifica un presupuesto de interrupción para tu aplicación.

Revisa las direcciones IP disponibles

Se aplican las siguientes consideraciones sobre las direcciones IP durante las actualizaciones de clústeres:

  • El proceso de actualización del clúster crea un nodo nuevo y vacía los recursos antes de borrar el nodo anterior. Te recomendamos que siempre tengas N+1 direcciones IP para el clúster de administrador o de usuario, en el que N es la cantidad de nodos en el clúster.
  • Cuando usas direcciones IP estáticas, las direcciones IP requeridas deben enumerarse en los archivos de bloque de IP.
  • Si usas DHCP, asegúrate de que las VMs nuevas puedan obtener asignaciones de tiempo 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 tus 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 de tu 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 una sola VM a la vez, incluso cuando se usan varios grupos de nodos.

Verifica el uso del clúster

Asegúrate de que los Pods puedan limpiarse cuando el nodo se vacíe 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 Google Cloud Observability 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 del recurso pueden ayudar a indicar cuándo una actualización causaría la menor interrupción, como los fines de semana o las noches, según la carga de trabajo en ejecución y los casos de uso.

El momento de la actualización del clúster de administrador puede ser menos crítico que para los clústeres de usuario, ya que una actualización del clúster de administrador no suele generar tiempo de inactividad de la aplicación. Sin embargo, es importante verificar si hay 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 cierto riesgo y, por lo tanto, se puede recomendar 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 una actualización del clúster.

Comprueba el uso de vSphere

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

En la pestaña Resumen, se muestra el consumo general de la memoria, la CPU y el almacenamiento de todo el clúster. Debido a que las actualizaciones de Google Distributed Cloud exigen 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 poder admitir los siguientes recursos adicionales:

  • +1 VM por actualización del 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 grupo tiene nodos que usan 8 CPU virtuales y 32 GB de RAM o más. Debido a que la actualización ocurre 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 VMs desde una plantilla puede generar estrés en el sistema de almacenamiento subyacente en forma de un aumento de las operaciones de E/S. La actualización puede ralentizarse considerablemente 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, recomendamos no hacer un exceso de compromiso de memoria de la VM. El exceso de compromiso de memoria puede generar un impacto grave en el rendimiento que afecte a todo el clúster, ya que vSphere proporciona la “RAM faltante” a partir del intercambio de páginas con el almacén de datos. Este comportamiento puede generar problemas durante una actualización de un clúster y causar un impacto en el rendimiento de otras VMs en ejecución en el clúster de vSphere.

Si los recursos disponibles ya son escasos, apaga las VMs 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 nodos que no están configurados de forma correcta o que tienen Pods que están en estado atascado. Si el comando gkectl diagnose muestra una advertencia Cluster unhealthy, soluciona los problemas antes de intentar una actualización. Para obtener más información, consulta Diagnostica problemas de clústeres.

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

Además, cuando actualices clústeres de usuario a 1.29 y versiones posteriores, te recomendamos que ejecutes el comando gkectl upgrade cluster con la marca --dry-run. La marca --dry-run ejecuta comprobaciones preliminares, pero no inicia el proceso de actualización. Aunque las versiones anteriores de Google Distributed Cloud ejecutan comprobaciones preliminares, no se pueden ejecutar por separado de la actualización. Cuando agregas la marca --dry-run, puedes detectar y corregir cualquier problema que las comprobaciones preliminares encuentren en tu clúster de usuario antes de la actualización.

Usa Deployments para minimizar las interrupciones de las aplicaciones

Como los nodos se deben vaciar durante las actualizaciones, las actualizaciones de los clústeres pueden provocar interrupciones de las aplicaciones. Vaciar los nodos significa que todos los Pods en ejecución deben apagarse 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 manejar interrupciones. Cualquier impacto debe ser mínimo para los Deployments que tienen varias réplicas. Aún puedes actualizar tu clúster si las aplicaciones no usan Deployments.

También hay reglas para los Deployments que garantizan que una cantidad determinada 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 se deben reprogramar por algún motivo, como actualizaciones o mantenimiento en los nodos del clúster, y es importante verificarlos antes de realizar una actualización.

Usa un par de balanceador de cargas de alta disponibilidad

Si usas Seesaw como un 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 falla eventual del balanceador de cargas, puedes usar un par de alta disponibilidad (par de HA). En esta configuración, el sistema crea y configura dos VMs del balanceador de cargas para que pueda realizarse una conmutación por error al otro par.

Para aumentar la disponibilidad del servicio (es decir, para el servidor de la API de Kubernetes), te recomendamos que siempre uses un par de HA frente al clúster de administrador. Para obtener más información acerca de 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 VM nueva del balanceador de cargas. Si un clúster de usuario solo usa una instancia única 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 de HA si el clúster de usuario 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 de HA.

Si usas MetalLB como un balanceador de cargas en paquetes, no se requiere 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 en las 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 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. Para obtener información sobre por qué es posible que quieras 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 de 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 en el clúster de usuario y los clústeres de administrador.

  1. Asegúrate de tener la última versión de gcloud CLI. Actualiza los componentes de gcloud CLI, si es necesario:

    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 host de tu flota.

    Cuando configuras --location=-, significa que se deben enumerar todos los clústeres en todas las regiones. Si necesitas reducir el alcance de la lista, configura --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. Para obtener la versión de Google Distributed Cloud correspondiente para una versión de Kubernetes, consulta Control 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.

Verifica 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

Hay 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 (Controlplane V2) o solo nodos trabajadores (kubeception). Con kubeception, el plano de control para un clúster de usuario se ejecuta en uno o más nodos en un clúster de administrador. En ambos casos, en la versión 1.14 y en las posteriores, 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.

Diferentes efectos de las actualizaciones del clúster de usuario en comparación con las actualizaciones del clúster de administrador

El procedimiento de actualización de Google Distributed Cloud 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 vaciado y la agrega al clúster. Los nodos trabajadores vaciados se quitan del inventario de VMware. Durante este proceso, se detiene cualquier carga de trabajo que se ejecuta en estos nodos y se reinicia en otros nodos disponibles del clúster.

Según la arquitectura elegida de la carga de trabajo, este procedimiento puede tener un impacto en la disponibilidad de una aplicación. Para evitar una sobrecarga en las capacidades de los recursos del clúster, Google Distributed Cloud 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 de usuarios 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 Pod (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 de escala automático horizontal de pod 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 se nota hasta que finaliza la actualización.
  • No afectado: Una interrupción del servicio puede ocurrir durante un período muy corto, 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 el clúster de usuario en sí (Controlplane V2), no ejecutan ninguna carga de trabajo de usuario. Durante una actualización, estos nodos del plano de control se vací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 de usuarios. En un entorno de alta disponibilidad, la actualización de un clúster de administrador no interrumpe las cargas de trabajo de usuarios. Para los clústeres de usuario que usan Controlplane V2, actualizar solo el plano de control no interrumpe las cargas de trabajo de usuarios.

Durante una actualización en un entorno de plano de control que no tiene alta disponibilidad, el plano de control no puede controlar las acciones de escalamiento, recuperación ni implementación de Pods. Durante la interrupción breve del plano de control durante la actualización, las cargas de trabajo de usuarios pueden verse afectadas si se encuentran en 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 usar 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 in situ 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 de usuarios No afectado No afectado No afectado
Nodo del plano de control Afectado Afectado No afectado
Escalador automático de Pods Afectado Afectado No afectado
Taller de automóviles Afectado Afectado No afectado
Ajuste de escala automático de nodos Afectado Afectado No afectado
Ajuste de escala automático horizontal de pod Afectado Afectado No afectado
  • Afectado: Una interrupción del servicio durante la actualización se nota hasta que finaliza la actualización.
  • No afectado: Una interrupción del servicio puede ocurrir durante un período muy corto, pero es casi imperceptible.

¿Qué sigue?