🥇Tamang paghahambing ng Kubernetes Apply, Palitan at Patch

Ang Kubernetes ay may ilang mga opsyon para sa pag-update ng mga mapagkukunan: ilapat, i-edit, i-patch at palitan. May pagkalito tungkol sa kung ano ang ginagawa ng bawat isa at kung kailan ito gagamitin. Alamin natin ito.

Kung maghanap sa Google ang pariralang "kubernetes apply vs replace" ay matatagpuan tumugon sa StackOverflow, na hindi tama. Kapag naghahanap "kubernetes apply vs patch" ang unang link ay ang dokumentasyon para sa kubectl patch, na hindi kasama ang paghahambing apply и patch. Ang artikulong ito ay titingnan ang iba't ibang mga opsyon, pati na rin ang wastong paggamit ng bawat isa.

Sa panahon ng lifecycle ng isang mapagkukunan ng Kubernetes (serbisyo, pag-deploy, pagpasok, atbp.), minsan kailangan mong baguhin, magdagdag o mag-alis ng ilang mga katangian ng mapagkukunang ito. Halimbawa, magdagdag ng tala, dagdagan o bawasan ang bilang ng mga replika.

Kubernetes CLI

Kung nagtatrabaho ka na sa mga kumpol ng Kubernetes sa pamamagitan ng CLI, pamilyar ka na apply и edit. Koponan apply binabasa ang detalye ng mapagkukunan mula sa file at gumagawa ng "upsert" sa cluster ng Kubernetes, i.e. lumilikha ng mapagkukunan kung wala ito at ina-update ito kung mayroon. Koponan edit nagbabasa ng mapagkukunan sa pamamagitan ng API, pagkatapos ay isusulat ang detalye ng mapagkukunan sa isang lokal na file, na pagkatapos ay binuksan sa isang text editor. Pagkatapos mong i-edit at i-save ang file, kubectl ay ibabalik ang mga pagbabagong ginawa sa pamamagitan ng API, na maingat na ilalapat ang mga pagbabagong ito sa mapagkukunan.

Hindi alam ng lahat ang mga utos patch и replace. Koponan patch nagbibigay-daan sa iyo na baguhin ang bahagi ng isang detalye ng mapagkukunan, na nagbibigay lamang ng binagong bahagi sa command line. Koponan replace gumagana katulad ng edit, ngunit ang lahat ay kailangang gawin nang manu-mano: kailangan mong i-download ang kasalukuyang bersyon ng pagtutukoy ng mapagkukunan, halimbawa, gamit ang kubectl get -o yaml, i-edit ito, pagkatapos ay gamitin replace upang i-update ang isang mapagkukunan ayon sa isang binagong detalye. Koponan replace hindi gagana kung may anumang pagbabagong naganap sa pagitan ng pagbabasa at pagpapalit ng mapagkukunan.

Kubernetes API

Marahil ay pamilyar ka sa mga pamamaraan CoreV1().Pods().Update(), replaceNamespacedService o patch_namespaced_deployment, kung nagtatrabaho ka sa mga kumpol sa pamamagitan ng library ng kliyente para sa Kubernetes API gamit ang ilang programming language. Pinangangasiwaan ng library ang mga pamamaraang ito sa pamamagitan ng mga kahilingan sa HTTP gamit ang mga pamamaraan PUT и PATCH... Kung saan update и replace gamitin PUTAt patch, gaano man ito kahalaga, ginagamit PATCH.

