Kubernetes het verskeie opsies vir die opdatering van hulpbronne: toepas, redigeer, pleister en vervang. Daar is verwarring oor wat elkeen doen en wanneer om dit te gebruik. Kom ons vind dit uit.
As die frase "kubernetes toepas vs vervang" is geleë , wat nie korrek is nie. "kubernetes apply vs patch" die eerste skakel is die dokumentasie vir kubectl patch, wat nie vergelyking insluit nie apply и patch. Hierdie artikel sal kyk na die verskillende opsies, sowel as die korrekte gebruik van elkeen.
Gedurende die lewensiklus van 'n Kubernetes-hulpbron (diens, ontplooiing, ingang, ens.), moet jy soms sekere eienskappe van hierdie hulpbron verander, byvoeg of verwyder. Voeg byvoorbeeld 'n nota by, verhoog of verminder die aantal replikas.
Kubernetes CLI
As jy reeds met Kubernetes-klusters werk via die CLI, is jy reeds vertroud met apply и edit. Span apply lees die hulpbronspesifikasie uit die lêer en maak 'n "upsert" na die Kubernetes-kluster, m.a.w. skep die hulpbron as dit nie bestaan nie en werk dit op indien dit bestaan. Span edit lees 'n hulpbron via die API, skryf dan die hulpbronspesifikasie na 'n plaaslike lêer, wat dan in 'n teksredigeerder oopgemaak word. Nadat jy die lêer gewysig en gestoor het, kubectl sal die veranderinge wat gemaak is terugstuur deur die API, wat hierdie veranderinge noukeurig op die hulpbron sal toepas.
Nie almal ken die opdragte nie patch и replace. Span patch laat jou toe om 'n deel van 'n hulpbronspesifikasie te verander, deur slegs die veranderde deel op die opdragreël te verskaf. Span replace werk dieselfde as edit, maar alles moet met die hand gedoen word: jy moet die huidige weergawe van die hulpbronspesifikasie aflaai, bv. kubectl get -o yaml, wysig dit en gebruik dan replace om 'n hulpbron volgens 'n veranderde spesifikasie by te werk. Span replace sal nie werk as enige veranderinge plaasgevind het tussen lees en vervanging van die hulpbron nie.
Kubernetes API
Jy is waarskynlik vertroud met die metodes CoreV1().Pods().Update(), replaceNamespacedService of patch_namespaced_deployment, as jy met clusters werk via gebruik een of ander programmeertaal. Die biblioteek hanteer hierdie metodes via HTTP-versoeke deur die metodes te gebruik PUT и PATCH... Waarin update и replace gebruik PUTEn patch, maak nie saak hoe onbenullig dit mag wees nie, gebruik PATCH.
Daar moet op gelet word dat kubectl werk ook met clusters via API. Met ander woorde, kubectlis 'n omhulsel bo-op die kliëntbiblioteek vir die Go-taal, wat grootliks die vermoë bied om subopdragte in 'n meer kompakte en leesbare vorm bykomend tot die standaard API-vermoëns te verskaf. Byvoorbeeld, soos jy dalk reeds opgemerk het, die metode apply is nie hierbo in die vorige paragraaf genoem nie. Tans (Mei 2020, ongeveer. vertaler) alle logika kubectl apply, d.w.s. die skep van nie-bestaande hulpbronne en die opdatering van bestaandes, werk heeltemal aan die kodekant kubectl. Pogings word aangewend apply na die API-kant, maar dit is steeds in beta. Ek sal hieronder in meer besonderhede skryf.
Patch by verstek
Beste gebruik patch, as jy die hulpbron wil opdateer. Dit is hoe beide kliëntbiblioteke werk bo-op die Kubernetes API en kubectl (nie verbasend nie, aangesien dit 'n omhulsel vir die kliëntbiblioteek is, ongeveer. vertaler).
Werk strategies
Alle spanne kubectl apply, edit и patch gebruik die metode PATCH in HTTP-versoeke om 'n bestaande hulpbron op te dateer. As jy meer in detail in die implementering van opdragte delf, gebruik almal die benadering hulpbronne op te dateer, hoewel die opdrag patch kan ander benaderings gebruik (meer hieroor hieronder). Die strategiese-samesmelting-patching-benadering poog om dit "reg te kry" deur die verskafde spesifikasie met die bestaande spesifikasie saam te voeg. Meer spesifiek, dit probeer om beide voorwerpe en skikkings te kombineer, wat beteken dat die veranderinge geneig is om byvoegend te wees. Byvoorbeeld, die uitvoering van die opdrag patch met 'n nuwe omgewingsveranderlike in die peulhouerspesifikasie, veroorsaak dat daardie omgewingsveranderlike by die bestaande omgewingsveranderlikes gevoeg word eerder as om dit te oorskryf. Om die gebruik van hierdie benadering te verwyder, moet jy die parameterwaarde dwing om nul in die verskafde spesifikasie. Watter van die spanne kubectl Is dit die beste om te gebruik vir opdatering?
As jy jou hulpbronne skep en bestuur deur kubectl apply, wanneer dit opgedateer word, is dit beter om altyd te gebruik kubectl applysodat kubectl kon opstelling bestuur en gevraagde veranderinge van toepassing tot toepassing korrek opspoor. Voordeel gebruik altyd apply is dat dit tred hou met 'n voorheen toegepaste spesifikasie, wat dit toelaat om te weet wanneer spesifikasie-eienskappe en skikkingselemente uitdruklik verwyder word. Dit laat jou toe om te gebruik apply om eienskappe en skikkingselemente te verwyder, terwyl 'n normale strategiese samesmelting nie sal werk nie. Spanne edit и patch moenie notas dat kubectl apply gebruik om sy veranderinge op te spoor, dus enige veranderinge wat deur die Kubernetes API nagespoor en gemaak word, maar deur opdragte gemaak word edit и patch, onsigbaar vir daaropvolgende opdragte applyDit is, apply verwyder hulle nie, selfs al verskyn hulle nie in die invoerspesifikasie vir apply (Die dokumentasie sê dit edit и patch maak opdaterings aan die notas wat gebruik word apply, maar in die praktyk - nee).
As jy nie die opdrag gebruik nie apply, kan gebruik word as editEn patch, die opdrag te kies wat die beste pas by die verandering wat gemaak word. Wanneer BOM-eienskappe bygevoeg en verander word, is beide benaderings min of meer dieselfde. Wanneer spesifikasie eienskappe of skikking elemente uitvee edit gedra soos 'n eenmalige bekendstelling apply, insluitend om tred te hou met hoe die spesifikasie was voor en nadat dit geredigeer is, sodat jy eksplisiet eienskappe en skikkingselemente van 'n hulpbron kan verwyder. Jy moet die eiendomswaarde uitdruklik op nul stel in die spesifikasie vir patchom dit uit die hulpbron te verwyder. Die verwydering van 'n skikkingselement deur gebruik te maak van strategiese-samevoeging-patching is meer kompleks omdat dit die gebruik van samesmeltingsriglyne vereis. Sien ander opgraderingsbenaderings hieronder vir meer lewensvatbare alternatiewe.
Om opdateringsmetodes in die kliëntbiblioteek te implementeer wat soortgelyk optree as die opdragte hierbo kubectl, moet in versoeke gestel word content-type в application/strategic-merge-patch+json. As u eiendomme in 'n spesifikasie wil verwyder, moet u hul waardes op 'n soortgelyke manier uitdruklik op nul stel kubectl patch. As jy skikkingselemente moet verwyder, moet jy samesmeltingsaanwysings in die opdateringspesifikasie insluit of 'n ander benadering tot opdaterings gebruik.
Ander benaderings tot opdaterings
Kubernetes ondersteun twee ander opdateringsbenaderings: и . Die JSON-samevoeging-patch-benadering neem 'n gedeeltelike Kubernetes-spesifikasie as inset en ondersteun samesmelting van voorwerpe soortgelyk aan die strategiese-samevoeging-patch-benadering. Die verskil tussen die twee is dat dit slegs skikkingsvervanging ondersteun, insluitend die houerskikking in die peulspesifikasie. Dit beteken dat wanneer u 'n JSON-samevoegingspleister gebruik, u volledige spesifikasies vir alle houers moet verskaf indien enige eiendom van enige houer verander. Hierdie benadering is dus nuttig om elemente uit 'n skikking in 'n BOM te verwyder. Op die opdragreël kan u JSON-samevoegingspleister kies met behulp van kubectl patch --type=merge. Wanneer u met die Kubernetes API werk, moet u die versoekmetode gebruik PATCH en installasie content-type в application/merge-patch+json.
Die JSON-pleisterbenadering, eerder as om 'n gedeeltelike spesifikasie van 'n hulpbron te verskaf, gebruik die verskaffing van die veranderinge wat jy aan die hulpbron wil maak as 'n skikking, waarin elke element van die skikking 'n beskrywing verteenwoordig van die verandering wat aan die hulpbron gemaak word. Hierdie benadering is 'n meer buigsame en kragtige manier om die veranderinge wat gemaak word, uit te druk, maar ten koste van die lys van die veranderinge wat gemaak word in 'n aparte, nie-Kubernetes-formaat, eerder as om 'n gedeeltelike hulpbronspesifikasie te stuur. IN kubectl jy kan JSON-pleister kies met behulp van kubectl patch --type=json. Wanneer die Kubernetes API gebruik word, werk hierdie benadering deur die versoekmetode te gebruik PATCH en installasie content-type в application/json-patch+json.
Ons het vertroue nodig - gebruik vervang
In sommige gevalle moet jy seker wees dat geen veranderinge aan 'n hulpbron aangebring word tussen die tyd wat die hulpbron gelees word en wanneer dit opgedateer word nie. Met ander woorde, jy moet seker maak dat alle veranderinge sal wees atoom. In hierdie geval, om hulpbronne by te werk wat jy moet gebruik replace. Byvoorbeeld, as jy 'n ConfigMap het met 'n teller wat deur verskeie bronne opgedateer word, moet jy seker wees dat twee bronne nie die teller op dieselfde tyd opdateer nie, wat veroorsaak dat die opdatering verlore gaan. Om te demonstreer, stel 'n reeks gebeure voor deur die benadering te gebruik patch:
- A en B kry die huidige toestand van die hulpbron vanaf die API
- Elkeen werk die spesifikasie plaaslik op deur die teller met een te verhoog en ook "A" of "B" onderskeidelik by die "bygewerk-deur"-nota by te voeg
- En dit werk die hulpbron 'n bietjie vinniger op
- B dateer die hulpbron op
As gevolg hiervan is opdatering A verlore. Laaste operasie patch wen, word die teller met een in plaas van twee verhoog, en die waarde van die "bygewerk-deur"-noot eindig met "B" en bevat nie "A". Kom ons vergelyk bogenoemde met wat gebeur wanneer opdaterings met behulp van die benadering gedoen word replace:
- A en B kry die huidige toestand van die hulpbron vanaf die API
- Elkeen werk die spesifikasie plaaslik op deur die teller met een te verhoog en ook "A" of "B" onderskeidelik by die "bygewerk-deur"-nota by te voeg
- En dit werk die hulpbron 'n bietjie vinniger op
- B probeer om die hulpbron op te dateer, maar die opdatering word deur die API verwerp omdat die hulpbronweergawe in die spesifikasie is
replacestem nie ooreen met die huidige weergawe van die hulpbron in Kubernetes nie, want die weergawe van die hulpbron is verhoog deur A se vervangingsbewerking.
In die bogenoemde geval sal B die hulpbron weer moet gaan haal, veranderinge aan die nuwe toestand moet aanbring en weer probeer replace. Dit sal veroorsaak dat die teller met twee verhoog word en die "bygewerk-deur"-nota sal "AB" aan die einde insluit.
Die voorbeeld hierbo impliseer dat wanneer dit uitgevoer word replace Die hele hulpbron word heeltemal vervang. Spesifikasie gebruik vir replace, moet nie gedeeltelik wees nie, of in dele soos in apply, maar volledig, insluitend die byvoeging resourceVersion in die spesifikasie-metadata. As jy nie geaktiveer het nie resourceVersion of die weergawe wat jy verskaf nie op datum is nie, sal die vervanging verwerp word. So die beste benadering om te gebruik is replace – lees die hulpbron, werk dit op en vervang dit onmiddellik. Met behulp van kubectl, kan dit so lyk:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Dit is opmerklik dat die volgende twee opdragte, wat opeenvolgend uitgevoer word, suksesvol sal uitgevoer word, aangesien deployment.yaml nie eiendom bevat nie .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlDit wil blykbaar weerspreek wat hierbo gesê is, m.a.w. "byvoeging resourceVersion in die spesifikasie-metadata." Is dit verkeerd om dit te sê? Nee, dit is nie, want as kubectl kennisgewings wat jy nie gespesifiseer het nie resourceVersion, sal dit dit uit die hulpbron lees en dit by die spesifikasie wat jy gespesifiseer het voeg, en dit dan eers uitvoer replace. Omdat dit potensieel gevaarlik is as jy op atomiteit staatmaak, werk die magie heeltemal aan die kant kubectl, moet jy nie daarop staatmaak wanneer jy kliëntbiblioteke gebruik wat met die API werk nie. In hierdie geval sal jy die huidige hulpbronspesifikasie moet lees, dit bywerk en dan uitvoer PUT versoek.
Jy kan nie 'n pleister doen nie - ons doen 'n vervanging
Soms moet jy 'n paar veranderinge maak wat nie deur die API hanteer kan word nie. In hierdie gevalle kan jy die vervanging van die hulpbron dwing deur dit uit te vee en weer te skep. Dit word gedoen met behulp van kubectl replace --force. Deur die opdrag uit te voer, word die hulpbronne onmiddellik verwyder en dan herskep vanaf die verskafde spesifikasie. Daar is geen "force replace"-hanteerder in die API nie, en om dit deur die API te doen, moet jy twee bewerkings uitvoer. Eerstens moet jy die hulpbron uitvee deur daarvoor in te stel gracePeriodSeconds na nul (0) en propagationPolicy in "Agtergrond" en herskep dan hierdie hulpbron met die verlangde spesifikasie.
Waarskuwing: Hierdie benadering is potensieel gevaarlik en kan lei tot 'n ongedefinieerde toestand.
Dien toe aan die bedienerkant
Soos hierbo genoem, werk Kubernetes-ontwikkelaars daaraan om die logika te implementeer apply van kubectl in die Kubernetes API. Logika apply beskikbaar in Kubernetes 1.18 via kubectl apply --server-side of via die API met behulp van die metode PATCH с content-type application/apply-patch+YAML.
Let wel: JSON is ook geldig YAML, so jy kan die spesifikasie as JSON stuur, selfs al
content-typesalapplication/apply-patch+yaml.
Behalwe daardie logika kubectl word vir almal beskikbaar via API, apply aan die bedienerkant, hou tred met wie verantwoordelik is vir die velde in die spesifikasie, en laat dus veilige meervoudige toegang toe vir die konflikvrye redigering daarvan. Met ander woorde, as apply aan die bedienerkant meer wydverspreid sal word, sal 'n universele veilige hulpbronbestuurkoppelvlak vir verskillende kliënte verskyn, byvoorbeeld kubectl, Pulumi of Terraform, GitOps, sowel as selfgeskrewe skrifte wat kliëntbiblioteke gebruik.
Resultate van
Ek hoop hierdie kort oorsig van verskillende maniere om hulpbronne in groepe by te werk, was nuttig vir jou. Dit is goed om te weet dat dit nie net toe te pas versus vervang is nie, dit is moontlik om 'n hulpbron op te dateer deur toepassing, redigeer, pleister of vervang. In beginsel het elke benadering immers sy eie toepassingsgebied. Vir atoomveranderinge is vervang verkieslik, anders moet jy strategiese samesmeltingspleister gebruik. Ek verwag ten minste van jou om te verstaan dat jy nie Google of StackOerflow kan vertrou wanneer jy na "kubernetes apply vs replace" soek nie. Ten minste totdat hierdie artikel die huidige antwoord vervang.
Bron: will.com