🥇Alat Helm sareng pitfalls na

Konsep angkutan barang Typhon, Anton Swanepoel

Nami abdi Dmitry Sugrobov, abdi pamekar di Leroy Merlin. Dina artikel ieu kuring gé ngabejaan Anjeun naha Helm diperlukeun, kumaha eta simplifies gawé bareng Kubernetes, naon geus robah dina versi katilu, sarta kumaha carana make eta pikeun ngapdet aplikasi dina produksi tanpa downtime.

Ieu kasimpulan dumasar kana pidato dina konferensi @Kubernetes Konférénsi by Mail.ru Cloud Solutions — upami anjeun henteu hoyong maca, tingali pidéo.

Naha kami nganggo Kubernetes dina produksi

Leroy Merlin mangrupikeun pamimpin pasar ritel DIY di Rusia sareng Éropa. Perusahaan kami ngagaduhan langkung ti saratus pamekar, 33 karyawan internal sareng sajumlah ageung jalma ngadatangan hypermarket sareng halaman wéb. Pikeun ngajantenkeun aranjeunna sadayana bagja, kami mutuskeun pikeun nuturkeun pendekatan standar industri. Ngembangkeun aplikasi anyar nganggo arsitéktur microservice; nganggo wadah pikeun ngasingkeun lingkungan sareng mastikeun pangiriman anu leres; sarta ngagunakeun Kubernetes pikeun orkestrasi. Harga ngagunakeun orkestrator gancang-gancang janten langkung mirah: jumlah insinyur anu mumpuni dina téknologi naék di pasar, sareng panyadia muncul nawiskeun Kubernetes salaku jasa.

Sagalana yén Kubernetes teu, tangtosna, bisa dipigawé ku cara séjén, contona, ku nutupan sababaraha Jenkins na docker-ngarang kalawan Aksara, tapi naha ngahesekeun hirup lamun aya solusi siap-dijieun tur dipercaya? Éta sababna urang sumping ka Kubernetes sareng parantos dianggo dina produksi salami sataun ayeuna. Ayeuna urang gaduh dua puluh opat klaster Kubernetes, anu pangkolotna umurna langkung ti sataun, kalayan sakitar dua ratus pod.

Kutukan file YAML ageung di Kubernetes

Pikeun ngajalankeun microservice di Kubernetes, urang bakal nyieun sahenteuna lima file YAML: pikeun Deployment, Service, Ingress, ConfigMap, Secrets - sarta ngirimkeunana ka klaster. Pikeun aplikasi salajengna urang bakal nulis pakét sarua jambs, jeung nu katilu urang nulis sejen, jeung saterusna. Upami urang ngalikeun jumlah dokumén ku jumlah lingkungan, urang parantos nampi ratusan file, sareng ieu henteu acan tumut kana lingkungan dinamis.

Adam Reese, pangropéa inti Helm, ngenalkeun konsép "Siklus Pangwangunan di Kubernetes", anu katingalina kieu:

Salin YAML - nyalin file YAML.
Témpél YAML - témpélkeun.
Ngalereskeun Indents - ngalereskeun indents.
Malikan - malikan deui.

Pilihanna tiasa dianggo, tapi anjeun kedah nyalin file YAML sababaraha kali. Pikeun ngarobah siklus ieu, Helm nimukeun.

Naon Helm

Anu kahiji, Helm- manajer pakét, nu mantuan Anjeun manggihan tur masang program nu peryogi. Pikeun masang, contona, MongoDB, anjeun henteu kedah angkat ka halaman wéb resmi sareng unduh binari, jalankeun paréntahna. helm install stable/mongodb.

Kadua, Helm- mesin témplat, mantuan pikeun parameterize file. Hayu urang balik deui ka kaayaan sareng file YAML di Kubernetes. Éta langkung gampang nyerat file YAML anu sami, tambahkeun sababaraha pananda tempat, dimana Helm bakal ngagentos nilai. Nyaéta, tinimbang sakumpulan scaffolds anu ageung, bakal aya sakumpulan témplat dimana nilai anu diperyogikeun bakal diganti dina waktos anu pas.

Katilu, Helm- master deployment. Kalayan éta anjeun tiasa masang, ngabalikan sareng ngapdet aplikasi. Hayu urang terang kumaha ngalakukeun ieu.

Kumaha ngagunakeun Helm pikeun nyebarkeun aplikasi anjeun sorangan