Dapat ito ay nabanggit na kubectl gumagana din sa mga kumpol sa pamamagitan ng API. Sa ibang salita, kubectlay isang wrapper sa ibabaw ng client library para sa Go language, na higit na nagbibigay ng kakayahang magbigay ng mga subcommand sa mas compact at nababasang form bilang karagdagan sa mga karaniwang kakayahan ng API. Halimbawa, tulad ng maaaring napansin mo na, ang pamamaraan apply ay hindi nabanggit sa itaas sa nakaraang talata. Sa kasalukuyan (Mayo 2020, tinatayang tagasalin) lahat ng lohika kubectl apply, ibig sabihin. paglikha ng mga hindi umiiral na mapagkukunan at pag-update ng mga umiiral na, ganap na gumagana sa gilid ng code kubectl. Ang mga pagsisikap ay ginagawa sa paglipat ng lohika apply sa gilid ng API, ngunit nasa beta pa rin ito. Isusulat ko nang mas detalyado sa ibaba.

Patch bilang default

Pinakamahusay na ginamit patch, kung gusto mong i-update ang mapagkukunan. Ito ay kung paano gumagana ang parehong client library sa itaas ng Kubernetes API at kubectl (hindi nakakagulat, dahil ito ay isang wrapper para sa client library, tinatayang tagasalin).

Magtrabaho nang madiskarte

Lahat ng team kubectl apply, edit и patch gamitin ang pamamaraan PATCH sa mga kahilingan ng HTTP na i-update ang isang kasalukuyang mapagkukunan. Kung susuriin mo ang pagpapatupad ng mga utos nang mas detalyado, lahat ng mga ito ay gumagamit ng diskarte estratehikong pagsasama-sama ng patching upang i-update ang mga mapagkukunan, kahit na ang command patch maaaring gumamit ng iba pang mga diskarte (higit pa dito sa ibaba). Sinusubukan ng strategic-merge na patching approach na "itama ito" sa pamamagitan ng pagsasama ng ibinigay na detalye sa kasalukuyang detalye. Higit na partikular, sinusubukan nitong pagsamahin ang parehong mga bagay at array, na nangangahulugang ang mga pagbabago ay may posibilidad na maging additive. Halimbawa, ang pagpapatakbo ng command patch na may bagong environment variable sa pod container specification, nagiging sanhi ng environment variable na iyon na maidagdag sa mga kasalukuyang environment variable sa halip na i-overwrite ang mga ito. Upang alisin gamit ang diskarteng ito, dapat mong pilitin ang halaga ng parameter sa null sa ibinigay na detalye. Alin sa mga koponan kubectl Ito ba ay pinakamahusay na gamitin para sa pag-update?

Kung gagawa at pinamamahalaan mo ang iyong mga mapagkukunan gamit ang kubectl apply, kapag nag-a-update ito ay mas mahusay na palaging gamitin kubectl applySa kubectl maaaring pamahalaan ang configuration at maayos na subaybayan ang mga hiniling na pagbabago mula sa application patungo sa application. Advantage laging gamitin apply ay na sinusubaybayan nito ang isang dating inilapat na detalye, na nagbibigay-daan dito na malaman kapag ang mga katangian ng detalye at mga elemento ng array ay tahasang inalis. Ito ay nagpapahintulot sa iyo na gamitin apply upang alisin ang mga katangian at elemento ng array, habang ang isang normal na strategic merge ay hindi gagana. Mga koponan edit и patch huwag i-update ang mga tala na kubectl apply ginagamit upang subaybayan ang mga pagbabago nito, kaya ang anumang mga pagbabago na sinusubaybayan at ginawa sa pamamagitan ng Kubernetes API, ngunit ginawa sa pamamagitan ng mga command edit и patch, hindi nakikita ng mga kasunod na utos applyIyon ay, apply ay hindi nag-aalis ng mga ito kahit na hindi sila lumabas sa detalye ng input para sa apply (Ang dokumentasyon ay nagsasabi na edit и patch gumawa ng mga update sa mga tala na ginamit apply, ngunit sa pagsasanay - hindi).

