Korrekt jämförelse av Kubernetes Apply, Replace och Patch

Det finns flera sätt att uppdatera resurser för Kubernetes: apply, edit, patch och replace. Det råder viss förvirring kring vad var och en av dem gör och när de ska användas. Låt oss reda ut det.

Om söka på Google frasen "kubernetes apply vs replace", hittas svaret på StackOverflow, vilket inte är korrekt. Vid sökning "kubernetes apply vs patch" är den första länken - dokumentationen för kubectl patch, som inte inkluderar en jämförelse apply och patch. I denna artikel kommer de olika alternativen att diskuteras, liksom rätt användning av var och en av dem.

Under livscykeln för en Kubernetes-resurs (t.ex. tjänst, deployment, ingress, etc.) behövs det ibland att ändra, lägga till eller ta bort vissa egenskaper från denna resurs. Till exempel kan man behöva lägga till en anteckning eller öka eller minska antalet repliker.

Kubernetes CLI

Om du redan arbetar med Kubernetes-kluster via CLI, är du förmodligen bekant med apply och edit. Kommandot apply läser resursens specifikation från en fil och gör en "upsert" i Kubernetes-klustret, det vill säga skapar resursen om den inte finns och uppdaterar den om den existerar. Kommandot edit läser resursen via API, och skriver sedan resursens specifikation till en lokal fil som sedan öppnas i en textredigerare. När du har redigerat och sparat filen, kubectl skickar de gjorda ändringarna tillbaka via API, som noggrant tillämpar dessa ändringar på resursen.

Inte alla känner till kommandona patch och replace. Kommandot patch tillåter att ändra en del av resursens specifikation genom att endast tillhandahålla den ändrade delen i kommandoraden. Kommandot replace fungerar på samma sätt som edit, men allt måste göras manuellt: Man måste ladda ner den aktuella versionen av resursens specifikation, till exempel med kubectl get -o yaml, redigera den, och sedan använda replace för att uppdatera resursen med den ändrade specifikationen. Kommandot replace kommer inte att fungera om det har skett några ändringar mellan läsningen och ersättningen av resursen.

Kubernetes API

Du är förmodligen bekant med metoderna CoreV1().Pods().Update(), replaceNamespacedService eller patch_namespaced_deployment, om du arbetar med kluster via klientbiblioteket för Kubernetes API med användning av något programmeringsspråk. Biblioteket hanterar dessa metoder via HTTP-förfrågningar, med användning av metoderna PUT och PATCH. Samtidigt update och replace använder PUT, och patch, hur banalt det än kan låta, använder PATCH.

Det är värt att nämna att kubectl fungerar också med kluster via API. Med andra ord, kubectl– är en wrapper över klientbiblioteket för Go-språket som i stor utsträckning ger möjlighet att erbjuda undermenyer på ett mer kompakt och läsbart sätt, utöver de inbyggda funktionerna i API:et. Till exempel, som du kanske redan har lagt märke till, nämndes inte metoden apply i den föregående paragrafen. För närvarande (maj 2020, översättarens anm.) fungerar all logik kubectl apply, det vill säga skapandet av icke-existerande resurser och uppdatering av befintliga, helt och hållet på klientsidan kubectl. Insatser görs för att flytta logik apply till API-sidan, men detta är fortfarande i beta-testning. Jag kommer att gå in mer detaljerat nedan.

Som standard används Patch

Bäst att tillämpa patch, om du vill uppdatera en resurs. Så fungerar både klientbiblioteken ovanpå Kubernetes API och kubectl (inte förvånande, eftersom det är en wrapper över klientbiblioteket, översättarens anm.).

Arbeta strategiskt

Alla kommandon kubectl apply, edit och patch använder metoden PATCH i HTTP-förfrågningar för att uppdatera en befintlig resurs. Om vi går djupare in i implementeringen av kommandona, används i alla fall metoden strategic-merge patching för att uppdatera resurser, även om kommandot patch kan använda andra metoder (mer om detta nedan). Metoden strategic-merge patching försöker 'göra allt rätt' när den slår ihop den tillhandahållna specifikationen med den befintliga. Mer specifikt försöker den kombinera både objekt och matriser, vilket betyder att ändringar vanligtvis är additiva. Till exempel, om man kör kommandot patch med en ny miljövariabel i podens containerspecifikation, läggs denna miljövariabel till de befintliga miljövariablerna istället för att åsidosätta dem. För att ta bort med denna metod bör parameterinställningen tvingas till null i den tillhandahållna specifikationen. Vilka kommandon kubectl är bäst att använda för uppdatering?

