A Kubernetes Apply, Replace és Patch megfelelő összehasonlítása

A Kubernetes számos lehetőséget kínál az erőforrások frissítésére: alkalmazás, szerkesztés, javítás és csere. Zavar van azzal kapcsolatban, hogy mindegyik mit csinál, és mikor használja őket. Találjuk ki.

Ha keress a Google-ban a "kubernetes alkalmazni vs csere" kifejezés található válaszoljon a StackOverflow-nak, ami nem helyes. A keresés során "kubernetes apply vs patch" az első hivatkozás a dokumentációja kubectl patch, amely nem tartalmazza az összehasonlítást apply и patch. Ez a cikk megvizsgálja a különböző lehetőségeket, valamint mindegyik helyes használatát.

Egy Kubernetes-erőforrás (szolgáltatás, üzembe helyezés, belépés stb.) életciklusa során néha módosítania kell, hozzá kell adnia vagy el kell távolítania az erőforrás egyes tulajdonságait. Például adjon hozzá megjegyzést, növelje vagy csökkentse a replikák számát.

Kubernetes CLI

Ha már dolgozik Kubernetes-fürtökkel a CLI-n keresztül, akkor már ismeri apply и edit. Csapat apply beolvassa a fájlból az erőforrás specifikációt és "upsert"-et csinál a Kubernetes fürthöz, azaz. létrehozza az erőforrást, ha nem létezik, és frissíti, ha létezik. Csapat edit beolvas egy erőforrást az API-n keresztül, majd beírja az erőforrás-specifikációt egy helyi fájlba, amely ezután megnyílik egy szövegszerkesztőben. A fájl szerkesztése és mentése után kubectl visszaküldi a módosításokat az API-n keresztül, amely gondosan alkalmazza ezeket a változtatásokat az erőforráson.

Nem mindenki ismeri a parancsokat patch и replace. Csapat patch lehetővé teszi az erőforrás-specifikáció egy részének módosítását, csak a megváltozott részt jelenítve meg a parancssorban. Csapat replace ugyanúgy működik, mint edit, de mindent manuálisan kell megtenni: le kell töltenie az erőforrás-specifikáció aktuális verzióját, például kubectl get -o yaml, szerkessze, majd használja replace erőforrás frissítéséhez a megváltozott specifikáció szerint. Csapat replace nem fog működni, ha bármilyen változás történt az erőforrás olvasása és cseréje között.

Kubernetes API

Valószínűleg ismeri a módszereket CoreV1().Pods().Update(), replaceNamespacedService vagy patch_namespaced_deployment, ha fürtökkel dolgozik keresztül ügyfélkönyvtár a Kubernetes API-hoz valamilyen programozási nyelv használatával. A könyvtár ezeket a metódusokat HTTP-kérésekkel kezeli a metódusok használatával PUT и PATCH... Hol update и replace használat PUTÉs patch, akármilyen triviális is, használja PATCH.

Meg kell jegyezni, hogy a kubectl klaszterekkel is működik API-n keresztül. Más szavakkal, kubectla Go nyelv klienskönyvtárának tetején található burkoló, amely nagyrészt lehetővé teszi az alparancsok tömörebb és olvashatóbb formában történő biztosítását a szabványos API-képességek mellett. Például, mint már észrevetted, a módszer apply az előző bekezdésben nem említettük. Jelenleg (2020. május kb. fordító) minden logika kubectl apply, azaz a nem létező erőforrások létrehozása és a meglévők frissítése teljes mértékben a kód oldalon működik kubectl. Erőfeszítések folynak logikai átvitelen apply API-oldalra, de még béta állapotban van. Az alábbiakban részletesebben írok.

Alapértelmezés szerint patch

Legjobban használt patch, ha frissíteni szeretné az erőforrást. Mindkét ügyfélkönyvtár így működik a Kubernetes API-n és kubectl (nem meglepő, mivel ez az ügyfélkönyvtár burkolója, kb. fordító).

Stratégiai munka