Kung hindi mo gagamitin ang command apply, ay maaaring gamitin bilang editAt patch, pagpili ng command na pinakaangkop sa pagbabagong ginagawa. Kapag nagdaragdag at nagbabago ng mga katangian ng BOM, ang parehong mga diskarte ay halos pareho. Kapag nagtatanggal ng mga katangian ng pagtutukoy o mga elemento ng array edit kumikilos tulad ng isang beses na paglulunsad apply, kabilang ang pagsubaybay sa kung ano ang hitsura ng detalye bago at pagkatapos itong i-edit, para tahasan mong maalis ang mga property at elemento ng array mula sa isang mapagkukunan. Kailangan mong tahasang itakda ang halaga ng ari-arian sa null sa detalye para sa patchupang alisin ito mula sa mapagkukunan. Ang pag-alis ng elemento ng array gamit ang strategic-merge na patching ay mas kumplikado dahil nangangailangan ito ng paggamit ng mga merge na direktiba. Tingnan ang iba pang mga diskarte sa pag-upgrade sa ibaba para sa mas mabubuhay na mga alternatibo.

Upang ipatupad ang mga paraan ng pag-update sa library ng kliyente na kumikilos nang katulad ng mga utos sa itaas kubectl, ay dapat itakda sa mga kahilingan content-type в application/strategic-merge-patch+json. Kung gusto mong alisin ang mga katangian sa isang detalye, kailangan mong tahasang itakda ang kanilang mga halaga sa null sa katulad na paraan kubectl patch. Kung kailangan mong mag-alis ng mga elemento ng array, dapat mong isama ang mga merge na direktiba sa detalye ng update o gumamit ng ibang diskarte sa mga update.

Iba pang mga diskarte sa mga update

Sinusuportahan ng Kubernetes ang dalawang iba pang mga diskarte sa pag-update: JSON merge patch и JSON patch. Ang JSON merge patch na diskarte ay tumatagal ng isang bahagyang detalye ng Kubernetes bilang input at sumusuporta sa pagsasama-sama ng mga bagay na katulad ng diskarte sa pag-patch ng strategic-merge. Ang pagkakaiba sa pagitan ng dalawa ay sinusuportahan lamang nito ang pagpapalit ng array, kabilang ang array ng container sa detalye ng pod. Nangangahulugan ito na kapag gumagamit ng JSON merge patch, kailangan mong magbigay ng kumpletong mga detalye para sa lahat ng container kung sakaling magbago ang anumang property ng anumang container. Kaya ang diskarte na ito ay kapaki-pakinabang para sa pag-alis ng mga elemento mula sa isang array sa isang BOM. Sa command line maaari mong piliin ang JSON merge patch gamit kubectl patch --type=merge. Kapag nagtatrabaho sa Kubernetes API, dapat mong gamitin ang paraan ng paghiling PATCH at pag-install content-type в application/merge-patch+json.

Ang diskarte sa patch ng JSON, sa halip na magbigay ng bahagyang detalye ng isang mapagkukunan, ay gumagamit ng pagbibigay ng mga pagbabagong gusto mong gawin sa mapagkukunan bilang isang array, kung saan ang bawat elemento ng array ay kumakatawan sa isang paglalarawan ng pagbabagong ginagawa sa mapagkukunan. Ang diskarte na ito ay isang mas nababaluktot at makapangyarihang paraan upang ipahayag ang mga pagbabagong ginagawa, ngunit sa halaga ng paglilista ng mga pagbabagong ginagawa sa isang hiwalay, hindi Kubernetes na format, sa halip na magpadala ng bahagyang detalye ng mapagkukunan. SA kubectl maaari mong piliin ang JSON patch gamit kubectl patch --type=json. Kapag ginagamit ang Kubernetes API, gumagana ang diskarteng ito gamit ang paraan ng paghiling PATCH at pag-install content-type в application/json-patch+json.

Kailangan namin ng kumpiyansa - gamitin ang palitan

