Het rapport is gewijd aan praktische kwesties bij het ontwikkelen van een operator in Kubernetes, het ontwerpen van de architectuur en de basisprincipes ervan.
In het eerste deel van het rapport gaan we in op:
- wat is een operator in Kubernetes en waarom is deze nodig;
- hoe de operator precies het beheer van complexe systemen vereenvoudigt;
- wat de operator wel en niet kan doen.
Laten we vervolgens verder gaan met het bespreken van de interne structuur van de operator. Laten we stap voor stap de architectuur en werking van de operator bekijken. Laten we het in detail bekijken:
- interactie tussen de operator en Kubernetes;
- welke functies de operator op zich neemt en welke functies hij delegeert aan Kubernetes.
Laten we eens kijken naar het beheren van shards en databasereplica's in Kubernetes.
Vervolgens bespreken we problemen met gegevensopslag:
- hoe je met Persistent Storage kunt werken vanuit het perspectief van een operator;
- valkuilen bij het gebruik van lokale opslag.
In het laatste deel van het rapport zullen we praktische voorbeelden van toepassingen bekijken met Amazon of Google Cloud Service. Het rapport is gebaseerd op het voorbeeld van de ontwikkelings- en operationele ervaring van een operator voor ClickHouse.
Video:
Mijn naam is Vladislav Klimenko. Vandaag wilde ik het hebben over onze ervaring met het ontwikkelen en exploiteren van een operator, en dit is een gespecialiseerde operator voor het beheer van databaseclusters. Bijvoorbeeld om het ClickHouse-cluster te beheren.
Waarom hebben we de mogelijkheid om over de operator en ClickHouse te praten?
- Wij ondersteunen en ontwikkelen ClickHouse.
- Op dit moment proberen wij langzaam onze bijdrage te leveren aan de ontwikkeling van ClickHouse. En we staan op de tweede plaats na Yandex wat betreft het aantal wijzigingen dat in ClickHouse is aangebracht.
- We proberen aanvullende projecten uit te voeren voor het ClickHouse-ecosysteem.
Over één van deze projecten wil ik u graag vertellen. Dit gaat over ClickHouse-operator voor Kubernetes.
In mijn rapport wil ik twee onderwerpen aansnijden:
- Het eerste onderwerp is hoe onze ClickHouse-databasebeheeroperator werkt in Kubernetes.
- Het tweede onderwerp is hoe elke operator werkt, dat wil zeggen hoe deze samenwerkt met Kubernetes.
Deze twee vragen zullen elkaar echter in mijn verslag kruisen.
Wie zou willen luisteren naar wat ik probeer te vertellen?
- Het zal van het grootste belang zijn voor degenen die exploitanten exploiteren.
- Of voor degenen die er zelf een willen maken om te begrijpen hoe het intern werkt, hoe de operator met Kubernetes omgaat en welke valkuilen zich kunnen voordoen.
Om zo goed mogelijk te begrijpen wat we vandaag gaan bespreken, is het een goed idee om te weten hoe Kubernetes werkt en wat basistraining in de cloud te volgen.
Wat is ClickHouse? Dit is een zuilvormige database met specifieke functionaliteiten voor het online verwerken van analytische queries. En het is volledig open source.
En het is belangrijk dat we slechts twee dingen weten. Je moet weten dat dit een database is, dus wat ik je zal vertellen zal op vrijwel elke database van toepassing zijn. En het feit dat het ClickHouse DBMS zeer goed schaalbaar is, geeft een vrijwel lineaire schaalbaarheid. En daarom is de clusterstatus een natuurlijke staat voor ClickHouse. En we zijn het meest geïnteresseerd in het bespreken van de manier waarop we het ClickHouse-cluster in Kubernetes kunnen bedienen.
Waarom is hij daar nodig? Waarom kunnen we het niet zelf blijven exploiteren? En de antwoorden zijn deels technisch en deels organisatorisch.
- In de praktijk komen we steeds vaker een situatie tegen waarbij bij grote bedrijven vrijwel alle componenten al in Kubernetes staan. Databases blijven buiten.
- En steeds vaker wordt de vraag gesteld: “Kan dit binnen geplaatst worden?” Daarom proberen grote bedrijven maximale unificatie van beheer te bereiken om hun datawarehouses snel te kunnen beheren.
- En dit helpt vooral als je de maximale mogelijkheid nodig hebt om hetzelfde op een nieuwe plek te herhalen, d.w.z. maximale draagbaarheid.
Hoe gemakkelijk of moeilijk is het? Dit kan uiteraard met de hand worden gedaan. Maar het is niet zo eenvoudig, omdat we de extra complexiteit hebben van het beheren van Kubernetes zelf, maar tegelijkertijd worden de specifieke kenmerken van ClickHouse over elkaar heen gelegd. En zo'n aggregatie resulteert.
En alles bij elkaar levert dit een vrij grote reeks technologieën op, die behoorlijk moeilijk te beheren worden, omdat Kubernetes zijn eigen alledaagse problemen met zich meebrengt, en ClickHouse zijn eigen problemen met de dagelijkse werking. Zeker als we meerdere ClickHouses hebben, en daar constant iets mee moeten doen.
Met een dynamische configuratie heeft ClickHouse een vrij groot aantal problemen die een constante belasting van DevOps veroorzaken:
- Wanneer we iets willen veranderen in ClickHouse, bijvoorbeeld een replica of shard willen toevoegen, dan moeten we de configuratie beheren.
- Wijzig vervolgens het gegevensschema, omdat ClickHouse een specifieke sharding-methode heeft. Daar moet u het gegevensdiagram opmaken, de configuraties opmaken.
- U moet monitoring instellen.
- Logboeken verzamelen voor nieuwe scherven, voor nieuwe replica's.
- Zorg voor restauratie.
- En opnieuw opstarten.
Dit zijn routinetaken die ik heel graag gemakkelijker in het gebruik zou willen maken.
Kubernetes zelf helpt goed bij het gebruik, maar dan op basissysteemzaken.
Kubernetes is goed in het faciliteren en automatiseren van zaken als:
- Recovery.
- Herstarten.
- Beheer van opslagsystemen.
Dat is goed, dat is de goede richting, maar hij heeft totaal geen idee hoe hij een databasecluster moet bedienen.
We willen meer, we willen dat de hele database in Kubernetes werkt.
Ik zou graag zoiets willen als een grote magische rode knop die je indrukt en een cluster met alledaagse taken die moeten worden opgelost, wordt gedurende de hele levenscyclus ingezet en onderhouden. ClickHouse-cluster in Kubernetes.
En we probeerden een oplossing te bedenken die het werk gemakkelijker zou maken. Dit is een ClickHouse-operator voor Kubernetes van Altinity.
Een operator is een programma waarvan de hoofdtaak het beheren van andere programma's is, dat wil zeggen dat het een manager is.
En het bevat gedragspatronen. Je kunt dit gecodificeerde kennis over het vakgebied noemen.
En zijn belangrijkste taak is om het leven van DevOps gemakkelijker te maken en micromanagement te verminderen, zodat hij (DevOps) al op hoog niveau denkt, dat wil zeggen, zodat hij (DevOps) zich niet bezighoudt met micromanagement, zodat hij niet configureert alle details handmatig.
En alleen de operator is een robotassistent die zich bezighoudt met microtaken en DevOps helpt.
Waarom heb je een operator nodig? Hij presteert bijzonder goed op twee gebieden:
- Wanneer de specialist die met ClickHouse te maken heeft niet voldoende ervaring heeft, maar ClickHouse al moet bedienen, faciliteert de operator de bediening en kunt u een ClickHouse-cluster bedienen met een vrij complexe configuratie, zonder al te veel in detail te treden over hoe het allemaal werkt binnen. Je geeft hem gewoon taken op hoog niveau, en het werkt.
- En de tweede taak waarin het het beste presteert, is wanneer het nodig is een groot aantal typische taken te automatiseren. Verwijdert microtaken van systeembeheerders.
Dit is het meest nodig door degenen die net aan hun reis zijn begonnen, of door degenen die veel automatisering moeten doen.
Waarin verschilt de operatorgebaseerde aanpak van andere systemen? Er is Helm. Het helpt ook om ClickHouse te installeren; u kunt stuurkaarten tekenen, waarmee u zelfs een heel ClickHouse-cluster kunt installeren. Wat is dan het verschil tussen de operator en dezelfde, bijvoorbeeld Helm?
Het belangrijkste fundamentele verschil is dat Helm pakketbeheer is en Operator een stap verder gaat. Dit is ondersteuning voor de gehele levenscyclus. Dit is niet alleen de installatie, dit zijn dagelijkse taken die onder meer schalen en sharden omvatten, dat wil zeggen alles wat tijdens de levenscyclus moet worden gedaan (indien nodig, en vervolgens ook verwijderen) - dit wordt allemaal beslist door de operator. Het probeert de gehele softwarelevenscyclus te automatiseren en te onderhouden. Dit is het fundamentele verschil met andere oplossingen die worden gepresenteerd.
Dat was het inleidende gedeelte, laten we verder gaan.
Hoe bouwen we onze operator? We proberen het probleem aan te pakken door het ClickHouse-cluster als één enkele bron te beheren.
Hier hebben we invoergegevens aan de linkerkant van de afbeelding. Dit is YAML met een clusterspecificatie, die op klassieke wijze via kubectl aan Kubernetes wordt doorgegeven. Daar pikt onze operator het op en doet zijn magie. En aan de uitgang krijgen we het volgende schema. Dit is een implementatie van ClickHouse in Kubernetes.
En dan zullen we langzaam kijken hoe de operator precies werkt, welke typische taken kunnen worden opgelost. We zullen alleen typische taken overwegen omdat we beperkte tijd hebben. En niet alles wat de operator kan beslissen, wordt besproken.
Laten we beginnen vanuit de praktijk. Ons project is volledig open source, dus je kunt zien hoe het werkt op GitHub. En u kunt uitgaan van de overweging dat als u het gewoon wilt starten, u kunt beginnen met de snelstartgids.
Als je het in detail wilt begrijpen, proberen we de documentatie in een min of meer fatsoenlijke vorm bij te houden.
Laten we beginnen met een praktisch probleem. De eerste taak, waarmee we allemaal willen beginnen, is om het eerste voorbeeld op de een of andere manier uit te voeren. Hoe kan ik ClickHouse starten met behulp van de operator, zelfs als ik niet echt weet hoe het werkt? Wij schrijven een manifest, omdat... Alle communicatie met k8s is communicatie via manifesten.
Dit is zo'n complex manifest. Wat we rood hebben gemarkeerd, is waar we ons op moeten concentreren. We vragen de operator om een cluster met de naam demo te maken.
Dit zijn voor nu eenvoudige voorbeelden. Opslag is nog niet beschreven, maar op opslag komen we later terug. Voorlopig zullen we de dynamiek van de ontwikkeling van het cluster observeren.
Wij hebben dit manifest gemaakt. Wij geven het door aan onze operator. Hij werkte, hij maakte magie.
We kijken naar de console. Drie componenten zijn van belang: een Pod, twee Services en een StatefulSet.
De operator heeft gewerkt en we kunnen zien wat hij precies heeft gemaakt.
Hij creëert zoiets als dit. We hebben een StatefulSet, Pod, ConfigMap voor elke replica, ConfigMap voor het hele cluster. Services zijn vereist als toegangspunten tot het cluster.
Services vormen de centrale Load Balancer Service en kunnen ook voor elke replica, voor elke shard, worden gebruikt.
Ons basiscluster ziet er ongeveer zo uit. Het komt uit één enkel knooppunt.
Laten we verder gaan en de zaken ingewikkelder maken. We moeten het cluster vernietigen.
Onze taken groeien, de dynamiek begint. We willen een scherf toevoegen. Wij volgen de ontwikkeling. We veranderen onze specificatie. Wij geven aan dat we twee scherven willen.
Dit is hetzelfde bestand dat zich dynamisch ontwikkelt met de groei van het systeem. Opslag nee, opslag wordt verder besproken, dit is een apart onderwerp.
We voeden de YAML-operator en kijken wat er gebeurt.
De operator bedacht en maakte de volgende entiteiten. We hebben al twee Pods, drie Services en plotseling twee StatefulSets. Waarom twee StatefulSets?
Op het diagram zag het er zo uit: dit is onze oorspronkelijke toestand, toen we nog één capsule hadden.
Het werd zo. Tot nu toe is alles eenvoudig, het is gedupliceerd.
En waarom zijn er twee StatefulSets ontstaan? Hier moeten we afdwalen en de vraag bespreken hoe Pods worden beheerd in Kubernetes.
Er is een object met de naam StatefulSet waarmee u een set Pods kunt maken op basis van een sjabloon. De belangrijkste factor hier is Sjabloon. En u kunt veel Pods starten met één sjabloon in één StatefulSet. En de sleutelzin hier is ‘veel pods voor één sjabloon’.
En de verleiding was groot om het hele cluster te maken en in één StatefulSet te stoppen. Het zal werken, er is geen probleem mee. Maar er is één kanttekening. Als we een heterogeen cluster willen samenstellen, dat wil zeggen uit verschillende versies van ClickHouse, dan beginnen er vragen te rijzen. Ja, StatefulSet kan een rolling update doen, en daar kun je een nieuwe versie uitrollen, leg uit dat je niet meer dan zoveel knooppunten tegelijk hoeft te proberen.
Maar als we de taak extrapoleren en zeggen dat we een volledig heterogeen cluster willen maken en niet willen overstappen van de oude versie naar een nieuwe met behulp van een rolling update, maar we willen eenvoudigweg een heterogeen cluster creëren, zowel in termen van van verschillende versies van ClickHouse en in termen van verschillende opslag. We willen bijvoorbeeld enkele replica's maken op afzonderlijke schijven, in het algemeen op langzame schijven, om een volledig heterogeen cluster te bouwen. En omdat StatefulSet vanuit één template een gestandaardiseerde oplossing maakt, is er geen manier om dit te doen.
Na enig nadenken werd besloten dat we het op deze manier zouden doen. We hebben elke replica in zijn eigen StatefulSet. Er kleven enkele nadelen aan deze oplossing, maar in de praktijk wordt deze allemaal volledig ingekapseld door de operator. En er zijn veel voordelen. We kunnen precies het cluster bouwen dat we willen, bijvoorbeeld een absoluut heterogeen cluster. Daarom zullen we in een cluster waarin we twee shards met één replica hebben, 2 StatefulSets en 2 Pods hebben, juist omdat we deze aanpak hebben gekozen om de hierboven genoemde redenen om een heterogeen cluster te kunnen bouwen.
Laten we terugkeren naar de praktische problemen. In ons cluster moeten we gebruikers configureren, d.w.z. u moet een configuratie van ClickHouse in Kubernetes uitvoeren. De operator biedt hiervoor alle mogelijkheden.
We kunnen rechtstreeks in YAML schrijven wat we willen. Alle configuratieopties worden rechtstreeks vanuit deze YAML toegewezen aan ClickHouse-configuraties, die vervolgens door het cluster worden gedistribueerd.
Je kunt het zo schrijven. Dit is bijvoorbeeld. Het wachtwoord kan worden gecodeerd. Absoluut alle ClickHouse-configuratieopties worden ondersteund. Hier is slechts een voorbeeld.
De clusterconfiguratie wordt gedistribueerd als een ConfigMap. In de praktijk vindt de ConfigMap-update niet onmiddellijk plaats, dus als het cluster groot is, duurt het proces van het pushen van de configuratie enige tijd. Maar dit alles is erg handig in gebruik.
Laten we de taak ingewikkelder maken. Het cluster is in ontwikkeling. We willen gegevens repliceren. Dat wil zeggen dat we al twee shards hebben, elk één replica, en dat gebruikers zijn geconfigureerd. We groeien en willen replicatie doen.
Wat hebben we nodig voor replicatie?
We hebben ZooKeeper nodig. In ClickHouse wordt replicatie gebouwd met behulp van ZooKeeper. ZooKeeper is nodig zodat verschillende ClickHouse-replica's consensus hebben over welke datablokken op welke ClickHouse staan.
ZooKeeper kan door iedereen worden gebruikt. Als de onderneming een externe ZooKeeper heeft, kan deze worden gebruikt. Als dit niet het geval is, kunt u het vanuit onze repository installeren. Er is een installatieprogramma dat dit hele ding eenvoudiger maakt.
En het interactiediagram van het hele systeem ziet er zo uit. Wij hebben Kubernetes als platform. Het voert de ClickHouse-operator uit. Ik stelde ZooKeeper hier voor. En de operator communiceert met zowel ClickHouse als ZooKeeper. Dat wil zeggen: interactieresultaten.
En dit alles is nodig voor ClickHouse om gegevens met succes in k8s te repliceren.
Laten we nu eens kijken naar de taak zelf, hoe het manifest voor replicatie eruit zal zien.
We voegen twee secties toe aan ons manifest. De eerste is waar je ZooKeeper kunt krijgen, zowel binnen Kubernetes als extern. Dit is slechts een beschrijving. En we bestellen replica's. Die. we willen twee replica's. In totaal zouden we 4 pods aan de uitgang moeten hebben. We herinneren ons de opslag, deze komt iets later terug. Opslag is een apart verhaal.
Het was zo.
Het wordt zo. Replica's worden toegevoegd. De 4e paste niet, wij denken dat er daar veel van zouden kunnen zijn. En ZooKeeper is aan de zijkant toegevoegd. De regelingen worden steeds complexer.
En het is tijd om de volgende taak toe te voegen. We zullen persistente opslag toevoegen.
Voor Persistent Storage hebben wij diverse mogelijkheden.
Als we bij een cloudprovider werken, bijvoorbeeld met Amazon, Google, dan is de verleiding groot om cloudopslag te gebruiken. Het is erg handig, het is goed.
En er is een tweede optie. Dit is voor lokale opslag, wanneer we op elk knooppunt lokale schijven hebben. Deze optie is veel moeilijker te implementeren, maar tegelijkertijd productiever.
Laten we eens kijken wat we hebben met betrekking tot cloudopslag.
Er zijn voordelen. Het is heel eenvoudig te configureren. We bestellen eenvoudigweg bij de cloudprovider die ons alstublieft opslag geeft van die en die capaciteit, van die en die klasse. De lessen worden onafhankelijk door de aanbieders gepland.
En er is een nadeel. Voor sommigen is dit een niet-kritisch nadeel. Natuurlijk zullen er enkele prestatieproblemen zijn. Het is erg handig in gebruik en betrouwbaar, maar er zijn enkele potentiële prestatienadelen.
En omdat ClickHouse richt zich specifiek op productiviteit, je zou zelfs kunnen zeggen dat het alles eruit haalt wat mogelijk is, en daarom proberen veel klanten maximale productiviteit eruit te persen.
En om er het maximale uit te halen, hebben we lokale opslag nodig.
Kubernetes biedt drie abstracties voor het gebruik van lokale opslag in Kubernetes. Dit:
- LeegDir
- HostPath.
- Lokale
Laten we eens kijken hoe ze verschillen en hoe ze op elkaar lijken.
Ten eerste hebben we bij alle drie de benaderingen opslag: dit zijn lokale schijven die zich op hetzelfde fysieke k8s-knooppunt bevinden. Maar ze hebben enkele verschillen.
Laten we beginnen met de eenvoudigste, namelijk emptyDir. Wat is dit in de praktijk? In onze specificatie vragen we het containerisatiesysteem (meestal Docker) om ons toegang te geven tot een map op de lokale schijf.
In de praktijk maakt Docker ergens langs zijn eigen paden een tijdelijke map aan en noemt deze een lange hash. En biedt een interface om er toegang toe te krijgen.
Hoe zal dit qua prestaties werken? Dit werkt op lokale schijfsnelheid, d.w.z. Dit is volledige toegang tot uw schroef.
Maar deze zaak heeft zijn keerzijde. Persistent is in deze kwestie nogal twijfelachtig. De eerste keer dat Docker met containers beweegt, gaat Persistent verloren. Als Kubernetes deze Pod om wat voor reden dan ook naar een andere schijf wil verplaatsen, gaan de gegevens verloren.
Deze aanpak is goed voor tests, omdat deze al een normale snelheid laat zien, maar voor iets serieus is deze optie niet geschikt.
Daarom is er een tweede benadering. Dit is hostPath. Als je naar de vorige dia en deze kijkt, zie je maar één verschil. Onze map is rechtstreeks van Docker naar het Kubernetes-knooppunt verplaatst. Hier is het iets eenvoudiger. We specificeren rechtstreeks het pad op het lokale bestandssysteem waar we onze gegevens willen opslaan.
Deze methode heeft voordelen. Dit is al een echte Persistent, en bovendien een klassieker. We zullen op een bepaald adres de gegevens op de schijf laten vastleggen.
Er zijn ook nadelen. Dit is de complexiteit van management. Onze Kubernetes willen de Pod mogelijk naar een ander fysiek knooppunt verplaatsen. En dit is waar DevOps in het spel komt. Hij moet het hele systeem correct uitleggen dat deze pods alleen kunnen worden verplaatst naar die knooppunten waarop je iets langs deze paden hebt gemonteerd, en niet meer dan één knooppunt tegelijk. Het is best moeilijk.
Speciaal voor deze doeleinden hebben we sjablonen in onze operator gemaakt om al deze complexiteit te verbergen. En je zou eenvoudigweg kunnen zeggen: “Ik wil één exemplaar van ClickHouse hebben voor elk fysiek knooppunt en langs dit en dat pad.”
Maar wij zijn niet de enigen die deze behoefte nodig hebben, dus de heren van Kubernetes zelf begrijpen ook dat mensen toegang willen hebben tot fysieke schijven, dus zorgen ze voor een derde laag.
Lokaal heet dat. Er is vrijwel geen verschil met de vorige dia. Alleen voorheen was het nodig om handmatig te bevestigen dat we deze pods niet van knooppunt naar knooppunt kunnen overbrengen, omdat ze langs een bepaald pad aan een lokale fysieke schijf moeten worden gekoppeld, maar nu is al deze kennis ingekapseld in Kubernetes zelf. En het blijkt veel eenvoudiger te configureren.
Laten we terugkeren naar ons praktische probleem. Laten we terugkeren naar de YAML-sjabloon. Hier hebben we echte opslagruimte. We zijn er weer mee bezig. We hebben de klassieke VolumeClaim-sjabloon ingesteld zoals in k8s. En we beschrijven wat voor soort opslag we willen.
Hierna zal k8s om opslag vragen. Zal het aan ons toewijzen in de StatefulSet. En uiteindelijk komt het ter beschikking van ClickHouse.
Wij hadden dit schema. Onze persistente opslag was rood, wat erop leek te duiden dat dit moest gebeuren.
En het wordt groen. Nu is het ClickHouse op k8s-clusterschema volledig afgerond. We hebben scherven, replica's, ZooKeeper, we hebben een echte Persistent, die op de een of andere manier wordt geïmplementeerd. De regeling is al volledig operationeel.
Wij blijven voortleven. Ons cluster is in ontwikkeling. En Alexey probeert het en brengt een nieuwe versie van ClickHouse uit.
Er doet zich een praktische taak voor: het testen van de nieuwe versie van ClickHouse op ons cluster. En je wilt natuurlijk niet alles uitrollen; je wilt een nieuwe versie in één replica ergens in de verre hoek stoppen, en misschien niet één nieuwe versie, maar twee tegelijk, omdat ze vaak verschijnen.
Wat kunnen we hierover zeggen?
Hier hebben we precies zo'n kans. Dit zijn pod-sjablonen. U kunt schrijven dat onze operator u volledig in staat stelt een heterogeen cluster te bouwen. Die. configureren, beginnend bij alle replica's in een groep, eindigend met elke persoonlijke replica, welke versie we ClickHouse willen, welke versie we opslag willen. We kunnen het cluster volledig configureren met de configuratie die we nodig hebben.
Laten we wat dieper naar binnen gaan. Hiervoor hebben we gesproken over hoe de ClickHouse-operator werkt in relatie tot de specifieke kenmerken van ClickHouse.
Nu zou ik een paar woorden willen zeggen over hoe een operator in het algemeen werkt, en hoe deze samenwerkt met K8's.
Laten we eerst kijken naar de interactie met de K8's. Wat gebeurt er als we kubectl toepassen? Onze objecten verschijnen in etcd via de API.
Bijvoorbeeld basis Kubernetes-objecten: pod, StatefulSet, service, enzovoort in de lijst.
Tegelijkertijd gebeurt er nog niets fysieks. Deze objecten moeten in het cluster worden gerealiseerd.
Hiervoor verschijnt een controller. De controller is een speciaal k8s-onderdeel dat deze beschrijvingen kan verwezenlijken. Hij weet hoe en wat hij fysiek moet doen. Hij weet hoe hij containers moet draaien en wat daar moet worden geconfigureerd om de server te laten werken.
En het materialiseert onze objecten in K8s.
Maar we willen niet alleen met pods en StatefulSets werken, we willen een ClickHouseInstallation creëren, d.w.z. een object van het type ClickHouse, om er als één geheel mee te kunnen werken. Tot nu toe bestaat een dergelijke mogelijkheid niet.
Maar K8s heeft het volgende leuke ding. We willen dat we ergens een complexe entiteit hebben waarin ons cluster zou worden samengesteld uit pods en StatefulSet.
En wat moet hiervoor gedaan worden? Ten eerste komt de aangepaste resourcedefinitie in beeld. Wat het is? Dit is een beschrijving voor K8s, dat je nog een gegevenstype zult hebben, dat we een aangepaste bron willen toevoegen aan de pod, StatefulSet, die van binnen complex zal zijn. Dit is een beschrijving van de datastructuur.
We sturen het daar ook naartoe via kubectl apply. Kubernetes nam het graag aan.
En nu heeft het object in etcd in onze opslag de mogelijkheid om een aangepaste bron op te nemen met de naam ClickHouseInstallation.
Maar voorlopig zal er verder niets gebeuren. Dat wil zeggen, als we nu het YAML-bestand maken waar we naar hebben gekeken, waarin shards en replica's worden beschreven en 'kubectl apply' zeggen, dan zal Kubernetes het accepteren, het in etcd plaatsen en zeggen: 'Geweldig, maar ik weet niet wat ik moet doen ermee. Ik weet niet hoe ik ClickHouseInstallation moet onderhouden.'
Daarom hebben we iemand nodig die Kubernetes helpt het nieuwe gegevenstype te bedienen. Aan de linkerkant hebben we een native Kubernetes-controller die werkt met native datatypen. En aan de rechterkant zouden we een aangepaste controller moeten hebben die met aangepaste gegevenstypen kan werken.
En op een andere manier wordt het een operator genoemd. Ik heb het hier specifiek opgenomen als Kubernetes, omdat het ook buiten K8s uitgevoerd kan worden. Meestal worden natuurlijk alle operators in Kubernetes uitgevoerd, maar niets verhindert dat het buiten staat, dus hier wordt het speciaal naar buiten verplaatst.
En op zijn beurt communiceert de aangepaste controller, ook wel de operator genoemd, via de API met Kubernetes. Het weet al hoe het met de API moet omgaan. En hij weet al hoe hij het complexe circuit dat we willen maken op basis van een aangepaste bron, moet materialiseren. Dit is precies wat de operator doet.
Hoe gaat de operator te werk? Laten we naar de rechterkant kijken om te zien hoe hij het doet. Laten we eens kijken hoe de operator dit allemaal materialiseert en hoe verdere interactie met K8's plaatsvindt.
Een operator is een programma. Ze is evenementengericht. De operator abonneert zich op evenementen met behulp van de Kubernetes API. De Kubernetes API heeft toegangspunten waar u zich kunt abonneren op evenementen. En als er iets verandert in K8s, stuurt Kubernetes gebeurtenissen naar iedereen, d.w.z. degene die zich op dit API-punt heeft geabonneerd, ontvangt meldingen.
De operator abonneert zich op evenementen en moet een reactie maken. Het is zijn taak om te reageren op opkomende gebeurtenissen.
Gebeurtenissen worden gegenereerd door bepaalde updates. Ons YAML-bestand met een beschrijving van ClickHouseInstallation arriveert. Hij ging naar etcd via kubectl apply. Daar werd een gebeurtenis geactiveerd en als gevolg daarvan kwam deze gebeurtenis bij de ClickHouse-operator terecht. De telefoniste heeft deze beschrijving ontvangen. En hij moet iets doen. Als er een update is ontvangen voor het ClickHouseInstallation-object, moet u het cluster bijwerken. En de taak van de operator is om het cluster bij te werken.
Wat is hij aan het doen? Eerst moeten we een actieplan opstellen voor wat we met deze update gaan doen. Updates kunnen zeer klein zijn, d.w.z. klein in YAML-uitvoering, maar kan zeer grote veranderingen in het cluster met zich meebrengen. Daarom maakt de operator een plan, en houdt zich daar vervolgens aan.
Volgens dit plan begint hij deze structuur binnenin te koken om peulen, diensten, d.w.z. te materialiseren. doen wat zijn hoofdtaak is. Zo bouwt u een ClickHouse-cluster in Kubernetes.
Laten we nu iets interessants bespreken. Dit is een verantwoordelijkheidsverdeling tussen Kubernetes en de operator, d.w.z. wat Kubernetes doet, wat de operator doet en hoe ze met elkaar omgaan.
Kubernetes is verantwoordelijk voor systeemzaken, d.w.z. voor een basisset objecten die kunnen worden geïnterpreteerd als systeemscope. Kubernetes weet hoe hij pods moet starten, hoe hij containers moet herstarten, hoe hij volumes moet mounten, hoe hij met ConfigMap moet werken, d.w.z. alles wat een systeem genoemd kan worden.
Operators opereren in domeinen. Elke operator is gemaakt voor zijn eigen vakgebied. Wij deden het voor ClickHouse.
En de operator handelt precies vakinhoudelijk, zoals het toevoegen van een replica, het maken van een diagram, het inrichten van monitoring. Dit resulteert in een verdeeldheid.
Laten we eens kijken naar een praktisch voorbeeld van hoe deze verdeling van verantwoordelijkheid plaatsvindt wanneer we de actie 'Replica toevoegen' uitvoeren.
De operator krijgt de taak om een replica toe te voegen. Wat doet de exploitant? De operator berekent dat er een nieuwe StatefulSet moet worden aangemaakt, waarin bepaalde sjablonen, volumeclaim, moeten worden beschreven.
Hij bereidt het allemaal voor en geeft het door aan K8s. Hij zegt dat hij ConfigMap, StatefulSet, Volume nodig heeft. Kubernetes werkt. Hij materialiseert de basiseenheden waarmee hij opereert.
En dan komt de ClickHouse-operator weer in beeld. Hij heeft al een fysieke pod waarop hij al iets kan doen. En ClickHouse-operator werkt weer in domeintermen. Die. Met name ClickHouse: om een replica in een cluster op te nemen, moet u eerst het gegevensschema configureren dat in dit cluster bestaat. En ten tweede moet deze replica in de monitoring worden meegenomen, zodat deze duidelijk traceerbaar is. De operator configureert dit al.
En pas daarna komt ClickHouse zelf in het spel, d.w.z. een andere entiteit op een hoger niveau. Dit is al een database. Het heeft zijn eigen exemplaar, een andere geconfigureerde replica die klaar is om lid te worden van het cluster.
Het blijkt dat de keten van uitvoering en verantwoordelijkheidsverdeling bij het toevoegen van een replica behoorlijk lang is.
Wij gaan door met onze praktische taken. Als u al een cluster heeft, kunt u de configuratie migreren.
We hebben het zo gemaakt dat u rechtstreeks in de bestaande XML kunt plakken, wat ClickHouse begrijpt.
U kunt ClickHouse verfijnen. Alleen gezoneerde implementatie is waar ik het over had toen ik hostPath, lokale opslag, uitlegde. Zo voert u de gezoneerde implementatie correct uit.
De volgende praktische taak is het monitoren.
Als ons cluster verandert, moeten we periodiek de monitoring configureren.
Laten we naar het diagram kijken. We hebben hier al naar de groene pijlen gekeken. Laten we nu naar de rode pijlen kijken. Zo willen wij ons cluster monitoren. Hoe statistieken uit het ClickHouse-cluster in Prometheus terechtkomen en vervolgens in Grafana.
Wat is het probleem met monitoren? Waarom wordt dit gepresenteerd als een soort prestatie? De moeilijkheid ligt in de dynamiek. Als we één cluster hebben en deze statisch is, kunnen we de monitoring één keer instellen en er geen moeite meer mee doen.
Maar als we veel clusters hebben, of als er voortdurend iets verandert, dan is het proces dynamisch. En het voortdurend opnieuw configureren van de monitoring is een verspilling van middelen en tijd. zelfs gewoon luiheid. Dit moet geautomatiseerd worden. De moeilijkheid ligt in de dynamiek van het proces. En de operator automatiseert dit heel goed.
Hoe heeft ons cluster zich ontwikkeld? In het begin was hij zo.
Toen was hij zo.
Uiteindelijk werd hij zo.
En de monitoring gebeurt automatisch door de operator. Eén toegangspunt.
En net bij de uitgang kijken we naar het Grafana-dashboard om te zien hoe het leven van ons cluster van binnen kookt.
Overigens wordt het Grafana-dashboard ook rechtstreeks in de broncode bij onze operator verspreid. U kunt verbinding maken en gebruiken. Onze DevOps gaf me deze screenshot.
Waar zouden we hierna graag heen willen? Dit:
- Ontwikkel testautomatisering. De hoofdtaak is het geautomatiseerd testen van nieuwe versies.
- Ook de integratie met ZooKeeper willen we heel graag automatiseren. En er zijn plannen om te integreren met ZooKeeper-operator. Die. Er is een operator geschreven voor ZooKeeper en het is logisch dat de twee operators beginnen te integreren om een gemakkelijkere oplossing te bouwen.
- We willen meer complexe vitale functies doen.
- Ik heb in het groen gemarkeerd dat we de overerving van sjablonen naderen - KLAAR, dat wil zeggen dat we bij de volgende release van de operator al overerving van sjablonen zullen hebben. Dit is een krachtig hulpmiddel waarmee u complexe configuraties uit stukken kunt bouwen.
- En we willen automatisering van complexe taken. De belangrijkste is opnieuw sharden.
Laten we enkele tussenresultaten nemen.
Wat krijgen we als resultaat? En is het de moeite waard om te doen of niet? Is het zelfs nodig om te proberen de database naar Kubernetes te slepen en de operator in het algemeen en de Alitnity-operator in het bijzonder te gebruiken?
Bij de uitvoer krijgen we:
- Aanzienlijke vereenvoudiging en automatisering van configuratie, implementatie en onderhoud.
- Direct ingebouwde monitoring.
- En kant-en-klare gecodificeerde sjablonen voor complexe situaties. Een actie zoals het toevoegen van een replica hoeft niet handmatig te worden gedaan. Dit doet de exploitant.
Er rest nog maar één laatste vraag. We hebben al een database in Kubernetes, virtualisatie. Hoe zit het met de prestaties van een dergelijke oplossing, vooral omdat ClickHouse is geoptimaliseerd voor prestaties?
Het antwoord is: alles is in orde! Ik zal niet in details treden; dit is het onderwerp van een afzonderlijk rapport.
Maar er is zo'n project als TSBS. Wat is zijn voornaamste taak? Dit is een databaseprestatietest. Dit is een poging om warm met warm, zacht met zacht te vergelijken.
Hoe werkt hij? Er wordt één dataset gegenereerd. Vervolgens wordt deze set gegevens op verschillende databases uitgevoerd met behulp van dezelfde set tests. En elke database lost één probleem op op de manier waarop hij weet hoe. En dan kun je de resultaten vergelijken.
Het ondersteunt al een groot aantal databases. Ik heb drie belangrijke geïdentificeerd. Dit:
- TijdschaalDB.
- InfluxDB.
- KlikHuis.
Er werd ook een vergelijking gemaakt met een andere soortgelijke oplossing. Vergelijking met RedShift. Vergelijking werd gemaakt op Amazon. ClickHouse loopt ook hierin voorop.
Welke conclusies kunnen worden getrokken uit wat ik zei?
- DB in Kubernetes is mogelijk. Waarschijnlijk is alles mogelijk, maar over het algemeen lijkt het erop dat het mogelijk is. ClickHouse in Kubernetes is zeker mogelijk met de hulp van onze operator.
- De operator helpt processen te automatiseren en maakt het leven echt makkelijker.
- Prestaties zijn normaal.
- En het lijkt ons dat dit gebruikt kan en moet worden.
Open source - doe mee!
Zoals ik al zei, is de operator een volledig open source-product, dus het zou heel goed zijn als het maximale aantal mensen er gebruik van zou maken. Doe met ons mee! Wij wachten op jullie allemaal!
Bedankt allemaal!
vragen
Bedankt voor het rapport! Mijn naam is Anton. Ik ben van SEMrush. Ik vraag me af hoe het zit met loggen. We horen over monitoring, maar niets over loggen, als we het over het hele cluster hebben. Zo hebben we bijvoorbeeld een cluster op hardware opgezet. En we gebruiken gecentraliseerde logboekregistratie, waarbij we ze met standaardmiddelen op een gemeenschappelijke hoop verzamelen. En van daaruit krijgen we de gegevens die ons interesseren.
Goede vraag, bijvoorbeeld inloggen op een todolijst. Onze operator automatiseert dit nog niet. Het is nog in ontwikkeling, het project is nog vrij jong. Wij begrijpen de noodzaak van houtkap. Dit is ook een heel belangrijk onderwerp. En het is waarschijnlijk niet minder belangrijk dan monitoring. Maar eerst op de lijst voor implementatie stond monitoring. Er zal worden gelogd. Uiteraard proberen we alle aspecten van het leven van het cluster te automatiseren. Daarom is het antwoord dat de operator op dit moment helaas niet weet hoe hij dit moet doen, maar het staat in de plannen dat we het zullen doen. Als je mee wilt doen, trek dan een verzoek in, alsjeblieft.
Hallo! Bedankt voor het rapport! Ik heb een standaardvraag met betrekking tot Persistent Volumes. Wanneer we een configuratie met deze operator maken, hoe bepaalt de operator dan op welk knooppunt een bepaalde schijf of map is aangesloten? We moeten hem eerst uitleggen dat we onze ClickHouse op deze knooppunten met een schijf moeten plaatsen?
Voor zover ik het begrijp is deze vraag een voortzetting van lokale opslag, vooral het hostPath-gedeelte ervan. Dit is hetzelfde als uitleggen aan het hele systeem dat de pod moet worden gelanceerd op een bepaald knooppunt, waarmee we een fysiek verbonden schijf hebben, die langs een bepaald pad is gemonteerd. Dit is een hele sectie die ik heel oppervlakkig heb besproken, omdat het antwoord daar vrij groot is.
In het kort ziet het er zo uit. Uiteraard moeten we deze volumes voorzien. Op dit moment is er geen sprake van dynamische voorziening in de lokale opslag, dus moet DevOps de schijven zelf, deze volumes, opsplitsen. En ze moeten de Kubernetes-inrichting uitleggen dat je persistente volumes van die en die klasse zult hebben, die zich op die en die knooppunten bevinden. Vervolgens moet u Kubernetes uitleggen dat pods die een bepaalde lokale opslagklasse nodig hebben, alleen naar die en die knooppunten moeten worden geleid met behulp van labels. Voor deze doeleinden heeft de operator de mogelijkheid om een soort label toe te wijzen, en één per hostinstantie. En het blijkt dat pods door Kubernetes zullen worden gerouteerd om alleen te draaien op knooppunten die voldoen aan de vereisten, labels, in eenvoudige bewoordingen. Beheerders wijzen handmatig labels toe en richten schijven in. En dan schaalt het.
En het is de derde optie, lokaal, die dit een beetje gemakkelijker maakt. Zoals ik al heb benadrukt, is dit nauwgezet afstemmen, wat uiteindelijk helpt om maximale prestaties te verkrijgen.
Ik heb een tweede vraag die hiermee verband houdt. Kubernetes is zo ontworpen dat het voor ons niet uitmaakt of we een node verliezen of niet. Wat moeten we in dit geval doen als we het knooppunt waar onze scherf hangt, kwijt zijn?
Ja, Kubernetes was aanvankelijk van mening dat onze relatie met onze peulen als vee is, maar bij ons wordt elke schijf zoiets als een huisdier. Het probleem is zo groot dat we ze niet zomaar kunnen weggooien. En de ontwikkeling van Kubernetes gaat in de richting dat het onmogelijk is om het filosofisch volledig te behandelen, alsof het een volledig weggegooide hulpbron is.
Nu een praktische vraag. Wat te doen als u het knooppunt bent kwijtgeraakt waarop de schijf stond? Hier wordt het probleem op een hoger niveau opgelost. In het geval van ClickHouse hebben we replica’s die op een hoger niveau werken, d.w.z. op ClickHouse-niveau.
Wat is de daaruit voortvloeiende dispositie? DevOps is ervoor verantwoordelijk dat gegevens niet verloren gaan. Hij moet de replicatie correct instellen en ervoor zorgen dat de replicatie actief is. De replica op ClickHouse-niveau moet dubbele gegevens bevatten. Dit is niet het probleem dat de operator oplost. En niet het probleem dat Kubernetes zelf oplost. Dit is op ClickHouse-niveau.
Wat moet u doen als uw ijzeren knoop eraf valt? En het blijkt dat je een tweede moet installeren, de schijf er op de juiste manier op moet plaatsen en labels moet aanbrengen. En daarna zal het voldoen aan de eisen dat Kubernetes er een instance pod op kan lanceren. Kubernetes zal het lanceren. Uw aantal pods is niet voldoende om aan het opgegeven aantal te voldoen. Het zal de cyclus doorlopen die ik heb laten zien. En op het hoogste niveau zal ClickHouse begrijpen dat we een replica hebben ingevoerd, deze is nog leeg en we moeten beginnen met het overbrengen van gegevens ernaar. Die. Dit proces is nog niet goed geautomatiseerd.
Bedankt voor het rapport! Als er allerlei nare dingen gebeuren, de operator crasht en opnieuw opstart, en op dat moment komen er gebeurtenissen, ga je hier dan op de een of andere manier mee om?
Wat gebeurt er als de operator crasht en opnieuw opstart, toch?
Ja. En op dat moment kwamen de gebeurtenissen.
De taak wat te doen in dit geval wordt deels gedeeld tussen de operator en Kubernetes. Kubernetes heeft de mogelijkheid om een gebeurtenis die heeft plaatsgevonden opnieuw af te spelen. Hij herhaalt. En het is de taak van de operator om ervoor te zorgen dat wanneer het gebeurtenislogboek op hem wordt afgespeeld, deze gebeurtenissen idempotent zijn. En zodat het herhaaldelijk voorkomen van dezelfde gebeurtenis ons systeem niet kapotmaakt. En onze operator kan deze taak aan.
Hallo! Bedankt voor het rapport! Dmitry Zavyalov, bedrijf Smedova. Zijn er plannen om de operator de mogelijkheid te geven om met haproxy te configureren? Ik zou geïnteresseerd zijn in een andere balancer naast de standaard, zodat deze slim is en begrijpt dat ClickHouse er echt is.
Heb je het over Ingress?
Ja, vervang Ingress door haproxy. In haproxy kunt u de topologie opgeven van het cluster waar het replica's heeft.
Wij hebben er nog niet over nagedacht. Als je het nodig hebt en kunt uitleggen waarom het nodig is, dan is het mogelijk om het uit te voeren, vooral als je wilt meedoen. Wij overwegen de optie graag. Het korte antwoord is nee, dergelijke functionaliteit hebben we momenteel niet. Bedankt voor de tip, we gaan deze kwestie onderzoeken. En als je dan ook de use case uitlegt en waarom dat in de praktijk nodig is, bijvoorbeeld issues op GitHub maakt, dan is dat helemaal mooi.
Heeft al.
Prima. Wij staan open voor alle suggesties. En haproxy wordt toegevoegd aan de todolijst. De todolijst groeit, maar krimpt nog niet. Maar dit is goed, het betekent dat er veel vraag is naar het product.
Bron: www.habr.com