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

Te sugerimos que sigas todas las prácticas recomendadas incluidas en este documento. Usa la siguiente lista de tareas para hacer un seguimiento de tu progreso. Cada elemento de la lista se vincula a una sección de este documento con más información:

Una vez completadas estas verificaciones, puedes comenzar el proceso de actualización. Supervisa el progreso hasta que todos los clústeres se actualicen de forma correcta.

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

El tiempo que lleva actualizar un clúster varía según la cantidad de nodos y la densidad de la carga de trabajo que se ejecuta en ellos. Para completar de forma correcta la actualización de un clúster, usa un período de mantenimiento con tiempo suficiente.

Para calcular una estimación aproximada de la actualización, usa 10 minutes * the number of nodes para la actualización de un solo nodo simultáneo.

Por ejemplo, si tienes cincuenta nodos en un clúster, el tiempo total de actualización sería de unos quinientos minutos: 10 minutes * 50 nodes = 500 minutes.

Verifica la compatibilidad de otros componentes de GKE Enterprise

Si el clúster ejecuta componentes de GKE Enterprise, como Anthos Service Mesh, Sincronizador de configuración, Controlador de políticas o el controlador de configuración, consulta la versión de GKE Enterprise y la compatibilidad con la actualización y verifica las versiones compatibles con Google Distributed Cloud antes y después de la actualización.

La verificación de compatibilidad se basa en el clúster de administrador o de usuario en el que se implementa Anthos Service Mesh, el Sincronizador de configuración, el controlador de políticas o el controlador de configuración.

Verifica el uso de recursos del clúster

Verifica el uso actual de recursos del clúster para asegurarte de que los Pods se puedan evacuar cuando se desvíe 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 de recursos de tu clúster, usa los paneles personalizados en la observabilidad de Google Cloud.

Puedes usar comandos, como kubectl top nodes, para obtener el uso actual de los recursos del clúster, pero 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, aún es importante verificar los recursos disponibles antes de comenzar la 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.

Recursos del plano de control del clúster de administrador

Todos los trabajos y controladores de actualización se ejecutan en los nodos del plano de control del clúster de administrador. Verifica el consumo de recursos de estos nodos del plano de control para conocer los recursos de procesamiento disponibles. Por lo general, el proceso de actualización requiere 1,000 millicores de CPU (1,000 mCPU) y entre 2 y 3 GiB de RAM para cada conjunto de controladores de ciclo de vida. Ten en cuenta que la unidad de CPU "mCPU" significa "milésima de un núcleo" y, por lo tanto, 1,000 millicores son el equivalente de un núcleo en cada nodo para cada conjunto de controladores del ciclo de vida. Para reducir los recursos de procesamiento adicionales requeridos durante una actualización, intenta mantener los clústeres de usuario en la misma versión.

En la siguiente implementación de ejemplo, los dos clústeres de usuario se encuentran en versiones diferentes a las del clúster de administrador:

Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
1.13.3 1.13.0 1.13.2

En el controlador de administrador, se implementa un conjunto de controladores de ciclo de vida para cada versión en uso. En este ejemplo, hay tres conjuntos de controladores de ciclo de vida: 1.13.3, 1.13.0 y 1.13.2. Cada conjunto de controladores de ciclo de vida consume un total de 1,000 mCPU y 3 GiB de RAM. El consumo total actual de recursos de estos controladores de ciclo de vida es de 3,000 mCPU y 9 GiB de RAM.

Si el clúster de usuario 2 se actualiza a 1.13.3, ahora hay dos conjuntos de controladores del ciclo de vida: 1.13.3 y 1.13.0:

Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
1.13.3 1.13.0 1.13.3

Los controladores de ciclo de vida ahora consumen un total de 2,000 mCPU y 6 GiB de RAM.

Si el clúster de usuario 1 se actualiza a 1.13.3, la flota ahora se ejecutará en la misma versión: 1.13.3:

Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
1.13.3 1.13.3 1.13.3

Ahora solo hay un conjunto de controladores de ciclo de vida que consume un total de 1, 000 mCPU y 3 GiB de RAM.

En el siguiente ejemplo, todos los clústeres de usuario tienen la misma versión. Si se actualiza el clúster de administrador, solo se usan dos conjuntos de controladores del ciclo de vida, por lo que se reduce el consumo de recursos de procesamiento:

Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
1.14.0 1.13.3 1.13.3

En este ejemplo, los controladores del ciclo de vida vuelven a consumir un total de 2,000 mCPU y 6 GiB de RAM hasta que todos los clústeres de usuario se actualizan a la misma versión que el clúster de administrador.

Si los nodos del plano de control no tienen recursos de procesamiento adicionales durante la actualización, es posible que veas Pods como anthos-cluster-operator, capi-controller-manager, cap-controller-manager o cap-kubeadm-bootstraper en un estado Pending. Para resolver este problema, actualiza algunos de los clústeres de usuario a la misma versión a fin de consolidar las versiones y reducir la cantidad de controladores del ciclo de vida en uso. Si tu actualización ya está bloqueada, también puedes usar kubectl edit deployment para editar las implementaciones pendientes y, así, reducir las solicitudes de CPU y RAM, de modo que se ajusten al plano de control del clúster de administrador.

En la siguiente tabla, se detallan los requisitos de los recursos de procesamiento para diferentes situaciones de actualización:

Clúster Los recursos del clúster de administrador son obligatorios
Actualización del clúster de usuario Actualiza a la misma versión de otros clústeres: N/A

Actualiza a una versión diferente de otros clústeres de administrador o de usuario: 1,000 mCPU y 3 GiB de RAM

