Door de jaren heen hebben de 300 miljoen gebruikers van Pinterest meer dan 200 miljard pins gemaakt op meer dan 4 miljard borden. Om dit leger van gebruikers en deze enorme inhoudsbasis te bedienen, heeft de portal duizenden services ontwikkeld, variërend van microservices die door een paar CPU's kunnen worden afgehandeld, tot gigantische monolieten die op een hele vloot van virtuele machines draaien. En toen kwam het moment waarop de blik van het bedrijf op k8s viel. Waarom zag de ‘kubus’ er goed uit op Pinterest? U leert hierover uit onze vertaling van een recent artikel uit .
Dus honderden miljoenen gebruikers en honderden miljarden pinnen. Om dit leger van gebruikers en deze enorme inhoudsbasis te bedienen, hebben we duizenden diensten ontwikkeld, variërend van microdiensten die door een paar CPU's kunnen worden afgehandeld, tot gigantische monolieten die op hele groepen virtuele machines draaien. Daarnaast hebben we een verscheidenheid aan frameworks waarvoor mogelijk ook CPU-, geheugen- of I/O-toegang vereist is.
Bij het onderhouden van deze dierentuin vol tools staat het ontwikkelingsteam voor een aantal uitdagingen:
- Er bestaat geen uniforme manier waarop engineers een productieomgeving kunnen runnen. Stateless services, Stateful services en projecten die actief worden ontwikkeld, zijn gebaseerd op totaal verschillende technologieën. Dit heeft geleid tot de creatie van een volledige opleiding voor ingenieurs, en bemoeilijkt ook het werk van ons infrastructuurteam ernstig.
- Ontwikkelaars met hun eigen vloot virtuele machines zorgen voor een enorme last voor de interne beheerders. Als gevolg hiervan duren dergelijke eenvoudige handelingen, zoals het updaten van het besturingssysteem of AMI, weken en maanden. Dit leidt tot een verhoogde werkdruk in schijnbaar alledaagse situaties.
- Moeilijkheden bij het creëren van mondiale infrastructuurbeheertools bovenop bestaande oplossingen. De situatie wordt verder gecompliceerd door het feit dat het vinden van de eigenaren van virtuele machines niet eenvoudig is. Dat wil zeggen dat we niet weten of deze capaciteit veilig kan worden gewonnen om in andere delen van onze infrastructuur te opereren.
Containerorkestratiesystemen zijn een manier om het beheer van de werklast te verenigen. Ze openen de deur naar een hogere ontwikkelingssnelheid en vereenvoudigen het infrastructuurbeheer, omdat alle middelen die bij het project betrokken zijn, worden beheerd door één gecentraliseerd systeem.
Figuur 1: Infrastructuurprioriteiten (betrouwbaarheid, productiviteit van ontwikkelaars en efficiëntie).
Het Cloud Management Platform-team van Pinterest ontdekte K8s in 2017. In de eerste helft van 2017 hadden we de meeste van onze productiemogelijkheden gedocumenteerd, inclusief de API en al onze webservers. Daarna hebben we een grondige beoordeling uitgevoerd van verschillende systemen voor het orkestreren van containeroplossingen, het bouwen van clusters en het werken ermee. Eind 2017 hebben we besloten om Kubernetes in te zetten. Het was behoorlijk flexibel en werd breed ondersteund in de ontwikkelaarsgemeenschap.
Tot nu toe hebben we onze eigen cluster-boottools gebouwd op basis van Kops en bestaande infrastructuurcomponenten zoals netwerken, beveiliging, statistieken, logboekregistratie, identiteitsbeheer en verkeer naar Kubernetes gemigreerd. We hebben ook een werklastmodelleringssysteem voor onze resource geïmplementeerd, waarvan de complexiteit verborgen is voor ontwikkelaars. Nu richten we ons op het waarborgen van de stabiliteit van het cluster, het opschalen ervan en het verbinden van nieuwe klanten.
Kubernetes: de Pinterest-manier
Aan de slag gaan met Kubernetes op de schaal van Pinterest, een platform waar onze technici dol op zouden zijn, bracht veel uitdagingen met zich mee.
Als groot bedrijf hebben we zwaar geïnvesteerd in infrastructuurtools. Voorbeelden zijn onder meer beveiligingstools die certificaten en sleuteldistributie afhandelen, componenten voor verkeerscontrole, systemen voor servicedetectie, zichtbaarheidscomponenten en componenten voor de verzending van logboeken en statistieken. Dit alles werd met een reden verzameld: we volgden het normale pad van vallen en opstaan, en daarom wilden we al deze apparatuur integreren in de nieuwe infrastructuur op Kubernetes in plaats van het oude wiel opnieuw uit te vinden op een nieuw platform. Deze aanpak heeft de migratie over het algemeen vereenvoudigd, omdat alle applicatieondersteuning al bestaat en niet helemaal opnieuw hoeft te worden gemaakt.
Aan de andere kant zijn de modellen voor het voorspellen van de belasting in Kubernetes zelf (zoals implementaties, taken en Daemon-sets) niet voldoende voor ons project. Deze bruikbaarheidsproblemen vormen enorme barrières voor de overstap naar Kubernetes. We hebben bijvoorbeeld serviceontwikkelaars horen klagen over ontbrekende of onjuiste inloginstellingen. We kwamen ook onjuist gebruik van sjabloonengines tegen, waarbij honderden kopieën werden gemaakt met dezelfde specificatie en taak, wat resulteerde in nachtmerrieachtige foutopsporingsproblemen.
Het was ook erg moeilijk om verschillende versies in hetzelfde cluster te onderhouden. Stel je de complexiteit van de klantenondersteuning eens voor als je tegelijkertijd in meerdere versies van dezelfde runtime-omgeving moet werken, met al hun problemen, bugs en updates.
Pinterest-gebruikerseigenschappen en -controllers
Om het voor onze engineers gemakkelijker te maken om Kubernetes te implementeren en om onze infrastructuur te vereenvoudigen en te versnellen, hebben we onze eigen aangepaste resourcedefinities (CRD's) ontwikkeld.
CRD's bieden de volgende functionaliteit:
- Het combineren van verschillende native Kubernetes-resources, zodat ze als één workload werken. De PinterestService-bron omvat bijvoorbeeld een implementatie, een inlogservice en een configuratiekaart. Hierdoor hoeven ontwikkelaars zich geen zorgen te maken over het instellen van DNS.
- Implementeer de benodigde applicatieondersteuning. De gebruiker hoeft zich alleen te concentreren op de containerspecificatie volgens zijn bedrijfslogica, terwijl de CRD-controller alle noodzakelijke init-containers, omgevingsvariabelen en pod-specificaties implementeert. Dit biedt een fundamenteel ander niveau van comfort voor ontwikkelaars.
- CRD-controllers beheren ook de levenscyclus van systeemeigen bronnen en verbeteren de beschikbaarheid van foutopsporing. Dit omvat het afstemmen van gewenste en feitelijke specificaties, het bijwerken van de CRD-status en het bijhouden van gebeurtenislogboeken, en meer. Zonder CRD zouden ontwikkelaars gedwongen worden meerdere bronnen te beheren, wat de kans op fouten alleen maar zou vergroten.
Hier is een voorbeeld van een PinterestService en een interne bron die wordt beheerd door onze controller:
Zoals u hierboven kunt zien, moeten we, om een aangepaste container te ondersteunen, een init-container en verschillende add-ons integreren om beveiliging, zichtbaarheid en netwerkverkeer te bieden. Daarnaast hebben we sjablonen voor configuratiekaarten gemaakt en ondersteuning geïmplementeerd voor PVC-sjablonen voor batchtaken, evenals het volgen van meerdere omgevingsvariabelen om identiteit, resourceverbruik en afvalinzameling bij te houden.
Het is moeilijk voor te stellen dat ontwikkelaars deze configuratiebestanden met de hand zouden willen schrijven zonder CRD-ondersteuning, laat staan de configuraties verder zouden willen onderhouden en debuggen.
Werkstroom voor applicatie-implementatie
De afbeelding hierboven laat zien hoe je een aangepaste Pinterest-bron implementeert in een Kubernetes-cluster:
- Ontwikkelaars communiceren met ons Kubernetes-cluster via de CLI en de gebruikersinterface.
- De CLI/UI-tools halen de YAML-bestanden van de workflowconfiguratie en andere build-eigenschappen (dezelfde versie-ID) op van Artifactory en verzenden deze vervolgens naar de Job Submission Service. Deze stap zorgt ervoor dat alleen productieversies aan het cluster worden geleverd.
- JSS is een gateway voor verschillende platforms, waaronder Kubernetes. Hier wordt de gebruiker geauthenticeerd, worden quota uitgegeven en wordt de configuratie van onze CRD gedeeltelijk gecontroleerd.
- Nadat de CRD aan de JSS-zijde is gecontroleerd, wordt de informatie naar de k8s-platform-API verzonden.
- Onze CRD-controller bewaakt gebeurtenissen op alle gebruikersbronnen. Het converteert CR's naar native k8s-bronnen, voegt de benodigde modules toe, stelt de juiste omgevingsvariabelen in en voert ander ondersteunend werk uit om ervoor te zorgen dat gecontaineriseerde gebruikersapplicaties voldoende infrastructuurondersteuning hebben.
- De CRD-controller geeft de ontvangen gegevens vervolgens door aan de Kubernetes API, zodat deze door de planner kunnen worden verwerkt en in productie kunnen worden genomen.
Noot: Deze pre-release workflow van de implementatie is gemaakt voor de eerste gebruikers van het nieuwe k8s-platform. We zijn momenteel bezig dit proces te verfijnen, zodat het volledig kan worden geïntegreerd met onze nieuwe CI/CD. Dit betekent dat wij u niet alles kunnen vertellen wat met Kubernetes te maken heeft. We kijken ernaar uit om onze ervaringen en de voortgang van het team in deze richting te delen in onze volgende blogpost, “Bouw een CI/CD-platform voor Pinterest.”
Soorten speciale bronnen
Op basis van de specifieke behoeften van Pinterest hebben we de volgende CRD's ontwikkeld voor verschillende workflows:
- PinterestService zijn staatloze diensten die al heel lang actief zijn. Veel van onze kernsystemen zijn gebaseerd op een reeks van dergelijke diensten.
- PinterestJobSet modelleert batchtaken met een volledige cyclus. Een veel voorkomend scenario op Pinterest is dat meerdere taken dezelfde containers parallel uitvoeren, ongeacht andere vergelijkbare processen.
- PinterestCronJob wordt veel gebruikt in combinatie met kleine periodieke belastingen. Dit is een wrapper voor native cron-werk met Pinterest-ondersteuningsmechanismen die verantwoordelijk zijn voor beveiliging, verkeer, logs en statistieken.
- PinterestDaemon bevat infrastructuur-daemons. Deze familie blijft groeien naarmate we meer ondersteuning aan onze clusters toevoegen.
- PinterestTrainingJob strekt zich uit tot Tensorflow- en Pytorch-processen en biedt hetzelfde niveau van runtime-ondersteuning als alle andere CRD's. Omdat Pinterest actief gebruik maakt van Tensorflow en andere machine learning-systemen, hadden we een reden om er een aparte CRD omheen te bouwen.
We werken ook aan PinterestStatefulSet, dat binnenkort zal worden aangepast voor datawarehouses en andere stateful systemen.
Runtime-ondersteuning
Wanneer een applicatiepod op Kubernetes draait, ontvangt deze automatisch een certificaat om zichzelf te identificeren. Dit certificaat wordt gebruikt om toegang te krijgen tot geheime opslag of om via mTLS met andere diensten te communiceren. Ondertussen zullen de Container Init Configurator en Daemon alle benodigde afhankelijkheden downloaden voordat de containerapplicatie wordt uitgevoerd. Wanneer alles klaar is, registreren de verkeerszijspan en Daemon het IP-adres van de module bij onze Zookeeper, zodat klanten het kunnen ontdekken. Dit alles zal werken omdat de netwerkmodule is geconfigureerd voordat de applicatie werd gestart.
Bovenstaande zijn typische voorbeelden van runtime-ondersteuning voor workloads. Andere soorten werkbelastingen vereisen mogelijk iets andere ondersteuning, maar ze komen allemaal in de vorm van zijspannen op podniveau, Daemons op knooppuntniveau of virtuele machineniveau. Wij zorgen ervoor dat dit allemaal binnen de beheerinfrastructuur wordt geïmplementeerd en consistent is tussen alle applicaties, wat uiteindelijk de lasten op het gebied van technisch werk en klantenondersteuning aanzienlijk vermindert.
Testen en kwaliteitscontrole
We hebben een end-to-end testpijplijn gebouwd bovenop de bestaande Kubernetes-testinfrastructuur. Deze tests zijn van toepassing op al onze clusters. Onze pijplijn heeft vele herzieningen ondergaan voordat deze onderdeel werd van het productcluster.
Naast het testen van systemen beschikken we over monitoring- en waarschuwingssystemen die voortdurend de status van systeemcomponenten, het verbruik van hulpbronnen en andere belangrijke indicatoren monitoren en ons alleen op de hoogte stellen wanneer menselijke tussenkomst noodzakelijk is.
alternatieven
We hebben gekeken naar enkele alternatieven voor aangepaste bronnen, zoals mutatietoegangscontrollers en sjabloonsystemen. Ze brengen echter allemaal aanzienlijke operationele uitdagingen met zich mee, dus kozen we voor de CRD-route.
Er werd een mutatie-toegangscontroller gebruikt om zijspannen, omgevingsvariabelen en andere runtime-ondersteuning te introduceren. Het werd echter geconfronteerd met verschillende problemen, zoals het binden van hulpbronnen en het beheer van de levenscyclus, waar dergelijke problemen zich niet voordoen bij CRD.
Opmerking: Sjabloonsystemen zoals Helm-diagrammen worden ook veel gebruikt om applicaties met vergelijkbare configuraties uit te voeren. Onze werkapplicaties zijn echter te divers om met templates te kunnen beheren. Ook tijdens continue implementatie zullen er te veel fouten optreden bij het gebruik van sjablonen.
Aankomend werk
Momenteel hebben we te maken met een gemengde belasting van al onze clusters. Om dergelijke processen van verschillende soorten en maten te ondersteunen, werken wij op de volgende gebieden:
- Een verzameling clusters distribueert grote applicaties over verschillende clusters voor schaalbaarheid en stabiliteit.
- Zorgen voor clusterstabiliteit, schaalbaarheid en zichtbaarheid om applicatieconnectiviteit en de bijbehorende SLA te creëren.
- Het beheren van bronnen en quota zodat applicaties niet met elkaar conflicteren, en de schaal van het cluster van onze kant wordt gecontroleerd.
- Een nieuw CI/CD-platform voor het ondersteunen en inzetten van applicaties op Kubernetes.
Bron: www.habr.com