Nota. traducir: Dailymotion es uno de los servicios de alojamiento de vídeos más grandes del mundo y, por lo tanto, un usuario notable de Kubernetes. En este material, el arquitecto de sistemas David Donchez comparte los resultados de la creación de la plataforma de producción de la empresa basada en K8, que comenzó con una instalación en la nube en GKE y terminó como una solución híbrida, lo que permitió mejores tiempos de respuesta y ahorros en costos de infraestructura.
Decidir reconstruir la API principal Hace tres años, queríamos desarrollar una forma más eficiente de alojar aplicaciones y hacerlo más fácil. . Para ello, decidimos utilizar una plataforma de orquestación de contenedores y, naturalmente, elegimos Kubernetes.
¿Por qué vale la pena construir tu propia plataforma basada en Kubernetes?
API de nivel de producción en poco tiempo usando Google Cloud
Verano 2016
Hace tres años, inmediatamente después de que Dailymotion fuera comprada por , nuestros equipos de ingeniería se centran en un objetivo global: crear un producto Dailymotion completamente nuevo.
Según nuestro análisis de contenedores, soluciones de orquestación y nuestra experiencia pasada, estamos convencidos de que Kubernetes es la elección correcta. Algunos desarrolladores ya conocían los conceptos básicos y sabían cómo utilizarlos, lo que supuso una gran ventaja para la transformación de la infraestructura.
Desde una perspectiva de infraestructura, se necesitaba un sistema potente y flexible para alojar nuevos tipos de aplicaciones nativas de la nube. Elegimos permanecer en la nube al comienzo de nuestro viaje para poder construir la plataforma local más sólida posible con tranquilidad. Decidimos desplegar nuestras aplicaciones utilizando Google Kubernetes Engine, aunque sabíamos que tarde o temprano nos trasladaríamos a nuestros propios centros de datos y aplicaríamos una estrategia híbrida.
¿Por qué elegiste GKE?
Tomamos esta decisión principalmente por razones técnicas. Además, era necesario dotar rápidamente de una infraestructura que satisficiera las necesidades comerciales de la empresa. Teníamos algunos requisitos para alojar aplicaciones, como distribución geográfica, escalabilidad y tolerancia a fallas.
Clústeres de GKE en Dailymotion
Dado que Dailymotion es una plataforma de vídeo disponible en todo el mundo, realmente queríamos mejorar la calidad del servicio reduciendo el tiempo de espera. (estado latente)... Previamente sólo estaba disponible en París, lo cual no era óptimo. Quería poder alojar aplicaciones no sólo en Europa, sino también en Asia y Estados Unidos.
Esta sensibilidad a la latencia significaba que habría que realizar un trabajo serio en la arquitectura de red de la plataforma. Si bien la mayoría de los servicios en la nube te obligaban a crear tu propia red en cada región y luego conectarlas a través de una VPN o algún tipo de servicio administrado, Google Cloud te permitía crear una red única totalmente enrutable que cubría todas las regiones de Google. Esta es una gran ventaja en términos de funcionamiento y eficiencia del sistema.
Además, los servicios de red y los balanceadores de carga de Google Cloud hacen un excelente trabajo. Simplemente le permiten utilizar direcciones IP públicas arbitrarias de cada región, y el maravilloso protocolo BGP se encarga del resto (es decir, redirige a los usuarios al clúster más cercano). Evidentemente, en caso de fallo, el tráfico se dirigirá automáticamente a otra región sin intervención humana.
Monitoreo del equilibrio de carga de Google
Nuestra plataforma también hace un uso intensivo de GPU. Google Cloud te permite utilizarlos de forma muy eficaz directamente en clústeres de Kubernetes.
En ese momento, el equipo de infraestructura se centraba principalmente en la pila heredada implementada en servidores físicos. Es por eso que el uso de un servicio administrado (incluidos los maestros de Kubernetes) cumplió con nuestros requisitos y nos permitió capacitar equipos para trabajar con clústeres locales.
Como resultado, pudimos comenzar a recibir tráfico de producción en la infraestructura de Google Cloud solo 6 meses después del inicio del trabajo.
Sin embargo, a pesar de una serie de ventajas, trabajar con un proveedor de la nube conlleva ciertos costes, que pueden aumentar en función de la carga. Es por eso que analizamos cuidadosamente cada servicio administrado que utilizamos, con la esperanza de implementarlos localmente en el futuro. De hecho, la implementación de clusters locales comenzó a finales de 2016 y al mismo tiempo se inició la estrategia híbrida.
Lanzamiento de la plataforma local de orquestación de contenedores Dailymotion
Otoño '2016
En condiciones en las que toda la pila estaba lista para producción y se trabajaba en la API , había llegado el momento de concentrarse en los grupos regionales.
En ese momento, los usuarios veían más de 3 mil millones de vídeos cada mes. Por supuesto, desde hace muchos años contamos con nuestra propia y extensa red de distribución de contenidos. Queríamos aprovechar esta circunstancia e implementar clústeres de Kubernetes en los centros de datos existentes.
La infraestructura de Dailymotion constaba de más de 2,5 mil servidores en seis centros de datos. Todos ellos están configurados usando Saltstack. Comenzamos a preparar todas las recetas necesarias para crear nodos maestros y trabajadores, así como un clúster etcd.
parte de la red
Nuestra red está completamente enrutada. Cada servidor anuncia su IP en la red mediante Exabgp. Comparamos varios complementos de red y el único que satisfizo todas las necesidades (debido al enfoque L3 utilizado) fue . Encaja perfectamente en el modelo de infraestructura de red existente.
Como queríamos utilizar todos los elementos de infraestructura disponibles, lo primero que teníamos que hacer era descubrir nuestra utilidad de red propia (utilizada en todos los servidores): usarla para anunciar rangos de direcciones IP en la red con nodos de Kubernetes. Permitimos que Calico asignara direcciones IP a pods, pero no las usamos ni las usamos para sesiones BGP en equipos de red. De hecho, el enrutamiento lo maneja Exabgp, que anuncia las subredes utilizadas por Calico. Esto nos permite llegar a cualquier pod desde la red interna (y en particular desde balanceadores de carga).
Cómo gestionamos el tráfico de entrada
Para redirigir las solicitudes entrantes al servicio deseado, se decidió utilizar Ingress Controller debido a su integración con los recursos de ingreso de Kubernetes.
Hace tres años, nginx-ingress-controller era el controlador más maduro: Nginx existía desde hacía mucho tiempo y era conocido por su estabilidad y rendimiento.
En nuestro sistema, decidimos colocar los controladores en servidores blade dedicados de 10 Gigabit. Cada controlador estaba conectado al punto final kube-apiserver del clúster correspondiente. Estos servidores también utilizaron Exabgp para anunciar direcciones IP públicas o privadas. Nuestra topología de red nos permite usar BGP de estos controladores para enrutar todo el tráfico directamente a los pods sin usar un servicio como NodePort. Este enfoque ayuda a evitar el tráfico horizontal entre nodos y mejora la eficiencia.
Movimiento de tráfico desde Internet a los pods
Ahora que entendemos nuestra plataforma híbrida, podemos profundizar en el proceso de migración del tráfico en sí.
Migración de tráfico de Google Cloud a la infraestructura de Dailymotion
Otoño '2018
Después de casi dos años de construcción, pruebas y ajustes, finalmente tenemos una pila de Kubernetes completa lista para aceptar algo de tráfico.
La estrategia de enrutamiento actual es bastante simple, pero suficiente para satisfacer las necesidades. Además de las IP públicas (en Google Cloud y Dailymotion), se utiliza AWS Route 53 para establecer políticas y redirigir a los usuarios al cluster que elijamos.
Ejemplo de política de enrutamiento utilizando la Ruta 53
Con Google Cloud, esto es fácil ya que compartimos una única IP en todos los clústeres y el usuario es redirigido al clúster de GKE más cercano. Para nuestros clusters la tecnología es diferente, ya que sus IP son diferentes.
Durante la migración, buscamos redirigir las solicitudes regionales a los grupos apropiados y evaluamos los beneficios de este enfoque.
Debido a que nuestros clústeres de GKE están configurados para escalarse automáticamente mediante métricas personalizadas, aumentan o disminuyen según el tráfico entrante.
En modo normal, todo el tráfico regional se dirige al clúster local y GKE sirve como reserva en caso de problemas (los controles de estado se llevan a cabo en la Ruta 53).
...
En el futuro, queremos automatizar completamente las políticas de enrutamiento para lograr una estrategia híbrida autónoma que mejore continuamente la accesibilidad para los usuarios. El lado positivo es que los costes de la nube se han reducido significativamente e incluso los tiempos de respuesta de las API se han reducido. Confiamos en la plataforma en la nube resultante y estamos listos para redirigir más tráfico hacia ella si es necesario.
PD del traductor
Quizás también le interese otra publicación reciente de Dailymotion sobre Kubernetes. Está dedicado a la implementación de aplicaciones con Helm en muchos clústeres de Kubernetes y Hace más o menos un mes.
Lea también en nuestro blog:
- «".
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «".
Fuente: habr.com