Om du skapar och hanterar dina resurser med kubectl apply, är det alltid bäst att använda kubectl apply, så att kubectl kan hantera konfigurationen och korrekt spåra begärda ändringar från tillämpning till tillämpning. Fördelen med att alltid använda apply är att det spårar den tidigare tillämpade specifikationen, vilket gör att det vet när specifikationens egenskaper och matrisens element uttryckligen tas bort. Detta möjliggör användning av apply för att ta bort egenskaper och element från en array, medan vanlig strategisk sammanslagning inte fungerar. Kommandon edit och patch uppdaterar inte anteckningar som kubectl apply används för att spåra sina förändringar, så eventuella förändringar som spåras och görs genom API:et Kubernetes, men som görs via kommandon edit och patch, är osynliga för efterföljande kommandon apply, det vill säga apply tar inte bort dem, även om de inte visas i den ingående specifikationen för apply (I dokumentationen står det att edit och patch gör uppdateringar av anteckningar som används apply, men i praktiken gör de inte det).

Om du inte använder kommandot apply, kan du använda edit, såväl som patch, och välja det kommando som passar bäst för den förändring som görs. Vid tillägg och ändring av egenskaper i specifikationen är de två metoderna i stort sett desamma. Vid borttagning av egenskaper i specifikationen eller element i en array edit bete sig som ett engångskörning apply, inklusive att spåra vad specifikationen var före och efter redigeringen, så att det är möjligt att explicit ta bort egenskaper och element från arrayen från resursen. Det är nödvändigt att explicit sätta värdet för egenskapen till null i specifikationen för patch, för att ta bort den från resursen. Att ta bort ett element i arrayen med hjälp av strategisk sammanslagningspatching är mer komplicerat, eftersom det kräver användning av sammanslagningsdirektiv. Se andra tillvägagångssätt för uppdatering nedan för att välja mer acceptabla alternativ.

För att implementera i klientbiblioteket metoder för uppdatering som beter sig på liknande sätt som ovanstående kommandon kubectl, bör i begärningarna ställas in content-type på application/strategic-merge-patch+json. Om du vill ta bort egenskaper i specifikationen behöver du uttryckligen sätta deras värden till null på samma sätt som kubectl patch. Om du behöver ta bort element från arrayen, bör du inkludera sammanslagningsdirektiv i uppdateringsspecifikationen eller använda en annan metod för uppdateringar.

Andra tillvägagångssätt för uppdateringar

I Kubernetes stöds två andra tillvägagångssätt för uppdateringar: JSON merge patch och JSON patch. JSON merge patch-metoden tar emot en partiell specifikation av Kubernetes som indata och stödjer sammanslagning av objekt liknande metoden för strategic-merge patching. Skillnaden mellan dem är att den endast stödjer ersättning av arrayer, inklusive arrayen av containrar i pod-specifikationen. Det innebär att när du använder JSON merge patch måste du tillhandahålla kompletta specifikationer för alla containrar om någon egenskap hos en container ändras. På så sätt är denna metod användbar för att ta bort element från arrayen i specifikationen. I kommandoraden kan du välja JSON merge patch med kubectl patch --type=merge. När du arbetar med Kubernetes API bör du använda begäran metod PATCH och ställa in content-type på application/merge-patch+json.

JSON patch-metoden istället för att tillhandahålla en partiell resurs-specifikation, använder en lista över ändringar som du vill göra i resursen i form av en array, där varje element i arrayen representerar en beskrivning av förändringen som görs i resursen. Denna metod är mer flexibel och kraftfull för att uttrycka de ändringar som görs, men detta sker på bekostnad av att listan av gjorda ändringar är i ett separat format, inte Kubernetes, istället för att skicka en partiell resurs-specifikation. I kubectl kan du välja JSON patch med kubectl patch --type=json. När du använder Kubernetes API fungerar denna metod med hjälp av begäran metoden PATCH och ställa in content-type på application/json-patch+json.

Behöver säkerhet — använd replace

I vissa fall behöver du vara säker på att resursen inte kommer att ändras mellan tiden för att läsa resursen och dess uppdatering. Med andra ord, se till att alla ändringar blir atomära. I detta fall bör du använda replace. Till exempel, om det finns en ConfigMap med en räknare som uppdateras av flera källor, bör du vara säker på att två källor inte uppdaterar räknaren samtidigt, vilket skulle leda till att uppdateringen går förlorad. För att demonstrera, föreställ dig en sekvens av händelser där patch:

• A och B får den aktuella tillståndet av resursen från API
• Var och en uppdaterar lokalt specifikationen, ökar räknaren med ett och lägger till "A" respektive "B" i noteringen "updated-by"
• A uppdaterar resursen något snabbare
• B uppdaterar resursen

Som ett resultat förlorades uppdatering A. Den senaste operationen patch vinner, räknaren ökar med ett istället för två, och värdet på noteringen "updated-by" slutar med "B" och innehåller inte "A". Låt oss jämföra det ovanstående med vad som händer när uppdateringar görs med hjälp av tillvägagångssättet replace:

