Een Kubernetes-platform creëren in Pinterest

In de jaren van zijn bestaan hebben 300 miljoen gebruikers van Pinterest meer dan 200 miljard pins gemaakt op meer dan 4 miljard borden. Om dit leger van gebruikers en de enorme contentbasis te bedienen, heeft het platform duizenden diensten ontwikkeld, van microservices die door een paar CPU's kunnen worden beheerd tot enorme monolithen die draaien op een hele reeks virtuele machines. En toen kwam het moment waarop het bedrijf zijn blik op k8s richtte. Wat vond 'Pinterest' zo aantrekkelijk aan de 'kubus'? Dit zult u ontdekken in onze vertaling van een recent artikel uit de blog van Pinterest engineering.

Dus, honderden miljoenen gebruikers en honderden miljard pins. Om dit leger van gebruikers en de uitgebreide contentbasis te bedienen, hebben we duizenden diensten ontwikkeld, van microservices die door een paar CPU's kunnen worden beheerd tot enorme monolithen die draaien op een hele reeks virtuele machines. Bovendien hebben we verschillende frameworks die ook CPU-resources, geheugen of toegang tot invoer- en uitvoerbewerkingen kunnen vereisen.

Tijdens het ondersteunen van deze zoo aan tools wordt het ontwikkelingsteam met een aantal problemen geconfronteerd:

• Ingenieurs hebben geen uniforme manier om een werkomgeving op te zetten. Stateless-services, Stateful-services en projecten die zich in actieve ontwikkeling bevinden, zijn gebaseerd op totaal verschillende technologie-stacks. Dit leidde tot de creatie van een hele training voor ingenieurs en maakt het werk van ons infrastructuurteam aanzienlijk gecompliceerder.
• Ontwikkelaars, die beschikken over hun eigen park van virtuele machines, creëren een enorme belasting voor de interne beheerders. Hierdoor kunnen zelfs eenvoudige operaties, zoals het updaten van het besturingssysteem of de AMI, zich uitstrekken over weken en maanden. Dit leidt tot een toename van de belasting in, schijnbaar, absoluut alledaagse situaties.
• Moeilijkheden bij het creëren van wereldwijde infrastructuurbeheertools bovenop bestaande oplossingen. De situatie wordt verder gecompliceerd door het feit dat het niet eenvoudig is om eigenaren van virtuele machines te vinden. Met andere woorden, we weten niet of we deze kracht veilig kunnen onttrekken voor gebruik op andere gebieden van onze infrastructuur.

Containerorkestratiesystemen zijn een manier om het beheer van workloads te uniformiseren. Ze bieden u de mogelijkheid om de snelheid van ontwikkeling te verhogen en vergemakkelijken het infrastructuurbeheer, omdat alle middelen die bij het project betrokken zijn, door één gecentraliseerd systeem worden beheerd.

Figuur 1: Prioriteiten van de infrastructuur (betrouwbaarheid, ontwikkelaarsprestaties en efficiëntie).

Het Cloud Management Platform-team bij Pinterest maakte in 2017 kennis met K8s. Tot in de eerste helft van 2017 documenteerden we een groot deel van onze productiecapaciteit, inclusief de API en al onze webservers. Daarna voerden we een grondige evaluatie uit van verschillende containerorkestratiesystemen, clusteropbouw en hoe ze te gebruiken. Tegen het einde van 2017 besloten we om Kubernetes te gebruiken. Het was voldoende flexibel en werd breed ondersteund binnen de ontwikkelaarsgemeenschap.

Tot nu toe hebben we onze eigen primaire clusterboot-tools gemaakt op basis van Kops en hebben we bestaande infrastructuurcomponenten zoals netwerken, beveiliging, monitoring, logging, identiteitsbeheer en verkeer overgezet naar Kubernetes. We hebben ook een werklastmodellering systeem geïmplementeerd voor onze resource, waarvan de complexiteit voor ontwikkelaars verborgen is. Momenteel zijn we gefocust op het waarborgen van de stabiliteit van het cluster, de schaalbaarheid en het aansluiten van nieuwe klanten.

Kubernetes: de weg van Pinterest

Het starten met Kubernetes op schaal bij Pinterest als een platform dat door onze engineers geliefd zal zijn, bracht vele uitdagingen met zich mee.

Als groot bedrijf hebben we aanzienlijke investeringen gedaan in infrastructuurtools. Een voorbeeld hiervan zijn de beveiligingstools die certificaten verwerken en sleutels distribueren, verkeerscontrolecomponenten, services Detectiesystemen, zichtbaarheidscomponenten en log- en metriekverzendcomponenten. Dit alles is niet zomaar bij elkaar gebracht: we hebben een normaal pad van proberen en falen doorlopen, en daarom wilden we al deze middelen integreren in de nieuwe infrastructuur op Kubernetes in plaats van het oude wiel opnieuw uit te vinden op een nieuw platform. Deze aanpak vergemakkelijkte de migratie, omdat alle applicatieondersteuning al bestaat en niet van nul af aan hoeft te worden opgebouwd.

