Operatør i Kubernetes til styring af databaseklynger. Vladislav Klimenko (Altinity, 2019)

Rapporten er afsat til de praktiske spørgsmål om at udvikle en operatør i Kubernetes, designe dens arkitektur og grundlæggende driftsprincipper.

I den første del af rapporten vil vi overveje:

• hvad er en operatør i Kubernetes, og hvorfor er det nødvendigt;
• præcis hvordan operatøren forenkler styringen af ​​komplekse systemer;
• hvad operatøren kan, og hvad operatøren ikke kan.

Lad os derefter gå videre til at diskutere operatørens interne struktur. Overvej operatørens arkitektur og drift trin for trin. Lad os analysere i detaljer:

• interaktion mellem operatøren og Kubernetes;
• hvilke funktioner operatøren påtager sig, og hvilke delegerer til Kubernetes.

Overvej at administrere shards og databasereplikaer i Kubernetes.
Dernæst vil vi diskutere problemer med datalagring:

• hvordan man arbejder med Persistent Storage fra en operatørs synspunkt;
• faldgruber ved at bruge Local Storage.

I den sidste del af rapporten vil vi overveje praktiske eksempler på anvendelsen klikhusoperatør med Amazon eller Google Cloud Service. Rapporten er baseret på eksemplet med udviklings- og driftserfaring hos operatøren for ClickHouse.

Video:

Mit navn er Vladislav Klimenko. I dag ville jeg fortælle om vores erfaring med at udvikle og drive en operatør, og dette er en specialiseret operatør til styring af databaseklynger. For eksempel ClickHouse-operatør at administrere ClickHouse-klyngen.

Hvorfor har vi mulighed for at tale om operatøren og ClickHouse?

• Vi støtter og udvikler ClickHouse.
• I øjeblikket forsøger vi langsomt at yde vores bidrag til udviklingen af ​​ClickHouse. Og vi er den anden efter Yandex med hensyn til mængden af ​​ændringer foretaget i ClickHouse.
• Vi forsøger at lave yderligere projekter til ClickHouse-økosystemet.

Jeg vil gerne tale om et af disse projekter. Dette handler om ClickHouse-operatøren til Kubernetes.

I min rapport vil jeg gerne komme ind på to emner:

• Det første emne er, hvordan vores ClickHouse-databaseoperatør fungerer i Kubernetes.
• Det andet emne er, hvordan enhver operatør fungerer, dvs. hvordan den interagerer med Kubernetes.

Disse to spørgsmål vil dog krydse hinanden gennem hele min betænkning.

Hvem ville være interesseret i at høre, hvad jeg prøver at sige?

• De mest interessante vil være dem, der udnytter operatørerne.
• Eller for dem, der ønsker at lave deres eget for at forstå, hvordan det fungerer indeni, hvordan operatøren interagerer med Kubernetes, og hvilke faldgruber der kan opstå.

For bedst at forstå, hvad vi vil diskutere i dag, ville det være rart at vide, hvordan Kubernetes fungerer og have en grundlæggende baggrund i cloud-teknologier.

Hvad er ClickHouse? Dette er en kolonnedatabase med detaljer i onlinebehandling af analytiske forespørgsler. Og det er fuldstændig open source.

Og vi behøver kun at vide to ting. Du skal vide, at dette er en database, så det, jeg vil fortælle dig, vil være gældende for næsten enhver database. Og det faktum, at ClickHouse DBMS skalerer meget godt, giver skalerbarheden næsten lineær. Og derfor er klyngens tilstand en naturlig tilstand for ClickHouse. Og vi er mest interesserede i at diskutere, hvordan man betjener en ClickHouse-klynge i Kubernetes.

Hvorfor er der brug for ham der? Hvorfor kan vi ikke fortsætte med at drive det selv? Og svarene er dels tekniske og dels organisatoriske.

• I praksis støder vi oftere og oftere på en situation, hvor i store virksomheder næsten alle komponenter allerede er i Kubernetes. Forbliv databaser udenfor.
• Og oftere og oftere stilles spørgsmålet: "Kan den placeres inde?". Derfor forsøger store virksomheder at producere den maksimale ensretning af ledelsen for hurtigt at kunne administrere deres datavarehuse.
• Og dette hjælper især, hvis du har brug for maksimal mulighed for at gentage det samme et nyt sted, det vil sige maksimal bærbarhed.

Hvor let eller svært er det? Dette kan selvfølgelig gøres i hånden. Men det er ikke så let, fordi vi tilføjer kompleksiteten ved at administrere Kubernetes selv, men samtidig påtvinges detaljerne i ClickHouse. Og det viser sig sådan en sammenlægning.

Og alt sammen giver dette et ret stort sæt teknologier, som allerede er ved at blive ret vanskelige at styre, fordi Kubernetes bringer sine daglige problemer i drift, og ClickHouse bringer sine problemer til daglig drift. Især hvis vi har flere ClickHouses, og vi skal hele tiden lave noget med dem.

ClickHouse med en dynamisk konfiguration har et ret stort antal problemer, der skaber en konstant belastning på DevOps:

• Når vi vil ændre noget i ClickHouse, f.eks. tilføje en replika, en shard, så skal vi administrere konfigurationen.
• Skift derefter dataskemaet, fordi ClickHouse har en specifik sønderdelingsmetode. Der er det nødvendigt at udlægge dataskemaet, udlægge konfigurationer.
• Du skal konfigurere overvågning.
• Indsamling af logs til nye skår, til nye replikaer.
• Pas på bedring.
• Og genstart.

