En este documento se describen las prácticas recomendadas y los aspectos que se deben tener en cuenta para actualizar Google Distributed Cloud. Aprenderás a prepararte para las actualizaciones de clústeres y las prácticas recomendadas que debes seguir antes de la actualización. Estas prácticas recomendadas ayudan a reducir los riesgos asociados a las actualizaciones de clústeres.
Si tienes varios entornos, como pruebas, desarrollo y producción, te recomendamos que empieces por el menos crítico, como pruebas, y que verifiques la funcionalidad de la actualización. Después de verificar que la actualización se ha realizado correctamente, pasa al siguiente entorno. Repite este proceso hasta que actualices tus entornos de producción. Este enfoque te permite pasar de un punto crítico a otro y verificar que la actualización y tus cargas de trabajo se ejecutan correctamente.
Lista de comprobación de la actualización
Te recomendamos que sigas todas las prácticas recomendadas de este documento. Usa la siguiente lista de comprobación para hacer un seguimiento de tu progreso. Cada elemento de la lista enlaza con una sección de este documento que contiene más información:
Una vez que se hayan completado estas comprobaciones, podrás iniciar el proceso de actualización. Supervisa el progreso hasta que todos los clústeres se hayan actualizado correctamente.
Planificar la actualización
Las actualizaciones pueden ser molestas. Antes de iniciar la actualización, planifica cuidadosamente el proceso para asegurarte de que tu entorno y tus aplicaciones estén listos.
Estimar el tiempo necesario y planificar una ventana de mantenimiento
El tiempo que se tarda en actualizar un clúster varía en función del número de nodos y de la densidad de la carga de trabajo que se ejecute en ellos. Para completar correctamente una actualización de clúster, utiliza una ventana 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.
Comprobar la compatibilidad de otros Google Cloud productos
Si tu clúster ejecuta Cloud Service Mesh, Config Sync o Policy Controller, consulta la sección Compatibilidad con versiones y actualizaciones y verifica las versiones compatibles con Google Distributed Cloud antes y después de la actualización.
La comprobación de compatibilidad se basa en el clúster de administrador o de usuario en el que se implementa Cloud Service Mesh, Config Sync o Policy Controller.
Comprobar la utilización de recursos del clúster
Para asegurarte de que los pods se puedan evacuar cuando se agote el nodo y de que haya suficientes recursos en el clúster que se va a actualizar para gestionar la actualización, comprueba el uso de recursos actual del clúster. Para comprobar el uso de recursos de tu clúster, usa los paneles de control personalizados de Google Cloud Observability.
Puedes usar comandos, como kubectl top nodes, para obtener el uso actual de los recursos del clúster, pero los paneles de control pueden proporcionar una vista más detallada de los recursos que se consumen a lo largo del tiempo. Estos datos de uso de recursos pueden ayudar a indicar cuándo una actualización causaría las menores interrupciones, por ejemplo, durante los fines de semana o por las noches, en función de la carga de trabajo y los casos de uso.
El momento de la actualización del clúster de administradores puede ser menos importante que el de los clústeres de usuarios, ya que la actualización de un clúster de administradores no suele provocar tiempos de inactividad de las aplicaciones. Sin embargo, sigue siendo importante comprobar si hay recursos disponibles antes de empezar a actualizar un clúster de administrador. Además, actualizar el clúster de administrador puede conllevar algún riesgo, por lo que se recomienda hacerlo durante los periodos de uso menos activos, cuando el acceso de gestión al clúster sea 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. Comprueba el consumo de recursos de estos nodos del plano de control para ver los recursos de computación disponibles. El proceso de actualización suele requerir 1000 milinúcleos de CPU (1000 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", por lo que 1000 milinúcleos equivalen a un núcleo en cada nodo por cada conjunto de controladores de ciclo de vida. Para reducir los recursos de computación adicionales que se necesitan 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 usuarios tienen versiones diferentes a la del clúster de administrador:
| Clúster de administradores | Clúster de usuarios 1 | Clúster de usuarios 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 de ciclo de vida consume un total de 1000 mCPU y 3 GiB de RAM. El consumo total de recursos actual de estos controladores de ciclo de vida es de 3000 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 administradores | Clúster de usuarios 1 | Clúster de usuarios 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.3 |
Los controladores de ciclo de vida ahora consumen un total de 2000 mCPU y 6 GiB de RAM.
Si el clúster de usuario 1 se actualiza a 1.13.3, toda la flota tendrá la misma versión: 1.13.3:
| Clúster de administradores | Clúster de usuarios 1 | Clúster de usuarios 2 |
|---|---|---|
| 1.13.3 | 1.13.3 | 1.13.3 |
Ahora solo hay un conjunto de controladores de ciclo de vida, que consumen un total de 1000 mCPUs y 3 GiB de RAM.
En el siguiente ejemplo, todos los clústeres de usuarios tienen la misma versión. Si se actualiza el clúster de administrador, solo se utilizan dos conjuntos de controladores de ciclo de vida, por lo que se reduce el consumo de recursos de computación:
| Clúster de administradores | Clúster de usuarios 1 | Clúster de usuarios 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 2000 mCPU y 6 GiB de RAM hasta que todos los clústeres de usuarios se actualicen a la misma versión que el clúster de administrador.
Si los nodos del plano de control no tienen recursos de computación 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 estado Pending. Para resolver este problema, actualice algunos de los clústeres de usuario a la misma versión para consolidar las versiones y reducir el número de controladores de ciclo de vida en uso. Si tu actualización ya se ha quedado bloqueada, también puedes usar kubectl edit deployment para editar las implementaciones pendientes y reducir las solicitudes de CPU y RAM para que se ajusten al plano de control del clúster de administración.
En la siguiente tabla se detallan los requisitos de recursos de computación para diferentes casos de actualización:
| Clúster | Recursos de clúster de administrador necesarios |
|---|---|
| Actualización de clústeres de usuarios | Actualizar a la misma versión de otros clústeres: N/A Actualizar a una versión diferente de otros clústeres de administrador o de usuario: 1000 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) | 1000 mCPUs y 3 GiB de RAM |
| Actualización de clúster híbrido (sin clúster de usuario) | 1000 mCPUs y 3 GiB de RAM. Los recursos se devuelven después de usarse. |
| Independiente | 200 mCPU y 1 GiB de RAM. Los recursos se devuelven después de usarse. |
Crear copias de seguridad de clústeres
Antes de iniciar una actualización, crea una copia de seguridad de los clústeres con el comando bmctl backup cluster.
Como el archivo de copia de seguridad contiene información sensible, guárdalo de forma segura.
Verificar que los clústeres estén configurados y funcionen correctamente
Para comprobar el estado de un clúster antes de actualizarlo, ejecuta bmctl check cluster en el clúster. El comando ejecuta comprobaciones avanzadas, como identificar nodos que no estén configurados correctamente o que tengan pods en un estado bloqueado.
Cuando ejecutas el comando bmctl upgrade cluster para actualizar tus clústeres, se realizan algunas comprobaciones previas. El proceso de actualización se detiene si estas comprobaciones no se realizan correctamente. Lo mejor es identificar y solucionar estos problemas de forma proactiva con el comando bmctl check cluster, en lugar de depender de las comprobaciones previas, que están ahí para proteger los clústeres de posibles daños.
Revisar las implementaciones de cargas de trabajo de los usuarios
Hay dos aspectos que debes tener en cuenta en relación con las cargas de trabajo de los usuarios: desactivación y compatibilidad con la API.
Drenaje de cargas de trabajo
La carga de trabajo del usuario en un nodo se agota 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 drenaje de la carga de trabajo puede provocar 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 que la actualización se quede bloqueada, el proceso de drenaje de la actualización a la versión 1.33 no respeta los presupuestos de interrupción de pods (PDBs). Las cargas de trabajo pueden ejecutarse en un estado degradado y la réplica que menos tráfico recibe sería total
replica number - concurrent upgrade number.
Compatibilidad con APIs
Para comprobar la compatibilidad de la API, comprueba la compatibilidad de la API de tu carga de trabajo con la versión secundaria más reciente de Kubernetes al actualizar a una versión secundaria. Si es necesario, actualiza la carga de trabajo a una versión compatible. Cuando es posible, el equipo de ingeniería de GKE proporciona instrucciones para identificar las cargas de trabajo que usan APIs incompatibles, como las APIs de Kubernetes retiradas.
Si usas Cloud Service Mesh, Config Sync o Policy Controller, comprueba si la versión instalada es compatible con la nueva versión de Google Distributed Cloud. Para obtener información sobre la compatibilidad de versiones, consulta Compatibilidad de versiones y actualizaciones.
Auditar el uso de webhooks
Comprueba si tu clúster tiene algún webhook, especialmente recursos de pods para auditorías, como Policy Controller. El proceso de drenaje durante la actualización del clúster puede interrumpir el servicio de webhook de Policy Controller, lo que puede provocar que la actualización se bloquee o tarde mucho tiempo. Te recomendamos que inhabilites temporalmente estos webhooks o que uses una implementación de alta disponibilidad.
Revisar el uso de las funciones de vista previa
Las funciones de vista previa están sujetas a cambios y se proporcionan únicamente con fines de prueba y evaluación. No utilice funciones de vista previa en sus clústeres de producción. No garantizamos que se puedan actualizar los clústeres que usen funciones de vista previa. En algunos casos, bloqueamos explícitamente las actualizaciones de los clústeres que usan funciones de vista previa.
Para obtener información sobre los cambios que implican un punto de ruptura relacionados con la actualización, consulta las notas de la versión.
Comprobar el estado de SELinux
Si quieres habilitar SELinux para proteger tus contenedores, debes asegurarte de que
SELinux esté habilitado en modo Enforced en todas tus máquinas host. A partir de la versión 1.9.0 de Google Distributed Cloud, puedes habilitar o inhabilitar SELinux antes o después de crear o actualizar un clúster. SELinux está habilitado de forma predeterminada en Red Hat Enterprise Linux (RHEL). Si SELinux está inhabilitado en tus máquinas host o no lo tienes claro, consulta el artículo Protege tus contenedores mediante SELinux para obtener instrucciones sobre cómo habilitarlo.
Google Distributed Cloud solo admite SELinux en sistemas RHEL.
No cambies la configuración de densidad de pods
Google Distributed Cloud admite la configuración de un máximo de 250 pods por nodo con nodeConfig.PodDensity.MaxPodsPerNode. Solo puedes configurar la densidad de pods durante la creación del clúster. No puedes actualizar la configuración de densidad de pods de los clústeres que ya tengas. No intentes cambiar la configuración de densidad de pods durante una actualización.
Comprueba que los nodos del plano de control y del balanceador de carga no estén en modo de mantenimiento
Asegúrate de que los nodos del plano de control y del balanceador de carga 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 asegurarse de que el plano de control y los grupos de nodos del balanceador de carga estén disponibles en cantidad suficiente.
Siguientes pasos
- Actualizar Google Distributed Cloud
- Más información sobre el ciclo de vida y las fases de las actualizaciones
- Solucionar problemas de actualización de clústeres