{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"La aventura de Kubernetes en Dailymotion: creaci\u00f3n de infraestructura en la nube + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"La
\n
\nNota de traducci\u00f3n.<\/b>: Dailymotion \u2014 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\u00f3n de la plataforma de producci\u00f3n de la empresa basada en K8s, que comenz\u00f3 con una instalaci\u00f3n en la nube en GKE y termin\u00f3 como una soluci\u00f3n h\u00edbrida, lo que permiti\u00f3 lograr un mejor tiempo de respuesta y ahorrar en costos de infraestructura.<\/i><\/p>\n

Al tomar la decisi\u00f3n de reconstruir la API principal Dailymotion<\/a><\/noindex> , hace tres a\u00f1os, quer\u00edamos desarrollar una forma m\u00e1s eficiente de alojar aplicaciones y facilitar los procesos en el desarrollo y la producci\u00f3n.<\/a><\/noindex>Para este prop\u00f3sito decidimos utilizar una plataforma de orquestaci\u00f3n de contenedores y, de forma natural, elegimos Kubernetes.<\/p>\n

\u00bfPor qu\u00e9 crear una plataforma propia basada en Kubernetes?<\/a><\/noindex><\/p>\n

API de nivel de producci\u00f3n en poco tiempo con Google Cloud<\/h2>\n

<\/p>\n

Verano de 2016<\/p><\/blockquote>\n

\nHace tres a\u00f1os, justo despu\u00e9s de la compra de Dailymotion por parte de Vivendi<\/a><\/noindex>, nuestros equipos de ingenier\u00eda se enfocaron en un objetivo global: crear un producto completamente nuevo para Dailymotion.<\/p>\n

Despu\u00e9s de analizar contenedores, soluciones de orquestaci\u00f3n y nuestra experiencia pasada, nos convencimos de que Kubernetes era la elecci\u00f3n correcta. Parte de los desarrolladores ya ten\u00eda una comprensi\u00f3n de los conceptos b\u00e1sicos y sab\u00eda c\u00f3mo utilizarlo, lo que fue una gran ventaja para la transformaci\u00f3n de la infraestructura.<\/p>\n

Desde la perspectiva de la infraestructura, se requer\u00eda 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\u00e1s confiable posible. Decidimos desplegar nuestras aplicaciones usando Google Kubernetes Engine, aunque sab\u00edamos que tarde o temprano migrar\u00edamos a nuestros propios centros de datos y aplicar\u00edamos una estrategia h\u00edbrida.<\/p>\n

\u00bfPor qu\u00e9 elegimos GKE?<\/h3>\n

\nHicimos esta elecci\u00f3n principalmente por razones t\u00e9cnicas. Adem\u00e1s, era necesario proporcionar r\u00e1pidamente una infraestructura que respondiera a las necesidades del negocio de la empresa. Ten\u00edamos algunos requisitos en cuanto al alojamiento de aplicaciones, como la distribuci\u00f3n geogr\u00e1fica, la escalabilidad y la resiliencia.<\/p>\n

\"La
\nCl\u00fasteres GKE en Dailymotion<\/i><\/p>\n

Dado que Dailymotion es una plataforma de video accesible en todo el mundo, quer\u00edamos mucho mejorar la calidad del servicio, reduciendo el tiempo de espera. (latencia)<\/i>Anteriormente nuestra API<\/a><\/noindex> solo estaba disponible en Par\u00eds, lo cual no era \u00f3ptimo. Se deseaba tener la posibilidad de desplegar aplicaciones no solo en Europa, sino tambi\u00e9n en Asia y en EE. UU.<\/p>\n

Esta sensibilidad a la latencia significaba que hab\u00eda que trabajar seriamente en la arquitectura de red de la plataforma. Mientras que la mayor\u00eda de los servicios en la nube obligaban a crear su propia red en cada regi\u00f3n y luego conectarlas a trav\u00e9s de VPN o alg\u00fan servicio administrado, Google Cloud permit\u00eda crear una red plenamente enrutada \u00fanica que abarca todas las regiones de Google. Esto es una gran ventaja en t\u00e9rminos de operaci\u00f3n y eficiencia del sistema.<\/p>\n

Adem\u00e1s, los servicios de red y balanceadores de carga de Google Cloud funcionan excepcionalmente bien. Simplemente permiten el uso de IP p\u00fablicas arbitrarias de cada regi\u00f3n, y el magn\u00edfico protocolo BGP se encargar\u00e1 de todo lo dem\u00e1s (es decir, redirigir\u00e1 a los usuarios al cl\u00faster m\u00e1s cercano). Es evidente que en caso de falla, el tr\u00e1fico se redirigir\u00e1 autom\u00e1ticamente a otra regi\u00f3n sin intervenci\u00f3n humana alguna.<\/p>\n

\"La
\nMonitoreo de balanceo de carga en Google<\/i><\/p>\n

Nuestra plataforma tambi\u00e9n utiliza activamente GPUs. Google Cloud permite utilizarlas de manera muy eficiente directamente en los cl\u00fasteres de Kubernetes.<\/p>\n

Mientras tanto, el equipo de infraestructura se concentraba principalmente en la antigua pila desplegada en servidores f\u00edsicos. Por esta raz\u00f3n, el uso de servicios administrados (incluyendo componentes maestros de Kubernetes) cumpl\u00eda con nuestras necesidades y permit\u00eda capacitar a los equipos para trabajar con cl\u00fasteres locales.<\/p>\n

Como resultado, pudimos comenzar a recibir tr\u00e1fico de producci\u00f3n en la infraestructura de Google Cloud solo seis meses despu\u00e9s de haber empezado a trabajar.<\/p>\n

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\u00f3n de cl\u00fasteres locales comenz\u00f3 a finales de 2016 y tambi\u00e9n se inici\u00f3 una estrategia h\u00edbrida en ese momento.<\/p>\n

Lanzamiento de la plataforma local de orquestaci\u00f3n de contenedores de Dailymotion<\/h2>\n

<\/p>\n

Oto\u00f1o de 2016<\/p><\/blockquote>\n

\nEn un contexto en el que toda la pila estaba lista para producci\u00f3n, y el trabajo en la API se prolong\u00f3<\/a><\/noindex>, era un momento para concentrarse en los cl\u00fasteres regionales.<\/p>\n

En ese momento, los usuarios ve\u00edan m\u00e1s de 3 mil millones de videos al mes. Por supuesto, ya llev\u00e1bamos varios a\u00f1os funcionando con nuestra propia red de entrega de contenido. Quer\u00edamos aprovechar esta circunstancia y desplegar cl\u00fasteres de Kubernetes en nuestros centros de datos existentes.<\/p>\n

La infraestructura de Dailymotion contaba con m\u00e1s 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\u00ed como el cl\u00faster etcd.<\/p>\n

\"La
\n<\/p>\n

La parte de red<\/h3>\n

\nNuestra red es completamente enrutada. Cada servidor anuncia su IP en la red utilizando Exabgp. Comparamos varios complementos de red y el \u00fanico que cumpl\u00eda con todas las necesidades (debido al enfoque utilizado a nivel L3) fue Calico<\/a><\/noindex>. Se integr\u00f3 perfectamente en el modelo de red existente de la infraestructura.<\/p>\n

Dado que quer\u00edamos utilizar todos los elementos de infraestructura disponibles, primero ten\u00edamos que entender nuestra herramienta de red interna (utilizada en todos los servidores): usarla para anunciar los rangos de direcciones IP en la red con nodos de Kubernetes. Permitimos que Calico asignara direcciones IP a los pods, pero no la usamos y todav\u00eda no la utilizamos para las sesiones BGP en el equipo de red. De hecho, el enrutamiento lo maneja Exabgp, que anuncia las subredes utilizadas por Calico. Esto nos permite acceder a cualquier pod desde la red interna (y en particular desde los equilibradores de carga).<\/p>\n

C\u00f3mo gestionamos el tr\u00e1fico ingress<\/h3>\n

\nPara redirigir las solicitudes entrantes al servicio adecuado, decidimos utilizar Ingress Controller debido a su integraci\u00f3n con los recursos ingress de Kubernetes.<\/p>\n

Hace tres a\u00f1os, nginx-ingress-controller era el controlador m\u00e1s maduro: Nginx hab\u00eda sido utilizado durante mucho tiempo y era conocido por su estabilidad y rendimiento.<\/p>\n

En nuestro sistema decidimos alojar los controladores en servidores blade dedicados de 10 gigabits. Cada controlador se conectaba al endpoint del kube-apiserver del cl\u00faster correspondiente. En estos servidores tambi\u00e9n se utiliz\u00f3 Exabgp para anunciar direcciones IP p\u00fablicas o privadas. La topolog\u00eda de nuestra red permite utilizar BGP desde estos controladores para enrutar todo el tr\u00e1fico directamente a los pods sin utilizar un servicio como NodePort. Este enfoque ayuda a evitar el tr\u00e1fico horizontal entre nodos y mejora la eficiencia.<\/p>\n

\"La
\nMovimiento de tr\u00e1fico desde Internet a los pods<\/i><\/p>\n

Ahora que hemos comprendido nuestra plataforma h\u00edbrida, podemos profundizar en el propio proceso de migraci\u00f3n del tr\u00e1fico.<\/p>\n

Migraci\u00f3n del tr\u00e1fico desde Google Cloud a la infraestructura de Dailymotion<\/h2>\n

<\/p>\n

Oto\u00f1o de 2018<\/p><\/blockquote>\n

\nDespu\u00e9s de casi dos a\u00f1os de creaci\u00f3n, pruebas y configuraciones, finalmente tenemos un stack completo de Kubernetes listo para recibir parte del tr\u00e1fico.<\/p>\n

\"La
\n
\nLa estrategia actual de enrutamiento es bastante simple, pero satisface las necesidades. Adem\u00e1s de las IP p\u00fablicas (en Google Cloud y Dailymotion), utilizamos AWS Route 53 para establecer pol\u00edticas y redirigir a los usuarios al cl\u00faster de nuestra elecci\u00f3n.<\/p>\n

\"La
\nEjemplo de pol\u00edtica de enrutamiento utilizando Route 53<\/i><\/p>\n

Con Google Cloud es sencillo, ya que empleamos una sola IP para todos los cl\u00fasteres, y el usuario se redirige al cl\u00faster GKE m\u00e1s cercano. Para nuestros cl\u00fasteres la tecnolog\u00eda es diferente, ya que sus IP son distintas.<\/p>\n

Durante la migraci\u00f3n, buscamos redirigir las solicitudes regionales a los cl\u00fasteres correspondientes y evaluamos los beneficios de este enfoque.<\/p>\n

Dado que nuestros cl\u00fasteres GKE est\u00e1n configurados para escalar autom\u00e1ticamente utilizando M\u00e9tricas Personalizadas, aumentan\/reducen recursos en funci\u00f3n del tr\u00e1fico entrante.<\/p>\n

En condiciones normales, todo el tr\u00e1fico regional se dirige al cl\u00faster local, mientras que GKE sirve como respaldo en caso de problemas (se realizan verificaciones de estado a trav\u00e9s de Route 53).<\/p>\n

\u2026<\/h2>\n

\nEn el futuro, queremos automatizar completamente las pol\u00edticas de enrutamiento para obtener una estrategia h\u00edbrida aut\u00f3noma que mejore continuamente la disponibilidad para los usuarios. En cuanto a los beneficios: los costes en la nube se han reducido considerablemente y tambi\u00e9n hemos logrado disminuir el tiempo de respuesta de la API. Confiamos en la plataforma en la nube resultante y estamos listos para redirigir m\u00e1s tr\u00e1fico a ella si es necesario.<\/p>\n

P.D. del traductor<\/h2>\n

\nPuede que tambi\u00e9n le interese otra publicaci\u00f3n reciente de Dailymotion sobre Kubernetes. Est\u00e1 dedicada al despliegue de aplicaciones con Helm en m\u00faltiples cl\u00fasteres de Kubernetes y se ha publicado<\/a><\/noindex> hace aproximadamente un mes.<\/p>\n

Tambi\u00e9n puedes leer en nuestro blog:<\/p>\n