Local<\/li>\n<\/ul>\n<\/p>\n
Lad os se p\u00e5, hvad der adskiller dem, og hvad der er ens. <\/p>\n
<\/p>\n
For det f\u00f8rste, i alle tre tilgange har vi storage \u2013 det er lokale diske, der ligger p\u00e5 den samme fysiske k8s-node. Men de har nogle forskelle.<\/p>\n
<\/p>\n
<\/p>\n
Lad os starte med den enkleste, dvs. emptyDir. Hvad er det i praksis? Det er, n\u00e5r vi beder vores specifikation om at give systemet til containerisering (oftest er det Docker) adgang til en mappe p\u00e5 den lokale disk.<\/p>\n
<\/p>\n
I praksis opretter Docker et sted i sine egne stier en midlertidig mappe, kalder den et langt hash. Og giver adgangsgr\u00e6nsefladen til det. <\/p>\n
<\/p>\n
Hvordan vil det fungere med hensyn til pr\u00e6station? Det vil fungere med hastigheden af den lokale disk, dvs. det er fuldst\u00e6ndig adgang til sin egen disk. <\/p>\n
<\/p>\n
Men denne metode har sin ulempe. Persistent i denne sammenh\u00e6ng er ret tvivlsom. Ved den f\u00f8rste bev\u00e6gelse af Docker med containere g\u00e5r Persistent tabt. Hvis Kubernetes af en eller anden grund vil flytte denne Pod til en anden disk, bliver dataene tabt. <\/p>\n
<\/p>\n
Denne tilgang er god til tests, fordi hastigheden er acceptabel, men til noget seri\u00f8st er denne mulighed ikke egnet. <\/p>\n
<\/p>\n
<\/p>\n
Derfor findes der en anden tilgang. Dette er hostPath. Hvis vi ser p\u00e5 den tidligere slide og denne, kan vi bem\u00e6rke \u00e9n forskel. Vores mappe er flyttet fra Docker direkte til Kubernetes noden. Her er det lidt enklere. Vi angiver blot stien til det lokale filsystem, hvor vi \u00f8nsker at gemme vores data. <\/p>\n
<\/p>\n
Der er fordele ved denne metode. Dette er allerede en \u00e6gte Persistent, en klassisk en. Vores data vil blive gemt p\u00e5 disken et bestemt sted. <\/p>\n
<\/p>\n
Der er ogs\u00e5 ulemper. Det er vanskeligt at administrere. Vores Kubernetes kan beslutte at flytte en Pod til en anden fysisk node. Og her tr\u00e6der DevOps ind. De skal korrekt kommunikere til hele systemet, at disse pod'er kun kan flyttes til mandder, hvor der er noget monteret som angivet, og kun \u00e9n node ad gangen. Det er ret komplekst. <\/p>\n
<\/p>\n
Specielt til dette form\u00e5l har vi i vores operat\u00f8r lavet skabeloner for at skjule al denne kompleksitet. Og man kunne simpelthen sige: \u00abJeg vil have, at der er \u00e9n instans af ClickHouse p\u00e5 hver fysisk node og p\u00e5 den angivne sti\u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Men dette behov g\u00e6lder ikke kun os, derfor forst\u00e5r herrerne fra Kubernetes ogs\u00e5, at folk gerne vil have adgang til fysiske diske, og derfor tilbyder de et tredje niveau.<\/p>\n
<\/p>\n
Det kaldes local. Der er stort set ingen forskel fra den tidligere slide. Tidligere skulle vi manuelt s\u00f8rge for, at vi ikke kunne flytte disse pod'er fra node til node, fordi de skulle v\u00e6re knyttet til den specifikke sti til den lokale fysiske disk, men nu er al denne viden indkapslet i selve Kubernetes. Og det bliver meget nemmere at konfigurere.<\/p>\n
<\/p>\n
<\/p>\n
Lad os vende tilbage til vores praktiske opgave. Vi vender tilbage til YAML skabelonen. Her har vi f\u00e5et en \u00e6gte storage. Vi er tilbage til dette. Vi angiver en klassisk VolumeClaim skabelon som i k8s. Og beskriver, hvilken storage vi \u00f8nsker.<\/p>\n
<\/p>\n
Derefter vil k8s anmode om storage. Den vil tildele os det i StatefulSet. Og i sidste ende vil det v\u00e6re til r\u00e5dighed for ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Vi havde en s\u00e5dan ordning. Vores Persistent Storage var r\u00f8d, hvilket ligesom antydede, at det burde g\u00f8res. <\/p>\n
<\/p>\n
<\/p>\n
Og den bliver gr\u00f8n. Nu er diagrammet for ClickHouse p\u00e5 k8s helt finaliseret. Vi har shards, replikaer, ZooKeeper, der er en \u00e6gte Persistent, der er implementeret p\u00e5 den ene eller anden m\u00e5de. Diagrammet er allerede fuldt operationelt. <\/p>\n
<\/p>\n
<\/p>\n
Vi forts\u00e6tter med at leve videre. Vores klynge udvikler sig. Og Alexey g\u00f8r en indsats og udsender en ny version af ClickHouse.<\/p>\n
<\/p>\n
Der opst\u00e5r en praktisk opgave \u2013 at teste den nye version af ClickHouse p\u00e5 vores klynge. Og selvf\u00f8lgelig \u00f8nsker vi ikke at opdatere hele klyngen; vi vil helst placere den nye version et sted i et afsides hj\u00f8rne, og m\u00e5ske ikke bare \u00e9n ny version, men to, fordi de ofte bliver udgivet. <\/p>\n
<\/p>\n
Hvad kan vi sige om dette emne?<\/p>\n
<\/p>\n
<\/p>\n
Her har vi netop muligheden for det. Det er pod-skabeloner. Vi kan beskrive det, vores operator giver os mulighed for at opbygge en heterogen klynge. Dvs. at konfigurere fra alle repliker samlet, til hver individuel replika, hvilken version af ClickHouse vi \u00f8nsker, hvilken version af storage vi \u00f8nsker. Vi kan fuldt ud konfigurere en klynge af den konfiguration, som vi \u00f8nsker. <\/p>\n
<\/p>\n
<\/p>\n
Vi vil nu dykke lidt dybere. Tidligere har vi talt om, hvordan ClickHouse-operat\u00f8ren fungerer i forhold til specifikationerne for ClickHouse.<\/p>\n
<\/p>\n
Nu vil jeg gerne sige et par ord om, hvordan enhver operat\u00f8r generelt fungerer, samt hvordan den interagerer med K8s.<\/p>\n
<\/p>\n
<\/p>\n
Lad os f\u00f8rst se p\u00e5 interaktionen med K8s. Hvad sker der, n\u00e5r vi k\u00f8rer kubectl apply? Vores objekter vises gennem API i etcd. <\/p>\n
<\/p>\n
<\/p>\n
For eksempel de grundl\u00e6ggende Kubernetes-objekter: pod, StatefulSet, service og s\u00e5 videre i r\u00e6kkef\u00f8lgen. <\/p>\n
<\/p>\n
Men intet fysisk sker endnu. Disse objekter skal materialiseres i klyngen. <\/p>\n
<\/p>\n
<\/p>\n
For dette opst\u00e5r en controller. Controlleren er en speciel komponent i K8s, som kan materialisere disse beskrivelser. Den ved, hvordan og hvad der skal g\u00f8res fysisk. Den ved, hvordan man starter containere, og hvad der skal konfigureres for at f\u00e5 serveren til at k\u00f8re. <\/p>\n
<\/p>\n
<\/p>\n
Og den materialiserer vores objekter i K8s.<\/p>\n
<\/p>\n
Men vi \u00f8nsker ikke kun at operere med pod-der og StatefulSet-der, vi \u00f8nsker at oprette en ClickHouseInstallation, dvs. et objekt af typen ClickHouse, s\u00e5 vi kan operere med det som \u00e9n helhed. I \u00f8jeblikket er der ikke s\u00e5dan en mulighed. <\/p>\n
<\/p>\n
<\/p>\n
Men K8s har en anden rar funktion. Vi \u00f8nsker, at der skal opst\u00e5 en kompleks enhed, som ville v\u00e6re samlet af pod-der og StatefulSet, vores klynge. <\/p>\n
<\/p>\n
<\/p>\n
Og hvad skal der til for dette? For det f\u00f8rste kommer Custom Resource Definition p\u00e5 scenen. Hvad er det? Det er en beskrivelse for K8s, som angiver, at du f\u00e5r en ny datatype, som vi \u00f8nsker at tilf\u00f8je en brugerdefineret ressource til pod, StatefulSet, der vil v\u00e6re kompleks indeni. Det er en beskrivelse af datakonstruktionen. <\/p>\n
<\/p>\n
<\/p>\n
Vi sender det ogs\u00e5 derhen via kubectl apply. Kubernetes har gl\u00e6deligt taget det til sig. <\/p>\n
<\/p>\n
Og nu har vi i lageret, for objektet i etcd, mulighed for at registrere en brugerdefineret ressource kaldet ClickHouseInstallation.<\/p>\n
<\/p>\n
Men indtil nu vil der ikke ske mere. Det vil sige, hvis vi nu opretter en YAML-fil, som vi har gennemg\u00e5et med beskrivelsen af shard, replikaer og siger \"kubectl apply\", s\u00e5 vil Kubernetes acceptere den, placere den i etcd og sige: \"Fint, men jeg ved ikke, hvad jeg skal g\u00f8re med den. Hvordan jeg skal h\u00e5ndtere ClickHouseInstallation, ved jeg ikke.\" <\/p>\n
<\/p>\n
<\/p>\n
Derfor har vi brug for nogen, der kan hj\u00e6lpe Kubernetes med at h\u00e5ndtere den nye datatype. Til venstre har vi den indbyggede controller i Kubernetes, som arbejder med de indbyggede datatyper. Og til h\u00f8jre skal vi have en brugerdefineret controller, der kan arbejde med brugerdefinerede datatyper. <\/p>\n
<\/p>\n
Og p\u00e5 en anden m\u00e5de kaldes den en operator. Jeg har bevidst flyttet den uden for Kubernetes, fordi den kan k\u00f8re uden for K8s. Ofte, selvf\u00f8lgelig, k\u00f8rer alle operat\u00f8rer i Kubernetes, men der er intet til hinder for, at den st\u00e5r udenfor, s\u00e5 derfor er den her bevidst flyttet udenfor. <\/p>\n
<\/p>\n
<\/p>\n
Og i sin tur interagerer den brugerdefinerede controller, det vil sige operatoren, med Kubernetes gennem API'et. Den kan allerede interagere med API'et. Og den ved allerede, hvordan man materialiserer en kompleks struktur fra den brugerdefinerede ressource, som vi \u00f8nsker at skabe. Det er netop det, operatoren g\u00f8r. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan fungerer operatoren? Lad os kigge til h\u00f8jre for at finde ud af, hvordan den g\u00f8r det. Vi vil l\u00e6re, hvordan operatoren materialiserer alt dette, og hvordan interaktionen med K8s derefter foreg\u00e5r.<\/p>\n
<\/p>\n
<\/p>\n
Operatoren er et program. Den er begivenhedsorienteret. Operatoren abonnerer ved hj\u00e6lp af Kubernetes API p\u00e5 begivenheder. I Kubernetes API'er er der indgange, hvor man kan abonnere p\u00e5 begivenheder. Og hvis noget \u00e6ndrer sig i K8s, sender Kubernetes begivenheder til alle, der \u00f8nsker det, det vil sige, den der har abonneret p\u00e5 denne API-punkt, vil modtage meddelelser.<\/p>\n
<\/p>\n
Operatoren abonnerer p\u00e5 begivenheder og skal reagere. Dens opgave er at reagere p\u00e5 de fremkomne begivenheder. <\/p>\n
<\/p>\n
<\/p>\n
Begivenheder genereres af visse opdateringer. Vores YAML-fil med beskrivelsen af ClickHouseInstallation kommer ind. Den blev sendt til etcd via kubectl apply. Der blev udl\u00f8st en event, og denne event blev sendt til ClickHouse-operat\u00f8ren. Operat\u00f8ren modtog denne beskrivelse, og han skal g\u00f8re noget. Hvis der er kommet en opdatering p\u00e5 objektet ClickHouseInstallation, skal klyngen opdateres. Operat\u00f8rens opgave er at opdatere klyngen. <\/p>\n
<\/p>\n
<\/p>\n
Hvad g\u00f8r han? For det f\u00f8rste skal der udarbejdes en handlingsplan for, hvad vi vil g\u00f8re med denne opdatering. Opdateringer kan v\u00e6re meget sm\u00e5, det vil sige sm\u00e5 i YAML-udf\u00f8relsen, men de kan medf\u00f8re meget store \u00e6ndringer i klyngen. Derfor skaber operat\u00f8ren en plan, og s\u00e5 holder han sig til den.<\/p>\n
<\/p>\n
<\/p>\n
Han begynder i henhold til denne plan at fremstille strukturen internt for at materialisere pods, tjenester osv., det vil sige at g\u00f8re det, som er hans hovedopgave. Det er som at bygge en ClickHouse-klynge i Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Lad os nu ber\u00f8re en interessant ting. Det er ansvarsdelingen mellem Kubernetes og operat\u00f8ren, det vil sige hvad Kubernetes g\u00f8r, hvad operat\u00f8ren g\u00f8r, og hvordan de interagerer med hinanden. <\/p>\n
<\/p>\n
Kubernetes st\u00e5r for systemiske ting, det vil sige et grundl\u00e6ggende s\u00e6t objekter, der kan fortolkes som system-omfang. Kubernetes ved, hvordan man starter pods, hvordan man genstarter containere, hvordan man mount'er volumener, hvordan man arbejder med ConfigMap, det vil sige alt, hvad man kan kalde systemet. <\/p>\n
<\/p>\n
Operat\u00f8rer arbejder inden for specifikke dom\u00e6ner. Hver operat\u00f8r laves til sit specifikke dom\u00e6ne. Vi har lavet en til ClickHouse.<\/p>\n
<\/p>\n
Og operat\u00f8ren interagerer netop i termer fra det specifikke dom\u00e6ne, som at tilf\u00f8je en replika, oprette et skema, konfigurere overv\u00e5gning. Der opst\u00e5r et s\u00e5dant skel.<\/p>\n
<\/p>\n
<\/p>\n
Lad os se p\u00e5 et praktisk eksempel p\u00e5, hvordan denne ansvarsdeling finder sted, n\u00e5r vi udf\u00f8rer handlingen \"tilf\u00f8je en replika\". <\/p>\n
<\/p>\n
Operat\u00f8ren f\u00e5r opgaven \u2013 at tilf\u00f8je en replika. Hvad g\u00f8r operat\u00f8ren? Operat\u00f8ren beregner, at der skal oprettes en ny StatefulSet, i hvilken der skal beskrives visse skabeloner og volumenklausuler. <\/p>\n
<\/p>\n
<\/p>\n
Han har forberedt det hele og sender det videre til K8s. Han siger, at han har brug for ConfigMap, StatefulSet og Volume. Kubernetes arbejder videre. Han materialiserer de grundl\u00e6ggende enheder, som han opererer med. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 kommer ClickHouse-operat\u00f8ren ind i billedet igen. Han har allerede en fysisk pod, hvor man kan begynde at arbejde. Og ClickHouse-operat\u00f8ren opererer igen i termer af dom\u00e6net. Det vil sige, for specifikt at inkludere en replika i klyngen, skal der for det f\u00f8rste konfigureres et dataskema, som findes i denne klynge. Og for det andet skal denne replika inkluderes i overv\u00e5gningen, s\u00e5 den kan f\u00f8lges ordentligt. Det er allerede operat\u00f8ren, der s\u00e6tter dette op. <\/p>\n
<\/p>\n
<\/p>\n
Og f\u00f8rst derefter tr\u00e6der selve ClickHouse ind i billedet, det vil sige en endnu mere overordnet enhed. Det er allerede databasen. Den har sin egen instans, en ny konfigureret replika, der er klar til at komme ind i klyngen.<\/p>\n
<\/p>\n
Det viser sig, at k\u00e6den af opgaver og ansvarsfordeling ved tilf\u00f8jelse af en replika er ret lang.<\/p>\n
<\/p>\n
<\/p>\n
Lad os forts\u00e6tte med vores praktiske opgaver. Hvis klyngen allerede eksisterer, er det muligt at foretage en migrationskonfiguration. <\/p>\n
<\/p>\n
<\/p>\n
Vi har gjort det muligt at flytte gennem den eksisterende xml, som ClickHouse forst\u00e5r.<\/p>\n
<\/p>\n
<\/p>\n
Man kan foretage finjusteringer af ClickHouse. Netop zoned deployment \u2013 det er, hvad jeg talte om i forbindelse med forklaringen af hostPath, lokal lagring. Det handler om, hvordan man korrekt laver zoned deployment.<\/p>\n
<\/p>\n
<\/p>\n
Den n\u00e6ste praktiske opgave er overv\u00e5gning.<\/p>\n
<\/p>\n
<\/p>\n
Hvis vi \u00e6ndrer vores klynge, skal overv\u00e5gningen j\u00e6vnligt tilpasses. <\/p>\n
<\/p>\n
Lad os se p\u00e5 skemaet. De gr\u00f8nne pile har vi allerede set p\u00e5. Nu lad os se p\u00e5 de r\u00f8de pile. Det er, hvordan vi \u00f8nsker at overv\u00e5ge vores klynge. Hvordan metrikker fra ClickHouse-klyngen g\u00e5r til Prometheus og derefter til Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Hvad er udfordringen med overv\u00e5gning? Hvorfor betragtes det som en pr\u00e6station? Udfordringen er netop i dynamikken. N\u00e5r vi har \u00e9n klynge, og den er statisk, kan man indstille overv\u00e5gningen \u00e9n gang og s\u00e5 lade den v\u00e6re.<\/p>\n
<\/p>\n
Men hvis vi har mange klynger, eller hvis der konstant sker \u00e6ndringer, s\u00e5 er processen dynamisk. Og at skulle besk\u00e6ftige sig med at justere overv\u00e5gningen konstant er en spild af ressourcer og tid, det vil sige, det kan ogs\u00e5 v\u00e6re ligegyldigt. Det skal automatiseres. Udfordringen ligger netop i dynamikken i processen. Og operat\u00f8ren automatiserer det rigtig godt. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan udviklede vores klynge sig? I begyndelsen var den s\u00e5dan her.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 blev den s\u00e5dan her.<\/p>\n
<\/p>\n
<\/p>\n
Som resultat blev den s\u00e5dan her. <\/p>\n
<\/p>\n
Og overv\u00e5gningen udf\u00f8res automatisk af operat\u00f8ren. En enhedlig indgangspunkt. <\/p>\n
<\/p>\n
<\/p>\n
Og vi ser blot p\u00e5 Grafana-dashboardet for at se, hvordan vores klynge fungerer. <\/p>\n
<\/p>\n
For resten distribueres Grafana-dashboardet ogs\u00e5 med vores operator direkte i kildekoderne. Det kan tilsluttes og bruges. Dette screenshot fik jeg fra vores DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Hvor \u00f8nsker vi at bev\u00e6ge os hen herfra? Det er:<\/p>\n
<\/p>\n
\nAt udvikle automatisering af test. Hovedopgaven er automatiseret test af nye versioner. <\/li>\n Vi \u00f8nsker ogs\u00e5 meget at automatisere integrationen med ZooKeeper. Og vi planl\u00e6gger at integrere med ZooKeeper-operatoren. Alts\u00e5, der er skrevet en operator til ZooKeeper, og det er logisk, at de to operatorer begynder at integrere sig for at skabe en mere bekvem l\u00f8sning. <\/li>\n Vi \u00f8nsker at lave mere avancerede sundhedstjek. <\/li>\n Jeg har markeret det, vi har p\u00e5 vej, arver Templates \u2013 DONE, s\u00e5 med den n\u00e6ste release af operatoren vil vi allerede have skabelonarv. Dette er et st\u00e6rkt v\u00e6rkt\u00f8j, der g\u00f8r det muligt at bygge komplekse konfigurationer fra sm\u00e5 dele. <\/li>\n Og vi \u00f8nsker automatisering af komplekse opgaver. Den vigtigste af disse er Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Lad os lave en midtvejsevaluering. <\/p>\n
<\/p>\n
<\/p>\n
Hvad f\u00e5r vi ud af det? Og er det v\u00e6rd at g\u00f8re, eller ej? Skal vi overhovedet fors\u00f8ge at bringe databasen ind i Kubernetes og anvende operatoren generelt, og Alitnity-operatoren specifikt?<\/p>\n
<\/p>\n
Udgangen er:<\/p>\n
<\/p>\n
\nBetydelig forenkling og automatisering af konfiguration, udrulning samt vedligeholdelse. <\/li>\n Indbygget overv\u00e5gning fra starten. <\/li>\n Og kodede skabeloner klar til brug til komplekse situationer. Allerede handlinger som at tilf\u00f8je en replika skal ikke g\u00f8res manuelt. Det klarer operatoren. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Der er kun \u00e9t sidste sp\u00f8rgsm\u00e5l. Vi har allerede databasen i Kubernetes, virtualisering. Hvordan st\u00e5r det til med ydeevnen af den l\u00f8sning, is\u00e6r i lyset af, at ClickHouse er optimeret til ydeevne?<\/p>\n
<\/p>\n
Svaret er \u2013 alt er fint! Jeg vil ikke g\u00e5 i detaljer, det er emnet for et separat foredrag. <\/p>\n
<\/p>\n
<\/p>\n
Men der er et projekt kaldet TSBS. Hvad er dets hovedopgave? Det er at teste databaser for ydeevne. Det er et fors\u00f8g p\u00e5 at sammenligne varme med varme, bl\u00f8dt med bl\u00f8dt. <\/p>\n
<\/p>\n
Hvordan fungerer det? Der genereres et datas\u00e6t. Derefter k\u00f8res dette datas\u00e6t p\u00e5 en ensartet r\u00e6kke tests p\u00e5 forskellige databaser. Og hver database l\u00f8ser en opgave p\u00e5 sin egen m\u00e5de. Derefter kan resultaterne sammenlignes. <\/p>\n
<\/p>\n
Det underst\u00f8tter allerede en stor m\u00e6ngde databaser. Jeg har fremh\u00e6vet tre hovedtyper. De er:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Der er ogs\u00e5 blevet lavet en sammenligning med en anden lignende l\u00f8sning. Sammenligningen med RedShift. Sammenligningen blev udf\u00f8rt p\u00e5 Amazon. ClickHouse overg\u00e5r ogs\u00e5 alle i denne sammenh\u00e6ng. <\/p>\n
<\/p>\n
<\/p>\n
Hvad kan vi konkludere ud fra det, jeg har fortalt?<\/p>\n
<\/p>\n
\nDB i Kubernetes er muligt. Det er nok muligt med alle, men generelt ser det ud til at v\u00e6re muligt. ClickHouse i Kubernetes kan helt sikkert implementeres af vores operator. <\/li>\n Operatoren hj\u00e6lper med at automatisere processerne og g\u00f8r virkelig livet lettere.<\/li>\n Ydelsen er acceptabel.<\/li>\n Og vi mener, at det kan og b\u00f8r bruges. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 kom og v\u00e6r med!<\/p>\n
<\/p>\n
Som jeg allerede har sagt, er operatoren et helt open source-produkt, s\u00e5 det ville v\u00e6re rigtig godt, hvis s\u00e5 mange som muligt ville bruge det. Kom og v\u00e6r med! Vi ser frem til at se jer alle!<\/p>\n
<\/p>\n
Tak for alle!<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l<\/p>\n
<\/p>\n
<\/p>\n
Tak for pr\u00e6sentationen! Mit navn er Anton. Jeg er fra virksomheden SEMrush. Jeg er interesseret i, hvad ang\u00e5r logningen. Vi h\u00f8rer om overv\u00e5gning, men intet om logning, hvis vi taler om hele klyngen. For eksempel har vi sat en klynge op p\u00e5 hardware. Vi bruger centraliseret logning, hvor vi samler det med standardv\u00e6rkt\u00f8jer i en samlet m\u00e6ngde. Og s\u00e5 tr\u00e6kker vi de interessante data derfra.<\/em> <\/p>\n<\/p>\n
Et godt sp\u00f8rgsm\u00e5l, dvs. logning er p\u00e5 todo-listen. Vores operator automatiserer stadig ikke det. Den er stadig under udvikling, projektet er stadig relativt ungt. Vi forst\u00e5r n\u00f8dvendigheden af logning. Det er ogs\u00e5 et meget vigtigt emne, som m\u00e5ske er liges\u00e5 vigtigt som overv\u00e5gning. Men overv\u00e5gning var f\u00f8rst p\u00e5 listen til implementering. Logning vil komme. Vi str\u00e6ber naturligvis efter at automatisere alle aspekter af klyngens livscyklus. S\u00e5 svaret er \u2013 p\u00e5 nuv\u00e6rende tidspunkt kan operatoren desv\u00e6rre ikke dette, men det er p\u00e5 vores planer, og vi vil g\u00f8re det. Hvis der er lyst til at deltage, er pull request velkommen.<\/p>\n
<\/p>\n
Hej! Tak for pr\u00e6sentationen! Jeg har et standardsp\u00f8rgsm\u00e5l relateret til Persistent Volumes. N\u00e5r vi opretter en konfiguration med denne operator, hvordan bestemmer operatoren, hvilken node vi har monteret en disk eller mappe p\u00e5? Skal vi p\u00e5 forh\u00e5nd forklare den, at den skal placere vores ClickHouse p\u00e5 de noder, der har disken?<\/em><\/p>\n<\/p>\n
S\u00e5 vidt jeg forst\u00e5r, er dette sp\u00f8rgsm\u00e5l en forts\u00e6ttelse af local storage, is\u00e6r den del, der omhandler hostPath. Det er som at forklare hele systemet, hvad der er n\u00f8dvendigt for, at pod'en skal k\u00f8re p\u00e5 en bestemt node, hvor vi har en fysisk tilsluttet disk, der er monteret p\u00e5 en bestemt sti. Det er en hel sektion, som jeg har ber\u00f8rt meget overfladisk, fordi svaret er ret omfattende. <\/p>\n
<\/p>\n
Kort sagt ser det s\u00e5dan ud. Vi skal selvf\u00f8lgelig foretage provisioning af disse volumes. P\u00e5 nuv\u00e6rende tidspunkt mangler der dynamisk provisionering i local storage, s\u00e5 DevOps skal selv oprette diske, disse volumes. Og de skal informere Kubernetes provisioneringen om, at der vil v\u00e6re Persistent volumes af en bestemt klasse, som findes p\u00e5 bestemte noder. Derefter skal det forklares for Kubernetes, at pod'e, som kr\u00e6ver en bestemt klasse local storage, kun skal planl\u00e6gges p\u00e5 de noder, der har de n\u00f8dvendige labels. Til dette form\u00e5l er der i operatoren mulighed for at tildele en bestemt label og \u00e9n pr. host-forekomst. Og resultatet bliver, at pod'ene vil blive rutet af Kubernetes til at k\u00f8re kun p\u00e5 noder, som opfylder kravene til labels, sagt p\u00e5 en enkel m\u00e5de. Administratorer tildeler labels og foretager provisioning af diske manuelt. Og s\u00e5 kan det skaleres.<\/p>\n
<\/p>\n
Og netop den tredje mulighed for local storage hj\u00e6lper med at lette dette lidt. Som jeg allerede har p\u00e5peget, er det et omhyggeligt stykke arbejde at konfigurere, som hj\u00e6lper med at opn\u00e5 maksimal ydelse i sidste ende.<\/p>\n
<\/p>\n
Jeg har et sp\u00f8rgsm\u00e5l mere, der h\u00e6nger sammen med dette. Kubernetes er designet s\u00e5ledes, at det ikke er vigtigt for os, om vi mister en node eller ej. Hvad skal vi g\u00f8re, hvis vi har mistet den node, hvor vores shard er placeret?<\/em><\/p>\n<\/p>\n
Ja, Kubernetes er oprindeligt positioneret s\u00e5dan, at vores forhold til vores pod'e er som kv\u00e6g, men her bliver hver disk noget, der minder mere om et k\u00e6ledyr. Der er et problem, at vi ikke bare kan kaste dem v\u00e6k. Udviklingen af Kubernetes g\u00e5r i den retning, at man ikke helt kan forholde sig til dette filosofisk som til fuldst\u00e6ndig udskiftelige ressourcer.<\/p>\n
<\/p>\n
Nu til et praktisk sp\u00f8rgsm\u00e5l. Hvad skal man g\u00f8re, hvis en node, hvor disken var, er blevet tabt? Det problem l\u00f8ses allerede p\u00e5 et h\u00f8jere niveau. I tilf\u00e6lde af ClickHouse har vi replikaer, der arbejder p\u00e5 et niveau over, dvs. p\u00e5 ClickHouse-niveau.<\/p>\n
<\/p>\n
Hvad er fordelingen? DevOps er ansvarlig for, at ingen data g\u00e5r tabt. Han skal korrekt konfigurere replikationen og overv\u00e5ge, at replikationen udf\u00f8res. Dataene skal v\u00e6re duplikeret i replikatet p\u00e5 ClickHouse-niveau. Det er ikke en opgave, som operat\u00f8ren l\u00f8ser. Og det er ikke en opgave, som Kubernetes selv l\u00f8ser. Det er p\u00e5 ClickHouse-niveau.<\/p>\n
<\/p>\n
Hvad skal man g\u00f8re, hvis jernnoden svigter? Og s\u00e5 skal man s\u00e6tte en anden op, korrekt provisionere en disk, p\u00e5f\u00f8re labels. Og derefter vil den opfylde kravene, s\u00e5 Kubernetes kan starte en instans af pod'en p\u00e5 den. Kubernetes vil starte den. I har jo ikke nok pods til det angivne antal. Den vil gennemg\u00e5 den cyklus, som jeg viste. Og p\u00e5 det \u00f8verste niveau vil ClickHouse forst\u00e5, at der er kommet en replik, den er stadig tom, og data skal begynde at flydes over til den. Alts\u00e5, denne proces er stadig d\u00e5rligt automatiseret. <\/p>\n
<\/p>\n
Tak for opl\u00e6gget! N\u00e5r der sker forskellige problemer, og operat\u00f8ren falder og genstarter, mens begivenhederne forts\u00e6tter med at komme, hvordan h\u00e5ndterer I det?<\/em><\/p>\n<\/p>\n
Hvad sker der, hvis operat\u00f8ren falder og genstarter, ikke? <\/p>\n
<\/p>\n
Ja. Og p\u00e5 det tidspunkt kom der begivenheder.<\/em> <\/p>\n<\/p>\n
Opgaven om, hvad der skal g\u00f8res i dette tilf\u00e6lde, er delvist opdelt mellem operat\u00f8ren og Kubernetes. Kubernetes har mulighed for at afspille de indtrufne begivenheder igen. Han afspiller dem. Og operat\u00f8rens opgave er at sikre, at n\u00e5r loggen med begivenhederne bliver afspillet til ham, s\u00e5 er disse begivenheder idempotente. Og at en gentagelse af den samme begivenhed ikke \u00f8del\u00e6gger vores system. Og vores operat\u00f8r klarer denne opgave. <\/p>\n
<\/p>\n
Hej! Tak for opl\u00e6gget! Dmitry Zavyalov, selskab<\/em> Smedova. Er der planer om at tilf\u00f8je mulighed for konfiguration med haproxy i operat\u00f8ren? Jeg er interesseret i en anden balancerer udover den standard, s\u00e5 den er smart og forst\u00e5r, at der faktisk er ClickHouse der.<\/em> <\/p>\n<\/p>\n
Taler du om Ingress?<\/p>\n
<\/p>\n
Ja, erstat Ingress med haproxy. I haproxy kan man angive topologien for klyngen, hvor dens replikater befinder sig.<\/em><\/p>\n<\/p>\n
Vi har ikke t\u00e6nkt over det endnu. Hvis du har brug for det og kan forklare, hvorfor det er n\u00f8dvendigt, kan vi overveje at implementere det, is\u00e6r hvis du \u00f8nsker at deltage. Vi vil med gl\u00e6de se p\u00e5 muligheden. Kort sagt \u2013 nej, vi har ikke denne funktionalitet i \u00f8jeblikket. Tak for tippet, vi vil kigge p\u00e5 det. Hvis du ogs\u00e5 kan forklare use case og hvorfor det er n\u00f8dvendigt i praksis, for eksempel ved at oprette issues p\u00e5 GitHub, ville det v\u00e6re fremragende.<\/p>\n
<\/p>\n
Der er allerede noget.<\/em><\/p>\n<\/p>\n
Godt. Vi er \u00e5bne for enhver forslag. Og haproxy er p\u00e5 todo-listen. Todo-listen vokser, men falder ikke endnu. Men det er godt, det betyder, at produktet er efterspurgt.<\/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