Det er sådanne rutinearbejde, som jeg meget gerne vil facilitere i drift.

Kubernetes selv hjælper meget i drift, men på grundlæggende systemting.

Kubernetes er fantastisk til at facilitere og automatisere ting som:

• Genopretning.
• Genstart.
• Lagerstyring.

Det er godt, det er den rigtige retning, men han er fuldstændig ude af kontakt med, hvordan man betjener en databaseklynge.

Jeg vil have mere, jeg vil have, at hele databasen fungerer for os i Kubernetes.

Jeg vil gerne have noget som en stor magisk rød knap, som du trykker på, og du har en klynge installeret og vedligeholdt gennem hele livscyklussen med hverdagsopgaver, der skal løses. ClickHouse-klynge i Kubernetes.

Og vi forsøgte at lave en løsning, der ville være med til at lette arbejdet. Dette er ClickHouse-operatøren til Kubernetes fra Altinity.

En operatør er et program, hvis hovedopgave er at styre andre programmer, det vil sige, at det er en manager.

Og den indeholder adfærdsmønstre. Man kan kalde det kodificeret viden om fagområdet.

Og hans hovedopgave er at gøre livet lettere for DevOps og reducere mikrostyring, så han (DevOps) allerede tænker på højt niveau, det vil sige, så han (DevOps) ikke mikromanagerer, så han ikke manuelt konfigurerer alle de detaljer.

Og netop operatøren er en robotassistent, der kæmper med mikroopgaver og hjælper DevOps.

Hvorfor er der brug for en operatør? Han udmærker sig på to områder:

• Når en ClickHouse-specialist ikke har nok erfaring, men det allerede er nødvendigt at betjene ClickHouse, letter operatøren betjeningen og giver dig mulighed for at betjene en ClickHouse-klynge med en ret kompleks konfiguration, uden at gå for meget i detaljer om, hvordan det hele fungerer indeni . Du giver ham bare opgaver på højt niveau, og det virker.
• Og den anden opgave, hvor den viser sig bedst, er, når det er nødvendigt at automatisere en lang række typiske opgaver. Fjerner mikroopgaver fra sysadmins.

Dette er der størst behov for enten af ​​dem, der lige er begyndt på deres rejse, eller af dem, der har brug for en masse automatisering.

Hvad er forskellen mellem den operatørbaserede tilgang og andre systemer? Der er også Helm. Det hjælper også at installere ClickHouse, du kan tegne styrdiagrammer, som endda vil installere en hel ClickHouse-klynge. Hvad er så forskellen mellem operatøren og fra samme, for eksempel Helm?

Den væsentligste grundlæggende forskel er, at Helm handler om pakkehåndtering, og operatøren går et skridt videre. Dette er støtten for hele livscyklussen. Dette er ikke kun installation, det er hverdagsopgaver, der inkluderer skalering, skæring, det vil sige alt, der skal gøres i løbet af livscyklussen (om nødvendigt også fjernelse) - det hele bestemmes af operatøren. Den forsøger at automatisere og betjene hele softwarens livscyklus. Dette er dens grundlæggende forskel fra andre løsninger, der præsenteres.

Det var den indledende del, lad os komme videre.

Hvordan bygger vi vores operatør? Vi forsøger at nærme os problemet for at administrere ClickHouse-klyngen som en enkelt ressource.

Her har vi inputdataene i venstre side af billedet. Dette er YAML med en klyngespecifikation, som klassisk sendes gennem kubectl til Kubernetes. Der henter vores operatør det, gør sin magi. Og som følge heraf får vi sådan en ordning. Dette er implementeringen af ​​ClickHouse i Kubernetes.

Og så vil vi langsomt se på, hvordan operatøren arbejder, hvilke typiske opgaver der kan løses. Vi vil kun overveje typiske opgaver, fordi vi har begrænset tid. Og det bliver ikke fortalt om alt, hvad operatøren kan bestemme.

Lad os starte fra praksis. Vores projekt er fuldstændig open source, så du kan se, hvordan det fungerer på GitHub. Og du kan gå ud fra overvejelserne, hvis du bare vil i gang, så kan du starte med Quick Start Guide.

Hvis du ønsker at forstå i detaljer, så forsøger vi at vedligeholde dokumentationen i en mere eller mindre anstændig form.

Lad os starte med et praktisk problem. Den første opgave, vi alle vil starte med, er at køre det første eksempel på en eller anden måde. Hvordan starter man ClickHouse med hjælp fra en operatør, uden overhovedet at vide, hvordan det fungerer? Vi skriver et manifest, pga al kommunikation med k8s er kommunikation gennem manifester.

Her er et så komplekst manifest. Det, vi har fremhævet med rødt, er det, vi skal fokusere på. Vi beder operatøren om at oprette en klynge med navnet demo.

For nu er disse grundlæggende eksempler. Opbevaring er endnu ikke beskrevet, men vi vender tilbage til opbevaring lidt senere. Indtil videre vil vi observere udviklingen af ​​klyngen i dynamik.

Vi har skabt dette manifest. Vi leverer det til vores operatør. Han arbejdede, han gjorde magi.

