Háromirányú egyesülés a werf-ben: Kubernetesbe történő bevezetés Helmen keresztül „szteroidokon”

Erre vártunk már olyan régen: a werf, a nyílt forráskódú eszköz, amely alkalmazásokat épít és telepít a Kubernetesbe, ezentúl támogatja a változtatások alkalmazását háromutas egyesítésű javítások segítségével! Ezenkívül lehetőség van a meglévő K8-erőforrások átvételére a Helm kiadásokhoz anélkül, hogy ezeket az erőforrásokat újra kellene létrehozni.

Röviden: beállíthatja a WERF_THREE_WAY_MERGE = engedélyezett beállítást, és rendelkezhet egy kubectl application- -val, mint például a meglévő Helm 2-alapú telepítésekkel kompatibilis telepítési folyamat (és még egy kicsit többet is) .

Kezdjük azonban egy elmélettel. Mik a háromirányú egyesítésű foltok? Hogyan találták fel őket, és miért annyira elengedhetetlenek a Kubernetes-alapú infrastruktúrával rendelkező CI / CD-folyamatokhoz? Később pedig a werf háromutas egyesítési folyamatát fogjuk megvitatni, alapértelmezés szerint milyen módokat használunk, és hogyan kezelhetitek ezeket a dolgokat.

Mi az a háromutas egyesítésű javítás?

Kezdjük azzal a feladattal, hogy a YAML-manifestekben ismertetett erőforrásokat a Kuberneteshez telepítsük.

A Kubernetes API a következő alapvető parancsokat biztosítja az erőforrásokkal való munkavégzéshez: create , patch , cserélje és delete . Feladatunk az erőforrások egyszerűen használható folyamatos telepítése egy fürtbe ezekkel a parancsokkal. Hogyan lehet ezt megtenni?

A kubectl parancsok kötelező érvényűek

Az objektumok Kubernetes-kezelésének alapvető megközelítése úgynevezett imperatív kubectl-parancsokat tartalmaz az objektumok létrehozására, módosítására és törlésére. Egyszerűen fogalmazva

Ez a megközelítés első látásra kényelmesnek tűnhet. Ennek azonban több nehézsége van:

Ez a megközelítés nem egyszerűen kompatibilis a konfigurációk alkalmazáskóddal történő tárolásával. Nem kompatibilis a teljes infrastruktúra-kódként (IaC) megközelítéssel ... vagy akár a GitOps-szal, mint a modernebb alternatívával, amely gyorsan népszerűvé válik a Kubernetes ökoszisztémában. Ezért felhagytak ezzel a kubectl parancs-alapú megközelítéssel.

Létrehozás, lekérés, kicserélés és törlés

A kezdeti létrehozás nagyon könnyen megvalósítható: csak meg kell adnia egy manifesztet a kube-api számára, és a szükséges erőforrás létrejön. Tárolhatja a jegyzék YAML reprezentációját a Git alkalmazásban, és az erőforrás létrehozásához használhatja a kubectl create -f manifest.yaml fájlt.

A törlés szintén könnyen elvégezhető: egyszerűen illessze be a fenti manifest.yaml fájlt a kubectl delete -f manifest.yaml fájlba.

A csere művelet lehetővé teszi az erőforrás konfigurációjának cseréjét egy újra anélkül, hogy újra létrehozná az erőforrást. Ez azt jelenti, hogy az erőforrás módosítása előtt kérheti az aktuális verziót a get paranccsal, módosíthatja azt, és frissítheti a csere paranccsal. A kube-apiserver támogatja az optimista zárolást, és ha egy objektum megváltozott a get művelet után, akkor a csere művelet sikertelen lesz.

A konfiguráció Git-ben történő tárolásához és a cserével történő frissítéséhez be kell szereznie, össze kell egyesítenie a Git-konfigurációt a kapott konfigurációval, majd végre kell hajtania a csere parancsot. Normál esetben a kubectl csak a kubectl -f manifest.yaml helyettesítését teszi lehetővé, ahol a manifest.yaml egy teljesen előre elkészített (esetünkben egyesített) manifeszt, amelyre szükség van. telepíteni kell. Kiderült, hogy a felhasználónak manuálisan kell egyesítenie a manifesztumokat (mondanunk kell, hogy nem triviális feladat).