Hayu urang masang klien Helm dina komputer Anjeun, nuturkeun resmi parentah. Salajengna, urang bakal nyiptakeun sakumpulan file YAML. Gantina nangtukeun nilai husus, urang bakal ninggalkeun placeholders, nu Helm bakal eusian informasi dina mangsa nu bakal datang. Hiji set file sapertos disebut bagan Helm. Éta tiasa dikirim ka klien konsol Helm ku tilu cara:

nunjukkeun polder sareng témplat;
pak arsip kana .tar tur nunjuk ka dinya;
nempatkeun témplat dina gudang jauh tur nambahkeun tumbu ka gudang di klien Helm.

Anjeun ogé peryogi file kalayan nilai - values.yaml. Data ti dinya bakal diselapkeun kana citakan. Hayu urang nyieun ogé.

Versi kadua Helm gaduh aplikasi server tambahan - Tiller. Éta ngagantung di luar Kubernetes sareng ngantosan pamundut ti klien Helm, sareng nalika ditelepon, ngagentos nilai anu diperyogikeun kana citakan sareng dikirimkeun ka Kubernetes.

Helm 3 leuwih basajan: tinimbang ngolah témplat dina server, informasi ayeuna diolah sagemblengna dina sisi klien Helm tur dikirim langsung ka API Kubernetes. Nyederhanakeun ieu ningkatkeun kaamanan klaster sareng ngagampangkeun skéma rollout.

Kumaha gawéna sadayana

Jalankeun paréntah helm install. Hayu urang nunjukkeun nami pelepasan aplikasi sareng masihan jalan ka values.yaml. Dina tungtungna urang bakal nunjukkeun gudang dimana bagan aya sareng nami bagan. Dina conto, ieu "lmru" jeung "bestchart", masing-masing.

helm install --name bestapp --values values.yaml lmru/bestchart

Paréntahna ngan ukur tiasa dieksekusi sakali, upami dieksekusi deui install perlu ngagunakeun upgrade. Pikeun kesederhanaan, tinimbang dua paréntah, anjeun tiasa ngajalankeun paréntah upgrade kalawan konci tambahan --install. Nalika dieksekusi pikeun kahiji kalina, Helm bakal ngirim paréntah pikeun masang sékrési, sareng bakal ngamutahirkeun ka hareup.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Pitfalls of deploying versi anyar tina hiji aplikasi kalawan Helm

Dina titik ieu dina carita, Kuring maén Who Wants to Be a Millionaire jeung panongton, sarta kami nuju figuring kaluar kumaha carana meunang Helm pikeun ngapdet versi aplikasi. Lalajo pidéo na.

Nalika kuring diajar kumaha Helm jalan, kuring kaget ku paripolah aneh nalika nyobian ngapdet versi aplikasi anu ngajalankeun. Kuring ngamutahirkeun kodeu aplikasi, unggah gambar anyar ka pendaptaran Docker, dikirim paréntah deployment - jeung euweuh kajadian. Di handap ieu aya sababaraha cara anu henteu sapinuhna suksés pikeun ngapdet aplikasi. Ku diajar unggal sahijina di leuwih jéntré, anjeun ngawitan ngartos struktur internal alat jeung alesan pikeun kabiasaan ieu teu atra.

Métode 1. Ulah ngarobah informasi saprak peluncuran panungtungan

Sakumaha nyebutkeun ramatloka resmi Helm, "Catatan Kubernetes tiasa ageung sareng rumit, janten Helm nyobian henteu ngarampa nanaon." Ku alatan éta, lamun ngamutahirkeun versi panganyarna tina gambar aplikasi dina pendaptaran docker tur ngajalankeun paréntah helm upgrade, lajeng nanaon bakal kajadian. Helm bakal mikir yén teu aya anu robih sareng henteu kedah ngirim paréntah ka Kubernetes pikeun ngapdet aplikasi.

Di dieu jeung di handap, tag panganyarna ditémbongkeun wungkul salaku conto. Nalika anjeun nangtukeun tag ieu, Kubernetes bakal ngaunduh gambar tina pendaptaran docker unggal waktos, henteu paduli parameter imagePullPolicy. Ngagunakeun panganyarna dina produksi teu dipikahoyong tur ngabalukarkeun efek samping.

Métode 2. Update LABEL dina gambar

Salaku ditulis dina sarua dokuméntasi, "Helm ngan bakal ngamutahirkeun hiji aplikasi lamun geus robah saprak release panungtungan." Pilihan logis pikeun ieu sigana bakal ngamutahirkeun LABEL dina gambar docker sorangan. Tapi, Helm henteu ningali kana gambar aplikasi sareng henteu terang ngeunaan parobahanana. Sasuai, nalika ngamutahirkeun labél dina gambar, Helm moal nyaho ngeunaan eta, sarta paréntah update aplikasi moal dikirim ka Kubernetes.

