Dina akhir Mei ngayakeun rapat online dina topik . Urang ngobrol ngeunaan wadahna, Kubernetes sareng orkestrasi prinsipna, kriteria pikeun milih infrastruktur sareng seueur deui. Pamilon ngabagi kasus tina praktékna sorangan.
Pamilonna:
- Evgeniy Potapov, CEO ITSumma. Langkung ti satengah palanggan na parantos pindah atanapi hoyong ngalih ka Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Mibanda 10+ taun pangalaman gawé bareng sistem wadahna.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ex-RAO UES. Anjeunna jangji bakal ngobrol ngeunaan kasus di perusahaan "getih".
- Andrey Fedorovsky, CTO "News360.com"Saatos ngagaleuh perusahaan ku pamaén sanés, anjeunna tanggung jawab sajumlah proyék sareng infrastruktur ML sareng AI.
- Ivan Kruglov, insinyur sistem, ex-Booking.com.Jalma anu sami anu ngalakukeun pisan sareng Kubernetes ku leungeun-Na sorangan.
Téma:
- Wawasan pamilon ngeunaan wadah sareng orkestrasi (Docker, Kubernetes, jsb.); naon anu dicoba dina prakna atawa dianalisis.
- Kasus: Perusahaan ngawangun rencana pangwangunan infrastruktur mangtaun-taun. Kumaha kaputusan dijieun naha ngawangun (atawa migrasi ayeuna) infrastruktur ka peti jeung Kuber atanapi henteu?
- Masalah di dunya awan-asli, naon anu leungit, hayu urang ngabayangkeun naon anu bakal kajadian isukan.
Diskusi anu pikaresepeun lumangsung, pendapat para pamilon béda-béda sareng nyababkeun seueur koméntar anu kuring hoyong bagikeun sareng anjeun. Dahar , sarta di handap ieu kasimpulan sawala.
Naha Kubernetes parantos janten pamasaran standar atanapi hébat?
"Kami sumping ka dinya (Kubernetes. - Ed.) Nalika teu aya anu terang ngeunaan éta. Urang datang ka manéhna sanajan manéhna teu aya. Kami hoyong éta sateuacan" - Dmitry Stolyarov
Poto ti Reddit.com
5-10 sababaraha taun ka pengker aya sajumlah ageung alat, sareng teu aya standar tunggal. Unggal genep bulan produk anyar muncul, atawa malah leuwih ti hiji. Mimiti Vagrant, teras Uyah, Chef, Wayang, ... "sareng anjeun ngawangun deui infrastruktur anjeun unggal genep bulan. Anjeun gaduh lima pangurus anu terus-terusan sibuk nyerat ulang konfigurasi, ”ngemut Andrey Fedorovsky. Anjeunna percaya yén Docker sareng Kubernetes parantos "rame kaluar" sésana. Docker parantos janten standar dina lima taun ka pengker, Kubernetes dina dua taun ka pengker. Sareng éta saé pikeun industri.
Dmitry Stolyarov jeung timnya cinta Kuber. Aranjeunna hoyong alat sapertos sateuacan muncul, sareng sumping ka éta nalika teu aya anu terang ngeunaan éta. Ayeuna, kusabab alesan genah, aranjeunna henteu nyandak klien upami aranjeunna ngartos yén aranjeunna moal nerapkeun Kubernetes sareng anjeunna. Dina waktos anu sami, numutkeun Dmitry, perusahaan ngagaduhan "seueur carita kasuksésan raksasa ngeunaan ngarobihkeun warisan anu dahsyat."
Kubernetes henteu ngan orchestration wadahna, éta sistem manajemen konfigurasi kalawan API dimekarkeun, komponén jaringan, L3 balancing na Ingress controller, nu ngajadikeun eta rélatif gampang pikeun ngatur sumberdaya, skala jeung abstrak ti lapisan handap infrastruktur.
Hanjakal, dina kahirupan urang urang kudu mayar sagalana. Sareng pajeg ieu ageung, khususna upami urang ngobrol ngeunaan transisi ka Kubernetes perusahaan kalayan infrastruktur anu maju, sakumaha anu dipercaya ku Ivan Kruglov. Anjeunna tiasa sacara bébas damel di perusahaan sareng infrastruktur tradisional sareng Kuber. Hal utama nyaéta ngartos karakteristik perusahaan sareng pasar. Tapi, contona, pikeun Evgeny Potapov, anu bakal generalize Kubernetes kana sagala alat orchestration wadahna, patarosan sapertos teu timbul.
Evgeniy ngagambar analogi sareng kaayaan dina taun 1990-an, nalika pemrograman berorientasi obyék muncul salaku cara pikeun program aplikasi kompléks. Dina waktos éta, perdebatan dituluykeun sareng alat-alat anyar muncul pikeun ngadukung OOP. Lajeng microservices mecenghul salaku cara pikeun mindahkeun jauh ti konsep monolithic. Ieu, kahareupna nyababkeun mecenghulna wadah sareng alat manajemén wadah. "Kuring nyangka yén urang bakal pas dugi ka waktos anu moal aya patarosan ngeunaan naha éta patut nyerat aplikasi microservice leutik, éta bakal diserat salaku microservice sacara standar," saur anjeunna. Kitu ogé, Docker sareng Kubernetes antukna bakal janten solusi standar tanpa peryogi pilihan.
Masalah database di stateless
poto ku
Kiwari, aya seueur resep pikeun ngajalankeun database di Kubernetes. Malah kumaha misahkeun bagian anu hade jeung I / O disk ti, conditionally, bagian aplikasi tina database. Naha mungkin dina mangsa nu bakal datang database bakal robah jadi loba nu bakal dikirimkeun dina kotak, dimana hiji bagian bakal orchestrated ngaliwatan Docker na Kubernetes, sarta dina bagian séjén infrastruktur, ngaliwatan software misah, bagian gudang bakal disadiakeun. ? Naha dasarna bakal robih salaku produk?
pedaran ieu sarupa jeung manajemén antrian, tapi sarat pikeun reliabiliti tur sinkronisasi informasi dina basis data tradisional loba nu leuwih luhur, Andrey yakin. Rasio hit cache dina database normal tetep dina 99%. Lamun pagawe turun, nu anyar dibuka, sarta cache "warms up" ti scratch. Nepi ka cache dipanaskeun, pagawé gawéna lalaunan, nu hartina teu bisa dieusian ku beban pamaké. Bari euweuh beban pamaké, cache teu haneut nepi. Ieu bunderan setan.
Dmitry dasarna teu satuju - kuorum sareng sharding ngajawab masalah. Tapi Andrey negeskeun yén solusina henteu cocog pikeun sadayana. Dina sababaraha kaayaan, quorum cocog, tapi nempatkeun beban tambahan dina jaringan. Database NoSQL henteu cocog dina sadaya kasus.
Peserta meetup dibagi jadi dua kubu.
Denis jeung Andrey ngajawab yén sagalana nu ditulis kana disk - database jeung saterusna - teu mungkin mun ngalakukeun dina ekosistem Kuber ayeuna. Teu mungkin pikeun ngajaga integritas sareng konsistensi data produksi di Kubernetes. Ieu fitur dasar. Solusi: infrastruktur hibrid.
Malahan basis data asli awan modern sapertos MongoDB sareng Cassandra, atanapi antrian pesen sapertos Kafka atanapi RabbitMQ, ngabutuhkeun toko data anu pengkuh di luar Kubernetes.
Objék Evgeniy: "Dasar di Kubera mangrupikeun cidera caket Rusia, atanapi caket perusahaan, anu aya hubunganana sareng kanyataan yén teu aya Cloud Adoption di Rusia." Perusahaan leutik atanapi sedeng di Jabar nyaéta Awan. Basis data Amazon RDS langkung gampang dianggo tibatan ngintip sareng Kubernetes nyalira. Di Rusia aranjeunna nganggo Kuber "on-premise" sareng mindahkeun pangkalan ka dinya nalika aranjeunna nyobian ngaleungitkeun kebon binatang.
Dmitry ogé henteu satuju kana pernyataan yén teu aya pangkalan data anu tiasa disimpen dina Kubernetes: "Dasar béda sareng dasar. Tur upami Anjeun salah nyorong database relational raksasa, teras dina kaayaan naon baé. Upami anjeun nyorong hal anu leutik sareng awan asli, anu disiapkeun sacara mental pikeun kahirupan semi-ephemeral, sadayana bakal saé. Dmitry ogé nyebatkeun yén alat manajemén database henteu siap pikeun Docker atanapi Kuber, janten kasusah anu ageung timbul.
Ivan, kahareupna yakin yén sanajan urang abstrak tina konsép stateful na stateless, ékosistem solusi perusahaan di Kubernetes teu acan siap. Kalayan Kuber, sesah ngajaga syarat législatif sareng pangaturan. Salaku conto, mustahil ngadamel solusi penyediaan identitas dimana jaminan idéntifikasi server anu ketat diperyogikeun, dugi ka hardware anu diselapkeun kana server. Wewengkon ieu ngembang, tapi tacan aya solusi.
Para pamilon henteu tiasa satuju, janten henteu aya kacindekan anu bakal ditarik dina bagian ieu. Hayu urang masihan sababaraha conto praktis.
Kasus 1. Cybersecurity of a "mega-regulator" kalawan basa di luar Kubera
Dina kasus sistem cybersecurity anu dimekarkeun, panggunaan wadah sareng orkestra ngamungkinkeun pikeun ngalawan serangan sareng intrusi. Salaku conto, dina hiji mega-regulator, Denis sareng timnya ngalaksanakeun kombinasi orkestra sareng layanan SIEM anu dilatih anu nganalisa log sacara real waktos sareng nangtoskeun prosés serangan, hacking atanapi gagal. Upami aya serangan, usaha pikeun nempatkeun hiji hal, atanapi upami aya invasi virus ransomware, éta, ngalangkungan orkestra, nyandak wadah anu aplikasina langkung gancang tibatan anu katépaan, atanapi langkung gancang tibatan panyerang narajang aranjeunna.
Kasus 2. Migrasi parsial database Booking.com ka Kubernetes
Dina Booking.com, database utama MySQL kalawan réplikasi Asynchronous - aya master sarta sakabeh hirarki budak. Ku waktu Ivan ninggalkeun parusahaan, hiji proyék dibuka pikeun mindahkeun budak nu bisa "ditémbak" jeung karuksakan tangtu.
Salian dasar utama, aya pamasangan Cassandra kalayan orkestrasi anu ditulis sorangan, anu ditulis sateuacan Kuber asup ka mainstream. Henteu aya masalah dina hal ieu, tapi tetep dina SSD lokal. Panyimpenan jarak jauh, bahkan dina pusat data anu sami, henteu dianggo kusabab masalah latency anu luhur.
Kelas katilu tina pangkalan data nyaéta jasa milarian Booking.com, dimana unggal titik jasa mangrupikeun pangkalan data. Usaha pikeun nransferkeun jasa pilarian ka Kuber gagal, sabab unggal titik 60-80 GB gudang lokal, nu hese "angkat" jeung "haneutkeun".
Hasilna, search engine teu dibikeun ka Kubernetes, sarta Ivan teu nyangka yén bakal aya usaha anyar dina mangsa nu bakal datang. Database MySQL ditransfer dina satengah: ngan Budak, anu henteu sieun "ditembak". Cassandra geus netep di sampurna.
Pilihan infrastruktur salaku tugas tanpa solusi umum
poto ku
Sebutkeun urang gaduh perusahaan énggal, atanapi perusahaan dimana bagian tina infrastruktur diwangun ku cara anu lami. Éta ngawangun rencana pangwangunan infrastruktur mangtaun-taun. Kumaha kaputusan dijieun naha ngawangun infrastruktur dina peti jeung Kuber atanapi henteu?
Pausahaan anu tarung pikeun nanoseconds teu kaasup ti diskusi. Konservatisme séhat mayar tina segi reliabilitas, tapi masih aya perusahaan anu kedah mertimbangkeun pendekatan énggal.
Ivan: "Kuring pasti bakal ngamimitian perusahaan dina awan ayeuna, ngan kusabab éta langkung gancang," sanaos henteu langkung mirah. Kalayan ngembangkeun kapitalisme venture, startups teu boga masalah badag duit, sarta tugas utama - nalukkeun pasar.
Ivan boga pamadegan yén ngembangkeun infrastruktur ayeuna mangrupakeun kriteria pilihan. Upami aya investasi anu serius dina jaman baheula, sareng tiasa dianggo, maka teu aya gunana pikeun ngulang deui. Lamun infrastruktur teu dimekarkeun, sarta aya masalah jeung parabot, kaamanan jeung ngawaskeun, mangka ngajadikeun rasa katingal dina infrastruktur disebarkeun.
Pajak kudu dibayar dina sagala hal, sarta Ivan bakal mayar hiji nu ngidinan anjeunna mayar kirang dina mangsa nu bakal datang. "Kusabab ngan ukur ku kanyataan yén kuring naek kareta api anu dipindah ku batur, kuring bakal ngarambat langkung jauh tibatan upami kuring naék karéta api anu sanés, dimana kuring kedah nempatkeun suluh sorangan."ceuk Ivan. Nalika perusahaan énggal, sareng sarat latency puluhan milliseconds, maka Ivan bakal ningali ka "operator" dimana database klasik "dibungkus" ayeuna. Aranjeunna ngangkat ranté réplikasi, anu ngagentos nyalira upami gagal, jsb ...
Pikeun perusahaan leutik sareng sababaraha server, Kubera henteu aya akal, ”saur Andrey. Tapi upami éta ngarencanakeun naék kana ratusan server atanapi langkung, maka peryogi otomatisasi sareng sistem manajemen sumber daya. 90% kasus patut biaya. Sumawona, paduli tingkat beban sareng sumber. Éta masuk akal pikeun sadayana, ti ngamimitian dugi ka perusahaan ageung kalayan panongton jutaan, pikeun laun-laun ningali kana produk orkestrasi wadahna. "Sumuhun, ieu bener mangsa nu bakal datang," Andrey yakin.
Denis ngagariskeun dua kriteria utama - scalability jeung stabilitas operasi. Anjeunna bakal milih alat anu paling cocog pikeun tugas éta. "Éta tiasa janten noname anu dipasang dina tuur anjeun, sareng éta ngagaduhan Nutanix Community Edition. Ieu tiasa janten garis kadua dina bentuk aplikasi dina Kuber sareng pangkalan data dina backend, anu direplikasi sareng parantos netepkeun parameter RTO sareng RPO" (tujuan waktos / titik pamulihan - kira-kira.).
Evgeniy ngaidentipikasi masalah mungkin kalawan tanaga. Ayeuna, teu seueur spesialis anu mumpuni di pasar anu ngartos "nyali". Mémang, lamun téhnologi dipilih geus heubeul, mangka hese nyewa saha lian ti jalma tengah umur anu bosen tur capé hirup. Sanajan pamilon séjén yakin yén ieu téh masalah latihan tanaga.
Upami urang nempatkeun patarosan pilihan: pikeun ngaluncurkeun perusahaan leutik di Public Cloud sareng database di Amazon RDS atanapi "dina premis" sareng database di Kubernetes, teras sanaos sababaraha kakurangan, Amazon RDS janten pilihan pamilon.
Kusabab seuseueurna pendengar meetup sanes ti perusahaan "getih", teras solusi disebarkeun téh naon urang kudu narékahan pikeun. Sistem panyimpen data kedah disebarkeun, dipercaya, sareng nyiptakeun latensi anu diukur dina unit milidetik, paling seueur puluhan.", Andrey nyimpulkeun.
Assessing pamakéan Kubernetes
Pangdéngé Anton Zhbankov naroskeun patarosan bubu ka apologists Kubernetes: kumaha anjeun milih sareng ngalaksanakeun studi kelayakan? Naha Kubernetes, naha henteu mesin virtual, contona?
poto ku
Dmitry jeung Ivan ngajawab eta. Dina duanana kasus, ngaliwatan trial and error, runtuyan kaputusan dijieun, hasilna duanana pamilon anjog di Kubernetes. Ayeuna usaha ngamimitian mandiri ngembangkeun parangkat lunak anu masuk akal pikeun mindahkeun ka Kuber. Kami henteu ngobrol ngeunaan sistem pihak katilu klasik, sapertos 1C. Kubernetes mantuan lamun pamekar kudu gancang nyieun release, kalawan non-stop Perbaikan Kontinyu.
Tim Andrey nyoba nyieun klaster scalable dumasar kana mesin virtual. Node murag kawas domino, nu kadang ngakibatkeun runtuhna klaster. "Sacara téoritis, anjeun tiasa ngabéréskeun éta sareng ngadukung éta ku panangan anjeun, tapi éta pikaboseneun. Sareng upami aya solusi dina pasar anu ngamungkinkeun anjeun damel di luar kotak, maka kami bakal resep. Sarta kami switched salaku hasilna, "saur Andrey.
Aya standar pikeun analisa sareng itungan sapertos kitu, tapi teu aya anu tiasa nyarios kumaha akuratna dina hardware nyata dina operasi. Pikeun itungan, éta ogé penting pikeun ngarti unggal alat jeung ékosistem, tapi ieu teu mungkin.
Naon awaits kami
poto ku
Salaku téhnologi evolves, beuki loba potongan disparate némbongan, lajeng transisi fase lumangsung, vendor mucunghul anu geus maéhan adonan cukup pikeun sagalana datangna babarengan dina alat tunggal.
Naha anjeun pikir bakal aya waktos nalika bakal aya alat sapertos Ubuntu pikeun dunya Linux? Panginten hiji wadah wadah sareng alat orkestra bakal kalebet Kuber. Éta bakal ngagampangkeun ngawangun awan di tempat.
Jawabanna dipasihkeun ku Ivan: "Google ayeuna ngawangun Anthos - ieu mangrupikeun tawaran rangkep anu nyebarkeun awan sareng kalebet Kuber, Service Mesh, monitoring - sadaya perkakas anu diperyogikeun pikeun microservices on-premise." Kami ampir ka hareup."
Denis ogé disebutkeun Nutanix na VMWare kalawan produk vRealize Suite, nu bisa Cope jeung tugas sarupa tanpa containerization.
Dmitry ngabagi pendapat na yén ngirangan "nyeri" sareng ngirangan pajeg mangrupikeun dua daérah dimana urang tiasa ngarepkeun perbaikan.
Pikeun nyimpulkeun sawala, urang nyorot masalah di handap ieu ngeunaan infrastruktur modern:
- Tilu pamilon langsung ngaidentifikasi masalah sareng stateful.
- Rupa-rupa masalah dukungan kaamanan, kalebet kamungkinan yén Docker bakal ditungtungan ku sababaraha versi Python, server aplikasi, sareng komponén.
Overspending, nu hadé dibahas dina rapat misah.
Tantangan diajar salaku orkestrasi mangrupikeun ékosistem anu kompleks.
Masalah umum di industri nyaéta nyalahgunakeun alat.Sesa conclusions terserah anjeun. Masih aya rasa yén kombinasi Docker + Kubernetes henteu gampang janten bagian "pusat" sistem. Salaku conto, sistem operasi dipasang dina hardware heula, anu henteu tiasa nyarios ngeunaan wadah sareng orkestra. Panginten ka hareup, sistem operasi sareng wadah bakal ngahiji sareng parangkat lunak manajemén awan.
poto kuAbdi hoyong nyandak kasempetan ieu pikeun ngucapkeun salam ka indung kuring sareng ngingetkeun yén urang gaduh grup Facebook , saluran kalawan publikasi metot ti sagala rupa blog tech. Sareng saluran kuring , dimana kuring ngobrol ngeunaan menata ngembangkeun di pausahaan produk.
sumber: www.habr.com