Érdemes megjegyezni azt is, hogy bár a manifest.yaml tárolva van a Git-ben, nem tudhatjuk előre, hogy objektumot kell-e létrehoznunk vagy frissítenünk - ez a felhasználó szoftverének feladata.

Következtetés: szervezhetünk-e folyamatos telepítést direktívák létrehozásával, cseréjével és törlésével, miközben az infrastruktúra konfigurációját a Gitben tároljuk a kód mellett, és felhasználóbarát CI / CD folyamatot valósítunk meg?

Ami azt illeti, igen. Ehhez be kell építenie a manifesztek összevonását néhány csomagolóval együtt, amely:

A frissítés során figyelembe kell venni, hogy az erőforrás megváltozhat a legutóbbi get parancs óta. Az optimista zárolás esetén a csomagolónak automatikusan meg kell próbálnia az erőforrás frissítését.

De miért találja újra a kereket, ha a kube-apiserver már rendelkezik egy másik remek módszerrel az erőforrások frissítésére a patch paranccsal? A javítás megkönnyíti a felhasználót a fenti nehézségek közül.

Javítás

És eljutottunk a régóta várt javításokhoz. A javítás a Kubernetes objektumok változásainak alkalmazásának fő módszere. A patch parancs a következőképpen működik:

Ebben az esetben nincs szükség optimista reteszelésre. Ez az eljárás inkább deklaratív, mintsem pótolja (bár elsőre fordítva tűnhet).

Ezért a következőt használjuk:

Lényeges szempont: hogy mindez valósággá váljon, létre kell hoznia a megfelelő javítást !

Kétirányú összevonás, ahogy a foltok működnek a Helm 2-ben

Az első kiadás telepítése során Helm egy create műveletet hajt végre a diagram erőforrásain.

Kiadás frissítésekor Helm:

Egy ilyen javítást kétirányú egyesítés nek fogunk hívni, mert kétféle megnyilvánuláson alapszik:

Törléskor a kube-apiserverben található delete műveletet olyan erőforrásokhoz használják, amelyeket az előző kiadás definiált, de a jelenlegi nem határoz meg.

A 2-way-merge-patch megközelítésnek problémája van: deszinkronizációhoz vezet a fürt erőforrásának valós állapota és a Gitben megnyilvánuló között.

Példa erre a problémára

Ebben az esetben erőforrásunk elveszítette a jegyzékkel való szinkronizálást, valamint a deklarativitást.

Mi az a szinkronizált erőforrás?

Lehetetlen abszolút egyformaságot elérni a futó fürt manifesztumának és a Gitben nyilvánvalónak. A valódi kiáltványban lehetnek szolgáltatásjegyzetek / címkék, kiegészítő tárolók és egyéb adatok, amelyeket a vezérlők dinamikusan adnak hozzá és törölnek az erőforrásból. Nem tárolhatjuk (és nem is akarjuk) ezeket az adatokat a Git adattárban. A telepítés során azonban a Git által kifejezetten megadott mezőknek megfelelő értékeket kell felvenniük.

Itt van egy általános szinkronizált erőforrás szabály: a telepítés során csak azokat a mezőket módosíthatja vagy törölheti, amelyek a Git-tárból kifejezetten a jegyzékben vannak megadva (vagy amelyeket a előző verzió és eltávolítva a jelenlegi verzióból).

háromutas egyesítésű javítás

A háromirányú egyesítés javításának alapötlete az, hogy javítást generáljon a Git-tárból származó, a jegyzékben utoljára alkalmazott verzió és a Git-jegyzék célváltozatának felhasználásával, figyelembe véve a jegyzék aktuális verzióját. a futó fürtből. Az utolsó javításnak meg kell felelnie a szinkronizált erőforrás szabályának:

Ez ugyanaz az elv, amelyet a kubectl sovelletaan használ a javítások előállításához:

Most, hogy gondoskodtunk az elméletről, itt az ideje megvitatni a werf legújabb fejleményeit.

