Jegyzet. ford.: Idén május 16-a jelentős mérföldkő a Kubernetes - Helm csomagkezelőjének fejlesztésében. Ezen a napon mutatták be a projekt leendő főverziójának – a 3.0-nak – az első alfa kiadását. Megjelenése jelentős és régóta várt változásokat hoz a Helmben, amihez a Kubernetes közösségben sokan nagy reményeket fűznek. Mi magunk is ezek közé tartozunk, hiszen aktívan használjuk a Helmet az alkalmazások telepítéséhez: integráltuk a CI/CD implementációs eszközünkbe. és időről időre hozzájárulunk az upstream fejlesztéséhez. Ez a fordítás a hivatalos Helm blog 7 jegyzetét egyesíti, amelyeket a Helm 3 első alfa kiadásának szenteltek, és amelyek a projekt történetéről és a Helm 3 főbb jellemzőiről szólnak. Szerzőjük Matt „bacongobbler” Fisher, a Microsoft alkalmazottja és a Helm egyik legfontosabb fenntartója.
15. október 2015-én megszületett a ma Helm néven ismert projekt. Mindössze egy évvel az alapítás után a Helm közösség csatlakozott a Kuberneteshez, miközben aktívan dolgozott a Helm 2-n. 2018 júniusában a Helm fejlesztő (inkubáló) projektként. Gyorsan előre a jelenbe, és úton van az új Helm 3 első alfa kiadása. (ez a kiadás május közepén - kb. fordítás.).
Ebben a részben arról fogok beszélni, hogy hol kezdődött minden, hogyan jutottunk el oda, ahol ma vagyunk, bemutatok néhány egyedi funkciót, amelyek a Helm 3 első alfa kiadásában elérhetők, és elmagyarázom, hogyan tervezzük a továbblépést.
Összegzés:
- Helm létrejöttének története;
- gyengéd búcsú Tillertől;
- diagramtárak;
- kiadáskezelés;
- a diagram függőségek változásai;
- könyvtári diagramok;
- mi a következő lépés?
Helm története
A születése
A Helm 1 a Deis által létrehozott nyílt forráskódú projektként indult. Kis startup voltunk A Microsoft 2017 tavaszán. A másik nyílt forráskódú projektünknek, a szintén Deisnek is volt, volt egy eszköze deisctl, amelyet (többek között) a Deis platform telepítésére és működtetésére használtak . Abban az időben a Fleet volt az egyik első konténer hangszerelési platform.
2015 közepén úgy döntöttünk, hogy irányt váltunk, és áthelyeztük a Deist (akkoriban Deis Workflow néven) a Fleetről a Kubernetesre. Az egyik első, amelyet újraterveztek, a telepítőeszköz volt. deisctl. Használtuk a Deis Workflow telepítéséhez és kezeléséhez a flottafürtben.
A Helm 1 olyan híres csomagkezelők képére jött létre, mint a Homebrew, apt és yum. Fő célja az volt, hogy egyszerűsítse az olyan feladatokat, mint például az alkalmazások csomagolása és telepítése a Kubernetesen. A Helmet hivatalosan 2015-ben mutatták be a KubeCon konferencián San Franciscóban.
Az első próbálkozásunk Helmmel sikerült, de nem volt mentes néhány komoly korláttól. Bevezető YAML blokkként generátorokkal ízesített Kubernetes manifeszteket vett. (elöljáró)*, és betöltötte az eredményeket a Kubernetesbe.
* Jegyzet. ford.: A Helm első verziójából a YAML szintaxist választották a Kubernetes erőforrások leírására, és a Jinja sablonok és a Python szkriptek támogatottak a konfigurációk írásakor. Erről és általában a Helm első változatának felépítéséről bővebben az „A Helm rövid története” című fejezetben írtunk. .
Például egy YAML-fájl mezőjének lecseréléséhez hozzá kellett adnia a következő konstrukciót a jegyzékhez:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlNagyszerű, hogy ma is léteznek sablonmotorok, nem igaz?
Ennek a korai Kubernetes-telepítőnek több okból is szüksége volt a jegyzékfájlok kemény kódolt listájára, és csak egy kis, rögzített eseménysorozatot hajtott végre. Annyira nehéz volt használni, hogy a Deis Workflow K+F csapata nehezen tudta átvinni termékét erre a platformra – az ötlet magvai azonban már el lettek vetve. Az első próbálkozásunk nagyszerű tanulási lehetőség volt: rájöttünk, hogy igazán szenvedélyesen szeretünk olyan pragmatikus eszközöket készíteni, amelyek megoldják a felhasználók mindennapi problémáit.
A múltbeli hibák tapasztalatai alapján elkezdtük a Helm 2 fejlesztését.
Helm készítése 2
2015 végén a Google csapata felvette velünk a kapcsolatot. Hasonló eszközön dolgoztak a Kubernetes számára. A Kubernetes Deployment Manager egy meglévő eszköz portja volt, amelyet a Google Cloud Platformhoz használtak. „Szeretnénk – kérdezték –, ha néhány napot eltöltünk a hasonlóságok és különbségek megvitatásával?”
2016 januárjában a Helm és a Deployment Manager csapata Seattle-ben találkozott, hogy eszmét cseréljenek. A tárgyalások egy ambiciózus tervvel zárultak: a két projektet kombinálva létrehozzák a Helm 2-t. A Deis és a Google mellett a srácok (most a Bitnami része – kb. fordítás), és elkezdtünk dolgozni a Helm 2-n.
Meg akartuk őrizni a Helm könnyű kezelhetőségét, de a következőket adjuk hozzá:
- diagramsablonok testreszabáshoz;
- klaszteren belüli menedzsment csapatok számára;
- világszínvonalú diagramtár;
- stabil csomagformátum aláírási lehetőséggel;
- erős elkötelezettség a szemantikai verziókezelés és a verziók közötti visszamenőleges kompatibilitás fenntartása mellett.
E célok elérése érdekében a Helm ökoszisztémát egy második elemmel egészítették ki. Ezt a fürtön belüli összetevőt Tillernek hívták, és a Helm diagramok telepítéséért és kezeléséért volt felelős.
A Helm 2 2016-os megjelenése óta a Kubernetes számos jelentős újítással bővült. Hozzáadott szerepkör alapú hozzáférés-vezérlés (), amely végül felváltotta az attribútum-alapú hozzáférés-vezérlést (ABAC). Új erőforrástípusokat vezettek be (a Telepítések akkor még béta állapotban voltak). Feltalálták az egyéni erőforrás-definíciókat (eredeti nevén Third Party Resources vagy TPR-k). És ami a legfontosabb, egy sor bevált gyakorlat alakult ki.
Mindezen változások közepette a Helm továbbra is hűségesen szolgálta a Kubernetes felhasználókat. Három év és sok új kiegészítés után egyértelművé vált, hogy ideje jelentős változtatásokat végrehajtani a kódbázison, hogy a Helm továbbra is megfelelhessen a fejlődő ökoszisztéma növekvő igényeinek.
Gyengéd búcsú Tillertől
A Helm 2 fejlesztése során bevezettük a Tillert a Google Deployment Managerrel való integrációnk részeként. A Tiller fontos szerepet játszott a közös klaszterben dolgozó csapatok számára: lehetővé tette az infrastruktúrát üzemeltető különböző szakemberek számára, hogy ugyanazokkal a kiadásokkal kommunikáljanak.
Mivel a szerepalapú hozzáférés-vezérlés (RBAC) alapértelmezés szerint engedélyezve volt a Kubernetes 1.6-ban, a Tillerrel való munkavégzés az éles környezetben nehezebbé vált. A lehetséges biztonsági szabályzatok hatalmas száma miatt az volt az álláspontunk, hogy alapértelmezés szerint megengedő konfigurációt kínálunk. Ez lehetővé tette az újoncok számára, hogy kísérletezzenek a Helmmel és a Kubernetes-szel anélkül, hogy először a biztonsági beállításokba kellett volna belemerülniük. Sajnos ez az engedélykonfiguráció túlságosan széles körű engedélyekkel ruházhatja fel a felhasználót, amire nincs szüksége. A DevOps és az SRE mérnökeinek további műveleti lépéseket kellett megtanulniuk, amikor a Tillert több bérlős fürtbe telepítették.
Miután megtudtuk, hogy a közösség hogyan használja a Helmet bizonyos helyzetekben, rájöttünk, hogy a Tiller kiadáskezelő rendszerének nem kell fürtön belüli összetevőre támaszkodnia az állapot fenntartása vagy a kiadási információk központi csomópontjaként való működése érdekében. Ehelyett egyszerűen információkat kaphatunk a Kubernetes API-kiszolgálótól, létrehozhatunk egy diagramot az ügyféloldalon, és eltárolhatjuk a telepítés rekordját a Kubernetesben.
Tiller fő célja Tiller nélkül is elérhető lett volna, így az egyik első döntésünk a Helm 3 kapcsán az volt, hogy teljesen elhagyjuk Tillert.
Tiller megszűnésével Helm biztonsági modellje radikálisan leegyszerűsödött. A Helm 3 mostantól támogatja a jelenlegi Kubernetes összes modern biztonsági, identitás- és engedélyezési módszerét. A kormányengedélyek meghatározása a segítségével történik . A fürt adminisztrátorai a felhasználói jogokat bármilyen részletességi szintre korlátozhatják. A kiadások továbbra is a fürtön belül vannak mentve, és a Helm többi funkciója érintetlen marad.
Diagramtárak
Magas szinten a diagramtár olyan hely, ahol a diagramok tárolhatók és megoszthatók. A Helm kliens becsomagolja és elküldi a diagramokat a tárolóba. Egyszerűen fogalmazva, a diagramtár egy primitív HTTP-kiszolgáló index.yaml fájllal és néhány csomagolt diagrammal.
Bár van néhány előnye annak, hogy a Charts Repository API megfelel a legtöbb alapvető tárolási követelménynek, van néhány hátránya is:
- A diagramtárolók nem kompatibilisek az éles környezetben szükséges legtöbb biztonsági megvalósítással. A hitelesítéshez és engedélyezéshez szabványos API megléte rendkívül fontos a termelési forgatókönyvekben.
- A Helm diagram eredetmeghatározási eszközei, amelyeket a diagramok aláírására, integritásának és eredetének ellenőrzésére használnak, a diagram közzétételi folyamatának opcionális részét képezik.
- Többfelhasználós forgatókönyv esetén ugyanazt a diagramot egy másik felhasználó is feltöltheti, ami megkétszerezi az ugyanazon tartalom tárolásához szükséges helyet. Okosabb adattárakat fejlesztettek ki a probléma megoldására, de ezek nem részei a formális specifikációnak.
- Egyetlen indexfájl használata a kereséshez, a metaadatok tárolásához és a diagramok lekéréséhez megnehezítette a biztonságos többfelhasználós megvalósítások fejlesztését.
Terv (más néven Docker Registry v2) a Docker Registry utódja, és alapvetően a Docker-képfájlok csomagolására, szállítására, tárolására és kézbesítésére szolgáló eszközkészletként működik. Számos nagy felhőszolgáltatás kínál terjesztési alapú termékeket. Ennek a fokozott figyelemnek köszönhetően a Distribution projekt több éven át tartó fejlesztések, bevált biztonsági gyakorlatok és helyszíni tesztelések előnyeit élvezte, amelyek a nyílt forráskódú világ egyik legsikeresebb, nem énekelt hősévé tették.
De tudtad, hogy a terjesztési projektet bármilyen tartalom terjesztésére tervezték, nem csak konténerképeket?
Az erőfeszítéseknek köszönhetően (vagy OCI), Helm diagramok elhelyezhetők bármely terjesztési példányon. Ez a folyamat egyelőre kísérleti jellegű. A bejelentkezési támogatás és a teljes Helm 3-hoz szükséges egyéb funkciók folyamatban vannak, de izgatottan várjuk, hogy tanuljunk az OCI és a Distribution csapatának az évek során tett felfedezéséből. Mentorálásuk és útmutatásuk révén pedig megtanuljuk, milyen egy magasan elérhető szolgáltatást nagyarányúan működtetni.
A Helm diagram tárolóinak néhány közelgő változásának részletesebb leírása elérhető .
Kiadáskezelés
A Helm 3-ban az alkalmazás állapotát a fürtön belül egy pár objektum követi nyomon:
- kiadás objektum – egy alkalmazáspéldányt képvisel;
- verzió titkos kiadása – az alkalmazás kívánt állapotát jelenti egy adott időpontban (például egy új verzió kiadásakor).
hívás helm install kiadási objektumot és titkos kiadási verziót hoz létre. Hívás helm upgrade kiadási objektumot igényel (amelyet megváltoztathat), és létrehoz egy új kiadási verzió titkát, amely tartalmazza az új értékeket és egy előkészített jegyzéket.
A kiadás objektum információkat tartalmaz a kiadásról, ahol a kiadás egy elnevezett diagram és értékek meghatározott telepítése. Ez az objektum a kiadás legfelső szintű metaadatait írja le. A kiadási objektum az alkalmazás teljes életciklusa alatt megmarad, és az összes kiadási verzió titkának, valamint a Helm diagram által közvetlenül létrehozott objektumnak a tulajdonosa.
A kiadási verzió titkossága a kiadást egy sor változathoz társítja (telepítés, frissítések, visszaállítások, törlés).
A Helm 2-ben a felülvizsgálatok rendkívül következetesek voltak. Hívás helm install létrehozott v1, az azt követő frissítés (frissítés) - v2, és így tovább. A kiadás és a kiadási titkosítás egyetlen objektummá, változat néven össze lett csukva. A változatok ugyanabban a névtérben voltak tárolva, mint a Tiller, ami azt jelentette, hogy minden kiadás "globális" névteret tekintve; ennek eredményeként a névnek csak egy példánya volt használható.
A Helm 3-ban minden kiadáshoz egy vagy több kiadási verzió titka tartozik. A kiadási objektum mindig a Kubernetesben telepített aktuális kiadást írja le. Minden kiadási titkosítás csak az adott kiadás egy verzióját írja le. A frissítés például létrehoz egy új kiadási verzió titkát, majd módosítja a kiadási objektumot, hogy az új verzióra mutasson. Visszaállítás esetén a korábbi verzió titkait használhatja a kiadás korábbi állapotra való visszaállításához.
Miután a Tillert elhagyták, a Helm 3 a kiadás adatait ugyanabban a névtérben tárolja, mint a kiadás. Ez a módosítás lehetővé teszi, hogy telepítsen egy diagramot ugyanazzal a kiadásnévvel egy másik névtérben, és az adatok mentésre kerülnek a fürtfrissítések/újraindítások között az etcd-ben. Például telepítheti a WordPress-t a "foo" névtérbe, majd a "bar" névtérbe, és mindkét kiadás elnevezése "wordpress".
Változások a diagram függőségeiben
Diagramok csomagolva (használva helm package) a Helm 2-vel való használatra telepíthető a Helm 3-mal, azonban a diagramfejlesztési munkafolyamat teljesen megújult, ezért néhány változtatást végre kell hajtani a diagramfejlesztés Helm 3-mal történő folytatásához. Különösen a diagramfüggőség-kezelő rendszer változott.
A diagram függőségi kezelő rendszere elköltözött requirements.yaml и requirements.lock on Chart.yaml и Chart.lock. Ez azt jelenti, hogy a parancsot használó diagramok helm dependency, némi beállítás szükséges a Helm 3 használatához.
Nézzünk egy példát. Adjunk hozzá egy függőséget a Helm 2 diagramjához, és nézzük meg, mi változik, amikor a Helm 3-ra váltunk.
A Helm 2-ben requirements.yaml így nézett ki:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
A Helm 3-ban ugyanez a függőség tükröződik majd a tiédben is Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
A diagramok továbbra is letöltődnek és a könyvtárba kerülnek charts/, tehát aldiagramok (aldiagramok), a katalógusban hever charts/, változtatás nélkül tovább fog működni.
Bemutatjuk a könyvtári diagramokat
A Helm 3 a diagramok egy osztályát támogatja, amelyeket könyvtári diagramoknak neveznek (könyvtári táblázat). Ezt a diagramot más diagramok is használják, de önmagában nem hoz létre kiadási melléktermékeket. A könyvtári diagramsablonok csak elemeket deklarálhatnak define. A többi tartalmat egyszerűen figyelmen kívül hagyja. Ez lehetővé teszi a felhasználók számára, hogy újra felhasználják és megosszák azokat a kódrészleteket, amelyek több diagramon is használhatók, elkerülve ezzel a párhuzamosságot és betartva az elvet. .
A könyvtári diagramok a részben vannak deklarálva dependencies fájlban Chart.yaml. Ezek telepítése és kezelése nem különbözik a többi diagramtól.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioIzgatottan várjuk, hogy ez a komponens milyen használati eseteket fog megnyílni a diagramfejlesztők számára, valamint a könyvtári diagramokból kirajzolódó bevált gyakorlatok miatt.
Mi a következő lépés?
A Helm 3.0.0-alpha.1 az alapja, amelyre elkezdjük építeni a Helm új verzióját. A cikkben leírtam a Helm 3 néhány érdekes funkcióját. Sok közülük még a fejlesztés korai szakaszában van, és ez normális; Az alfa kiadás lényege, hogy teszteljük az ötletet, visszajelzéseket gyűjtsünk a korai felhasználóktól, és megerősítsük feltételezéseinket.
Amint megjelenik az alfa verzió (ne feledje, hogy ez - kb. fordítás.), elkezdjük elfogadni a Helm 3 javításait a közösségtől. Erős alapot kell teremtenie, amely lehetővé teszi új funkciók fejlesztését és átvételét, valamint azt, hogy a felhasználók úgy érezzék, részt vesznek a folyamatban a jegyek megnyitásával és a javítások elvégzésével.
Megpróbáltam kiemelni néhányat a Helm 3 főbb fejlesztései közül, de ez a lista korántsem teljes. A Helm 3 teljes ütemterve olyan funkciókat tartalmaz, mint a továbbfejlesztett frissítési stratégiák, az OCI-nyilvántartásokkal való mélyebb integráció, valamint a JSON-sémák használata a diagramértékek érvényesítésére. Azt is tervezzük, hogy megtisztítjuk a kódbázist és frissítjük az elmúlt három évben elhanyagolt részeit.
Ha úgy érzed, hogy lemaradtunk valamiről, szívesen meghallgatjuk a gondolataidat!
Csatlakozzon a beszélgetésünkhöz :
-
#helm-userskérdésekre és egyszerű kommunikációra a közösséggel; -
#helm-deva lehívási kérések, a kód és a hibák megvitatására.
Heti nyilvános fejlesztői hívásainkon is cseveghet csütörtökönként 19:30-kor MSK. A találkozók célja a kulcsfontosságú fejlesztők és a közösség által jelenleg is foglalkozó kérdések megvitatása, valamint a hét vitatémái. Bárki csatlakozhat és részt vehet a találkozón. A link elérhető a Slack csatornán #helm-dev.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «";
- «".
Forrás: will.com