Aan de andere kant zijn de modellen voor het voorspellen van belasting in Kubernetes (zoals deployments, jobs en Daemon sets) niet voldoende voor ons project. Deze gebruiksvriendelijkheidsproblemen vormen enorme obstakels voor de overstap naar Kubernetes. Zo hebben we gehoord dat ontwikkelaars van diensten klagen over het ontbreken of de verkeerde configuratie van een toegangsmechanisme. Ook kwamen we verkeerd gebruik van sjablonen tegen, waarbij honderden identieke kopieën met dezelfde specificatie en taak werden aangemaakt, wat leidde tot verschrikkelijke problemen bij het debuggen.

Het was ook erg moeilijk om verschillende versies in hetzelfde cluster te ondersteunen. Stel je de complexiteit voor van klantenondersteuning als je met meerdere versies van dezelfde uitvoeringomgeving moet werken, met al hun problemen, bugs en updates.

Aangepaste bronnen en controllers van Pinterest

Om het voor onze ingenieurs gemakkelijker te maken om Kubernetes in te voeren en om de infrastructuur te vereenvoudigen en te versnellen, hebben we onze eigen definities van aangepaste bronnen (CRD) ontwikkeld.

CRD biedt de volgende functionaliteiten:

1. Integratie van verschillende native Kubernetes-resources zodat ze als één belasting functioneren. Bijvoorbeeld, de PinterestService-resource omvat een deployment, een toegangsservice en een configuratiemap. Dit stelt ontwikkelaars in staat om zich geen zorgen te maken over de DNS-configuratie.
2. Invoering van de nodige applicatondersteuning. De gebruiker hoeft zich alleen te concentreren op de specificatie van de container volgens zijn bedrijfslogica, terwijl de CRD-controller alle benodigde init-containers, omgevingsvariabelen en pod-specificaties implementeert. Dit biedt een wezenlijk ander niveau van comfort voor ontwikkelaars.
3. CRD-controllers beheren ook de levenscyclus van hun eigen bronnen en verbeteren de beschikbaarheid van debugging. Dit omvat het afstemmen van gewenste en werkelijke specificaties, het bijwerken van de status van de CRD, en het loggen van gebeurtenissen en meer. Zonder CRD zouden ontwikkelaars gedwongen zijn om een groot aantal bronnen te beheren, wat de kans op fouten alleen maar verhoogde.

Hier is een voorbeeld van PinterestService en een interne resource die door onze controller wordt beheerd:

Zoals hierboven te zien is, moeten we voor de ondersteuning van de gebruikerscontainer deze integreren met een initiële container en verschillende toevoegingen om de veiligheid, zichtbaarheid en het werken met netwerkt verkeer te waarborgen. Daarnaast hebben we sjablonen voor configuratiekaarten gemaakt en ondersteuning voor PVC-sjablonen voor batchtaken geïmplementeerd, evenals het volgen van verschillende omgevingsvariabelen voor identificatie, resourcegebruik en 'garbage collection'.

Het is moeilijk voor te stellen dat ontwikkelaars deze configuratiebestanden handmatig willen schrijven zonder de ondersteuning van CRD, laat staan de verdere ondersteuning en debugging van configuraties.

Workflow voor implementatie van applicaties

De afbeelding hierboven toont hoe je een gebruikersbron van Pinterest in een Kubernetes-cluster kunt implementeren:

1. Ontwikkelaars hebben toegang tot ons Kubernetes-cluster via de CLI en de gebruikersinterface.
2. CLI-/UI-tools halen YAML-bestanden voor de configuratie van de workflow en andere bouwparameters (dezelfde versie-id) uit Artifactory, waarna ze deze naar de Job Submission Service sturen. Deze stap zorgt ervoor dat alleen werkende versies in het cluster worden geplaatst.
3. JSS fungeert als een gateway voor verschillende platforms, waaronder Kubernetes. Hier vindt de gebruikersauthenticatie plaats, wordt quota toegewezen en vindt gedeeltelijke controle van de configuratie van onze CRD plaats.
4. Na de controle van de CRD aan de JSS-zijde wordt de informatie naar de API van het k8s-platform gestuurd.
5. Onze CRD-controller houdt gebeurtenissen bij voor alle gebruikersbronnen. Hij transformeert CR naar native k8s-resources, voegt de noodzakelijke modules toe, stelt de juiste omgevingsvariabelen in en voert andere ondersteunende taken uit, waardoor voldoende infrastructuurondersteuning voor containergebaseerde gebruikersapplicaties wordt gegarandeerd.
6. Vervolgens stuurt de CRD-controller de verkregen gegevens naar de Kubernetes-API zodat ze door de planner kunnen worden verwerkt en in werking worden gesteld.

Opmerking: deze pre-release deployment workflow is gemaakt voor de eerste gebruikers van het nieuwe k8s-platform. Momenteel zijn we bezig dit proces verder te ontwikkelen om volledig te integreren met onze nieuwe CI/CD. Dit betekent dat we niet alles kunnen vertellen over Kubernetes. We kijken ernaar uit om onze ervaringen te delen en de voortgang van het team in deze richting te bespreken in onze volgende blogpost 'Building a CI/CD platform for Pinterest'.

