Operator di Kubernetes pikeun ngatur klaster database. Vladislav Klimenko (Altinity, 2019)

Laporan ieu dikhususkeun pikeun masalah praktis ngeunaan ngembangkeun operator di Kubernetes, ngarancang arsitéktur sareng prinsip dasar operasi.

Dina bagian mimiti laporan, urang bakal mertimbangkeun:

• naon operator di Kubernetes sareng naha éta diperyogikeun;
• kumaha kahayang operator simplifies manajemén sistem kompléks;
• naon operator bisa jeung naon operator teu bisa.

Salajengna, urang balikkeun ka sawala ngeunaan struktur internal operator. Mertimbangkeun arsitéktur sarta operasi operator step by step. Hayu urang analisa sacara rinci:

• interaksi antara operator jeung Kubernetes;
• naon fungsi operator nyandak on na naon delegasi ka Kubernetes.

Pertimbangkeun pikeun ngatur beling sareng réplika database di Kubernetes.
Salajengna, urang bakal ngabahas masalah panyimpen data:

• kumaha dianggo sareng Panyimpenan Persistent tina sudut pandang operator;
• pitfalls tina ngagunakeun Panyimpenan Lokal.

Dina bagian ahir laporan, urang bakal mertimbangkeun conto praktis tina aplikasi operator clickhouse sareng Amazon atanapi Google Cloud Service. Laporan ieu dumasar kana conto ngembangkeun sarta operasi pangalaman operator pikeun ClickHouse.

video:

Ngaran abdi Vladislav Klimenko. Dinten abdi hoyong ngobrol ngeunaan pangalaman urang dina ngembangkeun sarta operasi operator, sarta ieu téh operator husus pikeun ngatur klaster database. Salaku conto ClickHouse-operator pikeun ngatur klaster ClickHouse.

Naha urang boga kasempetan pikeun ngobrol ngeunaan operator na ClickHouse?

• Urang ngarojong sarta ngamekarkeun ClickHouse.
• Di momen, urang nyobian lalaunan nyieun kontribusi kami pikeun ngembangkeun ClickHouse. Sareng kami anu kadua saatos Yandex dina hal jumlah parobihan anu dilakukeun dina ClickHouse.
• Kami nyobian ngadamel proyék tambahan pikeun ékosistem ClickHouse.

Abdi hoyong ngobrol ngeunaan salah sahiji proyék ieu. Ieu ngeunaan ClickHouse-operator pikeun Kubernetes.

Dina laporan kuring, kuring hoyong nyabak dua topik:

• Topik anu munggaran nyaéta kumaha operator database ClickHouse kami jalanna di Kubernetes.
• Topik kadua nyaéta kumaha operator naon waé jalanna, nyaéta kumaha interaksina sareng Kubernetes.

Sanajan kitu, dua patarosan ieu bakal motong sapanjang laporan abdi.

Saha anu bakal resep ngadangu naon anu kuring badé nyarios?

• Anu paling pikaresepeun nyaéta jalma anu ngamangpaatkeun operator.
• Atawa pikeun maranéhanana anu rék nyieun sorangan dina urutan ngartos kumaha gawéna di jero, kumaha operator berinteraksi sareng Kubernetes, sarta naon pitfalls bisa muncul.

Pikeun ngartos naon anu bakal urang bahas ayeuna, langkung saé terang kumaha jalanna Kubernetes sareng gaduh latar dasar dina komputasi awan.

Naon ClickHouse? Ieu database kolom kalawan spésifik dina ngolah online queries analitik. Jeung éta sagemblengna open source.

Sareng urang ngan ukur kedah terang dua hal. Anjeun kedah terang yén ieu mangrupikeun pangkalan data, janten naon anu kuring bakal nyarioskeun ka anjeun bakal tiasa dianggo pikeun ampir sadaya databés. Jeung kanyataan yén skala ClickHouse DBMS kacida alusna méré scalability ampir linier. Ku kituna, kaayaan klaster mangrupakeun kaayaan alam pikeun ClickHouse. Sarta kami paling museurkeun ngabahas kumaha carana ngawula klaster ClickHouse di Kubernetes.

Naha anjeunna diperlukeun di dinya? Naha urang henteu tiasa terus ngoperasikeunana sorangan? Sareng jawaban sabagian téknis sareng sabagéan organisasi.

• Dina prakna, beuki sering urang sapatemon kaayaan kitu nalika di pausahaan badag ampir kabéh komponén geus aya dina Kubernetes. Tetep database di luar.
• Sareng beuki sering patarosan naroskeun: "Naha tiasa ditempatkeun di jero?". Ku alatan éta, pausahaan badag nyoba ngahasilkeun ngahijikeun Tatar maksimum dina urutan pikeun gancang bisa ngatur gudang data maranéhanana.
• Sareng ieu hususna ngabantosan upami anjeun peryogi kasempetan maksimal pikeun ngulang hal anu sami di tempat anu énggal, nyaéta, portabilitas maksimal.

Kumaha gampang atawa hésé éta? Ieu, tangtosna, tiasa dilakukeun ku leungeun. Tapi ieu teu jadi gampang, sabab urang nambahkeun up pajeulitna ngatur Kubernetes sorangan, tapi dina waktos anu sareng nu specifics of ClickHouse ditumpukeun. Jeung tétéla aggregation misalna hiji.

Sareng sadayana, ieu masihan set téknologi anu lumayan ageung, anu parantos janten sesah pikeun ngatur, sabab Kubernetes ngalaksanakeun masalah sapopoéna, sareng ClickHouse ngalaksanakeun masalahna pikeun operasi sapopoé. Utamana lamun urang boga sababaraha ClickHouses, sarta kami kudu terus ngalakukeun hiji hal sareng maranehna.

ClickHouse kalayan konfigurasi dinamis ngagaduhan sajumlah masalah anu cukup ageung anu nyiptakeun beban konstan dina DevOps:

• Nalika urang hoyong ngarobih hiji hal di ClickHouse, contona, tambahkeun réplika, beling, maka urang kedah ngatur konfigurasi.
• Lajeng ngarobah skéma data, sabab ClickHouse boga metoda sharding husus. Aya perlu iklas kaluar skéma data, iklas kaluar konfigurasi.
• Anjeun kedah nyetél monitoring.
• Kumpulan log pikeun shards anyar, pikeun réplika anyar.
• Jaga pamulihan.
• Jeung balikan deui.