Minden csapat kubectl apply, edit и patch használja a módszert PATCH HTTP kérésekben egy meglévő erőforrás frissítésére. Ha részletesebben elmélyül a parancsok megvalósításában, akkor mindegyik használja a megközelítést stratégiai összeolvadás foltozás az erőforrások frissítéséhez, bár a parancs patch más megközelítéseket is használhat (erről lentebb olvashat bővebben). A stratégiai összevonásos foltozási megközelítés a mellékelt specifikáció és a meglévő specifikáció egyesítése révén próbálja meg "megoldani". Pontosabban, megpróbálja kombinálni az objektumokat és a tömböket, ami azt jelenti, hogy a változtatások általában additívak. Például a parancs futtatása patch egy új környezeti változóval a pod-tároló specifikációjában, azt okozza, hogy a környezeti változót a meglévő környezeti változókhoz adják, nem pedig felülírják. Az ezzel a megközelítéssel történő eltávolításhoz a megadott specifikációban nullára kell kényszerítenie a paraméter értékét. Melyik csapat kubectl Frissítésre érdemes használni?

Ha erőforrásait úgy hozza létre és kezeli kubectl apply, frissítéskor jobb mindig használni kubectl applyúgy hogy kubectl képes kezelni a konfigurációt és helyesen nyomon követni a kért változtatásokat alkalmazásról alkalmazásra. Előny mindig használja apply az, hogy nyomon követi a korábban alkalmazott specifikációt, lehetővé téve számára, hogy tudja, ha a specifikáció tulajdonságait és a tömbelemeket kifejezetten eltávolították. Ez lehetővé teszi a használatát apply tulajdonságok és tömbelemek eltávolításához, míg a normál stratégiai egyesítés nem fog működni. Csapatok edit и patch ne frissítse megjegyzi, hogy kubectl apply módosításainak nyomon követésére használja, tehát minden olyan változtatást, amelyet a Kubernetes API-n keresztül követnek és hajtanak végre, de parancsokkal edit и patch, láthatatlan a következő parancsok számára applyEz azt jelenti, apply akkor sem távolítja el őket, ha nem jelennek meg a bemeneti specifikációban apply (A dokumentáció ezt írja edit и patch frissítse a használt jegyzeteket apply, de a gyakorlatban - nem).

Ha nem használja a parancsot apply, mint editÉs patch, válassza ki a végrehajtott változtatásnak leginkább megfelelő parancsot. A darabjegyzék-tulajdonságok hozzáadásakor és módosításakor mindkét megközelítés nagyjából megegyezik. Specifikációs tulajdonságok vagy tömbelemek törlésekor edit úgy viselkedik, mint egy egyszeri indítás apply, beleértve annak nyomon követését, hogy milyen volt a specifikáció szerkesztése előtt és után, így kifejezetten eltávolíthatja a tulajdonságokat és a tömbelemeket egy erőforrásból. A tulajdonság értékét kifejezetten nullára kell állítania a for specifikációjában patchhogy távolítsa el az erőforrásból. Egy tömbelem eltávolítása stratégiai összevonási foltozással bonyolultabb, mert összevonási utasításokat igényel. Tekintse meg alább az egyéb frissítési módszereket életképesebb alternatívákért.

Frissítési módszerek megvalósítása az ügyfélkönyvtárban, amelyek a fenti parancsokhoz hasonlóan viselkednek kubectl, be kell állítani a kérésekben content-type в application/strategic-merge-patch+json. Ha el akarja távolítani a tulajdonságokat egy specifikációból, akkor hasonló módon explicit módon nullára kell állítania az értékeiket. kubectl patch. Ha el kell távolítania a tömbelemeket, vegyen fel egyesítési direktívákat a frissítési specifikációba, vagy használjon más megközelítést a frissítésekhez.

A frissítések egyéb megközelítései