Sa ilang mga kaso, kailangan mong tiyakin na walang mga pagbabagong ginawa sa isang mapagkukunan sa pagitan ng oras na nabasa ang mapagkukunan at kapag ito ay na-update. Sa madaling salita, dapat mong tiyakin na ang lahat ng mga pagbabago ay magiging atomic. Sa kasong ito, upang i-update ang mga mapagkukunan na dapat mong gamitin replace. Halimbawa, kung mayroon kang ConfigMap na may counter na ina-update ng maraming source, dapat mong tiyakin na hindi ina-update ng dalawang source ang counter nang sabay, na nagiging sanhi ng pagkawala ng update. Upang ipakita, isipin ang isang pagkakasunud-sunod ng mga kaganapan gamit ang diskarte patch:

Nakukuha ng A at B ang kasalukuyang estado ng mapagkukunan mula sa API
Lokal na ina-update ng bawat isa ang detalye sa pamamagitan ng pagdaragdag ng counter ng isa at pagdaragdag din ng "A" o "B" ayon sa pagkakabanggit sa "updated-by" na tala
At ina-update nito ang mapagkukunan nang mas mabilis
Ina-update ni B ang mapagkukunan

Bilang resulta, nawala ang update A. Huling operasyon patch mananalo, ang counter ay dinadagdagan ng isa sa halip na dalawa, at ang halaga ng "updated-by" na tala ay nagtatapos sa "B" at hindi naglalaman ng "A". Ihambing natin ang nasa itaas sa kung ano ang mangyayari kapag ang mga pag-update ay ginawa gamit ang diskarte replace:

Nakukuha ng A at B ang kasalukuyang estado ng mapagkukunan mula sa API
Lokal na ina-update ng bawat isa ang detalye sa pamamagitan ng pagdaragdag ng counter ng isa at pagdaragdag din ng "A" o "B" ayon sa pagkakabanggit sa "updated-by" na tala
At ina-update nito ang mapagkukunan nang mas mabilis
Sinusubukan ni B na i-update ang mapagkukunan, ngunit ang pag-update ay tinanggihan ng API dahil ang bersyon ng mapagkukunan ay nasa detalye replace ay hindi tumutugma sa kasalukuyang bersyon ng mapagkukunan sa Kubernetes dahil ang bersyon ng mapagkukunan ay nadagdagan ng pagpapalit ng operasyon ng A.

Sa kaso sa itaas, kakailanganing kunin muli ni B ang mapagkukunan, gumawa ng mga pagbabago sa bagong estado at subukang muli replace. Ito ay magiging sanhi ng counter na madagdagan ng dalawa at ang "updated-by" na tala ay magsasama ng "AB" sa dulo.

Ang halimbawa sa itaas ay nagpapahiwatig na kapag nagsasagawa replace Ang buong mapagkukunan ay ganap na pinalitan. Ang pagtutukoy na ginamit para sa replace, hindi dapat bahagyang, o sa mga bahagi tulad ng sa apply, ngunit kumpleto, kasama ang karagdagan resourceVersion sa metadata ng detalye. Kung hindi mo pa pinagana resourceVersion o ang bersyon na iyong ibinigay ay hindi kasalukuyan, ang kapalit ay tatanggihan. Kaya ang pinakamahusay na diskarte upang gamitin ay replace – basahin ang mapagkukunan, i-update ito at palitan kaagad. Gamit kubectl, maaaring ganito ang hitsura:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

Kapansin-pansin na ang sumusunod na dalawang utos, na isinagawa nang sunud-sunod, ay matagumpay na maipapatupad, dahil deployment.yaml ay hindi naglalaman ng ari-arian .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

Ito ay tila salungat sa sinabi sa itaas, i.e. "dagdag resourceVersion sa metadata ng detalye." Mali bang sabihin iyon? Hindi, hindi, dahil kung kubectl mga abiso na hindi mo tinukoy resourceVersion, babasahin ito mula sa mapagkukunan at idagdag ito sa pagtutukoy na iyong tinukoy, at pagkatapos lamang isagawa ito replace. Dahil ito ay potensyal na mapanganib kung umaasa ka sa atomicity, ang magic ay ganap na gumagana sa gilid kubectl, hindi ka dapat umasa dito kapag gumagamit ng mga library ng kliyente na gumagana sa API. Sa kasong ito, kakailanganin mong basahin ang kasalukuyang detalye ng mapagkukunan, i-update ito at pagkatapos ay isagawa PUT kahilingan.