Vi kigger på konsollen. Tre komponenter er af interesse - disse er Pod, to Service-a, StatefulSet.

Operatøren har arbejdet, og vi kan se, hvad han præcist har skabt.

Han skaber sådan noget. Vi har et StatefulSet, Pod, ConfigMap for hver replika, ConfigMap for hele klyngen. Nødvendigvis tjenester som indgangspunkter til klyngen.

Services er den centrale Load Balancer Service, og det er muligt for hver replika, for hver shard.

Her er vores basisklynge, der ser sådan ud. Han er fra en enkelt knude.

Lad os gå videre, vi vil komplicere. Du skal sønderdele klyngen.

Vores opgaver vokser, dynamikken begynder. Vi ønsker at tilføje et skår. Vi følger udviklingen. Vi ændrer vores specifikation. Vi angiver, at vi ønsker to skår.

Dette er den samme fil, som vi udvikler dynamisk med systemets vækst. Der er ingen opbevaring, opbevaring vil blive diskuteret yderligere, dette er et separat spørgsmål.

Vi fodrer YAML-operatøren og ser, hvad der sker.

Operatøren tænkte og lavede følgende enheder. Vi har allerede to Pods, tre Services og pludselig 2 StatefulSets. Hvorfor 2 StatefulSets?

Det var sådan på diagrammet - dette er vores begyndelsestilstand, da vi havde en pod.

Det blev sådan her. Indtil videre er alt simpelt, det er blevet duplikeret.

Og hvorfor blev StatefulSet til to? Her er vi nødt til at afvige og diskutere spørgsmålet om, hvordan Pods administreres i Kubernetes.

Der er sådan et objekt kaldet StatefulSet, som giver dig mulighed for at lave et sæt Pods fra en skabelon. Nøglefaktoren her er skabelon. Og du kan køre mange Pods i ét StatefulSet i henhold til en skabelon. Og nøglesætningen her er "én skabelon mange Pods".

Og der var en stor fristelse til at lave hele klyngen og pakke den ind i ét StatefulSet. Det vil virke, der er ikke noget problem i det. Men der er en advarsel. Hvis vi ønsker at sammensætte en heterogen klynge, altså fra flere versioner af ClickHouse, så begynder vores spørgsmål. Ja, StatefulSet kan lave en rullende opdatering, men der kan du udrulle en ny version, forklare at du ikke skal prøve mere end så mange noder på samme tid.

Men hvis vi ekstrapolerer opgaven og siger, at vi vil lave en fuldstændig heterogen klynge og ikke vil skifte fra den gamle version til en ny ved hjælp af en rullende opdatering, men blot ønsker at skabe en heterogen klynge både i forhold til forskellige versioner af ClickHouse og i forhold til forskellig opbevaring. Vi ønsker for eksempel at lave nogle replikaer på separate diske, på langsomme diske generelt, for fuldstændig at bygge en heterogen klynge. Og på grund af det faktum, at StatefulSet laver en standardiseret løsning ud af én skabelon, så der er ingen måde at gøre dette på.

Efter nogle overvejelser blev det besluttet, at vi gør sådan her. Vi har hver replika i sit eget StatefulSet. Der er nogle ulemper ved denne løsning, men i praksis er det hele fuldstændig indkapslet operatøren. Og der er mange fordele. Vi kan bygge en fuldstændig sådan klynge, som vi ønsker, for eksempel en absolut heterogen. Derfor vil vi i en klynge, hvor vi har to shards med en replika, have 2 StatefulSets og 2 Pods, netop fordi vi valgte denne tilgang på grund af ovenstående årsager til evnen til at bygge en heterogen klynge.

Lad os vende tilbage til praktiske opgaver. I vores klynge skal vi konfigurere brugere, dvs. du skal lave noget konfiguration af ClickHouse i Kubernetes. Operatøren giver alle muligheder for dette.

Vi kan skrive hvad vi vil direkte i YAML. Alle konfigurationsmuligheder kortlægges direkte fra denne YAML til ClickHouse-konfigurationer, som derefter implementeres i hele klyngen.

Du kan også skrive sådan her. Dette er for et eksempel. Adgangskoden kan krypteres. Absolut alle ClickHouse-konfigurationsmuligheder er understøttet. Her er blot et eksempel.

Klyngekonfigurationen distribueres som ConfigMap. I praksis sker ConfigMap-opdateringen ikke med det samme, så hvis der er en stor klynge, så tager processen med at skubbe konfigurationen noget tid. Men alt dette er meget praktisk at bruge.

Vi komplicerer opgaven. Klyngen er under udvikling. Vi ønsker at replikere data. Det vil sige, at vi allerede har to shards, en replika hver, brugerne er konfigureret. Vi vokser og vil gerne kopiere.

Hvad har vi brug for til replikation?

Vi har brug for ZooKeeper. I ClickHouse bygges replikering ved hjælp af ZooKeeper. ZooKeeper er nødvendig, så forskellige ClickHouse replikaer har en konsensus om, hvilke datablokke der er på hvilke ClickHouse.

ZooKeeper kan bruges af alle. Hvis en virksomhed har en ekstern ZooKeeper, så kan den bruges. Hvis ikke, så kan du installere fra vores lager. Der er en installatør, der gør det hele nemmere.

