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 los clústeres y a conocer las prácticas recomendadas 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 comenzar con el entorno menos crítico, como prueba, y verificar la funcionalidad de actualización. Después de verificar que la actualización se realizó de forma correcta, pasa al 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 las cargas de trabajo se ejecuten de forma correcta.
Lista de tareas de la 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 disruptivas. Antes de comenzar la actualización, planifica con cuidado para asegurarte de que el entorno y las aplicaciones estén listos y preparados.
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 posteriores, puedes acelerar una actualización si configuras el valor de maxSurge para grupos de nodos individuales.
Crea una copia de seguridad del clúster de usuario y administrador
Antes de comenzar una actualización, crea una copia de seguridad de los clústeres de usuario y 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 la versión 1.8 de Google Distributed Cloud y las versiones 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 y agrega el campo clusterBackup.datastore. 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 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 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 pueden fallar. Este comportamiento es una forma útil de proporcionar la disponibilidad de la aplicación.
Para verificar qué PDB están configurados en tu clúster, usa el comando
kubectl get pdb:kubectl get pdb -A --kubeconfig KUBECONFIGReemplaza
KUBECONFIGpor el nombre de tu archivo kubeconfig.En el siguiente resultado de ejemplo, se muestran los PDB llamados
istio-ingress,istiodykube-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 es crítica durante las actualizaciones cuando se agotan los nodos.
Verifica si hay PDB que no se puedan completar. Por ejemplo, puedes establecer una disponibilidad mínima de 1, cuando la Deployment solo presenta 1 réplica. En este ejemplo, la operación de desvío 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 comenzar 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.
Google Distributed Cloud ejecuta una comprobación preliminar durante el proceso de actualización para advertir sobre las PDB. Sin embargo, también debes verificar manualmente las PDB para garantizar una experiencia de actualización fluida. 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 sobre la dirección IP se aplican durante las actualizaciones de los clústeres:
- El proceso de actualización del clúster crea un nodo nuevo y agota los recursos antes de borrar el antiguo. 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 estar enumeradas 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 tus direcciones IP.
- Si necesitas agregar direcciones IP, actualiza el archivo de bloque de IP y, luego, ejecuta el comando
- 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 bloqueo 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 se puedan evacuar cuando se vacía el nodo y de 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 mediante 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 momento de la 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 de la aplicación. Sin embargo, es importante verificar los recursos gratuitos en vSphere antes de comenzar una actualización del clúster de administrador. Además, actualizar el clúster de administrador puede implicar cierto riesgo y, por lo tanto, podría recomendarse 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 del clúster.
Verifica el uso de vSphere
Verifica que haya recursos suficientes en la infraestructura subyacente de vSphere. Para verificar este uso de recursos, selecciona un clúster en vCenter y revisa la pestaña Summary.
En la pestaña de resumen, se muestra la memoria general, la CPU y el consumo de almacenamiento de todo el clúster. Debido a que las actualizaciones de Google Distributed Cloud requieren recursos adicionales, también debes verificar si el clúster puede manejar estas solicitudes de recursos adicionales.
Como regla general, tu clúster de vSphere debe ser capaz de admitir los siguientes recursos adicionales:
- Más de 1 VM por actualización de clúster de administrador
- Más de 1 VM por grupo de nodos por actualización de clúster de usuario
Por ejemplo, supongamos que un clúster de usuario tiene 3 grupos de nodos y 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 VM mediante la operación de clonación de vSphere. La clonación de varias VM a partir de una plantilla puede generar estrés en el sistema de almacenamiento subyacente en forma de operaciones de E/S en aumento. La actualización puede ralentizarse 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 proporcionarlos, incluso cuando hay exceso de compromiso, te recomendamos no sobrecargar la memoria de la VM. El exceso de compromiso de memoria puede generar graves impactos en el rendimiento que afectan a todo el clúster, ya que vSphere proporciona la "RAM faltante" del intercambio de páginas al 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 cumplir con 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, como para identificar nodos que no están configurados de forma correcta o que tienen Pods que están en estado detenido. Si el comandogkectl diagnosemuestra una advertenciaCluster unhealthy, soluciona los problemas antes de intentar una actualización. Para obtener más información, consulta Diagnostica problemas de clústeres.Herramienta previa a la actualización: Además de verificar el estado y la configuración del clúster, la herramienta comprueba si hay posibles problemas conocidos que podrían ocurrir durante la actualización del clúster.
Además, cuando actualices clústeres de usuario a la versión 1.29 y posteriores, te recomendamos que ejecutes el comando gkectl upgrade cluster con la marca --dry-run. La marca --dry-run ejecuta verificaciones previas, 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. Si agregas la marca --dry-run, puedes encontrar y solucionar cualquier problema
que las comprobaciones preliminares encuentren con el clúster de usuario antes de la actualización.
Usa objetos Deployment para minimizar la interrupción de la aplicación
Dado que es necesario vaciar los nodos durante las actualizaciones, las actualizaciones de los clústeres pueden provocar interrupciones en la aplicación. 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 Deployments. Con este enfoque, las aplicaciones están diseñadas para manejar las interrupciones. Cualquier impacto debe ser mínimo en los Deployments que tienen varias réplicas. Aun así, puedes actualizar el clúster si las aplicaciones no usan Deployments.
También hay reglas para que los Deployments se aseguren de que una cantidad determinada de réplicas se siga ejecutando siempre. 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 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 la 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 VM del balanceador de cargas para que pueda ocurrir 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 la 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 única de balanceador de cargas, se produce una interrupción del servicio hasta que se completa 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 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.
Si usas MetalLB como un balanceador de cargas en paquetes, no se requiere ninguna 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 actualizar un clúster de usuario completo (es decir, puedes actualizar el plano de control y todos los grupos de nodos del clúster) o 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é te recomendamos 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_KUBECONFIGpor 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
En el caso de los clústeres 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.
Asegúrate de tener la versión más reciente de gcloud CLI. Actualiza los componentes de gcloud CLI si es necesario:
gcloud components updateEjecuta 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 de proyecto host de 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--locationen 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 a 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 tus certificados de la AC de forma manual 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, es posible que contenga nodos trabajadores y nodos del plano de control (Controlplane 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, en la versión 1.14 y en las versiones 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 desvío de nodos que quita todos los Pods de un nodo. El proceso crea una VM nueva para cada nodo trabajador desviado y lo 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 reinicia en otros nodos disponibles del 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 un gran esfuerzo en las habilidades de recursos del clúster, Google Distributed Cloud actualiza un nodo a la vez.
Interrupción de clústeres de usuario
En la siguiente tabla, se describe el impacto de una actualización del clúster de usuario in situ:
| 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 provocar que la actualización falle o se detenga.
- Afectado: es evidente una interrupción del servicio durante la actualización hasta que esta finaliza.
- No afectada: Es posible que ocurra una interrupción del servicio durante un período muy breve, pero 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í (Controlplane V2), no ejecutan ninguna carga de trabajo de 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. Para los clústeres de usuario que usan Controlplane V2, actualizar solo el plano de control no interrumpe las cargas de trabajo del usuario.
Durante una actualización en un entorno de plano de control que no tiene alta disponibilidad, el plano de control no puede controlar el escalamiento de Pods, la recuperación o las acciones de 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 están 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, 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 del clúster de administrador in situ:
| 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: es evidente una interrupción del servicio durante la actualización hasta que esta finaliza.
- No afectada: Es posible que ocurra una interrupción del servicio durante un período muy breve, pero casi imperceptible.