Ing antisipasi Vitaly Khabarov diwawancarai Dmitry Stolyarov (), direktur teknis lan pendiri perusahaan Flant. Vitaly takon marang Dmitry babagan apa sing ditindakake Flant, babagan Kubernetes, pangembangan ekosistem, dhukungan. Kita rembugan kenapa Kubernetes dibutuhake lan apa perlu. Lan uga babagan layanan mikro, Amazon AWS, pendekatan "Aku bakal begja" kanggo DevOps, masa depan Kubernetes dhewe, kenapa, kapan lan kepiye carane bakal njupuk alih jagad iki, prospek DevOps lan apa sing kudu disiapake para insinyur ing padhang lan cedhak karo simplifikasi lan jaringan saraf.
ngrungokake minangka podcast ing DevOps Deflop - podcast basa Rusia babagan DevOps, lan ing ngisor iki versi teks.
Ing kene lan ing ngisor iki dheweke takon insinyur saka Express42.
Tentang "Flant"
- Hello Dima. Sampeyan direktur teknis ""lan uga pendiri. Mangga kandhani apa sing ditindakake perusahaan lan apa sing sampeyan lakoni?
Dmitry: Saka njaba misale jek kaya wong-wong sing ngubengi nginstal Kubernetes kanggo kabeh wong lan nindakake apa wae. Nanging kuwi ora bener. Kita miwiti minangka perusahaan sing ngurusi Linux, nanging wis suwe banget kegiatan utama kita yaiku nglayani proyèk produksi lan turnkey kanthi beban dhuwur. Biasane kita mbangun kabeh infrastruktur saka awal lan banjur tanggung jawab kanggo wektu sing suwe. Mulane, karya utama sing ditindakake "Flant", sing entuk dhuwit, yaiku njupuk tanggung jawab lan ngleksanakake produksi turnkey.
Aku, minangka direktur teknis lan salah sawijining pendiri perusahaan, ngentekake sedina lan wengi nyoba ngerteni carane nambah aksesibilitas produksi, nyederhanakake operasi, nggawe urip pangurus luwih gampang, lan urip pangembang luwih nyenengake. .
Babagan Kubernetes
- Akhir-akhir iki aku wis weruh akeh laporan saka Flant lan babagan Kubernetes. Kepiye carane sampeyan teka?
Dmitry: Aku wis ngomong babagan iki kaping pirang-pirang, nanging aku ora keberatan mbaleni maneh. Aku pancene bener kanggo mbaleni topik iki amarga ana kebingungan antarane sabab lan akibat.
Kita pancene butuh alat. Kita ngadhepi akeh masalah, berjuang, ngatasi kanthi macem-macem kruk lan rumangsa butuh alat. Kita ngliwati macem-macem pilihan, nggawe sepedha dhewe, lan entuk pengalaman. Mboko sithik kita tekan titik ing ngendi kita wiwit nggunakake Docker meh sanalika muncul - sekitar 2013. Nalika katon, kita wis akeh pengalaman karo kontaner, kita wis nulis analog saka "Docker" - sawetara crutches kita dhewe ing Python. Kanthi tekane Docker, bisa mbuwang crutches lan nggunakake solusi sing dipercaya lan didhukung komunitas.
Kanthi Kubernetes critane padha. Nalika wiwit entuk momentum - kanggo kita iki versi 1.2 - kita wis duwe akeh crutches ing Shell lan Chef, sing kita nyoba ngatur karo Docker. Kita serius nggoleki Rancher lan macem-macem solusi liyane, nanging banjur muncul Kubernetes, sing kabeh ditindakake kanthi persis kaya sing bakal ditindakake utawa luwih apik. Ora ana apa-apa kanggo sambat.
Ya, ana sawetara jinis imperfection ing kene, ana sawetara jenis imperfection ana - ana akeh imperfections, lan 1.2 umume elek, nanging ... Kubernetes kaya bangunan ing construction - sampeyan ndeleng proyek lan ngerti. sing bakal kelangan. Yen bangunan saiki duwe dhasar lan rong lantai, mula sampeyan ngerti manawa luwih becik ora pindhah, nanging ora ana masalah karo piranti lunak kasebut - sampeyan wis bisa nggunakake.
Kita ora duwe wayahe mikir babagan nggunakake Kubernetes utawa ora. Kita ngenteni suwe sadurunge muncul, lan nyoba nggawe analog dhewe.
Babagan Kubernetes
— Apa sampeyan langsung melu pangembangan Kubernetes dhewe?
Dmitry: Sedheng. Nanging, kita melu pangembangan ekosistem. Kita ngirim sawetara panjalukan narik: menyang Prometheus, menyang macem-macem operator, kanggo Helm - menyang ekosistem. Sayange, aku ora bisa nglacak kabeh kita apa lan aku bisa salah, nanging ora ana blumbang siji saka kita menyang inti.
— Ing wektu sing padha, apa sampeyan ngembangake akeh alat ing sekitar Kubernetes?
Dmitry: Strategi iki: kita pindhah lan narik panjalukan kanggo kabeh sing wis ana. Yen panjaluk tarik ora ditampa ing kana, kita mung ngethok dhewe lan urip nganti ditampa karo bangunan kita. Banjur, nalika tekan hulu, kita bali menyang versi hulu.
Contone, kita duwe operator Prometheus, sing bisa bolak-balik menyang hulu perakitan kita wis 5 kali. We kudu sawetara jenis fitur, kita ngirim panjalukan narik, kita kudu muter metu sesuk, nanging kita ora pengin ngenteni kanggo dirilis ing hulu. Patut, kita ngumpul kanggo awake dhewe, muter metu perakitan kita karo fitur kita, kang perlu kanggo sawetara alesan, kanggo kabeh klompok kita. Banjur, contone, padha nguripake menyang kita ing hulu karo tembung: "Guys, ayo nindakaken kanggo kasus sing luwih umum," kita, utawa wong liya, rampung, lan liwat wektu iku merges maneh.
Kita nyoba ngembangake kabeh sing ana. Akeh unsur sing durung ana, durung ditemokake, utawa wis diciptakake, nanging ora duwe wektu kanggo ngetrapake - kita nindakake. Lan ora amarga kita seneng proses utawa bangunan sepeda minangka industri, nanging mung amarga kita butuh alat iki. Pitakonan asring ditakokake, kenapa kita nindakake iki utawa perkara kasebut? Jawaban iki prasaja - ya, amarga kita kudu luwih maju, ngrampungake sawetara masalah praktis, lan kita ngrampungake karo tula iki.
Path kasebut mesthi kaya mangkene: kita nggoleki kanthi ati-ati lan, yen kita ora nemokake solusi babagan carane nggawe trolleybus saka roti, banjur nggawe roti dhewe lan trolleybus dhewe.
Alat Flanta
- Aku ngerti yen Flant saiki duwe operator addon, operator cangkang, lan alat dapp/werf. Nalika aku ngerti, iki minangka instrumen sing padha ing inkarnasi sing beda. Aku uga ngerti manawa ana akeh alat liyane ing Flaunt. Iki bener?
Dmitry: Kita duwe luwih akeh ing GitHub. Saka sing dakelingake saiki, kita duwe peta status - panel kanggo Grafana sing wis ditemokake kabeh. Disebutake ing meh saben artikel kapindho babagan pemantauan Kubernetes ing Medium. Sampeyan ora bisa njlèntrèhaké kanthi ringkes apa statusmap - iku perlu artikel kapisah, nanging iku migunani banget kanggo ngawasi status liwat wektu, amarga ing Kubernetes kita asring kudu nuduhake status liwat wektu. Kita uga duwe LogHouse - iki adhedhasar ClickHouse lan sihir ireng kanggo ngumpulake log ing Kubernetes.
Akeh keperluan! Lan bakal ana liyane, amarga sawetara solusi internal bakal dirilis ing taun iki. Saka sing gedhe banget adhedhasar operator addon, ana akeh addon kanggo Kubernetes, ala carane nginstal manajer sert kanthi bener - alat kanggo ngatur sertifikat, carane nginstal Prometheus kanthi akeh aksesoris - iki kira-kira rong puluh beda. binar sing ngekspor data lan ngumpulake soko, kanggo Prometheus iki wis grafis paling apik tenan lan tandha. Kabeh iki mung Bunch saka addons kanggo Kubernetes, kang diinstal ing kluster, lan dadi saka prasaja kanggo kelangan, canggih, otomatis, kang akeh masalah wis ditanggulangi. Ya, kita nindakake akeh.
Pengembangan Ekosistem
"Sampeyan misale jek iki minangka kontribusi gedhe kanggo pangembangan instrumen iki lan cara panggunaane." Apa sampeyan bisa ngira sapa maneh sing bakal menehi kontribusi sing padha kanggo pangembangan ekosistem?
Dmitry: Ing Rusia, perusahaan sing beroperasi ing pasar kita, ora ana sing cedhak. Mesthine, iki minangka pernyataan sing banter, amarga ana pemain utama kaya Mail lan Yandex - dheweke uga nindakake apa wae karo Kubernetes, nanging malah ora nyedhaki kontribusi perusahaan ing saindenging jagad sing nindakake luwih akeh tinimbang kita. Iku angel kanggo mbandhingaké Flant, kang duwe Staff 80 wong, lan Red Hat, kang 300 engineers saben Kubernetes piyambak, yen aku ora salah. Iku angel kanggo mbandhingaké. Kita duwe 6 wong ing departemen RnD, kalebu aku, sing ngethok kabeh alat. 6 wong nglawan 300 insinyur Red Hat - pancen angel dibandhingake.
- Nanging, nalika malah iki 6 wong bisa nindakake soko tenan migunani lan alienating, nalika lagi ngadhepi karo masalah praktis lan menehi solusi kanggo masyarakat - kasus menarik. Aku ngerti manawa ing perusahaan teknologi gedhe, ing ngendi dheweke duwe tim pangembangan lan dhukungan Kubernetes dhewe, ing prinsip, alat sing padha bisa dikembangake. Iki minangka conto kanggo dheweke babagan apa sing bisa dikembangake lan diwenehake marang masyarakat, menehi dorongan kanggo kabeh komunitas sing nggunakake Kubernetes.
Dmitry: Iki mbokmenawa fitur saka integrator, peculiarity sawijining. Kita duwe akeh proyek lan kita ndeleng macem-macem kahanan. Kanggo kita, cara utama kanggo nggawe nilai tambah yaiku nganalisa kasus kasebut, golek kesamaan lan nggawe regane murah kanggo kita. Kita aktif nggarap iki. Pancen angel kanggo aku ngomong babagan Rusia lan jagad iki, nanging ana 40 insinyur DevOps ing perusahaan sing nggarap Kubernetes. Aku ora mikir ana akeh perusahaan ing Rusia karo nomer iso dibandhingke spesialis sing ngerti Kubernetes, yen ana ing kabeh.
Aku ngerti kabeh babagan judhul proyek insinyur DevOps, kabeh wong ngerti kabeh lan wis biasa nelpon insinyur DevOps insinyur DevOps, kita ora bakal ngrembug babagan iki. Kabeh 40 insinyur DevOps sing nggumunake iki ngadhepi lan ngrampungake masalah saben dina, kita mung nganalisa pengalaman iki lan nyoba nggawe umum. Kita mangertos, yen tetep ana ing njero kita, banjur ing setahun utawa rong alat kasebut ora ana gunane, amarga ing endi wae ing masyarakat bakal katon Tula sing wis siap. Ora ana gunane kanggo nglumpukake pengalaman iki kanthi internal - mung mbuwang energi lan wektu menyang dev / null. Lan kita ora melas kanggo kabeh. Kita nerbitake kabeh kanthi seneng banget lan ngerti manawa kudu diterbitake, dikembangake, dipromosikan, dipromosekake, supaya wong nggunakake lan nambah pengalaman - banjur kabeh tuwuh lan urip. Banjur sawise rong taun piranti kasebut ora mlebu ing tong sampah. Iku ora tega kanggo terus pour ing kekuatan, amarga wis cetha yen ana wong nggunakake piranti, lan sawise rong taun kabeh wong nggunakake.
Iki minangka bagean saka strategi gedhe kita karo dapp/werf. Aku ora ngelingi nalika kita miwiti nggawe, misale jek kaya 3 taun kepungkur. Kaping pisanan, umume ana ing cangkang. Iku bukti super konsep, kita ditanggulangi sawetara masalah tartamtu - iku bisa! Nanging ana masalah karo cangkang, ora bisa nggedhekake luwih lanjut, program ing cangkang minangka tugas liyane. Kita duwe pakulinan nulis ing Ruby, mula, kita nggawe maneh ing Ruby, dikembangake, dikembangake, dikembangake, lan kedadeyan yen masyarakat, wong akeh sing ora ujar "kita pengin utawa ora pengin, ” dadi irung munggah marang Ruby, Piye iki ora lucu? Kita nyadari yen kita kudu nulis kabeh iki ing Go mung kanggo nemokake titik pisanan ing daftar priksa: Alat DevOps kudu binar statis. Dadi Go utawa ora penting banget, nanging binar statis sing ditulis ing Go luwih apik.
Kita ngginakaken energi, rewrote dapp ing Go lan disebut werf. Dapp ora maneh didhukung, ora dikembangaké, mlaku ing sawetara versi paling anyar, nanging ana path upgrade Absolute kanggo ndhuwur, lan sampeyan bisa tindakake iku.
Kenapa dapp digawe?
— Apa sampeyan bisa ngomong kanthi ringkes kenapa dapp digawe, masalah apa sing dirampungake?
Dmitry: Alasan pisanan ing perakitan. Kaping pisanan, kita duwe masalah serius karo mbangun nalika Docker ora duwe kemampuan multi-stage, mula kita nggawe multi-stage dhewe. Banjur kita duwe masalah liyane babagan ngresiki gambar. Saben uwong sing nindakake CI / CD, cepet tinimbang mengko, ngadhepi karo masalah sing ana Bunch saka gambar diklumpukake, sampeyan kudu piye wae ngresiki metu apa ora perlu lan ninggalake apa sing perlu.
Alasan kapindho yaiku penyebaran. Ya, ana Helm, nanging mung ngrampungake sawetara masalah. Cukup lucu, ditulis manawa "Helm minangka Manajer Paket kanggo Kubernetes." Persis apa "ing". Ana uga tembung "Package Manager" - apa sing dikarepake saka Manager Paket? Kita ujar: "Package Manager - instal paket!" lan kita ngarepake dheweke ngandhani: "Paket wis dikirim."
Iku menarik yen kita ngomong: "Helm, nginstal paket," lan nalika wangsulan sing wis diinstal, pranyata dheweke mung miwiti instalasi - nuduhake Kubernetes: "Bukak iki!", Lan apa iku diwiwiti utawa ora. , apa bisa utawa ora , Helm ora ngatasi masalah iki ing kabeh.
Pranyata Helm mung preprocessor teks sing ngemot data menyang Kubernetes.
Nanging minangka bagean saka penyebaran apa wae, kita pengin ngerti apa aplikasi kasebut wis dirilis kanggo produksi utawa ora? Digulung metu kanggo prod tegese aplikasi wis dipindhah ana, versi anyar wis disebarake, lan paling ora nabrak ana lan nanggapi kanthi bener. Helm ora ngatasi masalah iki kanthi cara apa wae. Kanggo ngatasi, sampeyan kudu nglampahi akeh gaweyan, amarga sampeyan kudu menehi Kubernetes printah kanggo muter metu lan ngawasi apa ana - apa iku disebarake utawa mbalek metu. Lan ana uga akeh tugas sing ana gandhengane karo penyebaran, reresik, lan perakitan.
Rencana
Taun iki kita bakal miwiti pembangunan lokal. Kita pengin entuk apa sing sadurunge ana ing Vagrant - kita ngetik "vagrant munggah" lan nggunakake mesin virtual. Kita pengin tekan titik ing ngendi ana proyek ing Git, kita nulis "werf munggah" ing kana, lan nggawa salinan lokal proyek iki, disebarake ing mini-Kub lokal, kanthi kabeh direktori sing trep kanggo pangembangan disambungake. . Gumantung ing basa pangembangan, iki ditindakake kanthi beda, nanging, supaya pangembangan lokal bisa ditindakake kanthi gampang ing file sing dipasang.
Langkah sabanjure kanggo kita yaiku nandur modal ing penak kanggo pangembang. Kanggo nyebarake proyek kanthi cepet kanthi siji alat, gawe, push menyang Git, lan uga bakal diluncurake menyang panggung utawa tes, gumantung saka saluran pipa, banjur gunakake alat sing padha kanggo produksi. Kesatuan, penyatuan, reproduksibilitas infrastruktur saka lingkungan lokal nganti dodolan minangka titik sing penting banget kanggo kita. Nanging iki durung ana ing werf - kita mung ngrencanakake.
Nanging dalan kanggo dapp/werf tansah padha karo Kubernetes ing wiwitan. Kita nemoni masalah, ngrampungake karo solusi - kita nemokake sawetara solusi kanggo awake dhewe ing cangkang, apa wae. Banjur padha nyoba kanggo mbenerake workarounds iki, generalize lan consolidate menyang binari ing kasus iki, kang kita mung nuduhake.
Ana cara liya kanggo ndeleng kabeh crita iki, kanthi analogi.
Kubernetes minangka pigura mobil kanthi mesin. Ora ana lawang, kaca, radio, wit Natal - ora ana apa-apa. Mung pigura lan mesin. Lan ana Helm - iki setir. Kelangan - ana setir, nanging sampeyan uga kudu pin setir, rak setir, gearbox lan gembong, lan sampeyan ora bisa nindakake tanpa wong.
Ing kasus werf, iki minangka komponen liyane kanggo Kubernetes. Mung saiki ing versi alpha saka werf, contone, Helm disusun nang werf, amarga kita wis kesel nindakake dhewe. Ana akeh alasan kanggo nindakake iki, aku bakal pitutur marang kowe kanthi rinci babagan ngapa kita ngumpulake kabeh setir bebarengan karo tiller inside werf. .
Saiki werf minangka komponen sing luwih terintegrasi. We njaluk setir rampung, pin setir - Aku ora banget apik ing mobil, nanging iki pamblokiran gedhe sing wis solves sawetara cukup sudhut masalah. Kita ora perlu mbukak katalog dhewe, pilih siji bagean kanggo liyane, mikir babagan carane meneng bebarengan. Kita entuk gabungan siap sing bisa ngrampungake pirang-pirang masalah sekaligus. Nanging nang iku dibangun saka komponen mbukak sumber padha, isih nggunakake Docker kanggo Déwan, Helm kanggo sawetara fungsi, lan ana sawetara perpustakaan liyane. Iki minangka alat terpadu kanggo njaluk CI / CD kelangan metu saka kothak kanthi cepet lan trep.
Apa Kubernetes angel dijaga?
- Sampeyan pirembagan bab pengalaman sing miwiti nggunakake Kubernetes, iki pigura kanggo sampeyan, mesin, lan sampeyan bisa nyumerepi akèh iku beda ing: awak, setir, meneng ing pedal, kursi. Pitakonan muncul - sepira angel dhukungan Kubernetes kanggo sampeyan? Sampeyan duwe akeh pengalaman, pinten wektu lan sumber daya sing sampeyan gunakake kanggo ndhukung Kubernetes kanthi kapisah saka kabeh liya?
Dmitry: Iki minangka pitakonan sing angel banget lan dijawab, kita kudu ngerti apa dhukungan lan apa sing dikarepake saka Kubernetes. Mungkin sampeyan bisa mbukak?
— Sak ngertiku lan aku weruh, saiki akeh tim sing pengin nyoba Kubernetes. Saben uwong nguwasani awake dhewe, nyelehake ing dhengkul. Aku duwe perasaan yen wong ora mesthi ngerti kerumitan sistem iki.
Dmitry: Wis ngono wae.
— Sepira angel kanggo njupuk lan nginstal Kubernetes saka awal supaya produksi siap?
Dmitry: Apa sampeyan mikir yen transplantasi jantung? Aku ngerti iki pitakonan kompromi. Nggunakake scalpel lan ora nggawe kesalahan ora angel. Yen sampeyan ngandhani ngendi kanggo motong lan ngendi kanggo jahitan, prosedur dhewe ora rumit. Iku angel kanggo njamin wektu sawise wektu sing kabeh bakal bisa metu.
Nginstal Kubernetes lan supaya bisa digunakake iku gampang: cah ayu! - diinstal, ana akeh cara instalasi. Nanging apa sing kedadeyan nalika ana masalah?
Pitakonan tansah muncul - apa sing durung digatekake? Apa sing durung rampung? Parameter kernel Linux sing ora ditemtokake? Gusti, apa kita malah nyebutake wong-wong mau?! Komponen Kubernetes sing wis dikirim lan sing durung? Ewonan pitakonan muncul, lan kanggo njawab, sampeyan kudu nglampahi 15-20 taun ing industri iki.
Aku duwe conto anyar babagan topik iki sing bisa mbukak makna masalah "Apa Kubernetes angel dijaga?" Sawetara wektu kepungkur kita mikir kanthi serius apa kita kudu nyoba ngetrapake Cilium minangka jaringan ing Kubernetes.
Ayo kula nerangake apa Cilium. Kubernetes duwe macem-macem implementasine saka subsistem jaringan, lan salah sijine keren banget - Cilium. Apa tegese? Ing kernel, sawetara wektu kepungkur bisa nulis pancingan kanggo kernel, sing kanthi cara siji utawa liyane nyerang subsistem jaringan lan macem-macem subsistem liyane, lan ngidini sampeyan ngliwati potongan gedhe ing kernel.
Kernel Linux sacara historis duwe ip rout, overfilter, jembatan lan akeh komponen lawas sing umure 15, 20, 30 taun. Umumé, padha bisa, kabeh apik, nanging saiki wis numpuk kontaner, lan katon kaya menara 15 bata ing ndhuwur saben liyane, lan sampeyan ngadeg ing siji wentis - koyo aneh. Sistem iki wis dikembangake sacara historis kanthi akeh nuansa, kayata apendiks ing awak. Ing sawetara kahanan ana masalah kinerja, contone.
Ana BPF apik banget lan kemampuan kanggo nulis pancingan kanggo kernel - wong lanang nulis pancingan dhewe kanggo kernel. Paket kasebut mlebu ing kernel Linux, njupuk langsung ing input, ngolah dhewe kaya sing dikarepake tanpa jembatan, tanpa TCP, tanpa tumpukan IP - ing cendhak, ngliwati kabeh sing ditulis ing kernel Linux, banjur ngidoni iku metu menyang wadhah.
Ana apa? Kinerja sing apik banget, fitur sing apik - keren! Nanging kita ndeleng iki lan ndeleng manawa ing saben mesin ana program sing nyambung menyang API Kubernetes lan, adhedhasar data sing ditampa saka API iki, ngasilake kode C lan nyusun binari sing dimuat menyang kernel supaya pancingan kasebut bisa digunakake. ing ruang kernel.
Apa sing kedadeyan yen ana sing salah? Kita ora ngerti. Kanggo mangerteni iki, sampeyan kudu maca kabeh kode iki, ngerti kabeh logika, lan iku apik tenan carane angel iku. Nanging, ing sisih liya, ana jembatan iki, saringan net, ip rout - aku durung maca kode sumber, lan uga ora duwe 40 insinyur sing kerja ing perusahaan kita. Mungkin mung sawetara sing ngerti sawetara bagean.
Lan apa bedane? Pranyata ana ip rout, kernel Linux, lan ana alat anyar - apa bedane, kita ora ngerti siji utawa liyane. Nanging kita wedi nggunakake sing anyar - kenapa? Amarga yen alat kasebut umure 30 taun, banjur ing 30 taun, kabeh kewan omo wis ditemokake, kabeh kesalahane wis ditindakake lan sampeyan ora perlu ngerti kabeh - kerjane kaya kothak ireng lan tansah bisa digunakake. Saben uwong ngerti obeng diagnostik sing kudu dilebokake ing papan sing endi, tcpdump sing bakal ditindakake ing wayahe. Saben uwong ngerti utilitas diagnostik lan ngerti cara kerjane komponen iki ing kernel Linux - dudu cara kerjane, nanging cara nggunakake.
Lan Cilium sing apik tenan durung umur 30 taun, durung umur. Kubernetes duwe masalah sing padha, salinan. Sing Cilium wis diinstal sampurna, sing Kubernetes wis diinstal sampurna, nanging nalika soko dadi salah ing produksi, sampeyan bisa kanggo cepet ngerti ing kahanan kritis apa salah?
Nalika kita ngomong iku angel kanggo njaga Kubernetes - ora, iku gampang banget, lan ya, iku luar biasa angel. Kubernetes bisa digunakake kanthi apik, nanging kanthi nuansa milyar.
Babagan pendekatan "Aku bakal begja".
- Apa ana perusahaan ing ngendi nuansa iki meh dijamin katon? Upaminipun Yandex dumadakan nransfer kabeh layanan menyang Kubernetes, bakal ana beban gedhe ing kana.
Dmitry: Ora, iki dudu obrolan babagan beban, nanging babagan sing paling gampang. Contone, kita duwe Kubernetes, kita masang aplikasi ing kana. Kepiye carane ngerti yen bisa digunakake? Ora ana alat sing wis siap kanggo ngerti manawa aplikasi kasebut ora nabrak. Ora ana sistem siap-siap sing ngirim tandha; sampeyan kudu ngatur tandha lan saben jadwal. Lan kita nganyari Kubernetes.
Aku duwe Ubuntu 16.04. Sampeyan bisa ngomong sing iki versi lawas, nanging kita isih ing amarga iku LTS. Ana systemd, nuansa sing ora ngresiki C-kelompok. Kubernetes ngluncurake pods, nggawe C-groups, banjur mbusak pods, lan piye wae ternyata - Aku ora ngelingi rincian, nuwun - sing irisan systemd tetep. Iki ndadékaké kanggo kasunyatan sing liwat wektu sembarang mobil wiwit alon banget. Iki dudu pitakonan babagan highload. Yen polong permanen diluncurake, umpamane, yen ana Proyek Cron sing terus-terusan ngasilake polong, mesin karo Ubuntu 16.04 bakal mulai alon sawise seminggu. Bakal ana rata-rata beban sing terus-terusan amarga kasunyatane akeh klompok C wis digawe. Iki minangka masalah sing bakal ditindakake dening sapa wae sing mung nginstal Ubuntu 16 lan Kubernetes ing ndhuwur.
Ayo dadi ngomong piye wae nganyari systemd utawa liya, nanging ing kernel Linux nganti 4.16 malah lucu - nalika mbusak C-kelompok, padha bocor ing kernel lan ora bener dibusak. Mulane, sawise sasi nggarap mesin iki, bakal mokal kanggo ndeleng statistik memori kanggo hearths. Kita njupuk file, gulung ing program kasebut, lan siji file digulung sajrone 15 detik, amarga kernel butuh wektu sing suwe kanggo ngetung sejuta C-klompok ing dhewe, sing katon bakal dibusak, nanging ora ana - bocor. .
Taksih kathah ingkang alit-alit ing ngriku. Iki dudu masalah sing kadhangkala bisa ditindakake dening perusahaan raksasa ing beban sing abot - ora, iki masalah saben dina. Wong bisa urip kaya iki nganti pirang-pirang wulan - padha nginstal Kubernetes, masang aplikasi kasebut - kayane bisa digunakake. Kanggo akeh wong iki normal. Dheweke ora bakal ngerti manawa aplikasi iki bakal nabrak sakperangan alesan, dheweke ora bakal nampa tandha, nanging iki minangka norma. Sadurunge, kita manggon ing mesin virtual tanpa ngawasi, saiki kita pindhah menyang Kubernetes, uga tanpa ngawasi - apa bedane?
Pitakonan iku nalika kita lumaku ing es, kita ora bakal ngerti kekandelan sawijining kajaba kita ngukur ing advance. Akeh wong mlaku lan ora kuwatir, amarga wis mlaku sadurunge.
Saka sudut pandangku, nuansa lan kerumitan operasi sistem apa wae yaiku kanggo mesthekake yen kekandelan es cukup kanggo ngatasi masalah kita. Iki sing diomongake.
Ing IT, misale jek aku, ana akeh banget pendekatan "Aku bakal begja". Akeh wong sing nginstal piranti lunak lan nggunakake perpustakaan piranti lunak kanthi pangarep-arep bakal entuk bathi. Umumé, akeh wong sing begja. Sing mbokmenawa kok bisa.
- Saka penilaian pesimisku, katon kaya mangkene: nalika ana risiko dhuwur, lan aplikasi kudu bisa digunakake, mula butuh dhukungan saka Flaunt, bisa uga saka Red Hat, utawa sampeyan butuh tim internal dhewe khusus kanggo Kubernetes, sing wis siyap. kanggo narik mati.
Dmitry: Secara obyektif, iki. Mlebet ing crita Kubernetes kanggo tim cilik dhewe mbutuhake sawetara risiko.
Apa kita butuh wadhah?
— Apa sampeyan bisa ngandhani kepiye nyebar Kubernetes ing Rusia?
Dmitry: Aku ora duwe data iki, lan aku ora yakin wong liya wis. Kita ngomong: "Kubernetes, Kubernetes," nanging ana cara liya kanggo ndeleng masalah iki. Aku uga ora ngerti carane nyebar kontaner, nanging aku ngerti tokoh saka laporan ing Internet sing 70% kontaner diatur dening Kubernetes. Iki minangka sumber sing bisa dipercaya kanggo sampel sing cukup gedhe ing saindenging jagad.
Banjur pitakonan liyane - apa kita butuh wadhah? Perasaan pribadi lan posisi umume perusahaan Flant yaiku Kubernetes minangka standar de facto.
Ora bakal ana apa-apa kajaba Kubernetes.
Iki minangka game-changer mutlak ing bidang manajemen infrastruktur. Mung Absolute - iku, ora luwih Ansible, Chef, mesin virtual, Terraform. Aku ora ngomong babagan cara farm kolektif lawas. Kubernetes minangka pangowahan mutlak, lan saiki mung bakal kaya iki.
Cetha yen kanggo sawetara butuh sawetara taun, lan kanggo wong liya sawetara dekade, kanggo ngerteni iki. Aku ora mangu-mangu yen ora ana apa-apa kajaba Kubernetes lan tampilan anyar iki: kita ora ngrusak sistem operasi maneh, nanging nggunakake infrastruktur minangka kode, mung ora nganggo kode, nanging nganggo yml - prasarana sing diterangake kanthi deklaratif. Aku duwe perasaan sing bakal tansah kaya iki.
- Tegese, perusahaan-perusahaan sing durung ngalih menyang Kubernetes mesthi bakal ngalih utawa tetep ora lali. Aku ngerti sampeyan bener?
Dmitry: Iki uga ora sakabehe bener. Contone, yen kita duwe tugas kanggo mbukak server DNS, mula bisa diluncurake ing FreeBSD 4.10 lan bisa digunakake kanthi sampurna sajrone 20 taun. Mung kerja lan sing. Mungkin ing 20 taun ana sing kudu dianyari sapisan. Yen kita ngomong babagan piranti lunak ing format sing diluncurake lan bisa digunakake nganti pirang-pirang taun tanpa nganyari, tanpa owah-owahan, mula mesthi ora ana Kubernetes. Dheweke ora dibutuhake ing kana.
Kabeh sing ana gandhengane karo CI / CD - ing ngendi wae Pangiriman Terus-terusan dibutuhake, ing ngendi sampeyan kudu nganyari versi, nggawe owah-owahan aktif, ing ngendi wae sampeyan kudu mbangun toleransi kesalahan - mung Kubernetes.
Babagan microservices
- Kene aku duwe disonansi tipis. Kanggo nggarap Kubernetes, sampeyan butuh dhukungan eksternal utawa internal - iki minangka titik pisanan. Sareh, nalika kita mung miwiti pembangunan, kita wiwitan cilik, kita durung duwe apa-apa, pembangunan kanggo Kubernetes utawa arsitektur microservice ing umum bisa dadi angel lan ora tansah ekonomi sabdho. Aku kasengsem ing mratelakake panemume - apa wiwitan kudu langsung miwiti nulis kanggo Kubernetes saka ngeruk, utawa isih bisa nulis monolit, lan banjur mung teka Kubernetes?
Dmitry: Pitakonan keren. Aku duwe pirembagan bab microservices Kaping pirang-pirang aku nemoni wong sing nyoba palu kuku nganggo mikroskop. Pendekatan kasebut bener; kita dhewe ngrancang piranti lunak internal kanthi cara iki. Nanging nalika sampeyan nindakake iki, sampeyan kudu ngerti kanthi jelas apa sing sampeyan lakoni. Tembung sing paling aku sengit babagan layanan mikro yaiku "mikro." Sacara historis, tembung iki asalé saka kono, lan sakperangan alesan wong mikir yen mikro cilik banget, kurang saka milimeter, kaya mikrometer. Iki salah.
Contone, ana monolit sing ditulis dening 300 wong, lan saben wong sing melu pembangunan ngerti yen ana masalah, lan kudu dipecah dadi potongan mikro - kira-kira 10 lembar, saben ditulis dening 30 wong. ing versi minimal. Iki penting, perlu lan keren. Nanging nalika wiwitan teka kanggo kita, ngendi 3 wong lanang banget kelangan lan bakat wrote 60 microservices ing dhengkul, saben-saben aku nggoleki Corvalol.
Iku misale jek kula iki wis ngandika bab ewu kaping - kita entuk monolith mbagekke ing siji wangun utawa liyane. Iki ora ekonomi sabdho, iku banget angel ing umum ing kabeh. Aku wis weruh iki kaping pirang-pirang sing tenan babras kula, supaya aku terus kanggo pirembagan bab iku.
Kanggo pitakonan awal, ana konflik antarane kasunyatan sing, ing tangan siji, Kubernetes medeni kanggo nggunakake, amarga ora cetha apa sing bisa break ana utawa ora bisa, ing tangan liyane, iku cetha sing kabeh dadi ana. lan ora ana apa-apa kajaba Kubernetes sing bakal ana. Wangsulan- nimbang jumlah keuntungan sing teka, jumlah tugas sing bisa ditanggulangi. Iki ana ing sisih siji saka skala. Ing sisih liya, ana risiko sing ana gandhengane karo downtime utawa nyuda wektu nanggepi, tingkat kasedhiyan - kanthi nyuda indikator kinerja.
Punika - salah siji kita mindhah cepet, lan Kubernetes ngidini kita nindakake akeh iku luwih cepet lan luwih apik, utawa kita nggunakake dipercaya, solusi wektu-dites, nanging obah luwih alon. Iki minangka pilihan sing kudu ditindakake saben perusahaan. Sampeyan bisa nganggep minangka dalan ing alas - nalika sampeyan mlaku pisanan, sampeyan bisa ketemu ula, macan utawa luak edan, lan yen sampeyan mlaku ping 10, sampeyan wis ngidak dalan, dibusak. cabang lan lumaku luwih gampang. Saben wektu dalan dadi luwih amba. Banjur iku dalan aspal, lan mengko boulevard ayu.
Kubernetes ora mandheg. Pitakonan maneh: Kubernetes, ing tangan siji, yaiku 4-5 binari, ing sisih liya, iku kabeh ekosistem. Iki minangka sistem operasi sing ana ing mesin kita. Apa iki? Ubuntu utawa Curios? Iki kernel Linux, akeh komponen tambahan. Kabeh iki ing kene, ula siji dibuwang metu saka dalan, pager digawe ing kono. Kubernetes berkembang kanthi cepet lan dinamis, lan volume risiko, volume sing ora dingerteni saya suda saben wulan lan, kanthi mangkono, timbangan kasebut diimbangi maneh.
Njawab pitakonan apa sing kudu ditindakake wiwitan, aku bakal ujar - teka ing Flaunt, mbayar 150 ewu rubel lan entuk layanan gampang DevOps turnkey. Yen sampeyan minangka wiwitan cilik karo sawetara pangembang, iki bisa digunakake. Tinimbang nyewa DevOps dhewe, sing kudu sinau carane ngatasi masalah lan mbayar gaji saiki, sampeyan bakal entuk solusi turnkey kanggo kabeh masalah. Ya, ana sawetara kekurangan. Kita, minangka outsourcing, ora bisa melu lan nanggapi kanthi cepet kanggo owah-owahan. Nanging kita duwe akeh keahlian lan praktik sing wis siap. Kita njamin yen ing kahanan apa wae, mesthi bakal cepet ngerteni lan ngunggahake Kubernetes saka wong mati.
Aku banget nyaranake outsourcing kanggo wiwitan lan bisnis mapan nganti ukuran ngendi sampeyan bisa ngaturake tim 10 wong kanggo operasi, amarga yen ora ana titik. Iku mesthi ndadekake pangertèn kanggo outsource iki.
Babagan Amazon lan Google
— Apa host saka solusi saka Amazon utawa Google bisa dianggep minangka outsource?
Dmitry: Ya, mesthi, iki solves sawetara masalah. Nanging maneh ana nuansa. Sampeyan isih kudu ngerti carane nggunakake. Contone, ana sewu perkara cilik ing karya Amazon AWS: Load Balancer kudu digawe panas utawa panjaluk kudu ditulis luwih dhisik yen "wong lanang, kita bakal nampa lalu lintas, anget Load Balancer kanggo kita!" Sampeyan kudu ngerti nuansa kasebut.
Nalika sampeyan nguripake kanggo wong sing spesialisasine iki, sampeyan njaluk meh kabeh iku khas ditutup. Saiki kita duwe 40 insinyur, ing pungkasan taun bisa uga ana 60 - kita mesthi nemoni kabeh iki. Sanajan kita nemoni masalah iki maneh ing sawetara proyek, kita cepet-cepet takon lan ngerti carane ngatasi.
Mbokmenawa jawabane - mesthi, crita sing di-host nggawe sawetara bagean luwih gampang. Pitakonan yaiku apa sampeyan siyap dipercaya hoster kasebut lan apa bakal ngrampungake masalah sampeyan. Amazon lan Google wis rampung kanthi apik. Kanggo kabeh kasus kita - persis. Kita ora duwe pengalaman sing luwih positif. Kabeh maya liyane sing kita coba nggarap nggawe akeh masalah - Ager, lan kabeh sing ana ing Rusia, lan kabeh jinis OpenStack ing implementasine beda: Headster, Overage - apa wae sing dikarepake. Kabeh mau nggawe masalah sing sampeyan ora pengin ngrampungake.
Mulane, jawabane ya, nanging, nyatane, ora akeh solusi sing di-host sing diwasa.
Sapa sing butuh Kubernetes?
— Nanging, sapa sing butuh Kubernetes? Sapa sing kudu ngalih menyang Kubernetes, sing dadi klien Flaunt khas sing khusus kanggo Kubernetes?
Dmitry: Iki minangka pitakonan sing menarik, amarga saiki, sawise Kubernetes, akeh wong sing teka menyang kita: "Wong lanang, kita ngerti yen sampeyan nindakake Kubernetes, lakoni kanggo kita!" Kita mangsuli: "Tuan-tuan, kita ora nindakake Kubernetes, kita nggawe prod lan kabeh sing ana gandhengane." Amarga saiki mung ora bisa nggawe produk tanpa nindakake kabeh CI / CD lan kabeh crita iki. Saben uwong wis pindhah saka divisi sing kita duwe pembangunan kanthi pembangunan, lan banjur eksploitasi kanthi eksploitasi.
Klien kita ngarepake macem-macem, nanging saben wong ngenteni sawetara keajaiban sing duwe masalah tartamtu, lan saiki - hop! - Kubernetes bakal ngatasi. Wong pracaya marang mukjijat. Ing pikirane, dheweke ngerti yen ora ana mukjizat, nanging ing jiwane padha ngarep-arep - apa yen Kubernetes iki saiki bakal ngrampungake kabeh kanggo kita, dheweke ngomong akeh babagan! Dumadakan dheweke saiki - wahing! - lan peluru perak, wahing! - lan kita duwe 100% uptime, kabeh pangembang bisa ngeculake apa wae sing entuk produksi kaping 50, lan ora nabrak. Umumé, mukjijat!
Nèk wong-wong kuwi teka, awaké dhéwé kandha, ”Nuwun sewu, nanging mboten wonten mukjijatipun.” Supaya sehat, sampeyan kudu mangan kanthi apik lan olahraga. Kanggo duwe produk sing dipercaya, kudu digawe kanthi andal. Kanggo duwe CI / CD trep, sampeyan kudu nggawe kaya iki. Iku akeh karya sing kudu ditindakake.
Njawab pitakonan sapa sing butuh Kubernetes - ora ana sing butuh Kubernetes.
Sawetara wong duwe salah paham yen dheweke butuh Kubernetes. Wong butuh, dheweke duwe kabutuhan sing jero kanggo mandheg mikir, sinau, lan kasengsem ing kabeh masalah infrastruktur lan masalah aplikasi. Dheweke pengin aplikasi mung bisa digunakake lan mung disebarake. Kanggo wong-wong mau, Kubernetes minangka pangarep-arep supaya bisa mandheg ngrungokake crita yen "kita ngapusi ana," utawa "ora bisa diluncurake," utawa liya-liyane.
Direktur teknis biasane teka menyang kita. Dheweke takon rong perkara: ing tangan siji, menehi fitur, ing sisih liyane, stabilitas. Disaranake sampeyan njupuk dhewe lan nindakake. Peluru perak, utawa luwih dilapisi perak, yaiku sampeyan bakal mandheg mikir babagan masalah kasebut lan mbuwang wektu. Sampeyan bakal duwe wong khusus sing bakal nutup masalah iki.
Tembung sing kita utawa wong liya mbutuhake Kubernetes ora bener.
Admin pancen butuh Kubernetes, amarga iki dolanan sing menarik banget sing bisa dimainake lan dimainake. Ayo dadi jujur - kabeh wong seneng dolanan. Kita kabeh bocah nang endi wae, lan nalika ndeleng sing anyar, kita pengin muter. Kanggo sawetara, iki wis pundung, contone, ing administrasi, amarga padha wis muter cukup lan wis kesel kanggo titik sing padha mung ora pengin. Nanging iki ora rampung ilang kanggo sapa wae. Contone, yen aku wis kesel karo dolanan ing bidang administrasi sistem lan DevOps nganti suwe, mula aku isih seneng dolanan, aku isih tuku sing anyar. Kabeh wong, salah siji cara utawa liyane, isih pengin sawetara jinis dolanan.
Ora perlu muter produksi. Apa wae sing dakkarepake supaya ora ditindakake lan apa sing dakdeleng saiki: "Oh, dolanan anyar!" - padha mlayu tuku, tuku lan: "Ayo digawa menyang sekolah saiki lan nuduhake menyang kabeh kanca." Aja ngono. Nyuwun pangapunten, anak-anakku lagi gedhe, aku terus-terusan ndeleng apa-apa ing bocah-bocah, sok dong mirsani ing awake dhewe, banjur umumake marang wong liya.
Wangsulan pungkasan yaiku: sampeyan ora butuh Kubernetes. Sampeyan kudu ngatasi masalah sampeyan.
Sing bisa digayuh yaiku:
- prod ora tiba;
- malah yen nyoba kanggo tiba, kita ngerti bab iku ing advance, lan kita bisa sijine soko ing;
- kita bisa ngganti ing kacepetan ing bisnis kita mbutuhake, lan kita bisa nindakake iku trep, iku ora nimbulaké kita masalah.
Ana rong kabutuhan nyata: linuwih lan dinamisme / keluwesan rollout. Saben uwong sing saiki nindakake sawetara jinis proyek IT, ora ketompo apa jenis bisnis - alus kanggo easing donya, lan sing mangerténi iki, kudu ngatasi kabutuhan iki. Kubernetes kanthi pendekatan sing bener, kanthi pangerten sing bener lan pengalaman sing cukup ngidini sampeyan ngatasi.
Babagan tanpa server
- Yen katon sethitik luwih menyang mangsa, banjur nyoba kanggo ngatasi masalah anané ngelu karo infrastruktur, kanthi kacepetan rollout lan kacepetan owah-owahan aplikasi, solusi anyar katon, contone, serverless. Apa sampeyan rumangsa potensial ing arah iki lan, ayo ngomong, bebaya kanggo Kubernetes lan solusi sing padha?
Dmitry: Ing kene kita kudu ujar maneh yen aku dudu wong sing ndeleng ngarep lan ujar - bakal kaya mangkene! Senajan aku mung nindakake bab sing padha. Aku katon ing sikil lan ndeleng Bunch saka masalah ana, contone, carane transistor bisa ing komputer. Iku lucu, ta? Kita nemoni sawetara kewan omo ing CPU.
Nggawe serverless cukup dipercaya, murah, efisien lan trep, ngrampungake kabeh masalah ekosistem. Ing kene aku setuju karo Elon Musk yen planet kapindho dibutuhake kanggo nggawe toleransi kesalahan kanggo manungsa. Sanajan aku ora ngerti apa sing diomongake, aku ngerti yen aku ora siap mabur menyang Mars lan ora bakal kelakon sesuk.
Kanthi tanpa server, jelas yen iki minangka perkara sing bener kanthi ideologis, kaya toleransi kesalahan kanggo manungsa - duwe rong planet luwih apik tinimbang siji. Nanging kepiye carane saiki? Ngirim siji ekspedisi ora masalah yen sampeyan musataken efforts ing. Ngirim sawetara ekspedisi lan mapan sawetara ewu wong ing kana, aku mikir, uga nyata. Nanging kanggo nggawe kabeh fault-tolerant supaya setengah saka manungsa manggon ing kono, misale jek kula saiki mokal, ora dianggep.
Kanthi tanpa server siji-siji: perkara kasebut keren, nanging adoh saka masalah 2019. Nyedhaki 2030 - ayo padha ndeleng. Aku ora mangu-mangu yen kita bakal urip, mesthi bakal urip (baleni sadurunge turu), nanging saiki kita kudu ngrampungake masalah liyane. Iku kaya pracaya ing dongeng poni Pelangi. Ya, sawetara persen kasus ditanggulangi, lan ditanggulangi kanthi sampurna, nanging kanthi subyektif, tanpa server minangka pelangi ... Kanggo kula, topik iki adoh banget lan ora bisa dingerteni. Aku durung siap ngomong. Ing 2019, sampeyan ora bisa nulis aplikasi siji tanpa server.
Carane Kubernetes bakal berkembang
— Nalika kita maju menyang masa depan sing adoh banget, kepiye carane Kubernetes lan ekosistem ing saubengé bakal berkembang?
Dmitry: Aku wis mikir babagan iki akeh lan aku duwe jawaban sing jelas. Sing pertama yaiku statefull - sawise kabeh, stateless luwih gampang ditindakake. Kubernetes pisanan nandur modal luwih akeh babagan iki, kabeh diwiwiti. Stateless dianggo meh sampurna ing Kubernetes, ana mung apa-apa kanggo sambat. Isih akeh masalah, utawa luwih, nuansa. Kabeh sing ana wis apik kanggo kita, nanging kita. Bakal njupuk paling sethithik saperangan taun kanggo iki bisa kanggo kabeh wong. Iki dudu indikator sing diwilang, nanging perasaanku saka sirahku.
Singkatnya, statefull kudu - lan bakal - berkembang banget, amarga kabeh aplikasi kita nyimpen status; ora ana aplikasi stateless. Iki minangka ilusi; sampeyan mesthi butuh sawetara jinis database lan liya-liyane. Statefull babagan mbenerake kabeh sing bisa, ndandani kabeh kewan omo, nambah kabeh masalah sing saiki diadhepi - ayo diarani adopsi.
Tingkat sing ora dingerteni, tingkat masalah sing ora ditanggulangi, tingkat kemungkinan nemoni sesuatu bakal mudhun kanthi signifikan. Iki crita penting. Lan operator - kabeh sing ana hubungane karo kodifikasi logika administrasi, logika kontrol supaya entuk layanan sing gampang: Layanan gampang MySQL, layanan gampang RabbitMQ, layanan gampang Memcache - umume, kabeh komponen iki sing kudu dijamin bisa digunakake. kothak. Iki mung solves pain sing kita pengin database, nanging kita ora pengin ngatur, utawa kita pengin Kubernetes, nanging kita ora pengin ngatur.
Iki crita pangembangan operator ing siji utawa liyane wangun bakal penting ing sawetara taun sabanjuré.
Aku ease saka nggunakake kudu nambah nemen - kothak bakal dadi liyane lan liyane ireng, liyane lan liyane dipercaya, karo liyane lan liyane knobs prasaja.
Aku tau ngrungokake wawancara lawas karo Isaac Asimov saka 80s ing YouTube ing Saturday Night Live - program kaya Urgant, mung menarik. Dheweke takon babagan masa depan komputer. Dheweke ujar manawa masa depan ana ing kesederhanaan, kaya radio. Panrima radio wiwitane minangka perkara sing rumit. Kanggo nyekel gelombang, sampeyan kudu nguripake tombol kanggo 15 menit, nguripake tusuk sate lan umume ngerti carane kabeh bisa, ngerti fisika transmisi gelombang radio. Akibaté, mung ana siji tombol ing radio.
Saiki ing 2019 radio apa? Ing mobil, panrima radio nemokake kabeh ombak lan jeneng stasiun. Fisika proses kasebut ora owah sajrone 100 taun, nanging gampang digunakake. Saiki, lan ora mung saiki, ing taun 1980, nalika ana wawancara karo Azimov, kabeh wong nggunakake radio lan ora ana sing mikir babagan cara kerjane. Iku tansah bisa - sing diwenehi.
Azimov banjur ujar manawa bakal padha karo komputer - ease saka nggunakake bakal nambah. Nalika ing taun 1980 sampeyan kudu dilatih kanggo mencet tombol ing komputer, sing ora bakal kedadeyan ing mangsa ngarep.
Aku duwe perasaan sing karo Kubernetes lan infrastruktur uga bakal nambah ageng ing ease saka nggunakake. Iki, miturut pendapatku, jelas - dumunung ing permukaan.
Apa sing kudu ditindakake karo insinyur?
— Apa banjur bakal kelakon kanggo engineers lan administrator sistem sing ndhukung Kubernetes?
Dmitry: Apa sing kedadeyan karo akuntan sawise kedadeyan 1C? Kira-kira padha. Sadurunge iki, padha diitung ing kertas - saiki ing program. Produktivitas tenaga kerja saya tambah akeh, nanging tenaga kerja dhewe ora ilang. Yen sadurunge njupuk 10 engineers kanggo meneng ing bohlam lampu, saiki siji bakal cukup.
Jumlah piranti lunak lan jumlah tugas, misale jek kula, saiki saya tambah kanthi tingkat sing luwih cepet tinimbang DevOps anyar sing katon lan efisiensi saya tambah. Ana kekurangan tartamtu ing pasar saiki lan bakal tahan suwe. Mengko, kabeh bakal bali menyang sawetara normalitas, ing ngendi efisiensi kerja bakal saya tambah, bakal ana serverless liyane, neuron bakal dipasang ing Kubernetes, sing bakal milih kabeh sumber daya sing dibutuhake, lan umume bakal. nindakake kabeh dhewe, kaya sing kudu ditindakake - wong mung mandheg lan ora ngganggu.
Nanging ana wong sing isih kudu nggawe keputusan. Cetha yen tingkat kualifikasi lan spesialisasi wong iki luwih dhuwur. Saiki ing jurusan akuntansi ora perlu 10 karyawan sing nyimpen buku supaya tangane ora kesel. Iku mung ora perlu. Akeh dokumen kanthi otomatis dipindai lan dikenali dening sistem manajemen dokumen elektronik. Salah kepala akuntan pinter cukup, wis karo skills luwih akeh, karo pangerten apik.
Umumé, iki cara kanggo pindhah ing kabeh industri. Iku padha karo mobil: sadurunge, mobil teka karo mekanik lan telung pembalap. Saiki, nyopir mobil minangka proses sing prasaja sing kita kabeh melu saben dina. Ora ana sing ngira yen mobil iku rumit.
DevOps utawa rekayasa sistem ora bakal ilang - karya lan efisiensi tingkat dhuwur bakal mundhak.
- Aku uga krungu idea menarik sing karya bener bakal nambah.
Dmitry: Mesthi, satus persen! Amarga jumlah piranti lunak sing kita tulis saya tambah akeh. Jumlah masalah sing diatasi nganggo piranti lunak saya tambah akeh. Gunggunge nyambut gawe. Saiki pasar DevOps wis panas banget. Iki bisa dideleng ing pangarepan gaji. Kanthi cara sing apik, tanpa njlentrehake, mesthine ana junior sing pengin X, sing tengah pengin 1,5X, lan senior sing pengin 2X. Lan saiki, yen sampeyan ndeleng pasar gaji Moscow DevOps, junior pengin saka X nganti 3X lan senior pengin saka X nganti 3X.
Ora ana sing ngerti pira regane. Tingkat gaji diukur kanthi kapercayan sampeyan - omah gila sing lengkap, jujur, pasar sing panas banget.
Mesthi, kahanan iki bakal ganti banget - sawetara kejenuhan kudu kedadeyan. Iki ora kedadeyan karo pangembangan piranti lunak - sanajan kasunyatane saben wong butuh pangembang, lan kabeh wong butuh pangembang sing apik, pasar ngerti sapa sing pantes - industri wis mapan. Ora kaya ngono karo DevOps saiki.
- Saka apa aku krungu, Aku rampung sing administrator sistem saiki kudu padha sumelang ing kakehan, nanging wektu kanggo upgrade skills lan nyiapake kanggo kasunyatan sing sesuk bakal ana liyane karya, nanging bakal luwih qualified.
Dmitry: Satus persen. Umumé, kita urip ing 2019 lan aturan urip yaiku: sinau seumur hidup - kita sinau ing saindhenging gesang kita. Kayane aku saiki kabeh wis ngerti lan ngrasakake iki, nanging ora cukup ngerti - sampeyan kudu nindakake. Saben dina kita kudu ganti. Yen kita ora nindakake iki, banjur cepet utawa mengko kita bakal dropped ing sela-sela profesi.
Disiapake kanggo puteran 180 derajat sing cetha. Aku ora ngilangi kahanan sing ana owah-owahan kanthi radikal, ana sing anyar - kedadeyan. Hop! - lan kita saiki tumindak beda. Penting kanggo disiapake lan ora kuwatir. Bisa uga sesuk kabeh sing daklakoni bakal dadi ora perlu - ora ana apa-apa, aku wis sinau kabeh urip lan siap sinau liyane. Iku ora masalah. Ora perlu wedi karo keamanan kerja, nanging sampeyan kudu siyap terus sinau sing anyar.
Wishes lan menit saka iklan
- Apa sampeyan duwe kepinginan?
Dmitry: Ya, aku duwe sawetara kepinginan.
First lan mercantile - langganan . Para pamaca sing ditresnani, bukak YouTube lan langganan saluran kita. Kira-kira sewulan, kita bakal miwiti ekspansi aktif ing layanan video. Kita bakal duwe akeh konten pendidikan babagan Kubernetes, mbukak lan maneka warna: saka praktis, nganti laboratorium, nganti teoretis dhasar sing jero lan cara nggunakake Kubernetes ing tingkat prinsip lan pola.
Kapindho mercantile wish - pindhah menyang lan sijine lintang amarga kita feed ing wong. Yen sampeyan ora menehi kita lintang, kita ora bakal duwe apa-apa kanggo mangan. Iku kaya mana ing game komputer. Kita nindakake soko, kita nindakake, kita nyoba, wong ngandika sing iki pit elek, wong sing kabeh rampung salah, nanging kita terus lan tumindak pancen jujur. Kita ndeleng masalah, ngrampungake lan nuduhake pengalaman. Mulane, wenehana lintang, iku ora bakal ilang saka sampeyan, nanging bakal teka kanggo kita, amarga kita mangan wong-wong mau.
Katelu, penting, lan ora ana maneh kepinginan dagang - mandheg percaya ing dongeng. Sampeyan profesional. DevOps minangka profesi sing serius lan tanggung jawab. Mungkasi dolanan ing papan kerja. Ayo klik kanggo sampeyan lan sampeyan bakal ngerti. Bayangna sampeyan teka ing rumah sakit, lan ing kana dhokter lagi nyobi sampeyan. Aku ngerti manawa iki bisa nyerang wong liya, nanging, sing paling mungkin, iki dudu babagan sampeyan, nanging babagan wong liya. Marang wong liya uga mandheg. Iki pancen ngrusak urip kanggo kita kabeh - akeh sing wiwit nganggep operasi, admin lan DevOps minangka wong lanang sing wis rusak maneh. Iki "rusak" paling asring amarga kasunyatan sing kita tindak kanggo muter, lan ora katon karo eling kadhemen sing iki carane iku, lan sing carane iku.
Iki ora ateges sampeyan ora kudu nyoba. Kita kudu eksperimen, kita nindakake dhewe. Jujur, kita dhewe kadhangkala main game - iki mesthi ala banget, nanging ora ana manungsa sing asing kanggo kita. Ayo ngumumake 2019 minangka taun eksperimen sing serius lan dipikirake kanthi apik, lan dudu game ing produksi. Mbokmenawa mangkono.
- Matur nuwun kanthi sanget!
Dmitry: Matur nuwun, Vitaly, kanggo wektu lan kanggo wawancara. Para maos ingkang minulya, matur nuwun sanget menawi ndadak tekan titik punika. Mugi sing kita nggawa sampeyan ing paling saperangan saka pikirane.
Ing wawancara, Dmitry ndemek babagan masalah werf. Saiki iki minangka piso Swiss universal sing ngrampungake meh kabeh masalah. Nanging ora mesthi. On ing festival Dmitry Stolyarov bakal ngandhani babagan alat iki kanthi rinci. ing laporan bakal ana kabeh: masalah lan nuansa didhelikake saka Kubernetes, opsi kanggo ngatasi kangelan iki lan implementasine saiki werf ing rinci. Gabung ing 27 lan 28 Mei, kita bakal nggawe alat sing sampurna.
Source: www.habr.com