Hindi ka maaaring gumawa ng isang patch - gumawa kami ng isang kapalit

Minsan kailangan mong gumawa ng ilang pagbabago na hindi maaaring pangasiwaan ng API. Sa mga kasong ito, maaari mong pilitin na palitan ang mapagkukunan sa pamamagitan ng pagtanggal at muling paggawa nito. Ginagawa ito gamit ang kubectl replace --force. Ang pagpapatakbo ng command ay agad na nag-aalis ng mga mapagkukunan at pagkatapos ay muling likhain ang mga ito mula sa ibinigay na detalye. Walang "force replace" handler sa API, at para magawa ito sa pamamagitan ng API, kailangan mong magsagawa ng dalawang operasyon. Una kailangan mong tanggalin ang mapagkukunan sa pamamagitan ng pagtatakda para dito gracePeriodSeconds sa zero (0) at propagationPolicy sa "Background" at pagkatapos ay muling likhain ang mapagkukunang ito gamit ang nais na detalye.

Babala: Ang diskarte na ito ay potensyal na mapanganib at maaaring humantong sa isang hindi natukoy na estado.

Mag-apply sa gilid ng server

Tulad ng nabanggit sa itaas, ang mga developer ng Kubernetes ay nagtatrabaho sa pagpapatupad ng lohika apply ng kubectl sa Kubernetes API. Logics apply magagamit sa Kubernetes 1.18 sa pamamagitan ng kubectl apply --server-side o sa pamamagitan ng API gamit ang pamamaraan PATCH с content-type application/apply-patch+YAML.

Tandaan: Ang JSON ay wastong YAML din, kaya maaari mong ipadala ang detalye bilang JSON kahit na content-type kalooban application/apply-patch+yaml.

Bukod sa logic na iyon kubectl magiging available sa lahat sa pamamagitan ng API, apply sa panig ng server, sinusubaybayan kung sino ang responsable para sa mga patlang sa detalye, kaya nagbibigay-daan sa secure na maramihang pag-access para sa walang salungat na pag-edit nito. Sa madaling salita, kung apply sa panig ng server ay magiging mas laganap, isang unibersal na secure na interface ng pamamahala ng mapagkukunan ay lilitaw para sa iba't ibang mga kliyente, halimbawa, kubectl, Pulumi o Terraform, GitOps, pati na rin ang mga self-written na script gamit ang mga library ng kliyente.

Mga resulta ng

Umaasa akong nakatulong sa iyo ang maikling pangkalahatang-ideya ng iba't ibang paraan ng pag-update ng mga mapagkukunan sa mga cluster. Magandang malaman na hindi lang ito nalalapat kumpara sa palitan; posibleng mag-update ng mapagkukunan gamit ang paglalapat, pag-edit, pag-patch, o pagpapalit. Pagkatapos ng lahat, sa prinsipyo, ang bawat diskarte ay may sariling lugar ng aplikasyon. Para sa mga pagbabago sa atomic, mas mainam na palitan; kung hindi, dapat mong gamitin ang strategic-merge patch sa pamamagitan ng pag-apply. Hindi bababa sa, inaasahan kong mauunawaan mo na hindi mo mapagkakatiwalaan ang Google o StackOerflow kapag naghahanap ng "kubernetes apply vs replace". Hindi bababa sa hanggang sa palitan ng artikulong ito ang kasalukuyang sagot.

Pinagmulan: www.habr.com

Wastong Paghahambing ng Kubernetes Apply, Palitan at Patch