Og interaktionsskemaet for hele systemet viser sig sådan her. Vi har Kubernetes som platform. Den udfører ClickHouse-sætningen. ZooKeeper jeg afbillede her. Og operatøren interagerer med både ClickHouse og ZooKeeper. Det vil sige, at der opnås en interaktion.

Og alt dette er nødvendigt for, at ClickHouse med succes kan replikere data til k8s.

Lad os nu se på selve opgaven, hvordan manifestet til replikering vil se ud.

Vi tilføjer to sektioner til vores manifest. Den første er, hvor man kan få ZooKeeper, som enten kan være inde i Kubernetes eller ekstern. Dette er kun en beskrivelse. Og vi bestiller kopier. De der. vi vil have to kopier. I alt skulle vi have 4 pods ved udgangen. Vi husker om opbevaring, det vil vende tilbage lidt længere. Opbevaring er en separat sang.

Det var sådan her.

Det bliver sådan her. Replikaer tilføjes. Den 4 passede ikke, vi tror på at der kan være mange af dem. Og ZooKeeper er tilføjet på siden. Mønstrene bliver mere komplekse.

Og det er tid til at tilføje den næste opgave. Vi tilføjer Persistent Storage.

For vedvarende opbevaring har vi en række muligheder.

Hvis vi kører i en cloud-udbyder, for eksempel ved hjælp af Amazon, Google, så er der en stor fristelse til at bruge cloud storage. Det er meget praktisk, det er godt.

Og der er en anden mulighed. Dette er til lokal lagring, når vi har lokale diske på hver node. Denne mulighed er meget sværere at implementere, men samtidig er den mere produktiv.

Lad os se, hvad vi har med hensyn til cloud storage.

Der er fordele. Det er meget nemt at konfigurere. Vi bestiller simpelthen fra en cloud-udbyder, som venligst giver os opbevaring af sådan en kapacitet, sådan og sådan klasse. Klasser males af udbydere uafhængigt.

Og der er en ulempe. For nogle er dette en ukritisk mangel. Selvfølgelig vil der være nogle præstationsoverlejringer. Det er meget praktisk at bruge, pålideligt, men der er nogle potentielle ulemper i ydeevnen.

Og siden ClickHouse fokuserer på ydeevne, man kan endda sige, at det presser alt muligt ud, så mange kunder forsøger at presse den maksimale ydeevne ud.

Og for at få mest muligt ud af det, har vi brug for lokal opbevaring.

Kubernetes giver tre abstraktioner til brug af lokal lagring i Kubernetes. Det her:

• EmptyDir
• HostPath.
• Lokale

Overvej, hvordan de adskiller sig, hvordan de ligner hinanden.

For det første, i alle tre tilgange, har vi storage - det er lokale diske, der er placeret på den samme fysiske k8s-node. Men de har nogle forskelle.

Lad os starte med det enkleste, dvs. tommeDir. Hvad er det i praksis? Det er os, der beder containeriseringssystemet (oftest Docker) ud fra vores specifikation om at give os adgang til en mappe på en lokal disk.

I praksis opretter docker en midlertidig mappe et sted i sine egne stier, kalder det en lang hash. Og giver en grænseflade til at få adgang til det.

Hvordan vil det præstere med hensyn til ydeevne? Dette vil køre med den lokale disks hastighed, dvs. dette er fuld adgang til din skrue.

Men denne sag har sin ulempe. Vedvarende i dette tilfælde er ret tvivlsomt. Ved den første bevægelse af havnearbejderen med containere går Persistent tabt. Hvis Kubernetes af en eller anden grund ønsker at flytte denne Pod til en anden disk, vil dataene gå tabt.

Denne tilgang er god til test, fordi den allerede viser normal hastighed, men denne mulighed er ikke egnet til noget seriøst.

Derfor er der en anden tilgang. Dette er hostPath. Hvis du ser på det forrige dias og dette, kan du kun se én forskel. Vores mappe forlod docker direkte til Kubernetes-knuden. Det er lidt hurtigere her. Vi skriver direkte stien på det lokale filsystem, hvor vi gerne vil gemme vores data.

Denne metode har fordele. Dette er allerede en rigtig Persistent og en klassisk. På vores disk vil data blive skrevet til en eller anden adresse.

Der er også ulemper. Dette er kompleksiteten i ledelsen. Vores Kubernetes vil måske flytte Pod'en til en anden fysisk node. Det er her DevOps kommer ind i billedet. Det skal korrekt forklare hele systemet, at du kun kan flytte disse pods til sådanne noder, hvorpå du har noget monteret langs disse stier, og ikke mere end én node ad gangen. Det er svært nok.

Specielt til disse formål har vi lavet skabeloner i vores operatør for at skjule al denne kompleksitet. Og du kan bare sige: "Jeg vil gerne have én forekomst af ClickHouse pr. fysisk knude og langs sådan og sådan en vej."

Men dette behov er ikke kun for os, så herrerne fra Kubernetes selv forstår også, at folk gerne vil have adgang til fysiske diske, så de giver et tredje niveau.

Det kaldes lokalt. Der er praktisk talt ingen forskel fra det forrige slide. Kun tidligere var det nødvendigt at udføre med vores hænder, at vi ikke kan overføre disse pods fra node til node, fordi de skal fastgøres langs en sådan og sådan vej til den lokale fysiske disk, og nu er al denne viden indkapslet i Kubernetes selv. Og det viser sig meget nemmere at konfigurere.

