Kubernetes duwe sawetara opsi kanggo nganyari sumber daya: aplikasi, sunting, patch lan ngganti. Ana kebingungan babagan apa sing ditindakake saben wong lan kapan nggunakake. Ayo dipikirake.
yen tembung "kubernetes aplikasi vs ngganti" dumunung , sing ora bener. "kubernetes aplikasi vs patch" link pisanan dokumentasi kanggo kubectl patch, kang ora kalebu comparison apply и patch. Artikel iki bakal ndeleng opsi sing beda-beda, uga panggunaan sing tepat kanggo saben.
Sajrone siklus urip sumber daya Kubernetes (layanan, panyebaran, ingress, etc.), kadhangkala sampeyan kudu ngganti, nambah utawa mbusak sawetara properti saka sumber iki. Contone, nambah cathetan, nambah utawa nyuda jumlah replika.
Kubernetes CLI
Yen sampeyan wis nggarap kluster Kubernetes liwat CLI, sampeyan wis ngerti apply и edit. tim apply maca specification sumber saka file lan nggawe "upsert" kanggo cluster Kubernetes, i.e. nggawe sumber daya yen ora ana lan nganyari yen ana. Tim edit maca sumber liwat API, banjur nulis spesifikasi sumber daya menyang file lokal, sing banjur dibukak ing editor teks. Sawise sampeyan ngowahi lan nyimpen file kasebut, kubectl bakal ngirim owah-owahan sing digawe maneh liwat API, sing bakal kasebut kanthi teliti, owahan iki kanggo sumber.
Ora saben wong ngerti perintah kasebut patch и replace. tim patch ngijini sampeyan kanggo ngganti bagean saka specification sumber, nyedhiyani mung bagean diganti ing baris printah. Tim replace dianggo padha karo edit, nanging kabeh kudu ditindakake kanthi manual: sampeyan kudu ngundhuh versi spesifikasi sumber daya saiki, contone, nggunakake kubectl get -o yaml, sunting, banjur gunakake replace kanggo nganyari sumber daya miturut specification diganti. tim replace ora bakal bisa yen ana owah-owahan antarane maca lan ngganti sumber daya.
Kubernetes API
Sampeyan mbokmenawa menowo karo cara CoreV1().Pods().Update(), replaceNamespacedService utawa patch_namespaced_deployment, yen sampeyan nggarap kluster liwat nggunakake sawetara basa pamrograman. Pustaka nangani metode kasebut liwat panjalukan HTTP nggunakake metode kasebut PUT и PATCH... Ing endi update и replace nggunakake PUTlan patch, ora ketompo carane ora pati penting iku uga, migunakake PATCH.
Wigati dicathet kubectl uga dianggo karo kluster liwat API. Ing tembung liya, kubectliku pambungkus ing ndhuwur perpustakaan klien kanggo basa Go, kang umumé menehi kemampuan kanggo nyedhiyani subcommands ing wangun luwih kompak lan diwaca saliyane Kapabilitas API standar. Contone, sampeyan bisa uga wis ngeweruhi, cara apply ora kasebut ing ndhuwur ing paragraf sadurunge. Saiki (Mei 2020, kira-kira. penerjemah) kabeh logika kubectl apply, i.e. nggawe sumber daya non-ana lan nganyari ana, dianggo tanggung ing sisih kode kubectl. Upaya lagi ditindakake apply menyang sisih API, nanging isih ing beta. Aku bakal nulis luwih rinci ing ngisor iki.
Patch kanthi gawan
Paling apik digunakake patch, yen sampeyan pengin nganyari sumber daya. Iki carane loro perpustakaan klien bisa ing ndhuwur Kubernetes API lan kubectl (ora nggumunake, amarga iku pambungkus kanggo perpustakaan klien, kira-kira. penerjemah).
Kerja kanthi strategis
Kabeh tim kubectl apply, edit и patch nggunakake cara PATCH ing panjalukan HTTP kanggo nganyari sumber daya sing wis ana. Yen sampeyan nyelidiki implementasine perintah kanthi luwih rinci, mula kabeh mau nggunakake pendekatan kasebut kanggo nganyari sumber daya, sanajan printah patch bisa nggunakake pendekatan liyane (liyane ing ngisor iki). Pendekatan patching strategic-merge nyoba kanggo "mbenerake" kanthi nggabungake spesifikasi sing diwenehake karo spesifikasi sing wis ana. Luwih khusus, nyoba nggabungake obyek lan susunan, sing tegese owah-owahan cenderung dadi aditif. Contone, mbukak printah patch kanthi variabel lingkungan anyar ing spesifikasi wadhah pod, nyebabake variabel lingkungan kasebut ditambahake menyang variabel lingkungan sing ana tinimbang nimpa. Kanggo mbusak nggunakake pendekatan iki, sampeyan kudu meksa nilai parameter null ing specification kasedhiya. Kang saka tim kubectl Apa sing paling apik digunakake kanggo nganyari?
Yen sampeyan nggawe lan ngatur sumber daya nggunakake kubectl apply, nalika nganyari iku luwih apik kanggo tansah nggunakake kubectl applysupaya kubectl bisa ngatur konfigurasi lan nglacak owah-owahan sing dijaluk saka aplikasi menyang aplikasi kanthi bener. Advantage tansah digunakake apply iku nglacak specification sadurunge Applied, saéngga ngerti nalika sifat specification lan unsur Uploaded cetha dibusak. Iki ngidini sampeyan nggunakake apply kanggo mbusak sifat lan unsur Uploaded, nalika nggabung strategis normal ora bisa. tim edit и patch ora nganyari cathetan sing kubectl apply digunakake kanggo nglacak owah-owahan, supaya owah-owahan sing dilacak lan digawe liwat API Kubernetes, nanging digawe liwat printah. edit и patch, ora katon kanggo printah sakteruse apply, sing apply ora mbusak mau malah yen padha ora katon ing specification input kanggo apply (Dokumentasi kasebut ujar manawa edit и patch gawe nganyari cathetan sing digunakake apply, nanging ing laku - ora).
Yen sampeyan ora nggunakake printah apply, bisa digunakake minangka editlan patch, milih printah sing paling cocog karo owah-owahan sing ditindakake. Nalika nambah lan ngganti sifat BOM, loro pendekatan kasebut kira-kira padha. Nalika mbusak sifat spesifikasi utawa unsur array edit tumindak kaya peluncuran sepisan apply, kalebu nglacak apa spesifikasi kasebut sadurunge lan sawise diowahi, supaya sampeyan bisa kanthi jelas mbusak properti lan unsur array saka sumber daya. Sampeyan kudu tegas nyetel Nilai property kanggo null ing specification kanggo patchkanggo mbusak saka sumber. Mbusak unsur array nggunakake patching gabungan strategis luwih rumit amarga mbutuhake panggunaan arahan gabungan. Deleng pendekatan upgrade liyane ing ngisor iki kanggo alternatif sing luwih sregep.
Kanggo ngleksanakake cara nganyari ing perpustakaan klien sing tumindak padha karo printah ndhuwur kubectl, kudu disetel ing panjalukan content-type в application/strategic-merge-patch+json. Yen sampeyan pengin mbusak properti ing spesifikasi, sampeyan kudu kanthi tegas nyetel nilai kasebut dadi null kanthi cara sing padha kubectl patch. Yen sampeyan kudu mbusak unsur array, sampeyan kudu nyakup arahan gabungan ing spesifikasi nganyari utawa nggunakake pendekatan sing beda kanggo nganyari.
Pendekatan liyane kanggo nganyari
Kubernetes ndhukung rong pendekatan nganyari liyane: и . Pendekatan patch gabungan JSON njupuk spesifikasi Kubernetes parsial minangka input lan ndhukung obyek gabungan sing padha karo pendekatan patch gabungan strategis. Bentenipun antarane loro iku mung ndhukung panggantos Uploaded, kalebu Uploaded wadhah ing specification pod. Iki tegese nalika nggunakake tembelan gabungan JSON, sampeyan kudu nyedhiyani spesifikasi lengkap kanggo kabeh kontaner yen ana owah-owahan ing kontaner. Dadi pendekatan iki migunani kanggo mbusak unsur saka array ing BOM. Ing baris printah sampeyan bisa milih JSON merge patch nggunakake kubectl patch --type=merge. Nalika nggarap API Kubernetes, sampeyan kudu nggunakake metode panyuwunan PATCH lan instalasi content-type в application/merge-patch+json.
Pendekatan patch JSON, tinimbang nyedhiyakake spesifikasi sebagean saka sumber, nggunakake nyedhiyakake owah-owahan sing pengin digawe kanggo sumber daya minangka array, ing ngendi saben unsur array nggambarake gambaran saka owah-owahan sing digawe kanggo sumber. Pendekatan iki minangka cara sing luwih fleksibel lan kuat kanggo nyatakake owah-owahan sing ditindakake, nanging kanthi biaya daftar owah-owahan sing digawe ing format non-Kubernetes sing kapisah, tinimbang ngirim spesifikasi sumber daya parsial. ING kubectl sampeyan bisa milih patch JSON nggunakake kubectl patch --type=json. Nalika nggunakake API Kubernetes, pendekatan iki bisa digunakake kanthi cara panyuwunan PATCH lan instalasi content-type в application/json-patch+json.
We kudu kapercayan - nggunakake ngganti
Ing sawetara kasus, sampeyan kudu mesthekake yen ora ana owah-owahan ing sumber daya antarane wektu sumber kasebut diwaca lan nalika dianyari. Ing tembung liyane, sampeyan kudu nggawe manawa kabeh owah-owahan bakal atom. Ing kasus iki, kanggo nganyari sumber daya sampeyan kudu nggunakake replace. Contone, yen sampeyan duwe ConfigMap karo counter sing dianyari dening macem-macem sumber, sampeyan kudu nggawe manawa loro sumber ora nganyari counter ing wektu sing padha, nyebabake nganyari kanggo ilang. Kanggo nduduhake, bayangake urutan acara nggunakake pendekatan kasebut patch:
- A lan B entuk status sumber daya saiki saka API
- Saben wong nganyari spesifikasi kanthi nambah siji counter lan uga nambahake "A" utawa "B" menyang cathetan "dianyari".
- Lan nganyari sumber daya luwih cepet
- B nganyari sumber daya
Akibaté, nganyari A ilang. Operasi pungkasan patch menang , counter incremented dening siji tinimbang loro, lan Nilai saka cathetan "dianyari-by" ends karo "B" lan ora ngemot "A". Ayo mbandhingake ing ndhuwur karo apa sing kedadeyan nalika nganyari rampung nggunakake pendekatan kasebut replace:
- A lan B entuk status sumber daya saiki saka API
- Saben wong nganyari spesifikasi kanthi nambah siji counter lan uga nambahake "A" utawa "B" menyang cathetan "dianyari".
- Lan nganyari sumber daya luwih cepet
- B nyoba nganyari sumber daya, nanging nganyari ditolak dening API amarga versi sumber ing specification
replaceora cocog karo versi saiki sumber daya ing Kubernetes amarga versi sumber daya tambah dening operasi ngganti A.
Ing kasus ing ndhuwur, B kudu njupuk maneh sumber daya, owah-owahan menyang negara anyar lan nyoba maneh replace. Iki bakal nyebabake counter ditambah loro lan cathetan "dianyari" kalebu "AB" ing pungkasan.
Conto ing ndhuwur tegese nalika nglakokake replace Kabeh sumber wis rampung diganti. Spesifikasi digunakake kanggo replace, ora kudu parsial, utawa ing bagean kaya ing apply, nanging lengkap, kalebu tambahan resourceVersion menyang metadata spesifikasi. Yen sampeyan durung ngaktifake resourceVersion utawa versi sing diwenehake ora saiki, panggantos bakal ditolak. Dadi pendekatan sing paling apik kanggo nggunakake yaiku replace – maca sumber, nganyari lan ngganti langsung. nggunakake kubectl, bisa uga katon kaya iki:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Wigati dicathet yen rong printah ing ngisor iki, sing dieksekusi sacara berurutan, bakal dieksekusi kanthi sukses, amarga deployment.yaml ora ngemot properti .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlIki bakal koyone mbantah apa sing diomongake ing ndhuwur, yaiku. "tambah resourceVersion menyang metadata spesifikasi." Apa salah ngomong? Ora, ora, amarga yen kubectl kabar sing sampeyan ora nemtokake resourceVersion, bakal diwaca saka sumber lan ditambahake menyang spesifikasi sing sampeyan temtokake, lan mung banjur nglakokake replace. Amarga iki duweni potensi mbebayani yen sampeyan ngandelake atomicity, sihir bisa digunakake ing sisih kubectl, sampeyan ora kudu ngandelake nalika nggunakake perpustakaan klien sing bisa digunakake karo API. Ing kasus iki, sampeyan kudu maca spesifikasi sumber daya saiki, nganyari banjur eksekusi PUT panyuwunan.
Sampeyan ora bisa nindakake tembelan - kita ngganti
Kadhangkala sampeyan kudu nggawe sawetara owah-owahan sing ora bisa ditangani dening API. Ing kasus kasebut, sampeyan bisa meksa ngganti sumber daya kanthi mbusak lan nggawe maneh. Iki rampung nggunakake kubectl replace --force. Nglakokake printah kasebut langsung mbusak sumber daya lan banjur nggawe maneh saka spesifikasi sing diwenehake. Ora ana "pasukan ngganti" handler ing API, lan kanggo nindakake liwat API, sampeyan kudu nindakake rong operasi. Pisanan sampeyan kudu mbusak sumber kanthi nyetel gracePeriodSeconds kanggo nul (0) lan propagationPolicy ing "Latar mburi" banjur gawe maneh sumber daya iki karo specification dikarepake.
Pènget: Pendekatan iki bisa mbebayani lan bisa nyebabake kahanan sing ora ditemtokake.
Aplikasi ing sisih server
Kaya sing kasebut ing ndhuwur, pangembang Kubernetes ngupayakake ngetrapake logika kasebut apply saka kubectl ing Kubernetes API. Logika apply kasedhiya ing Kubernetes 1.18 liwat kubectl apply --server-side utawa liwat API nggunakake cara PATCH с content-type application/apply-patch+YAML.
Cathetan: JSON uga YAML sing bener, supaya sampeyan bisa ngirim spesifikasi minangka JSON sanajan
content-typebakalapplication/apply-patch+yaml.
Saliyane logika kasebut kubectl kasedhiya kanggo kabeh wong liwat API, apply ing sisih server, nglacak sing tanggung jawab kanggo lapangan ing specification, saéngga ngidini sawetara akses aman kanggo editing konflik-free sawijining. Ing tembung liyane, yen apply ing sisih server bakal dadi luwih nyebar, antarmuka manajemen sumber daya aman universal bakal katon kanggo klien sing beda-beda, contone, kubectl, Pulumi utawa Terraform, GitOps, uga skrip sing ditulis dhewe nggunakake perpustakaan klien.
Hasil
Muga-muga ringkesan singkat babagan macem-macem cara nganyari sumber daya ing klompok bisa mbantu sampeyan. Iku apik kanggo ngerti yen ora mung ditrapake tinimbang ngganti; sampeyan bisa nganyari sumber daya nggunakake aplikasi, sunting, tembelan, utawa ngganti. Sawise kabeh, ing prinsip, saben pendekatan duwe area aplikasi dhewe. Kanggo owah-owahan atom, ganti luwih becik; yen ora, sampeyan kudu nggunakake patch gabungan strategis liwat aplikasi. Paling ora, aku ngarepake sampeyan ngerti yen sampeyan ora bisa dipercaya Google utawa StackOerflow nalika nggoleki "kubernetes apply vs replace". Paling ora nganti artikel iki ngganti jawaban saiki.
Source: www.habr.com