Los clústeres de usuario de un clúster híbrido tienen los mismos requisitos de recursos.
Actualización del clúster de administrador (con clúster de usuario) 1,000 mCPU y 3 GiB de RAM
Actualización del clúster híbrido (sin clúster de usuario) Aumento de 1,000 mCPU y 3 GiB de RAM. Los recursos se muestran después de su uso.
Independiente Aumento de 200 mCPU y 1 GiB de RAM. Los recursos se muestran después de su uso.

Crear copias de seguridad de los clústeres

Antes de iniciar una actualización, crea una copia de seguridad de los clústeres con el comando bmctl backup cluster.

Almacena el archivo de copia de seguridad de forma segura, ya que contiene información sensible.

Verifica que los clústeres estén configurados y funcionen correctamente

Para verificar el estado de un clúster antes de una actualización, ejecuta bmctl check cluster en él. 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.

Cuando ejecutas el comando bmctl upgrade cluster para actualizar los clústeres, se ejecutan algunas verificaciones previas. El proceso de actualización se detiene si estas verificaciones no se realizan de forma correcta. Es mejor identificar y solucionar estos problemas de forma proactiva con el comando bmctl check cluster, en lugar de depender de las comprobaciones preliminares, que están allí para proteger los clústeres de cualquier posible daño.

Revisa las implementaciones de carga de trabajo del usuario

Hay dos áreas que se deben tener en cuenta para las cargas de trabajo de los usuarios: el desvío y la compatibilidad de la API.

Vaciado de cargas de trabajo

La carga de trabajo del usuario en un nodo se vacía durante una actualización. Si la carga de trabajo tiene una sola réplica o todas las réplicas están en el mismo nodo, el vaciado de la carga de trabajo podría causar interrupciones en los servicios que se ejecutan en el clúster. Ejecuta tus cargas de trabajo con varias réplicas. El número de réplica debe ser superior al número de nodo simultáneo.

Para evitar una actualización detenida, el proceso de vaciado de la actualización hasta 1.29 no respeta los presupuestos de interrupción de Pods (PDB). Las cargas de trabajo pueden ejecutarse en un estado degradado y la réplica menos entregada sería total replica number - concurrent upgrade number.

Compatibilidad de API

Para la compatibilidad de la API, verifica la compatibilidad de la API de la carga de trabajo con la versión secundaria más reciente de Kubernetes cuando realices una actualización de versión secundaria. Si es necesario, actualiza la carga de trabajo a una versión compatible. Cuando sea posible, el equipo de ingeniería de GKE Enterprise proporciona instrucciones para identificar las cargas de trabajo mediante APIs incompatibles, como las APIs de Kubernetes quitadas.

Si usas Anthos Service Mesh, el Sincronizador de configuración, el Controlador de políticas, el controlador de configuración o algún otro componente de GKE Enterprise, verifica si la versión instalada es compatible con la versión nueva de Google Distributed Cloud. Para obtener información sobre la compatibilidad de la versión de los componentes de GKE Enterprise, consulta Asistencia para la versión y la actualización de GKE Enterprise.

Audita el uso de webhooks

Verifica si tu clúster tiene webhooks, en especial, recursos de Pods para fines de auditoría, como el controlador de políticas. El proceso de vaciado durante la actualización del clúster puede interrumpir el servicio de webhook del controlador de políticas, lo que puede hacer que la actualización se detenga o tarde mucho tiempo. Te recomendamos que inhabilites estos webhooks de manera temporal o que uses una implementación con alta disponibilidad (HA).

Revisa el uso de las funciones de versión preliminar

Las funciones de vista previa están sujetas a cambios y se proporcionan solo con fines de prueba y evaluación. No uses las funciones de versión preliminar en tus clústeres de producción. No garantizamos que los clústeres que usan funciones de versión preliminar se puedan actualizar. En algunos casos, bloqueamos de forma explícita las actualizaciones para los clústeres que usan las funciones de vista previa.

Para obtener información sobre los cambios rotundos relacionados con las actualizaciones, consulta las notas de la versión.

Cómo comprobar el estado de SELinux

Si deseas habilitar SELinux para proteger tus contenedores, debes asegurarte de que SELinux esté habilitado en el modo Enforced en todas tus máquinas anfitrión. A partir de la versión 1.9.0 o posterior de Google Distributed Cloud, puedes habilitar o inhabilitar SELinux antes o después de la creación o actualización del clúster. SELinux está habilitado de forma predeterminada en Red Hat Enterprise Linux (RHEL). Si SELinux está inhabilitado en tus máquinas anfitrión o no estás seguro, consulta Protege tus contenedores con SELinux a fin de obtener instrucciones para habilitarlo.

Google Distributed Cloud admite SELinux solo en los sistemas RHEL.

No cambies la configuración de la densidad del Pod

Google Distributed Cloud admite la configuración de hasta 250 Pods como máximo por nodo con nodeConfig.PodDensity.MaxPodsPerNode. Solo puedes configurar la densidad del pod durante la creación del clúster. No puedes actualizar la configuración de la densidad del pod para los clústeres existentes. No intentes cambiar la configuración de la densidad de Pods durante una actualización.

Asegúrate de que el plano de control y los nodos del balanceador de cargas no estén en modo de mantenimiento

Asegúrate de que el plano de control y los nodos del balanceador de cargas no estén en mantenimiento antes de iniciar una actualización. Si algún nodo está en modo de mantenimiento, la actualización se detiene para garantizar que los grupos de nodos del plano de control y del balanceador de cargas estén lo suficientemente disponibles.

¿Qué sigue?