Local<\/li>\n<\/ul>\n<\/p>\n
La oss se p\u00e5 hvordan de skiller seg fra hverandre, og hva de har til felles. <\/p>\n
<\/p>\n
For det f\u00f8rste, i alle tre tiln\u00e6rmingene har vi storage \u2013 lokale disker som ligger p\u00e5 den samme fysiske k8s noden. Men de har noen forskjeller.<\/p>\n
<\/p>\n
<\/p>\n
La oss begynne med det enkleste, det vil si med emptyDir. Hva er dette i praksis? Det er at vi ber systemet for containere (oftest er det Docker) om \u00e5 gi oss tilgang til en mappe p\u00e5 den lokale disken.<\/p>\n
<\/p>\n
I praksis oppretter Docker et sted der borte med sine egne stier en midlertidig mappe, navn gitt som en lang hash. Og den gir tilgangsgrensesnitt til den. <\/p>\n
<\/p>\n
Hvordan vil dette fungere med ytelsen? Dette vil fungere med hastigheten til den lokale disken, dvs. det er full tilgang til sin egen harddisk. <\/p>\n
<\/p>\n
Men dette har en ulempe. Persistensen er ganske tvilsom. Ved den f\u00f8rste bevegelsen av Docker med containerne g\u00e5r persistensen tapt. Hvis Kubernetes av en eller annen grunn \u00f8nsker \u00e5 flytte denne Pod-en til en annen disk, vil dataene g\u00e5 tapt. <\/p>\n
<\/p>\n
Denne tiln\u00e6rmingen er bra for tester, fordi den viser grei hastighet, men for noe seri\u00f8st er ikke dette alternativet passende. <\/p>\n
<\/p>\n
<\/p>\n
Derfor er det en annen tiln\u00e6rming. Dette er hostPath. Hvis vi ser p\u00e5 det forrige lyset og dette, kan vi se \u00e9n eneste forskjell. Mappen v\u00e5r har g\u00e5tt fra Docker direkte til Kubernetes-noden. Her er det litt enklere. Vi skriver rett ut hvilken sti vi \u00f8nsker \u00e5 bruke p\u00e5 det lokale filsystemet for \u00e5 lagre v\u00e5re data. <\/p>\n
<\/p>\n
Fordelene med denne metoden er reelle. Dette er allerede ekte persistering, og dessuten klassisk. Vi vil ha data lagret p\u00e5 disken et bestemt sted. <\/p>\n
<\/p>\n
Det finnes ogs\u00e5 ulemper. Dette er kompleksiteten ved administrasjon. V\u00e5r Kubernetes kan \u00f8nske \u00e5 flytte en Pod til en annen fysisk node. Og da kommer DevOps inn i bildet. Han m\u00e5 forklare systemet korrekt at disse pod'ene bare kan flyttes til noder der du har noe montert p\u00e5 disse stiene, og ikke mer enn en node av gangen. Dette er ganske komplisert. <\/p>\n
<\/p>\n
Spesielt for disse form\u00e5lene har vi laget maler for \u00e5 skjule all denne kompleksiteten. Man kunne enkelt si: \u00abJeg \u00f8nsker at det skal v\u00e6re \u00e9n instans av ClickHouse p\u00e5 hver fysisk node og p\u00e5 denne stien\u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Men dette behovet gjelder ikke bare oss, derfor forst\u00e5r gutta i Kubernetes ogs\u00e5 at folk \u00f8nsker tilgang til fysiske disker, s\u00e5 de tilbyr et tredje niv\u00e5.<\/p>\n
<\/p>\n
Det kalles lokal. Forskjellen fra forrige lysbilde er praktisk talt ingen. Tidligere m\u00e5tte man gj\u00f8re det manuelt, at pod'ene ikke kan flyttes fra node til node fordi de m\u00e5 v\u00e6re festet til en bestemt sti til en lokal fysisk disk, men n\u00e5 er all denne kunnskapen innkapslet i Kubernetes selv. Og det blir mye enklere \u00e5 konfigurere.<\/p>\n
<\/p>\n
<\/p>\n
La oss g\u00e5 tilbake til v\u00e5r praktiske oppgave. La oss g\u00e5 tilbake til YAML-malen. Her har vi f\u00e5tt en ekte lagring. Vi har kommet tilbake til dette. Vi definerer en klassisk VolumeClaim-mal som i k8s. Og beskriver hvilken lagring vi \u00f8nsker.<\/p>\n
<\/p>\n
Etter dette vil k8s be om lagring. Den vil tildele oss det i StatefulSet. Og til slutt vil det bli tilgjengelig for ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Vi hadde et slikt skjema. V\u00e5r Persistent Storage var r\u00f8d, noe som antydet at det burde gj\u00f8res noe med det. <\/p>\n
<\/p>\n
<\/p>\n
Og det blir gr\u00f8nt. N\u00e5 er skjemaet for ClickHouse-klyngen p\u00e5 k8s helt ferdigstilt. Vi har shard, replikaer, ZooKeeper, og det er ekte Persistent, som er implementert p\u00e5 en eller annen m\u00e5te. Skjemaet er allerede helt operativt. <\/p>\n
<\/p>\n
<\/p>\n
Vi fortsetter \u00e5 leve videre. Klyngen v\u00e5r utvikler seg. Og Alexey jobber hardt og slipper en ny versjon av ClickHouse.<\/p>\n
<\/p>\n
Det oppst\u00e5r en praktisk oppgave \u2013 \u00e5 teste den nye versjonen av ClickHouse p\u00e5 v\u00e5r klynge. Og selvf\u00f8lgelig \u00f8nsker vi ikke \u00e5 rulle den ut helt, vi \u00f8nsker \u00e5 sette en ny versjon i et hj\u00f8rne, og kanskje ikke bare \u00e9n ny versjon, men to samtidig, fordi de lanseres ganske ofte. <\/p>\n
<\/p>\n
Hva kan vi si om dette?<\/p>\n
<\/p>\n
<\/p>\n
Her har vi nettopp en slik mulighet. Dette er maler for pod\u2019er. Man kan spesifisere, v\u00e5r operator lar oss fullt ut bygge et heterogent kluster. Dvs. konfigurere, fra alle replikene sammen, til hver enkelt replik som hvilken versjon av ClickHouse vi \u00f8nsker, hvilken versjon av lagring vi \u00f8nsker. Vi kan fullstendig konfigurere klusteret i den konfigurasjonen vi trenger. <\/p>\n
<\/p>\n
<\/p>\n
Vi skal dykke litt dypere. F\u00f8r dette snakket vi om hvordan ClickHouse-operatoren fungerer spesifikt for ClickHouse.<\/p>\n
<\/p>\n
N\u00e5 vil jeg gjerne si noen ord om hvordan hvilken som helst operator fungerer, samt hvordan den interagerer med K8s.<\/p>\n
<\/p>\n
<\/p>\n
La oss f\u00f8rst se p\u00e5 interaksjonen med K8s. Hva skjer n\u00e5r vi kj\u00f8rer kubectl apply? V\u00e5re objekter dukker opp i etcd via API. <\/p>\n
<\/p>\n
<\/p>\n
For eksempel de grunnleggende Kubernetes-objektene: pod, StatefulSet, service og s\u00e5 videre. <\/p>\n
<\/p>\n
Samtidig skjer det ingen fysiske endringer enn\u00e5. Disse objektene m\u00e5 materialiseres i klusteret. <\/p>\n
<\/p>\n
<\/p>\n
For dette dukker det opp en kontroller. Kontrolleren er en spesialkomponent i k8s, som kan materialisere disse beskrivelsene. Den vet hva som m\u00e5 gj\u00f8res fysisk. Den vet hvordan man starter containere, hva som m\u00e5 settes opp for at serveren skal fungere. <\/p>\n
<\/p>\n
<\/p>\n
Og den materialiserer v\u00e5re objekter i K8s.<\/p>\n
<\/p>\n
Men vi \u00f8nsker \u00e5 operere ikke bare med pod\u2019er, StatefulSet\u2019er, vi \u00f8nsker \u00e5 opprette ClickHouseInstallation, alts\u00e5 et objekt av typen ClickHouse, s\u00e5 vi kan operere med det som en helhet. Forel\u00f8pig finnes det ikke en slik mulighet. <\/p>\n
<\/p>\n
<\/p>\n
Men K8s har en annen nyttig funksjon. Vi \u00f8nsker at det skal oppst\u00e5 en slik kompleks enhet, der v\u00e5rt kluster er samlet fra pod\u2019er og StatefulSet\u2019er. <\/p>\n
<\/p>\n
<\/p>\n
Hva m\u00e5 vi gj\u00f8re for dette? F\u00f8rst og fremst kommer Custom Resource Definition inn p\u00e5 scenen. Hva er dette? Dette er en beskrivelse for K8s, som sier at du vil ha en annen datatyper, at vi \u00f8nsker \u00e5 legge til en tilpasset ressurs til pod, StatefulSet, som vil v\u00e6re kompleks innvendig. Dette er beskrivelsen av dataskrukturen. <\/p>\n
<\/p>\n
<\/p>\n
Vi sender det ogs\u00e5 dit via kubectl apply. Kubernetes tok det med glede. <\/p>\n
<\/p>\n
Og n\u00e5 har vi i lagringen, for objektet i etcd, muligheten til \u00e5 registrere den tilpassede ressursen med navnet ClickHouseInstallation.<\/p>\n
<\/p>\n
Men inntil videre skjer det ikke noe mer. Det vil si, hvis vi n\u00e5 lager en YAML-fil som vi har diskutert med beskrivelse av shards, replikaer, og sier \u00abkubectl apply\u00bb, s\u00e5 vil Kubernetes godta den, lagre den i etcd og si: \u00abFlott, men hva skal jeg gj\u00f8re med den? Jeg vet ikke hvordan jeg skal h\u00e5ndtere ClickHouseInstallation\u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Derfor trenger vi noen som kan hjelpe Kubernetes med \u00e5 h\u00e5ndtere en ny type data. Til venstre har vi den innebygde Kubernetes-kontrolleren som arbeider med innebygde datatyper. Og til h\u00f8yre m\u00e5 vi ha en egendefinert kontroller som kan arbeide med egendefinerte datatyper. <\/p>\n
<\/p>\n
Og den kalles ogs\u00e5 en operator. Jeg har spesifikt plassert den utenfor Kubernetes her, fordi den kan kj\u00f8re ogs\u00e5 utenfor K8s. Ofte kj\u00f8rer selvf\u00f8lgelig alle operatorene i Kubernetes, men ingenting hindrer den fra \u00e5 st\u00e5 utenfor, s\u00e5 derfor er den spesifikt plassert utenfor. <\/p>\n
<\/p>\n
<\/p>\n
Den egendefinerte kontrolleren, som er operat\u00f8ren, interagerer med Kubernetes via API. Den vet allerede hvordan den skal interagere med API-en. Og den vet allerede hvordan man kan materialisere den komplekse strukturen fra den egendefinerte ressursen som vi \u00f8nsker. Det er nettopp dette operat\u00f8ren gj\u00f8r. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan fungerer operat\u00f8ren? La oss se til h\u00f8yre for \u00e5 finne ut hvordan den gj\u00f8r dette. Vi vil finne ut hvordan operat\u00f8ren materialiserer alt dette, og hvordan interaksjonen med K8s fortsetter.<\/p>\n
<\/p>\n
<\/p>\n
En operat\u00f8r er et program. Den er hendelsesdrevet. Operat\u00f8ren abonnerer p\u00e5 hendelser ved hjelp av Kubernetes API. I Kubernetes API finnes det tilgangspunkter hvor man kan abonnere p\u00e5 hendelser. Og hvis noe endres i K8s, s\u00e5 sender Kubernetes hendelser til alle som \u00f8nsker det, det vil si, de som abonnerte p\u00e5 dette API-punktet vil motta varsler.<\/p>\n
<\/p>\n
Operat\u00f8ren abonnerer p\u00e5 hendelser og m\u00e5 reagere p\u00e5 dem. Dens oppgave er \u00e5 reagere p\u00e5 de nye hendelsene som dukker opp. <\/p>\n
<\/p>\n
<\/p>\n
Hendelsene genereres av oppdateringer. V\u00e5r YAML-fil med beskrivelsen av ClickHouseInstallation kommer inn. Den g\u00e5r gjennom kubectl apply til etcd. Der trer det inn en hendelse, og denne hendelsen kommer til ClickHouse-operat\u00f8ren. Operat\u00f8ren mottar denne beskrivelsen. Og den m\u00e5 gj\u00f8re noe. Hvis det kommer en oppdatering p\u00e5 ClickHouseInstallation-objektet, s\u00e5 m\u00e5 klusteret oppdateres. Og operat\u00f8rens oppgave er \u00e5 oppdatere klusteret. <\/p>\n
<\/p>\n
<\/p>\n
Hva gj\u00f8r han? For det f\u00f8rste m\u00e5 vi lage en handlingsplan for hva vi skal gj\u00f8re med denne oppdateringen. Oppdateringer kan v\u00e6re veldig sm\u00e5, dvs. sm\u00e5 i YAML-implementeringen, men kan f\u00f8re til store endringer i klusteret. Derfor lager operat\u00f8ren en plan, og s\u00e5 f\u00f8lger han den.<\/p>\n
<\/p>\n
<\/p>\n
Han begynner i henhold til denne planen \u00e5 lage strukturen internt for \u00e5 materialisere podder, tjenester, dvs. gj\u00f8re det som er hans hovedoppgave. Det er som \u00e5 bygge et ClickHouse-kluster i Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
La oss n\u00e5 se p\u00e5 noe interessant. Dette er ansvarsdelingen mellom Kubernetes og operat\u00f8ren, dvs. hva Kubernetes gj\u00f8r, hva operat\u00f8ren gj\u00f8r og hvordan de samhandler. <\/p>\n
<\/p>\n
Kubernetes h\u00e5ndterer systemrelaterte ting, dvs. den grunnleggende sett med objekter som kan tolkes som systemomfang. Kubernetes vet hvordan man kj\u00f8rer podder, hvordan man restart containerne, hvordan man monterer volumer, hvordan man arbeider med ConfigMap, dvs. alt som kan kalles systemet. <\/p>\n
<\/p>\n
Operat\u00f8rer opererer innenfor spesifikke domener. Hver operat\u00f8r er laget for sitt spesifikke domene. Vi har laget for ClickHouse.<\/p>\n
<\/p>\n
Og operat\u00f8ren samhandler nettopp i termer av det spesifikke domenet, som \u00e5 legge til en replika, lage et skjema, sette opp overv\u00e5kning. Det blir en slik inndeling.<\/p>\n
<\/p>\n
<\/p>\n
La oss se p\u00e5 et praktisk eksempel p\u00e5 hvordan denne ansvarsdelingen skjer n\u00e5r vi utf\u00f8rer oppgaven med \u00e5 legge til en replika. <\/p>\n
<\/p>\n
Operat\u00f8ren f\u00e5r i oppgave \u2013 \u00e5 legge til en replika. Hva gj\u00f8r operat\u00f8ren? Operat\u00f8ren beregner at det m\u00e5 lages en ny StatefulSet, hvor vi m\u00e5 beskrive bestemte maler, volumkrav. <\/p>\n
<\/p>\n
<\/p>\n
Han forbereder alt dette og sender det videre til K8s. Han sier at han trenger ConfigMap, StatefulSet, Volum. Kubernetes utf\u00f8rer oppgaven. Han materialiserer de grunnleggende enhetene som han opererer med. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 kommer ClickHouse-operat\u00f8ren inn i bildet igjen. Han har allerede en fysisk pod, hvor det kan gj\u00f8res noe. Og ClickHouse-operat\u00f8ren jobber igjen i termer av det spesifikke domenet. For \u00e5 aktivere en replika i klusteret m\u00e5 ClickHouse, for det f\u00f8rste, konfigurere datamodellen som finnes i dette klusteret. Og for det andre, m\u00e5 denne replikas overv\u00e5king settes opp slik at den kan spores godt. Det er operat\u00f8ren som konfigurerer dette. <\/p>\n
<\/p>\n
<\/p>\n
Og f\u00f8rst etter dette kommer ClickHouse inn i bildet, det vil si en annen mer avansert enhet. Dette er allerede en database. Den har sin egen instans, en ny konfigurasjon av replikasjonen, klar til \u00e5 bli med i klyngen.<\/p>\n
<\/p>\n
Dermed blir kjeden av utf\u00f8relse og ansvarsfordeling ved tillegging av replikas ganske lang.<\/p>\n
<\/p>\n
<\/p>\n
La oss fortsette med v\u00e5re praktiske oppgaver. Hvis klyngen allerede eksisterer, kan vi utf\u00f8re migrering av konfigurasjonen. <\/p>\n
<\/p>\n
<\/p>\n
Vi har gjort det slik at vi kan legge inn data i den eksisterende XML-filen som ClickHouse forst\u00e5r.<\/p>\n
<\/p>\n
<\/p>\n
Det er mulig \u00e5 gj\u00f8re en finjustering av ClickHouse. Nettopp zoned deployment \u2013 det er hva jeg snakket om da jeg forklarte hostPath, lokal lagring. Det handler om hvordan man gj\u00f8r zoned deployment riktig.<\/p>\n
<\/p>\n
<\/p>\n
Neste praktiske oppgave er overv\u00e5king.<\/p>\n
<\/p>\n
<\/p>\n
Hvis klyngen v\u00e5r endres, m\u00e5 overv\u00e5kingen justeres regelmessig. <\/p>\n
<\/p>\n
La oss se p\u00e5 diagrammet. Vi har allerede vurdert de gr\u00f8nne pilene. N\u00e5 la oss se p\u00e5 de r\u00f8de pilene. Dette viser hvordan vi \u00f8nsker \u00e5 overv\u00e5ke klyngen v\u00e5r. Hvordan metrikker fra ClickHouse-klyngen kommer inn i Prometheus og deretter til Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Hva er utfordringen med overv\u00e5king? Hvorfor betraktes det som en prestasjon? Utfordringen ligger nettopp i dynamikken. N\u00e5r vi har \u00e9n klynge som er statisk, kan vi sette opp overv\u00e5kingen \u00e9n gang og s\u00e5 glemme den.<\/p>\n
<\/p>\n
Men hvis vi har mange klynger, eller hvis noe stadig endres, er prosessen dynamisk. Og \u00e5 stadig m\u00e5tte justere overv\u00e5kingen er en ressurs- og tidskrevende oppgave, det vil si selv det krever litt latskap. Dette m\u00e5 automatiseres. Utfordringen ligger nettopp i prosessens dynamikk. Og operat\u00f8ren automatiserer dette veldig godt. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan har klyngen v\u00e5r utviklet seg? I begynnelsen var den slik.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 var den slik.<\/p>\n
<\/p>\n
<\/p>\n
Til slutt ble den slik. <\/p>\n
<\/p>\n
Og overv\u00e5kingen gj\u00f8res automatisk av operat\u00f8ren. En inngangspunkt. <\/p>\n
<\/p>\n
<\/p>\n
Og vi ser bare p\u00e5 utgangen i Grafana-dashbordet, hvordan livet i klyngen v\u00e5r pulserer. <\/p>\n
<\/p>\n
For \u00f8vrig blir Grafana-dashbordet ogs\u00e5 distribuert med operat\u00f8ren v\u00e5r rett fra kildekoden. Det er mulig \u00e5 koble til og bruke. Dette skjermbildet fikk jeg fra v\u00e5r DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Hvor \u00f8nsker vi \u00e5 g\u00e5 videre? Det er:<\/p>\n
<\/p>\n
\n\u00c5 utvikle automatisering av testing. Hovedoppgaven er automatisk testing av nye versjoner. <\/li>\n Vi \u00f8nsker ogs\u00e5 \u00e5 automatisere integrasjonen med ZooKeeper. Planene inkluderer integrasjon med ZooKeeper-operatoren. Det vil si at det er skrevet en operator for ZooKeeper, og det er logisk at de to operat\u00f8rene b\u00f8r begynne \u00e5 integreres for \u00e5 bygge en mer brukervennlig l\u00f8sning. <\/li>\n Vi \u00f8nsker \u00e5 gj\u00f8re mer avanserte livssykluskontroller. <\/li>\n Jeg har markert gr\u00f8nt det som er i anmarsj: arven fra Templates \u2013 FERTIG, det vil si at med neste utgivelse av operat\u00f8ren vil vi allerede ha arving av maler. Dette er et kraftig verkt\u00f8y som lar oss bygge komplekse konfigurasjoner fra biter. <\/li>\n Og vi \u00f8nsker automatisering av komplekse oppgaver. Den viktigste av disse er Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
La oss oppsummere s\u00e5 langt. <\/p>\n
<\/p>\n
<\/p>\n
Hva f\u00e5r vi ut av dette? Og er det verdt innsatsen eller ikke? Skulle vi i det hele tatt pr\u00f8ve \u00e5 integrere databasen i Kubernetes og bruke operat\u00f8ren generelt og Alitnity-operat\u00f8ren spesielt?<\/p>\n
<\/p>\n
Utgangen blir:<\/p>\n
<\/p>\n
\nBetydelig forenkling og automatisering av konfigurasjon, distribusjon og vedlikehold. <\/li>\n Umiddelbart innebygd overv\u00e5king. <\/li>\n Og klare, kodifiserte maler for komplekse situasjoner. Det er ikke lenger n\u00f8dvendig \u00e5 legge til en replika manuelt. Dette gj\u00f8res av operat\u00f8ren. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Det er bare ett sp\u00f8rsm\u00e5l igjen. Vi har allerede databasen i Kubernetes, virtualisering. Hvordan st\u00e5r det til med ytelsen til en slik l\u00f8sning, spesielt med tanke p\u00e5 at ClickHouse er optimalisert for ytelse?<\/p>\n
<\/p>\n
Svaret er \u2013 alt er i orden! Jeg vil ikke g\u00e5 inn p\u00e5 detaljene, dette er et eget tema for en presentasjon. <\/p>\n
<\/p>\n
<\/p>\n
Men det finnes et prosjekt som heter TSBS. Hva er hovedoppgaven? Det er en ytelsestesting av databaser. Det er et fors\u00f8k p\u00e5 \u00e5 sammenligne varme med varme, myk med myk. <\/p>\n
<\/p>\n
Hvordan fungerer det? Det genereres et datasett. Deretter kj\u00f8res dette datasettet gjennom et identisk sett med tester p\u00e5 forskjellige databaser. Hver database l\u00f8ser en oppgave p\u00e5 sitt eget m\u00e5te. Deretter kan man sammenligne resultatene. <\/p>\n
<\/p>\n
Det st\u00f8tter allerede mange databaser. Jeg har markert tre hovedtyper. Disse er:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Det ble ogs\u00e5 gjort en sammenligning med en annen lignende l\u00f8sning. Sammenligningen med RedShift. Sammenligningen ble gjort p\u00e5 Amazon. ClickHouse overg\u00e5r ogs\u00e5 alle i denne sammenhengen. <\/p>\n
<\/p>\n
<\/p>\n
Hvilke konklusjoner kan vi trekke fra det jeg har fortalt?<\/p>\n
<\/p>\n
\nDB i Kubernetes er mulig. Kanskje alle kan v\u00e6re det, men generelt ser det ut til at det er mulig. ClickHouse i Kubernetes er absolutt mulig med hjelp fra v\u00e5r operator. <\/li>\n Operatoren hjelper med \u00e5 automatisere prosesser og gj\u00f8r livet enklere.<\/li>\n Ytelsen er normal.<\/li>\n Og vi mener at dette kan og b\u00f8r brukes. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 bli med!<\/p>\n
<\/p>\n
Som jeg allerede har sagt, er operatoren et helt open source produkt, s\u00e5 det ville v\u00e6rt veldig bra om s\u00e5 mange som mulig bruker det. Bli med! Vi venter p\u00e5 dere alle!<\/p>\n
<\/p>\n
Takk til alle!<\/p>\n
<\/p>\n
Sp\u00f8rsm\u00e5l<\/p>\n
<\/p>\n
<\/p>\n
Takk for presentasjonen! Jeg heter Anton. Jeg er fra SEMrush. Jeg er interessert i logging. Vi h\u00f8rer om overv\u00e5king, men ingenting om logging n\u00e5r vi snakker om hele klyngen. Vi har for eksempel satt opp en klynge p\u00e5 eget utstyr. Og vi bruker sentralisert logging, samler med standardverkt\u00f8y i en felles logg, og deretter henter vi ut interessante data.<\/em> <\/p>\n<\/p>\n
Godt sp\u00f8rsm\u00e5l, alts\u00e5 logging st\u00e5r p\u00e5 todo-listen. V\u00e5r operator automatiserer ikke dette for \u00f8yeblikket. Den er fortsatt under utvikling, prosjektet er fortsatt relativt ungt. Vi forst\u00e5r n\u00f8dvendigheten av logging. Dette er ogs\u00e5 et veldig viktig tema. Og det er kanskje ikke mindre viktig enn overv\u00e5king. Men det f\u00f8rste p\u00e5 listen for implementering var overv\u00e5king. Logging vil komme. Vi gj\u00f8r selvf\u00f8lgelig v\u00e5rt beste for \u00e5 automatisere alle aspekter av klyngens livssyklus. S\u00e5 svaret er \u2013 i \u00f8yeblikket kan ikke operatoren dette, men det er p\u00e5 planen, og vi vil gj\u00f8re det. Hvis noen har lyst til \u00e5 bidra, s\u00e5 send inn en pull request, v\u00e6r s\u00e5 snill.<\/p>\n
<\/p>\n
Hei! Takk for presentasjonen! Jeg har et standardsp\u00f8rsm\u00e5l knyttet til Persistent Volumes. N\u00e5r vi oppretter en konfigurasjon med denne operatoren, hvordan bestemmer operatoren hvilken node vi har montert en disk eller mappe p\u00e5? M\u00e5 vi p\u00e5 forh\u00e5nd forklare at vi \u00f8nsker \u00e5 plassere v\u00e5r ClickHouse nettopp p\u00e5 de nodene der det finnes disk?<\/em><\/p>\n<\/p>\n
S\u00e5 vidt jeg forst\u00e5r, er dette sp\u00f8rsm\u00e5let en fortsettelse av lokal lagring, spesielt delen som gjelder hostPath. Det er som \u00e5 forklare hele systemet at pod'en m\u00e5 kj\u00f8re p\u00e5 en spesifikk node hvor vi har en fysisk tilkoblet disk som er montert p\u00e5 en spesifikk sti. Dette er en hel seksjon som jeg ber\u00f8rte veldig overfladisk fordi svaret er ganske omfattende. <\/p>\n
<\/p>\n
Kort sagt ser det slik ut. Vi m\u00e5 selvf\u00f8lgelig gj\u00f8re provisioning av disse volumene. Per n\u00e5 finnes det ingen dynamisk provisioning i local storage, s\u00e5 DevOps m\u00e5 selv opprette diskene, disse volumene. De m\u00e5 forklare Kubernetes provisioning at du vil ha Persistent volumes av en bestemt klasse, som ligger p\u00e5 bestemte noder. Deretter m\u00e5 de forklare Kubernetes at pod'er som krever en bestemt klasse local storage, kun skal planlegges p\u00e5 de bestemte nodene basert p\u00e5 labels. For dette form\u00e5let har operat\u00f8ren muligheten til \u00e5 tildele en bestemt label og en per host-instans. Dermed vil pod'ene bli rutet av Kubernetes for \u00e5 kj\u00f8re kun p\u00e5 noder som oppfyller kravene, labels, for \u00e5 si det enkelt. Administratorene tildeler labels og gj\u00f8r provisioning av diskene manuelt. Og s\u00e5 kan det skaleres.<\/p>\n
<\/p>\n
Og nettopp det tredje alternativet for local storage hjelper litt med dette. Som jeg allerede har p\u00e5pekt, er det et tidkrevende arbeid med konfigurasjon som ved sluttresultatet hjelper \u00e5 oppn\u00e5 maksimal ytelse.<\/p>\n
<\/p>\n
Jeg har et annet sp\u00f8rsm\u00e5l relatert til dette. Kubernetes var tenkt slik at vi ikke bryr oss om vi mister en node eller ikke. Hva gj\u00f8r vi i dette tilfellet hvis vi mister noden der shard'en v\u00e5r ligger?<\/em><\/p>\n<\/p>\n
Ja, Kubernetes ble opprinnelig posisjonert p\u00e5 den m\u00e5ten at vi behandler v\u00e5re pod'er som storfe, mens her blir hver disk noe som ligner p\u00e5 et kj\u00e6ledyr. Det er et problem at vi ikke bare kan kaste dem bort. Utviklingen av Kubernetes g\u00e5r i retning av at vi ikke kan forholde oss helt filosofisk til dette, som til helt avhendte ressurser.<\/p>\n
<\/p>\n
N\u00e5 et praktisk sp\u00f8rsm\u00e5l. Hva gj\u00f8r du hvis du har mistet en node der disken var? Dette problemet l\u00f8ses allerede p\u00e5 et h\u00f8yere niv\u00e5. I tilfellet med ClickHouse har vi replikater som fungerer p\u00e5 et h\u00f8yere niv\u00e5, dvs. p\u00e5 ClickHouse-niv\u00e5.<\/p>\n
<\/p>\n
Hva blir s\u00e5 disposisjonen? Det er DevOps som har ansvaret for at dataene ikke g\u00e5r tapt. Han m\u00e5 korrekt konfigurere replikasjonen og s\u00f8rge for at replikasjonen utf\u00f8res. Dataene m\u00e5 v\u00e6re duplisert i replikene p\u00e5 ClickHouse-niv\u00e5. Dette er ikke en oppgave som operat\u00f8ren l\u00f8ser. Og det er ikke en oppgave som Kubernetes selv l\u00f8ser. Det er p\u00e5 ClickHouse-niv\u00e5.<\/p>\n
<\/p>\n
Hva skal man gj\u00f8re hvis den fysiske noden din faller av? Det viser seg at du m\u00e5 sette opp en ny, riktig provisjonere en disk, og p\u00e5f\u00f8re etiketter. Etter dette vil den oppfylle kravene om at Kubernetes kan starte en instans av en pod p\u00e5 den. Kubernetes vil starte den. Antall pod-er dine er jo ikke tilstrekkelig i henhold til spesifikasjonene. Den vil g\u00e5 gjennom syklusen som jeg viste. Og p\u00e5 det \u00f8verste niv\u00e5et for ClickHouse vil det forst\u00e5 at v\u00e5r replika er kommet inn, den er fortsatt tom, og vi m\u00e5 begynne \u00e5 overf\u00f8re data til den. Det vil si at denne prosessen fortsatt er lite automatisert. <\/p>\n
<\/p>\n
Takk for foredraget! N\u00e5r det skjer uventede hendelser, faller operat\u00f8ren og starter p\u00e5 nytt, mens hendelser inntreffer, hvordan h\u00e5ndterer dere dette?<\/em><\/p>\n<\/p>\n
Hva skjer hvis operat\u00f8ren faller og starter p\u00e5 nytt, ikke sant? <\/p>\n
<\/p>\n
Ja. Og i dette \u00f8yeblikket kom det hendelser.<\/em> <\/p>\n<\/p>\n
Oppgaven om hva man skal gj\u00f8re i dette tilfellet deles delvis mellom operat\u00f8ren og Kubernetes. Kubernetes har muligheten til \u00e5 spille av den skjede hendelsen. Den spiller av. Og det er oppgaven til operat\u00f8ren \u00e5 s\u00f8rge for at n\u00e5r hendelsene blir spilt p\u00e5 nytt, s\u00e5 er disse hendelsene idempotente. Og at en gjentatt inntreden av den samme hendelsen ikke bryter systemet v\u00e5rt. Og v\u00e5r operat\u00f8r h\u00e5ndterer denne oppgaven. <\/p>\n
<\/p>\n
Hei! Takk for foredraget! Dmitrij Zavyalov, selskapet<\/em> Smedova. Er det planlagt \u00e5 legge til muligheten for \u00e5 konfigurere med haproxy i operat\u00f8ren? Det ville v\u00e6rt interessant med en annen balanseh\u00e5ndterer enn standarden, slik at den er smart og forst\u00e5r hva ClickHouse faktisk er.<\/em> <\/p>\n<\/p>\n
Snakker du om Ingress?<\/p>\n
<\/p>\n
Ja, \u00e5 erstatte Ingress med haproxy. I haproxy kan man spesifisere topologien til klyngen, hvor replikene befinner seg.<\/em><\/p>\n<\/p>\n
Forel\u00f8pig har vi ikke tenkt p\u00e5 dette. Hvis dette er n\u00f8dvendig for deg og du kan forklare hvorfor det er n\u00f8dvendig, kan det realiseres, spesielt hvis du \u00f8nsker \u00e5 delta. Vi vurderer det gjerne. Kort svar \u2013 nei, vi har ikke denne funksjonaliteten for \u00f8yeblikket. Takk for innspill, vi vil se p\u00e5 det. Og hvis du ogs\u00e5 forklarer bruksomr\u00e5det og hvorfor det er n\u00f8dvendig i praksis, for eksempel ved \u00e5 opprette issues p\u00e5 GitHub, vil det v\u00e6re flott.<\/p>\n
<\/p>\n
Det er allerede gjort.<\/em><\/p>\n<\/p>\n
Bra. Vi er \u00e5pne for alle forslag. Og haproxy legges til todo-listen. Todo-listen vokser, ikke minker enn\u00e5. Men det er bra, det betyr at produktet er etterspurt.<\/p>\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Operator](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n