Métode 3: Anggo konci --force

Hayu urang balikkeun ka manual sareng milarian konci anu diperyogikeun. konci ngajadikeun paling raos --force. Sanajan ngaranna atra, kabiasaan béda ti ekspektasi. Gantina maksakeun apdet aplikasi, tujuan anu saleresna nyaéta mulangkeun pelepasan anu aya dina status GAGAL. Upami anjeun henteu nganggo konci ieu, anjeun kedah ngaéksekusi paréntah sacara berurutan helm delete && helm install --replace. Disarankeun pikeun nganggo konci --force, nu ngajadikeun otomatis palaksanaan runtuyan paréntah ieu. Inpo nu leuwih lengkep dina ieu pamundut tarik. Dina raraga ngabejaan Helm pikeun ngapdet versi aplikasi, hanjakalna, konci ieu moal jalan.

Métode 4. Robah labél langsung di Kubernetes

Ngamutahirkeun labél langsung dina klaster ngagunakeun paréntah kubectl edit - gagasan goréng. Peta ieu bakal ngakibatkeun inconsistency inpormasi antara aplikasi jalan jeung hiji nu asalna dikirim pikeun deployment. Paripolah Helm salila deployment dina hal ieu béda ti versi na: Helm 2 moal ngalakukeun nanaon, sarta Helm 3 bakal nyebarkeun versi anyar tina aplikasi. Pikeun ngartos naha, anjeun kedah ngartos kumaha Helm jalan.

Kumaha gawéna Helm?

Pikeun nangtukeun lamun hiji aplikasi geus robah ti release panungtungan, Helm bisa ngagunakeun:

ngajalankeun aplikasi dina Kubernetes;
nilai anyar.yaml jeung bagan ayeuna;
Inpormasi pelepasan internal Helm.

Pikeun leuwih panasaran: dimana Helm nyimpen informasi internal ngeunaan release?Ku ngalaksanakeun paréntah helm history, urang bakal meunang sagala informasi ngeunaan versi dipasang maké Helm.

Aya ogé inpormasi lengkep ngeunaan témplat sareng nilai anu dikirim. Urang tiasa nyuhunkeun:

Dina versi kadua Helm, informasi ieu lokasina dina spasi ngaran sarua dimana Tiller ngajalankeun (kube-sistem sacara standar), dina ConfigMap, ditandaan ku labél "OWNER=TILLER":

Nalika versi katilu Helm mucunghul, informasi dipindahkeun ka Rahasia, sarta ngaranspasi sarua dimana aplikasi ieu ngajalankeun. Hatur nuhun kana ieu, éta janten mungkin pikeun ngajalankeun sababaraha aplikasi sakaligus dina spasi ngaran béda jeung ngaran release sarua. Dina versi kadua éta nyeri sirah serius lamun namespaces diisolasi tapi bisa pangaruh silih.

Helm kadua, nalika nyobian ngartos naha pembaruan diperyogikeun, ngan ukur nganggo dua sumber inpormasi: naon anu disayogikeun ayeuna, sareng inpormasi internal ngeunaan rilis, anu aya dina ConfigMap.

Helm katilu nganggo strategi gabungan tilu arah: salian ti inpormasi éta, éta ogé merhatikeun aplikasi anu dijalankeun ayeuna di Kubernetes.

Ku sabab kitu, versi heubeul Helm moal ngalakukeun nanaon, sabab teu tumut kana akun informasi aplikasi dina klaster, tapi Helm 3 bakal nampa parobahan sarta ngirim aplikasi anyar pikeun deployment.

Métode 5. Anggo saklar --recreate-pods

Kalayan konci --recreate-pods Anjeun tiasa ngahontal naon asalna rencanana pikeun ngahontal jeung konci --force. Wadahna bakal balikan deui sareng, numutkeun kana imagePullPolicy: Salawasna kabijakan pikeun tag panganyarna (langkung seueur ngeunaan ieu dina catetan kaki di luhur), Kubernetes bakal ngaunduh sareng ngaluncurkeun vérsi gambar énggal. Ieu moal dilakukeun ku cara anu pangsaéna: tanpa merhatikeun StrategyType of deployment, éta bakal ngadadak mareuman sadaya instansi aplikasi anu lami sareng ngamimitian ngaluncurkeun anu énggal. Salila balikan deui, sistem moal jalan, pamaké bakal sangsara.

