🥇 Bevezetés a Helm 3-ba

Megjegyzés fordítás.: május 16-án jelentős mérföldkőhöz érkezett a Kubernetes csomagkezelőjének, a Helm-nek a fejlesztése. Ezen a napon bemutatták a projekt jövőbeli nagy verziójának első alfa kiadását – 3.0. Ennek megjelenése jelentős és régóta várt változásokat hoz a Helm-be, amelyekben sokan, a Kubernetes közösségében, nagy reményeket fűznek. Mi is közéjük tartozunk, mivel aktívan használjuk a Helmet alkalmazások telepítésére: integráltuk a CI/CD megvalósító eszközünkbe. werf és alkalomról alkalomra hozzájárulunk az upstream fejlesztéséhez. Ez a fordítás 7 megjegyzést egyesít a Helm hivatalos blogjából, amelyek az 1. alfa kiadásra vonatkoznak, és mesélnek a projektről és a Helm 3 főbb funkcióiról. Írója Matt „bacongobbler” Fisher, a Microsoft munkatársa és a Helm egyik kulcsfontosságú fenntartója.

2015. október 15-én született meg a projekt, ma Helm néven ismert. Csak egy évvel a megalakulása után a Helm közössége csatlakozott a Kuberneteshez, miközben aktívan dolgozott a Helm 2-n. 2018 júniusában a Helm a CNCF tagja lett fejlődő (incubating) projektként. Térjünk vissza a jelenbe – és már közelít az új Helm 3 első alfa kiadása, (ez a kiadás már meg is történt május közepén – a ford. megj.)..

Ebben az anyagban beszélek arról, hogy miként indult minden, hogyan jutottunk el a jelenlegi szakaszig, bemutatok néhány egyedi jellemzőt, amelyek az első alfa kiadásban elérhetők, és elmagyarázom, hogyan tervezünk tovább fejlődni.

Összefoglaló:

a Helm létrehozásának története;
szomorú búcsú a Tiller-től;
chart tárolók;
kiadások kezelése;
a chartok függőségeiben bekövetkezett változások;
library charts;
mi a következő lépés?

A Helm létrehozásának története

Születés

A Helm 1 nyílt forráskódú projektként kezdődött, amelyet a Deis indított. Mi egy kis startup voltunk, amelyet a Microsoft felvásárolt 2017 tavaszán. Másik nyílt forráskódú projektünk, amely szintén Deis névre hallgatott, egy olyan eszközt használt, aminek nevedeisctl , amelyet (mások mellett) a Deis platform telepítésére és üzemeltetésére használtaka Fleet klaszterben.

Abban az időben a Fleet volt az egyik első konténer orchestration platform. aminek neve2015 közepén úgy döntöttünk, hogy váltunk, és átálltunk a Deist (akkor Deis Workflow-ra átnevezett) a Fleet-ről a Kubernetes-re. Az egyik első lépés volt az telepítő eszköz átdolgozása, amelyet a Deis Workflow telepítésére és kezelésére használtunk a Fleet klaszterben.

A Helm 1 a híres csomagkezelők, például a Homebrew, az apt és a yum mintájára készült. Fő feladata a Kubernetes alkalmazások csomagolásának és telepítésének leegyszerűsítése volt. A Helm hivatalosan 2015-ben debütált a KubeCon konferencián San Franciscóban.

Az első kísérletünk a Helmmel sikeres volt, de nem kerültük el a komoly korlátokat. A Kubernetes manifestumok egy csoportját vette alapul, amelyeket generátorok díszítettek ki bemeneti YAML-blokkokként. (front-matter)*, és betöltötte az eredményeket a Kubernetesbe.

* Megjegyzés fordítás.: A Helm első verziójának megjelenésekor a Kubernetes erőforrások leírására a YAML szintaxis lett választva, és a konfigurációk írásakor Jinja és Python script sablonokat támogattak. Ezzel kapcsolatban és a Helm első verziójának felépítéséről a „Helm rövid története” fejezetben írtunk. ez anyag.

Például, ha egy mezőt szeretnénk kicserélni egy YAML-fájlban, a következő konstrukciót kellett hozzáadnunk a manifestumhoz:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Jó látni, hogy ma már léteznek sablonkezelők, nem igaz?

Sok okból ez a korai Kubernetes telepítő szigorúan meghatározott listát igényelt a manifest-fájlokról és csak egy kis rögzített eseményláncot futtatott. Annyira nehéz volt használni, hogy a Deis Workflow R&D csapatának nehézségei adódtak, amikor megpróbálták átváltani a terméküket erre a platformra — de az ötlet magjait már vetették. Az első próbálkozásunk nagyszerű lehetőség volt a tanulásra: rájöttünk, hogy igazán szenvedélyesen érdekelnek minket a pragmatikus eszközök létrehozása, amelyek a felhasználóink mindennapi problémáit oldják meg.