Ieu mangrupikeun padamelan rutin anu kuring hoyong pisan ngagampangkeun dina operasi.

Kubernetes sorangan mantuan pisan dina operasi, tapi dina hal sistem dasar.

Kubernetes hébat dina ngagampangkeun sareng ngajadikeun otomatis hal sapertos:

• Pamulihan.
• Uihan deui.
• Manajemén gudang.

Éta alus, éta arah katuhu, tapi anjeunna sagemblengna kaluar tina kabaran ku cara beroperasi klaster database.

Abdi hoyong langkung, Abdi hoyong sakabéh database dianggo pikeun urang di Kubernetes.

Abdi hoyong kéngingkeun sapertos tombol beureum anu ageung anu anjeun pencét sareng anjeun gaduh klaster anu dipasang sareng dijaga sapanjang siklus kahirupan kalayan tugas-tugas sapopoé anu kedah direngsekeun. Kluster ClickHouse di Kubernetes.

Sareng urang nyobian ngadamel solusi anu bakal ngabantosan padamelan. Ieu ClickHouse-operator pikeun Kubernetes ti Altinity.

Operator mangrupikeun program anu tugas utami nyaéta ngatur program anu sanés, nyaéta manajer.

Sarta eta ngandung pola kabiasaan. Anjeun tiasa nyauran éta pangaweruh anu dikodifikasi ngeunaan daérah subjek.

Sareng tugas utami nyaéta ngagampangkeun kahirupan pikeun DevOps sareng ngirangan micromanagement supados anjeunna (DevOps) parantos mikir dina istilah tingkat tinggi, nyaéta, supados anjeunna (DevOps) henteu ngatur mikro, ku kituna anjeunna henteu ngonpigurasikeun sadayana sacara manual. rinci.

Sareng operator mangrupikeun asistén robot anu bajoang sareng microtasks sareng ngabantosan DevOps.

Naha operator diperlukeun? Anjeunna unggul dina dua widang:

• Nalika spesialis ClickHouse teu boga cukup pangalaman, tapi geus diperlukeun pikeun beroperasi ClickHouse, operator facilitates operasi sarta ngidinan Anjeun pikeun beroperasi klaster ClickHouse kalawan konfigurasi rada kompléks, bari teu balik kana teuing jéntré ngeunaan kumaha eta sadayana jalan di jero. . Anjeun ngan masihan anjeunna tugas-tingkat tinggi, sarta gawéna.
• Sareng tugas kadua dimana éta nunjukkeun diri anu paling saé nyaéta nalika anjeun kedah ngajadikeun otomatis sajumlah ageung tugas khas. Ngahapus microtasks tina sysadmins.

Ieu paling dibutuhkeun boh ku anu nembé ngamimitian perjalanan, atanapi ku anu kedah ngalakukeun seueur otomatisasi.

Naon bedana pendekatan dumasar operator sareng sistem anu sanés? Aya ogé Helm. Éta ogé ngabantosan masang ClickHouse, anjeun tiasa ngagambar grafik Helm, anu malah bakal masang klaster ClickHouse sadayana. Naon lajeng nya éta selisih operator jeung ti sarua, Contona, Helm?

Beda fundamental utama éta Helm téh sadayana ngeunaan manajemen pakét, sarta operator mana undak salajengna. Ieu ngarojong sakabéh siklus kahirupan. Ieu sanés ngan ukur pamasangan, ieu mangrupikeun tugas sapopoe anu kalebet skala, sharding, nyaéta sadayana anu kedah dilakukeun salami siklus kahirupan (upami perlu, panyabutan ogé) - ieu sadayana diputuskeun ku operator. Ieu nyoba ngajadikeun otomatis tur ngalayanan sakabéh siklus hirup software. Ieu mangrupikeun bédana dasarna tina solusi anu sanés anu disayogikeun.

Éta bagian bubuka, hayu urang ngaléngkah.

Kumaha urang ngawangun operator urang? Kami nyobian ngadeukeutan masalah pikeun ngatur klaster ClickHouse salaku sumber tunggal.

Di dieu urang boga data input di sisi kénca gambar. Ieu YAML kalayan spésifikasi klaster, anu sacara klasik dialirkeun kubectl ka Kubernetes. Aya, operator urang nyokot eta up, ngalakukeun magic na. Sareng hasilna, urang nampi skéma sapertos kitu. Ieu mangrupikeun palaksanaan ClickHouse di Kubernetes.

Lajeng urang lalaunan bakal kasampak di kumaha operator jalan, naon tugas has bisa direngsekeun. Urang bakal mertimbangkeun ngan tugas has, sabab urang boga waktu kawates. Sarta eta moal ngabejaan ngeunaan sagalana yén operator bisa mutuskeun.

Hayu urang mimitian ti latihan. Proyék kami lengkep open source, ku kituna anjeun tiasa ningali kumaha jalanna dina GitHub. Jeung anjeun bisa neruskeun ti tinimbangan, lamun ngan hayang ngamimitian, mangka anjeun bisa mimitian ku Guide Gancang Mimitian.

Upami anjeun hoyong ngartos sacara rinci, maka urang nyobian ngajaga dokuméntasi dina bentuk anu langkung atanapi kirang santun.

Hayu urang mimitian ku masalah praktis. Tugas munggaran urang sadayana hoyong ngamimitian nyaéta ngajalankeun conto munggaran kumaha bae. Kumaha ngajalankeun ClickHouse kalayan bantosan operator, tanpa terang kumaha jalanna? Kami nulis manifesto, sabab kabéh komunikasi jeung k8s nyaéta komunikasi ngaliwatan manifests.

Ieu mangrupikeun manifesto anu kompleks. Naon anu urang disorot beureum nyaéta naon anu urang kedah difokuskeun. Kami naroskeun ka operator pikeun nyiptakeun klaster anu namina demo.

Pikeun ayeuna mah, ieu conto dasar. Panyimpenan henteu acan dijelaskeun, tapi urang bakal uih deui ka panyimpenan sakedik engké. Pikeun ayeuna, urang bakal niténan ngembangkeun klaster dina dinamika.

Kami parantos nyiptakeun manifesto ieu. Urang eupan ka operator urang. Anjeunna damel, anjeunna ngalakukeun sihir.