A Kubernetes két másik frissítési megközelítést is támogat: JSON egyesítési javítás и JSON javítás. A JSON egyesítési javítási megközelítés részleges Kubernetes-specifikációt használ bemenetként, és támogatja az objektumok egyesítését, hasonlóan a stratégiai összevonási javítási megközelítéshez. A kettő közötti különbség az, hogy csak a tömb cseréjét támogatja, beleértve a tárolótömböt a pod specifikációban. Ez azt jelenti, hogy JSON-egyesítési javítás használatakor meg kell adnia az összes tároló teljes specifikációját arra az esetre, ha a tároló bármely tulajdonsága megváltozna. Tehát ez a megközelítés hasznos az elemek eltávolításához egy darabjegyzék tömbjéből. A parancssorban kiválaszthatja a JSON egyesítési javítást kubectl patch --type=merge. Ha a Kubernetes API-val dolgozik, használja a kérési módszert PATCH és telepítés content-type в application/merge-patch+json.

A JSON-javítási megközelítés az erőforrás részleges specifikációja helyett az erőforráson végrehajtani kívánt módosításokat tömbként biztosítja, amelyben a tömb minden eleme az erőforráson végrehajtott módosítás leírását jelenti. Ez a megközelítés rugalmasabb és hatékonyabb módja a végrehajtott változtatások kifejezésének, de annak az árán, hogy a végrehajtott változtatásokat külön, nem Kubernetes formátumban listázzák, ahelyett, hogy részleges erőforrás-specifikációt küldenének. BAN BEN kubectl segítségével kiválaszthatja a JSON javítást kubectl patch --type=json. A Kubernetes API használatakor ez a megközelítés a kérési módszerrel működik PATCH és telepítés content-type в application/json-patch+json.

Bizalomra van szükségünk – használja a helyettesítést

Bizonyos esetekben meg kell győződnie arról, hogy az erőforráson nem történik változás az erőforrás olvasása és frissítése között. Más szóval, meg kell győződnie arról, hogy minden változtatás megtörténik atom. Ebben az esetben az erőforrások frissítéséhez használja replace. Ha például több forrásból frissített számlálóval rendelkező ConfigMap-je van, akkor biztosnak kell lennie abban, hogy két forrás nem frissíti egyszerre a számlálót, ami a frissítés elvesztését okozza. A bemutatáshoz képzelje el az események sorozatát a megközelítés segítségével patch:

• A és B megkapja az erőforrás aktuális állapotát az API-tól
• Mindegyik helyileg frissíti a specifikációt úgy, hogy eggyel növeli a számlálót, és hozzáadja az "A" vagy "B" értéket az "updated-by" megjegyzéshez.
• És egy kicsit gyorsabban frissíti az erőforrást
• B frissíti az erőforrást

Ennek eredményeként az A frissítés elveszik. Utolsó művelet patch nyer, a számláló kettő helyett eggyel növekszik, és az "updated-by" megjegyzés értéke "B"-re végződik, és nem tartalmaz "A"-t. Hasonlítsuk össze a fentieket azzal, hogy mi történik, ha a frissítések a megközelítés használatával történnek replace:

• A és B megkapja az erőforrás aktuális állapotát az API-tól
• Mindegyik helyileg frissíti a specifikációt úgy, hogy eggyel növeli a számlálót, és hozzáadja az "A" vagy "B" értéket az "updated-by" megjegyzéshez.
• És egy kicsit gyorsabban frissíti az erőforrást
• B megpróbálja frissíteni az erőforrást, de az API visszautasítja a frissítést, mert az erőforrás verziója szerepel a specifikációban replace nem egyezik az erőforrás jelenlegi verziójával a Kubernetesben, mert az erőforrás verzióját növelte az A csere művelete.

A fenti esetben B-nek újra le kell kérnie az erőforrást, módosítania kell az új állapotot, és újra meg kell próbálnia replace. Ez azt eredményezi, hogy a számláló kettővel növekszik, és az "updated-by" megjegyzésben az "AB" szerepel a végén.

A fenti példa arra utal, hogy végrehajtáskor replace A teljes erőforrás teljesen kicserélődik. Ehhez használt specifikáció replace, nem lehet részleges, vagy részleges, mint a apply, de teljes, beleértve a kiegészítést is resourceVersion a specifikáció metaadataiba. Ha nem engedélyezte resourceVersion vagy az Ön által megadott verzió nem aktuális, a csere elutasításra kerül. Tehát a használat legjobb módja az replace – olvassa el a forrást, frissítse és azonnal cserélje ki. Használata kubectl, így nézhet ki:

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