Lad os vende tilbage til vores praktiske opgave. Lad os vende tilbage til YAML skabelonen. Her har vi en rigtig opbevaring. Vi er tilbage til dette. Vi indstiller den klassiske VolumeClaim-skabelon som i k8s. Og vi beskriver, hvilken slags opbevaring vi ønsker.

Derefter vil k8s anmode om opbevaring. Tildel det til os i StatefulSet. Og i sidste ende vil det vise sig at være til rådighed for ClickHouse.

Vi havde sådan en ordning. Vores Persistent Storage var rød, hvilket syntes at antyde, at det burde gøres.

Og den bliver grøn. Nu er ClickHouse på k8s klyngeskemaet fuldt færdiggjort. Vi har skår, replikaer, ZooKeeper, vi har ægte Persistent, som er implementeret på den ene eller anden måde. Ordningen er allerede fuldt funktionsdygtig.

Vi lever videre. Vores klynge vokser. Og Aleksey forsøger at udgive en ny version af ClickHouse.

En praktisk opgave melder sig - at teste den nye version af ClickHouse på vores klynge. Og selvfølgelig vil jeg ikke rulle det hele ud, jeg vil lægge en ny version et sted i det fjerneste hjørne i én replika, eller måske ikke én ny version, men to på én gang, fordi de udkommer ofte.

Hvad kan vi sige om dette?

Her har vi netop sådan en mulighed. Disse er pod-skabeloner. Du kan male, vores operatør giver dig fuldstændig mulighed for at bygge en heterogen klynge. De der. konfigurere, startende fra alle replikaer i en flok, slutter med hver personlig replika, hvilken version vi ønsker ClickHouse, hvilken version vi ønsker opbevaring. Vi kan fuldt ud konfigurere klyngen i en sådan konfiguration, som vi har brug for.

Lad os gå dybere inde lidt. Inden da talte vi om, hvordan ClickHouse-operatøren fungerer i forhold til ClickHouses specifikationer.

Nu vil jeg gerne sige et par ord om, hvordan enhver operatør fungerer generelt, samt hvordan den interagerer med K8'ere.

Overvej interaktion med K8'er til at begynde med. Hvad sker der, når vi anvender kubectl? Gennem API'et vises vores objekter i etcd.

For eksempel de grundlæggende Kubernetes-objekter: pod, StatefulSet, service og så videre gennem listen.

Der sker dog ikke noget fysisk endnu. Disse objekter skal materialiseres i en klynge.

Det er her controlleren kommer ind. Controlleren er en speciel k8s-komponent, der kan materialisere disse beskrivelser. Han ved hvordan og hvad han skal gøre fysisk. Han ved, hvordan man kører containere, hvad der skal konfigureres der, for at serveren kan fungere.

Og det materialiserer vores objekter i K8s.

Men vi ønsker ikke kun at arbejde med pods, StatefulSets, vi ønsker at skabe en ClickHouseInstallation, det vil sige et objekt af typen ClickHouse, for at kunne arbejde med det som helhed. Indtil videre er der ingen sådan mulighed.

Men K8s har en anden god ting. Vi ønsker, at vi skal have en så kompleks entitet et eller andet sted, hvor vores klynge vil blive samlet fra pods og StatefulSet.

Og hvad skal der gøres for dette? Først kommer Custom Resource Definition ind i scenen. Hvad er det? Dette er en beskrivelse for K8'er, som du vil have en anden datatype, som vi ønsker at tilføje til poden, StatefulSet, en tilpasset ressource, der vil være kompleks indeni. Dette er en beskrivelse af datastrukturen.

Vi sender det også dertil via kubectl application. Kubernetes tog det med glæde.

Og nu i vores lager har objektet i etcd mulighed for at skrive en tilpasset ressource kaldet ClickHouseInstallation.

Men indtil videre sker der ikke andet. Det vil sige, hvis vi nu opretter en YAML-fil, som vi overvejede med en beskrivelse af shard, replikaer og siger "kubectl apply", så vil Kubernetes acceptere den, lægge den i etcd og sige: "Fantastisk, men jeg ved det ikke hvad skal man gøre med det. Jeg ved ikke, hvordan man vedligeholder ClickHouseInstallation."

Derfor har vi brug for nogen til at hjælpe Kubernetes med at betjene den nye datatype. Til venstre har vi en lager Kubernetes-controller, der arbejder med lagerdatatyper. Og til højre skulle vi have en brugerdefineret controller, der kan arbejde med brugerdefinerede datatyper.

Og på en anden måde kaldes det en operatør. Jeg tog det specifikt ud her til Kubernetes, fordi det også kan udføres uden for K8s. Oftest bliver alle udsagn selvfølgelig eksekveret i Kubernetes, men intet forhindrer den i at stå udenfor, så her er den specielt bragt frem.

Og allerede til gengæld interagerer den brugerdefinerede controller, også kendt som operatøren, med Kubernetes gennem API'en. Han ved allerede, hvordan man interagerer med API'en. Og han ved allerede, hvordan man materialiserer et komplekst skema, som vi ønsker at lave fra en tilpasset ressource. Det er præcis, hvad operatøren gør.

Hvordan arbejder operatøren? Lad os tage et kig på højre side for at se, hvordan han gør det. Vi vil finde ud af, hvordan operatøren materialiserer alt dette, og hvordan yderligere interaktion med K8s finder sted.

