Uber explicó cómo reorganizó el escalado de sus servicios en Kubernetes para responder a fallos regionales sin mantener tanta capacidad inactiva. Su plataforma opera más de cien clústeres y miles de servicios. Cuando una región falla, otra debe absorber tráfico: antes se reservaban recursos ociosos para ese escenario; ahora Uber busca liberar capacidad de servicios menos prioritarios y asignarla a los más críticos.
El reto era permitir que el controlador habitual de despliegues y el sistema de recuperación expresaran decisiones de escalado sobre las mismas cargas. Uber creó el recurso ServiceScale para registrar cada intención y un controlador específico que combina esas intenciones y aplica el resultado a Kubernetes. Guardar el estado en recursos del propio clúster facilita inspeccionar quién solicitó un cambio y recuperar la situación normal después de un incidente.
La implantación reveló problemas propios de los sistemas con varios escritores. Las cachés de los controladores podían mostrar datos atrasados, por lo que Uber añadió una comprobación de generación antes de informar que un cambio había terminado. También detectó desajustes entre los metadatos y la configuración de ReplicaSet cuando dos controladores escribían a la vez; incorporó observabilidad y reparación automática. El despliegue duró un año, con pruebas de integración y activación gradual, y terminó sin interrupciones para los clientes. La experiencia subraya que coordinar el estado observado y las escrituras importa tanto como diseñar los nuevos recursos.
Glosario
- Kubernetes
- Plataforma que organiza la ejecución, el despliegue y el escalado de aplicaciones en contenedores.
- ServiceScale
- Recurso creado por Uber para registrar la capacidad que solicita cada sistema encargado del escalado.
- Controlador
- Proceso que observa el estado de Kubernetes y realiza cambios para acercarlo al estado deseado.
- ReplicaSet
- Recurso de Kubernetes que mantiene en funcionamiento un número determinado de réplicas de una aplicación.