A korábbi hibák tapasztalataira támaszkodva elkezdtük a Helm 2 fejlesztését.

A Helm 2 létrehozása

2015 végén kapcsolatba lépett velünk a Google csapata. Egy hasonló eszközön dolgoztak a Kuberneteshez. A Deployment Manager a Google Cloud Platform számára használt eszköz portolása volt. „Nem akarunk-e néhány napot arra szánni, hogy megbeszéljük a hasonlóságokat és különbségeket?” – kérdezték.

2016 januárjában a Helm és a Deployment Manager csapatai Seattle-ben találkoztak, hogy ötleteket cseréljenek. A tárgyalások ambiciózus tervvel zárultak: a két projekt egyesítése Helm 2 létrehozására. A Deis és a Google mellett a fejlesztőcsapathoz csatlakoztak a SkippBox (jelenleg a Bitnami része — a fordító megj.), és elkezdtük a Helm 2 munkáját.

A Helm használatának egyszerűségét szerettük volna megőrizni, de a következőket hozzáadni:

sablonok testreszabásához;
belső klaszter kezelés csapatok számára;
kiváló chart repozitórium;
stabil csomagformátum aláírási lehetőséggel;
tökéletes elköteleződés a szemantikus verziózás és a verziók közötti visszafelé kompatibilitás fenntartása mellett.

E célok elérése érdekében a Helm ökoszisztémájához egy második elemet adtunk hozzá. Ezt a belső klaszter komponenst Tillernek neveztük el, amely a Helm chartok telepítésével és kezelésével foglalkozott.

A Helm 2 2016-os megjelenése óta a Kubernetes számos jelentős újítással gazdagodott. Bevezetésre került a szerepkör alapú hozzáférés-ellenőrzés (RBAC), amely végül helyettesítette az attribútumokon alapuló hozzáférés-ellenőrzést (ABAC). Új erőforrás típusok jelentek meg (a Deployments ekkor még bétaverzióban voltak). Feltalálták a Custom Resource Definitions-t (eredetileg Third Party Resources vagy TPR néven ismerték). És ami a legfontosabb - megjelent a legjobb gyakorlatok sora.

Mindezek változásai mellett a Helm továbbra is hű maradt a Kubernetes felhasználóihoz. Három év és számos új kiegészítés után nyilvánvalóvá vált, hogy jelentős változtatásokat kell végrehajtani a kódalapon, hogy a Helm továbbra is képes legyen kielégíteni a fejlődő ökoszisztéma növekvő igényeit.

Búcsú Tiller-től

A Helm 2 fejlesztése során Tiller-t bemutattuk, mint a Google Deployment Managerével való integráció részét. Tiller fontos szerepet játszott azok számára, akik közös klaszter keretein belül dolgoztak: lehetővé tette a különböző szakemberek számára, hogy ugyanazzal a kiadási készlettel lépjenek kapcsolatba.

Mivel a szerepkör alapú hozzáférés-ellenőrzés (RBAC) alapértelmezés szerint engedélyezett volt a Kubernetes 1.6-ban, a Tiller megvalósítása a gyártási környezetben bonyolultabbá vált. A lehetséges biztonsági politikák nagy száma miatt az volt a megközelítésünk, hogy alapértelmezés szerint engedélyező konfigurációt kínáljunk. Ez lehetővé tette a kezdők számára, hogy kísérletezzenek a Helmmel és a Kubernetesszel anélkül, hogy először belemerülnének a biztonsági beállításokba. Sajnos ez az engedélyező konfiguráció túl széles körű jogosultságokkal ruházhatta fel a felhasználót, amelyekre nem volt szüksége. A DevOps- és SRE-mérnököknek további üzemeltetési lépéseket kellett tanulmányozniuk a Tiller többfelhasználós (multi-tenant) klaszterbe történő telepítésekor.

Miután megtudtuk, hogyan használják a közösség tagjai a Helmet különböző szituációkban, rájöttünk, hogy a Tiller kiadáskezelő rendszerének nem kell támaszkodnia belső klaszter komponensre az állapotok fenntartásához vagy a kiadásinformációk központi központjaként való működéshez. Ehelyett egyszerűen kapcsolatba léphettünk a Kubernetes API-szerverével, generálhattunk chart-ot kliensoldalon, és tárolhattuk a telepítési adatokat a Kubernetesben.

A Tiller fő funkcióját Tiller nélkül is meg lehetett valósítani, ezért az egyik első döntésünk a Helm 3-mal kapcsolatban a Tiller teljes elhagyása volt.