Operatøren er programmet. Hun er begivenhedsorienteret. Operatøren abonnerer på begivenheder ved hjælp af Kubernetes API. Kubernetes API har indgangspunkter, hvor du kan abonnere på begivenheder. Og hvis noget ændrer sig i K8s, så sender Kubernetes begivenheder til alle, dvs. som abonnerer på dette API-punkt vil modtage meddelelser.

Operatøren abonnerer på begivenheder og skal lave en form for reaktion. Dens opgave er at reagere på nye begivenheder.

Begivenheder genereres af nogle opdateringer. Vores YAML-fil kommer med en beskrivelse af ClickHouseInstallation. Han gik til etcd via kubectl application. En begivenhed fungerede der, som et resultat, denne begivenhed kom til ClickHouse-operatøren. Operatøren modtog denne beskrivelse. Og han skal gøre noget. Hvis der kom en opdatering til ClickHouseInstallation-objektet, så skal du opdatere klyngen. Og operatørens opgave er at opdatere klyngen.

Hvad laver han? Først skal vi udarbejde en handlingsplan for, hvad vi vil gøre med denne opdatering. Opdateringer kan være meget små, dvs. lille i YAML-udførelse, men kan føre til meget store ændringer på klyngen. Derfor laver operatøren en plan, og så overholder han den.

Han begynder, ifølge denne plan, at koge denne struktur indeni for at materialisere bælg, tjenester, dvs. at gøre, hvad dens hovedopgave er. Det er som at bygge en ClickHouse-klynge i Kubernetes.

Lad os nu komme ind på sådan en interessant ting. Dette er en ansvarsfordeling mellem Kubernetes og operatøren, dvs. hvad Kubernetes gør, hvad operatøren gør, og hvordan de interagerer med hinanden.

Kubernetes står for systemting, dvs. for et grundlæggende sæt af objekter, der kan tolkes som et system-scope. Kubernetes ved, hvordan man starter pods, hvordan man genstarter containere, hvordan man monterer volumener, hvordan man arbejder med ConfigMap, dvs. alt, der kan kaldes et system.

Operatører opererer inden for fagområder. Hver operatør er lavet til sit fagområde. Vi lavede til ClickHouse.

Og operatøren interagerer præcist med hensyn til emneområdet, såsom tilføjelse af en replika, lave et skema, opsætte overvågning. Der er sådan en opdeling.

Lad os se på et praktisk eksempel på, hvordan denne adskillelse af bekymringer opstår, når vi udfører en tilføjelse af replika-handling.

Opgaven kommer til operatøren - at tilføje en replika. Hvad laver operatøren? Operatøren vil beregne, at det er nødvendigt at lave et nyt StatefulSet, hvori det er nødvendigt at beskrive sådanne og sådanne skabeloner, volumenkrav.

Han forberedte det hele og giver det videre til K8s. Han siger, at han har brug for ConfigMap, StatefulSet, Volume. Kubernetes virker. Han materialiserer de grundlæggende enheder, som han opererer med.

Og så kommer ClickHouse-operatør i spil igen. Han har allerede en fysisk pod, som du allerede kan gøre noget på. Og ClickHouse-operatør fungerer igen i forhold til fagområdet. De der. Specifikt, ClickHouse, for at inkludere en replika i en klynge, skal du først konfigurere det dataskema, der findes i denne klynge. Og for det andet skal denne bemærkning indgå i overvågningen, så den tydeligt kan spores. Operatøren har allerede sat det op.

Og først derefter kommer selve ClickHouse i spil, dvs. en anden enhed på højere niveau. Det er allerede en database. Den har sin egen instans, den næste konfigurerede replika, som er klar til at slutte sig til klyngen.

Det viser sig, at kæden af ​​udførelse og adskillelse af ansvar, når du tilføjer en replika, er lang nok.

Vi fortsætter vores praktiske opgaver. Hvis klyngen allerede eksisterer, kan du migrere konfigurationen.

Vi har gjort det, så det er muligt at gå igennem i den eksisterende xml, som ClickHouse forstår.

Du kan finjustere ClickHouse. Bare zoneinddelt implementering er det, jeg talte om, da jeg forklarede hostPath, lokal lagring. Sådan udføres zoneinddeling korrekt.

Den næste praktiske opgave er overvågning.

Hvis vores klynge ændrer sig, skal vi med jævne mellemrum konfigurere overvågning.

Lad os tage et kig på diagrammet. Vi har allerede overvejet de grønne pile her. Lad os nu se på de røde pile. Det er sådan, vi vil overvåge vores klynge. Hvordan målinger fra ClickHouse-klyngen kommer ind i Prometheus og derefter ind i Grafana.

Hvad er problemet med overvågning? Hvorfor præsenteres dette som en slags præstation? Vanskeligheden ligger i dynamikken. Når vi har én klynge, og den er statisk, så kan du sætte overvågning op én gang og ikke gider mere.

Men hvis vi har mange klynger, eller noget ændrer sig konstant, så er processen dynamisk. Og konstant at omkonfigurere overvågning er spild af ressourcer og tid; endda bare doven. Dette skal automatiseres. Vanskeligheden ligger i dynamikken i processen. Og operatøren automatiserer dette meget godt.