Soorten speciale bronnen

Gezien de specifieke behoeften van Pinterest, hebben we de volgende CRD's ontwikkeld die geschikt zijn voor verschillende werkprocessen:

• PinterestService zijn al geruime tijd werkende stateless services. Veel van onze belangrijkste systemen zijn gebaseerd op een set van dergelijke services.
• PinterestJobSet modelleert batchtaken van de volledige cyclus. Bij Pinterest is er een algemene situatie waarbij meerdere taken dezelfde containers parallel uitvoeren, ongeacht andere soortgelijke processen.
• PinterestCronJob wordt veel gebruikt in combinatie met kleine periodieke workloads. Dit is een wrapper voor native cron-werking met ondersteuning mechanismen van Pinterest die verantwoordelijk zijn voor beveiliging, verkeer, logs en metrics.
• PinterestDaemon omvat de infrastructuur Daemons. Deze familie blijft groeien naarmate we steeds meer ondersteuning voor onze clusters toevoegen.
• PinterestTrainingJob strekt zich uit over Tensorflow en Pytorch processen, waarbij hetzelfde ondersteuningsniveau tijdens uitvoering wordt geboden als bij alle andere CRD's. Aangezien Pinterest actief gebruikmaakt van Tensorflow en andere machine learning systemen, hadden we reden om een aparte CRD rondom hen te bouwen.

We werken ook aan PinterestStatefulSet, die binnenkort zal worden aangepast voor gegevensopslag en andere stateful-systemen.

Ondersteuning voor de runtime-omgeving

Wanneer de applicatiemodule in Kubernetes wordt gestart, ontvangt deze automatisch een certificaat voor zelfidentificatie. Dit certificaat wordt gebruikt voor toegang tot de geheime opslag of voor communicatie met andere diensten via mTLS. Ondertussen zullen de containerinitialisatieconfigurator en Daemon alle benodigde afhankelijkheden laden voordat de containerapplicatie wordt gestart. Zodra alles klaar is, registreren de sidecar traffic en Daemon het IP-adres van de module in onze Zookeeper, zodat klanten deze kunnen ontdekken. Dit alles werkt omdat de netwerkmodule al vóór de applicatie-uitvoering was geconfigureerd.

Bovenstaande zijn typische voorbeelden van ondersteuning voor workloads tijdens de uitvoering. Voor andere types workloads kan iets andere ondersteuning nodig zijn, maar allemaal worden ze gepresenteerd in de vorm van pod-level sidecars, node-level of VM-level Daemons. We zorgen ervoor dat dit alles wordt uitgerold binnen de beheersinfrastructuur en gecoördineerd is tussen de applicaties, wat uiteindelijk de technische belasting en klantenondersteuning aanzienlijk vermindert.

Testen en QA

We hebben een end-to-end testpijplijn opgebouwd bovenop de al bestaande testinfrastructuur van Kubernetes. Deze tests zijn van toepassing op al onze clusters. Onze pijplijn heeft meerdere herzieningen ondergaan voordat deze onderdeel werd van het productcluster.

Naast de testsystemen hebben we monitoring- en alarmeringssystemen die voortdurend de status van de systeemcomponenten, hulpbronnenverbruik en andere belangrijke indicatoren volgen, en alleen bij de noodzaak voor menselijke tussenkomst alarm slaan.

Alternatieven

We hebben enkele alternatieven voor aangepaste bronnen overwogen, zoals mutatiewijze toewijzingscontrollers en sjabloonsystemen. Echter, al deze opties komen met aanzienlijke operationele uitdagingen, dus we hebben gekozen voor de CRD-route.

De mutatiewijze toewijzingscontroller werd gebruikt voor het invoeren van sidecars, omgevingsvariabelen en andere ondersteuningen tijdens de uitvoering. Echter, het had verschillende problemen, zoals het binden van hulpbronnen en het beheren van hun levenscyclus, terwijl deze problemen niet optreden bij CRD.

Opmerking: Sjablon systemen zoals Helm-diagrammen worden ook vaak gebruikt om applicaties met vergelijkbare configuraties te starten. Echter, onze operationele applicaties zijn te divers om met sjablonen te beheren. Daarnaast zullen er tijdens continue implementatie met sjablonen te veel fouten optreden.

Aankomende werkzaamheden

Momenteel hebben we te maken met een gemengde belasting op al onze clusters. Om dergelijke processen van verschillende types en groottes te ondersteunen, werken we in de volgende richtingen:

• Een verzameling clusters verspreidt grote applicaties over verschillende clusters voor schaalbaarheid en stabiliteit.
• Zorgen voor stabiliteit, schaalbaarheid en zichtbaarheid van de cluster om de verbinding tussen de applicatie en zijn SLA te creëren.
• Resource- en quotabeheer, zodat applicaties niet met elkaar conflicteren en de schaal van de cluster onder onze controle blijft.
• Een nieuw CI/CD-platform ter ondersteuning van de implementatie van applicaties in Kubernetes.

Bron: habr.com