A Tiller távozásával a Helm biztonsági modellje radikálisan leegyszerűsödött. A Helm 3 mostantól támogatja a jelenlegi Kubernetes összes modern biztonsági, azonosítási és engedélyezési módját. A Helm engedélyeit a következő segítségével határozzák meg: a kubeconfig fájl. A klaszter adminisztrátorai bármilyen részletességgel korlátozhatják a felhasználók jogait. A kiadások továbbra is a klaszteren belül maradnak, a Helm egyéb funkciói pedig megmaradnak.

Chart-repozitóriumok

Magas szinten a chart-repozitórium az a hely, ahol a chartokat tárolni és megosztani lehet. A Helm kliens a chartokat becsomagolja és a repozitóriumba küldi. Egyszerűbben fogalmazva, a chart-repozitórium egy primitív HTTP-szerver, tartalmaz egy index.yaml fájlt és néhány becsomagolt chartot.

Bár néhány előnye van annak, hogy a chart-repozitórium API-ja a legfőbb tárolási igényeknek eleget tesz, van néhány hátránya is:

A chart repository is poorly compatible with most security implementations needed in a production environment. Having a standard API for authentication and authorization is crucial in production scenarios.
Helm tools for tracking a chart's provenance, used for signing, verifying integrity, and sourcing a chart, are optional parts of the chart publishing process.
In multi-user scenarios, the same chart can be uploaded by different users, doubling the storage space required for the same content. Smarter repositories were developed to solve this problem, but they are not part of the formal specification.
Using a single index file for searching, storing metadata, and retrieving charts has complicated the development of secure multi-user implementations.

Projekt Docker Distribution (also known as Docker Registry v2) is the successor to Docker Registry and essentially serves as a set of tools for packaging, distributing, storing, and delivering Docker images. Many major cloud services offer products based on Distribution. With such increased attention, the Distribution project has benefited from years of improvements, best security practices, and real-world testing, making it one of the most successful unsung heroes of the Open Source world.

But did you know that the Distribution project was designed to distribute any form of content, not just container images?

Thanks to the efforts of Open Container Initiative (or OCI), Helm charts can be hosted on any instance of Distribution. While this process is still experimental, work on supporting logins and other features needed for full Helm 3 functionality is not yet complete, but we are very excited about the opportunity to learn from the discoveries made by the OCI and Distribution teams over the years. Thanks to their mentorship and guidance, we are learning what it means to operate a highly available service at scale.

A more detailed description of some upcoming changes to Helm chart repositories is available a linken.

Kiadáskezelés

In Helm 3, the application's state is tracked within the cluster by a pair of objects:

release object — represents an instance of the application;
a kiadási verzió titka – a kívánt állapotot jelenti egy alkalmazás adott időpontban (például egy új verzió kiadása).

Hívás helm install létrehozza a kiadási objektumot és a kiadási verzió titkát. A hívás helm upgrade megköveteli a kiadási objektum meglétét (amelyet módosíthat) és új kiadási verzió titkot hoz létre, amely új értékeket és előkészített manifesztet tartalmaz.

A kiadási objektum tartalmazza a kiadásról szóló információkat, ahol a kiadás egy konkrét, néven elnevezett chart és értékek telepítése. Ez az objektum a kiadásról szóló legfelső szintű metainformációkat írja le. A kiadási objektum az alkalmazás életciklusa alatt megmarad, és a kiadási verzió titkok és a Helm-chart által közvetlenül létrehozott összes objektum tulajdonosaként működik.

A kiadási verzió titok összekapcsolja a kiadást a revíziók sorozatával (telepítés, frissítések, visszagörgetés, törlés).

A Helm 2-ben a revíziók kizárólagosan sorosak voltak. A hívás helm install létrehozta a v1-et, a következő frissítés (upgrade) – a v2-t, és így tovább. A kiadás és a kiadási verzió titok egyetlen objektumként volt összevonva, amely ismert volt mint revízió. A revíziók ugyanabban a névtérben voltak tárolva, mint a Tiller, ami azt jelentette, hogy minden kiadás globális volt a névtér szempontjából; ennek eredményeként csak egy példány használható volt a névvel.

A Helm 3-ban minden kiadás egy vagy több kiadási verzió titkokhoz kapcsolódik. A kiadási objektum mindig a jelenlegi kiadást írja le, amely a Kubernetesben van telepítve. Minden kiadási verzió titok csak a kiadás egy verzióját írja le. A frissítés (upgrade) például új kiadási verzió titkot hoz létre, majd módosítja a kiadási objektumot, hogy ez az új verzióra mutasson. Visszagörgetés (rollback) esetén a korábbi kiadási verzió titkok használhatók a kiadás visszaállítására a korábbi állapotra.