Urang kasampak di konsol. Tilu komponén anu dipikaresep - ieu Pod, dua Service-a, StatefulSet.

Operator parantos damel, sareng urang tiasa ningali naon anu diciptakeunana.

Anjeunna nyiptakeun hal sapertos kieu. Simkuring boga StatefulSet, pod, ConfigMap pikeun tiap replica, ConfigMap pikeun sakabéh klaster. Sapertos jasa salaku titik éntri kana kluster.

Jasa nyaéta Service Load Balancer sentral jeung kasebut nyaéta dimungkinkeun pikeun tiap replica, pikeun tiap beling.

Ieu mangrupikeun klaster dasar urang sapertos kieu. Anjeunna ti hiji titik tunggal.

Hayu urang leuwih jauh, urang bakal ngahesekeun. Anjeun kudu beling kluster.

Tugas urang ngembang, dinamika dimimitian. Simkuring hoyong nambahkeun beling a. Urang nuturkeun perkembangannya. Urang ngarobah spésifikasi urang. Urang nunjukkeun yén urang hoyong dua shards.

Ieu mangrupikeun file anu sami anu urang kembangkeun sacara dinamis sareng kamekaran sistem. Henteu aya panyimpen, panyimpen bakal dibahas deui, ieu mangrupikeun masalah anu misah.

Urang eupan operator YAML tur tingal kumaha kajadian.

Operator panginten sareng ngadamel éntitas di handap ieu. Kami parantos gaduh dua Pods, tilu Services sareng, ujug-ujug, 2 StatefulSets. Naha 2 StatefulSets?

Éta sapertos dina diagram - ieu mangrupikeun kaayaan awal urang, nalika urang ngagaduhan hiji pod.

Janten sapertos kieu. Sajauh ieu, sagalana geus basajan, éta geus duplikat.

Sareng naha StatefulSet janten dua? Di dieu urang kedah nyimpang sareng ngabahas patarosan kumaha Pods diurus di Kubernetes.

Aya obyék sapertos anu disebut StatefulSet, anu ngamungkinkeun anjeun ngadamel set Pods tina citakan. Faktor konci di dieu nyaéta Citakan. Sareng anjeun tiasa ngajalankeun seueur Pod dina hiji StatefulSet dumasar kana hiji template. Jeung frase konci didieu nyaeta "hiji template loba pods".

Sareng aya godaan anu saé pikeun ngadamel sadayana klaster, ngarangkep kana hiji StatefulSet. Éta bakal tiasa dianggo, teu aya masalah dina éta. Tapi aya hiji caveat. Upami urang hoyong ngumpul klaster hétérogén, nyaéta tina sababaraha versi ClickHouse, teras patarosan urang dimimitian. Sumuhun, StatefulSet tiasa ngalakukeun update rolling, tapi aya anjeun bisa gulung kaluar versi anyar, ngajelaskeun yén anjeun kedah nyobian euweuh leuwih ti kitu loba titik dina waktos anu sareng.

Tapi lamun urang extrapolate tugas jeung nyebutkeun yen urang hayang nyieun klaster lengkep hétérogén jeung teu hayang ngarobah tina versi heubeul ka nu anyar ngagunakeun update rolling, tapi ngan saukur hayang nyieun klaster hétérogén boh dina watesan versi béda. tina ClickHouse sarta dina watesan gudang béda. Simkuring hoyong, contona, nyieun sababaraha réplika dina disk misah, dina slows, sacara umum, pikeun sakabéhna ngawangun hiji klaster hétérogén. Sareng kusabab kanyataan yén StatefulSet ngadamel solusi standar tina hiji template, janten teu aya deui jalan pikeun ngalakukeun ieu.

Saatos sababaraha pamikiran, éta mutuskeun yén urang ngalakukeun sapertos kieu. Simkuring gaduh unggal replica di StatefulSet sorangan. Aya sababaraha kalemahan pikeun solusi ieu, tapi dina prakna éta sadayana lengkep encapsulates operator. Jeung aya loba mangpaat. Urang tiasa ngawangun klaster anu lengkep sapertos anu dipikahoyong, contona, anu hétérogén pisan. Ku alatan éta, dina klaster nu urang boga dua shards kalawan hiji réplika, urang bakal boga 2 StatefulSets na 2 pods persis sabab urang milih pendekatan ieu alatan alesan di luhur pikeun kamampuhan pikeun ngawangun klaster hétérogén.

Hayu urang balik deui ka tugas praktis. Dina klaster urang, urang kudu ngonpigurasikeun pamaké, i.e. Anjeun kedah ngalakukeun sababaraha konfigurasi ClickHouse di Kubernetes. Operator nyadiakeun sagala kemungkinan pikeun ieu.

Urang tiasa nyerat naon anu dipikahoyong langsung di YAML. Sadaya pilihan konfigurasi langsung dipetakeun tina YAML ieu kana konfigurasi ClickHouse, anu teras disebarkeun sapanjang kluster.

Anjeun ogé tiasa nyerat sapertos kieu. Ieu kanggo conto. Sandi tiasa énkripsi. Leres pisan sadaya pilihan konfigurasi ClickHouse dirojong. Ieu ngan conto.

Konfigurasi klaster disebarkeun salaku ConfigMap. Dina prakna, update ConfigMap henteu lumangsung langsung, jadi lamun aya klaster badag, prosés nyorong konfigurasi butuh sababaraha waktu. Tapi kabeh ieu pisan merenah ngagunakeun.

Urang ngahesekeun tugas. Kluster ngembang. Urang rék ngayakeun réplikasi data. Hartina, urang geus boga dua beling, hiji replica unggal, pamaké nu ngonpigurasi. Urang tumuwuh sarta hayang ngayakeun réplikasi.

Naon anu urang peryogikeun pikeun réplikasi?

Urang peryogi ZooKeeper. Dina ClickHouse, réplikasi diwangun nganggo ZooKeeper. ZooKeeper diperlukeun ku kituna réplika ClickHouse béda boga konsensus on mana blok data aya dina ClickHouse.

ZooKeeper tiasa dianggo ku saha waé. Upami perusahaan gaduh ZooKeeper éksternal, éta tiasa dianggo. Upami henteu, maka anjeun tiasa pasang tina gudang kami. Aya hiji installer nu ngajadikeun sakabeh hal ieu gampang.

