Hace unas semanas, actualizamos con éxito el entorno de pruebas para desarrolladores de Cloud Application Platform 2.0 a 2.1. 

Antes de la actualización, se tenía algunas dudas sobre la actualización porque también se estaba actualizando la versión de Kubernetes de 1.14 a 1.18, lo que significaba aumentar las versiones del plano de control y de trabajador. Esto significó la destrucción y la recreación de los nodos de computación varias veces en una sucesión bastante rápida. Todas estas partes móviles significaban una cantidad significativa de riesgo, así como una cantidad desconocida de tiempo de inactividad.

El día de la actualización, comenzamos a escalar el Kubernetes subyacente. El proceso para hacer esto es

• Actualizar el plano de control a la versión n + 1
• Crea nuevos nodos trabajadores con la versión n + 2
• Acordonar luego drenar los nodos viejos
• Repita con el plano de control n + 3
• etc ...

Cada paso de ese proceso tiene el potencial de poner de rodillas a una plataforma desprevenida ...

A continuación, se actualizo la versión de la plataforma a 2.1. Este es un proceso de dos pasos: actualizar el operador de Quarks y luego actualizar las especificaciones de la plataforma. Al igual que con la actualización de K8s, esto no resultó en ningún tiempo de inactividad de la plataforma y solo las cargas de trabajo de una sola réplica vieron alguna interrupción.

Como siempre, Stratos y Minibroker fueron tan fáciles como actualizar el timón.