A Tiller elhagyása után a Helm 3 az adatokat a kiadással azonos névtérben tárolja. Ez a változtatás lehetővé teszi, hogy egy azonos nevű chartot telepítsünk egy másik névtérbe, és az adatok frissítések/újraindítások során az etcd-ben megmaradnak. Például a WordPress telepíthető a „foo” névtérbe, majd a „bar” névtérbe, és mindkét kiadás „wordpress” néven hívható.

A chartok függőségeinek módosítása

A chartok csomagolása (a helm package) Helm 2-vel való használatra, Helm 3-mal is telepíthető, azonban a chartok fejlesztési folyamata teljesen átalakul, ezért néhány módosítást kell eszközölni a chartok Helm 3-mal való fejlesztésének folytatásához. Különösen a chartok függőségkezelési rendszere megváltozott.

A chart függőségkezelési rendszere átállt requirements.yaml és requirements.lock Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Chart.yaml és Chart.lock. Ez azt jelenti, hogy azok a chartok, amelyek használták a parancsot helm dependency, némi beállítást igényelnek a Helm 3-ban való működéshez.

Nézzük meg a példát. Adjunk hozzá egy függőséget egy chart-hoz Helm 2-ben, és nézzük meg, mi változik, amikor Helm 3-ra váltunk.

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

Helm 3-ban ugyanaz a függőség a következőképpen fog megjelenni: Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

A chartok továbbra is letöltődnek és a charts/mappába kerülnek, így a (subcharts)mappa alatt elhelyezkedő subchartok charts/, továbbra is változtatás nélkül működnek.

Bemutatjuk a Library Chartokat

A Helm 3 támogat egy új chart típusát, amelyet könyvtári chartoknak (library charts) neveznek. Ez a chart más chartok által felhasználható, de önállóan nem hoz létre kiadási artefaktumokat. A könyvtári chartok sablonjaikban csak elemeket deklarálhatnak. Más tartalmak egyszerűen figyelmen kívül maradnak. Ez lehetővé teszi a felhasználók számára, hogy kóddarabokat újrahasználjanak és megosszák, amelyek sok chartban felhasználhatók, ezzel elkerülve a duplikálást és betartva a defineLibrary chartok a DRY.

szakaszban vannak deklarálva. Telepítésük és kezelésük nem különbözik a többi charttól. függőségeket a fájlban Chart.yamldependencies: - name: mylib version: 1.x.x repository: quay.io

Már alig várjuk azokat a felhasználási lehetőségeket, amelyeket ez az komponens nyújt a chart fejlesztők számára, valamint a legjobb gyakorlatokat, amelyek a könyvtári chartok révén merülhetnek fel.

A Helm 3.0.0-alpha.1 az a alap, amelyre építve elkezdjük a Helm új verziójának létrehozását. A cikkemben néhány érdekes lehetőséget írtam le, amelyből sok még korai fejlesztési fázisban van, és ez rendben van; az alfa kiadás célja, hogy tesztelje az elképzeléseket, visszajelzéseket gyűjtsön a korai felhasználóktól, és megerősítse a feltevéseinket.

Mi következik?

Amint az alfa verzió megjelenik

(ne feledje, hogy ez már megtörtént már megtörtént — a fordító megjegyzése), elkezdenénk a közösségi Helm 3 javítások fogadását. Meg kell valósítanunk egy megbízható alapot, amely lehetővé teszi új funkciók fejlesztését és elfogadását, miközben a felhasználók is érezhetik, hogy részt vesznek a folyamatban, hibajegyeket nyitva és javításokat javasolva.

A cikkben megpróbáltam bemutatni néhány komoly fejlesztést, amelyek a Helm 3-ban megjelennek, azonban ezt a listát semmiképpen sem nevezhetjük kimerítőnek. A Helm 3 teljes körű tervei között szerepelnek olyan újítások, mint a fejlettebb frissítési stratégiák, mélyebb integráció az OCI tárolókkal és JSON-sémák használata a chart értékek ellenőrzésére. Tervezzük a kód alapjának tisztítását és azokat a részeket is frissíteni, amelyeket az utolsó három évben elhanyagoltunk.

Ha úgy érzi, hogy valamit kihagytunk, szívesen hallanánk a véleményét!

Csatlakozzon a diskurzushoz a mi Slack-csatornáinkon:

#helm-users kérdések és egyszerű beszélgetések a közösséggel;
#helm-dev pull requestek, kódok és hibák megvitatására.

A nyilvános fejlesztői hívásainkon is beszélgethet, minden csütörtökön 19:30 MSK időpontban. A találkozókon a kulcsfejlesztők és a közösség által végzett feladatokról, valamint a heti beszélgetési témákról folyik a diskurzus. Bárki csatlakozhat és részt vehet a találkozón. A hivatkozás a Slack-csatornán található. #helm-dev.