Sareng skéma interaksi sadaya sistem tétéla sapertos kieu. Kami ngagaduhan Kubernetes salaku platform. Ieu executes operator ClickHouse. ZooKeeper I gambar di dieu. Sareng operator berinteraksi sareng ClickHouse sareng ZooKeeper. Hartina, hiji interaksi diala.

Sarta sakabeh ieu diperlukeun pikeun ClickHouse hasil ngayakeun réplikasi data ka k8s.

Hayu urang ayeuna nempo tugas sorangan, kumaha manifest pikeun réplikasi bakal kasampak kawas.

Urang tambahkeun dua bagian kana manifest urang. Anu kahiji nyaéta dimana kéngingkeun ZooKeeper, anu tiasa di jero Kubernetes atanapi éksternal. Ieu ngan pedaran. Sarta kami mesen réplika. Jelema. urang hoyong dua réplika. Dina total, urang kudu boga 4 pods dina kaluaran. Urang émut ngeunaan neundeun, éta bakal uih deui sakedik. Panyimpenan mangrupakeun lagu misah.

Ieu kawas kieu.

Janten sapertos kieu. Réplika ditambahkeun. The 4 teu cocog, kami yakin yén meureun aya loba di antarana. Sarta ZooKeeper ditambahkeun di sisi. Pola beuki kompleks.

Sareng waktosna pikeun nambihan tugas salajengna. Urang bakal nambahan Panyimpenan Persistent.

Pikeun Panyimpenan Persistent, urang gaduh sababaraha pilihan.

Upami urang ngajalankeun dina panyadia awan, contona, nganggo Amazon, Google, maka aya godaan anu hadé pikeun ngagunakeun panyimpenan awan. Merenah pisan, sae.

Sareng aya pilihan kadua. Ieu kanggo panyimpenan lokal, nalika urang gaduh disk lokal dina unggal titik. Pilihan ieu langkung hese pikeun dilaksanakeun, tapi dina waktos anu sami langkung produktif.

Hayu urang tingali naon anu urang gaduh ngeunaan panyimpenan awan.

Aya kaunggulan. Ieu pisan gampang pikeun ngonpigurasikeun. Kami ngan saukur mesen ti panyadia awan anu punten pasihan kami neundeun kapasitas sapertos kitu, kelas sapertos kitu. Kelas dicét ku panyadia sacara mandiri.

Sareng aya kalemahan. Kanggo sababaraha, ieu mangrupikeun kakurangan anu teu kritis. Tangtosna, bakal aya sababaraha overlay kinerja. Hal ieu kacida merenah ngagunakeun, dipercaya, tapi aya sababaraha drawdowns poténsial dina kinerja.

Sarta saprak ClickHouse museurkeun kana kinerja, anjeun malah bisa disebutkeun yen eta squeezes kaluar sagalana mungkin, jadi loba klien nyoba squeeze kaluar kinerja maksimum.

Sarta pikeun meunangkeun mangpaat pangseueurna ti eta, urang peryogi gudang lokal.

Kubernetes nyadiakeun tilu abstraksi pikeun pamakéan gudang lokal di Kubernetes. Ieu:

• EmptyDir
• HostPath.
• lokal

Pertimbangkeun kumaha aranjeunna béda, kumaha aranjeunna sami.

Firstly, dina sagala tilu pendekatan, urang boga gudang - ieu disk lokal anu lokasina dina titik k8s fisik sarua. Tapi aranjeunna gaduh sababaraha béda.

Hayu urang mimitian ku pangbasajanna, nyaéta kosongDir. Naon eta dina prakna? Kami anu naroskeun sistem containerization (sering Docker) tina spésifikasi kami pikeun nyayogikeun aksés kana polder dina disk lokal.

Dina prakna, docker nyiptakeun folder samentawis dimana waé dina jalurna sorangan, nyebatna hash panjang. Sareng nyayogikeun antarmuka pikeun ngaksés éta.

Kumaha eta bakal ngalakukeun dina watesan kinerja? Ieu bakal ngajalankeun dina laju disk lokal, i.e. ieu aksés pinuh ka screw Anjeun.

Tapi kasus ieu boga aral na. Pengkuh dina hal ieu rada dubious. Dina gerakan mimiti docker kalawan peti, Persistent leungit. Upami Kubernetes hoyong mindahkeun Pod ieu ka disk anu sanés kusabab sababaraha alesan, maka datana bakal leungit.

pendekatan Ieu alus keur tés, sabab geus nembongkeun speed normal, tapi pilihan ieu teu cocog pikeun hal serius.

Ku alatan éta, aya pendekatan kadua. Ieu hostPath. Upami anjeun ningali slide sateuacana sareng ieu, anjeun ngan ukur tiasa ningali hiji bédana. Polder kami ninggalkeun docker langsung ka titik Kubernetes. Ieu rada gancang di dieu. Urang langsung nyerat jalur dina sistem file lokal dimana urang hoyong nyimpen data urang.

Metoda ieu boga kaunggulan. Ieu parantos Persistent nyata, sareng klasik. Dina disk urang, data bakal ditulis ka sababaraha alamat.

Aya ogé kalemahan. Ieu pajeulitna manajemén. Kubernetes urang meureun hoyong mindahkeun Pod ka titik fisik sejen. Ieu dimana DevOps asalna kana antrian. Éta kedah leres-leres ngajelaskeun ka sadaya sistem yén anjeun ngan ukur tiasa ngalihkeun pods ieu kana titik dimana anjeun gaduh hiji hal dipasang sapanjang jalur ieu, sareng henteu langkung ti hiji titik dina hiji waktos. Ieu cukup hésé.

Khususna pikeun tujuan ieu, kami parantos ngadamel témplat dina operator kami pikeun nyumputkeun pajeulitna ieu. Sareng anjeun ngan ukur tiasa nyarios: "Kuring hoyong gaduh hiji conto ClickHouse per titik fisik sareng sapanjang jalur sapertos kitu."

Tapi kabutuhan ieu henteu ngan keur urang, jadi gentlemen ti Kubernetes sorangan ogé ngarti yén jalma hayang boga aksés ka disk fisik, ngarah nyadiakeun tingkat katilu.