Dina Kubernetes sorangan, masalah anu sami ogé parantos lami. Sareng ayeuna, 4 taun saatos dibuka hasil, masalahna geus dibereskeun, sarta dimimitian ku versi 1.15 of Kubernetes, kamampuhan pikeun roll-restart pods mucunghul.

Helm ngan saukur mareuman sadaya aplikasi sareng ngaluncurkeun wadah énggal anu caket dieu. Anjeun teu tiasa ngalakukeun ieu dina produksi, ku kituna henteu ngabalukarkeun downtime aplikasi. Ieu ngan diperlukeun pikeun kaperluan ngembangkeun sarta ngan bisa dipigawé di lingkungan panggung.

Kumaha ngapdet versi aplikasi nganggo Helm?

Kami bakal ngarobih nilai anu dikirim ka Helm. Biasana, ieu mangrupikeun nilai anu digantikeun pikeun tag gambar. Dina kasus panganyarna, anu sering dianggo pikeun lingkungan anu teu produktif, inpormasi anu tiasa dirobih mangrupikeun anotasi, anu henteu aya gunana pikeun Kubernetes sorangan, sareng pikeun Helm éta bakal janten sinyal pikeun kabutuhan ngapdet aplikasi. Pilihan pikeun ngeusian nilai annotation:

nilai acak ngagunakeun fungsi standar - {{ randAlphaNum 6 }}.
Aya caveat a: sanggeus unggal deployment maké bagan kalayan variabel misalna, nilai annotation bakal unik, sarta Helm bakal nganggap yén aya parobahan. Tétéla urang bakal salawasna balikan deui aplikasi, sanajan urang teu robah versi na. Ieu teu kritis, saprak moal aya downtime, tapi masih pikaresepeun.
Témpél ayeuna tanggal jeung waktu - {{ .Release.Date }}.
Varian sarua jeung nilai acak ku variabel unik permanén.
Cara anu langkung leres nyaéta ngagunakeun checksums. Ieu mangrupikeun SHA gambar atanapi SHA tina komitmen terakhir dina git - {{ .Values.sha }}.
Éta bakal perlu diitung sarta dikirim ka klien Helm dina samping nelepon, contona dina Jenkins. Upami aplikasi parantos robih, maka checksum bakal robih. Ku alatan éta, Helm ngan bakal ngamutahirkeun aplikasi lamun diperlukeun.

Hayu urang nyimpulkeun usaha urang

Helm ngadamel parobihan dina cara anu paling invasif, janten naon waé parobihan dina tingkat gambar aplikasi dina Docker Registry moal ngahasilkeun pembaruan: teu aya anu bakal kajadian saatos paréntahna dieksekusi.
konci --force dipaké pikeun mulangkeun kaluaran masalah jeung teu pakait sareng apdet kapaksa.
konci --recreate-pods bakal maksakeun ngamutahirkeun aplikasi, tapi bakal ngalakukeun eta ku cara vandal: eta ngadadak bakal mareuman sakabeh wadahna. Pamaké bakal sangsara tina ieu; anjeun teu kedah ngalakukeun ieu dina produksi.
Langsung jieun perobahan kana klaster Kubernetes nganggo paréntah kubectl edit ulah: urang bakal megatkeun konsistensi, jeung kabiasaan bakal béda gumantung kana versi Helm.
Kalayan sékrési versi Helm énggal, seueur nuansa anu muncul. Masalah dina gudang Helm dijelaskeun dina basa anu jelas, aranjeunna bakal ngabantosan anjeun ngartos detilna.
Nambahkeun anotasi anu tiasa diédit kana bagan bakal ngajantenkeun langkung fleksibel. Ieu bakal ngidinan Anjeun pikeun gulung kaluar aplikasi bener, tanpa downtime.

Pikiran "perdamaian dunya" anu dianggo dina sagala widang kahirupan: baca petunjuk sateuacan dianggo, sanés saatosna. Ngan kalayan inpormasi lengkep bakal tiasa ngawangun sistem anu tiasa dipercaya sareng ngajantenkeun pangguna senang.

Tumbu patali séjén:

laporan ieu munggaran dibere di @Kubernetes Konférénsi ku Mail.ru Cloud Solutions. Neuteup видео pintonan séjén sarta ngalanggan announcements acara on Telegram Sabudeureun Kubernetes di Mail.ru Grup.

sumber: www.habr.com

Alat Helm sareng pitfalls na