Kubernetes minangka alat sing apik kanggo mbukak wadhah Docker ing lingkungan produksi kluster. Nanging, ana masalah sing Kubernetes ora bisa ngatasi. Kanggo panyebaran produksi sing kerep, kita butuh panyebaran Biru/Ijo kanthi otomatis kanggo ngindhari downtime ing proses kasebut, sing uga kudu nangani panjalukan HTTP eksternal lan nindakake SSL offloads. Iki mbutuhake integrasi karo load balancer kayata ha-proxy. Tantangan liyane yaiku skala semi-otomatis saka kluster Kubernetes dhewe nalika mlaku ing lingkungan maya, umpamane sebagian skala kluster mudhun ing wayah wengi.
Nalika Kubernetes ora duwe fitur iki metu saka kothak, iku nyedhiyani API sing bisa digunakake kanggo ngatasi masalah padha. Piranti kanggo penyebaran otomatis Biru/Ijo lan skala saka kluster Kubernetes dikembangake minangka bagΓ©an saka proyek Cloud RTI, sing digawe adhedhasar open-source.
Artikel iki, transkrip video, nuduhake sampeyan carane nyiyapake Kubernetes bebarengan karo komponen open source liyane kanggo nggawe lingkungan sing siap produksi sing nampa kode saka git commit tanpa downtime ing produksi.
Dadi, yen sampeyan duwe akses menyang aplikasi saka jagad njaba, sampeyan bisa miwiti nyiyapake otomatisasi kanthi lengkap, yaiku, nggawa menyang panggung ing ngendi sampeyan bisa nindakake git commit lan priksa manawa git commit iki rampung ing produksi. Alami, nalika ngetrapake langkah-langkah kasebut, nalika ngetrapake penyebaran, kita ora pengin nemoni downtime. Dadi, otomatisasi apa wae ing Kubernetes diwiwiti kanthi API.
Kubernetes dudu alat sing bisa digunakake kanthi produktif metu saka kothak. Mesthi wae, sampeyan bisa nindakake, nggunakake kubectl lan liya-liyane, nanging isih API minangka perkara sing paling menarik lan migunani babagan platform iki. Kanthi nggunakake API minangka sakumpulan fungsi, sampeyan bisa ngakses meh kabeh sing pengin ditindakake ing Kubernetes. kubectl dhewe uga nggunakake REST API.
Iki REST, supaya sampeyan bisa nggunakake basa utawa alat apa wae kanggo nggarap API iki, nanging urip sampeyan bakal luwih gampang dening perpustakaan khusus. Timku nulis 2 perpustakaan kuwi: siji kanggo Java/OSGi lan siji kanggo Go. Sing nomer loro ora asring digunakake, nanging ing kasus apa wae sampeyan duwe barang sing migunani. Iki minangka proyek sumber terbuka sing dilisensi sebagian. Ana akeh perpustakaan kanggo macem-macem basa, supaya sampeyan bisa milih sing paling cocog karo sampeyan.
Dadi, sadurunge sampeyan miwiti ngotomatisasi penyebaran sampeyan, sampeyan kudu mesthekake yen proses kasebut ora bakal ngalami downtime. Contone, tim kita nganakake penyebaran produksi nalika tengah dina nalika wong nggunakake aplikasi paling akeh, mula penting kanggo ngindhari wektu tundha ing proses iki. Kanggo ngindhari downtime, 2 cara digunakake: penyebaran biru / ijo utawa nganyari rolling. Ing kasus terakhir, yen sampeyan duwe 5 replika saka aplikasi mlaku, padha dianyari sequentially siji sawise liyane. Cara iki dianggo apik, nanging ora cocok yen sampeyan duwe versi beda saka aplikasi mlaku bebarengan sak proses penyebaran prajurit. Ing kasus iki, sampeyan bisa nganyari antarmuka panganggo nalika backend mlaku versi lawas, lan aplikasi bakal mandheg digunakake. Mulane, saka sudut pandang pemrograman, kerja ing kahanan kaya mengkono iku cukup angel.
Iki minangka salah sawijining sebab kenapa kita luwih seneng nggunakake penyebaran biru/ijo kanggo ngotomatisasi panyebaran aplikasi kita. Kanthi cara iki, sampeyan kudu mesthekake yen mung siji versi aplikasi sing aktif ing siji wektu.
Mekanisme penyebaran biru / ijo katon kaya iki. Kita nampa lalu lintas kanggo aplikasi kita liwat ha-proxy, sing nerusake menyang replika aplikasi saka versi sing padha.
Nalika penyebaran anyar digawe, kita nggunakake Deployer, kang diwenehi komponen anyar lan deploys versi anyar. Nganggo versi anyar saka aplikasi tegese replika anyar "diunggahake", sawise replika versi anyar iki diluncurake ing pod anyar sing kapisah. Nanging, ha-proxy ora ngerti apa-apa babagan dheweke lan durung ngirim beban kerja menyang dheweke.
Mulane, pisanan kabeh, perlu kanggo nindakake mriksa kinerja versi anyar saka mriksa kesehatan kanggo mesthekake yen replika siap kanggo layanan mbukak.
Kabeh komponen penyebaran kudu ndhukung sawetara bentuk pemeriksaan kesehatan. Iki bisa dadi mriksa telpon HTTP sing prasaja banget, nalika sampeyan nampa kode kanthi status 200, utawa mriksa luwih jero, ing ngendi sampeyan mriksa sambungan replika karo database lan layanan liyane, stabilitas sambungan lingkungan dinamis. , lan apa kabeh diwiwiti lan bisa digunakake kanthi bener. Proses iki bisa cukup rumit.
Sawise sistem verifikasi yen kabeh replika sing dianyari bisa digunakake, Deployer bakal nganyari konfigurasi lan ngliwati confd sing bener, sing bakal ngatur ulang ha-proxy.
Mung sawise iki, lalu lintas bakal diarahake menyang pod kanthi replika versi anyar, lan pod lawas bakal ilang.
Mekanisme iki dudu fitur Kubernetes. Konsep panyebaran Biru/ijo wis cukup suwe lan mesthi nggunakake penyeimbang beban. Pisanan, sampeyan ngarahake kabeh lalu lintas menyang versi lawas aplikasi, lan sawise nganyari, sampeyan kudu nransfer menyang versi anyar. Prinsip iki digunakake ora mung ing Kubernetes.
Saiki aku bakal ngenalake sampeyan komponen penyebaran anyar - Deployer, sing nindakake pemeriksaan kesehatan, ngonfigurasi ulang proxy, lan liya-liyane. Iki minangka konsep sing ora ditrapake kanggo jagad njaba lan ana ing Kubernetes. Aku bakal nuduhake sampeyan carane nggawe konsep Deployer dhewe nggunakake alat open-source.
Dadi, sing pertama ditindakake Deployer yaiku nggawe pengontrol replikasi RC nggunakake API Kubernetes. API iki nggawe pod lan layanan kanggo penyebaran luwih lanjut, yaiku, nggawe kluster anyar kanggo aplikasi kita. Sanalika RC wis nggawe percoyo sing tiron wis diwiwiti, bakal nindakake mriksa Kesehatan ing fungsi sing. Kanggo nindakake iki, Deployer nggunakake perintah GET /kesehatan. Iku nganggo komponen scan cocok lan mriksa kabeh unsur sing ndhukung operasi saka kluster.
Sawise kabeh pod wis nglaporake kesehatane, Deployer nggawe unsur konfigurasi anyar - panyimpenan sing disebarake etcd, sing digunakake sacara internal dening Kubernetes, kalebu nyimpen konfigurasi load balancer. Kita nulis data menyang etcd, lan alat cilik sing diarani confd monitor etcd kanggo data anyar.
Yen ndeteksi owah-owahan ing konfigurasi awal, iku njedulake file setelan anyar lan nransfer menyang ha-proxy. Ing kasus iki, ha-proxy urip maneh tanpa kelangan sambungan lan alamat beban menyang layanan anyar sing ngidini versi anyar aplikasi kita bisa digunakake.
Kaya sing sampeyan ngerteni, sanajan akeh komponen, ora ana sing rumit ing kene. Sampeyan mung kudu mbayar manungsa waΓ© liyane kanggo API lan etc. Aku pengin ngandhani babagan panyebar open-source sing kita gunakake dhewe - Amdatu Kubernetes Deployer.
Iku alat kanggo ngatur penyebaran Kubernetes lan nduweni fitur ing ngisor iki:
- Penyebaran Biru/Ijo;
- nyetel imbangan beban eksternal;
- manajemen deskriptor penyebaran;
- ngatur penyebaran nyata;
- mriksa fungsi pamriksa kesehatan sajrone penyebaran;
- implementasi variabel lingkungan menyang pods.
Deployer iki dibangun ing ndhuwur API Kubernetes lan nyedhiyakake API REST kanggo ngatur gagang lan panyebaran, uga API Websocket kanggo streaming log sajrone proses penyebaran.
Nempatno data konfigurasi load balancer menyang etcd, supaya sampeyan ora kudu nggunakake ha-proxy karo out-of-the-box support, nanging gampang nggunakake file konfigurasi load balancer dhewe. Amdatu Deployer ditulis ing Go, kaya Kubernetes dhewe, lan dilisensi dening Apache.
Sadurunge miwiti nggunakake versi deployer iki, aku nggunakake deskriptor penyebaran ing ngisor iki, sing nemtokake paramèter sing dibutuhake.
Salah sawijining parameter penting saka kode iki yaiku ngaktifake gendera "useHealthCheck". Kita kudu nemtokake manawa priksa kewarasan kudu ditindakake sajrone proses penyebaran. Setelan iki bisa dipateni nalika panyebaran nggunakake wadhah pihak katelu sing ora perlu diverifikasi. Deskriptor iki uga nuduhake jumlah replika lan URL frontend sing perlu ha-proxy. Ing pungkasan punika flag specification pod "podspec", kang nelpon Kubernetes kanggo informasi ing konfigurasi port, gambar, etc. Iki minangka deskriptor JSON sing cukup prasaja.
Alat liyane sing dadi bagean saka proyek Amdatu open-source yaiku Deploymentctl. Nduwe UI kanggo ngatur penyebaran, nyimpen riwayat penyebaran, lan ngemot webhooks kanggo callback saka pangguna lan pangembang pihak katelu. Sampeyan bisa uga ora nggunakake UI amarga Amdatu Deployer dhewe minangka REST API, nanging antarmuka iki bisa nggawe penyebaran luwih gampang kanggo sampeyan tanpa nglibatake API apa wae. Deploymentctl ditulis ing OSGi/Vertx nggunakake Angular 2.
Saiki aku bakal nduduhake ndhuwur ing layar nggunakake rekaman sing wis direkam supaya sampeyan ora kudu ngenteni. Kita bakal nggunakake aplikasi Go sing prasaja. Aja kuwatir yen sampeyan durung nyoba Go sadurunge, iku aplikasi sing gampang banget supaya sampeyan kudu ngerti.
Ing kene kita nggawe server HTTP sing mung nanggapi / kesehatan, mula aplikasi iki mung nyoba mriksa kesehatan lan ora liya. Yen mriksa liwat, struktur JSON ditampilake ing ngisor iki digunakake. Isine versi aplikasi sing bakal disebarake dening deployer, pesen sing sampeyan deleng ing ndhuwur file, lan jinis data boolean - apa aplikasi kita bisa digunakake utawa ora.
Aku ngapusi sethitik karo baris pungkasan, amarga aku sijine Nilai boolean tetep ing ndhuwur file, kang ing mangsa bakal bantuan kula masang malah aplikasi "ora sehat". Kita bakal ngrampungake iki mengko.
Dadi ayo miwiti. Kaping pisanan, priksa manawa ana pod sing mlaku nggunakake printah ~ kubectl get pods lan, adhedhasar ora ana respon saka URL frontend, kita priksa manawa ora ana penyebaran sing saiki ditindakake.
Sabanjure ing layar sampeyan ndeleng antarmuka Deploymentctl sing dakkandhakake, ing ngendi paramèter penyebaran disetel: ruang jeneng, jeneng aplikasi, versi penyebaran, nomer replika, URL ngarep, jeneng wadhah, gambar, watesan sumber daya, nomer port kanggo mriksa kesehatan, lsp. Watesan sumber daya penting banget, amarga ngidini sampeyan nggunakake hardware maksimal. Ing kene sampeyan uga bisa ndeleng log Deployment.
Yen sampeyan saiki mbaleni printah ~ kubectl njaluk pods, sampeyan bisa ndeleng manawa sistem "freezes" kanggo 20 detik, sajrone ha-proxy reconfigured. Sawise iki, pod diwiwiti, lan replika kita bisa dideleng ing log penyebaran.
Aku Cut metu 20 detik Enteni saka video, lan saiki sampeyan bisa ndeleng ing layar sing versi pisanan saka aplikasi wis tugasaken. Kabeh iki rampung mung nggunakake UI.
Saiki ayo nyoba versi kapindho. Kanggo nindakake iki, aku ngganti pesen aplikasi saka "Hello, Kubernetes!" ing "Hello, Deployer!", Sistem nggawe gambar iki lan nyelehake ing registri Docker, sawise iku mung klik tombol "Deploy" maneh ing jendela Deploymentctl. Ing kasus iki, log panyebaran kanthi otomatis diluncurake kanthi cara sing padha kaya nalika nggunakake versi pisanan aplikasi kasebut.
Printah ~ kubectl get pods nuduhake yen saiki ana 2 versi aplikasi sing mlaku, nanging frontend nuduhake yen kita isih mbukak versi 1.
Load balancer ngenteni mriksa kesehatan rampung sadurunge ngarahake lalu lintas menyang versi anyar. Sawise 20 detik, kita ngalih menyang nggulung lan ndeleng manawa kita saiki duwe versi 2 saka aplikasi sing disebarake, lan sing pisanan wis dibusak.
Iki minangka panyebaran aplikasi "sehat". Ayo ndeleng apa sing kedadeyan yen kanggo versi aplikasi anyar aku ngganti parameter Sehat saka bener dadi palsu, yaiku, aku nyoba masang aplikasi sing ora sehat sing gagal mriksa kesehatan. Iki bisa kedadeyan yen sawetara kesalahan konfigurasi digawe ing aplikasi ing tahap pangembangan, lan dikirim menyang produksi ing wangun iki.
Kaya sing sampeyan ngerteni, panyebaran kasebut ngliwati kabeh langkah ing ndhuwur lan ~kubectl get pods nuduhake yen loro pods mlaku. Nanging ora kaya panyebaran sadurunge, log nuduhake status wektu entek. Yaiku, amarga mriksa kesehatan gagal, versi anyar aplikasi kasebut ora bisa digunakake. AkibatΓ©, sampeyan bisa ndeleng manawa sistem wis bali menyang nggunakake versi lawas saka aplikasi, lan versi anyar mung wis dibusak.
Sing apik babagan iki yaiku sanajan sampeyan duwe panjaluk sing akeh banget sing mlebu ing aplikasi kasebut, dheweke ora bakal sok dong mirsani downtime nalika ngetrapake prosedur penyebaran. Yen sampeyan nyoba aplikasi iki nggunakake framework Gatling, kang ngirim minangka akeh panjalukan sabisa, banjur ora ana panjalukan iki bakal dropped. Iki tegese pangguna kita ora bakal sok dong mirsani nganyari versi ing wektu nyata. Yen gagal, karya bakal diterusake ing versi lawas; yen sukses, pangguna bakal ngalih menyang versi anyar.
Mung ana siji perkara sing bisa gagal - yen mriksa kesehatan sukses, nanging aplikasi kasebut gagal nalika beban kerja ditrapake, yaiku, ambruk bakal kedadeyan mung sawise panyebaran rampung. Ing kasus iki, sampeyan kudu muter maneh kanthi manual menyang versi lawas. Dadi, kita ndeleng carane nggunakake Kubernetes karo alat open-source sing dirancang kanggo iku. Proses panyebaran bakal luwih gampang yen sampeyan nggawe alat kasebut menyang pipa Build/Deploy. Ing wektu sing padha, kanggo miwiti panyebaran, sampeyan bisa nggunakake antarmuka pangguna utawa ngotomatisasi proses iki kanthi nggunakake, contone, komitmen kanggo nguasai.
Server Build kita bakal nggawe gambar Docker, push menyang Docker Hub utawa registri apa wae sing sampeyan gunakake. Docker Hub ndhukung webhook, supaya kita bisa micu penyebaran remot liwat Deployer kanthi cara sing dituduhake ing ndhuwur. Kanthi cara iki sampeyan bisa ngotomatisasi panyebaran aplikasi sampeyan menyang produksi potensial.
Ayo pindhah menyang topik sabanjure - skala cluster Kubernetes. Elinga yen perintah kubectl minangka perintah skala. Kanthi bantuan liyane, kita bisa kanthi gampang nambah jumlah replika ing kluster sing wis ana. Nanging, ing laku, kita biasane pengin nambah jumlah node tinimbang pods.
Ing wektu sing padha, sajrone jam kerja sampeyan bisa uga kudu nambah, lan ing wayah wengi, kanggo nyuda biaya layanan Amazon, sampeyan bisa uga kudu nyuda jumlah aplikasi sing mlaku. Iki ora ateges yen mung jumlah polong bakal cukup, amarga sanajan salah sawijining simpul ora aktif, sampeyan isih kudu mbayar Amazon. Sing, bebarengan karo scaling pods, sampeyan kudu ukuran nomer mesin digunakake.
Iki bisa dadi tantangan amarga apa kita nggunakake Amazon utawa layanan maya liyane, Kubernetes ora ngerti babagan jumlah mesin sing digunakake. Ora ana alat sing ngidini sampeyan ngukur sistem ing tingkat simpul.
Dadi, kita kudu ngurus simpul lan pods. Kita bisa kanthi gampang ngluncurake simpul anyar kanthi nggunakake mesin grup AWS API lan Scaling kanggo ngatur jumlah node pekerja Kubernetes. Sampeyan uga bisa nggunakake cloud-init utawa skrip sing padha kanggo ndaftar simpul ing kluster Kubernetes.
Mesin anyar diwiwiti ing grup Scaling, miwiti dhewe minangka simpul, ndhaptar ing pendaptaran master lan wiwit bisa digunakake. Sawise iki, sampeyan bisa nambah jumlah replika sing digunakake ing node sing diasilake. Scaling mudhun mbutuhake gaweyan liyane, amarga sampeyan kudu nggawe manawa langkah kuwi ora mimpin kanggo karusakan saka aplikasi wis mlaku sawise mateni mesin "ora perlu". Kanggo nyegah skenario kasebut, sampeyan kudu nyetel simpul menyang status "ora bisa dijadwal". Iki tegese panjadwal standar bakal nglirwakake simpul kasebut nalika njadwalake pod DaemonSet. Penjadwal ora bakal mbusak apa-apa saka server kasebut, nanging uga ora bakal mbukak wadhah anyar ing kana. Langkah sabanjure kanggo mbusak simpul saluran, yaiku, kanggo nransfer polong mlaku saka mesin liyane, utawa kelenjar liyane sing nduweni kapasitas sing cukup kanggo iki. Sawise sampeyan mesthekake yen wis ora ana maneh wadhah ing simpul iki, sampeyan bisa mbusak saka Kubernetes. Sawise iki, dheweke mung bakal mandheg ana kanggo Kubernetes. Sabanjure, sampeyan kudu nggunakake API AWS kanggo mateni simpul utawa mesin sing ora perlu.
Sampeyan bisa nggunakake Amdatu Scalerd, alat skala open source liyane sing padha karo API AWS. Nyedhiyakake CLI kanggo nambah utawa mbusak kelenjar ing kluster. Fitur sing menarik yaiku kemampuan kanggo ngatur jadwal nggunakake file json ing ngisor iki.
Kode sing ditampilake nyuda kapasitas kluster nganti setengah ing wayah wengi. Konfigurasi jumlah replika sing kasedhiya lan kapasitas kluster Amazon sing dikarepake. Nggunakake panjadwal iki kanthi otomatis bakal nyuda jumlah simpul ing wayah wengi lan nambah ing wayah esuk, ngirit biaya nggunakake simpul saka layanan awan kaya Amazon. Fitur iki ora dibangun ing Kubernetes, nanging nggunakake Scalerd bakal ngidini sampeyan nggedhekake platform iki sanajan sampeyan pengin.
Aku pengin nuduhake manawa akeh wong sing ujar, "Iku kabeh apik lan apik, nanging kepiye databaseku, sing biasane statis?" Kepiye carane sampeyan bisa mbukak kaya iki ing lingkungan dinamis kaya Kubernetes? Ing mratelakake panemume, sampeyan ora kudu nindakake iki, sampeyan ora kudu nyoba kanggo mbukak data warehouse ing Kubernetes. Iki bisa kanthi teknis, lan ana tutorial ing Internet babagan subyek iki, nanging bakal nggawe rumit urip sampeyan.
Ya, ana konsep toko sing terus-terusan ing Kubernetes, lan sampeyan bisa nyoba mbukak toko data kaya Mongo utawa MySQL, nanging iki minangka tugas sing mbutuhake tenaga kerja. Iki amarga kasunyatan manawa gudang data ora ndhukung interaksi kanthi lingkungan dinamis. Umume database mbutuhake konfigurasi sing signifikan, kalebu konfigurasi manual kluster, ora seneng autoscaling lan liyane sing padha.
Mula, sampeyan ora kudu nggawe rumit urip kanthi nyoba mbukak gudang data ing Kubernetes. Atur pakaryan kanthi cara tradisional nggunakake layanan sing wis dikenal lan cukup menehi Kubernetes kemampuan kanggo nggunakake.
Kanggo ngrampungake topik kasebut, aku pengin ngenalake sampeyan menyang platform Cloud RTI adhedhasar Kubernetes, sing digarap timku. Nyedhiyakake logging terpusat, aplikasi lan pemantauan kluster, lan akeh fitur migunani liyane sing bakal migunani. Iki nggunakake macem-macem alat open-source kayata Grafana kanggo nampilake pemantauan.
Ana pitakonan babagan kenapa nggunakake imbangan beban ha-proxy karo Kubernetes. Pitakonan sing apik amarga saiki ana 2 level load balancing. Layanan Kubernetes isih manggon ing alamat IP virtual. Sampeyan ora bisa digunakake kanggo port ing mesin host eksternal amarga yen Amazon overloads host maya, alamat bakal ganti. Pramila kita nyelehake ha-proxy ing ngarep layanan - kanggo nggawe struktur sing luwih statis supaya lalu lintas bisa komunikasi kanthi lancar karo Kubernetes.
Pitakonan liyane sing apik yaiku carane sampeyan bisa ngurus owah-owahan skema database nalika nindakake panyebaran biru / ijo? Kasunyatane yaiku preduli saka panggunaan Kubernetes, ngganti skema database minangka tugas sing angel. Sampeyan kudu mesthekake yen skema lawas lan anyar kompatibel, sawise sampeyan bisa nganyari database banjur nganyari aplikasi dhewe. Sampeyan bisa hot swap database banjur nganyari aplikasi. Aku ngerti wong sing wis boot munggah kluster database rampung anyar karo skema anyar, iki pilihan yen sampeyan duwe database schemeless kaya Mongo, nanging ora tugas gampang tho. Yen sampeyan ora duwe pitakonan liyane, matur nuwun kanggo manungsa waΓ©!
Sawetara iklan π
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com