Disebutna lokal. Aya praktis euweuh bédana ti slide saméméhna. Ngan samemehna urang kedah ngalaksanakeun kalawan leungeun kami yén urang teu bisa mindahkeun pods ieu ti titik ka titik, sabab kudu napel sapanjang jalur ieu jeung kitu ka disk fisik lokal, sarta ayeuna sakabeh pangaweruh ieu encapsulated dina Kubernetes sorangan. Jeung tétéla loba gampang pikeun ngonpigurasikeun.

Hayu urang balik deui ka tugas praktis urang. Hayu urang balik deui ka template YAML. Di dieu urang boga gudang nyata. Urang balik deui ka ieu. Kami nyetél template VolumeClaim klasik sapertos dina k8s. Sarta kami ngajelaskeun jenis gudang urang hoyong.

Sanggeus éta, k8s bakal menta gudang. Alokasikeun ka kami di StatefulSet. Sarta dina tungtungna, éta bakal ngahurungkeun kaluar dina pembuangan ClickHouse.

Kami ngagaduhan skéma sapertos kitu. Panyimpen Persistent kami beureum, anu sigana nunjukkeun yén éta kedah dilakukeun.

Sareng janten héjo. Ayeuna ClickHouse on k8s skéma klaster geus pinuh finalized. Kami gaduh beling, réplika, ZooKeeper, kami gaduh Persistent nyata, anu dilaksanakeun dina hiji cara atanapi anu sanés. Skéma éta parantos beroperasi sacara lengkep.

Urang terus hirup. klaster urang tumuwuh. Sareng Aleksey nyobian sareng ngaleupaskeun versi anyar ClickHouse.

Hiji tugas praktis timbul - pikeun nguji versi anyar tina ClickHouse on klaster urang. Na, tangtosna, abdi teu hoyong gulung eta sadayana kaluar, Abdi hoyong nempatkeun versi anyar wae di pojok tebih dina hiji replica, atawa meureun moal hiji versi anyar, tapi dua sakaligus, sabab mindeng kaluar.

Naon anu urang tiasa nyarios ngeunaan ieu?

Di dieu urang gaduh kasempetan sapertos kitu. Ieu témplat pod. Anjeun tiasa cet, operator kami sagemblengna ngidinan Anjeun pikeun ngawangun klaster hétérogén. Jelema. ngonpigurasikeun, mimitian ti sagala réplika dina kebat, ditungtungan make unggal replica pribadi, nu versi urang hoyong ClickHouse, nu versi urang rék neundeun. Urang pinuh tiasa ngonpigurasikeun klaster dina konfigurasi sapertos anu urang peryogikeun.

Hayu urang lebet langkung jero. Sateuacan éta, urang ngobrol ngeunaan kumaha ClickHouse-operator jalan dina hubungan jeung specifics of ClickHouse.

Ayeuna Abdi hoyong nyebutkeun sababaraha kecap ngeunaan kumaha operator sagala jalan sacara umum, kitu ogé kumaha interaksi jeung K8s.

Mertimbangkeun interaksi jeung K8s dimimitian ku. Naon anu lumangsung nalika urang nerapkeun kubectl? Ngaliwatan API, objék urang muncul dina etcd.

Contona, objék dasar Kubernetes: pod, StatefulSet, service, jeung saterusna ngaliwatan daptar.

Sanajan kitu, euweuh fisik anu lumangsung acan. objék ieu kudu materialized dina klaster.

Ieu dimana controller asalna di. Controller mangrupakeun komponén k8s husus nu bisa materialize déskripsi ieu. Anjeunna terang kumaha sareng naon anu kedah dilakukeun sacara fisik. Anjeunna terang kumaha ngajalankeun peti, naon anu kedah dikonpigurasikeun di dinya supados server tiasa dianggo.

Sarta eta materializes objék kami di K8s.

Tapi urang rék beroperasi teu ukur mibanda pods, StatefulSets, urang rék nyieun hiji ClickHouseInstallation, nyaeta, hiji objek tipe ClickHouse, guna beroperasi kalawan eta sakabéhna. Sajauh ieu, teu aya kamungkinan sapertos kitu.

Tapi K8s boga hal nice sejen. Kami hoyong urang gaduh éntitas kompleks sapertos dimana waé, dimana klaster urang bakal dirakit tina pods sareng StatefulSet.

Sareng naon anu kedah dilakukeun pikeun ieu? Kahiji, Harti Sumberdaya Adat asup kana adegan. Naon éta? Ieu pedaran pikeun K8s nu bakal boga tipe data sejen nu urang hoyong tambahkeun kana pod, StatefulSet, sumberdaya custom nu bakal kompléks jero. Ieu pedaran ngeunaan struktur data.

Urang ogé ngirim ka dinya via kubectl nerapkeun. Kubernetes happily nyandak eta.

Tur ayeuna di gudang urang, obyék di etcd boga kasempetan pikeun nulis sumberdaya custom disebut ClickHouseInstallation.

Tapi pikeun ayeuna, euweuh nu sejenna bakal kajadian. Nyaéta, upami urang ayeuna nyiptakeun file YAML anu kami anggap kalayan pedaran beling, réplika sareng ucapkeun "kubectl nerapkeun", maka Kubernetes bakal nampi, nempatkeun kana jsb sareng ucapkeun: "Hebat, tapi kuring henteu terang. naon anu kudu dipigawé kalayan eta. Kuring henteu weruh kumaha carana ngajaga ClickHouseInstallation."

Sasuai, urang butuh batur pikeun mantuan Kubernetes ngalayanan tipe data anyar. Di kénca, kami gaduh pangendali saham Kubernetes anu tiasa dianggo sareng jinis data saham. Sareng di sisi katuhu, urang kedah gaduh pangontrol khusus anu tiasa dianggo sareng jinis data khusus.

Sarta dina cara séjén disebut operator. Kuring husus nyandak kaluar dieu pikeun Kubernetes, sabab ogé bisa dieksekusi di luar K8s. Seringna, tangtosna, sadaya pernyataan dieksekusi dina Kubernetes, tapi teu aya anu ngahalangan nangtung di luar, janten di dieu khususna dibawa kaluar.

Sareng parantos, péngkolan, pengontrol khusus, ogé katelah operator, berinteraksi sareng Kubernetes ngalangkungan API. Anjeunna parantos terang kumaha berinteraksi sareng API. Sareng anjeunna parantos terang kumaha ngawujudkeun skéma kompleks anu urang hoyong jieun tina sumber daya khusus. Ieu persis naon operator teu.