Változások alkalmazása a werf-ben

Korábban a werf (mint a Helm 2) kétirányú egyesítésű javításokat használt.

Javítás javítás

A foltok új stílusára való áttéréshez - a háromirányú egyesítéshez - elsősorban az úgynevezett javítási javításokat hajtottuk végre.

Telepítéskor a szokásos kétirányú egyesítési javítást használjuk. A werf azonban generál egy extra javítást, amely szinkronizálja az erőforrás valós állapotát a Gitben megadott állapottal (ez a javítás a fent leírt szinkronizált erőforrásra vonatkozó szabály használatával jön létre).

Szinkronizálás esetén, mielőtt a telepítés befejeződik, a felhasználó egy FIGYELMEZTETŐ üzenetet kap, amely egy javítást tartalmaz, amelyet alkalmaznia kell az erőforrás szinkronizált űrlapra hozatalához. Ez a javítás a werf.io/repair-patch feliratba is mentésre kerül. A felhasználónak manuálisan kell alkalmaznia a javító javítást: a werf elvben nem fogja megtenni a felhasználó számára.

A javítási javítások generálása egy ideiglenes intézkedés, amely lehetővé teszi a háromirányú egyesítésű javítások tesztelését (nem automatikusan alkalmazza őket). Jelenleg ez a működési mód alapértelmezés szerint engedélyezett.

Háromutas merge javítások csak új kiadásokhoz

2019. december 1-jétől a werf béta és alfa verziói alapértelmezés szerint elindulnak, teljes értékű, háromirányú egyesítésű javítások alkalmazásával, a Werf-en keresztül telepített új Helm-kiadások módosításainak alkalmazásához. A meglévő kiadások továbbra is a kétirányú egyesítés + javítás javítás megközelítést használják.

Ezt az üzemmódot azonnal engedélyezheti a WERF_THREE_WAY_MERGE_MODE = onlyNewReleases beállításával.

Megjegyzés : Ez a szolgáltatás számos werf kiadás során fejlődött. Késznek nyilvánították az alfacsatornában kezdődő v1.0.5-alpha.19 kezdettel és v1.0.4-beta.20 a béta csatornában.

Háromutas merge javítások minden kiadáshoz

2019. december 15-től a werf béta és alfa verziói teljes értékű, háromutas egyesítésű javításokat fognak használni a változások módosításához.

Ezt az üzemmódot azonnal engedélyezheti a WERF_THREE_WAY_MERGE_MODE = engedélyezett beállításával.

Mi a helyzet az erőforrások automatikus skálázásával?

A Kubernetesben kétféle automatikus skálázás létezik: HPA (vízszintes) és VPA (függőleges).

A HPA skálázza a podreplikák számát, míg a VPA több (vagy kevesebb) erőforrást allokál a meglévő podokhoz. A replikák számát és az erőforrásigényeket egyaránt meghatározza az erőforrásjegyzék (lásd: spec.replicas vagy spec.containers []. Resources.limits.cpu , spec .containers []. resources.limits.memory stb.).

De itt van a probléma: Ha a diagram erőforrása úgy van konfigurálva, hogy az az erőforrások vagy másolatok meghatározott értékeit tartalmazza, és az erőforrás automatikus skálázása engedélyezve van, akkor ezek az értékek visszaállnak a diagram nyilvántartásában megadott értékekre minden egyes bevetéssel.

Ennek a problémának két megoldása van. Először is, nem szabad kifejezetten meghatározni az automatikus skálázás értékeit a diagram nyilvántartásában. Ha ez a változat valamilyen oknál fogva nem megfelelő (például azért, mert kényelmes megadni a kezdeti erőforráskorlátokat és a diagramban lévő replikák számát), akkor a werf a következő feliratozásokat biztosítja:

Ezzel a megjegyzéssel a werf nem állítja vissza a megfelelő értékeket minden telepítéskor - csak az erőforrás kezdeti létrehozása során állítja be őket.

További információ a HPA és a VPA projektdokumentációjában található.

A háromutas egyesítésű javítások letiltása