• A och B får den aktuella tillståndet av resursen från API
• Var och en uppdaterar lokalt specifikationen, ökar räknaren med ett och lägger till "A" respektive "B" i noteringen "updated-by"
• A uppdaterar resursen något snabbare
• B försöker uppdatera resurser, men uppdateringen avvisas av API:et eftersom versionen av resursen i specifikationen replace inte matchar den aktuella versionen av resursen i Kubernetes, eftersom resursversionen har ökat vid utförande av en ersättning från A.

I det ovanstående fallet måste B hämta resurserna igen, göra ändringar i det nya tillståndet och försöka igen replace. Som ett resultat kommer räknaren att öka med två, och noteringen "updated-by" kommer att innehålla "AB" i slutet.

Det ovanstående exemplet antyder att vid utförande av replace en fullständig ersättning av hela resurser utförs. Specifikationen som används för replace, måste vara fullständig och inte partiell, som i apply, utan fullständig, inklusive tillägg av resourceVersion till metadata i specifikationen. Om du inte inkluderade resourceVersion eller om den version du tillhandahöll inte är den aktuella, kommer ersättningen att avvisas. Därför är det bästa tillvägagångssättet att använda replace – läsa resurser, uppdatera dem och omedelbart ersätta. Genom att använda kubectl, kan det se ut så här:

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

Det är värt att notera att de följande två kommandona, som körs sekventiellt, kommer att lyckas eftersom deployment.yaml inte innehåller attributet .metadata.resourceVersion

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

Det verkar som detta strider mot vad som nämndes ovan, det vill säga "tillägg av resourceVersion i metadata i specifikationen". Är det felaktigt att hävda det? Nej, det är det inte, eftersom om kubectl upptäcker att du inte angav resourceVersion, kommer den att läsa den från resursen och lägga till den i den specifikation du angav och först därefter utföra replace. Eftersom denna potentiellt farliga, om man förlitar sig på atomäritet, magi fungerar helt på sidan av kubectl, ska man inte förlita sig på den när man använder klientbibliotek som arbetar med API:et. I det här fallet kommer du att behöva läsa den aktuella specifikationen för resursen, uppdatera den och sedan utföra PUT begäran.

Man kan inte göra patch – vi gör replace

Ibland behöver man göra vissa ändringar som inte kan hanteras av API:et. I dessa fall kan man tvinga fram att resurser byts ut genom att ta bort och återskapa dem. Detta görs med kubectl replace --force. Att köra kommandot tar omedelbart bort resurserna och återskaper dem med den angivna specifikationen. Det finns ingen hanterare för "tvinga fram byte" i API:et, och för att göra detta via API:et måste två operationer utföras. Först måste resurserna tas bort, och man sätter gracePeriodSeconds till noll (0) och propagationPolicy till "Background", och sedan återskapa denna resurs med den önskade specifikationen.

Observera: denna metod är potentiellt farlig och kan leda till ett osäkert tillstånd.

Apply på serversidan

Som nämnts ovan jobbar Kubernetes-utvecklarna på att implementera logik apply från kubectl i Kubernetes API:et. Logiken apply är tillgänglig i Kubernetes 1.18 via kubectl apply --server-side eller via API:et, med metoden PATCH med content-type application/apply-patch+YAML.

Observera: JSON är också giltig YAML, så man kan skicka specifikationen i JSON-format, även om content-type För användare med migrän och epilepsi har vissa animations effekter vid öppning av flikar tagits bort. Till exempel, istället för den hoppande punkten visas nu en ikon med sandur under tiden fliken laddar. application/apply-patch+yaml.

Dessutom, att logiken kubectl blir tillgänglig för alla via API:et, apply på serversidan spårar den ansvariga för fälten i specifikationen, vilket möjliggör säker samtidig redigering utan konflikter. Med andra ord, om apply på serversidan får en bredare spridning, kommer det att finnas ett universellt säkerhetsgränssnitt för hantering av resurser för olika klienter, som kubectl, Pulumi eller Terraform, GitOps, samt skräddarsydda skript som använder klientbibliotek.

Sammanfattning

Jag hoppas att denna korta översikt över olika sätt att uppdatera resurser i kluster var användbar för dig. Det är bra att veta att det inte bara är apply mot replace, eftersom man kan uppdatera en resurs med apply, edit, patch eller replace. Var och en har verkligen sitt eget tillämpningsområde. För atomära förändringar är replace att föredra, annars bör man använda strategic-merge patch genom apply. I sista hand hoppas jag att du förstod att man inte kan lita på Google eller StackOverflow när man söker "kubernetes apply vs replace". Åtminstone tills denna artikel ersätter det aktuella svaret.

Källa: habr.com