Local<\/li>\n<\/ul>\n<\/p>\n
L\u00e5t oss titta p\u00e5 hur de skiljer sig \u00e5t och vad de har gemensamt. <\/p>\n
<\/p>\n
F\u00f6r det f\u00f6rsta har vi i alla tre metoderna lagring \u2013 det \u00e4r lokala diskar som finns p\u00e5 samma fysiska k8s-nod. Men de har vissa skillnader.<\/p>\n
<\/p>\n
<\/p>\n
Vi b\u00f6rjar med det enklaste, dvs. med emptyDir. Vad \u00e4r detta i praktiken? Det \u00e4r n\u00e4r vi ber v\u00e5rt system f\u00f6r containerhantering (oftast Docker) att ge oss \u00e5tkomst till en mapp p\u00e5 den lokala disken.<\/p>\n
<\/p>\n
I praktiken skapar Docker n\u00e5gonstans p\u00e5 sina egna v\u00e4gar en tempor\u00e4r mapp, d\u00f6per den till en l\u00e5ng hash. Och ger ett gr\u00e4nssnitt f\u00f6r \u00e5tkomst till den. <\/p>\n
<\/p>\n
Hur kommer detta att fungera sett till prestanda? Det kommer att fungera med hastigheten av den lokala disken, dvs. det \u00e4r en fullst\u00e4ndig \u00e5tkomst till sin enhet. <\/p>\n
<\/p>\n
Men detta har sin nackdel. Persistent i detta avseende \u00e4r ganska os\u00e4kert. Vid den minsta inverkan av Docker p\u00e5 containrarna f\u00f6rloras persistent data. Om Kubernetes av n\u00e5gon anledning vill flytta denna Pod till en annan disk, s\u00e5 g\u00e5r uppgifterna f\u00f6rlorade. <\/p>\n
<\/p>\n
Denna metod \u00e4r bra f\u00f6r tester, eftersom hastigheten redan \u00e4r acceptabel, men f\u00f6r n\u00e5got mer seri\u00f6st \u00e4r detta alternativ inte l\u00e4mpligt. <\/p>\n
<\/p>\n
<\/p>\n
D\u00e4rf\u00f6r finns det en andra metod. Det \u00e4r hostPath. Om man tittar p\u00e5 den f\u00f6reg\u00e5ende sliden och denna, s\u00e5 kan man se bara en enda skillnad. V\u00e5r mapp har flyttat fr\u00e5n Docker direkt till Kubernetes-noden. H\u00e4r \u00e4r det lite enklare. Vi anger direkt s\u00f6kv\u00e4gen i det lokala filsystemet d\u00e4r vi vill lagra v\u00e5ra data. <\/p>\n
<\/p>\n
F\u00f6rdelar finns med denna metod. Det \u00e4r redan en riktig persistent lagring, och dessutom klassisk. Uppgifterna kommer att skrivas till disken p\u00e5 en viss adress. <\/p>\n
<\/p>\n
Det finns nackdelar. Det handlar om hanteringskomplexitet. V\u00e5r Kubernetes kan vilja flytta en Pod till en annan fysisk nod. H\u00e4r kommer DevOps in i bilden. De m\u00e5ste f\u00f6rklara systemet korrekt att dessa pods bara kan flyttas till s\u00e5dana noder som har n\u00e5got monterat l\u00e4ngs dessa v\u00e4gar, och h\u00f6gst en nod \u00e5t g\u00e5ngen. Det \u00e4r ganska komplicerat. <\/p>\n
<\/p>\n
F\u00f6r dessa \u00e4ndam\u00e5l har vi skapat mallar hos oss som operat\u00f6r f\u00f6r att d\u00f6lja all denna komplexitet. Man skulle enkelt kunna s\u00e4ga: \"Jag vill ha en instans av ClickHouse p\u00e5 varje fysisk nod och i en specifik s\u00f6kv\u00e4g.\" <\/p>\n
<\/p>\n
<\/p>\n
Men denna n\u00f6dv\u00e4ndighet g\u00e4ller inte bara oss, d\u00e4rf\u00f6r f\u00f6rst\u00e5r \u00e4ven herrarna fr\u00e5n Kubernetes att m\u00e4nniskor vill ha tillg\u00e5ng till fysiska diskar, s\u00e5 de erbjuder en tredje niv\u00e5.<\/p>\n
<\/p>\n
Den kallas local. Det finns praktiskt taget ingen skillnad fr\u00e5n f\u00f6reg\u00e5ende bild. Tidigare var vi tvungna att manuellt genomf\u00f6ra att dessa pods inte kunde flyttas fr\u00e5n nod till nod, eftersom de m\u00e5ste vara kopplade langs en specifik s\u00f6kv\u00e4g till den lokala fysiska disken, men nu inkapslas all denna kunskap inom Kubernetes. Det blir mycket enklare att konfigurera.<\/p>\n
<\/p>\n
<\/p>\n
L\u00e5t oss \u00e5terg\u00e5 till v\u00e5r praktiska uppgift. L\u00e5t oss \u00e5terg\u00e5 till YAML-mallen. H\u00e4r har vi en riktig lagring. Vi kom tillbaka till detta. Vi definierar en klassisk VolumeClaim-mall som i k8s. Och beskriver vilken lagring vi vill ha.<\/p>\n
<\/p>\n
Efter detta kommer k8s att beg\u00e4ra lagring. Det kommer att tilldela det till oss i StatefulSet. Och slutligen kommer det att bli tillg\u00e4ngligt f\u00f6r ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Vi hade en s\u00e5dan h\u00e4r schema. V\u00e5r Persistenta Lagring var r\u00f6d, vilket liksom antydde att vi borde \u00e5tg\u00e4rda det. <\/p>\n
<\/p>\n
<\/p>\n
Och den blir gr\u00f6n. Nu har schemat f\u00f6r ClickHouse-klustret p\u00e5 k8s fullbordats. Vi har shards, repliker, ZooKeeper, och det finns en riktig Persistent, som har realiserats p\u00e5 olika s\u00e4tt. Schemat \u00e4r nu helt fungerande. <\/p>\n
<\/p>\n
<\/p>\n
Vi forts\u00e4tter fram\u00e5t. V\u00e5rt kluster v\u00e4xer. Och Aleksej anstr\u00e4nger sig och sl\u00e4pper en ny version av ClickHouse.<\/p>\n
<\/p>\n
En praktisk uppgift uppst\u00e5r \u2013 att testa den nya versionen av ClickHouse p\u00e5 v\u00e5rt kluster. Naturligtvis vill vi inte rulla ut den helt, vi vill kanske s\u00e4tta en ny version i ett avl\u00e4gset h\u00f6rn p\u00e5 en replika, och kanske inte bara en ny version, utan tv\u00e5, eftersom de sl\u00e4pps ganska ofta. <\/p>\n
<\/p>\n
Vad kan vi s\u00e4ga om detta?<\/p>\n
<\/p>\n
<\/p>\n
H\u00e4r har vi precis en s\u00e5dan m\u00f6jlighet. Det handlar om mallarna f\u00f6r poddar. Vi kan specificera hur v\u00e5r operator helt och h\u00e5llet till\u00e5ter att bygga en heterogen kluster. Det vill s\u00e4ga konfigurera, fr\u00e5n att ha alla repliker i en h\u00f6g, till att ha varje individuell replika med vilken version av ClickHouse vi vill ha, vilken lagringsversion vi vill ha. Vi kan helt konfigurera klustret enligt den konfiguration vi beh\u00f6ver. <\/p>\n
<\/p>\n
<\/p>\n
Nu kommer vi att f\u00f6rdjupa oss lite mer. Tidigare har vi pratat om hur ClickHouse-operatorn fungerar specifikt f\u00f6r ClickHouse.<\/p>\n
<\/p>\n
Nu skulle jag vilja s\u00e4ga n\u00e5gra ord om hur vilken operator som helst fungerar, samt hur den interagerar med K8s.<\/p>\n
<\/p>\n
<\/p>\n
Vi b\u00f6rjar med att titta p\u00e5 interaktionen med K8s. Vad h\u00e4nder n\u00e4r vi g\u00f6r kubectl apply? V\u00e5ra objekt dyker upp i etcd via API:et. <\/p>\n
<\/p>\n
<\/p>\n
Till exempel de grundl\u00e4ggande objekten i Kubernetes: pod, StatefulSet, service och s\u00e5 vidare. <\/p>\n
<\/p>\n
Ingenting fysiskt h\u00e4nder \u00e4nnu. Dessa objekt m\u00e5ste materialiseras i klustret. <\/p>\n
<\/p>\n
<\/p>\n
F\u00f6r detta kommer en controller in i bilden. En controller \u00e4r en speciell komponent i k8s som vet hur man materialiserar dessa beskrivningar. Den vet hur och vad som m\u00e5ste g\u00f6ras fysiskt. Den vet hur man startar containrar och vad som m\u00e5ste konfigureras f\u00f6r att servern ska fungera. <\/p>\n
<\/p>\n
<\/p>\n
Och den materialiserar v\u00e5ra objekt i K8s.<\/p>\n
<\/p>\n
Men vi vill inte bara hantera poddar och StatefulSet:er, vi vill skapa ClickHouseInstallation, det vill s\u00e4ga ett objekt av typen ClickHouse, f\u00f6r att hantera det som en helhet. F\u00f6r n\u00e4rvarande finns det ingen s\u00e5dan m\u00f6jlighet. <\/p>\n
<\/p>\n
<\/p>\n
Men K8s har en annan trevlig funktion. Vi vill att det ska finnas en s\u00e5dan komplex entitet d\u00e4r v\u00e5r kluster sammanst\u00e4lls av poddar och StatefulSet. <\/p>\n
<\/p>\n
<\/p>\n
Vad beh\u00f6ver vi g\u00f6ra f\u00f6r detta? F\u00f6r det f\u00f6rsta kommer Custom Resource Definition in p\u00e5 scenen. Vad \u00e4r det? Det \u00e4r en beskrivning f\u00f6r K8s av att du kommer f\u00e5 ytterligare en datatyp, och att vi vill l\u00e4gga till en anpassad resurs f\u00f6r poddar och StatefulSet, som blir komplex inuti. Det \u00e4r en beskrivning av datastukturen. <\/p>\n
<\/p>\n
<\/p>\n
Vi skickar ocks\u00e5 denna via kubectl apply dit. Kubernetes tar den med gl\u00e4dje. <\/p>\n
<\/p>\n
Och nu har vi i lagringen, hos objektet i etcd, m\u00f6jlighet att registrera den anpassade resursen med namnet ClickHouseInstallation.<\/p>\n
<\/p>\n
Men f\u00f6r nu kommer ingenting att h\u00e4nda. D.v.s. om vi nu skapar en YAML-fil som vi diskuterade med beskrivning av shards, repliker och s\u00e4ger \"kubectl apply\", s\u00e5 kommer Kubernetes att ta emot den, spara den i etcd och s\u00e4ga: \"Bra, men jag vet inte vad jag ska g\u00f6ra med den. Jag vet inte hur man underh\u00e5ller ClickHouseInstallation.\" <\/p>\n
<\/p>\n
<\/p>\n
D\u00e4rf\u00f6r beh\u00f6ver vi n\u00e5gon som hj\u00e4lper Kubernetes att underh\u00e5lla den nya datatypen. Till v\u00e4nster har vi den inbyggda Kubernetes-controllern som arbetar med inbyggda datatyper. Och till h\u00f6ger b\u00f6r vi f\u00e5 en anpassad controller som kan arbeta med anpassade datatyper. <\/p>\n
<\/p>\n
Och p\u00e5 ett annat s\u00e4tt kallas den operat\u00f6r. Jag har specifikt placerat den utanf\u00f6r Kubernetes, eftersom den kan k\u00f6ras utanf\u00f6r K8s. Oftast k\u00f6rs dock alla operat\u00f6rer i Kubernetes, men ingenting hindrar den fr\u00e5n att st\u00e5 utanf\u00f6r, d\u00e4rf\u00f6r har den placerats externt h\u00e4r. <\/p>\n
<\/p>\n
<\/p>\n
Och i sin tur interagerar den anpassade controllern, \u00e4ven kallad operat\u00f6r, med Kubernetes via API. Den kan redan interagera med API. Och den vet redan hur man materialiserar en komplex struktur fr\u00e5n en anpassad resurs, som vi vill skapa. Det \u00e4r precis det operat\u00f6ren g\u00f6r. <\/p>\n
<\/p>\n
<\/p>\n
Hur fungerar operat\u00f6ren? L\u00e5t oss titta p\u00e5 den h\u00f6gra delen f\u00f6r att f\u00f6rst\u00e5 hur den g\u00f6r detta. Vi ska ta reda p\u00e5 hur operat\u00f6ren materialiserar allt detta och hur interaktionen med K8s g\u00e5r till.<\/p>\n
<\/p>\n
<\/p>\n
Operat\u00f6ren \u00e4r ett program. Det \u00e4r h\u00e4ndelsestyrt. Operat\u00f6ren registrerar sig via Kubernetes API f\u00f6r h\u00e4ndelser. I Kubernetes API finns ing\u00e5ngspunkter d\u00e4r man kan registrera sig f\u00f6r h\u00e4ndelser. Och om n\u00e5got f\u00f6r\u00e4ndras i K8s, skickar Kubernetes h\u00e4ndelser till alla som vill, d.v.s. den som har registrerat sig p\u00e5 den h\u00e4r API-punkten f\u00e5r meddelanden.<\/p>\n
<\/p>\n
Operat\u00f6ren registrerar sig f\u00f6r h\u00e4ndelser och m\u00e5ste reagera p\u00e5 dem. Dess uppgift \u00e4r att reagera p\u00e5 uppkommande h\u00e4ndelser. <\/p>\n
<\/p>\n
<\/p>\n
H\u00e4ndelser genereras av vissa uppdateringar. V\u00e5r YAML-fil med beskrivningen av ClickHouseInstallation kommer in. Den har g\u00e5tt till etcd genom kubectl apply. D\u00e4r utl\u00f6ste det en h\u00e4ndelse, och denna h\u00e4ndelse kom till ClickHouse-operat\u00f6ren. Operat\u00f6ren fick denna beskrivning. Och den m\u00e5ste g\u00f6ra n\u00e5got. Om en uppdatering av objektet ClickHouseInstallation har kommit, s\u00e5 m\u00e5ste klustret uppdateras. Och operat\u00f6rens uppgift \u00e4r att uppdatera klustret. <\/p>\n
<\/p>\n
<\/p>\n
Vad g\u00f6r han? F\u00f6rst och fr\u00e4mst m\u00e5ste en handlingsplan uppr\u00e4ttas f\u00f6r vad vi ska g\u00f6ra med denna uppdatering. Uppdateringar kan vara mycket sm\u00e5, det vill s\u00e4ga sm\u00e5 i YAML-implementering, men de kan leda till mycket stora f\u00f6r\u00e4ndringar i klustret. D\u00e4rf\u00f6r skapar operat\u00f6ren en plan och f\u00f6ljer den d\u00e4refter.<\/p>\n
<\/p>\n
<\/p>\n
Han b\u00f6rjar att enligt denna plan bearbeta denna struktur inuti f\u00f6r att materialisera poddar, tj\u00e4nster, det vill s\u00e4ga g\u00f6ra det som \u00e4r hans huvuduppgift. Det \u00e4r som att bygga ett ClickHouse-kluster i Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Nu ska vi ta upp en intressant sak. Det \u00e4r delningen av ansvar mellan Kubernetes och operat\u00f6ren, det vill s\u00e4ga vad Kubernetes g\u00f6r, vad operat\u00f6ren g\u00f6r och hur de interagerar med varandra. <\/p>\n
<\/p>\n
Kubernetes ansvarar f\u00f6r systemrelaterade saker, det vill s\u00e4ga f\u00f6r den grundl\u00e4ggande upps\u00e4ttningen objekt som kan tolkas som systemomfattande. Kubernetes vet hur man startar poddar, hur man startar om containrar, hur man monterar volymer, hur man arbetar med ConfigMap, det vill s\u00e4ga allt som kan kallas systemet. <\/p>\n
<\/p>\n
Operat\u00f6rer arbetar inom specifika \u00e4mnesomr\u00e5den. Varje operat\u00f6r \u00e4r specifik f\u00f6r sitt \u00e4mnesomr\u00e5de. Vi har gjort en f\u00f6r ClickHouse.<\/p>\n
<\/p>\n
Och operat\u00f6ren interagerar just i termer av \u00e4mnesomr\u00e5den, s\u00e5som att l\u00e4gga till en replik, skapa ett schema, st\u00e4lla in \u00f6vervakning. Det blir en s\u00e5dan separation.<\/p>\n
<\/p>\n
<\/p>\n
L\u00e5t oss titta p\u00e5 ett praktiskt exempel p\u00e5 hur denna ansvarsdela sker n\u00e4r vi utf\u00f6r \u00e5tg\u00e4rden att l\u00e4gga till en replik. <\/p>\n
<\/p>\n
Operat\u00f6ren f\u00e5r i uppdrag att l\u00e4gga till en replik. Vad g\u00f6r operat\u00f6ren? Operat\u00f6ren ber\u00e4knar att en ny StatefulSet m\u00e5ste skapas, d\u00e4r s\u00e5dana mallar och volymanspr\u00e5k m\u00e5ste beskrivas. <\/p>\n
<\/p>\n
<\/p>\n
Han har f\u00f6rberett allt detta och vidarebefordrar det till K8s. Han s\u00e4ger att han beh\u00f6ver ConfigMap, StatefulSet, Volym. Kubernetes utf\u00f6r det. Han materialiserar de grundl\u00e4ggande enheter som han arbetar med. <\/p>\n
<\/p>\n
<\/p>\n
Och sedan kommer ClickHouse-operat\u00f6ren \u00e5terigen in i bilden. Han har redan en fysisk pod d\u00e4r man kan g\u00f6ra n\u00e5got. Och ClickHouse-operat\u00f6ren arbetar \u00e5terigen i termer av \u00e4mnesomr\u00e5den. Det vill s\u00e4ga f\u00f6r ClickHouse, f\u00f6r att aktivera en replik i klustret, m\u00e5ste dataskeman som finns i detta kluster st\u00e4llas in. Och f\u00f6r det andra m\u00e5ste denna replik inkluderas i \u00f6vervakning s\u00e5 att den kan sp\u00e5ras v\u00e4l. Det \u00e4r operat\u00f6ren som st\u00e4ller detta in. <\/p>\n
<\/p>\n
<\/p>\n
Och f\u00f6rst efter detta kommer sj\u00e4lva ClickHouse i spel, det vill s\u00e4ga ytterligare en mer h\u00f6gst\u00e5ende enhet. Detta \u00e4r redan en databas. Den har sin egen instans, en konfigurerad replika som \u00e4r redo att g\u00e5 in i klustret.<\/p>\n
<\/p>\n
Det blir en l\u00e5ng kedja av utf\u00f6rande och ansvarsf\u00f6rdelning vid till\u00e4gg av en replika.<\/p>\n
<\/p>\n
<\/p>\n
Vi forts\u00e4tter med v\u00e5ra praktiska uppgifter. Om klustret redan finns kan vi genomf\u00f6ra migrering av konfigurering. <\/p>\n
<\/p>\n
<\/p>\n
Vi har gjort det s\u00e5 att i den befintliga xml som ClickHouse f\u00f6rst\u00e5r kan vi skicka igenom data.<\/p>\n
<\/p>\n
<\/p>\n
Det g\u00e5r att g\u00f6ra en finjustering av ClickHouse. Just zonad distribution \u00e4r det jag n\u00e4mnde n\u00e4r jag f\u00f6rklarade hostPath, lokal lagring. Hur man korrekt g\u00f6r zonad distribution.<\/p>\n
<\/p>\n
<\/p>\n
Den n\u00e4sta praktiska uppgiften \u00e4r \u00f6vervakning.<\/p>\n
<\/p>\n
<\/p>\n
Om v\u00e5rt kluster f\u00f6r\u00e4ndras m\u00e5ste vi periodiskt st\u00e4lla in \u00f6vervakningen. <\/p>\n
<\/p>\n
L\u00e5t oss titta p\u00e5 schemat. Vi har redan diskuterat de gr\u00f6na pilarna. Nu l\u00e5t oss titta p\u00e5 de r\u00f6da pilarna. Det \u00e4r hur vi vill \u00f6vervaka v\u00e5rt kluster. Hur m\u00e4tv\u00e4rden fr\u00e5n ClickHouse-klustret hamnar i Prometheus, och sedan i Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Vad \u00e4r sv\u00e5righeten med \u00f6vervakning? Varf\u00f6r framh\u00e5lls det som n\u00e5gon slags prestation? Sv\u00e5righeten ligger just i dynamiken. N\u00e4r vi har ett kluster och det \u00e4r statiskt kan vi en g\u00e5ng st\u00e4lla in \u00f6vervakningen och sedan inte bekymra oss mer.<\/p>\n
<\/p>\n
Men om vi har m\u00e5nga kluster, eller om n\u00e5got st\u00e4ndigt \u00e4ndras, s\u00e5 \u00e4r processen dynamisk. Att st\u00e4ndigt beh\u00f6va omkonfigurera \u00f6vervakningen \u00e4r en sl\u00f6seri med resurser och tid, det vill s\u00e4ga \u00e4ven bara lathet. Detta m\u00e5ste automatiseras. Sv\u00e5righeten ligger just i den dynamiska processen. Och operat\u00f6ren automatiserar detta mycket bra. <\/p>\n
<\/p>\n
<\/p>\n
Hur har v\u00e5rt kluster utvecklats? I b\u00f6rjan s\u00e5g det ut s\u00e5 h\u00e4r.<\/p>\n
<\/p>\n
<\/p>\n
Sedan s\u00e5g det ut s\u00e5 h\u00e4r.<\/p>\n
<\/p>\n
<\/p>\n
I slut\u00e4ndan blev det s\u00e5 h\u00e4r. <\/p>\n
<\/p>\n
Och \u00f6vervakningen g\u00f6rs automatiskt av operat\u00f6ren. En enda ing\u00e5ngspunkt. <\/p>\n
<\/p>\n
<\/p>\n
Och vi tittar bara p\u00e5 utdata i Grafana-dashboarden, hur livet i v\u00e5rt kluster pulserar inuti. <\/p>\n
<\/p>\n
F\u00f6r \u00f6vrigt sprids ocks\u00e5 Grafana-dashboards med v\u00e5r operat\u00f6r direkt i k\u00e4llkoden. Man kan ansluta och anv\u00e4nda det. Denna sk\u00e4rmdump fick jag av v\u00e5ra DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Vart skulle vi vilja g\u00e5 h\u00e4rifr\u00e5n? Det \u00e4r:<\/p>\n
<\/p>\n
\nAtt utveckla automatisering av testning. Huvuduppgiften \u00e4r automatisk testning av nya versioner. <\/li>\n Vi vill ocks\u00e5 automatisera integrationen med ZooKeeper. Vi planerar att integrera med ZooKeeper-operatorn. Det vill s\u00e4ga, en operator f\u00f6r ZooKeeper har skrivits och det \u00e4r logiskt att de tv\u00e5 operatorerna b\u00f6rjar integrera sig f\u00f6r att bygga en mer bekv\u00e4m l\u00f6sning. <\/li>\n Vi vill g\u00f6ra mer komplexa livscykelkontroller. <\/li>\n Jag har markerat i gr\u00f6nt det som \u00e4r p\u00e5 g\u00e5ng \u2014 arv av mallar \u2013 KLAR, allts\u00e5 i n\u00e4sta version av operatorn kommer vi redan att ha m\u00f6jligheten att arva mallar. Detta \u00e4r ett kraftfullt verktyg som m\u00f6jligg\u00f6r att bygga komplexa konfigurationer fr\u00e5n bitar. <\/li>\n Och vi vill automatisera komplexa uppgifter. Den st\u00f6rsta av dem \u00e4r Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
L\u00e5t oss g\u00f6ra en mellanliggande sammanfattning. <\/p>\n
<\/p>\n
<\/p>\n
Vad f\u00e5r vi ut p\u00e5 andra sidan? \u00c4r det v\u00e4rt att syssla med detta eller inte? Borde vi alls f\u00f6rs\u00f6ka dra databasen till Kubernetes och anv\u00e4nda operatorn i allm\u00e4nhet och Alitnity-operatorn i synnerhet?<\/p>\n
<\/p>\n
Resultatet blir:<\/p>\n
<\/p>\n
\nV\u00e4sentlig f\u00f6renkling och automatisering av konfiguration, distribution samt underh\u00e5ll. <\/li>\n Omedelbart inbyggd \u00f6vervakning. <\/li>\n Och f\u00e4rdiga, kodifierade mallar f\u00f6r komplexa situationer. Redan \u00e5tg\u00e4rder som att l\u00e4gga till en replik beh\u00f6ver inte g\u00f6ras manuellt. Det g\u00f6r operatorn. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Det finns bara en sista fr\u00e5ga kvar. Vi har redan databasen i Kubernetes, virtualisering. Hur \u00e4r det med prestandan hos en s\u00e5dan l\u00f6sning, s\u00e4rskilt med tanke p\u00e5 att ClickHouse \u00e4r optimerad f\u00f6r prestanda?<\/p>\n
<\/p>\n
Svaret \u2013 allt \u00e4r okej! Jag kommer inte att g\u00e5 in p\u00e5 detaljer, det \u00e4r ett \u00e4mne f\u00f6r en separat presentation. <\/p>\n
<\/p>\n
<\/p>\n
Men det finns ett projekt som heter TSBS. Vad \u00e4r dess huvuduppgift? Det \u00e4r en prestandatest av databaser. Det \u00e4r ett f\u00f6rs\u00f6k att j\u00e4mf\u00f6ra lika med lika. <\/p>\n
<\/p>\n
Hur fungerar det? En upps\u00e4ttning data genereras. Sedan k\u00f6rs denna upps\u00e4ttning data genom samma upps\u00e4ttning tester p\u00e5 olika databaser. Och varje databas l\u00f6ser en uppgift p\u00e5 det s\u00e4tt som den kan. Sedan kan resultaten j\u00e4mf\u00f6ras. <\/p>\n
<\/p>\n
Det st\u00f6der redan m\u00e5nga databaser. Jag har markerat tre huvudsakliga. Det \u00e4r:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Det har ocks\u00e5 gjorts en j\u00e4mf\u00f6relse med en annan liknande l\u00f6sning. En j\u00e4mf\u00f6relse med RedShift. J\u00e4mf\u00f6relsen gjordes p\u00e5 Amazon. ClickHouse sl\u00e5r ocks\u00e5 alla i denna fr\u00e5ga. <\/p>\n
<\/p>\n
<\/p>\n
Vilka slutsatser kan dras fr\u00e5n det jag har ber\u00e4ttat?<\/p>\n
<\/p>\n
\nDatabaser i Kubernetes \u00e4r m\u00f6jliga. Troligtvis kan man anv\u00e4nda vilken som helst, men \u00f6verlag verkar det som att det \u00e4r m\u00f6jligt. ClickHouse i Kubernetes kan definitivt anv\u00e4ndas av v\u00e5r operat\u00f6r. <\/li>\n Operat\u00f6ren hj\u00e4lper till att automatisera processer och f\u00f6renklar verkligen livet.<\/li>\n Prestandan \u00e4r normal.<\/li>\n Och vi tycker att detta \u00e4r n\u00e5got som b\u00e5de kan och b\u00f6r anv\u00e4ndas. <\/li>\n<\/ul>\n<\/p>\n
\u00d6ppen k\u00e4llkod \u2013 g\u00e5 med!<\/p>\n
<\/p>\n
Som jag redan n\u00e4mnt, operat\u00f6ren \u00e4r en helt \u00f6ppen k\u00e4llkodsprodukt, s\u00e5 det skulle vara mycket bra om s\u00e5 m\u00e5nga som m\u00f6jligt anv\u00e4nde den. G\u00e5 med! Vi v\u00e4ntar p\u00e5 er alla!<\/p>\n
<\/p>\n
Tack alla!<\/p>\n
<\/p>\n
Fr\u00e5gor<\/p>\n
<\/p>\n
<\/p>\n
Tack f\u00f6r presentationen! Jag heter Anton. Jag kommer fr\u00e5n f\u00f6retaget SEMrush. Jag undrar \u00f6ver loggning. Jag har h\u00f6rt om \u00f6vervakning, men inget om loggning n\u00e4r det g\u00e4ller hela klustret. Vi har exempelvis satt upp ett kluster p\u00e5 h\u00e5rdvara. Och vi anv\u00e4nder centraliserad loggning, samlar in med standardverktyg till en gemensam plats. Och sedan h\u00e4mtar vi intressanta data d\u00e4rifr\u00e5n.<\/em> <\/p>\n<\/p>\n
Bra fr\u00e5ga, det vill s\u00e4ga loggning st\u00e5r p\u00e5 listan \u00f6ver att g\u00f6ra. V\u00e5r operat\u00f6r automatiserar fortfarande inte detta. Den utvecklas fortfarande, projektet \u00e4r relativt ungt. Vi f\u00f6rst\u00e5r behovet av loggning. Det \u00e4r ocks\u00e5 ett mycket viktigt \u00e4mne. Och det \u00e4r nog inte mindre viktigt \u00e4n \u00f6vervakning. Men f\u00f6rst p\u00e5 listan f\u00f6r implementering var \u00f6vervakning. Loggning kommer att ske. Vi f\u00f6rs\u00f6ker naturligtvis automatisera alla aspekter av klusterets livscykel. S\u00e5 svaret \u00e4r att i nul\u00e4get kan operat\u00f6ren tyv\u00e4rr inte detta, men det finns p\u00e5 planerna, vi kommer att g\u00f6ra detta. Om det finns intresse att g\u00e5 med, g\u00f6r g\u00e4rna en pull request.<\/p>\n
<\/p>\n
Hej! Tack f\u00f6r presentationen! Jag har en standardfr\u00e5ga som r\u00f6r Persistenta Volymer. N\u00e4r vi skapar en konfiguration med denna operat\u00f6r, hur best\u00e4mmer operat\u00f6ren p\u00e5 vilken nod vi har monterat en viss disk eller mapp? M\u00e5ste vi f\u00f6rklara f\u00f6r den att den ska placera v\u00e5r ClickHouse just p\u00e5 dessa noder d\u00e4r det finns en disk?<\/em><\/p>\n<\/p>\n
S\u00e5vitt jag f\u00f6rst\u00e5r, denna fr\u00e5ga \u00e4r en forts\u00e4ttning p\u00e5 lokal lagring, s\u00e4rskilt delen som r\u00f6r hostPath. Det handlar om att f\u00f6rklara hela systemet att en pod ska startas p\u00e5 en viss nod, d\u00e4r vi har en fysiskt ansluten disk som \u00e4r monterad p\u00e5 en viss v\u00e4g. Det \u00e4r en hel sektion som jag endast ber\u00f6rt ytligt, f\u00f6r svaret \u00e4r ganska omfattande. <\/p>\n
<\/p>\n
Sammanfattningsvis ser det ut s\u00e5 h\u00e4r. Sj\u00e4lvklart m\u00e5ste vi g\u00f6ra provisioning av dessa volymer. F\u00f6r n\u00e4rvarande finns det ingen dynamisk provisioning i lokal lagring, s\u00e5 DevOps m\u00e5ste sj\u00e4lva partitionera diskarna, allts\u00e5 dessa volymer. Och de m\u00e5ste f\u00f6rklara f\u00f6r Kubernetes provisioning att du kommer att ha Persistent volumes av en viss klass som finns p\u00e5 vissa noder. Sen m\u00e5ste de f\u00f6rklara f\u00f6r Kubernetes att poddar som kr\u00e4ver en viss klass av lokal lagring, m\u00e5ste schemal\u00e4ggas endast p\u00e5 dessa noder. F\u00f6r dessa syften finns det m\u00f6jlighet att tilldela vissa etiketter och en per v\u00e4rdinstans. Och det kommer att resultera i att poddarna kommer att routas av Kubernetes f\u00f6r att bara k\u00f6ras p\u00e5 noder som uppfyller kraven, etiketter, f\u00f6r att uttrycka det enkelt. Administrat\u00f6rerna tilldelar etiketter, g\u00f6r provisioning av diskarna manuellt. Och d\u00e5 g\u00e5r det att skala.<\/p>\n
<\/p>\n
Och just den tredje varianten av lokal lagring hj\u00e4lper att f\u00f6renkla detta n\u00e5got. Som jag redan har betonat, \u00e4r det ett noggrant arbete med inst\u00e4llningar som i slut\u00e4nden hj\u00e4lper att f\u00e5 ut maximal prestanda.<\/p>\n
<\/p>\n
Jag har en andra fr\u00e5ga som \u00e4r relaterad till detta. Kubernetes \u00e4r utformad s\u00e5 att vi inte ska bry oss om vi f\u00f6rlorar en nod eller inte. Vad ska vi g\u00f6ra i det h\u00e4r fallet om vi har f\u00f6rlorat noden d\u00e4r v\u00e5r shard finns?<\/em><\/p>\n<\/p>\n
Ja, Kubernetes positionerade sig fr\u00e5n b\u00f6rjan s\u00e5 att v\u00e5r relation till v\u00e5ra poddar \u00e4r som boskap, men h\u00e4r blir varje disk n\u00e5got som liknar ett husdjur. Det finns ett problem med att vi inte kan sl\u00e4nga dem hur som helst. Och utvecklingen av Kubernetes g\u00e5r i en riktning d\u00e4r vi inte kan helt hantera detta filosofiskt som helt f\u00f6rbrukningsbara resurser.<\/p>\n
<\/p>\n
Nu till den praktiska fr\u00e5gan. Vad ska man g\u00f6ra om en nod som hade disken f\u00f6rsvann? H\u00e4r l\u00f6ser man problemet p\u00e5 en h\u00f6gre niv\u00e5. I fallet med ClickHouse har vi replikat som arbetar p\u00e5 en h\u00f6gre niv\u00e5, allts\u00e5 p\u00e5 ClickHouse-niv\u00e5.<\/p>\n
<\/p>\n
Vad blir dispositionen? DevOps ansvarar f\u00f6r att inga data g\u00e5r f\u00f6rlorade. De m\u00e5ste korrekt st\u00e4lla in replikeringen och f\u00f6lja upp s\u00e5 att replikeringen utf\u00f6rs. I replikatet p\u00e5 ClickHouse-niv\u00e5 m\u00e5ste data duplikeras. Det h\u00e4r \u00e4r inte en uppgift som operat\u00f6ren l\u00f6ser. Och det \u00e4r inte en uppgift som Kubernetes l\u00f6ser. Det ligger p\u00e5 ClickHouse-niv\u00e5.<\/p>\n
<\/p>\n
Vad ska man g\u00f6ra om ni har en fysisk nod som har fallit bort? S\u00e5 det blir n\u00f6dv\u00e4ndigt att s\u00e4tta upp en ny, korrekt provisionera en disk p\u00e5 den, applicera labels. Och efter det kommer den att uppfylla kraven s\u00e5 att Kubernetes kan starta en instans av podden p\u00e5 den. Kubernetes kommer att starta den. Ni har ju inte tillr\u00e4ckligt med pods enligt det angivna antalet. Den kommer att g\u00e5 igenom cykeln som jag visade. Och p\u00e5 den \u00f6versta niv\u00e5n kommer ClickHouse att f\u00f6rst\u00e5 att en replika har kommit in, den \u00e4r fortfarande tom och vi m\u00e5ste b\u00f6rja \u00f6verf\u00f6ra data till den. D.v.s. den h\u00e4r processen \u00e4r fortfarande d\u00e5ligt automatiserad. <\/p>\n
<\/p>\n
Tack f\u00f6r presentationen! N\u00e4r det sker olika problem, faller operat\u00f6ren och startar om, och under den tiden kommer det in h\u00e4ndelser, hanterar ni detta p\u00e5 n\u00e5got s\u00e4tt?<\/em><\/p>\n<\/p>\n
Vad h\u00e4nder om operat\u00f6ren har fallit och startat om, eller hur? <\/p>\n
<\/p>\n
Ja. Och under den tiden kom h\u00e4ndelser.<\/em> <\/p>\n<\/p>\n
Uppgiften om vad man ska g\u00f6ra i det h\u00e4r fallet delas delvis mellan operat\u00f6ren och Kubernetes. Kubernetes har m\u00f6jlighet att \u00e5terspela den intr\u00e4ffade h\u00e4ndelsen. Den \u00e5terspelar. Och operat\u00f6rens uppgift \u00e4r att se till att n\u00e4r han f\u00e5r en replay av h\u00e4ndelselogg, s\u00e5 \u00e4r dessa h\u00e4ndelser idempotenta. S\u00e5 att en upprepning av samma h\u00e4ndelse inte bryter v\u00e5r system. Och v\u00e5r operat\u00f6r klarar av den uppgiften. <\/p>\n
<\/p>\n
Hej! Tack f\u00f6r presentationen! Dmitry Zavyalov, f\u00f6retaget<\/em> Smedova. Planeras det att l\u00e4gga till m\u00f6jlighet att konfigurera operat\u00f6ren med haproxy? Det skulle vara intressant med n\u00e5gon annan lastbalanserare \u00e4n den standardm\u00e4ssiga, som \u00e4r smart och f\u00f6rst\u00e5r att det verkligen handlar om ClickHouse.<\/em> <\/p>\n<\/p>\n
Pratar ni om Ingress?<\/p>\n
<\/p>\n
Ja, ers\u00e4tt Ingress med haproxy. I haproxy kan man ange klustrets topologi, d\u00e4r den har repliker.<\/em><\/p>\n<\/p>\n
Vi har \u00e4nnu inte t\u00e4nkt p\u00e5 det. Om ni beh\u00f6ver det och kan f\u00f6rklara varf\u00f6r det beh\u00f6vs, s\u00e5 kan det genomf\u00f6ras, speciellt om ni vill delta. Vi kommer g\u00e4rna att \u00f6verv\u00e4ga alternativet. Kort svar \u2013 nej, vi har f\u00f6r n\u00e4rvarande inte den funktionen. Tack f\u00f6r tipset, vi kommer att titta p\u00e5 det. Om ni ocks\u00e5 kan f\u00f6rklara use case och varf\u00f6r det beh\u00f6vs i praktiken, till exempel, om ni skapar issues p\u00e5 GitHub, s\u00e5 vore det fantastiskt.<\/p>\n
<\/p>\n
Det finns redan.<\/em><\/p>\n<\/p>\n
Bra. Vi \u00e4r \u00f6ppna f\u00f6r alla f\u00f6rslag. Och haproxy s\u00e4tts p\u00e5 to-do-listan. To-do-listan v\u00e4xer och minskar inte f\u00f6r tillf\u00e4llet. Men det \u00e4r bra, det betyder att produkten \u00e4r efterfr\u00e5gad.<\/p>\n
K\u00e4lla: 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
![\"Operat\u00f6r](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n