Hvordan udviklede vores klynge sig? I begyndelsen var han sådan.

Så var han sådan her.

Til sidst blev han sådan.

Og overvågning udføres automatisk af operatøren. Enkelt indgangssted.

Og vi ser bare på udgangen i Grafana-instrumentbrættet, hvordan livet i vores klynge koger indeni.

Grafana dashboard er i øvrigt også distribueret med vores operatør lige i kildekoden. Du kan oprette forbindelse og bruge. Dette skærmbillede blev givet til mig af vores DevOps.

Hvor vil vi gerne hen næste gang? Det her:

• Udvikle testautomatisering. Hovedopgaven er automatiseret test af nye versioner.
• Vi vil også rigtig gerne automatisere integrationen med ZooKeeper. Og planlægger at integrere med ZooKeeper-operatør. De der. der er skrevet en operatør til ZooKeeper, og det er logisk, at de to operatører begynder at integrere sig for at bygge en mere bekvem løsning.
• Vi ønsker at lave mere komplekse livstjek.
• Jeg fremhævede med grønt, at vi har skabelonarv på vej - DONE, dvs. med næste udgivelse af operatøren vil vi allerede have skabelonarv. Dette er et kraftfuldt værktøj, der giver dig mulighed for at bygge komplekse konfigurationer fra stykker.
• Og vi vil automatisere komplekse opgaver. Den vigtigste er Re-sharding.

Lad os lave nogle mellemresultater.

Hvad får vi som resultat? Og er det det værd eller ej? Behøver jeg overhovedet at prøve at trække databasen ind i Kubernetes og anvende operatøren generelt og Alitnity operatøren i særdeleshed.

Ved udgangen får vi:

• Dramatisk forenkle og automatisere konfiguration, implementering og vedligeholdelse.
• Straks indbygget overvågning.
• Og klar til brug kodificerede skabeloner til komplekse situationer. Allerede handlingen af ​​typen for at tilføje en replika behøver ikke at udføres i hånden. Dette gøres af operatøren.

Kun det sidste spørgsmål er tilbage. Vi har allerede en database i Kubernetes, virtualisering. Hvad med ydelsen af ​​en sådan løsning, især da ClickHouse er optimeret til ydeevne?

Svaret er, at alt er i orden! Jeg vil ikke beskrive i detaljer, dette er emnet for en separat rapport.

Men der er sådan et projekt som TSBS. Hvad er dens hovedopgave? Dette er en databaseydeevnetest. Dette er et forsøg på at sammenligne varm med varm, blød med blød.

Hvordan arbejder han? Et sæt data genereres. Derefter køres dette datasæt på det samme testsæt på forskellige databaser. Og hver database løser et problem på den måde, den kan. Og så kan du sammenligne resultaterne.

Det understøtter allerede en lang række databaser. Jeg har identificeret tre vigtigste. Det her:

• tidsskaleretb.
• TilstrømningDB.
• klikhus.

Der blev også foretaget en sammenligning med en anden lignende løsning. Sammenligning med RedShift. Sammenligningen er foretaget på Amazon. ClickHouse er også et godt stykke foran alle i denne sag.

Hvilke konklusioner kan man drage af det, jeg har sagt?

• DB i Kubernetes er muligt. Sandsynligvis kan du gøre alt, men generelt ser det ud til, at du kan. ClickHouse i Kubernetes er helt sikkert muligt med hjælp fra vores operatør.
• Operatøren hjælper med at automatisere processer og forenkler virkelig livet.
• Ydeevnen er normal.
• Og det forekommer os, at det kan og bør bruges.

Open source - vær med!

Operatøren er som sagt et fuldstændig open source-produkt, så det ville være meget godt, hvis det maksimale antal personer brugte det. Deltag nu! Vi venter på jer alle!

Tak til alle!

R'RѕRїSЂRѕSЃS <

Tak for rapporten! Jeg hedder Anton. Jeg er fra SEMrush. Jeg spekulerer på, hvad der sker med logningen. Vi hører om overvågning, men intet om logning, hvis vi taler om hele klyngen. For eksempel har vi en klynge på hardware. Og vi bruger centraliseret logning, vi samler det i en fælles bunke med standardmidler. Og derfra får vi data, der er interessante for os.

Godt spørgsmål, dvs. at logge på todo-listen. Vores operatør automatiserer ikke dette endnu. Det er stadig under udvikling, projektet er stadig ret ungt. Vi forstår behovet for logning. Dette er også et meget vigtigt emne. Og det er nok ikke mindre vigtigt end overvågning. Men først på listen for implementering var overvågning. Der vil være logning. Naturligvis forsøger vi at automatisere alle aspekter af klyngens liv. Derfor er svaret, at i øjeblikket ved operatøren desværre ikke, hvordan man gør dette, men det ligger i planerne, vi vil gøre det. Hvis du vil være med, så træk anmodning, tak.

Hej! Tak for rapporten! Jeg har et standardspørgsmål relateret til Persistent Volumes. Når vi opretter en konfiguration med denne operatør, hvordan bestemmer operatøren, på hvilken node vi har en disk eller mappe? Vi skal først forklare ham, at venligst placere vores ClickHouse præcis på disse noder, der har en disk?