Jelenleg a felhasználónak lehetősége van egy új típusú javítások letiltására a werf-ben a WERF_THREE_WAY_MERGE_MODE = letiltva beállításával. 2020. március 1-jétől azonban ez a lehetőség megszűnik , és csak a háromirányú egyesítésű javításokat támogatjuk.

Erőforrások elfogadása a werf-ben

A változtatások háromirányú egyesítésű javításokkal történő alkalmazása közben úgy döntöttünk, hogy a klaszterben meglévő erőforrásokat a Helm kiadásba is beépítjük.

A Helm 2 problémája van: nem adhat hozzá erőforrást a fürtben már meglévő diagramjegyzékekhez anélkül, hogy ezt az erőforrást a semmiből újból létrehozná (lásd: # 6031, # 3275). Megtanítottuk werf-nek, hogyan kell a meglévő erőforrásokat átvenni a kiadáshoz. Ehhez feljegyzést kell telepítenie az erőforrás aktuális verziójára egy futó fürtből (például a kubectl edit segítségével):

& quot; werf.io/allow-adoption-by-release" ;: RELEASE_NAME

Most le kell írnia az erőforrást egy diagramban. Legközelebb, amikor a werf a megfelelő nevet veszi igénybe a kiadásban, a meglévő erőforrást a kiadás fogja elfogadni, és továbbra is az irányítása alatt marad. Ezenkívül az erőforrás kiadás általi átvétele során a werf az erőforrás aktuális állapotát a futó fürtből a diagramban leírt állapotba hozza ugyanazon háromutas egyesítési javítások és a szinkronizált erőforrásszabály használatával. p>

Megjegyzés : A WERF_THREE_WAY_MERGE_MODE környezeti változó nem befolyásolja az erőforrások elfogadása. Örökbefogadás esetén a háromirányú egyesítésű javítások az egyetlen választás.

További részletek megtalálhatók a dokumentációban.

Következtetések és tervek

Remélem, hogy ez a cikk tisztázta a háromutas egyesítésű javítások egyes aspektusait és azok megvalósításának indoklását. Gyakorlati szempontból integrációjuk újabb lépést jelent a Helm-szerű telepítési folyamat javítása felé. Most megfeledkezhet a konfiguráció szinkronizálásának összetettségéről, amely korábban a Helm 2-t sújtotta. Eközben hozzáadtunk egy új és hasznos funkciót: mostantól a Helm kiadásai átvehetik a telepített Kubernetes erőforrásokat.

Még mindig vannak problémák a Helm-szerű telepítési folyamatokkal kapcsolatban, például a Go sablonok használata. Tovább fogunk dolgozni rajtuk.

Itt további információkat talál az erőforrás frissítésének és elfogadásának módszereiről.

Helm 3

Mivel a Helm új nagy verziója - v3 - alig két hete jelent meg, és háromirányú összeolvadási javításokat is tartalmaz, külön említést érdemel itt. Az új Helm verzió megköveteli a meglévő telepítések áttelepítését, hogy a kiadások tárolásának új formátumává konvertálják őket.

A werf a maga részéről már teljesen elhagyta a Tillert, 3-irányú egyesítésű javításokra váltott, számos egyéb hasznos funkciót megvalósított, miközben kompatibilis maradt a meglévő Helm 2 telepítésekkel (nem kell futtatni bármilyen migrációs szkript). Ezért a werf-felhasználók élvezhetik a Helm 3 összes előnyét a Helm 2-vel szemben, még akkor is, ha a werf még nem teljes mértékben a Helm 3-ra vált.

A werf áttérése a Helm 3 kódbázisra azonban hamarosan bekövetkezik, és hamarosan bekövetkezik. Várhatóan a werf 1.1 vagy a werf 1.2 esetén fordul elő. A werf jelenlegi verziója 1.0, a werf verzióséma további részletei itt érhetők el. Így a Helm 3-nak ideje stabilizálódni.

Ezt a cikket eredetileg a rendszerfejlesztőnk Timofey Kirillov írta. Kövesse blogunkat , hogy új kiváló tartalmat szerezzen a Flant-tól!