Kumaha operator dianggo? Hayu urang tingali di sisi katuhu pikeun ningali kumaha anjeunna ngalakukeunana. Urang bakal manggihan kumaha operator materializes sadayana ieu sareng kumaha interaksi salajengna kalawan K8s lumangsung.

Operator nyaéta program. Anjeunna berorientasi acara. Operator ngalanggan acara nganggo API Kubernetes. API Kubernetes ngagaduhan titik éntri dimana anjeun tiasa ngalanggan acara. Sareng upami aya anu robih dina K8, teras Kubernetes ngirim acara ka sadayana, nyaéta. anu ngalanggan titik API ieu bakal nampi bewara.

Operator ngalanggan acara, sareng kedah ngalakukeun sababaraha réaksi. Tugasna nyaéta pikeun ngaréspon kana kajadian anu muncul.

Kajadian dihasilkeun ku sababaraha apdet. Berkas YAML kami sumping sareng pedaran ngeunaan ClickHouseInstallation. Manéhna indit ka etcd via kubectl nerapkeun. Hiji acara digawé aya, salaku hasilna, acara ieu sumping ka ClickHouse-operator. Operator nampi pedaran ieu. Sareng anjeunna kedah ngalakukeun hiji hal. Upami apdet sumping ka obyék ClickHouseInstallation, maka anjeun kedah ngapdet kluster. Sareng tugas operator nyaéta ngapdet klaster.

Naon anu anjeunna lakukeun? Mimiti, urang kedah ngadamel rencana aksi pikeun naon anu bakal urang laksanakeun sareng pembaruan ieu. Apdet tiasa pisan leutik, nyaéta. leutik dina palaksanaan YAML, tapi bisa ngakibatkeun parobahan anu kacida gedéna dina klaster. Ku alatan éta, operator nyieun rencana, lajeng anjeunna taat kana eta.

Anjeunna dimimitian, nurutkeun rencana ieu, kulub struktur ieu di jero guna materialize pods, jasa, i.e. pikeun ngalakukeun naon tugas utama na. Éta sapertos ngawangun klaster ClickHouse di Kubernetes.

Ayeuna hayu urang nyabak hiji hal metot. Ieu mangrupikeun pembagian tanggung jawab antara Kubernetes sareng operator, nyaéta. naon anu dilakukeun ku Kubernetes, naon anu dilakukeun ku operator, sareng kumaha aranjeunna berinteraksi.

Kubernetes tanggung jawab pikeun hal sistem, i.e. pikeun set dasar objék nu bisa diinterpretasi salaku sistem-wengkuan. Kubernetes terang kumaha ngamimitian pods, kumaha ngabalikan deui wadahna, kumaha ngalakukeun volume mount, kumaha damel sareng ConfigMap, i.e. naon bae anu bisa disebut sistem.

Operator beroperasi di wewengkon subjék. Unggal operator dijieun pikeun wewengkon subjek na. Urang dijieun pikeun ClickHouse.

Sareng operator berinteraksi persis dina hal daérah subjek, sapertos nambihan réplika, ngadamel skéma, nyetél ngawaskeun. Aya pamisah sapertos kitu.

Hayu urang tingali conto praktis kumaha pamisahan masalah ieu lumangsung nalika urang ngalakukeun tindakan réplika.

tugas datang ka operator - pikeun nambahkeun replica a. Naon anu operator lakukeun? Operator bakal ngitung yén éta téh perlu nyieun StatefulSet anyar, nu perlu ngajelaskeun template sapertos na, klaim volume.

Anjeunna nyiapkeun sadayana sareng masihan kana K8s. Anjeunna nyarios yén anjeunna peryogi ConfigMap, StatefulSet, Jilid. Kubernetes berpungsi. Anjeunna materializes unit dasar kalayan mana anjeunna beroperasi.

Lajeng ClickHouse-operator asalna kana maén deui. Anjeunna parantos gaduh pod fisik dimana anjeun parantos tiasa ngalakukeun hiji hal. Jeung ClickHouse-operator deui jalan dina watesan wewengkon subjek. Jelema. Husus, ClickHouse, dina urutan ngawengku replica dina klaster, Anjeun kudu, firstly, ngonpigurasikeun skéma data nu aya dina klaster ieu. Jeung, kadua, ucapan ieu kudu diasupkeun kana monitoring sangkan bisa dilacak jelas. Operator parantos nyetél éta.

Sarta ngan sanggeus éta ClickHouse sorangan asalna kana antrian, i.e. éntitas tingkat luhur sejen. Ieu geus database a. Cai mibanda conto sorangan, replica ngonpigurasi salajengna, nu siap gabung kluster.

Tétéla ranté palaksanaan na separation tanggung jawab nalika nambahkeun réplika cukup panjang.

Urang neruskeun tugas praktis urang. Upami kluster parantos aya, anjeun tiasa migrasi konfigurasi.

Urang dijieun sangkan nu kasebut nyaéta dimungkinkeun pikeun nembus kana xml aya, nu ClickHouse understands.

Anjeun tiasa fine-Ngepaskeun ClickHouse. Ngan panyebaran zona nyaéta anu kuring nyarioskeun nalika ngajelaskeun hostPath, panyimpenan lokal. Ieu kumaha cara ngalakukeun penyebaran zona kalayan leres.

Tugas praktis salajengna nyaéta ngawaskeun.

Upami klaster urang robih, maka urang kedah périodik ngonpigurasikeun monitoring.

Hayu urang nempo diagram. Kami parantos nganggap panah héjo di dieu. Ayeuna hayu urang nempo panah beureum. Ieu kumaha urang hoyong ngawas kluster urang. Kumaha métrik tina klaster ClickHouse asup kana Prometheus, teras kana Grafana.

Naon masalahna ngawaskeun? Naha ieu dibere salaku sababaraha jenis prestasi? Kasusahna aya dina dinamika. Nalika kami gaduh hiji klaster sareng statik, anjeun tiasa nyetél ngawaskeun sakali sareng henteu ngaganggu deui.

Tapi lamun urang boga loba klaster, atawa hal anu terus ngarobah, lajeng prosés téh dinamis. Sarta terus reconfiguring ngawaskeun mangrupakeun runtah sumberdaya jeung waktu; malah ngan puguh. Ieu perlu otomatis. Kasusahna aya dina dinamika prosés. Jeung operator ngajadikeun otomatis ieu kacida alusna.

