Al llarg dels anys, els 300 milions d'usuaris de Pinterest han creat més de 200 mil milions de pins en més de 4 mil milions de taulers. Per servir aquest exèrcit d'usuaris i una àmplia base de contingut, el portal ha desenvolupat milers de serveis, que van des de microserveis que poden ser gestionats per unes quantes CPU, fins a monòlits gegants que s'executen en tota una flota de màquines virtuals. I aleshores va arribar el moment en què els ulls de l'empresa van caure en els k8. Per què el "cub" es veia bé a Pinterest? Aprendràs sobre això amb la nostra traducció d'un article recent de .
Així, centenars de milions d'usuaris i centenars de milers de milions de pins. Per servir aquest exèrcit d'usuaris i una àmplia base de contingut, hem desenvolupat milers de serveis, que van des de microserveis que poden ser gestionats per unes quantes CPU fins a monòlits gegants que s'executen en flotes senceres de màquines virtuals. A més, tenim una varietat de marcs que també poden requerir accés a CPU, memòria o E/S.
En mantenir aquest zoo d'eines, l'equip de desenvolupament s'enfronta a una sèrie de reptes:
- No hi ha una manera uniforme perquè els enginyers executin un entorn de producció. Els serveis sense estat, els serveis amb estat i els projectes en desenvolupament actiu es basen en piles de tecnologia completament diferents. Això va comportar la creació de tot un curs de formació per a enginyers, i també complica seriosament la feina del nostre equip d'infraestructures.
- Els desenvolupadors amb la seva pròpia flota de màquines virtuals creen una gran càrrega per als administradors interns. Com a resultat, operacions tan senzilles com l'actualització del sistema operatiu o de l'AMI triguen setmanes i mesos. Això comporta un augment de la càrrega de treball en situacions aparentment absolutament quotidianes.
- Dificultats per crear eines globals de gestió d'infraestructures sobre les solucions existents. La situació es complica encara més pel fet que trobar els propietaris de màquines virtuals no és fàcil. És a dir, no sabem si aquesta capacitat es pot extreure amb seguretat per operar en altres parts de la nostra infraestructura.
Els sistemes d'orquestració de contenidors són una manera d'unificar la gestió de la càrrega de treball. Obren la porta a una major velocitat de desenvolupament i simplifiquen la gestió de la infraestructura, ja que tots els recursos implicats en el projecte són gestionats per un sistema centralitzat.
Figura 1: Prioritats d'infraestructura (fiabilitat, productivitat del desenvolupador i eficiència).
L'equip de Cloud Management Platform de Pinterest va descobrir K8s el 2017. Al primer semestre del 2017, havíem documentat la majoria de les nostres capacitats de producció, inclosa l'API i tots els nostres servidors web. Després, vam realitzar una avaluació exhaustiva de diversos sistemes per orquestrar solucions de contenidors, construir clústers i treballar amb ells. A finals del 2017, vam decidir utilitzar Kubernetes. Era bastant flexible i tenia un gran suport a la comunitat de desenvolupadors.
Fins ara, hem creat les nostres pròpies eines d'arrencada de clúster basades en Kops i hem migrat components d'infraestructura existents com ara xarxes, seguretat, mètriques, registre, gestió d'identitats i trànsit a Kubernetes. També hem implementat un sistema de modelització de càrrega de treball per al nostre recurs, la complexitat del qual està oculta als desenvolupadors. Ara estem centrats a garantir l'estabilitat del clúster, escalar-lo i connectar nous clients.
Kubernetes: la manera de Pinterest
Començar amb Kubernetes a l'escala de Pinterest com a plataforma que els encantaria als nostres enginyers va comportar molts reptes.
Com a gran empresa, hem invertit molt en eines d'infraestructura. Alguns exemples inclouen eines de seguretat que gestionen el processament de certificats i la distribució de claus, components de control de trànsit, sistemes de descoberta de serveis, components de visibilitat i components de registre i enviament de mètriques. Tot això es va recollir per un motiu: vam seguir el camí normal d'assaig i error i, per tant, vam voler integrar tot aquest equipament a la nova infraestructura de Kubernetes en comptes de reinventar la roda antiga en una plataforma nova. Aquest enfocament en general va simplificar la migració, ja que tot el suport de l'aplicació ja existeix i no cal que es creï des de zero.
D'altra banda, els models de previsió de càrrega del mateix Kubernetes (com ara desplegaments, treballs i conjunts de Daemon) no són suficients per al nostre projecte. Aquests problemes d'usabilitat són grans obstacles per passar a Kubernetes. Per exemple, hem sentit que els desenvolupadors de serveis es queixen de la falta de configuració d'inici de sessió o és incorrecta. També vam trobar un ús incorrecte dels motors de plantilles, quan es van crear centenars de còpies amb la mateixa especificació i tasca, la qual cosa va provocar problemes de depuració de malson.
També era molt difícil mantenir diferents versions al mateix clúster. Imagineu la complexitat de l'assistència al client si necessiteu treballar simultàniament en diverses versions del mateix entorn d'execució, amb tots els seus problemes, errors i actualitzacions.
Propietats i controladors d'usuari de Pinterest
Per facilitar als nostres enginyers la implementació de Kubernetes i per simplificar i accelerar la nostra infraestructura, hem desenvolupat les nostres pròpies definicions de recursos personalitzades (CRD).
Els CRD proporcionen la següent funcionalitat:
- Combinant diferents recursos natius de Kubernetes perquè funcionin com una única càrrega de treball. Per exemple, el recurs PinterestService inclou un desplegament, un servei d'inici de sessió i un mapa de configuració. Això permet als desenvolupadors no preocupar-se per configurar DNS.
- Implementar el suport d'aplicació necessari. L'usuari només ha de centrar-se en l'especificació del contenidor d'acord amb la seva lògica de negoci, mentre que el controlador CRD implementa tots els contenidors d'inici necessaris, les variables d'entorn i les especificacions del pod. Això proporciona un nivell de comoditat fonamentalment diferent per als desenvolupadors.
- Els controladors CRD també gestionen el cicle de vida dels recursos natius i milloren la disponibilitat de depuració. Això inclou la conciliació de les especificacions desitjades i reals, l'actualització de l'estat de CRD i el manteniment dels registres d'esdeveniments i molt més. Sense CRD, els desenvolupadors es veurien obligats a gestionar diversos recursos, la qual cosa només augmentaria la probabilitat d'error.
Aquí teniu un exemple d'un servei Pinterest i un recurs intern que gestiona el nostre controlador:
Com podeu veure més amunt, per donar suport a un contenidor personalitzat hem d'integrar un contenidor d'inici i diversos complements per proporcionar seguretat, visibilitat i trànsit de xarxa. A més, hem creat plantilles de mapa de configuració i hem implementat suport per a plantilles de PVC per a treballs per lots, així com el seguiment de múltiples variables d'entorn per fer un seguiment de la identitat, el consum de recursos i la recollida d'escombraries.
És difícil imaginar que els desenvolupadors vulguin escriure aquests fitxers de configuració a mà sense suport CRD, i molt menys mantenir i depurar les configuracions.
Flux de treball de desplegament d'aplicacions
La imatge de dalt mostra com implementar un recurs personalitzat de Pinterest a un clúster de Kubernetes:
- Els desenvolupadors interactuen amb el nostre clúster Kubernetes mitjançant la CLI i la interfície d'usuari.
- Les eines CLI/UI recuperen els fitxers YAML de configuració del flux de treball i altres propietats de compilació (el mateix ID de versió) d'Artifactory i, a continuació, els envien al Servei de presentació de treballs. Aquest pas garanteix que només es lliuren versions de producció al clúster.
- JSS és una passarel·la per a diverses plataformes, inclòs Kubernetes. Aquí s'autentica l'usuari, s'emeten quotes i es comprova parcialment la configuració del nostre CRD.
- Després de comprovar el CRD al costat de JSS, la informació s'envia a l'API de la plataforma k8s.
- El nostre controlador CRD supervisa els esdeveniments en tots els recursos d'usuari. Converteix CR en recursos nadius de k8s, afegeix els mòduls necessaris, estableix les variables d'entorn adequades i realitza altres treballs de suport per garantir que les aplicacions d'usuari en contenidors tinguin suficient suport d'infraestructura.
- A continuació, el controlador CRD passa les dades rebudes a l'API de Kubernetes perquè el planificador les processi i les posi en producció.
Nota: Aquest flux de treball previ al llançament del desplegament es va crear per als primers usuaris de la nova plataforma k8s. Actualment estem en procés de perfeccionar aquest procés per integrar-lo completament amb el nostre nou CI/CD. Això vol dir que no us podem dir tot el relacionat amb Kubernetes. Esperem compartir la nostra experiència i el progrés de l'equip en aquesta direcció a la nostra propera entrada al bloc, "Creant una plataforma CI/CD per a Pinterest".
Tipus de recursos especials
En funció de les necessitats específiques de Pinterest, hem desenvolupat els següents CRD per adaptar-se a diferents fluxos de treball:
- PinterestService són serveis sense estat que s'estan executant durant molt de temps. Molts dels nostres sistemes bàsics es basen en un conjunt d'aquests serveis.
- PinterestJobSet modela treballs per lots de cicle complet. Un escenari comú a Pinterest és que diversos treballs executen els mateixos contenidors en paral·lel, independentment d'altres processos similars.
- PinterestCronJob s'utilitza àmpliament juntament amb petites càrregues periòdiques. Aquest és un embolcall per al treball cron natiu amb mecanismes de suport de Pinterest que són responsables de la seguretat, el trànsit, els registres i les mètriques.
- PinterestDaemon inclou dimonis d'infraestructura. Aquesta família continua creixent a mesura que afegim més suport als nostres clústers.
- PinterestTrainingJob s'estén als processos Tensorflow i Pytorch, proporcionant el mateix nivell de suport en temps d'execució que tots els altres CRD. Com que Pinterest utilitza activament Tensorflow i altres sistemes d'aprenentatge automàtic, teníem un motiu per crear un CRD separat al seu voltant.
També estem treballant en PinterestStatefulSet, que aviat s'adaptarà per a magatzems de dades i altres sistemes amb estat.
Suport en temps d'execució
Quan un pod d'aplicació s'executa a Kubernetes, rep automàticament un certificat per identificar-se. Aquest certificat s'utilitza per accedir a l'emmagatzematge secret o per comunicar-se amb altres serveis mitjançant mTLS. Mentrestant, el Container Init Configurator i Daemon baixaran totes les dependències necessàries abans d'executar l'aplicació en contenidors. Quan tot estigui a punt, el vehicle sidecar de trànsit i Daemon registraran l'adreça IP del mòdul amb el nostre Zookeeper perquè els clients la puguin descobrir. Tot això funcionarà perquè el mòdul de xarxa es va configurar abans de llançar l'aplicació.
Els anteriors són exemples típics de suport en temps d'execució per a càrregues de treball. Altres tipus de càrregues de treball poden requerir un suport lleugerament diferent, però tots es presenten en forma de sidecars a nivell de pod, dimonis a nivell de node o de màquina virtual. Ens assegurem que tot això es desplega dins de la infraestructura de gestió i és coherent entre les aplicacions, la qual cosa, en definitiva, redueix significativament la càrrega en termes de treball tècnic i assistència al client.
Proves i control de qualitat
Hem creat un pipeline de proves d'extrem a extrem a sobre de la infraestructura de proves de Kubernetes existent. Aquestes proves s'apliquen a tots els nostres clústers. El nostre pipeline va passar per moltes revisions abans de passar a formar part del clúster de productes.
A més dels sistemes de prova, disposem de sistemes de monitorització i alerta que controlen constantment l'estat dels components del sistema, el consum de recursos i altres indicadors importants, avisant-nos només quan és necessària la intervenció humana.
Alternatives
Hem analitzat algunes alternatives als recursos personalitzats, com ara controladors d'accés a mutacions i sistemes de plantilles. Tot i això, tots tenen importants reptes operatius, així que vam triar la ruta CRD.
Es va utilitzar un controlador d'admissió mutacional per introduir sidecars, variables d'entorn i altres suports en temps d'execució. No obstant això, es va enfrontar a diversos problemes, com ara la vinculació de recursos i la gestió del cicle de vida, on aquests problemes no sorgeixen en CRD.
Nota: Els sistemes de plantilles com els gràfics Helm també s'utilitzen àmpliament per executar aplicacions amb configuracions similars. Tanmateix, les nostres aplicacions de treball són massa diverses per gestionar-les mitjançant plantilles. També durant el desplegament continu hi haurà massa errors en utilitzar plantilles.
Pròxima obra
Actualment estem tractant amb una càrrega mixta en tots els nostres clústers. Per donar suport a aquests processos de diferents tipus i mides, treballem en les àrees següents:
- Una col·lecció de clústers distribueix grans aplicacions entre diferents clústers per a l'escalabilitat i l'estabilitat.
- Assegurar l'estabilitat, l'escalabilitat i la visibilitat del clúster per crear connectivitat d'aplicacions i SLA.
- Gestionar recursos i quotes perquè les aplicacions no entren en conflicte entre si, i l'escala del clúster estigui controlada per la nostra part.
- Una nova plataforma CI/CD per donar suport i desplegar aplicacions a Kubernetes.
Font: www.habr.com