Kubernetes boga sababaraha pilihan pikeun ngamutahirkeun sumberdaya: nerapkeun, edit, patch na ngaganti. Aya kabingungan ngeunaan naon anu dilakukeun ku masing-masing sareng iraha ngagunakeunana. Hayu urang angka eta kaluar.
upami frasa "kubernetes nerapkeun vs ngaganti" lokasina , nu teu bener. "kubernetes nerapkeun vs patch" link kahiji nyaéta dokuméntasi pikeun kubectl patch, nu teu kaasup babandingan apply и patch. Artikel ieu bakal kasampak di pilihan béda, kitu ogé pamakéan ditangtoskeun tina tiap hiji.
Salila siklus hirup hiji sumberdaya Kubernetes (layanan, deployment, ingress, jsb), sakapeung anjeun kudu ngarobah, nambahkeun atawa mupus sababaraha sipat sumberdaya ieu. Contona, tambahkeun catetan, nambahan atawa ngurangan jumlah réplika.
Kubernetes CLI
Upami anjeun parantos damel sareng klaster Kubernetes ngalangkungan CLI, anjeun parantos biasa apply и edit. Tim apply maca spésifikasi sumberdaya ti file jeung ngajadikeun hiji "upsert" kana klaster Kubernetes, i.e. nyiptakeun sumberdaya upami teu aya sareng ngapdet upami aya. Tim edit maca sumberdaya liwat API, teras nyerat spésifikasi sumberdaya kana file lokal, anu teras dibuka dina pangropéa téksu. Saatos Anjeun ngédit sareng nyimpen file, kubectl bakal ngirim perobahan dijieun deui ngaliwatan API, nu taliti bakal nerapkeun parobahan ieu sumberdaya nu.
Henteu sadayana terang paréntahna patch и replace. Tim patch ngidinan Anjeun pikeun ngarobah bagian tina hiji spésifikasi sumberdaya, nyadiakeun ngan bagian robah dina garis paréntah. Tim replace gawéna sarua jeung edit, tapi sadayana kedah dilakukeun sacara manual: anjeun kedah ngaunduh versi spésifikasi sumberdaya ayeuna, contona, nganggo kubectl get -o yaml, édit éta, teras dianggo replace pikeun ngapdet sumberdaya nurutkeun spésifikasi robah. Tim replace moal jalan mun aya parobahan antara maca jeung ngaganti sumberdaya.
API Kubernetes
Anjeun meureun wawuh jeung métode CoreV1().Pods().Update(), replaceNamespacedService atawa patch_namespaced_deployment, mun anjeun damel sareng klaster via ngagunakeun sababaraha basa pamrograman. Perpustakaan handles métode ieu via requests HTTP ngagunakeun métode PUT и PATCH... Dimana update и replace ngagunakeun PUTjeung patch, euweuh urusan kumaha trivial meureun nya, ngagunakeun PATCH.
Eta sia noting yén kubectl ogé jalan kalawan klaster via API. Istilah sanésna, kubectlmangrupakeun wrapper on luhureun perpustakaan klien pikeun basa Go, nu sakitu legana nyadiakeun kamampuhan pikeun nyadiakeun subcommands dina formulir leuwih ci sarta bisa dibaca salian kamampuhan API baku. Contona, anjeun bisa geus noticed, metoda apply teu disebutkeun di luhur dina paragraf saméméhna. Ayeuna (Mei 2020, kira-kira. penerjemah) sadayana logika kubectl apply, i.e. nyiptakeun sumberdaya non-existent jeung ngamutahirkeun nu geus aya, jalan sagemblengna dina sisi kode kubectl. Usaha keur dilakukeun apply ka sisi API, tapi masih dina béta. Kuring bakal nulis leuwih jéntré di handap.
Patch sacara standar
Pangalusna dipaké patch, upami anjeun hoyong ngapdet sumberdaya. Ieu kumaha duanana perpustakaan klien dianggo dina luhureun API Kubernetes na kubectl (Teu héran, sabab éta bungkus pikeun perpustakaan klien, kira-kira. penerjemah).
Gawé sacara strategis
Sadaya tim kubectl apply, edit и patch ngagunakeun métode PATCH dina pamundut HTTP pikeun ngapdet hiji sumberdaya aya. Lamun delve kana palaksanaan paréntah di leuwih jéntré, lajeng sakabéh éta ngagunakeun pendekatan pikeun ngapdet sumberdaya, sanajan paréntah patch tiasa nganggo pendekatan anu sanés (langkung seueur ngeunaan ieu di handap). Pendekatan patching strategic-merge nyoba "ngalereskeun" ku ngahijikeun spésifikasi anu disayogikeun sareng spésifikasi anu tos aya. Leuwih husus, éta nyoba ngagabungkeun duanana objék jeung arrays, nu hartina parobahan condong jadi aditif. Contona, ngajalankeun paréntah patch kalawan variabel lingkungan anyar dina spésifikasi wadah pod, ngabalukarkeun variabel lingkungan ditambahkeun kana variabel lingkungan aya tinimbang overwriting aranjeunna. Pikeun miceun ngagunakeun pendekatan ieu, anjeun kudu maksakeun nilai parameter null dina spésifikasi disadiakeun. Tim mana kubectl Naha éta langkung saé dianggo pikeun ngapdet?
Upami anjeun nyiptakeun sareng ngatur sumberdaya anjeun nganggo kubectl apply, nalika ngamutahirkeun éta hadé pikeun salawasna ngagunakeun kubectl applyka kubectl tiasa ngatur konfigurasi sareng leres ngalacak parobahan anu dipénta tina aplikasi ka aplikasi. Kauntungannana salawasna ngagunakeun apply nyaéta yén éta ngalacak spésifikasi anu diterapkeun sateuacana, ngamungkinkeun éta terang nalika sipat spésifikasi sareng elemen Asép Sunandar Sunarya dihapus sacara eksplisit. Hal ieu ngamungkinkeun anjeun ngagunakeun apply pikeun miceun sipat sarta elemen Asép Sunandar Sunarya, bari ngahiji strategis normal moal jalan. Tim edit и patch teu update catetan éta kubectl apply dianggo pikeun ngalacak parobahanana, janten parobahan naon waé anu dilacak sareng dilakukeun ngaliwatan API Kubernetes, tapi dilakukeun ngaliwatan paréntah. edit и patch, teu katingali ku paréntah salajengna apply, Nyaeta apply teu dipiceun aranjeunna sanajan maranéhna teu muncul dina spésifikasi input pikeun apply (Dokuméntasi nyebutkeun yén edit и patch nyieun apdet kana catetan dipaké apply, tapi dina prakna - euweuh).
Upami anjeun henteu nganggo paréntah apply, bisa dipaké salaku editjeung patch, milih paréntah anu paling cocog sareng parobahan anu dilakukeun. Nalika nambihan sareng ngarobih sipat BOM, duanana pendekatan anu kasarna sami. Nalika mupus sipat spésifikasi atawa elemen Asép Sunandar Sunarya edit behaves kawas peluncuran hiji-waktos apply, kaasup ngalacak naon spésifikasi éta kawas saméméh jeung sanggeus éta diédit, jadi Anjeun bisa sacara eksplisit nyabut sipat sarta elemen Asép Sunandar Sunarya ti sumberdaya a. Anjeun kudu eksplisit nyetel nilai sipat null dina spésifikasi pikeun patchpikeun nyabut eta tina sumberdaya. Nyoplokkeun hiji unsur Asép Sunandar Sunarya ngagunakeun patching strategis-ngahiji leuwih kompleks sabab merlukeun pamakéan diréktif merge. Tempo pendekatan pamutahiran séjén di handap pikeun alternatif leuwih giat.
Pikeun nerapkeun métode update di perpustakaan klien nu kalakuanana sarupa jeung paréntah di luhur kubectl, kudu disetel dina requests content-type в application/strategic-merge-patch+json. Upami anjeun hoyong ngahapus sipat dina spésifikasi, anjeun kedah sacara eksplisit nyetél nilaina ka null dina cara anu sami kubectl patch. Upami anjeun kedah ngahapus elemen Asép Sunandar Sunarya, anjeun kedah ngalebetkeun diréktif gabungan dina spésifikasi pembaruan atanapi nganggo pendekatan anu béda pikeun apdet.
pendekatan séjén pikeun apdet
Kubernetes ngadukung dua pendekatan pembaruan anu sanés: и . Pendekatan patch gabungan JSON nyandak spésifikasi Kubernetes parsial salaku input sareng ngadukung ngahijikeun objék anu sami sareng pendekatan patching-strategis. Beda antara dua éta ngan ngarojong ngagantian Asép Sunandar Sunarya, kaasup wadahna Asép Sunandar Sunarya dina spésifikasi pod. Ieu ngandung harti yén nalika nganggo patch gabungan JSON, anjeun kedah nyayogikeun spésifikasi lengkep pikeun sadaya wadah upami aya harta anu aya parobahan wadahna. Jadi pendekatan ieu mangpaat pikeun nyoplokkeun elemen ti Asép Sunandar Sunarya dina BOM a. Dina garis paréntah anjeun tiasa milih JSON merge patch nganggo kubectl patch --type=merge. Nalika damel sareng API Kubernetes, anjeun kedah nganggo metode pamundut PATCH sareng pamasangan content-type в application/merge-patch+json.
Pendekatan patch JSON, tinimbang nyadiakeun spésifikasi parsial sumberdaya a, migunakeun nyadiakeun parobahan nu Anjeun hoyong jieun ka sumberdaya salaku hiji Asép Sunandar Sunarya, nu unggal unsur Asép Sunandar Sunarya ngagambarkeun pedaran parobahan keur sumberdaya nu. Pendekatan ieu mangrupikeun cara anu langkung fleksibel sareng kuat pikeun nganyatakeun parobihan anu dilakukeun, tapi kalayan biaya daptar parobihan anu dilakukeun dina format anu misah, non-Kubernetes, tinimbang ngirimkeun spésifikasi sumberdaya parsial. DI kubectl Anjeun tiasa milih patch JSON ngagunakeun kubectl patch --type=json. Nalika nganggo API Kubernetes, pendekatan ieu tiasa dianggo nganggo metode pamundut PATCH sareng pamasangan content-type в application/json-patch+json.
Urang kudu kapercayaan - pamakéan ngaganti
Dina sababaraha kasus, anjeun kedah mastikeun yén teu aya parobahan anu dilakukeun pikeun sumber daya antara waktos sumber dibaca sareng nalika diropéa. Dina basa sejen, Anjeun kudu mastikeun yén sagala parobahan bakal atom. Dina hal ieu, pikeun ngapdet sumberdaya anjeun kedah nganggo replace. Contona, upami anjeun gaduh ConfigMap kalawan counter nu diropéa ku sababaraha sumber, Anjeun kudu mastikeun yén dua sumber teu ngamutahirkeun counter dina waktos anu sareng, ngabalukarkeun update leungit. Pikeun nunjukkeun, bayangkeun runtuyan acara ngagunakeun pendekatan patch:
- A jeung B meunang kaayaan kiwari sumberdaya ti API
- Tiap hiji lokal ngamutahirkeun spésifikasi ku incrementing counter ku hiji jeung ogé nambahkeun "A" atawa "B" masing-masing kana catetan "diropéa-ku"
- Sarta eta ngamutahirkeun sumberdaya saeutik leuwih gancang
- B ngamutahirkeun sumberdaya
Hasilna, update A leungit. Operasi panungtungan patch ngéléhkeun , counter ieu incremented ku hiji tinimbang dua, jeung nilai "diropéa-ku" catetan ditungtungan make "B" na teu ngandung "A". Hayu urang bandingkeun di luhur sareng naon anu kajantenan nalika pembaruan dilakukeun nganggo pendekatan replace:
- A jeung B meunang kaayaan kiwari sumberdaya ti API
- Tiap hiji lokal ngamutahirkeun spésifikasi ku incrementing counter ku hiji jeung ogé nambahkeun "A" atawa "B" masing-masing kana catetan "diropéa-ku"
- Sarta eta ngamutahirkeun sumberdaya saeutik leuwih gancang
- B nyoba ngamutahirkeun sumberdaya, tapi update ditolak ku API sabab versi sumberdaya aya dina spésifikasi.
replaceteu cocog jeung versi kiwari sumberdaya di Kubernetes sabab versi sumberdaya ngaronjat ku operasi ngaganti A.
Dina kasus di luhur, B kedah nyandak deui sumberdaya, parobihan kana kaayaan énggal sareng cobian deui replace. Ieu bakal ngabalukarkeun loket jadi incremented ku dua jeung catetan "diropéa-ku" ngawengku "AB" dina tungtungna.
Conto di luhur nunjukkeun yén nalika ngalaksanakeun replace Sakabéh sumberdaya sagemblengna diganti. Spésifikasi dipaké pikeun replace, teu kudu parsial, atawa sabagian saperti dina apply, tapi lengkep, kaasup tambahan resourceVersion kana metadata spésifikasi. Upami anjeun teu acan ngaktipkeun resourceVersion atawa versi anjeun nyadiakeun teu ayeuna, ngagantian bakal ditolak. Janten pendekatan anu pangsaéna pikeun dianggo nyaéta replace - baca sumberna, ngapdet sareng ngagentos langsung. Ngagunakeun kubectl, sigana sapertos kieu:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Perlu dicatet yén dua paréntah di handap ieu, dieksekusi sacara berurutan, bakal suksés dieksekusi, sabab deployment.yaml teu ngandung harta .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlIeu bakal sigana contradict naon ieu ceuk luhur, i.e. " nambahan resourceVersion kana metadata spésifikasi. "Naha salah ngomong kitu? Henteu, éta henteu, sabab lamun kubectl notices nu teu tangtu resourceVersion, éta bakal maca éta tina sumber sareng nambihan kana spésifikasi anu anjeun jelaskeun, teras laksanakeun éta. replace. Kusabab ieu berpotensi bahaya lamun ngandelkeun atomicity, magic jalan sagemblengna di sisi kubectl, Anjeun teu kudu ngandelkeun eta lamun ngagunakeun perpustakaan klien nu gawéna kalayan API. Dina hal ieu anjeun kedah maca spésifikasi sumberdaya ayeuna, ngapdet teras laksanakeun PUT kahoyong.
Anjeun teu bisa ngalakukeun patch a - urang ngalakukeun hiji ngaganti
Kadang-kadang anjeun kedah ngalakukeun sababaraha parobihan anu henteu tiasa diurus ku API. Dina kasus ieu, anjeun tiasa maksa ngagantian sumberdaya ku mupus sareng nyiptakeun deui. Hal ieu dilakukeun ngagunakeun kubectl replace --force. Ngajalankeun paréntah geuwat miceun sumberdaya lajeng recreates aranjeunna tina spésifikasi disadiakeun. Aya henteu "gaya ngaganti" Handler di API, sarta dina urutan pikeun ngalakukeunana ngaliwatan API, Anjeun kudu ngalakukeun dua operasi. Mimiti anjeun kedah ngahapus sumberdaya ku netepkeunana gracePeriodSeconds ka enol (0) jeung propagationPolicy dina "Background" lajeng nyieun deui sumberdaya ieu kalawan spésifikasi nu dipikahoyong.
Perhatosan: Pendekatan ieu berpotensi bahaya sareng tiasa ngakibatkeun kaayaan anu teu jelas.
Larapkeun dina sisi server
Sakumaha didadarkeun di luhur, pamekar Kubernetes ngusahakeun ngalaksanakeun logika apply ti kubectl dina API Kubernetes. Logika apply sadia dina Kubernetes 1.18 via kubectl apply --server-side atanapi via API ngagunakeun métode PATCH с content-type application/apply-patch+YAML.
Catetan: JSON ogé valid YAML, jadi Anjeun bisa ngirim spésifikasi salaku JSON sanajan
content-typebakalapplication/apply-patch+yaml.
Salian ti éta logika kubectl janten sadia ka sadayana via API, apply di sisi server, ngalacak saha jawab widang dina spésifikasi, sahingga ngamungkinkeun sababaraha aksés aman pikeun ngedit konflik-gratis na. Dina basa sejen, lamun apply di sisi server bakal jadi leuwih nyebar, a panganteur manajemén sumberdaya aman universal bakal muncul pikeun klien béda, contona, kubectl, Pulumi atanapi Terraform, GitOps, kitu ogé Aksara timer ditulis ngagunakeun perpustakaan klien.
hasil
Abdi ngarepkeun anjeun mendakan gambaran pondok ieu ngeunaan cara anu béda pikeun ngapdet sumber dina kluster mantuan. Hadé pisan mun éta terang yén éta henteu ngan ukur nerapkeun versus ngaganti, tapi mungkin pikeun ngapdet sumberdaya nganggo aplikasi, édit, patch, atanapi ganti. Barina ogé, prinsipna mah, unggal pendekatan boga wewengkon aplikasi sorangan. Pikeun parobahan atom, ngaganti leuwih hade; lamun heunteu, Anjeun kudu make strategis-ngagabung patch via aplikasi. Sahenteuna, kuring ngarepkeun anjeun ngartos yén anjeun henteu tiasa percanten ka Google atanapi StackOerflow nalika milarian "kubernetes nerapkeun vs ngaganti". Sahenteuna dugi artikel ieu ngagantikeun jawaban ayeuna.
sumber: www.habr.com