Halo, jenengku Dmitry Krasnov. Luwih saka limang taun aku wis ngatur kluster Kubernetes lan mbangun arsitektur microservice sing kompleks. Ing awal taun iki, kita ngluncurake layanan kanggo ngatur klompok Kubernetes adhedhasar Containerum. Njupuk kesempatan iki, aku bakal pitutur marang kowe apa iku Kubernetes lan carane integrasi karo vendor beda saka open source.
Kanggo wiwitan, apa . Iki minangka sistem kanggo ngatur kontaner ing akeh host. Saka basa Yunani, iki diterjemahake minangka "pilot" utawa "helmsman". Originally dikembangake dening Google lan banjur nyumbang minangka kontribusi teknologi kanggo Cloud Native Computing Foundation, organisasi nirlaba internasional sing nggabungake pangembang, pangguna pungkasan lan panyedhiya teknologi kontainer terkemuka ing donya.
Ngatur jumlah akeh kontaner
Saiki ayo dipikirake apa jinis wadhah kasebut. Iki minangka aplikasi kanthi kabeh lingkungane - utamane perpustakaan sing gumantung karo program kasebut. Kabeh iki wis rangkep ing arsip lan presented ing wangun gambar sing bisa mbukak preduli saka sistem operasi, dites lan liyane. Nanging ana masalah - ngatur kontaner ing nomer akeh host angel banget. Mulane Kubernetes digawe.
Gambar wadhah nggambarake aplikasi plus dependensi. Aplikasi, dependensi, lan gambar sistem file OS dumunung ing macem-macem bagean gambar, sing disebut lapisan. Lapisan bisa digunakake maneh kanggo macem-macem wadah. Contone, kabeh aplikasi ing perusahaan bisa nggunakake lapisan dhasar Ubuntu. Nalika mbukak wadhah, ora perlu kanggo nyimpen sawetara salinan saka lapisan basa siji ing inang. Iki ngidini sampeyan ngoptimalake panyimpenan lan pangiriman gambar.
Nalika kita arep kanggo mbukak aplikasi saka wadhah, lapisan perlu superimposed ing saben liyane lan sistem file overlay kawangun. Lapisan rekaman diselehake ing ndhuwur, sing dicopot nalika wadhah mandheg. Iki mesthekake yen wadhah mbukak, aplikasi bakal tansah lingkungan padha, kang ora bisa diganti. Iki njamin reproduksibilitas lingkungan ing OS host sing beda. Apa iku Ubuntu utawa CentOS, lingkungan bakal tansah padha. Kajaba iku, wadhah kasebut diisolasi saka host nggunakake mekanisme sing dibangun ing kernel Linux. Aplikasi ing wadhah ora ndeleng file, pangolahan host lan wadhah tetanggan. Isolasi aplikasi saka OS host iki nyedhiyakake lapisan keamanan tambahan.
Ana akeh alat sing kasedhiya kanggo ngatur kontaner ing host. Sing paling populer yaiku Docker. Iki ngidini sampeyan nyedhiyakake siklus urip lengkap kontaner. Nanging, mung bisa digunakake ing siji host. Yen sampeyan kudu ngatur kontaner ing pirang-pirang host, Docker bisa nggawe neraka kanggo para insinyur. Mulane Kubernetes digawe.
Panjaluk Kubernetes pancen amarga kemampuan kanggo ngatur klompok wadhah ing pirang-pirang host minangka sawetara entitas tunggal. Popularitas sistem kasebut menehi kesempatan kanggo mbangun DevOps utawa Development Operations, ing ngendi Kubernetes digunakake kanggo nglakokake proses DevOps iki.
Gambar 1. Perwakilan skematis babagan cara kerja Kubernetes
Otomatis lengkap
DevOps sejatine minangka otomatisasi proses pangembangan. Secara kasar, pangembang nulis kode sing diunggah menyang repositori. Banjur kode iki bisa diklumpukake kanthi otomatis menyang wadhah kanthi kabeh perpustakaan, diuji lan "digulung" menyang tahap sabanjure - Pementasan, banjur langsung menyang Produksi.
Bebarengan karo Kubernetes, DevOps ngidini sampeyan ngotomatisasi proses iki supaya ora ana partisipasi saka pangembang dhewe. Amarga iki, mbangun luwih cepet, amarga pangembang ora kudu nindakake iki ing komputer - dheweke mung nulis potongan kode, nyurung kode kasebut menyang gudang, sawise pipa kasebut diluncurake, sing bisa kalebu proses kasebut. saka mbangun, testing, lan rolling metu. Lan iki kedadeyan karo saben komitmen, mula tes terus-terusan.
Ing wektu sing padha, nggunakake wadhah ngijini sampeyan kanggo mesthekake yen kabeh lingkungan program iki bakal dirilis menyang produksi persis ing wangun kang wis dites. Yaiku, ora bakal ana masalah kaya "ana sawetara versi ing tes, liyane ing produksi, nanging nalika kita nginstal, kabeh ambruk." Lan wiwit dina iki kita duwe gaya menyang arsitektur microservice, nalika tinimbang siji aplikasi gedhe ana atusan cilik, supaya bisa ngatur kanthi manual, Staff ageng karyawan bakal dibutuhake. Mulane kita nggunakake Kubernetes.
Pro, pro, pro
Yen kita ngomong babagan kaluwihan Kubernetes minangka platform, mula nduweni kaluwihan sing signifikan saka sudut pandang ngatur arsitektur layanan mikro.
- Ngatur pirang-pirang replika. Sing paling penting yaiku ngatur kontaner ing pirang-pirang host. Sing luwih penting, atur pirang-pirang replika aplikasi ing wadhah minangka entitas siji. Thanks kanggo iki, insinyur ora kudu kuwatir babagan saben wadhah individu. Yen salah siji wadhah kacilakan, Kubernetes bakal weruh iki lan miwiti maneh.
- Jaringan kluster. Kubernetes uga duwe jaringan kluster sing diarani kanthi papan alamat dhewe. Thanks kanggo iki, saben pod duwe alamat dhewe. A subpod dipahami minangka unit struktural minimal saka kluster ing ngendi kontainer diluncurake langsung. Kajaba iku, Kubernetes nduweni fungsi sing nggabungake penyeimbang beban lan Penemuan Layanan. Iki ngidini sampeyan ngilangi manajemen alamat IP manual lan utusan tugas iki menyang Kubernetes. Lan pamriksa kesehatan otomatis bakal mbantu ndeteksi masalah lan ngarahake lalu lintas menyang pod sing digunakake.
- Manajemen konfigurasi. Nalika ngatur akeh aplikasi, dadi angel kanggo ngatur konfigurasi aplikasi. Kanggo tujuan iki, Kubernetes duwe sumber daya ConfigMap khusus. Dheweke ngidini sampeyan nyimpen konfigurasi ing tengah lan mbukak menyang pods nalika mbukak aplikasi. Mekanisme iki ngidini kita njamin konsistensi konfigurasi ing paling sepuluh utawa atus replika aplikasi.
- Volume terus-terusan. Kontainer pancen ora bisa diganti lan nalika wadhah mandheg, kabeh data sing ditulis ing sistem file bakal dirusak. Nanging sawetara aplikasi nyimpen data langsung ing disk. Kanggo ngatasi masalah iki, Kubernetes nduweni fungsi manajemen panyimpenan disk - Persistent Volumes. Mekanisme iki nggunakake panyimpenan eksternal kanggo data lan bisa nransfer panyimpenan, blok utawa file sing terus-terusan menyang wadhah. Solusi iki ngidini sampeyan nyimpen data kanthi kapisah saka buruh, sing nyimpen yen buruh sing padha rusak.
- Load Balancer. Sanajan ing Kubernetes, kita ngatur entitas abstrak kaya Deployment, StatefulSet, lan sapiturute, pungkasane wadah mbukak ing mesin virtual utawa server hardware biasa. Padha ora sampurna lan bisa tiba ing sembarang wektu. Kubernetes bakal ndeleng iki lan ngarahake lalu lintas internal menyang replika liyane. Nanging apa sing kudu dilakoni karo lalu lintas sing teka saka njaba? Yen sampeyan mung ngarahake lalu lintas menyang salah sawijining buruh, yen nabrak, layanan kasebut ora kasedhiya. Kanggo ngatasi masalah iki, Kubernetes duwe layanan kaya Load Balancer. Dheweke dirancang kanthi otomatis ngatur keseimbangan awan eksternal kanggo kabeh buruh ing kluster. Balance eksternal iki ngarahake lalu lintas eksternal menyang buruh lan ngawasi statuse dhewe. Yen siji utawa luwih buruh ora kasedhiya, lalu lintas dialihake menyang wong liya. Iki ngidini sampeyan nggawe layanan sing kasedhiya banget nggunakake Kubernetes.
Kubernetes paling apik nalika mbukak arsitektur layanan mikro. Sampeyan bisa ngleksanakake sistem menyang arsitektur klasik, nanging ora ana gunane. Yen aplikasi ora bisa mlaku ing pirang-pirang replika, mula apa bedane - ing Kubernetes utawa ora?
Open source Kubernetes
Open source Kubernetes iku apik banget: Aku nginstal lan kerjane. Sampeyan bisa masang ing server hardware dhewe, ing infrastruktur dhewe, nginstal master lan buruh kang kabeh aplikasi bakal mbukak. Lan sing paling penting, kabeh iki gratis. Nanging, ana nuansa.
- Sing pertama yaiku panjaluk kawruh lan pengalaman para pangurus lan insinyur sing bakal nyebar lan ndhukung kabeh iki. Wiwit klien nampa kamardikan lengkap tumindak ing kluster, tanggung jawab kanggo kinerja kluster dhewe. Lan gampang banget kanggo ngilangi kabeh ing kene.
- Kapindho yaiku kekurangan integrasi. Yen sampeyan mbukak Kubernetes tanpa platform virtualisasi sing populer, sampeyan ora bakal entuk kabeh keuntungan saka program kasebut. Kayata nggunakake layanan Volume Persistent lan Load balancer.
Gambar 2. arsitektur k8s
Kubernetes saka vendor
Integrasi karo panyedhiya awan nyedhiyakake rong pilihan:
- Kaping pisanan, wong mung bisa ngeklik tombol "gawe kluster" lan entuk kluster sing wis dikonfigurasi lan siap digunakake.
- Kapindho, vendor dhewe nginstal kluster lan nyetel integrasi karo awan.
Carane mengkono kene. Insinyur sing miwiti kluster nemtokake jumlah buruh sing dibutuhake lan paramèter apa (contone, 5 buruh, saben 10 CPU, 16 GB RAM lan, ngomong, 100 GB disk). Sawise iku entuk akses menyang kluster sing wis dibentuk. Ing kasus iki, buruh sing mbukak mbukak rampung ditransfer menyang klien, nanging kabeh bidang manajemen tetep dadi tanggung jawab vendor (yen layanan diwenehake miturut model layanan sing dikelola).
Nanging, skema iki nduweni kekurangan. Amarga kasunyatan sing pesawat Manajemen tetep karo vendor, vendor ora menehi akses lengkap kanggo klien, lan iki nyuda keluwesan ing karya karo Kubernetes. Kadhangkala ana klien sing pengin nambah sawetara fungsi tartamtu kanggo Kubernetes, contone, bukti asli liwat LDAP, nanging konfigurasi bidang manajemen ora ngidini iki.
Gambar 3. Conto kluster Kubernetes saka panyedhiya maya
Apa sing kudu dipilih: mbukak sumber utawa vendor
Dadi, apa Kubernetes mbukak sumber utawa vendor khusus? Yen kita njupuk open source Kubernetes, banjur pangguna nindakake apa sing dikarepake. Nanging ana kemungkinan gedhe kanggo njupuk dhewe ing sikil. Kanthi vendor luwih angel, amarga kabeh wis dipikirake lan diatur kanggo perusahaan. Kerugian paling gedhe saka open source Kubernetes yaiku syarat kanggo spesialis. Kanthi pilihan vendor, perusahaan dibebasake saka sirah iki, nanging kudu mutusake apa kudu mbayar spesialis utawa vendor.
Inggih, pro wis ketok, cons uga dikenal. Siji bab tetep: Kubernetes ngatasi akeh masalah kanthi ngotomatisasi manajemen akeh kontaner. Lan endi sing kudu dipilih, mbukak sumber utawa vendor - saben wong nggawe keputusan dhewe.
Artikel kasebut disiapake dening Dmitry Krasnov, arsitek utama layanan Containerum saka panyedhiya #CloudMTS
Source: www.habr.com