Nota. transl.: Dailymotion és un dels serveis d'allotjament de vídeo més grans del món i, per tant, un usuari notable de Kubernetes. En aquest material, l'arquitecte de sistemes David Donchez comparteix els resultats de la creació de la plataforma de producció de l'empresa basada en K8s, que va començar amb una instal·lació al núvol a GKE i va acabar com una solució híbrida, que va permetre millors temps de resposta i estalvi en costos d'infraestructura.
Decidir reconstruir l'API principal Fa tres anys, volíem desenvolupar una manera més eficient d'allotjar aplicacions i fer-ho més fàcil . Amb aquesta finalitat, vam decidir utilitzar una plataforma d'orquestració de contenidors i, naturalment, vam triar Kubernetes.
Per què val la pena crear la vostra pròpia plataforma basada en Kubernetes?
API de nivell de producció en molt poc temps amb Google Cloud
Estiu 2016
Fa tres anys, immediatament després que Dailymotion fos comprat per , els nostres equips d'enginyeria estan centrats en un objectiu global: crear un producte Dailymotion completament nou.
Basant-nos en la nostra anàlisi de contenidors, solucions d'orquestració i la nostra experiència passada, estem convençuts que Kubernetes és l'opció correcta. Alguns desenvolupadors ja tenien una comprensió dels conceptes bàsics i sabien com utilitzar-los, la qual cosa va suposar un gran avantatge per a la transformació de la infraestructura.
Des de la perspectiva de la infraestructura, es necessitava un sistema potent i flexible per allotjar nous tipus d'aplicacions natives del núvol. Vam triar quedar-nos al núvol al principi del nostre viatge per poder construir la plataforma local més sòlida possible amb tranquil·litat. Vam decidir desplegar les nostres aplicacions mitjançant Google Kubernetes Engine, tot i que sabíem que tard o d'hora ens traslladaríem als nostres propis centres de dades i aplicaríem una estratègia híbrida.
Per què vas triar GKE?
Hem fet aquesta elecció principalment per motius tècnics. A més, va ser necessari dotar ràpidament d'una infraestructura que respongués a les necessitats de negoci de l'empresa. Teníem alguns requisits per allotjar aplicacions, com ara distribució geogràfica, escalabilitat i tolerància a errors.
Clústers de GKE a Dailymotion
Com que Dailymotion és una plataforma de vídeo disponible a tot el món, volíem millorar la qualitat del servei reduint el temps d'espera. (latència). Abans només estava disponible a París, cosa que no era òptima. Volia poder allotjar aplicacions no només a Europa, sinó també a Àsia i als EUA.
Aquesta sensibilitat a la latència significava que s'hauria de fer un treball seriós a l'arquitectura de xarxa de la plataforma. Tot i que la majoria dels serveis al núvol us obligaven a crear la vostra pròpia xarxa a cada regió i després connectar-los mitjançant una VPN o algun tipus de servei gestionat, Google Cloud us va permetre crear una xarxa única totalment encaminable que cobreixi totes les regions de Google. Això és un gran avantatge pel que fa al funcionament i l'eficiència del sistema.
A més, els serveis de xarxa i els equilibradors de càrrega de Google Cloud fan una feina excel·lent. Simplement us permeten utilitzar adreces IP públiques arbitràries de cada regió, i el meravellós protocol BGP s'encarrega de la resta (és a dir, redirigir els usuaris al clúster més proper). Evidentment, en cas d'avaria, el trànsit anirà automàticament a una altra regió sense cap intervenció humana.
Supervisió de l'equilibri de càrrega de Google
La nostra plataforma també fa un gran ús de les GPU. Google Cloud us permet utilitzar-los de manera molt efectiva directament als clústers de Kubernetes.
En aquell moment, l'equip d'infraestructura es va centrar principalment en la pila heretada desplegada en servidors físics. És per això que l'ús d'un servei gestionat (inclosos els màsters de Kubernetes) va complir els nostres requisits i ens va permetre formar equips per treballar amb clústers locals.
Com a resultat, vam poder començar a rebre trànsit de producció a la infraestructura de Google Cloud només 6 mesos després de l'inici del treball.
Tanmateix, malgrat una sèrie d'avantatges, treballar amb un proveïdor de núvol està associat a certs costos, que poden augmentar en funció de la càrrega. És per això que hem analitzat acuradament cada servei gestionat que hem utilitzat, amb l'esperança d'implementar-los localment en el futur. De fet, a finals de 2016 es va iniciar la implantació dels clústers locals i al mateix temps es va iniciar l'estratègia híbrida.
Llançament de la plataforma local d'orquestració de contenidors Dailymotion
Tardor 2016
En condicions en què tota la pila estava a punt per a la producció i treballar a l'API , era hora de concentrar-se en els clústers regionals.
En aquell moment, els usuaris miraven més de 3 milions de vídeos cada mes. Per descomptat, fa molts anys que tenim la nostra pròpia xarxa de distribució de contingut. Volíem aprofitar aquesta circumstància i desplegar clústers Kubernetes als centres de dades existents.
La infraestructura de Dailymotion constava de més de 2,5 mil servidors en sis centres de dades. Tots ells es configuren mitjançant Saltstack. Vam començar a preparar totes les receptes necessàries per crear nodes mestres i de treball, així com un clúster etcd.
Part de xarxa
La nostra xarxa està completament encaminada. Cada servidor anuncia la seva IP a la xarxa mitjançant Exabgp. Hem comparat diversos connectors de xarxa i l'únic que va satisfer totes les necessitats (a causa de l'enfocament L3 utilitzat) va ser . S'adapta perfectament al model d'infraestructura de xarxa existent.
Com que volíem utilitzar tots els elements d'infraestructura disponibles, el primer que havíem de fer va ser esbrinar la nostra utilitat de xarxa pròpia (utilitzada a tots els servidors): utilitzar-la per anunciar intervals d'adreces IP a la xarxa amb nodes Kubernetes. Vam permetre que Calico assignés adreces IP als pods, però no les vam utilitzar i encara no les vam utilitzar per a sessions BGP en equips de xarxa. De fet, l'encaminament el gestiona Exabgp, que anuncia les subxarxes utilitzades per Calico. Això ens permet arribar a qualsevol pod des de la xarxa interna (i en particular des dels equilibradors de càrrega).
Com gestionem el trànsit d'entrada
Per redirigir les sol·licituds entrants al servei desitjat, es va decidir utilitzar Ingress Controller a causa de la seva integració amb els recursos d'entrada de Kubernetes.
Fa tres anys, nginx-ingress-controller era el controlador més madur: Nginx havia existit durant molt de temps i era conegut per la seva estabilitat i rendiment.
Al nostre sistema, vam decidir col·locar els controladors en servidors blade dedicats de 10 Gigabits. Cada controlador estava connectat al punt final kube-apiserver del clúster corresponent. Aquests servidors també utilitzaven Exabgp per anunciar adreces IP públiques o privades. La nostra topologia de xarxa ens permet utilitzar BGP d'aquests controladors per encaminar tot el trànsit directament als pods sense utilitzar un servei com NodePort. Aquest enfocament ajuda a evitar el trànsit horitzontal entre nodes i millora l'eficiència.
Moviment de trànsit d'Internet a pods
Ara que entenem la nostra plataforma híbrida, podem aprofundir en el procés de migració del trànsit en si.
Migració del trànsit de Google Cloud a la infraestructura de Dailymotion
Tardor 2018
Després de gairebé dos anys de creació, prova i ajustament, finalment tenim una pila de Kubernetes completa preparada per acceptar una mica de trànsit.
L'estratègia d'encaminament actual és bastant simple, però suficient per satisfer les necessitats. A més de les IP públiques (a Google Cloud i Dailymotion), AWS Route 53 s'utilitza per establir polítiques i redirigir els usuaris al clúster que escollim.
Exemple de política d'encaminament amb Route 53
Amb Google Cloud això és fàcil, ja que compartim una única IP a tots els clústers i l'usuari es redirigeix al clúster de GKE més proper. Per als nostres clústers la tecnologia és diferent, ja que les seves IP són diferents.
Durant la migració, vam intentar redirigir les sol·licituds regionals als clústers adequats i vam avaluar els beneficis d'aquest enfocament.
Com que els nostres clústers de GKE estan configurats per escalar automàticament mitjançant mètriques personalitzades, augmenten o redueixen en funció del trànsit entrant.
En mode normal, tot el trànsit regional es dirigeix al clúster local i GKE serveix de reserva en cas de problemes (les comprovacions de salut es fan a la Ruta 53).
...
En el futur, volem automatitzar completament les polítiques d'encaminament per aconseguir una estratègia híbrida autònoma que millori contínuament l'accessibilitat per als usuaris. A més, els costos del núvol s'han reduït significativament i els temps de resposta de l'API fins i tot s'han reduït. Confiem en la plataforma de núvol resultant i estem preparats per redirigir-hi més trànsit si cal.
PS del traductor
També us pot interessar una altra publicació recent de Dailymotion sobre Kubernetes. Es dedica al desplegament d'aplicacions amb Helm en molts clústers de Kubernetes i fa aproximadament un mes.
Llegeix també al nostre blog:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Font: www.habr.com
