Nota de traducción.: Dailymotion — uno de los mayores servicios de alojamiento de video en el mundo y por tanto un usuario destacado 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 K8s, que comenzó con una instalación en la nube en GKE y terminó como una solución híbrida, lo que permitió lograr un mejor tiempo de respuesta y ahorrar en costos de infraestructura.
Al tomar la decisión de reconstruir la API principal , hace tres años, queríamos desarrollar una forma más eficiente de alojar aplicaciones y facilitar Para este propósito decidimos utilizar una plataforma de orquestación de contenedores y, de forma natural, elegimos Kubernetes.
¿Por qué crear una plataforma propia basada en Kubernetes?
API de nivel de producción en poco tiempo con Google Cloud
Verano de 2016
Hace tres años, justo después de la compra de Dailymotion por parte de , nuestros equipos de ingeniería se enfocaron en un objetivo global: crear un producto completamente nuevo para Dailymotion.
Después de analizar contenedores, soluciones de orquestación y nuestra experiencia pasada, nos convencimos de que Kubernetes era la elección correcta. Parte de los desarrolladores ya tenía una comprensión de los conceptos básicos y sabía cómo utilizarlo, lo que fue una gran ventaja para la transformación de la infraestructura.
Desde la perspectiva de la infraestructura, se requería un sistema potente y flexible para alojar nuevos tipos de aplicaciones nativas de la nube. Preferimos quedarnos en la nube al principio de nuestro viaje para construir una plataforma local lo más confiable posible. Decidimos desplegar nuestras aplicaciones usando Google Kubernetes Engine, aunque sabíamos que tarde o temprano migraríamos a nuestros propios centros de datos y aplicaríamos una estrategia híbrida.
¿Por qué elegimos GKE?
Hicimos esta elección principalmente por razones técnicas. Además, era necesario proporcionar rápidamente una infraestructura que respondiera a las necesidades del negocio de la empresa. Teníamos algunos requisitos en cuanto al alojamiento de aplicaciones, como la distribución geográfica, la escalabilidad y la resiliencia.
Clústeres GKE en Dailymotion
Dado que Dailymotion es una plataforma de video accesible en todo el mundo, queríamos mucho mejorar la calidad del servicio, reduciendo el tiempo de espera. (latencia)Anteriormente solo estaba disponible en París, lo cual no era óptimo. Se deseaba tener la posibilidad de desplegar aplicaciones no solo en Europa, sino también en Asia y en EE. UU.
Esta sensibilidad a la latencia significaba que había que trabajar seriamente en la arquitectura de red de la plataforma. Mientras que la mayoría de los servicios en la nube obligaban a crear su propia red en cada región y luego conectarlas a través de VPN o algún servicio administrado, Google Cloud permitía crear una red plenamente enrutada única que abarca todas las regiones de Google. Esto es una gran ventaja en términos de operación y eficiencia del sistema.
Además, los servicios de red y balanceadores de carga de Google Cloud funcionan excepcionalmente bien. Simplemente permiten el uso de IP públicas arbitrarias de cada región, y el magnífico protocolo BGP se encargará de todo lo demás (es decir, redirigirá a los usuarios al clúster más cercano). Es evidente que en caso de falla, el tráfico se redirigirá automáticamente a otra región sin intervención humana alguna.
Monitoreo de balanceo de carga en Google
Nuestra plataforma también utiliza activamente GPUs. Google Cloud permite utilizarlas de manera muy eficiente directamente en los clústeres de Kubernetes.
Mientras tanto, el equipo de infraestructura se concentraba principalmente en la antigua pila desplegada en servidores físicos. Por esta razón, el uso de servicios administrados (incluyendo componentes maestros de Kubernetes) cumplía con nuestras necesidades y permitía capacitar a los 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 seis meses después de haber empezado a trabajar.
Sin embargo, a pesar de una serie de ventajas, trabajar con un proveedor de nube conlleva ciertos costos que pueden aumentar dependiendo de la carga. Por eso, analizamos cuidadosamente cada servicio administrado utilizado, considerando en el futuro implementarlos en nuestras instalaciones. De hecho, la implementación de clústeres locales comenzó a finales de 2016 y también se inició una estrategia híbrida en ese momento.
Lanzamiento de la plataforma local de orquestación de contenedores de Dailymotion
Otoño de 2016
En un contexto en el que toda la pila estaba lista para producción, y el trabajo en la API , era un momento para concentrarse en los clústeres regionales.
En ese momento, los usuarios veían más de 3 mil millones de videos al mes. Por supuesto, ya llevábamos varios años funcionando con nuestra propia red de entrega de contenido. Queríamos aprovechar esta circunstancia y desplegar clústeres de Kubernetes en nuestros centros de datos existentes.
La infraestructura de Dailymotion contaba con más de 2,5 mil servidores en seis centros de datos. Todos ellos se configuran mediante Saltstack. Comenzamos a preparar todas las recetas necesarias para crear nodos maestro y worker, así como el clúster etcd.
La parte de red
Nuestra red es completamente enrutada. Cada servidor anuncia su IP en la red utilizando Exabgp. Comparamos varios complementos de red y el único que cumplía con todas las necesidades (debido al enfoque utilizado a nivel L3) fue . Se integró perfectamente en el modelo de red existente de la infraestructura.
Dado que queríamos utilizar todos los elementos de infraestructura disponibles, primero había que entender nuestra herramienta de red desarrollada internamente (utilizada en todos los servidores): usarla para anunciar rangos de direcciones IP en la red con los nodos de Kubernetes. Permitimos que Calico asignara direcciones IP a los pods, pero no lo utilizamos y aún no lo utilizamos para las sesiones BGP en el equipo de red. De hecho, el enrutamiento es gestionado por Exabgp, que anuncia las subredes utilizadas por Calico. Esto nos permite acceder a cualquier pod desde la red interna (y en particular desde los balanceadores de carga).
Cómo gestionamos el tráfico ingress
Para redirigir las solicitudes entrantes al servicio adecuado, decidimos utilizar Ingress Controller debido a su integración con los recursos ingress de Kubernetes.
Hace tres años, nginx-ingress-controller era el controlador más maduro: Nginx había sido utilizado durante mucho tiempo y era conocido por su estabilidad y rendimiento.
En nuestro sistema, decidimos ubicar los controladores en servidores blade dedicados de 10 gigabits. Cada controlador se conectaba al endpoint kube-apiserver del clúster correspondiente. En estos servidores también se utilizaba Exabgp para anunciar direcciones IP públicas o privadas. La topología de nuestra red permite utilizar BGP desde estos controladores para enrutar todo el tráfico directamente a los pods sin utilizar servicios como NodePort. Este enfoque ayuda a evitar el tráfico horizontal entre nodos y aumenta la eficiencia.
El tráfico desde Internet hacia los pods
Ahora que hemos comprendido nuestra plataforma híbrida, podemos profundizar en el propio proceso de migración del tráfico.
Migración del tráfico desde Google Cloud a la infraestructura de Dailymotion
Otoño de 2018
Después de casi dos años de creación, pruebas y configuraciones, finalmente tenemos un stack completo de Kubernetes listo para recibir parte del tráfico.
La estrategia actual de enrutamiento es bastante simple, pero satisface las necesidades. Además de las IP públicas (en Google Cloud y Dailymotion), utilizamos AWS Route 53 para establecer políticas y redirigir a los usuarios al clúster de nuestra elección.
Ejemplo de política de enrutamiento utilizando Route 53
Con Google Cloud es sencillo, ya que empleamos una sola IP para todos los clústeres, y el usuario se redirige al clúster GKE más cercano. Para nuestros clústeres la tecnología es diferente, ya que sus IP son distintas.
Durante la migración, buscamos redirigir las solicitudes regionales a los clústeres correspondientes y evaluamos los beneficios de este enfoque.
Dado que nuestros clústeres GKE están configurados para escalar automáticamente utilizando Métricas Personalizadas, aumentan/reducen recursos en función del tráfico entrante.
En condiciones normales, todo el tráfico regional se dirige al clúster local, y GKE sirve como respaldo en caso de problemas (los health-checks se realizan a través de Route 53).
…
En el futuro, queremos automatizar completamente las políticas de enrutamiento para obtener una estrategia híbrida autónoma que mejore continuamente la disponibilidad para los usuarios. En cuanto a los beneficios: los costes en la nube se han reducido considerablemente y también hemos logrado disminuir el tiempo de respuesta de la API. Confiamos en la plataforma en la nube resultante y estamos listos para redirigir más tráfico a ella si es necesario.
P.D. del traductor
Puede que también le interese otra publicación reciente de Dailymotion sobre Kubernetes. Está dedicada al despliegue de aplicaciones con Helm en múltiples clústeres de Kubernetes y hace aproximadamente un mes.
También puedes leer en nuestro blog:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
