Kubernetes hà parechje opzioni per aghjurnà e risorse: applicà, edità, patch è rimpiazzà. Ci hè una cunfusione nantu à ciò chì ognunu face è quandu l'utilizanu. Scupritemu.
se a frasa "kubernetes applica vs rimpiazzà" si trova , chì ùn hè micca currettu. "kubernetes applica vs patch" u primu ligame hè a documentazione per kubectl patch, chì ùn include micca paraguni apply и patch. Questu articulu hà da vede e diverse opzioni, è ancu l'usu propiu di ognunu.
Duranti u ciclu di vita di una risorsa Kubernetes (serviziu, implementazione, ingressu, etc.), qualchì volta avete bisognu di cambià, aghjunghje o sguassà alcune proprietà di sta risorsa. Per esempiu, aghjunghje una nota, aumentate o diminuite u numeru di rèpliche.
Kubernetes CLI
Sè avete digià travagliatu cù clusters Kubernetes via a CLI, avete digià familiarizatu apply и edit. squadra apply leghje a specificazione di risorsa da u schedariu è face un "upsert" à u cluster Kubernetes, i.e. crea a risorsa s'ellu ùn esiste micca è l'aghjurnà s'ellu esiste. squadra edit leghje una risorsa via l'API, poi scrive a specificazione di risorsa in un schedariu locale, chì hè dopu apertu in un editore di testu. Dopu avè editatu è salvate u schedariu, kubectl mandarà i cambiamenti fatti à traversu l'API, chì applicà cun cura questi cambiamenti à a risorsa.
Micca tutti cunnosce i cumandamenti patch и replace. squadra patch permette di cambià una parte di una specificazione di risorsa, furnisce solu a parte cambiata in a linea di cummanda. squadra replace travaglia u listessu cum'è edit, ma tuttu deve esse fattu manualmente: avete bisognu di scaricà a versione attuale di a specificazione di risorse, per esempiu, usendu kubectl get -o yaml, editallu, dopu aduprà replace per aghjurnà una risorsa secondu una specificazione cambiata. squadra replace ùn funziona micca se ci sò stati cambiamenti trà a lettura è a sostituzione di a risorsa.
API Kubernetes
Probabilmente site familiarizatu cù i metudi CoreV1().Pods().Update(), replaceNamespacedService o patch_namespaced_deployment, se travagliate cù cluster via usendu qualchì lingua di prugrammazione. A biblioteca gestisce questi metudi via richieste HTTP utilizendu i metudi PUT и PATCH... Induve update и replace usu PUTe patch, ùn importa quantu triviale pò esse, usa PATCH.
Ci hè da nutà chì kubectl travaglia ancu cù clusters via API. In altre parolle, kubectlhè un wrapper in cima di a libreria di u cliente per a lingua Go, chì largamente furnisce l'abilità di furnisce subcumandamenti in una forma più compacta è leghjite in più di e capacità standard API. Per esempiu, cum'è vo avete digià nutatu, u metudu apply ùn era micca mintuatu sopra in u paràgrafu precedente. Attualmente (maghju 2020, ca. traduttore) tutta a logica kubectl apply, i.e. criendu risorse inesistenti è aghjurnà quelli esistenti, travaglia interamente in u latu di u codice kubectl. I sforzi sò fatti apply à u latu API, ma hè sempre in beta. Scriveraghju in più dettagliu quì sottu.
Patch per difettu
U megliu utilizatu patch, se vulete aghjurnà a risorsa. Hè cusì chì e duie librerie di u cliente travaglianu in cima à l'API Kubernetes è kubectl (micca surprisante, postu chì hè un wrapper per a biblioteca di u cliente, ca. traduttore).
U travagliu strategicu
Tutte e squadre kubectl apply, edit и patch aduprà u metudu PATCH in HTTP richieste per aghjurnà una risorsa esistente. Sè vo sfondate in l'implementazione di cumandamenti in più detail, allora tutti l'utilizanu l'approcciu per aghjurnà e risorse, ancu se u cumandimu patch pò aduprà altri approcci (più nantu à questu quì sottu). L'approcciu di patching strategicu di fusione tenta di "avè u dirittu" unendu a specificazione furnita cù a specificazione esistente. Più specificamente, prova di cumminà l'uggetti è l'array, chì significa chì i cambiamenti tendenu à esse additivi. Per esempiu, eseguisce u cumandamentu patch cù una nova variabile d'ambiente in a specificazione di u contenitore di pod, face chì quella variabile d'ambiente sia aghjuntu à e variabili di l'ambiente esistenti invece di sovrascrive. Per sguassà cù stu approcciu, duvete furzà u valore di u paràmetru à null in a specificazione furnita. Quale di e squadre kubectl Hè megliu aduprà per l'aghjurnamentu?
Sè vo create è gestisce e vostre risorse usendu kubectl apply, quandu aghjurnà hè megliu aduprà sempre kubectl applycusì kubectl puderia gestisce a cunfigurazione è seguità currettamente i cambiamenti dumandati da l'applicazione à l'applicazione. Advantage aduprà sempre apply hè chì mantene a traccia di una specificazione applicata previamente, chì permette di sapè quandu e proprietà di specificazione è l'elementi di l'array sò esplicitamente eliminati. Questu permette di utilizà apply per sguassà proprietà è elementi di array, mentre chì una fusione strategica normale ùn funziona micca. Squadre edit и patch ùn aghjurnà micca e note chì kubectl apply usa per seguità i so cambiamenti, cusì tutti i cambiamenti chì sò tracciati è fatti attraversu l'API Kubernetes, ma fatti per cumandamenti edit и patch, invisibile à i cumandamenti successivi apply, questu hè apply ùn li sguassate ancu s'ellu ùn appare micca in a specificazione di input per apply (A documentazione dice chì edit и patch fate l'aghjurnamenti di e note aduprate apply, ma in pratica - no).
Se ùn utilizate micca u cumandamentu apply, pò esse usatu cum'è edit, è patch, scegliendu u cumandamentu chì si adatta megliu à u cambiamentu chì hè fattu. Quandu aghjunghjenu è cambiate e proprietà di BOM, i dui approcci sò quasi listessi. Quandu sguassate proprietà di specificazione o elementi di array edit cumporta cum'è un lanciu una volta apply, cumpresu a traccia di ciò chì a specificazione era cum'è prima è dopu hè stata editata, cusì pudete sguassà esplicitamente proprietà è elementi di array da una risorsa. Avete bisognu di stabilisce esplicitamente u valore di a pruprietà à null in a specificazione per patchper sguassà da a risorsa. L'eliminazione di un elementu di array utilizendu patching strategicu di fusione hè più cumplessa perchè esige l'usu di direttive di fusione. Vede altri approcci di aghjurnamentu sottu per alternative più viable.
Per implementà metudi d'aghjurnamentu in a biblioteca di u cliente chì si cumportanu in modu simili à i cumandamenti sopra kubectl, deve esse stabilitu in richieste content-type в application/strategic-merge-patch+json. Se vulete caccià e proprietà in una specificazione, avete bisognu di stabilisce esplicitamente i so valori à null in un modu simili. kubectl patch. Sè avete bisognu di caccià elementi di array, duvete include direttive di fusione in l'especificazioni di l'aghjurnamentu o utilizate un approcciu sfarente per l'aghjurnamenti.
Altri approcci à l'aghjurnamenti
Kubernetes supporta dui altri approcci di aghjurnamentu: и . L'approcciu di patch di fusione JSON piglia una specificazione parziale di Kubernetes cum'è input è sustene l'uggetti di fusione simili à l'approcciu di patch di fusione strategica. A diffarenza trà i dui hè chì sustene solu a sustituzione di array, cumpresa a matrice di container in a specificazione di pod. Questu significa chì quandu aduprate un patch di fusione JSON, avete bisognu di furnisce specificazioni cumplete per tutti i cuntenituri in casu chì ogni pruprietà di qualsiasi cuntainer cambia. Allora stu approcciu hè utile per sguassà elementi da un array in una BOM. Nantu à a linea di cumanda pudete selezziunate u patch di fusione JSON usendu kubectl patch --type=merge. Quandu travaglia cù l'API Kubernetes, duvete aduprà u metudu di dumanda PATCH è installazione content-type в application/merge-patch+json.
L'approcciu di patch JSON, invece di furnisce una specificazione parziale di una risorsa, usa furnisce i cambiamenti chì vulete fà à a risorsa cum'è un array, in quale ogni elementu di a matrice rapprisenta una descrizzione di u cambiamentu chì hè fattu à a risorsa. Stu approcciu hè un modu più flexibule è putente per sprimà i cambiamenti chì sò fatti, ma à u costu di listinu i cambiamenti chì sò fatti in un furmatu separatu, micca Kubernetes, invece di mandà una specificazione parziale di risorse. IN kubectl pudete selezziunà u patch JSON usendu kubectl patch --type=json. Quandu si usa l'API Kubernetes, stu approcciu travaglia cù u metudu di dumanda PATCH è installazione content-type в application/json-patch+json.
Avemu bisognu di cunfidenza - utilizate rimpiazzà
In certi casi, avete bisognu à esse sicuru chì ùn ci hè micca cambiatu à una risorsa trà u tempu chì a risorsa hè lettu è quandu hè aghjurnata. In altri palori, duvete assicurà chì tutti i cambiamenti seranu atomicu. In questu casu, per aghjurnà e risorse duvete aduprà replace. Per esempiu, sè vo avete un ConfigMap cun un contatore chì hè aghjurnatu da parechje fonti, avete da esse sicuru chì duie fonti ùn aghjurnà micca u cuntatore à u stessu tempu, chì causanu a perdita di l'aghjurnamentu. Per dimustrà, imagine una sequenza di avvenimenti chì utilizanu l'approcciu patch:
- A è B uttene u statu attuale di a risorsa da l'API
- Ognunu aghjurnà localmente a specificazione aumentendu u contatore da unu è aghjunghjendu "A" o "B" rispettivamente à a nota "aghjurnata da"
- È aghjurnà a risorsa un pocu più veloce
- B aghjurnà a risorsa
In u risultatu, l'aghjurnamentu A hè persu. Ultima operazione patch vittorie, u cuntatore hè aumentatu da unu invece di dui, è u valore di a nota "aghjurnata da" finisce cù "B" è ùn cuntene "A". Confrontemu quì sopra cù ciò chì succede quandu l'aghjurnamenti sò fatti cù l'approcciu replace:
- A è B uttene u statu attuale di a risorsa da l'API
- Ognunu aghjurnà localmente a specificazione aumentendu u contatore da unu è aghjunghjendu "A" o "B" rispettivamente à a nota "aghjurnata da"
- È aghjurnà a risorsa un pocu più veloce
- B prova à aghjurnà a risorsa, ma l'aghjurnamentu hè rifiutatu da l'API perchè a versione di risorsa hè in a specificazione.
replaceùn currisponde à a versione attuale di a risorsa in Kubernetes perchè a versione di a risorsa hè stata aumentata da l'operazione di rimpiazzamentu di A.
In u casu sopra, B duverà ricuperà a risorsa, fà cambiamenti à u novu statu è pruvate di novu replace. Questu pruvucarà u cuntatore per esse incrementatu da dui è a nota "aghjurnata da" per include "AB" à a fine.
L'esempiu di sopra implica chì quandu eseguisce replace A risorsa sana hè completamente rimpiazzata. Specificazione utilizata per replace, ùn deve esse parziale, o in parti cum'è in apply, ma cumpleta, cumpresa l'aghjuntu resourceVersion in i metadati di specificazione. Se ùn avete micca attivatu resourceVersion o a versione chì furnite ùn hè micca attuale, a sustituzione serà rifiutata. Allora u megliu approcciu à aduprà hè replace - leghje a risorsa, aghjurnà è rimpiazzà immediatamente. Utilizendu kubectl, pò esse cusì:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Hè da nutà chì i seguenti dui cumandamenti, eseguiti in sequenza, seranu eseguiti cù successu, postu chì deployment.yaml ùn cuntene micca pruprietà .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlQuestu parerebbe cuntradisce ciò chì era dettu sopra, i.e. "aghjunghje resourceVersion in i metadati di specificazione. "Hè sbagliatu di dì chì? No, ùn hè micca, perchè se kubectl nota chì ùn avete micca specificatu resourceVersion, u leghjerà da a risorsa è aghjunghje à a specificazione chì avete specificatu, è solu dopu eseguisce replace. Perchè questu hè potenzalmentu periculosu s'ellu si basa in l'atomicità, a magia funziona interamente à u latu kubectl, ùn deve micca cunfidendu quandu utilizate biblioteche cliente chì travaglianu cù l'API. In questu casu, avete da leghje a specificazione di risorsa attuale, aghjurnà è poi eseguisce PUT dumanda.
Ùn pudete micca fà un patch - facemu un sustitutu
Calchì volta ci vole à fà qualchi cambiamenti chì ùn pò esse trattatu da l 'API. In questi casi, pudete furzà a rimpiazzamentu di a risorsa sguassendu è ricreendu. Questu hè fattu cù l'usu kubectl replace --force. Eseguisce u cumandamentu elimina immediatamente e risorse è poi ricreate da a specificazione furnita. Ùn ci hè micca un gestore di "rimpiazzare forza" in l'API, è per fà cusì attraversu l'API, avete bisognu di fà duie operazioni. Prima avete bisognu di sguassà a risorsa cunfittendu per questu gracePeriodSeconds à zero (0) è propagationPolicy in "Background" è poi ricreà sta risorsa cù l'specificazione desiderata.
Attenzione: Stu approcciu hè potenzialmente periculoso è pò purtà à un statu indefinitu.
Applica da u latu di u servitore
Cumu l'esitatu sopra, i sviluppatori di Kubernetes travaglianu per implementà a logica apply из kubectl in l'API Kubernetes. A logica apply dispunibule in Kubernetes 1.18 via kubectl apply --server-side o via l'API cù u metudu PATCH с content-type application/apply-patch+YAML.
Nota: JSON hè ancu validu YAML, cusì pudete mandà a specificazione cum'è JSON ancu s'ellu
content-typesaràapplication/apply-patch+yaml.
In più di quella logica kubectl diventa disponibile per tutti via API, apply da u latu di u servitore, mantene a traccia di quale hè rispunsevuli di i campi in a specificazione, cusì permette un accessu multiplu sicuru per a so edizione senza cunflittu. In altre parolle, se apply in u latu di u servitore diventerà più diffusa, una interfaccia universale di gestione di risorse sicura appariscerà per i clienti diffirenti, per esempiu, kubectl, Pulumi o Terraform, GitOps, è ancu scripts auto-scritti cù biblioteche cliente.
Risultati
Spergu chì sta breve panoramica di e diverse modi per aghjurnà e risorse in clusters hè stata utile per voi. Hè bonu di sapè chì ùn hè micca solu applicà versus rimpiazzà; hè pussibule aghjurnà una risorsa usendu applicà, edità, patch, o rimpiazzà. Dopu tuttu, in principiu, ogni approcciu hà u so propiu spaziu di applicazione. Per i cambiamenti atomichi, rimpiazzà hè preferibile; altrimenti, duvete aduprà u patch di fusione strategica via applicà. À u minimu, m'aspettu chì capisce chì ùn pudete micca fiducia in Google o StackOerflow quandu cercate "kubernetes apply vs replace". Almenu finu à chì questu articulu rimpiazza a risposta attuale.
Source: www.habr.com