Mae gan Kubernetes sawl opsiwn ar gyfer diweddaru adnoddau: cymhwyso, golygu, clytio a disodli. Mae dryswch ynghylch beth mae pob un yn ei wneud a phryd i'w defnyddio. Gadewch i ni chyfrif i maes.
Os mae'r ymadrodd "kubernetes apply vs replace" wedi'i leoli , sydd ddim yn gywir. "kubernetes apply vs patch" y ddolen gyntaf yw'r ddogfennaeth kubectl patch, nad yw'n cynnwys cymhariaeth apply и patch. Bydd yr erthygl hon yn edrych ar y gwahanol opsiynau, yn ogystal â'r defnydd cywir o bob un.
Yn ystod cylch bywyd adnodd Kubernetes (gwasanaeth, defnydd, mynediad, ac ati), weithiau mae angen i chi newid, ychwanegu neu ddileu rhai o briodweddau'r adnodd hwn. Er enghraifft, ychwanegu nodyn, cynyddu neu leihau nifer y copïau.
Kubernetes CLI
Os ydych chi eisoes yn gweithio gyda chlystyrau Kubernetes trwy'r CLI, rydych chi eisoes yn gyfarwydd ag ef apply и edit. Tîm apply yn darllen y fanyleb adnoddau o'r ffeil ac yn gwneud "ofid" i glwstwr Kubernetes, h.y. yn creu'r adnodd os nad yw'n bodoli ac yn ei ddiweddaru os yw'n bodoli. Tîm edit yn darllen adnodd trwy'r API, yna'n ysgrifennu'r fanyleb adnoddau i ffeil leol, sydd wedyn yn cael ei hagor mewn golygydd testun. Ar ôl i chi olygu a chadw'r ffeil, kubectl yn anfon y newidiadau a wnaed yn ôl trwy'r API, a fydd yn cymhwyso'r newidiadau hyn yn ofalus i'r adnodd.
Nid yw pawb yn gwybod y gorchmynion patch и replace. Tîm patch yn eich galluogi i newid rhan o fanyleb adnodd, gan ddarparu dim ond y rhan sydd wedi'i newid ar y llinell orchymyn. Tîm replace yn gweithio yr un fath â edit, ond mae angen gwneud popeth â llaw: mae angen i chi lawrlwytho'r fersiwn gyfredol o'r fanyleb adnoddau, er enghraifft, defnyddio kubectl get -o yaml, ei olygu, yna defnyddiwch replace diweddaru adnodd yn unol â manyleb wedi'i newid. Tîm replace Ni fydd yn gweithio os digwyddodd unrhyw newidiadau rhwng darllen a disodli'r adnodd.
Kubernetes API
Mae'n debyg eich bod yn gyfarwydd â'r dulliau CoreV1().Pods().Update(), replaceNamespacedService neu patch_namespaced_deployment, os ydych yn gweithio gyda chlystyrau trwy defnyddio rhywfaint o iaith raglennu. Mae'r llyfrgell yn trin y dulliau hyn trwy geisiadau HTTP gan ddefnyddio'r dulliau PUT и PATCH... Lle update и replace defnyddiwch PUTAc patch, ni waeth pa mor ddibwys y gall fod, yn defnyddio PATCH.
Dylid nodi bod kubectl hefyd yn gweithio gyda chlystyrau trwy API. Mewn geiriau eraill, kubectlyn ddeunydd lapio ar ben y llyfrgell cleientiaid ar gyfer yr iaith Go, sydd i raddau helaeth yn darparu'r gallu i ddarparu is-orchmynion mewn ffurf fwy cryno a darllenadwy yn ychwanegol at y galluoedd API safonol. Er enghraifft, fel efallai eich bod eisoes wedi sylwi, y dull apply nas crybwyllwyd uchod yn y paragraff blaenorol. Ar hyn o bryd (Mai 2020, tua. cyfieithydd) pob rhesymeg kubectl apply, h.y. creu adnoddau nad ydynt yn bodoli a diweddaru rhai presennol, yn gweithio'n gyfan gwbl ar ochr y cod kubectl. Mae ymdrechion yn cael eu gwneud apply i ochr API, ond mae'n dal i fod yn beta. Ysgrifennaf yn fanylach isod.
Patch yn ddiofyn
Wedi'i ddefnyddio orau patch, os ydych am ddiweddaru'r adnodd. Dyma sut mae'r ddwy lyfrgell cleient yn gweithio ar ben API Kubernetes a kubectl (nid yw'n syndod, gan ei fod yn ddeunydd lapio ar gyfer y llyfrgell cleientiaid, tua. cyfieithydd).
Gweithio'n strategol
Pob tîm kubectl apply, edit и patch defnyddio'r dull PATCH mewn ceisiadau HTTP i ddiweddaru adnodd sy'n bodoli eisoes. Os ydych chi'n ymchwilio i weithrediad gorchmynion yn fwy manwl, yna mae pob un ohonynt yn defnyddio'r dull i ddiweddaru adnoddau, er bod y gorchymyn patch Gall ddefnyddio dulliau eraill (mwy am hyn isod). Mae'r dull clytio uno strategol yn ceisio "gwneud pethau'n iawn" trwy gyfuno'r fanyleb a ddarparwyd â'r fanyleb bresennol. Yn fwy penodol, mae'n ceisio cyfuno gwrthrychau ac araeau, sy'n golygu bod y newidiadau yn tueddu i fod yn ychwanegyn. Er enghraifft, rhedeg y gorchymyn patch gyda newidyn amgylchedd newydd yn y fanyleb cynhwysydd pod, yn achosi i'r newidyn amgylchedd hwnnw gael ei ychwanegu at y newidynnau amgylchedd presennol yn hytrach na'u trosysgrifo. I ddileu gan ddefnyddio'r dull hwn, rhaid i chi orfodi gwerth y paramedr i null yn y fanyleb a ddarperir. Pa un o'r timau kubectl A yw'n well ei ddefnyddio ar gyfer diweddaru?
Os ydych chi'n creu ac yn rheoli'ch adnoddau gan ddefnyddio kubectl apply, wrth ddiweddaru mae'n well ei ddefnyddio bob amser kubectl applyI kubectl yn gallu rheoli cyfluniad ac olrhain newidiadau y gofynnir amdanynt yn gywir o'r cais i'r cymhwysiad. Mantais bob amser yn defnyddio apply yw ei fod yn cadw golwg ar fanyleb a gymhwyswyd yn flaenorol, gan ganiatáu iddo wybod pryd mae priodweddau manyleb ac elfennau arae yn cael eu tynnu'n benodol. Mae hyn yn eich galluogi i ddefnyddio apply i gael gwared ar eiddo ac elfennau arae, tra na fydd uno strategol arferol yn gweithio. Timau edit и patch peidiwch â diweddaru nodiadau hynny kubectl apply defnyddio i olrhain ei newidiadau, felly unrhyw newidiadau sy'n cael eu holrhain a'u gwneud trwy API Kubernetes, ond a wneir trwy orchmynion edit и patch, yn anweledig i orchmynion dilynol applyHynny yw, apply nid yw'n eu dileu hyd yn oed os nad ydynt yn ymddangos yn y fanyleb mewnbwn ar gyfer apply (Mae'r ddogfennaeth yn dweud hynny edit и patch gwneud diweddariadau i'r nodiadau a ddefnyddiwyd apply, ond yn ymarferol - dim).
Os na ddefnyddiwch y gorchymyn apply, gellir ei ddefnyddio fel editAc patch, gan ddewis y gorchymyn sy'n gweddu orau i'r newid sy'n cael ei wneud. Wrth ychwanegu a newid priodweddau BOM, mae'r ddau ddull yn fras yr un peth. Wrth ddileu priodweddau manyleb neu elfennau arae edit yn ymddwyn fel lansiad un-amser apply, gan gynnwys cadw golwg ar sut oedd y fanyleb cyn ac ar ôl iddi gael ei golygu, fel y gallwch gael gwared ar briodweddau ac elfennau arae o adnodd yn benodol. Mae angen i chi osod gwerth yr eiddo yn nwl yn benodol yn y fanyleb ar gyfer patchi'w dynnu o'r adnodd. Mae cael gwared ar elfen arae gan ddefnyddio clytio uno strategol yn fwy cymhleth oherwydd mae angen defnyddio cyfarwyddebau uno. Gweler dulliau uwchraddio eraill isod am ddewisiadau amgen mwy hyfyw.
Gweithredu dulliau diweddaru yn y llyfrgell cleientiaid sy'n ymddwyn yn debyg i'r gorchmynion uchod kubectl, dylid eu gosod mewn ceisiadau content-type в application/strategic-merge-patch+json. Os ydych chi am gael gwared ar eiddo mewn manyleb, mae angen i chi osod eu gwerthoedd i null yn benodol mewn ffordd debyg kubectl patch. Os oes angen i chi gael gwared ar elfennau arae, dylech gynnwys cyfarwyddebau uno yn y fanyleb diweddaru neu ddefnyddio ymagwedd wahanol at ddiweddariadau.
Dulliau eraill o roi diweddariadau
Mae Kubernetes yn cefnogi dau ddull diweddaru arall: и . Mae dull patsh uno JSON yn cymryd manyleb Kubernetes rhannol fel mewnbwn ac yn cefnogi gwrthrychau sy'n uno tebyg i'r dull clytio uno strategol. Y gwahaniaeth rhwng y ddau yw ei fod yn cefnogi amnewid arae yn unig, gan gynnwys yr arae cynhwysydd yn y fanyleb pod. Mae hyn yn golygu, wrth ddefnyddio darn uno JSON, bod angen i chi ddarparu manylebau cyflawn ar gyfer pob cynhwysydd rhag ofn y bydd unrhyw eiddo i unrhyw gynhwysydd yn newid. Felly mae'r dull hwn yn ddefnyddiol ar gyfer tynnu elfennau o arae mewn BOM. Ar y llinell orchymyn gallwch ddewis clwt uno JSON gan ddefnyddio kubectl patch --type=merge. Wrth weithio gydag API Kubernetes, dylech ddefnyddio'r dull cais PATCH a gosod content-type в application/merge-patch+json.
Mae dull clwt JSON, yn hytrach na darparu manyleb rannol o adnodd, yn defnyddio darparu'r newidiadau yr ydych am eu gwneud i'r adnodd fel arae, lle mae pob elfen o'r arae yn cynrychioli disgrifiad o'r newid sy'n cael ei wneud i'r adnodd. Mae'r dull hwn yn ffordd fwy hyblyg a phwerus o fynegi'r newidiadau sy'n cael eu gwneud, ond ar draul rhestru'r newidiadau sy'n cael eu gwneud mewn fformat ar wahân, nad yw'n fformat Kubernetes, yn hytrach nag anfon manyleb adnoddau rhannol. YN kubectl gallwch ddewis clwt JSON gan ddefnyddio kubectl patch --type=json. Wrth ddefnyddio API Kubernetes, mae'r dull hwn yn gweithio gan ddefnyddio'r dull cais PATCH a gosod content-type в application/json-patch+json.
Mae angen hyder arnom - defnyddiwch gymryd lle
Mewn rhai achosion, mae angen i chi fod yn siŵr na wneir unrhyw newidiadau i adnodd rhwng yr amser y darllenir yr adnodd a phan gaiff ei ddiweddaru. Mewn geiriau eraill, dylech sicrhau y bydd yr holl newidiadau atomig. Yn yr achos hwn, i ddiweddaru adnoddau y dylech eu defnyddio replace. Er enghraifft, os oes gennych ConfigMap gyda chownter sy'n cael ei ddiweddaru gan ffynonellau lluosog, dylech fod yn siŵr nad yw dwy ffynhonnell yn diweddaru'r cownter ar yr un pryd, gan achosi i'r diweddariad gael ei golli. I ddangos, dychmygwch ddilyniant o ddigwyddiadau gan ddefnyddio'r ymagwedd patch:
- Mae A a B yn cael cyflwr presennol yr adnodd o'r API
- Mae pob un yn diweddaru'r fanyleb yn lleol trwy gynyddu'r cownter fesul un a hefyd ychwanegu "A" neu "B" yn y drefn honno i'r nodyn "diweddaru-by"
- Ac mae'n diweddaru'r adnodd ychydig yn gyflymach
- Mae B yn diweddaru'r adnodd
O ganlyniad, mae diweddariad A yn cael ei golli. Y llawdriniaeth ddiwethaf patch yn ennill, mae'r cownter yn cael ei gynyddu gan un yn lle dau, ac mae gwerth y nodyn "wedi'i ddiweddaru gan" yn gorffen gyda "B" ac nid yw'n cynnwys "A". Gadewch i ni gymharu'r uchod â'r hyn sy'n digwydd pan fydd diweddariadau yn cael eu gwneud gan ddefnyddio'r dull replace:
- Mae A a B yn cael cyflwr presennol yr adnodd o'r API
- Mae pob un yn diweddaru'r fanyleb yn lleol trwy gynyddu'r cownter fesul un a hefyd ychwanegu "A" neu "B" yn y drefn honno i'r nodyn "diweddaru-by"
- Ac mae'n diweddaru'r adnodd ychydig yn gyflymach
- Mae B yn ceisio diweddaru'r adnodd, ond mae'r diweddariad yn cael ei wrthod gan yr API oherwydd bod y fersiwn adnoddau yn y fanyleb
replaceNid yw'n cyfateb i fersiwn gyfredol yr adnodd yn Kubernetes oherwydd cynyddwyd y fersiwn o'r adnodd gan weithrediad disodli A.
Yn yr achos uchod, bydd yn rhaid i B ail nôl yr adnodd, gwneud newidiadau i'r cyflwr newydd a cheisio eto replace. Bydd hyn yn achosi i'r rhifydd gael ei gynyddu gan ddau a'r nodyn "wedi'i ddiweddaru gan" i gynnwys "AB" ar y diwedd.
Mae'r enghraifft uchod yn awgrymu hynny wrth weithredu replace Mae'r adnodd cyfan yn cael ei ddisodli'n llwyr. Manyleb a ddefnyddir ar gyfer replace, ni ddylai fod yn rhanol, nac mewn rhanau fel yn apply, ond yn gyflawn, yn cynnwys yr ychwanegiad resourceVersion i mewn i fetadata'r fanyleb. Os nad ydych wedi galluogi resourceVersion neu os nad yw'r fersiwn a ddarperir gennych yn gyfredol, bydd y fersiwn newydd yn cael ei wrthod. Felly y dull gorau o ddefnyddio yw replace – darllenwch yr adnodd, ei ddiweddaru a'i ddisodli ar unwaith. Defnyddio kubectl, efallai ei fod yn edrych fel hyn:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Mae'n werth nodi y bydd y ddau orchymyn canlynol, a weithredir yn olynol, yn gweithredu'n llwyddiannus, ers hynny deployment.yaml nid yw'n cynnwys eiddo .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlYmddengys fod hyn yn gwrth-ddweud yr hyn a ddywedwyd uchod, h.y. "gan ychwanegu resourceVersion i mewn i fetadata'r fanyleb." A yw'n anghywir dweud hynny? Na, nid yw, oherwydd os kubectl hysbysiadau na wnaethoch chi eu nodi resourceVersion, bydd yn ei ddarllen o'r adnodd a'i ychwanegu at y fanyleb a nodwyd gennych, a dim ond wedyn ei weithredu replace. Oherwydd y gallai hyn fod yn beryglus os ydych chi'n dibynnu ar atomigedd, mae'r hud yn gweithio'n gyfan gwbl ar yr ochr kubectl, ni ddylech ddibynnu arno wrth ddefnyddio llyfrgelloedd cleientiaid sy'n gweithio gyda'r API. Yn yr achos hwn bydd yn rhaid i chi ddarllen y fanyleb adnoddau gyfredol, ei diweddaru ac yna gweithredu PUT cais.
Ni allwch wneud darn - rydym yn gwneud un arall
Weithiau mae angen i chi wneud rhai newidiadau na all yr API eu trin. Yn yr achosion hyn, gallwch orfodi amnewid yr adnodd trwy ei ddileu a'i ail-greu. Gwneir hyn gan ddefnyddio kubectl replace --force. Mae rhedeg y gorchymyn yn dileu'r adnoddau ar unwaith ac yna'n eu hail-greu o'r fanyleb a gyflenwir. Nid oes unrhyw driniwr "force replace" yn yr API, ac er mwyn gwneud hynny trwy'r API, mae angen i chi berfformio dwy weithred. Yn gyntaf mae angen i chi ddileu'r adnodd trwy osod ar ei gyfer gracePeriodSeconds i sero (0) a propagationPolicy yn “Cefndir” ac yna ail-greu'r adnodd hwn gyda'r fanyleb ddymunol.
Rhybudd: Gall y dull hwn fod yn beryglus a gall arwain at gyflwr anniffiniedig.
Gwnewch gais ar ochr y gweinydd
Fel y soniwyd uchod, mae datblygwyr Kubernetes yn gweithio ar weithredu'r rhesymeg apply o kubectl yn API Kubernetes. Rhesymeg apply ar gael yn Kubernetes 1.18 trwy kubectl apply --server-side neu drwy'r API gan ddefnyddio'r dull PATCH с content-type application/apply-patch+YAML.
Nodyn: Mae JSON hefyd yn YAML dilys, felly gallwch chi anfon y fanyleb fel JSON hyd yn oed os
content-typeByddapplication/apply-patch+yaml.
Heblaw am y rhesymeg honno kubectl ar gael i bawb trwy API, apply ar ochr y gweinydd, yn cadw golwg ar bwy sy'n gyfrifol am y meysydd yn y fanyleb, gan ganiatáu mynediad lluosog diogel ar gyfer ei olygu heb wrthdaro. Mewn geiriau eraill, os apply ar ochr y gweinydd yn dod yn fwy eang, bydd rhyngwyneb rheoli adnoddau diogel cyffredinol yn ymddangos ar gyfer gwahanol gleientiaid, er enghraifft, kubectl, Pulumi neu Terraform, GitOps, yn ogystal â sgriptiau hunan-ysgrifenedig gan ddefnyddio llyfrgelloedd cleientiaid.
Canlyniadau
Rwy'n gobeithio bod y trosolwg byr hwn o wahanol ffyrdd o ddiweddaru adnoddau mewn clystyrau wedi bod o gymorth i chi. Mae'n dda gwybod nad cais yn erbyn disodli yn unig mohono; mae'n bosibl diweddaru adnodd gan ddefnyddio cymhwyso, golygu, clytio, neu amnewid. Wedi'r cyfan, mewn egwyddor, mae gan bob dull ei faes cymhwyso ei hun. Ar gyfer newidiadau atomig, mae ailosod yn well; fel arall, dylech ddefnyddio darn uno strategol trwy wneud cais. O leiaf, disgwyliaf ichi ddeall na allwch ymddiried yn Google neu StackOerflow wrth chwilio am "kubernetes apply vs replace". O leiaf nes bod yr erthygl hon yn disodli'r ateb presennol.
Ffynhonnell: hab.com