Anu kami (sanés ngan ukur kami) parantos ngantosan parantos lami kajantenan: , utilitas Open Source kami pikeun ngawangun aplikasi sareng ngirimkeunana ka Kubernetes, ayeuna ngadukung nerapkeun parobihan nganggo patch gabungan 3 arah! Sajaba ti ieu, kasebut nyaéta dimungkinkeun pikeun ngadopsi sumberdaya K8s aya kana release Helm tanpa rebuilding sumberdaya ieu.
Lamun pondok pisan, lajeng urang nempatkeun WERF_THREE_WAY_MERGE=enabled - urang meunang deployment "sakumaha dina kubectl apply", cocog sareng pamasangan Helm 2 anu tos aya sareng sakedik deui.
Tapi hayu urang mimitian ku téori: naon persisna patch 3-way-merge, kumaha jalma-jalma datang sareng pendekatan pikeun ngahasilkeunana, sareng naha éta penting dina prosés CI / CD sareng infrastruktur basis Kubernetes? Sareng saatos éta, hayu urang tingali naon 3-way-merge dina werf, modeu naon anu dianggo sacara standar sareng kumaha ngatur éta.
Naon patch 3-way-merge?
Janten, hayu urang mimitian ku tugas ngagulungkeun sumber daya anu dijelaskeun dina YAML diwujudkeun kana Kubernetes.
Pikeun damel sareng sumber daya, API Kubernetes nawiskeun operasi dasar ieu: nyiptakeun, nambal, ngagentos sareng ngahapus. Hal ieu dianggap yén kalayan bantuan maranéhanana perlu ngawangun hiji rollout kontinyu merenah sumberdaya pikeun klaster. Kumaha?
paréntah imperatif kubectl
Pendekatan anu munggaran pikeun ngatur objék dina Kubernetes nyaéta ngagunakeun paréntah imperatif kubectl pikeun nyiptakeun, ngarobih, sareng ngahapus objék ieu. Kantun nempatkeun:
- tim
kubectl runanjeun tiasa ngajalankeun Deployment atanapi Job:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - tim
kubectl scale- ngarobah jumlah réplika:kubectl scale --replicas=3 deployment/mysql - jeung sajabana
pendekatan ieu bisa sigana merenah dina glance kahiji. Tapi aya masalah:
- Hese ngajadikeun otomatis.
- kumaha ngagambarkeun konfigurasi di Git? Kumaha marios parobahan anu lumangsung dina kluster?
- Kumaha nyadiakeun reproducibility konfigurasi dina balikan deui?
- ...
Éta jelas yén pendekatan ieu henteu cocog sareng nyimpen aplikasi sareng infrastruktur salaku kode (IaC; atanapi malah salaku pilihan anu langkung modéren, kéngingkeun popularitas di ékosistem Kubernetes). Ku alatan éta, paréntah ieu henteu nampi pamekaran salajengna dina kubectl.
Jieun, meunang, ngaganti jeung mupus operasi
Kalawan primér ciptaan éta basajan: ngirim manifest ka operasi create kube api sareng sumberna parantos didamel. Perwakilan YAML tina manifes tiasa disimpen dina Git sareng didamel nganggo paréntah kubectl create -f manifest.yaml.
С miceun ogé basajan: ngagantikeun sarua manifest.yaml ti Git ka tim kubectl delete -f manifest.yaml.
Operasi replace ngidinan Anjeun pikeun sakabéhna ngaganti konfigurasi sumberdaya nu anyar, tanpa recreating sumberdaya. Ieu ngandung harti yén saméméh nyieun parobahan sumberdaya a, éta logis mun query versi ayeuna kalayan operasi get, robih sareng ngapdet sareng operasi replace. kube apiserver diwangun dina jeung, lamun sanggeus bedah get obyék geus robah, lajeng operasi replace eta moal jalan.
Pikeun nyimpen konfigurasi dina Git sareng ngapdetna nganggo ngagantian, anjeun kedah ngalakukeun operasi get, ngagabung config ti Git jeung naon urang narima, sarta ngaéksekusi replace. Sacara standar, kubectl ngan ukur ngamungkinkeun anjeun nganggo paréntah kubectl replace -f manifest.yamldimana manifest.yaml - hiji geus pinuh disiapkeun (dina hal urang, dihijikeun) manifest nu kudu dipasang. Tétéla yén pamaké kudu nerapkeun ngagabung manifests, sarta ieu teu masalah trivial ...
Éta ogé sia noting yén sanajan manifest.yaml sarta disimpen dina Git, urang teu bisa nyaho sateuacanna naha perlu nyieun hiji obyék atawa ngamutahirkeun eta - ieu kudu dipigawé ku software pamaké.
total: tiasa urang ngawangun rollout kontinyu ngan ngagunakeun nyieun, ngaganti tur mupus, mastikeun yén konfigurasi infrastruktur disimpen dina Git sapanjang kalawan kode jeung merenah CI / CD?
Sacara prinsip, urang tiasa ... Pikeun ieu anjeun bakal kedah ngalaksanakeun operasi ngahiji Manifesto sareng sababaraha jinis anu mengikat:
- mariksa ayana hiji obyék dina klaster,
- ngalaksanakeun nyiptakeun sumber daya awal,
- ngamutahirkeun atawa ngahapus eta.
Nalika ngamutahirkeun, punten perhatikeun éta sumberdaya bisa geus robah saprak panungtungan get tur otomatis nanganan kasus ngonci optimistis - nyieun usaha update ulang.
Sanajan kitu, naha reinvent kabayang lamun kube-apiserver nawarkeun cara séjén pikeun ngapdet sumberdaya: operasi patch, nu relieves pamaké sababaraha masalah dijelaskeun?
nambal
Ayeuna urang angkat ka patches.
Patch mangrupikeun cara utama pikeun nerapkeun parobahan kana objék anu aya dina Kubernetes. Operasi patch gawéna saperti kieu:
- pamaké kube-apiserver kedah ngirim patch dina bentuk JSON sareng netepkeun obyék,
- sarta apiserver sorangan bakal nungkulan kaayaan obyék ayeuna jeung mawa ka formulir diperlukeun.
Ngonci optimis teu diperlukeun dina hal ieu. Operasi ieu langkung déklaratif tibatan ngagantian, sanaos mimitina sigana sabalikna.
kituna:
- ngagunakeun operasi
createurang nyieun hiji obyék nurutkeun kana manifest ti Git, - kalayan bantuan
delete- pupus upami obyék henteu diperyogikeun deui, - kalayan bantuan
patch- urang ngarobah obyék, mawa kana formulir dijelaskeun dina Git.
Nanging, pikeun ngalakukeun ieu, anjeun kedah nyiptakeun patch bener!
Kumaha patch dianggo dina Helm 2: 2-jalan-ngagabung
Sawaktos Anjeun pertama masang pelepasan, Helm ngalakukeun operasi create pikeun sumberdaya grafik.
Nalika ngamutahirkeun release Helm pikeun tiap sumberdaya:
- mertimbangkeun patch antara versi sumberdaya ti bagan saméméhna jeung versi bagan ayeuna,
- nerapkeun patch ieu.
Urang bakal nelepon patch ieu 2-arah ngahiji patch, sabab 2 manifesto aub dina kreasi na:
- manifest sumberdaya ti release saméméhna,
- sumberdaya manifest ti sumberdaya ayeuna.
Nalika ngahapus operasi delete di kube apiserver disebut sumberdaya nu dinyatakeun dina release saméméhna, tapi teu dinyatakeun dina ayeuna.
The 2 way merge pendekatan patch boga masalah: eta ngabalukarkeun kaluar tina sinkron jeung kaayaan nyata sumberdaya dina klaster jeung manifest dina Git.
Ilustrasi masalah sareng conto
- Dina Git, bagan nyimpen hiji manifest dimana widang
imageurusan deploymentubuntu:18.04. - Pamaké via
kubectl editrobah nilai widang ieu kaubuntu:19.04. - Nalika nyebarkeun deui bagan Helm teu ngahasilkeun patch a, sabab sawah
imagedina versi release saméméhna jeung dina bagan ayeuna sarua. - Sanggeus re-deployment
imagetetepubuntu:19.04, sanajan bagan nyebutkeunubuntu:18.04.
Kami ngagaduhan desynchronization sareng kaleungitan déklaratif.
Naon sumberdaya anu disingkronkeun?
Umumna nyarios lengkep Mustahil pikeun kéngingkeun patandingan antara sumber daya dina klaster jalan sareng manifes ti Git. Kusabab dina nyata nyata meureun aya annotations jasa / labél, peti tambahan sarta data lianna nu ditambahkeun jeung dihapus tina sumberdaya dinamis ku sababaraha controller. Kami henteu tiasa sareng henteu hoyong nyimpen data ieu dina Git. Najan kitu, urang hoyong widang anu sacara eksplisit kami jelaskeun dina Git nyandak nilai anu pas nalika diluncurkeun.
Tétéla jadi umum aturan sumberdaya nyingkronkeun: nalika ngagulingkeun sumber daya, anjeun ngan ukur tiasa ngarobih atanapi ngahapus lapangan anu sacara eksplisit ditunjuk dina manifes ti Git (atanapi disaluyukeun dina versi sateuacana sareng ayeuna dihapus).
3-arah ngahiji patch
gagasan sentral : urang ngahasilkeun patch antara versi terapan panungtungan tina manifest ti Git jeung versi target tina manifest ti Git, nyokot kana akun versi ayeuna tina manifest ti klaster ngajalankeun. Patch anu hasilna kedah saluyu sareng aturan sumberdaya anu disingkronkeun:
- widang anyar ditambahkeun kana vérsi target ditambahkeun maké patch a;
- widang saméméhna aya dina versi dilarapkeun panungtungan sarta teu aya dina versi target anu ngareset maké patch a;
- Widang dina versi obyék ayeuna anu bénten sareng vérsi target tina manifest diropéa nganggo patch.
Éta dina prinsip ieu anu ngahasilkeun patches kubectl apply:
- versi terapan terakhir tina manifest disimpen dina annotation tina objék sorangan,
- target - dicandak tina file YAML anu ditangtukeun,
- anu ayeuna ti kluster jalan.
Ayeuna urang geus diurutkeun kaluar téori, éta waktu pikeun ngabejaan ka maneh naon urang lakukeun di werf.
Nerapkeun parobahan werf
Saméméhna, werf, kawas Helm 2, dipaké 2 arah-ngagabung patch.
ngalereskeun patch
Pikeun ngalih ka jinis patch anyar - 3-way-merge - léngkah munggaran anu kami diwanohkeun nyaéta anu disebut perbaikan patch.
Nalika nyebarkeun, patch 2-way-merge standar dianggo, tapi werf ogé ngahasilkeun patch anu bakal nyingkronkeun kaayaan nyata sumberdaya sareng naon anu diserat dina Git (patch sapertos kitu didamel nganggo aturan sumber daya anu sami anu disingkronkeun di luhur) .
Lamun desynchronization lumangsung, dina ahir deployment pamaké narima PERHATOSAN kalawan pesen pakait jeung patch anu kudu dilarapkeun pikeun mawa sumberdaya ka formulir nyingkronkeun. patch ieu ogé kacatet dina annotation husus werf.io/repair-patch. Hal ieu dianggap yén leungeun pamaké сам bakal nerapkeun patch ieu: werf moal nerapkeun eta pisan.
Ngahasilkeun patch perbaikan mangrupikeun ukuran samentawis anu ngamungkinkeun anjeun leres-leres nguji kreasi patch dumasar kana prinsip 3-way-merge, tapi henteu otomatis nerapkeun patch ieu. Ayeuna, modeu operasi ieu diaktipkeun sacara standar.
Patch 3-way-merge ngan ukur kanggo édisi énggal
Dimimitian 1 Désémber 2019, versi béta sareng alfa tina werf dimimitian sacara standar ngagunakeun patch 3-jalan-ngahiji pinuh pikeun nerapkeun parobahan ngan ka release Helm anyar digulung kaluar ngaliwatan werf. Kaluaran anu tos aya bakal teras nganggo pendekatan 2-way-merge + patch perbaikan.
Modeu operasi ieu tiasa diaktipkeun sacara eksplisit ku netepkeun WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ayeuna.
nyarios: fitur nu mucunghul di werf leuwih sababaraha release: dina channel alfa janten siap kalawan versi , sarta dina saluran béta - kalawan .
3-way-merge patch pikeun sakabéh release
Dimimitian 15 Désémber 2019, versi béta sareng alfa tina werf mimiti nganggo patch 3-way-merge pinuh sacara standar pikeun nerapkeun parobahan ka sadaya sékrési.
Modeu operasi ieu tiasa diaktipkeun sacara eksplisit ku netepkeun WERF_THREE_WAY_MERGE_MODE=enabled ayeuna.
Naon anu kudu dipigawé kalayan autoscaling sumberdaya?
Aya 2 jinis autoscaling dina Kubernetes: HPA (horizontal) sareng VPA (vertikal).
Horizontal otomatis milih jumlah réplika, nangtung - jumlah sumberdaya. Duanana jumlah réplika sareng sarat sumberdaya dieusian dina manifes sumberdaya (tingali Resource Manifest). spec.replicas atawa spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
Masalah: upami pangguna ngonpigurasikeun sumberdaya dina bagan supados netepkeun nilai-nilai anu tangtu pikeun sumber atanapi réplika sareng autoscalers diaktipkeun pikeun sumber ieu, maka kalayan unggal panyebaran werf bakal ngareset nilai-nilai ieu kana naon anu diserat dina bagan manifest. .
Aya dua solusi pikeun masalah. Pikeun dimimitian ku, leuwih sae pikeun nyingkahan eksplisit nangtukeun nilai autoscaled dina manifest bagan. Upami pilihan ieu henteu cocog pikeun sababaraha alesan (contona, sabab cocog pikeun nyetél wates sumberdaya awal sareng jumlah réplika dina bagan), maka werf nawiskeun annotations ieu:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Upami annotasi sapertos kitu aya, werf moal ngareset nilai anu saluyu dina unggal panyebaran, tapi ngan ukur bakal nyetél nalika sumberna mimitina diciptakeun.
Pikeun leuwih rinci, tingali dokuméntasi proyék pikeun и .
Larang pamakean patch 3-way-merge
Pamaké ayeuna tiasa nyaram pamakean patch énggal dina werf nganggo variabel lingkungan WERF_THREE_WAY_MERGE_MODE=disabled. Sanajan kitu, dimimitian Ti 1 Maret 2020, larangan ieu moal berlaku deui. tur éta ngan bakal mungkin migunakeun patch 3-jalan-ngahiji.
Nyoko sumberdaya di werf
Ngawasaan metode nerapkeun parobahan sareng patch 3-way-merge ngamungkinkeun urang pikeun langsung nerapkeun fitur sapertos nyoko sumber anu aya dina kluster kana pelepasan Helm.
Helm 2 ngagaduhan masalah: anjeun moal tiasa nambihan sumber pikeun bagan manifests anu parantos aya dina kluster tanpa nyiptakeun sumber ieu ti mimiti (tingali. , ). Urang diajar werf narima sumberdaya aya pikeun release. Jang ngalampahkeun ieu, anjeun kudu masang annotation dina versi ayeuna sumberdaya ti klaster ngajalankeun (contona, ngagunakeun kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEAyeuna sumberna kedah dijelaskeun dina bagan sareng waktos salajengna werf nyebarkeun sékrési kalayan nami anu pas, sumberdaya anu aya bakal ditampi kana sékrési ieu sareng tetep aya dina kontrolna. Leuwih ti éta, dina prosés narima sumberdaya pikeun dileupaskeun, werf bakal mawa kaayaan kiwari sumberdaya ti klaster ngajalankeun kana kaayaan dijelaskeun dina bagan, ngagunakeun patch 3-jalan-ngagabung sarua jeung aturan sumberdaya nyingkronkeun.
nyarios: setting WERF_THREE_WAY_MERGE_MODE henteu mangaruhan nyoko sumberdaya - dina kasus nyoko, patch 3-way-merge sok dipaké.
Rincian - di .
Kacindekan jeung rencana kahareup
Kuring miharep yén sanggeus artikel ieu geus jadi jelas naon patch 3-jalan-ngahiji jeung naha maranéhna datang ka aranjeunna. Tina sudut pandang praktis ngeunaan pamekaran proyék werf, palaksanaanna mangrupikeun léngkah anu sanés pikeun ningkatkeun panyebaran sapertos Helm. Ayeuna anjeun tiasa hilap ngeunaan masalah sareng sinkronisasi konfigurasi anu sering timbul nalika nganggo Helm 2. Dina waktos anu sami, fitur anyar anu kapaké pikeun ngadopsi sumberdaya Kubernetes anu parantos diunduh parantos ditambah kana pelepasan Helm.
Masih aya sababaraha masalah sareng tantangan sareng panyebaran sapertos Helm, sapertos pamakean template Go, anu bakal urang teruskeun.
Émbaran ngeunaan métode update sumberdaya jeung nyoko ogé bisa kapanggih dina .
Helm 3
Pantes catetan husus ngan dinten sejen versi utama anyar Helm - v3 - nu ogé ngagunakeun patch 3-jalan-ngagabung jeung meunang leupas tina Tiller. Versi anyar Helm merlukeun pamasangan anu tos aya pikeun ngarobih kana format panyimpenan énggal.
Werf, pikeun bagian na, ayeuna parantos ngaleungitkeun ngagunakeun Tiller, ngalih ka 3-way-merge sareng nambihan , bari tetep cocog sareng pamasangan Helm 2 anu tos aya (henteu aya skrip migrasi anu kedah dieksekusi). Ku alatan éta, dugi werf pindah ka Helm 3, pamaké werf teu leungit kaunggulan utama Helm 3 leuwih Helm 2 (werf ogé boga aranjeunna).
Sanajan kitu, switch of werf ka Helm 3 codebase teu bisa dihindari sarta bakal kajadian dina mangsa nu bakal datang. Presumably ieu bakal werf 1.1 atanapi werf 1.2 (di momen, versi utama werf nyaeta 1.0; pikeun émbaran nu langkung lengkep ihwal alat versioning werf, tingali ). Salila ieu, Helm 3 bakal gaduh waktos pikeun nyaimbangkeun.
PS
Baca ogé dina blog urang:
- Runtuyan catetan ngeunaan inovasi dina werf:
- «";
- «";
- «".
- «";
- «";
- «".
sumber: www.habr.com