A Kubernetes legnépszerűbb csomagkezelőjéről szóló történetet egy emoji segítségével lehetne illusztrálni:
- doboz – ez a Helm (ez a legmegfelelőbb a legutóbbi Emoji kiadásban);
- zár – biztonság;
- emberke – a probléma megoldása.
Valójában azonban minden kicsit bonyolultabb lesz, és a beszámoló tele van technikai részletekkel arról, hogyan tehetjük biztonságossá a Helmet.
- Röviden, mi az a Helm, ha nem tudta vagy elfelejtette. Milyen problémákat old meg, és hol helyezkedik el az ökoszisztémában.
- Nézzük meg a Helm architektúráját. Egyetlen beszélgetés sem lehet biztonságról és arról, hogyan tehetjük a szerszámot vagy megoldást biztonságosabbá, anélkül, hogy megértenénk az összetevő architektúráját.
- Beszéljünk a Helm összetevőiről.
- A legégetőbb kérdés – a jövő – az új Helm 3 verzió.
Mindez a cikk a Helm 2-ről szól. Ez a verzió jelenleg a termelésben van, és valószínűleg ezt használja, és éppen ebben vannak biztonsági fenyegetések.
A szóról: Alexander Khaeyrov () 10 éve foglalkozik fejlesztéssel, segít a tartalom javításában és csatlakozott a bizottsághoz . Jelenleg a Chainstack-nél dolgozik fejlesztési vezetői pozícióban – ez egy hibrid az ügyvezető és a kiadott végtermékért felelős személy között. Tehát ott van a tűzvonalban, ahol minden történik a termék létrehozásától kezdve a működtetéséig.
A Chainstack egy kis, aktívan növekvő startup, amelynek célja, hogy lehetőséget biztosítson a klienseknek, hogy elfelejtsék az infrastruktúrát és a decentralizált alkalmazások kezelésének nehézségeit, a fejlesztő csapat Szingapúrban található. Ne kérje a Chainstack-től, hogy adjon el vagy vásároljon kriptovalutát, de ajánlja fel, hogy beszélgessen az enterprise blockchain kereteiről, és szívesen válaszolnak Önnek.
Helm
Ez egy csomagkezelő (chart) Kubernetes számára. A legérthetőbb és leguniverzálisabb módja az alkalmazások Kubernetes klaszterbe való bejuttatásának.
Ez természetesen strukturáltabb és ipari megközelítést jelent, mint saját YAML-manifesztumok létrehozása és kicsi eszközök írása.
A Helm a legjobb, ami jelenleg elérhető és népszerű.
Miért Helm? Elsősorban azért, mert támogatja a CNCF. A Cloud Native egy nagy szervezet, amely a Kubernetes, etcd, Fluentd és más projektek szülőcége.
Egy másik fontos tény, hogy a Helm egy nagyon népszerű projekt. Amikor 2019 januárjában először elgondolkodtam azon, hogy hogyan lehet a Helmet biztonsossá tenni, a projektnek ezer csillagja volt a GitHub-on. Májusra ez már 12 ezerre nőtt.
Sokan érdeklődnek a Helm iránt, ezért még ha eddig nem is használta, a biztonságával kapcsolatos ismeretek hasznosak lehetnek. A biztonság fontos.
A Helm fő csapatát a Microsoft Azure támogatja, ezáltal a projekt meglehetősen stabil, ellentétben sok más projekttel. A Helm 3 Alpha 2 megjelenése július közepén arra utal, hogy éppen elég ember dolgozik a projekten, és szeretnék tovább fejleszteni és javítani a Helmet.
A Helm több alapvető problémát megold az alkalmazások Kubernetes-ben való kezelésével kapcsolatban.
- Alkalmazáscsomagolás. Még egy „Hello, World” típusú alkalmazás WordPress-en is több szolgáltatást képvisel, és ezeket szeretnénk egy csomagban tartani.
- A komplexitás kezelése, amely a menedzsmentből ered.
- Az életciklus, amely nem ér véget az alkalmazás telepítése vagy bevezetése után. Az alkalmazás tovább él, frissíteni kell, és ebben a Helm segít, és igyekszik a megfelelő intézkedéseket és politikákat bevezetni.
Csomagolás érthető módon van felépítve: metaadatok vannak a Linux, Windows vagy MacOS szokásos csomagkezelőjével való működés teljes megfelelésével. Tehát repository, különböző csomagoktól való dépendenciák, metainformációk az alkalmazásokról, beállítások, konfigurációs sajátosságok, információindexelés, stb. Mindezt a Helm lehetővé teszi, hogy megkapjuk és használjuk az alkalmazások számára.
A komplexitás kezelése. Ha sok az egyforma alkalmazás, akkor paraméterezés szükséges. Ebből következnek a sablonok, de hogy ne kelljen saját sablonkészítési módszert kitalálni, használhatjuk a Helm által előre biztosítottakat.
Az alkalmazás életciklusának kezelése — véleményem szerint ez a legérdekesebb és megoldatlan kérdés. Ez az, amiért annak idején a Helmhez fordultam. Figyelemmel kellett kísérnünk az alkalmazás életciklusát, át akartuk helyezni a CI/CD-t és az alkalmazás ciklusokat ebbe a paradigmába.
A Helm lehetővé teszi:
- kezelni a telepítéseket, bevezeti a konfiguráció és a revízió fogalmát;
- sikeresen végrehajtani a rollbacket;
- használni a hookokat különböző eseményekhez;
- további alkalmazásellenőrzéseket hozzáadni, és reagálni azok eredményeire.
Ezen kívül A Helmnél vannak „akkumulátorok” — hatalmas mennyiségű finom dolog, amit pluginekként beépíthetünk, megkönnyítve ezzel az életünket. A plugineket saját kezűleg is írhatjuk, elég izoláltak, és nem igényelnek komplex architektúrát. Ha valamit meg szeretnél valósítani, javaslom, hogy készítsd el plugin formájában, aztán esetleg integrálhatod az upstreambe.
A Helm három fő koncepcióra épül:
- Chart Repo — a manifesztusod leírása és paraméterezési mátrixa.
- Konfiguráció —ezek a kiértékelt értékek (szöveg, számértékek stb.).
- Kiadás két felső komponenst fog össze, és együtt Release-zé alakulnak. A kiadások verziózhatóak, így megszervezhetjük az életciklust: kicsi a telepítéskor, és nagyobb a frissítések, visszaminősítések vagy visszagörgetések idején.
A Helm architektúrája
A diagram szemlélteti a Helm magas szintű architektúráját.
Ne feledd, hogy a Helm a Kuberneteshez kapcsolódik. Így elengedhetetlen a Kubernetes klaszter (téglalap). A kube-apiserver komponens a mesterre kerül. Helm nélkül van Kubeconfigunk. A Helm hoz egy kis bináris alkalmazást, ha így lehet nevezni, Helm CLI néven, amely telepíthető számítógépre, laptopra, mainframe-re – bárhova.
De ez nem elég. A Helm rendelkezik egy szerveroldali komponenssel, a Tillerrel. Ez képviseli a Helm érdekeit a klaszterben, ez ugyanolyan alkalmazás a Kubernetes klaszterben, mint bármely másik.
A következő komponens a Chart Repo - a chartek tárolója. Létezik hivatalos tároló, és lehet privát tároló is, vállalatok vagy projektek számára.
Interakció
Nézzük meg, hogy a komponensek hogyan működnek együtt, amikor alkalmazást szeretnénk telepíteni a Helm segítségével.
- Mondjuk,
Helm install, és megkeressük a tárolót (Chart Repo), majd megkapjuk a Helm chartot.
- A Helm-eszköz (Helm CLI) interakcióba lép a Kubeconfiggal, hogy kiderítse, melyik klaszterhez kell fordulnia.
- Miután megkapta ezt az információt, az eszköz a Tillerhez fordul, amely a klaszterünkben, mint alkalmazás található.
- A Tiller a Kube-apiserverhez fordul, hogy végrehajtson műveleteket a Kubernetesben, létrehozzon valamilyen objektumokat (szolgáltatások, podok, replikák, titkok stb.).
Ezután bonyolítjuk a sémát, hogy lássuk a támadási vektorokat, amelyekkel az egész Helm architektúra szembekerülhet. Aztán megpróbáljuk megvédeni.
Támadási vektor
Az első potenciálisan gyenge pont — a privilegizált API—a felhasználó. A rendszer keretein belül egy hacker, aki adminisztrátor hozzáféréssel bír a Helm CLI-hez.
Nem privilégizált API-felhasználó szintén veszélyt jelenthet, ha a közelben tartózkodik. Ennek a felhasználónak más kontextusa lehet, például rögzíthetik egy namespace-ben a klaszterben a Kubeconfig beállítások alapján.
A legérdekesebb támadási irány lehet egy folyamat, ami a klaszteren belül van valahol a Tiller mellett, és kommunikálni tud vele. Ez lehet egy webszerver vagy mikroszolgáltatás, ami látja a klaszter hálózati környezetét.
Exotikus, de egyre népszerűbb támadási lehetőség a Chart Repo-hoz kapcsolódik. Egy rossz szándékú szerző által létrehozott chart biztonságtalan erőforrást tartalmazhat, amit végrehajtasz, mivel hiszel neki. Vagy helyettesítheti a chartot, amelyet az hivatalos tárolóból töltesz le, és például erőforrást hozhat létre politikák formájában, ezzel eszközölve a hozzáférésének fokozását.
Próbáljuk megvédeni magunkat minden négy irányból, és kideríteni, hol vannak a problémák a Helm architektúrájában, és hol lehet, hogy nincsenek.
Tágítsuk a rendszert, adjunk hozzá több elemet, de tartsuk meg az alapvető tartalmakat.
A Helm CLI kommunikál a Chart Repo-val, interakcióba lép a Kubeconfig-gal, a munka a klaszterbe kerül a Tiller komponensen keresztül.
A Tiller két objektummal van képviselve:
- A Tiller-deploy svc, amely kiad egy szolgáltatást;
- A Tiller-deploy pod (a diagramon egyedi példányban, egy replikában), amelyen az összes terhelés fut, és amely hozzáfér a klaszterhez.
Különböző protokollokat és sémákat használnak az interakcióhoz. Biztonsági szempontból a legérdekesebb számunkra:
- A mechanizmus, amellyel a Helm CLI a chart repo-hoz kapcsolódik: milyen protokoll van, van-e hitelesítés, és mit tehetünk ezzel kapcsolatban.
- Az a protokoll, amelyen a Helm CLI a kubectl segítségével kommunikál a Tiller-rel. Ez egy RPC-szerver, amely a klaszter belsejében van telepítve.
- A Tiller elérhető a klaszterben található mikroszolgáltatások számára, és együttműködik a Kube-apiserver-rel.
Beszéljünk ezekről az irányokról egyesével.
RBAC
Haszontalan szóba hozni bármilyen biztonságot a Helm vagy más szolgáltatás kapcsán a klaszterben, ha az RBAC nincs engedélyezve.
Úgy tűnik, nem a legfrissebb ajánlás, de biztos vagyok benne, hogy sokan még mindig nem aktiválták az RBAC-t még a termelési környezetben sem, mert ez sok macerával jár, és sok mindent be kell állítani. Ennek ellenére buzdítom mindenkit, hogy tegye meg.
— ügyvéd oldal az RBAC-hoz. Itt hatalmas mennyiségű érdekes anyagot gyűjtöttek össze, amelyek segítenek az RBAC beállításában, megmutatják, miért jó, és hogyan lehet vele általában élni a termelési környezetben.
Megpróbálom elmagyarázni, hogyan működik a Tiller és az RBAC. A Tiller a klaszterben működik egy szolgáltatásfiók alatt. Általában, ha az RBAC nincs beállítva, akkor ez szuperfelhasználó lesz. Az alap konfigurációban a Tiller adminisztrátor. Éppen ezért mondják gyakran, hogy a Tiller egy SSH-alagút a klaszteredhez. Valójában ez így van, ezért egy külön, specializált szolgáltatásfiókot lehet használni a fenti ábrán bemutatott Alapértelmezett Szolgáltatásfiók helyett.
Amikor inicializálod a Helm-et, tehát először telepíted a szerverre, megadhatsz egy szolgáltatásfiókot a következőkkel: --service-account. Ez lehetővé teszi, hogy a minimálisan szükséges jogosultságokkal rendelkező felhasználót használd. Igaz, hogy létre kell hozni egy ilyen „girlandot”: Szerep és Szerepkötés.
Sajnos a Helm ezt nem fogja megtenni helyetted. Neked vagy a Kubernetes klasztered adminisztrátorának előre fel kell készíteni egy Szerep és Szerepkötés készletét a szolgáltatásfiók számára, hogy átadhasd a Helm-nek.
Felmerül a kérdés — mi a különbség a Szerep és a Klaszter Szerep között? A különbség az, hogy a Klaszter Szerep minden namespace-re érvényes, míg a szokásos Szerep és Szerepkötés csak egy adott namespace-ra vonatkozik. A politikák beállíthatók az egész klaszterre és minden namespace-re, valamint személyre szabottan minden egyes namespace-ra.
Érdemes megemlíteni, hogy az RBAC egy másik nagy problémát is megold. Sokan panaszkodnak, hogy a Helm sajnos nem multitenancy (nem támogatja a többrétegű bérbeadást). Ha több csapat használja a klasztert és a Helm-et, alapvetően lehetetlen a politikák beállítása és a hozzáférés elkülönítése ennek a klaszternak a keretein belül, mivel van egy szolgáltatásfiók, amivel a Helm működik, és ez alól minden erőforrást létrehoz a klaszterben, ami néha nagyon kényelmetlen. Ez igaz — mint maga a bináris fájl, mint folyamat, A Helm Tiller nem rendelkezik multitenancy fogalmával..
Azonban van egy nagyszerű módszer, amely lehetővé teszi, hogy a Tiller-t többször indítsd el a klaszterben. Ezzel nincs semmiféle probléma, a Tillert minden namespace-ben el lehet indítani. Ezzel kihasználhatod az RBAC-ot, a Kubeconfig-ot mint kontextust, és korlátozhatod a hozzáférést egy speciális Helm-re.
Ez így néz ki.
Például van két Kubeconfig a kontextussal, különböző csapatok számára (két namespace): X Team a fejlesztői csapat számára és egy admin cluster. Az admin clusternek széles Tillerje van, amely a Kube-system namespace-ben található, ennek megfelelően fejlett service-account. És külön namespace a fejlesztői csapat számára, ők a saját szolgáltatásaikat tudják telepíteni egy speciális namespace-be.
Ez egy működő megközelítés, a Tiller nem annyira költséges, hogy ez jelentősen befolyásolná a költségvetését. Ez az egyik gyors megoldás.
Ne habozzon külön beállítani a Tillert, és Kubeconfigot biztosítani a csapathoz, egy adott fejlesztőhöz vagy környezethez: Dev, Staging, Production (nem valószínű, hogy minden egy klusztérben lenne, de meg lehet csinálni).
Folytatva a történetünket, váltogassunk az RBAC-ról a ConfigMap-ekre.
ConfigMap-ek
A Helm a ConfigMap-eket használja adatbázisként. Amikor az architektúráról beszéltünk, nem voltam szó adatbázisról, amely a kiadások, konfigurációk, rollbackek stb. információit tárolná. Ehhez használjuk a ConfigMap-eket.
A ConfigMap-ekkel kapcsolatos alapvető probléma ismert – alapvetően nem biztonságosak. Nem lehet érzékeny adatokat tárolni bennük.Ez minden olyan dologra vonatkozik, ami nem kerülhet ki a szolgáltatáson kívül, például jelszavak. A Helm legnemesebb módja jelenleg a ConfigMap-ek használatának átállása titkokra.
Ez nagyon egyszerűen elvégezhető. Átállítja a Tiller beállításait, és megadja, hogy a tároló titkok lesznek. Akkor minden telepítéskor nem ConfigMap-et, hanem titkot fog kapni.
Ellenkezhet azzal, hogy a titkok furcsa koncepció, és nem túl biztonságos. azonban érdemes megérteni, hogy ezt maguk a Kubernetes fejlesztők végzik. 1.10-es verziótól kezdve, tehát már régen, lehetőség van legalább a nyilvános felhőkben a megfelelő tároló csatlakoztatására a titkok tárolására. Jelenleg a csapat azon dolgozik, hogy még jobban elérhetővé tegye a titkokat, külön egyes podok vagy más entitások számára.
A Helm tárolását jobban kell átkonfigurálni titkokra, és azok központilag biztonságosabbá tehetők.
Természetesen maradni fog az adatok tárolásának 1 MB-os korlátja.. A Helm itt az etcd-t használja elosztott tárolóként a ConfigMap-ekhez. Ott úgy ítélik meg, hogy ez egy megfelelő adathalmaz a replikációkhoz és hasonlókhoz. Ezzel kapcsolatban érdekes beszélgetés folyik a Redditen, ajánlom, hogy találj rá erre a szórakoztató olvasmányra a hétvégére, vagy olvasd el a kivonatot. .
Chart Repos
A chartok a legnagyobb mértékben társadalmi szempontból sebezhetők, és forrásai lehetnek a „man in the middle” támadásoknak, különösen, ha alapértelmezett megoldást használnak. Elsősorban azokról a tárolókról van szó, amelyek HTTP-n keresztül elérhetők.
Határozottan érdemes a Helm Repo-t HTTPS-en keresztül elérhetővé tenni - ez a legjobb megoldás, és nem drága.
Kérjük, vegye figyelembe a chartok aláírási mechanizmusa. A technológia roppant egyszerű. Ugyanaz, amit a GitHub-on használsz, a szokásos PGP gépezettel, nyilvános és privát kulcsokkal. Állítsd be, és biztos lehetsz benne, hogy a megfelelő kulcsok birtokában minden aláírásod valóban a te chartod.
Ezen kívül, A Helm-kliens támogatja a TLS-t (nem a szerver oldaláról, hanem kölcsönös TLS). Használhatod a szerver- és kliens kulcsokat a kommunikációhoz. Őszintén szólva, én nem használom ezt a mechanizmust a kölcsönös tanúsítványokkal kapcsolatos vonzódás hiánya miatt. Elvileg, — a Helm Repo kihelyezésének alapvető eszköze a Helm 2-höz — támogatja a basic auth-ot is. Használhatsz basic auth-ot, ha ez kényelmesebb és nyugodtabb.
Még van egy plugin , amely lehetővé teszi a Chart Repos elhelyezését a Google Cloud Storage-ban. Ez nagyon kényelmes, szépen működik, és elég biztonságos, mert minden leírt mechanizmust figyelembe vesz.
Ha engedélyezed a HTTPS-t vagy TLS-t, használsz mTLS-t, és basic auth-ot is bevezetve, hogy még inkább csökkentsd a kockázatokat, egy biztonságos kommunikációs csatornát kapsz a Helm CLI és a Chart Repo között.
gRPC API
A következő lépés nagyon felelősségteljes - megvédeni a Tiller-t, amely a klaszterben található, és egyrészt szerver, másrészt pedig hozzáfér más komponensekhez, és próbálja magát valakiként bemutatni.
Ahogy már mondtam, a Tiller az a szolgáltatás, amely gRPC-t kínál, a Helm-kliens gRPC-n keresztül csatlakozik hozzá. Alapértelmezés szerint természetesen a TLS ki van kapcsolva. Hogy ez miért van, az vitatott kérdés; szerintem azért, hogy megkönnyítse a kezdeti beállítást.
Production és még staging környezethez is ajánlom a TLS bekapcsolását a gRPC-n.
Véleményem szerint, ellentétben az mTLS-sel a chartok esetében, itt ez helyénvaló és nagyon egyszerűen megvalósítható — generálsz egy PQI infrastruktúrát, létrehozol egy tanúsítványt, elindítod a Tiller-t, és átadod a tanúsítványt az inicializálás során. Ezt követően már minden Helm-parancsot végrehajthatsz a generált tanúsítvánnyal és privát kulccsal.
Ezzel megvéded magad a Tiller felé irányuló minden külső kéréstől a klaszteren kívül.
Tehát biztonságossá tettük a kapcsolatot a Tiller-rel, már megvitattuk az RBAC-ot és beállítottuk a Kubernetes apiserver jogait, csökkentettük a domaint, amellyel interakcióba léphet.
Biztonságos Helm
Nézzük meg a végső sémát. Ez ugyanaz az architektúra ugyanazokkal a nyilakkal.
Most már bátran zölddel rajzolhatunk minden kapcsolatot:
- a Chart Repo esetén TLS-t vagy mTLS-t és alapvető hitelesítést használunk;
- mTLS a Tillerhez, amelyet gRPC-szolgáltatásként TLS-sel állítanak be, tanúsítványokat használunk;
- a klaszterben speciális szolgáltatás-fiókot használunk szereppel és RoleBinding-gal.
Láthatóan biztonságosabbá tettük a klasztert, de valaki bölcsen mondta:
„Teljesen biztonságos megoldás csak egy lehet — a kikapcsolt számítógép, amely beton dobozban van és katonák őrzik.”
Különböző módok léteznek az adatok manipulálására és új támadási vektorok felkutatására. De biztos vagyok benne, hogy ezek az ajánlások lehetővé teszik a biztonság alapvető ipari szabványának megvalósítását.
Bónusz
Ez a rész nem kapcsolódik közvetlenül a biztonsághoz, de hasznos lesz. Megmutatom néhány érdekes dolgot, amiről kevesen tudnak. Például, hogyan keresd a chartokat — hivatalosakat és nem hivatalosakat.
A tárolóban jelenleg körülbelül 300 chart és két stream: stable és incubátor. Aki hozzájárul, az jól tudja, mennyire nehéz bekerülni az incubátorból a stable-be, és mennyire könnyű kiesni a stable-ból. Azonban ez nem a legjobb eszköz, hogy chartokat keress Prometheushoz és bármi máshoz, egy egyszerű okból kifolyólag — ez nem egy portál, ahol könnyen kereshetsz csomagokat.
De van egy szolgáltatás , amellyel sokkal kényelmesebben találhatsz chartokat. A legfontosabb, hogy ott sokkal több külső repó áll rendelkezésre, és majdnem 800 chart érhető el. Plusz, csatlakoztathatod a saját repódat, ha valamilyen okból nem szeretnéd elküldeni a chartjaidat a stable-be.
Próbálja ki a hub.helm.sh-t, és fejlesszük közösen. Ez a szolgáltatás a Helm-projekt alatt működik, és Ön hozzájárulhat a felhasználói felületéhez is, ha front-end fejlesztő, és szeretné javítani a megjelenést.
Továbbá szeretném felhívni a figyelmét Open Service Broker API integrációra. Nagyon hangzatosnak és érthetetlennek tűnik, de megoldja azokat a problémákat, amelyekkel mindannyian szembesülünk. Egy egyszerű példán keresztül elmagyarázom.
Van egy Kubernetes klaszterünk, amelyben egy klasszikus alkalmazást szeretnénk futtatni – WordPress-t. Általában a teljes funkcionalitáshoz adatbázisra van szükség. Sok különböző megoldás létezik, például elindíthatunk egy stateful szolgáltatást. Ez nem túl kényelmes, de sokan így tesznek.
Mások, mint például mi a Chainstack-nél, kezelhető adatbázisokat használnak, például MySQL-t vagy PostgreSQL-t, a szerverekhez. Ezért az adatbázisunk valahol a felhőben található.
De felmerül a probléma: össze kell kapcsolnunk a szolgáltatásunkat az adatbázissal, létre kell hoznunk az adatbázis flavor-t, át kell adnunk a hitelesítő adatokat, és valahogyan kezelni kell őket. Mindezt általában a rendszergazda vagy a fejlesztő végzi manuálisan. Nincs is probléma, ha kevés alkalmazás van. Ha azonban sok van, szükség van egy kombinálóra. Ilyen kombináló a Service Broker. Ez lehetővé teszi, hogy különleges plugint használjunk a nyilvános felhő klaszterhez, és rendelhetünk forrásokat a szolgáltatótól Broker-en keresztül, mintha ez egy API lenne. Erre a Kubernetes natív eszközei is használhatók.
Ez nagyon egyszerű. Kérhet például Managed MySQL-t az Azure-ban alap szinten (ezt be lehet állítani). Az Azure API-jának használatával az adatbázis létrejön és készen áll a használatra. Ehhez nem kell beavatkoznia, a plugin felel érte. Például az OSBA (Azure plugin) visszaadja a hitelesítő adatokat a szolgáltatásnak, és átadja ezt a Helm-nek. Így használhatja a WordPress-t a felhőbeli MySQL-lal, anélkül, hogy foglalkoznia kellene a kezelt adatbázisokkal vagy a stateful szolgáltatásokkal.
Mondhatjuk, hogy a Helm a ragasztó, amely egyrészt lehetővé teszi a szolgáltatások telepítését, másrészt pedig a felhőszolgáltatók erőforrásainak fogyasztását.
Írhat saját plugint, és használhatja ezt az egész történetet on-premise. Akkor egyszerűen lesz saját plug-in az ipari Cloud szolgáltatójához. Javaslom, hogy próbálja ki ezt a megközelítést, különösen, ha nagy a méret és gyorsan szeretné kiépíteni a fejlesztési, tesztelési vagy egész infrastruktúrát egy funkció köré. Ez megkönnyíti az életét az üzemeltetőinknek vagy a DevOps-nak.
Még egy felfedezés, amit már említettem — ez a helm-gcs plugin, amely lehetővé teszi a Google-bucketek (objektumtárolás) használatát Helm-diagramok tárolására.
Csak négy parancsra van szükség az indításához:
- a plug-in telepítése;
- kezdeményezése;
- megadni a gcp-n található bucket elérési útját;
- a diagramok publikálása a szokásos módon.
A szépsége az, hogy a gcp natív módját fogja használni az azonosításhoz. Használhat szolgáltatói fiókot, fejlesztői fiókot — bármi megteszi. Nagyon kényelmes és nem kerül semmibe a fenntartás. Ha Ön, mint én, az opsless filozófiát hirdeti, akkor ez rendkívül kényelmes lesz, különösen a kis csapatok számára.
Alternatívák
A Helm nem az egyetlen megoldás a szolgáltatások kezelésére. Sok kérdés merült fel vele kapcsolatban, lehet, hogy ezért jelent meg olyan gyorsan a harmadik verzió. Természetesen vannak alternatívák.
Ezek lehetnek olyan speciális megoldások, mint például a Ksonnet vagy a Metaparticle. Használhatja a klasszikus infrastruktúra-kezelő eszközeit (Ansible, Terraform, Chef stb.) ugyanazokhoz a célokhoz, amelyeket említettem.
Végül itt egy megoldás , amelynek népszerűsége folyamatosan növekszik.
Az Operator Framework a Helm legfontosabb alternatívája, amelyre érdemes figyelni.
Ez natívabb a CNCF és a Kubernetes számára, de a belépési küszöb sokkal magasabb, többet kell programozni és kevesebbet kell leírni a manifestumokat.
Számos különböző kiegészítő érhető el, mint például a Draft, Scaffold. Ezek nagyon megkönnyítik az életet, például a fejlesztőknek egyszerűsítik a Helm küldő és üzembe helyezési ciklusát a tesztkörnyezet telepítéséhez. Én kiterjesztő lehetőségeknek nevezném őket.
Itt van egy szemléltető grafikon arról, hogy hol találhatóak azok a dolgok.
Az x-tengely a kezében lévő személyes ellenőrzés szintje, az y-tengely pedig a Kubernetes natív szintje. A Helm 2 valahol a középen helyezkedik el. A 3. verzióban nem hatalmas a különbség, de mind az ellenőrzés, mind a natív szint javult. A Ksonnet szintű megoldások még a Helm 2-t is alulmúlják. De érdemes megnézni őket, hogy tudjuk, mi más létezik e világban. Természetesen a konfigurációs menedzser az Ön ellenőrzése alatt marad, de teljesen nem natív a Kubernetes számára.
Az Operator Framework teljesen natív Kubernetes számára készült, lehetővé téve, hogy sokkal elegánsabban és gondosabban kezeljük (de ne feledkezzünk meg a belépési szintről). Inkább speciális alkalmazásokra és menedzsmentjük létrehozására alkalmas, mintsem egy tömeges megoldás óriási mennyiségű alkalmazás Helm általi csomagolására.
A kiterjesztők csak kissé javítják az ellenőrzést, kiegészítik a munkafolyamatokat, vagy lerövidítik a CI/CD csöveket.
A Helm jövője
A jó hír az, hogy megérkezett a Helm 3. Már elérhető a Helm 3.0.0-alpha.2 alfa verziója, meg lehet próbálni. Elég stabil, de a funkcionalitása még korlátozott.
Miért van szükség a Helm 3-ra? Mindenekelőtt ez egy történet a Tiller eltűnéséről, mint komponens. Ez, ahogy már érted, hatalmas előrelépés, mert a biztonsági architektúra szempontjából minden egyszerűsödik.
Amikor a Helm 2-t kifejlesztették, ez a Kubernetes 1.8 idejében, vagy még korábban történt, sok koncepció éretlen volt. Például a CRD koncepcióját most aktívan bevezetjük, és a Helm a CRD-t fogja használni, hogy tárolja a struktúrákat. Lehetővé válik csak a kliens használata, és nem szükséges a szerveroldali rész. Ennek megfelelően a Kubernetes natív parancsait használhatjuk a struktúrákkal és erőforrásokkal való munkához. Ez hatalmas előrelépés.
Megérkezik a natív OCI tárolók támogatása (Open Container Initiative). Ez egy hatalmas kezdeményezés, és a Helm számára elsősorban az, hogy a saját chartjait elhelyezze. Olyan messzire jutottunk, hogy például a Docker Hub sok OCI szabványt támogat. Nem jósolok mérföldköveket, de lehet, hogy a klasszikus Docker-tárolók szolgáltatói lehetőséget fognak adni a saját Helm chartok tárolására.
Számomra ellentmondásos történet – ez a Lua támogatás, mint templating engine a szkriptek írásához. Nem vagyok nagy rajongója a Luának, de ez teljesen opcionális lehetőség lesz. Háromszor ellenőriztem – a Lua használata nem kötelező. Ezért aki szeretné, használhatja a Luát, aki pedig a Go-t szereti – csatlakozzon a mi hatalmas táborunkhoz, és használja a go-tmpl-et ehhez.
Végre megérkezik az, amire nekem már nagyon szükségem volt – a séma megjelenése és az adat típusa validálása. Többé nem lesz probléma az int vagy string típussal, nem szükséges a nullát dupla idézőjelekbe tenni. Megérkezik egy JSON schema, amely lehetővé teszi, hogy ezt egyértelműen leírjuk az értékek számára.
Nagyon átdolgozzák az események vezérelt modelljét. Már konceptuálisan le van írva. Nézze meg a Helm 3 szálat, és láthatja, mennyi esemény és hook lett hozzáadva, ami jelentősen leegyszerűsíti, ugyanakkor nagyobb kontrollt ad a telepítési folyamatok felett és azok reakciói felett.
A Helm 3 egyszerűbb, biztonságosabb és izgalmasabb lesz, nem azért, mert nem szeretjük a Helm 2-t, hanem mert a Kubernetes egyre fejlettebbé válik. Ennek megfelelően a Helm kihasználhatja a Kubernetes fejlesztéseit, és nagyszerű menedzsereket készíthet a Kuberneteshez.
Még egy jó hír, hogy a Alekszandr Hajórov fog beszélni arról, Emlékeztetjük, hogy a fejlesztési, tesztelési és üzemeltetési folyamatok integrációjáról szóló konferencia Moszkvában szeptember 30-án és október 1-jén. Augusztus 20-áig még lehet és mesélni a saját tapasztalatairól a DevOps megközelítés feladatainak.
A konferencia mérföldköveivel és híreivel követheti a és .
Forrás: habr.com
