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
Te recomendamos que sigas todas las prácticas recomendadas de 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 que se completen 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 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
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 una actualización del clúster de forma correcta, debes usar un período de mantenimiento con tiempo suficiente.
Si quieres 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 de actualización total sería de alrededor de quinientos minutos: 10 minutes * 50 nodes = 500 minutes.
Verifica la compatibilidad de otros componentes de GKE Enterprise
Si tu clúster ejecuta componentes de GKE Enterprise, como Cloud Service Mesh, el Sincronizador de configuración, Policy Controller o Config Controller, consulta la compatibilidad con la versión y la actualización de GKE Enterprise 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 Cloud Service Mesh, el Sincronizador de configuración, Policy Controller o el Controlador de configuración.
Verifica el uso de recursos del clúster
Para asegurarte de que los Pods puedan limpiarse cuando el nodo se desvíe y que haya suficientes recursos en el clúster que se están actualizando para administrar la actualización, verifica el uso actual de los recursos del clúster. Para verificar el uso de recursos de tu clúster, usa los paneles personalizados en Google Cloud Observability.
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 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 disponibles 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.
Recursos del plano de control del clúster de administrador
Todos los controladores y trabajos 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 los recursos de procesamiento disponibles. El proceso de actualización suele requerir 1,000 milicores de CPU (1,000 mCPU) y de 2 a 3 GiB de RAM para cada conjunto de controladores del ciclo de vida. Ten en cuenta que la unidad de CPU “mCPU” significa “milésima de un núcleo”, por lo que 1,000 milicores es el equivalente a un núcleo en cada nodo para cada conjunto de controladores del ciclo de vida. Para reducir los recursos de procesamiento adicionales necesarios 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 están 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 |
Se implementa un conjunto de controladores de ciclo de vida en el controlador de administrador 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 del ciclo de vida consume un total de 1,000 mCPU y 3 GiB de RAM. El consumo total de recursos actual de estos controladores del 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 de 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 del 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 ejecuta 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 hay solo 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 de 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 de 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 actualicen 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 de ciclo de vida en uso. Si tu actualización ya está bloqueada, también puedes usar kubectl edit deployment para editar las implementaciones pendientes a fin de reducir las solicitudes de CPU y RAM para que se ajusten al plano de control del clúster de administrador.
En la siguiente tabla, se detallan los requisitos de recursos de procesamiento para diferentes situaciones de actualización:
| Clúster | Recursos del clúster de administrador necesarios |
|---|---|
| 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 en 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 de clústeres híbridos (sin clúster de usuario) | Aumento de 1,000 mCPU y 3 GiB de RAM. Los recursos se muestran después del uso. |
| Independiente | Aumento de 200 mCPU y 1 GiB de RAM. Los recursos se muestran después del uso. |
Crear copias de seguridad de los clústeres
Antes de comenzar una actualización, crea una copia de seguridad de los clústeres con el comando bmctl backup cluster.
Debido a que el archivo de copia de seguridad contiene información sensible, almacénalo de forma segura.
Verifica que los clústeres estén configurados y funcionen de forma correcta
Para verificar el estado de un clúster antes de una actualización, ejecuta bmctl check cluster en el clúster. 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.
Cuando ejecutas el comando bmctl upgrade cluster para actualizar los clústeres, se ejecutan algunas comprobaciones previas. El proceso de actualización se detiene si estas verificaciones no se realizan de forma correcta. Es mejor identificar y solucionar de forma proactiva estos problemas con el comando bmctl check cluster, en lugar de depender de las comprobaciones previas que existen para proteger los clústeres de cualquier daño posible.
Revisa las implementaciones de cargas de trabajo de los usuarios
Hay dos áreas que debes tener en cuenta para las cargas de trabajo de los usuarios: el vaciado 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 puede 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 nodos simultáneos.
Para evitar una actualización detenida, el proceso de desvío de la actualización a 1.30 no respeta los presupuestos de interrupción del Pod (PDB). Las cargas de trabajo podrían ejecutarse en un estado degradado y la réplica con menos entregas sería total
replica number - concurrent upgrade number.
Compatibilidad de API
Para la compatibilidad de API, verifica la compatibilidad de la API de 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 cargas de trabajo mediante APIs incompatibles, como las APIs de Kubernetes que se quitaron.
Si usas Cloud Service Mesh, el Sincronizador de configuración, Policy Controller, el Controlador de configuración o cualquier otro componente de GKE Enterprise, verifica si la versión instalada es compatible con la nueva versión de Google Distributed Cloud. Para obtener información sobre la compatibilidad de la versión del componente GKE Enterprise, consulta Compatibilidad con versiones y actualizaciones 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 Policy Controller. El proceso de desvío durante la actualización del clúster puede interrumpir el servicio de webhook de Policy Controller, lo que puede hacer que la actualización se detenga o tome mucho tiempo. Te recomendamos inhabilitar de forma temporal estos webhooks o usar 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 funciones de versión preliminar en tus clústeres de producción. No garantizamos que los clústeres que usan características de vista previa 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.
Comprueba 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 de clústeres. 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 es compatible con SELinux solo en sistemas RHEL.
No cambies la configuración de la densidad del Pod
Google Distributed Cloud admite la configuración de hasta 250 Pods máximos 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 del Pod 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 el plano de control y los grupos de nodos del balanceador de cargas tengan suficiente disponibilidad.
¿Qué sigue?
- Actualiza Google Distributed Cloud
- Obtén más información sobre el ciclo de vida y las etapas de las actualizaciones.
- Soluciona problemas de actualización de clústeres