Érdemes megjegyezni, hogy a következő két parancs egymás után végrehajtva sikeresen végrehajtódik, mivel deployment.yaml nem tartalmaz tulajdont .metadata.resourceVersion

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

Ez ellentmondani látszik a fentebb elmondottaknak, pl. " hozzátéve resourceVersion a specifikáció metaadataiba." Helytelen ezt mondani? Nem, nem, mert ha kubectl észreveszi, hogy nem adtad meg resourceVersion, akkor beolvassa az erőforrásból, és hozzáadja az Ön által megadott specifikációhoz, és csak ezután hajtja végre replace. Mivel ez potenciálisan veszélyes, ha az atomitásra hagyatkozik, a varázslat teljes mértékben oldalról hat kubectl, ne hagyatkozzon rá, ha olyan ügyfélkönyvtárakat használ, amelyek együttműködnek az API-val. Ebben az esetben el kell olvasnia az aktuális erőforrás-specifikációt, frissítenie kell, majd végre kell hajtania PUT kérés.

Nem lehet javítani – mi cseréljük

Néha olyan változtatásokat kell végrehajtania, amelyeket az API nem képes kezelni. Ezekben az esetekben az erőforrás törlésével és újbóli létrehozásával kényszerítheti az erőforrás cseréjét. Ez segítségével történik kubectl replace --force. A parancs futtatása azonnal eltávolítja az erőforrásokat, majd újra létrehozza őket a mellékelt specifikációból. Az API-ban nincs "kényszerített csere" kezelő, és ahhoz, hogy ezt az API-n keresztül megtehesse, két műveletet kell végrehajtania. Először törölnie kell az erőforrást a beállítással gracePeriodSeconds nullára (0) és propagationPolicy a „Háttérben”, majd hozza létre újra ezt az erőforrást a kívánt specifikációval.

Figyelmeztetés: Ez a megközelítés potenciálisan veszélyes, és meghatározatlan állapothoz vezethet.

Jelentkezés a szerver oldalon

Mint fentebb említettük, a Kubernetes fejlesztői a logika megvalósításán dolgoznak apply A kubectl a Kubernetes API-ban. Logikák apply elérhető a Kubernetes 1.18-ban keresztül kubectl apply --server-side vagy az API-n keresztül a metódus használatával PATCH с content-type application/apply-patch+YAML.

Megjegyzés: A JSON is érvényes YAML, így a specifikációt akkor is elküldheti JSON-ként, ha content-type akarat application/apply-patch+yaml.

Ezen a logikán kívül kubectl API-n keresztül mindenki számára elérhetővé válik, apply szerver oldalon nyomon követi, hogy ki a felelős a specifikációban szereplő mezőkért, így biztonságos többszörös hozzáférést tesz lehetővé konfliktusmentes szerkesztéséhez. Más szóval, ha apply A szerver oldalon egyre elterjedtebb lesz, egy univerzális biztonságos erőforrás-kezelő felület jelenik meg a különböző kliensekhez, például a kubectl, a Pulumi vagy a Terraform, a GitOps, valamint a klienskönyvtárak segítségével saját maga írt szkriptek.

Eredményei

Remélem, ez a rövid áttekintés az erőforrások fürtökben történő frissítésének különböző módjairól hasznos volt az Ön számára. Jó tudni, hogy nem csak az alkalmazás és a csere jelenti a különbséget, hanem az alkalmazás, a szerkesztés, a javítás vagy a csere segítségével frissíthető az erőforrás. Végül is elvileg minden megközelítésnek megvan a maga alkalmazási területe. Az atomi változtatásokhoz a csere előnyösebb, ellenkező esetben a stratégiai egyesítési foltot kell használnia az Apply segítségével. Arra számítok, hogy legalább megértse, hogy nem bízhat a Google-ban vagy a StackOerflow-ban, amikor a „kubernetes alkalmazza vagy cserélje” kifejezésre keres. Legalábbis addig, amíg ez a cikk fel nem váltja a jelenlegi választ.

Forrás: will.com