Kumaha klaster urang berkembang? Dina awalna anjeunna sapertos kieu.

Teras anjeunna sapertos kieu.

Tungtungna, anjeunna janten sapertos kieu.

Sareng ngawaskeun sacara otomatis dilakukeun ku operator. Hiji titik asupna.

Sareng urang ngan ukur ningali jalan kaluar dina dasbor Grafana, kumaha kahirupan kluster urang di jero.

Ku jalan kitu, dasbor Grafana ogé disebarkeun sareng operator kami langsung dina kode sumber. Anjeun tiasa nyambungkeun sareng nganggo. Potret layar ieu dipasihkeun ka kuring ku DevOps kami.

Dimana urang badé angkat salajengna? Ieu:

• Ngembangkeun automation test. Tugas utama nyaéta nguji otomatis tina versi anyar.
• Kami ogé hoyong ngajadikeun otomatis integrasi sareng ZooKeeper. Jeung rencana pikeun ngahijikeun kalawan ZooKeeper-operator. Jelema. hiji operator geus ditulis pikeun ZooKeeper, tur éta logis yén dua operator ngawitan ngahijikeun ngawangun solusi leuwih merenah.
• Urang rék ngalakukeun cék hirup leuwih kompleks.
• Kuring disorot dina héjo nu urang boga warisan Citakan dina jalan - rengse, i.e.. jeung release saterusna operator, urang bakal geus boga warisan template. Ieu mangrupikeun alat anu kuat anu ngamungkinkeun anjeun ngawangun konfigurasi kompléks tina potongan.
• Sarta kami rék ngajadikeun otomatis tugas kompléks. Anu utama nyaéta Re-sharding.

Hayu urang ngalakukeun sababaraha hasil panengah.

Naon anu urang meunang salaku hasilna? Sareng naha éta patut atanapi henteu? Naha kuring kedah nyobian nyered pangkalan data kana Kubernetes sareng nerapkeun operator sacara umum sareng operator Alitnity khususna.

Dina output urang meunang:

• Nyederhanakeun sacara dramatis sareng ngajadikeun otomatis konfigurasi, panyebaran, sareng pangropéa.
• Langsung diwangun-di ngawaskeun.
• Sareng témplat anu dikodifikasi anu siap dianggo pikeun kaayaan anu rumit. Geus Peta sahiji jenis pikeun nambahkeun réplika teu perlu dipigawé ku leungeun. Hal ieu dilakukeun ku operator.

Ngan sual panungtungan tetep. Urang geus boga database di Kubernetes, virtualization. Kumaha upami kinerja solusi sapertos kitu, khususna saprak ClickHouse dioptimalkeun pikeun pagelaran?

Dina jawaban eta sagalana geus rupa! Kuring moal ngajelaskeun di jéntré, ieu topik laporan misah.

Tapi aya proyék sapertos TSBS. Naon tugas utama na? Ieu tés kinerja database. Ieu usaha pikeun ngabandingkeun haneut jeung haneut, lemes jeung lemes.

Kumaha anjeunna dianggo? Hiji set data dihasilkeun. Lajeng set data ieu dina set test sarua dijalankeun dina database béda. Sarta unggal database solves hiji masalah cara eta tiasa. Teras anjeun tiasa ngabandingkeun hasilna.

Éta parantos ngadukung seueur pangkalan data. Kuring geus ngaidentifikasi tilu leuwih utama. Ieu:

• skala waktub.
• InfluxDB.
• clickhouse.

Perbandingan ogé dilakukeun sareng solusi anu sami. Babandingan jeung RedShift. Perbandingan ieu dilakukeun dina Amazon. ClickHouse ogé payuneun sadayana dina masalah ieu.

Kacindekan naon anu tiasa ditarik tina naon anu kuring nyarios?

• DB di Kubernetes mungkin. Panginten, anjeun tiasa ngalakukeun nanaon, tapi sacara umum sigana anjeun tiasa. ClickHouse di Kubernetes pasti mungkin kalayan bantosan operator kami.
• Operator mantuan pikeun ngajadikeun otomatis prosés jeung bener simplifies hirup.
• Kinerja normal.
• Sareng, sigana urang tiasa sareng kedah dianggo.

Open source - gabung kami!

Salaku Cenah mah, operator mangrupa produk lengkep open source, jadi bakal jadi pohara alus lamun jumlah maksimum jalma dipaké. Gabung ayeuna! Kami ngantosan anjeun sadayana!

Hatur nuhun ka sadayana!

patarosan

Hatur nuhun laporan! Nami abdi Anton. Abdi ti SEMrush. Kuring heran naon anu aya dina logging. Urang ngadangu ngeunaan monitoring, tapi euweuh ngeunaan logging, lamun urang ngobrol ngeunaan sakabeh klaster. Contona, urang boga klaster on hardware. Sareng kami nganggo logging terpusat, kami kumpulkeun dina tumpukan umum ku cara standar. Lajeng ti dinya urang meunang data anu metot pikeun urang.

Patarosan anu saé, nyaéta asup kana daptar tugas. Operator kami henteu acan ngajadikeun otomatis ieu. Ieu masih ngembang, proyék masih rada ngora. Urang ngarti kabutuhan logging. Ieu ogé topik anu penting pisan. Sarta eta meureun teu kurang pentingna ti ngawaskeun. Tapi mimitina dina daptar pikeun palaksanaan éta ngawaskeun. Bakal aya logging. Alami, urang nyobian ngajadikeun otomatis sagala aspek kahirupan klaster. Ku alatan éta, jawaban nu di momen operator, hanjakalna, teu nyaho kumaha carana ngalakukeun ieu, tapi aya dina rencana, urang bakal ngalakukeun eta. Upami anjeun hoyong gabung, teras tarik pamundut, mangga.

Halo! Hatur nuhun laporan! Kuring boga patarosan baku patali Jilid pengkuh. Nalika urang nyieun konfigurasi kalawan operator ieu, kumaha operator nangtukeun on nu titik urang boga sababaraha disk atawa folder? Urang kedah ngajelaskeun heula ka anjeunna yén, punten, nempatkeun ClickHouse kami persis dina titik ieu anu gaduh disk?

