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 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 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, kubectl
a 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 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 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 apply
Ez 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 patch
hogy 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: 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
akaratapplication/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