Rapporten er viet til de praktiske spørsmålene ved å utvikle en operatør i Kubernetes, designe dens arkitektur og grunnleggende operasjonsprinsipper.
I den første delen av rapporten tar vi for oss:
- hva er en operatør i Kubernetes og hvorfor er det nødvendig;
- nøyaktig hvordan operatøren forenkler administrasjonen av komplekse systemer;
- hva operatøren kan og hva operatøren ikke kan.
Deretter går vi til en diskusjon av den interne strukturen til operatøren. Vurder arkitekturen og driften til operatøren trinn for trinn. La oss analysere i detalj:
- interaksjon mellom operatøren og Kubernetes;
- hvilke funksjoner operatøren tar på seg og hvilke delegerer til Kubernetes.
Vurder å administrere shards og databasereplikaer i Kubernetes.
Deretter vil vi diskutere problemer med datalagring:
- hvordan jobbe med persistent lagring fra en operatørs synspunkt;
- fallgruvene ved å bruke lokal lagring.
I den siste delen av rapporten vil vi ta for oss praktiske eksempler på applikasjonen med Amazon eller Google Cloud Service. Rapporten er basert på eksempelet på utviklingen og driftserfaringen til operatøren for ClickHouse.
Video:
Mitt navn er Vladislav Klimenko. I dag ville jeg snakke om vår erfaring med å utvikle og drifte en operatør, og dette er en spesialisert operatør for å administrere databaseklynger. For eksempel for å administrere ClickHouse-klyngen.
Hvorfor har vi mulighet til å snakke om operatøren og ClickHouse?
- Vi støtter og utvikler ClickHouse.
- For øyeblikket prøver vi sakte å gi vårt bidrag til utviklingen av ClickHouse. Og vi er den andre etter Yandex når det gjelder mengden endringer som er gjort i ClickHouse.
- Vi prøver å lage flere prosjekter for ClickHouse-økosystemet.
Jeg vil gjerne snakke om et av disse prosjektene. Dette handler om ClickHouse-operatøren for Kubernetes.
I rapporten min vil jeg komme inn på to temaer:
- Det første emnet er hvordan vår ClickHouse-databaseoperatør fungerer i Kubernetes.
- Det andre emnet er hvordan enhver operatør fungerer, dvs. hvordan den samhandler med Kubernetes.
Disse to spørsmålene vil imidlertid krysse hverandre gjennom hele rapporten min.
Hvem vil være interessert i å høre hva jeg prøver å si?
- Det mest interessante vil være de som utnytter operatørene.
- Eller for de som ønsker å lage sine egne for å forstå hvordan det fungerer innvendig, hvordan operatøren samhandler med Kubernetes, og hvilke fallgruver som kan dukke opp.
For best mulig å forstå hva vi skal diskutere i dag, ville det være fint å vite hvordan Kubernetes fungerer og ha en grunnleggende bakgrunn innen cloud computing.
Hva er ClickHouse? Dette er en kolonnedatabase med spesifikasjoner innen online behandling av analytiske spørringer. Og det er helt åpen kildekode.
Og vi trenger bare å vite to ting. Du må vite at dette er en database, så det jeg vil fortelle deg vil gjelde for nesten alle databaser. Og det faktum at ClickHouse DBMS skalerer veldig bra gir skalerbarheten nesten lineær. Og derfor er klyngens tilstand en naturlig tilstand for ClickHouse. Og vi er mest interessert i å diskutere hvordan man kan betjene en ClickHouse-klynge i Kubernetes.
Hvorfor trengs han der? Hvorfor kan vi ikke fortsette å drive det selv? Og svarene er dels tekniske og dels organisatoriske.
- I praksis møter vi oftere og oftere en slik situasjon når i store selskaper nesten alle komponenter allerede er i Kubernetes. Forbli databaser utenfor.
- Og oftere og oftere stilles spørsmålet: "Kan den plasseres inne?". Derfor prøver store selskaper å produsere maksimal forening av ledelsen for raskt å kunne administrere datavarehusene sine.
- Og dette hjelper spesielt hvis du trenger maksimal mulighet til å gjenta det samme på et nytt sted, det vil si maksimal portabilitet.
Hvor lett eller vanskelig er det? Dette kan selvfølgelig gjøres for hånd. Men dette er ikke så lett, fordi vi legger sammen kompleksiteten ved å administrere Kubernetes selv, men samtidig pålegges detaljene til ClickHouse. Og det viser seg en slik aggregering.
Og alt sammen gir dette et ganske stort sett med teknologier, som allerede begynner å bli ganske vanskelig å administrere, fordi Kubernetes bringer sine daglige problemer til drift, og ClickHouse bringer problemene sine til daglig drift. Spesielt hvis vi har flere ClickHouses, og vi må hele tiden gjøre noe med dem.
ClickHouse med en dynamisk konfigurasjon har et ganske stort antall problemer som skaper en konstant belastning på DevOps:
- Når vi vil endre noe i ClickHouse, for eksempel, legge til en replika, en shard, så må vi administrere konfigurasjonen.
- Endre deretter dataskjemaet, fordi ClickHouse har en spesifikk skjæringsmetode. Der er det nødvendig å legge ut dataskjemaet, legge ut konfigurasjoner.
- Du må sette opp overvåking.
- Innsamling av tømmerstokker for nye skår, for nye kopier.
- Ta vare på restitusjonen.
- Og start på nytt.
Dette er slike rutinearbeid som jeg veldig gjerne vil legge til rette for i drift.
Kubernetes selv hjelper mye i drift, men på grunnleggende systemting.
Kubernetes er flinke til å tilrettelegge og automatisere ting som:
- Gjenoppretting.
- Omstart.
- Lagringshåndtering.
Det er bra, det er riktig retning, men han er helt ute av kontakt med hvordan man driver en databaseklynge.
Jeg vil ha mer, jeg vil at hele databasen skal fungere for oss i Kubernetes.
Jeg vil gjerne ha noe sånt som en stor magisk rød knapp som du trykker på og du har en klynge distribuert og vedlikeholdt gjennom hele livssyklusen med dagligdagse oppgaver som må løses. ClickHouse-klynge i Kubernetes.
Og vi prøvde å lage en løsning som ville bidra til å lette arbeidet. Dette er ClickHouse-operatøren for Kubernetes fra Altinity.
En operatør er et program hvis hovedoppgave er å administrere andre programmer, det vil si at det er en leder.
Og den inneholder atferdsmønstre. Du kan kalle det kodifisert kunnskap om fagområdet.
Og hovedoppgaven hans er å gjøre livet enklere for DevOps og redusere mikroadministrasjon slik at han (DevOps) allerede tenker på høyt nivå, det vil si slik at han (DevOps) ikke mikromanagerer, slik at han ikke manuelt konfigurerer alle detaljer.
Og bare operatøren er en robotassistent som sliter med mikrooppgaver og hjelper DevOps.
Hvorfor trengs en operatør? Han utmerker seg på to områder:
- Når en ClickHouse-spesialist ikke har nok erfaring, men det allerede er nødvendig å betjene ClickHouse, letter operatøren driften og lar deg betjene en ClickHouse-klynge med en ganske kompleks konfigurasjon, uten å gå for mye i detalj om hvordan det hele fungerer inni. . Du gir ham bare oppgaver på høyt nivå, og det fungerer.
- Og den andre oppgaven den viser seg best i er når det er nødvendig å automatisere et stort antall typiske oppgaver. Fjerner mikrooppgaver fra systemadministratorer.
Dette er mest nødvendig enten av de som nettopp har startet reisen, eller av de som trenger å gjøre mye automatisering.
Hva er forskjellen mellom den operatørbaserte tilnærmingen og andre systemer? Det er også Helm. Det hjelper også å installere ClickHouse, du kan tegne rordiagrammer, som til og med vil installere en hel ClickHouse-klynge. Hva er da forskjellen mellom operatøren og fra samme, for eksempel Helm?
Den viktigste grunnleggende forskjellen er at Helm handler om pakkehåndtering, og operatøren går et skritt videre. Dette er støtten for hele livssyklusen. Dette er ikke bare installasjon, dette er dagligdagse oppgaver som inkluderer skalering, skjæring, det vil si alt som må gjøres i løpet av livssyklusen (om nødvendig, fjerning også) - alt dette bestemmes av operatøren. Den prøver å automatisere og betjene hele programvarens livssyklus. Dette er den grunnleggende forskjellen fra andre løsninger som presenteres.
Det var den innledende delen, la oss gå videre.
Hvordan bygger vi vår operatør? Vi prøver å nærme oss problemet for å administrere ClickHouse-klyngen som en enkelt ressurs.
Her har vi inndataene på venstre side av bildet. Dette er YAML med en klyngespesifikasjon, som klassisk sendes gjennom kubectl til Kubernetes. Der henter operatøren vår den, gjør sin magi. Og som et resultat får vi en slik ordning. Dette er implementeringen av ClickHouse i Kubernetes.
Og så skal vi sakte se på hvordan operatøren jobber, hvilke typiske oppgaver som kan løses. Vi vil kun vurdere typiske oppgaver, fordi vi har begrenset tid. Og det blir ikke fortalt om alt som operatøren kan bestemme.
La oss starte fra praksis. Prosjektet vårt er helt åpen kildekode, så du kan se hvordan det fungerer på GitHub. Og du kan gå videre fra betraktningene, hvis du bare vil starte, så kan du begynne med hurtigstartguiden.
Hvis du ønsker å forstå i detalj, så prøver vi å vedlikeholde dokumentasjonen i en mer eller mindre anstendig form.
La oss starte med et praktisk problem. Den første oppgaven vi alle ønsker å starte med er å kjøre det første eksemplet på en eller annen måte. Hvordan starte ClickHouse ved hjelp av en operatør, uten engang å vite hvordan det fungerer? Vi skriver et manifest, fordi all kommunikasjon med k8s er kommunikasjon gjennom manifester.
Her er et så komplekst manifest. Det vi har markert med rødt er det vi må fokusere på. Vi ber operatøren opprette en klynge kalt demo.
Foreløpig er dette grunnleggende eksempler. Lagring er ennå ikke beskrevet, men vi kommer tilbake til oppbevaring litt senere. Foreløpig vil vi observere utviklingen av klyngen i dynamikk.
Vi har laget dette manifestet. Vi mater den til operatøren vår. Han jobbet, han gjorde magi.
Vi ser på konsollen. Tre komponenter er av interesse - disse er Pod, to Service-a, StatefulSet.
Operatøren har jobbet, og vi kan se nøyaktig hva han har laget.
Han lager noe slikt. Vi har et StatefulSet, Pod, ConfigMap for hver replika, ConfigMap for hele klyngen. Nødvendigvis tjenester som inngangspunkter til klyngen.
Tjenester er den sentrale Load Balancer Service og det er mulig for hver replika, for hvert shard.
Her er vår baseklynge ser omtrent slik ut. Han er fra en enkelt node.
La oss gå videre, vi vil komplisere. Du må sønderdele klyngen.
Oppgavene våre vokser, dynamikken begynner. Vi ønsker å legge til et skår. Vi følger utviklingen. Vi endrer spesifikasjonen vår. Vi indikerer at vi ønsker to skår.
Dette er den samme filen som vi utvikler dynamisk med veksten av systemet. Det er ingen lagring, lagring vil bli diskutert videre, dette er en egen sak.
Vi mater YAML-operatøren og ser hva som skjer.
Operatøren tenkte og laget følgende enheter. Vi har allerede to Pods, tre Services og, plutselig, 2 StatefulSets. Hvorfor 2 StatefulSets?
Det var slik på diagrammet - dette er vår opprinnelige tilstand, da vi hadde en pod.
Det ble slik. Så langt er alt enkelt, det har blitt duplisert.
Og hvorfor ble StatefulSet to? Her må vi avvike og diskutere spørsmålet om hvordan Pods administreres i Kubernetes.
Det er et slikt objekt kalt StatefulSet, som lar deg lage et sett med Pods fra en mal. Nøkkelfaktoren her er mal. Og du kan kjøre mange Pods i ett StatefulSet i henhold til én mal. Og nøkkelfrasen her er "én mal mange Pods".
Og det var en stor fristelse å lage hele klyngen, pakke den inn i ett StatefulSet. Det vil fungere, det er ikke noe problem i det. Men det er ett forbehold. Hvis vi ønsker å sette sammen en heterogen klynge, det vil si fra flere versjoner av ClickHouse, begynner spørsmålene våre. Ja, StatefulSet kan gjøre en rullende oppdatering, men der kan du rulle ut en ny versjon, forklare at du ikke trenger å prøve mer enn så mange noder samtidig.
Men hvis vi ekstrapolerer oppgaven og sier at vi ønsker å lage en helt heterogen klynge og ikke ønsker å bytte fra den gamle versjonen til en ny ved hjelp av en rullende oppdatering, men bare ønsker å lage en heterogen klynge både når det gjelder forskjellige versjoner av ClickHouse og når det gjelder forskjellig lagring. Vi ønsker for eksempel å lage noen kopier på separate disker, på trege, generelt, for å bygge en heterogen klynge fullstendig. Og på grunn av det faktum at StatefulSet lager en standardisert løsning av én mal, så det er ingen måte å gjøre dette på.
Etter litt omtanke ble det bestemt at vi gjør som dette. Vi har hver replika i sitt eget StatefulSet. Det er noen ulemper med denne løsningen, men i praksis er det hele operatøren fullstendig innkapslet. Og det er mange fordeler. Vi kan bygge en helt slik klynge som vi ønsker, for eksempel en helt heterogen. Derfor, i en klynge der vi har to shards med en replika, vil vi ha 2 StatefulSets og 2 Pods nettopp fordi vi valgte denne tilnærmingen på grunn av de ovennevnte grunnene for muligheten til å bygge en heterogen klynge.
La oss gå tilbake til praktiske oppgaver. I klyngen vår må vi konfigurere brukere, dvs. du må gjøre noe konfigurasjon av ClickHouse i Kubernetes. Operatøren gir alle muligheter for dette.
Vi kan skrive hva vi vil direkte i YAML. Alle konfigurasjonsalternativer er direkte kartlagt fra denne YAML til ClickHouse-konfigurasjoner, som deretter distribueres i hele klyngen.
Du kan også skrive slik. Dette er for et eksempel. Passordet kan krypteres. Absolutt alle ClickHouse-konfigurasjonsalternativer støttes. Her er bare et eksempel.
Klyngekonfigurasjonen er distribuert som ConfigMap. I praksis skjer ikke ConfigMap-oppdateringen umiddelbart, så hvis det er en stor klynge, tar prosessen med å presse konfigurasjonen litt tid. Men alt dette er veldig praktisk å bruke.
Vi kompliserer oppgaven. Klyngen er i utvikling. Vi ønsker å replikere data. Det vil si at vi allerede har to shards, en replika hver, brukerne er konfigurert. Vi vokser og ønsker å kopiere.
Hva trenger vi for replikering?
Vi trenger ZooKeeper. I ClickHouse bygges replikering ved hjelp av ZooKeeper. ZooKeeper er nødvendig for at forskjellige ClickHouse-replikaer skal ha enighet om hvilke datablokker som er på hvilke ClickHouse.
ZooKeeper kan brukes av alle. Hvis en bedrift har en ekstern ZooKeeper, kan den brukes. Hvis ikke, kan du installere fra vårt depot. Det er et installatør som gjør det hele enklere.
Og samhandlingsskjemaet til hele systemet blir slik. Vi har Kubernetes som plattform. Den utfører ClickHouse-setningen. ZooKeeper jeg avbildet her. Og operatøren samhandler med både ClickHouse og ZooKeeper. Det vil si at det oppnås en interaksjon.
Og alt dette er nødvendig for at ClickHouse skal kunne replikere data til k8s.
La oss nå se på selve oppgaven, hvordan manifestet for replikering vil se ut.
Vi legger til to deler til manifestet vårt. Den første er hvor du kan få ZooKeeper, som kan være enten inne i Kubernetes eller ekstern. Dette er bare en beskrivelse. Og vi bestiller kopier. De. vi vil ha to kopier. Totalt skal vi ha 4 pods ved utgangen. Vi husker om lagring, den kommer tilbake litt lenger. Storage er en egen sang.
Det var slik.
Det blir slik. Replikaer er lagt til. Den 4 passet ikke, vi tror at det kan være mange av dem. Og ZooKeeper er lagt til på siden. Mønstrene blir mer komplekse.
Og det er på tide å legge til neste oppgave. Vi legger til Persistent Storage.
For Persistent Storage har vi forskjellige implementeringsalternativer.
Hvis vi kjører i en skyleverandør, for eksempel ved å bruke Amazon, Google, er det en stor fristelse å bruke skylagring. Det er veldig praktisk, det er bra.
Og det er et annet alternativ. Dette er for lokal lagring, når vi har lokale disker på hver node. Dette alternativet er mye vanskeligere å implementere, men samtidig er det mer produktivt.
La oss se hva vi har angående skylagring.
Det er fordeler. Det er veldig enkelt å konfigurere. Vi bestiller rett og slett fra en skyleverandør som vennligst gir oss lagring av slik og slik kapasitet, slik og slik klasse. Klassene males av leverandørene uavhengig.
Og det er en ulempe. For noen er dette en ukritisk mangel. Selvfølgelig vil det være noen ytelsesoverlegg. Det er veldig praktisk å bruke, pålitelig, men det er noen potensielle ulemper i ytelsen.
Og siden ClickHouse fokuserer på ytelse, du kan til og med si at det presser ut alt som er mulig, så mange kunder prøver å presse ut maksimal ytelse.
Og for å få mest mulig ut av det, trenger vi lokal lagring.
Kubernetes gir tre abstraksjoner for bruk av lokal lagring i Kubernetes. Dette:
- EmptyDir
- HostPath.
- lokal
Vurder hvordan de er forskjellige, hvordan de er like.
For det første, i alle tre tilnærmingene, har vi lagring - dette er lokale disker som er plassert på den samme fysiske k8s-noden. Men de har noen forskjeller.
La oss starte med det enkleste, dvs. tommeDir. Hva er det i praksis? Det er vi som ber containeriseringssystemet (oftest Docker) fra vår spesifikasjon om å gi oss tilgang til en mappe på en lokal disk.
I praksis oppretter docker en midlertidig mappe et sted i sine egne baner, kaller det en lang hash. Og gir et grensesnitt for å få tilgang til det.
Hvordan vil den prestere når det gjelder ytelse? Dette vil kjøre med hastigheten til den lokale disken, dvs. dette er full tilgang til skruen din.
Men denne saken har sin ulempe. Vedvarende i dette tilfellet er ganske tvilsomt. Ved den første bevegelsen av havnearbeideren med containere, går Persistent tapt. Hvis Kubernetes ønsker å flytte denne Poden til en annen disk av en eller annen grunn, vil dataene gå tapt.
Denne tilnærmingen er bra for tester, fordi den allerede viser normal hastighet, men dette alternativet er ikke egnet for noe alvorlig.
Derfor er det en annen tilnærming. Dette er hostPath. Hvis du ser på forrige lysbilde og dette, kan du bare se én forskjell. Mappen vår forlot docker direkte til Kubernetes-noden. Det går litt fortere her. Vi skriver direkte banen på det lokale filsystemet der vi ønsker å lagre dataene våre.
Denne metoden har fordeler. Dette er allerede en ekte Persistent, og en klassisk en. På disken vår vil data bli skrevet til en eller annen adresse.
Det er også ulemper. Dette er kompleksiteten i ledelsen. Våre Kubernetes vil kanskje flytte Pod til en annen fysisk node. Det er her DevOps kommer inn i bildet. Det må korrekt forklare hele systemet at du bare kan flytte disse podene til slike noder som du har noe montert på langs disse banene, og ikke mer enn én node om gangen. Det er vanskelig nok.
Spesielt for disse formålene har vi laget maler i vår operatør for å skjule all denne kompleksiteten. Og du kan bare si: "Jeg vil ha en forekomst av ClickHouse per fysisk node og langs en slik og en slik bane."
Men dette behovet er ikke bare for oss, så herrene fra Kubernetes selv forstår også at folk ønsker å ha tilgang til fysiske disker, så de gir et tredje nivå.
Det kalles lokalt. Det er praktisk talt ingen forskjell fra forrige lysbilde. Bare tidligere var det nødvendig å utføre for hånd at vi ikke kan overføre disse podene fra node til node, fordi de må festes langs en slik og en bane til den lokale fysiske disken, og nå er all denne kunnskapen innkapslet i Kubernetes selv. Og det viser seg mye enklere å konfigurere.
La oss gå tilbake til vår praktiske oppgave. La oss gå tilbake til YAML-malen. Her har vi et skikkelig lager. Vi er tilbake til dette. Vi setter den klassiske VolumeClaim-malen som i k8s. Og vi beskriver hva slags oppbevaring vi ønsker.
Etter det vil k8s be om lagring. Tildel det til oss i StatefulSet. Og til slutt vil det vise seg til disposisjon for ClickHouse.
Vi hadde et slikt opplegg. Vår vedvarende lagring var rød, noe som så ut til å antyde at det burde gjøres.
Og den blir grønn. Nå er ClickHouse på k8s-klyngeordningen fullstendig ferdigstilt. Vi har skår, replikaer, ZooKeeper, vi har ekte Persistent, som er implementert på en eller annen måte. Ordningen er allerede fullt funksjonell.
Vi fortsetter å leve videre. Klyngen vår vokser. Og Aleksey prøver å gi ut en ny versjon av ClickHouse.
En praktisk oppgave dukker opp - å teste den nye versjonen av ClickHouse på klyngen vår. Og, selvfølgelig, jeg vil ikke rulle alt ut, jeg vil legge en ny versjon et sted i det fjerne hjørnet i en kopi, eller kanskje ikke en ny versjon, men to på en gang, fordi de kommer ut ofte.
Hva kan vi si om dette?
Her har vi nettopp en slik mulighet. Dette er pod-maler. Du kan male, vår operatør lar deg bygge en heterogen klynge. De. konfigurere, fra alle replikaer i en haug, og slutter med hver personlig replika, hvilken versjon vi vil ha ClickHouse, hvilken versjon vi ønsker lagring. Vi kan fullt ut konfigurere klyngen i en slik konfigurasjon som vi trenger.
La oss gå dypere inn litt. Før det snakket vi om hvordan ClickHouse-operatøren fungerer i forhold til detaljene til ClickHouse.
Nå vil jeg gjerne si noen ord om hvordan enhver operatør fungerer generelt, samt hvordan den samhandler med K8-er.
Vurder interaksjon med K8s til å begynne med. Hva skjer når vi søker kubectl? Gjennom API vises objektene våre i etcd.
For eksempel, de grunnleggende Kubernetes-objektene: pod, StatefulSet, service og så videre gjennom listen.
Men ingenting fysisk skjer ennå. Disse objektene må materialiseres i en klynge.
Det er her kontrolleren kommer inn. Kontrolleren er en spesiell k8s-komponent som kan materialisere disse beskrivelsene. Han vet hvordan og hva han skal gjøre fysisk. Han vet hvordan man kjører containere, hva som må konfigureres der for at serveren skal fungere.
Og det materialiserer objektene våre i K8s.
Men vi ønsker å operere ikke bare med pods, StatefulSets, vi ønsker å lage en ClickHouseInstallation, det vil si et objekt av typen ClickHouse, for å kunne operere med det som en helhet. Så langt er det ingen slik mulighet.
Men K8s har en annen fin ting. Vi vil at vi skal ha en så kompleks enhet et sted, der klyngen vår vil bli satt sammen fra pods og StatefulSet.
Og hva bør gjøres for dette? Først kommer Custom Resource Definition inn i scenen. Hva det er? Dette er en beskrivelse for K8s som du vil ha en annen datatype som vi ønsker å legge til poden, StatefulSet, en tilpasset ressurs som vil være kompleks inni. Dette er en beskrivelse av datastrukturen.
Vi sender den også dit via kubectl application. Kubernetes tok det med glede.
Og nå i vårt lager har objektet i etcd muligheten til å skrive en tilpasset ressurs kalt ClickHouseInstallation.
Men foreløpig vil ingenting annet skje. Det vil si, hvis vi nå lager en YAML-fil som vi vurderte med en beskrivelse av shard, replikaer og sier "kubectl apply", så vil Kubernetes godta den, legge den inn i etcd og si: "Flott, men jeg vet ikke hva skal man gjøre med det. Jeg vet ikke hvordan jeg vedlikeholder ClickHouseInstallation."
Derfor trenger vi noen til å hjelpe Kubernetes med å betjene den nye datatypen. Til venstre har vi en lager Kubernetes-kontroller som fungerer med lagerdatatyper. Og til høyre bør vi ha en tilpasset kontroller som kan jobbe med tilpassede datatyper.
Og på en annen måte kalles det en operatør. Jeg tok det spesielt ut her for Kubernetes, fordi det også kan kjøres utenfor K8s. Oftest blir selvfølgelig alle utsagn utført i Kubernetes, men ingenting hindrer den i å stå utenfor, så her er den spesielt hentet frem.
Og allerede på sin side samhandler den tilpassede kontrolleren, også kjent som operatøren, med Kubernetes gjennom API. Han vet allerede hvordan han skal samhandle med API. Og han vet allerede hvordan han skal materialisere et komplekst opplegg som vi ønsker å lage fra en tilpasset ressurs. Det er akkurat det operatøren gjør.
Hvordan fungerer operatøren? La oss ta en titt på høyre side for å se hvordan han gjør det. Vi vil finne ut hvordan operatøren materialiserer alt dette og hvordan videre interaksjon med K8s foregår.
Operatøren er programmet. Hun er arrangementsorientert. Operatøren abonnerer på hendelser ved hjelp av Kubernetes API. Kubernetes API har inngangspunkter der du kan abonnere på arrangementer. Og hvis noe endres i K8s, så sender Kubernetes hendelser til alle, dvs. som abonnerer på dette API-punktet vil motta varsler.
Operatøren abonnerer på hendelser, og må gjøre en form for reaksjon. Dens oppgave er å reagere på nye hendelser.
Hendelser genereres av noen oppdateringer. YAML-filen vår kommer med en beskrivelse av ClickHouseInstallation. Han gikk til etcd via kubectl application. Et arrangement fungerte der, som et resultat kom denne hendelsen til ClickHouse-operatøren. Operatøren mottok denne beskrivelsen. Og han må gjøre noe. Hvis en oppdatering kom til ClickHouseInstallation-objektet, må du oppdatere klyngen. Og operatørens oppgave er å oppdatere klyngen.
Hva er det han gjør? Først må vi lage en handlingsplan for hva vi skal gjøre med denne oppdateringen. Oppdateringer kan være svært små, dvs. liten i YAML-utførelse, men kan føre til svært store endringer på klyngen. Derfor lager operatøren en plan, og deretter holder han seg til den.
Han begynner, i henhold til denne planen, å koke denne strukturen inne for å materialisere pods, tjenester, d.v.s. å gjøre det som er hovedoppgaven. Det er som å bygge en ClickHouse-klynge i Kubernetes.
La oss nå berøre en så interessant ting. Dette er en ansvarsfordeling mellom Kubernetes og operatøren, d.v.s. hva Kubernetes gjør, hva operatøren gjør og hvordan de samhandler med hverandre.
Kubernetes er ansvarlig for systemting, dvs. for et grunnleggende sett med objekter som kan tolkes som et systemomfang. Kubernetes vet hvordan man starter pods, hvordan man starter beholdere på nytt, hvordan man monterer volumer, hvordan man jobber med ConfigMap, dvs. alt som kan kalles et system.
Operatører opererer innen fagområder. Hver operatør er laget for sitt fagområde. Vi laget for ClickHouse.
Og operatøren samhandler nøyaktig når det gjelder fagområdet, som å legge til en kopi, lage et opplegg, sette opp overvåking. Det er et slikt skille.
La oss se på et praktisk eksempel på hvordan denne separasjonen av bekymringer oppstår når vi gjør en add replika-handling.
Oppgaven kommer til operatøren - å legge til en kopi. Hva gjør operatøren? Operatøren vil beregne at det er nødvendig å lage et nytt StatefulSet, der det er nødvendig å beskrive slike og slike maler, volumkrav.
Han forberedte alt og gir det videre til K8s. Han sier at han trenger ConfigMap, StatefulSet, Volume. Kubernetes fungerer. Han materialiserer de grunnleggende enhetene han opererer med.
Og så kommer ClickHouse-operatør inn i bildet igjen. Han har allerede en fysisk pod som du allerede kan gjøre noe på. Og ClickHouse-operatør fungerer igjen med tanke på fagområdet. De. Spesifikt, ClickHouse, for å inkludere en replika i en klynge, må du først konfigurere dataskjemaet som finnes i denne klyngen. Og for det andre må denne merknaden tas med i overvåkingen slik at den kan spores tydelig. Operatøren har allerede satt den opp.
Og først etter det kommer selve ClickHouse inn i bildet, dvs. en annen enhet på høyere nivå. Det er allerede en database. Den har sin egen forekomst, den neste konfigurerte replikaen, som er klar til å bli med i klyngen.
Det viser seg at kjeden av utførelse og separasjon av ansvar når du legger til en kopi er lang nok.
Vi fortsetter våre praktiske oppgaver. Hvis klyngen allerede eksisterer, kan du migrere konfigurasjonen.
Vi gjorde det slik at det er mulig å gå gjennom i eksisterende xml, som ClickHouse forstår.
Du kan finjustere ClickHouse. Bare sonet distribusjon er det jeg snakket om da jeg forklarte hostPath, lokal lagring. Dette er hvordan du gjør sonedistribusjon riktig.
Den neste praktiske oppgaven er overvåking.
Hvis klyngen vår endres, må vi med jevne mellomrom konfigurere overvåking.
La oss ta en titt på diagrammet. Vi har allerede vurdert de grønne pilene her. La oss nå se på de røde pilene. Det er slik vi ønsker å overvåke klyngen vår. Hvordan beregninger fra ClickHouse-klyngen kommer inn i Prometheus og deretter til Grafana.
Hva er problemet med overvåking? Hvorfor presenteres dette som en slags prestasjon? Vanskeligheten ligger i dynamikken. Når vi har en klynge og den er statisk, så kan du sette opp overvåking en gang og ikke bry deg mer.
Men hvis vi har mange klynger, eller noe er i konstant endring, så er prosessen dynamisk. Og å konstant rekonfigurere overvåking er bortkastet ressurser og tid; selv bare lat. Dette må automatiseres. Vanskeligheten ligger i dynamikken i prosessen. Og operatøren automatiserer dette veldig bra.
Hvordan utviklet klyngen vår seg? I begynnelsen var han slik.
Da var han slik.
Til slutt ble han slik.
Og overvåking gjøres automatisk av operatøren. Enkelt inngangspunkt.
Og vi ser bare på utgangen i Grafana-dashbordet, hvordan livet til klyngen vår koker inni.
Grafana dashboard er forresten også distribuert med vår operatør rett i kildekoden. Du kan koble til og bruke. Dette skjermbildet ble gitt til meg av våre DevOps.
Hvor vil vi dra videre? Dette:
- Utvikle testautomatisering. Hovedoppgaven er automatisert testing av nye versjoner.
- Vi ønsker også virkelig å automatisere integrasjonen med ZooKeeper. Og planlegger å integrere med ZooKeeper-operatør. De. Det er skrevet en operatør for ZooKeeper, og det er logisk at de to operatørene begynner å integrere seg for å bygge en mer praktisk løsning.
- Vi ønsker å gjøre mer komplekse livssjekker.
- Jeg markerte med grønt at vi har malarv på vei – FERDIG, dvs. med neste utgivelse av operatøren vil vi allerede ha malarv. Dette er et kraftig verktøy som lar deg bygge komplekse konfigurasjoner fra deler.
- Og vi ønsker å automatisere komplekse oppgaver. Den viktigste er Re-sharding.
La oss gjøre noen mellomresultater.
Hva får vi som resultat? Og er det verdt det eller ikke? Trenger jeg i det hele tatt å prøve å dra databasen inn i Kubernetes og bruke operatøren generelt og Alitnity-operatøren spesielt.
Ved utgangen får vi:
- Dramatisk forenkle og automatisere konfigurasjon, distribusjon og vedlikehold.
- Umiddelbart innebygd overvåking.
- Og klare til bruk kodifiserte maler for komplekse situasjoner. Allerede handlingen av typen for å legge til en kopi trenger ikke å gjøres for hånd. Dette gjøres av operatøren.
Bare det siste spørsmålet gjenstår. Vi har allerede en database i Kubernetes, virtualisering. Hva med ytelsen til en slik løsning, spesielt siden ClickHouse er optimalisert for ytelse?
Svaret er at alt er bra! Jeg vil ikke beskrive i detalj, dette er tema for en egen rapport.
Men det finnes et slikt prosjekt som TSBS. Hva er hovedoppgaven? Dette er en databaseytelsestest. Dette er et forsøk på å sammenligne varm med varm, myk med myk.
Hvordan jobber han? Ett sett med data genereres. Da kjøres dette datasettet på samme testsett på forskjellige databaser. Og hver database løser ett problem slik den kan. Og så kan du sammenligne resultatene.
Den støtter allerede en stor haug med databaser. Jeg har identifisert tre hovedtrekk. Dette:
- tidsskalertb.
- InfluxDB.
- klikkhus.
Det ble også gjort en sammenligning med en annen lignende løsning. Sammenligning med RedShift. Sammenligningen ble gjort på Amazon. ClickHouse ligger også godt foran alle i denne saken.
Hvilke konklusjoner kan trekkes fra det jeg har sagt?
- DB i Kubernetes er mulig. Sannsynligvis kan du gjøre hva som helst, men generelt ser det ut som du kan. ClickHouse i Kubernetes er definitivt mulig ved hjelp av vår operatør.
- Operatøren hjelper til med å automatisere prosesser og forenkler virkelig livet.
- Ytelsen er normal.
- Og det ser ut til at det kan og bør brukes.
Åpen kildekode - bli med oss!
Operatøren er som sagt et helt åpen kildekode-produkt, så det ville vært veldig bra om maksimalt antall personer brukte det. Bli med nå! Vi venter på dere alle!
Takk alle!
spørsmål
Takk for rapporten! Mitt navn er Anton. Jeg er fra SEMrush. Jeg lurer på hva som skjer med loggingen. Vi hører om overvåking, men ingenting om logging, hvis vi snakker om hele klyngen. For eksempel har vi en klynge på maskinvare. Og vi bruker sentralisert logging, vi samler det i en felles haug med standard midler. Og derfra får vi data som er interessante for oss.
Godt spørsmål, dvs. å logge på gjøremålslisten. Vår operatør automatiserer ikke dette ennå. Det er fortsatt i utvikling, prosjektet er fortsatt ganske ungt. Vi forstår behovet for logging. Dette er også et veldig viktig tema. Og det er nok ikke mindre viktig enn overvåking. Men først på listen for implementering var overvåking. Det blir logging. Naturligvis prøver vi å automatisere alle aspekter av klyngens liv. Derfor er svaret at for øyeblikket vet dessverre ikke operatøren hvordan dette skal gjøres, men det ligger i planene, vi skal gjøre det. Hvis du vil være med, så trekk forespørselen, takk.
Hallo! Takk for rapporten! Jeg har et standardspørsmål knyttet til Persistent Volumes. Når vi oppretter en konfigurasjon med denne operatøren, hvordan bestemmer operatøren på hvilken node vi har en disk eller mappe? Vi må først forklare ham at, vær så snill, plasser vårt ClickHouse nøyaktig på disse nodene som har en disk?
Så vidt jeg forstår er dette spørsmålet en fortsettelse av lokal lagring, spesielt hostPath-delen av den. Det er som å forklare hele systemet at det er nødvendig at poden lanseres nøyaktig på en slik og en node, som vi har en fysisk tilkoblet disk på, som er montert på en slik og en bane. Dette er et helt avsnitt som jeg berørte veldig overfladisk, fordi svaret der er ganske stort.
Kort fortalt ser det slik ut. Selvfølgelig må vi sørge for tilførsel av disse volumene. For øyeblikket er det ingen dynamisk bestemmelse i lokal lagring, så DevOps må kutte diskene selv, her er disse volumene. Og de må forklare Kubernetes klargjøring, at du vil ha vedvarende volumer av en slik og en slik klasse, som er plassert på slike og slike noder. Da vil det være nødvendig å forklare Kubernetes at poder som krever en slik og en lokal lagringsklasse må planlegges i henhold til etiketter kun til slike og slike noder. For disse formålene har operatøren muligheten til å tilordne en slags etikett og en per vertsforekomst. Og det viser seg at pods vil bli rutet av Kubernetes til å kjøre kun på noder som oppfyller kravene, etiketter, på en enkel måte. Administratorer tildeler etiketter, gjør klargjøring av disker for hånd. Og så skalerer den.
Og bare det tredje alternativet lokalt bidrar til å gjøre det litt enklere. Som jeg allerede har understreket, er dette et møysommelig arbeid med tuning, som til syvende og sist bidrar til å få maksimal ytelse.
Jeg har et annet spørsmål knyttet til dette. Kubernetes ble unnfanget på en slik måte at det ikke spiller noen rolle for oss om vi mister en node eller ikke. Hva skal vi gjøre i dette tilfellet hvis vi har mistet noden der vi har et skår?
Ja, Kubernetes var opprinnelig posisjonert at forholdet vårt til belgene våre er som storfe, men her blir hver disk noe som et kjæledyr. Det er et slikt problem at vi ikke bare kan kaste dem. Og utviklingen av Kubernetes går i retning av at det er umulig å fullstendig behandle den filosofisk, som en fullstendig forkastet ressurs.
Nå et praktisk spørsmål. Hva gjør du hvis du mistet noden som disken var på? Her er problemet løst på et høyere nivå. Når det gjelder ClickHouse har vi replikaer som fungerer på et høyere nivå, dvs. på ClickHouse-nivå.
Hva er disposisjonen? DevOps er ansvarlig for å sikre at data ikke går tapt. Den må konfigurere replikering riktig og sikre at replikering kjører. I replikaen på ClickHouse-nivå må dataene dupliseres. Dette er ikke oppgaven operatøren løser. Og ikke oppgaven som Kubernetes selv løser. Dette er på ClickHouse-nivå.
Hva gjør du hvis jernnoden din har falt av? Og det viser seg at det vil være nødvendig å sette den andre, flytte disken ordentlig på den, bruke etiketter. Og etter det vil den tilfredsstille kravene om at Kubernetes på den kan kjøre en pod-forekomst. Kubernetes vil lansere den. Antallet pods er ikke nok til den angitte. Den vil gå gjennom syklusen som jeg viste. Og på høyeste nivå vil ClickHouse forstå at vi har lagt inn en replika, den er fortsatt tom og vi må begynne å overføre data til den. De. denne prosessen er fortsatt dårlig automatisert.
Takk for rapporten! Når alle slags ekle ting skjer, krasjer operatøren og starter på nytt, og i det øyeblikket kommer hendelser, behandler du dette på en eller annen måte?
Hva skjer hvis operatøren krasjer og starter på nytt, ja?
Ja. Og i det øyeblikket kom hendelsene.
Oppgaven med hva du skal gjøre i dette tilfellet er delvis delt mellom operatøren og Kubernetes. Kubernetes har muligheten til å spille av en hendelse som har skjedd. Han spiller om. Og operatørens oppgave er å sørge for at når hendelsesloggen ble spilt av på den, er disse hendelsene idempotente. Og slik at gjentakelsen av den samme hendelsen ikke ødelegger systemet vårt for oss. Og vår operatør takler denne oppgaven.
Hallo! Takk for rapporten! Dmitry Zavialov, selskap Smedov. Er det planlagt å legge til tilpasningsalternativer med haproxy til operatøren? En annen balanserer er interessant i tillegg til standarden, slik at den er smart og forstår at ClickHouse er ekte der.
Snakker du om Ingress?
Ja, bytt ut Ingress med haproxy. I haproxy kan du spesifisere klyngetopologien der den har replikaer.
Så langt har vi ikke tenkt på det. Hvis du trenger det og kan forklare hvorfor det trengs, så vil det være mulig å implementere det, spesielt hvis du ønsker å delta. Vi vurderer gjerne alternativet. Det korte svaret er nei, vi har foreløpig ikke slik funksjonalitet. Takk for tipset, vi skal ta en titt på dette. Og hvis du også forklarer brukssaken og hvorfor det er nødvendig i praksis, for eksempel opprette problemer på GitHub, så vil det være flott.
Har allerede.
Fint. Vi er åpne for alle forslag. Og haproxy er satt på gjøremålslisten. Todo-listen vokser, den krymper ikke ennå. Men dette er bra, det betyr at produktet er etterspurt.
Kilde: www.habr.com