Sajauh I ngartos, patarosan ieu mangrupa tuluyan tina gudang lokal, utamana bagian hostPath eta. Éta sapertos ngajelaskeun ka sadayana sistem yén pod kedah diluncurkeun persis dina titik sapertos kitu, dimana urang gaduh disk anu nyambungkeun fisik, anu dipasang dina jalur sapertos kitu. Ieu sakabeh bagian anu kuring keuna pisan deet, sabab jawaban aya rada badag.

Sakeudeung, sigana kieu. Tangtosna, urang kedah nyayogikeun jilid-jilid ieu. Ayeuna, teu aya panyediaan dinamis dina panyimpenan lokal, janten DevOps kedah motong disk nyalira, ieu jilid ieu. Sareng aranjeunna kedah ngajelaskeun penyediaan Kubernetes, yén anjeun bakal gaduh jilid Persistent kelas sapertos kitu, anu aya dina titik sapertos kitu. Teras kedah dijelaskeun ka Kubernetes yén pods anu meryogikeun kelas panyimpen lokal sapertos kitu kedah dijadwalkeun dumasar kana labél ngan pikeun titik sapertos kitu. Pikeun tujuan ieu, operator ngagaduhan kamampuan pikeun napelkeun sababaraha jinis labél sareng hiji per conto host. Jeung tétéla yén pods bakal routed ku Kubernetes pikeun ngajalankeun ngan dina titik nu minuhan sarat, labél, dina istilah basajan. Administrator napelkeun labél, ngalakukeun provisioning of disk ku leungeun. Lajeng éta skala.

Sarta ngan pilihan katilu lokal mantuan pikeun nyieun saeutik gampang. Salaku geus I emphasized, ieu téh karya painstaking of tuning, nu pamustunganana mantuan pikeun meunangkeun kinerja maksimum.

Kuring boga patarosan kadua patali ieu. Kubernetes diciptakeun ku cara anu henteu masalah pikeun urang naha urang kaleungitan titik atanapi henteu. Naon anu kudu urang pigawé dina hal ieu lamun urang geus leungit titik dimana urang boga beling?

Leres, Kubernetes mimitina diposisikan yén hubungan urang sareng polong urang sapertos sapi, tapi di dieu unggal disk janten sapertos piaraan. Aya masalah sapertos anu urang teu bisa ngan buang aranjeunna. Sareng pamekaran Kubernetes nuju ka arah anu mustahil pikeun ngubaranana sacara filosofis, salaku sumber daya anu dipiceun.

Ayeuna patarosan praktis. Naon anu kudu dilakukeun upami anjeun kaleungitan titik dimana disk éta? Di dieu masalahna direngsekeun dina tingkat anu langkung luhur. Dina kasus ClickHouse, urang gaduh réplika anu dianggo dina tingkat anu langkung luhur, nyaéta. dina tingkat ClickHouse.

Naon disposition? DevOps tanggung jawab pikeun mastikeun yén data henteu leungit. Éta kedah leres nyetél réplikasi sareng kedah mastikeun yén réplikasi jalan. Dina replika di tingkat ClickHouse, data kudu duplikat. Ieu sanés tugas anu direngsekeun ku operator. Sareng sanés tugas anu direngsekeun ku Kubernetes nyalira. Ieu di tingkat ClickHouse.

Naon anu kudu dilakukeun upami titik beusi anjeun murag? Sareng tétéla éta bakal kedah nempatkeun anu kadua, leres-leres mindahkeun disk ka dinya, nerapkeun labél. Sarta sanggeus éta, éta bakal nyugemakeun sarat yén Kubernetes dina eta bisa ngajalankeun hiji conto pod. Kubernetes bakal ngaluncurkeunana. Jumlah polong anjeun henteu cekap pikeun anu ditangtukeun. Bakal ngaliwat siklus anu kuring nunjukkeun. Sareng dina tingkat anu paling luhur, ClickHouse bakal ngartos yén urang gaduh réplika anu diasupkeun, éta masih kosong sareng urang kedah ngamimitian nransfer data ka dinya. Jelema. prosés ieu masih kirang otomatis.

Hatur nuhun laporan! Nalika sagala rupa hal jahat kajantenan, operator nabrak sareng ngamimitian deui, sareng dina waktos éta acara sumping, anjeun kumaha waé ngolah ieu?

Naon anu lumangsung upami operator nabrak sareng ngamimitian deui, leres?

Sumuhun. Sarta dina momen éta kajadian datang.

Tugas naon anu kudu dipigawé dina hal ieu sawaréh dibagi antara operator jeung Kubernetes. Kubernetes mibanda kamampuhan pikeun muterkeun deui kajadian anu geus lumangsung. Anjeunna replays. Sareng tugas operator nyaéta mastikeun yén nalika log acara diulang deui, acara ieu idempoten. Sareng supados lumangsungna deui kajadian anu sami henteu ngarusak sistem kami pikeun urang. Jeung operator urang copes jeung tugas ieu.

Halo! Hatur nuhun laporan! Dmitry Zavialov, pausahaan Smedov. Naha rencanana pikeun nambihan pilihan kustomisasi sareng haproxy ka operator? Sababaraha balancer séjén metot sagigireun hiji standar, meh pinter jeung understands yén ClickHouse nyata aya.

Anjeun ngobrol ngeunaan Ingress?

Sumuhun, ngaganti Ingress ku haproxy. Dina haproxy, anjeun tiasa netepkeun topologi klaster dimana éta gaduh réplika.

Sajauh ieu, urang teu acan mikir ngeunaan eta. Upami anjeun peryogi sareng tiasa ngajelaskeun naha éta diperyogikeun, maka éta bakal tiasa dilaksanakeun, khususna upami anjeun hoyong ilubiung. Kami bakal resep mertimbangkeun pilihan. Jawaban pondok henteu, urang ayeuna teu gaduh fungsionalitas sapertos kitu. Hatur nuhun tip, urang tingali ieu. Sareng upami anjeun ogé ngajelaskeun kasus pamakean sareng kunaon perlu dina prakna, contona, nyiptakeun masalah dina GitHub, maka éta bakal saé.

Geus.

muhun. Kami kabuka pikeun sagala saran. Sareng haproxy dipasang dina daptar tugas. Daptar todo beuki nambahan, teu nyusut-nyusut acan. Tapi ieu saé, éta hartosna produkna aya dina paménta.

sumber: www.habr.com