Så vidt jeg forstår, er dette spørgsmål en fortsættelse af lokal lagring, især hostPath-delen af ​​den. Det er som at forklare hele systemet, at det er nødvendigt at poden lanceres præcis på sådan en node, hvorpå vi har en fysisk tilsluttet disk, som er monteret på sådan og sådan en sti. Dette er et helt afsnit, som jeg berørte meget overfladisk, fordi svaret der er ret stort.

Kort fortalt ser det sådan ud. Naturligvis skal vi sørge for levering af disse mængder. I øjeblikket er der ingen dynamisk bestemmelse i lokal lagring, så DevOps skal selv klippe diskene, her er disse volumener. Og de skal forklare Kubernetes provisioning, at du vil have vedvarende volumener af sådan og sådan en klasse, som er placeret på sådanne og sådanne noder. Så vil det være nødvendigt at forklare Kubernetes, at pods, der kræver en sådan og sådan en lokal opbevaringsklasse, kun skal planlægges i henhold til etiketter til sådanne og sådanne noder. Til disse formål har operatøren mulighed for at tildele en slags etiket og en pr. værtsforekomst. Og det viser sig, at pods vil blive dirigeret af Kubernetes til kun at køre på noder, der opfylder kravene, etiketter, i enkle vendinger. Administratorer tildeler etiketter, gør klargøring af diske i hånden. Og så skalerer den.

Og netop den tredje mulighed lokalt er med til at gøre det lidt nemmere. Som jeg allerede har understreget, er dette et omhyggeligt arbejde med tuning, som i sidste ende hjælper med at få maksimal ydeevne.

Jeg har et andet spørgsmål relateret til dette. Kubernetes blev udtænkt på en sådan måde, at det ikke betyder noget for os, om vi mister en node eller ej. Hvad skal vi gøre i dette tilfælde, hvis vi har mistet knudepunktet, hvor vi har et skår?

Ja, Kubernetes var oprindeligt antaget, at vores forhold til vores bælg er som kvæg, men her bliver hver disk noget som et kæledyr. Der er sådan et problem, at vi ikke bare kan smide dem væk. Og udviklingen af ​​Kubernetes går i den retning, at det er umuligt helt at behandle det filosofisk, som en fuldstændig kasseret ressource.

Nu et praktisk spørgsmål. Hvad skal du gøre, hvis du mistede noden, hvorpå disken var? Her er problemet løst på et højere niveau. I tilfældet med ClickHouse har vi replikaer, der fungerer på et højere niveau, dvs. på ClickHouse-niveau.

Hvad er dispositionen? DevOps er ansvarlig for at sikre, at data ikke går tabt. Den skal konfigurere replikering korrekt og skal sikre, at replikering kører. I replikaen på ClickHouse-niveau skal dataene duplikeres. Det er ikke den opgave, som operatøren løser. Og ikke den opgave, som Kubernetes selv løser. Dette er på ClickHouse-niveau.

Hvad skal man gøre, hvis din jernknude er faldet af? Og det viser sig, at det vil være nødvendigt at sætte den anden, flytte disken ordentligt på den, anvende etiketter. Og derefter vil den opfylde kravene om, at Kubernetes på den kan køre en pod-instans. Kubernetes vil lancere det. Dit antal pods er ikke nok til den angivne. Det vil gå gennem den cyklus, som jeg viste. Og på højeste niveau vil ClickHouse forstå, at vi har indtastet en replika, den er stadig tom, og vi skal begynde at overføre data til den. De der. denne proces er stadig dårligt automatiseret.

Tak for rapporten! Når alle mulige grimme ting sker, operatøren crasher og genstarter, og i det øjeblik indtræffer begivenheder, behandler du så det på en eller anden måde?

Hvad sker der, hvis operatøren går ned og genstarter, ja?

Ja. Og i det øjeblik kom begivenhederne.

Opgaven med, hvad der skal gøres i dette tilfælde, er delvist delt mellem operatøren og Kubernetes. Kubernetes har evnen til at afspille en begivenhed, der har fundet sted. Han genspiller. Og operatørens opgave er at sikre, at når hændelsesloggen blev afspillet på den, er disse hændelser idempotente. Og så gentagelsen af ​​den samme begivenhed ikke bryder vores system for os. Og vores operatør klarer denne opgave.

Hej! Tak for rapporten! Dmitry Zavialov, firma Smedov. Er det planlagt at tilføje tilpasningsmuligheder med haproxy til operatøren? En anden balancer er interessant udover standarden, så den er smart og forstår, at ClickHouse er ægte der.

Taler du om Ingress?

Ja, udskift Ingress med haproxy. I haproxy kan du angive klyngetopologien, hvor den har replikaer.

Indtil videre har vi ikke tænkt over det. Hvis du har brug for det og kan forklare hvorfor det er nødvendigt, så vil det være muligt at implementere det, især hvis du ønsker at deltage. Vi overvejer gerne muligheden. Det korte svar er nej, vi har i øjeblikket ikke en sådan funktionalitet. Tak for tippet, det vil vi tage et kig på. Og hvis du også forklarer use casen og hvorfor det er nødvendigt i praksis, for eksempel at lave problemer på GitHub, så vil det være fantastisk.

Har allerede.

Bøde. Vi er åbne for alle forslag. Og haproxy er sat på todo-listen. Todo-listen vokser, ikke skrumpende endnu. Men det er godt, det betyder, at produktet er efterspurgt.

Kilde: www.habr.com