Ing pungkasan Mei nganakake rapat online babagan topik kasebut . Kita ngomong babagan kontainer, Kubernetes lan orkestrasi ing prinsip, kritéria kanggo milih infrastruktur lan liya-liyane. Peserta nuduhake kasus saka praktike dhewe.
Peserta:
- Evgeniy Potapov, CEO ITSumma. Luwih saka setengah pelanggan wis pindhah utawa pengin pindhah menyang Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Nduwe pengalaman 10+ taun nggarap sistem kontainer.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, mantan RAO UES. Dheweke janji bakal ngomong babagan kasus ing perusahaan "getih".
- Andrey Fedorovsky, CTO "News360.com"Sawise tuku perusahaan dening pemain liyane, dheweke tanggung jawab kanggo sawetara proyek lan infrastruktur ML lan AI.
- Ivan Kruglov, insinyur sistem, ex-Booking.com.Wong sing padha nindakake akeh karo Kubernetes nganggo tangane dhewe.
Tema:
- Wawasan peserta babagan wadhah lan orkestrasi (Docker, Kubernetes, lsp); apa sing dicoba ing laku utawa dianalisis.
- Kasus: Perusahaan mbangun rencana pembangunan infrastruktur kanggo taun. Kepiye keputusan apa arep mbangun (utawa migrasi infrastruktur saiki) menyang kontaner lan Kuber utawa ora?
- Masalah ing jagad asli awan, apa sing ilang, ayo bayangake apa sing bakal kedadeyan sesuk.
Diskusi sing menarik ditindakake, panemu para peserta beda banget lan nyebabake akeh komentar sing aku pengin bareng karo sampeyan. mangan , lan ing ngisor iki ringkesan diskusi.
Apa Kubernetes wis dadi marketing standar utawa apik?
"We teka menyang (Kubernetes. - Ed.) Nalika durung ana sing ngerti. Kita teka marang dheweke sanajan dheweke ora ana. Kita pengin sadurunge" - Dmitry Stolyarov
Foto saka Reddit.com
5-10 taun kepungkur ana akeh alat, lan ora ana standar siji. Saben nem sasi produk anyar muncul, utawa malah luwih saka siji. Vagrant pisanan, banjur Salt, Chef, Wayang, ... "lan sampeyan mbangun maneh infrastruktur saben nem sasi. Sampeyan duwe limang administrator sing terus-terusan sibuk nulis ulang konfigurasi, "kelingan Andrey Fedorovsky. Dheweke percaya yen Docker lan Kubernetes wis "wong akeh" liyane. Docker wis dadi standar sajrone limang taun kepungkur, Kubernetes sajrone rong taun kepungkur. Lan iku apik kanggo industri..
Dmitry Stolyarov lan tim tresna Kuber. Dheweke pengin alat kasebut sadurunge katon, lan teka nalika ora ana sing ngerti. Saiki, kanthi alasan penak, dheweke ora njupuk klien yen dheweke ngerti yen dheweke ora bakal ngetrapake Kubernetes karo dheweke. Ing wektu sing padha, miturut Dmitry, perusahaan kasebut duwe "akeh crita sukses gedhe babagan nggawe maneh warisan sing nggegirisi."
Kubernetes ora mung orkestrasi wadhah, iku sistem manajemen konfigurasi karo API dikembangaké, komponèn jaringan, imbangan L3 lan pengontrol Ingress, kang ndadekake iku relatif gampang kanggo ngatur sumber daya, ukuran lan abstrak saka lapisan ngisor saka infrastruktur.
Sayange, ing urip kita kudu mbayar kabeh. Lan pajak iki gedhe, utamane yen kita ngomong babagan transisi menyang Kubernetes perusahaan kanthi infrastruktur sing dikembangake, kaya sing dipercaya Ivan Kruglov. Dheweke bisa kerja kanthi bebas ing perusahaan kanthi infrastruktur tradisional lan karo Kuber. Sing utama yaiku ngerti karakteristik perusahaan lan pasar. Nanging, contone, kanggo Evgeny Potapov, sing bakal generalize Kubernetes kanggo sembarang alat orkestrasi wadhah, pitakonan kuwi ora muncul.
Evgeniy nggambar analogi karo kahanan ing taun 1990-an, nalika pemrograman berorientasi obyek muncul minangka cara pemrograman aplikasi kompleks. Ing wektu iku, debat terus lan alat anyar katon kanggo ndhukung OOP. Banjur microservices muncul minangka cara kanggo pindhah saka konsep monolitik. Iki, ing siji, mimpin kanggo emergence saka wadhah lan piranti manajemen wadhah. "Aku mikir sing kita bakal rauh teka ing wektu nalika ora ana pitakonan apa iku worth nulis aplikasi microservice cilik, iku bakal ditulis minangka microservice minangka standar,"Panjenenganipun pracaya. Kajaba iku, Docker lan Kubernetes pungkasane bakal dadi solusi standar tanpa mbutuhake pilihan.
Masalah database ing stateless
Foto dening
Saiki, ana akeh resep kanggo mbukak database ing Kubernetes. Malah carane misahake bagean sing dianggo karo I / O disk saka, kondisional, bagean aplikasi saka database. Apa bisa uga ing mangsa ngarep database bakal owah dadi akeh sing bakal dikirim ing kothak, ing ngendi siji bagean bakal diatur liwat Docker lan Kubernetes, lan ing bagean infrastruktur liyane, liwat piranti lunak sing kapisah, bagean panyimpenan bakal diwenehake. ? Apa basis bakal ganti minangka produk?
Katrangan iki padha karo manajemen antrian, nanging syarat kanggo linuwih lan sinkronisasi informasi ing basis data tradisional luwih dhuwur, Andrey percaya. Rasio hit cache ing database normal tetep ing 99%. Yen buruh mudhun, sing anyar diluncurake, lan cache "anget" saka awal. Nganti cache wis digawe panas, buruh kasebut alon-alon, tegese ora bisa diisi karo beban pangguna. Nalika ora ana beban pangguna, cache ora dadi panas. Iku bunder setan.
Dmitry dhasar ora setuju - kuorum lan sharding ngatasi masalah kasebut. Nanging Andrey negesake manawa solusi kasebut ora cocog kanggo kabeh wong. Ing sawetara kahanan, quorum cocok, nanging nempatno beban tambahan ing jaringan. Database NoSQL ora cocok ing kabeh kasus.
Peserta meetup dibagi dadi rong kemah.
Denis lan Andrey mbantah manawa kabeh sing ditulis ing disk - database lan liya-liyane - ora bisa ditindakake ing ekosistem Kuber saiki. Ora bisa njaga integritas lan konsistensi data produksi ing Kubernetes. Iki minangka fitur dhasar. Solusi: infrastruktur hibrida.
Malah database asli awan modern kaya MongoDB lan Cassandra, utawa antrian pesen kaya Kafka utawa RabbitMQ, mbutuhake nyimpen data sing terus-terusan ing njaba Kubernetes.
Obyek Evgeniy: "Basis ing Kubera minangka ciloko sing cedhak karo Rusia, utawa cedhak perusahaan, sing digandhengake karo kasunyatan manawa ora ana Adoption Cloud ing Rusia." Perusahaan cilik utawa menengah ing Kulon yaiku Cloud. Database Amazon RDS luwih gampang digunakake tinimbang tinkering karo Kubernetes dhewe. Ing Rusia padha nggunakake Kuber "on-premise" lan nransfer basis kanggo iku nalika padha nyoba kanggo njaluk nyisihaken saka zoo.
Dmitry uga ora setuju karo pernyataan yen ora ana database sing bisa disimpen ing Kubernetes: "Base beda karo basis. Lan yen sampeyan push database relasional buta, banjur ing kahanan apa wae. Yen sampeyan push soko cilik lan maya asli, kang mental disiapake kanggo urip semi-ephemeral, kabeh bakal apik. Dmitry uga nyebutake manawa alat manajemen database durung siyap kanggo Docker utawa Kuber, mula ana alangan gedhe.
Ivan, kanthi yakin, sanajan kita abstrak saka konsep stateful lan stateless, ekosistem solusi perusahaan ing Kubernetes durung siap. Kanthi Kuber, angel njaga syarat legislatif lan peraturan. Contone, ora bisa nggawe solusi panyedhiya identitas sing mbutuhake jaminan identifikasi server sing ketat, nganti hardware sing dipasang ing server. Wilayah iki berkembang, nanging durung ana solusi.
Peserta ora bisa setuju, mula ora ana kesimpulan sing bakal ditindakake ing bagean iki. Ayo menehi sawetara conto praktis.
Kasus 1. Cybersecurity saka "mega-regulator" karo basis njaba Kubera
Ing kasus sistem cybersecurity sing dikembangake, panggunaan wadhah lan orkestrasi ndadekake bisa nglawan serangan lan intrusi. Contone, ing siji mega-regulator, Denis lan tim nindakake kombinasi orkestra karo layanan SIEM dilatih sing nganalisa log ing wektu nyata lan nemtokake proses serangan, hacking utawa Gagal. Yen ana serangan, upaya kanggo nyelehake barang, utawa yen ana invasi virus ransomware, liwat orkestra, njupuk wadhah kanthi aplikasi luwih cepet tinimbang sing kena infeksi, utawa luwih cepet tinimbang sing nyerang.
Kasus 2. Migrasi parsial saka database Booking.com menyang Kubernetes
Ing Booking.com, basis data utama yaiku MySQL kanthi replikasi asinkron - ana master lan kabeh hirarki budak. Nalika Ivan ninggalake perusahaan kasebut, sawijining proyek diluncurake kanggo nransfer budak sing bisa "ditembak" kanthi karusakan tartamtu.
Saliyane ing basis utama, ana instalasi Cassandra kanthi orkestrasi sing ditulis dhewe, sing ditulis sadurunge Kuber mlebu aliran utama. Ora ana masalah ing babagan iki, nanging tetep ing SSD lokal. Panyimpenan adoh, sanajan ing pusat data sing padha, ora digunakake amarga masalah latensi dhuwur.
Database kelas katelu yaiku layanan telusuran Booking.com, ing ngendi saben simpul layanan minangka basis data. Usaha kanggo mindhah layanan telusuran menyang Kuber gagal, amarga saben simpul 60-80 GB panyimpenan lokal, sing angel "ngangkat" lan "anget".
Akibaté, mesin telusur ora ditransfer menyang Kubernetes, lan Ivan ora mikir yen bakal ana upaya anyar ing mangsa ngarep. Database MySQL ditransfer setengah: mung Budak, sing ora wedi "ditembak". Cassandra wis mapan ing sampurna.
Pilihan infrastruktur minangka tugas tanpa solusi umum
Foto dening
Ayo kita duwe perusahaan anyar, utawa perusahaan sing bagean infrastruktur dibangun kanthi cara sing lawas. Iku mbangun rencana pembangunan infrastruktur kanggo taun. Kepiye keputusane arep mbangun infrastruktur ing kontainer lan Kuber utawa ora?
Perusahaan sing berjuang kanggo nanodetik ora kalebu saka diskusi. Konservatisme sing sehat mbayar saka segi linuwih, nanging isih ana perusahaan sing kudu nimbang pendekatan anyar.
Ivan: "Aku mesthi bakal miwiti perusahaan ing awan saiki, mung amarga luwih cepet," sanajan ora mesthi luwih murah. Kanthi pangembangan kapitalisme ventura, startup ora duwe masalah gedhe karo dhuwit, lan tugas utama yaiku nelukake pasar.
Ivan wis mratelakake panemume pangembangan infrastruktur saiki minangka kritéria pilihan. Yen ana investasi serius ing jaman kepungkur, lan kerjane, mula ora ana gunane maneh. Yen infrastruktur ora dikembangaké, lan ana masalah karo alat, keamanan lan ngawasi, banjur iku ndadekake pangertèn kanggo dipikir ing infrastruktur mbagekke.
Ing kasus apa wae, pajak kudu dibayar, lan Ivan bakal mbayar sing ngidini dheweke mbayar luwih murah ing mangsa ngarep. "Amarga mung amarga aku numpak sepur sing diobahake wong liya, aku bakal lelungan luwih adoh tinimbang yen aku lungguh ing sepur liyane, sing kudu daklebokake bahan bakar dhewe."ujare Ivan. Nalika perusahaan anyar, lan syarat latensi puluhan milidetik, banjur Ivan bakal katon menyang "operator" ing ngendi database klasik "dibungkus" saiki. Padha mundhakaken chain replikasi, kang ngalih dhewe ing cilik saka failover, etc ...
Kanggo perusahaan cilik sing duwe sawetara server, Kubera ora ana gunane, "ujare Andrey. Nanging yen rencana bakal tuwuh nganti atusan server utawa luwih, mula butuh otomatisasi lan sistem manajemen sumber daya. 90% kasus worth biaya. Kajaba iku, preduli saka tingkat beban lan sumber daya. Iku ndadekake pangertèn kanggo kabeh wong, saka startups kanggo perusahaan gedhe karo pamirsa yuta, kanggo mboko sithik katon menyang produk orkestrasi wadah. "Ya, iki pancen masa depan," Andrey yakin.
Denis nerangake rong kritéria utama - skalabilitas lan stabilitas operasi. Dheweke bakal milih alat sing paling cocog kanggo tugas kasebut. "Bisa uga ora ana jeneng sing dipasang ing dhengkul, lan ana Nutanix Community Edition. Iki bisa dadi baris kapindho ing wangun aplikasi ing Kuber kanthi basis data ing backend, sing ditiru lan wis nemtokake paramèter RTO lan RPO" (tujuan wektu / titik pemulihan - kira-kira).
Evgeniy ngenali masalah bisa karo personel. Saiki, ora akeh spesialis sing nduweni kualifikasi ing pasar sing ngerti "nyali". Pancen yen teknologi sing dipilih wis tuwa, mula angel nyewa wong liya kajaba wong setengah tuwa sing bosen lan kesel urip. Sanajan peserta liyane percaya yen iki minangka latihan personel.
Yen kita sijine pitakonan pilihan: kanggo miwiti perusahaan cilik ing Public Cloud karo database ing Amazon RDS utawa "ing premis" karo database ing Kubernetes, banjur senadyan sawetara shortcomings, pilihan saka peserta ana Amazon RDS.
Amarga mayoritas pamireng meetup ora saka perusahaan "getih", banjur solusi sing disebarake yaiku sing kudu ditindakake. Sistem panyimpenan data kudu disebarake, dipercaya, lan nggawe latensi sing diukur ing unit milidetik, paling akeh puluhan", Andrey nyimpulake.
Netepake panggunaan Kubernetes
Pendengar Anton Zhbankov takon pitakonan jebakan menyang apolog Kubernetes: kepiye sampeyan milih lan nganakake studi kelayakan? Napa Kubernetes, apa ora mesin virtual, contone?
Foto dening
Dmitry lan Ivan mangsuli. Ing kasus loro, liwat nyoba lan kesalahan, urutan kaputusan digawe, minangka asil saka loro peserta teka ing Kubernetes. Saiki bisnis wiwit ngembangake piranti lunak kanthi mandiri sing bisa ditransfer menyang Kuber. Kita ora ngomong babagan sistem pihak katelu klasik, kayata 1C. Kubernetes mbantu nalika pangembang kudu cepet-cepet nggawe rilis, kanthi dandan Terus-terusan tanpa mandheg.
Tim Andrey nyoba nggawe kluster sing bisa diukur adhedhasar mesin virtual. Node ambruk kaya domino, sing kadhangkala nyebabake ambruk kluster. "Secara teoritis, sampeyan bisa ngrampungake lan nyengkuyung nganggo tangan sampeyan, nanging angel banget. Lan yen ana solusi ing pasar sing ngidini sampeyan bisa metu saka kothak, mula kita bakal seneng. Lan kita ngalih minangka asil, "ujare Andrey.
Ana standar kanggo analisis lan pitungan kuwi, nanging ora ana kang bisa ngomong carane akurat ing hardware nyata ing operasi. Kanggo petungan, uga penting kanggo ngerti saben alat lan ekosistem, nanging iki ora bisa ditindakake.
Apa sing nunggu kita
Foto dening
Minangka teknologi evolves, liyane lan liyane bêsik disparate katon, lan banjur transisi phase dumadi, vendor katon sing wis matèni cukup adonan kanggo kabeh teka bebarengan ing alat siji.
Apa sampeyan mikir bakal ana wektu nalika bakal ana alat kaya Ubuntu kanggo jagad Linux? Bisa uga alat wadah lan orkestrasi siji bakal kalebu Kuber. Iku bakal nggawe gampang kanggo mbangun awan ing panggonan.
Wangsulan kasebut diwenehake dening Ivan: "Google saiki mbangun Anthos - iki minangka tawaran paket sing nyebarake awan lan kalebu Kuber, Service Mesh, ngawasi - kabeh hardware sing dibutuhake kanggo microservices on-premise." Kita meh ing mangsa ngarep."
Denis uga kasebut Nutanix lan VMWare karo produk vRealize Suite, kang bisa ngrampungake karo tugas padha tanpa containerization.
Dmitry mratelakake panemume yen nyuda "nyeri" lan nyuda pajak minangka rong wilayah sing bisa diarepake.
Kanggo ngringkes diskusi, kita nyorot masalah infrastruktur modern ing ngisor iki:
- Telung peserta langsung ngenali masalah karo stateful.
- Macem-macem masalah dhukungan keamanan, kalebu kemungkinan Docker bakal entuk pirang-pirang versi Python, server aplikasi, lan komponen.
Overspending, sing luwih apik kanggo dibahas ing rapat sing kapisah.
Tantangan sinau minangka orkestrasi minangka ekosistem sing kompleks.
Masalah umum ing industri yaiku nyalahi panggunaan alat.Liyane saka kesimpulan terserah sampeyan. Isih ana perasaan sing ora gampang kanggo kombinasi Docker + Kubernetes dadi bagean "tengah" saka sistem. Contone, sistem operasi diinstal ing hardware pisanan, kang ora bisa ngandika bab wadhah lan orkestrasi. Mungkin ing mangsa ngarep, sistem operasi lan kontaner bakal gabung karo piranti lunak manajemen awan.
Foto deningAku pengin njupuk kesempatan iki kanggo ngucapake salam marang ibu lan ngelingake yen kita duwe grup Facebook , saluran karo publikasi menarik saka macem-macem blog teknologi. Lan saluranku , ing ngendi aku ngomong babagan ngatur pangembangan ing perusahaan produk.
Source: www.habr.com