A Kubernetes legnépszerűbb csomagkezelőjéről szóló történet lényege egy emoji segítségével ábrázolható:
- a doboz a Helm (ami a legközelebb áll a legújabb Emoji kiadáshoz);
- zár - biztonság;
- a kis ember a megoldás a problémára.
Valójában minden kicsit bonyolultabb lesz, és a történet tele van technikai részletekkel Hogyan tegyük biztonságossá Helmet.
- Röviden, mi az a Helm, ha nem tudná, vagy elfelejtette. Milyen problémákat old meg, és hol található az ökoszisztémában.
- Nézzük a Helm architektúrát. A biztonságról és egy eszköz vagy megoldás biztonságosabbá tételéről szóló beszélgetés sem teljes az összetevő architektúrájának megértése nélkül.
- Beszéljük meg a Helm összetevőit.
- A legégetőbb kérdés a jövő – a Helm 3 új verziója.
Ebben a cikkben minden a Helm 2-re vonatkozik. Ez a verzió jelenleg éles állapotban van, és nagy valószínűséggel az, amelyet jelenleg használ, és ez a verzió tartalmazza a biztonsági kockázatokat.
Az előadóról: Alekszandr Hajorov () 10 éve fejleszt, segít a tartalom fejlesztésében és csatlakozott a bizottsághoz . Jelenleg a Chainstacknél dolgozik fejlesztői vezetőként – ez egy hibrid a fejlesztési menedzser és egy olyan személy között, aki a végső kiadások beszerzéséért felelős. Vagyis a csatatéren található, ahol a termék megalkotásától a működéséig minden történik.
A Chainstack egy kicsi, aktívan növekvő startup, amelynek küldetése, hogy az ügyfelek elfelejtsék a decentralizált alkalmazások üzemeltetésének infrastruktúráját és bonyolultságát; a fejlesztőcsapat Szingapúrban található. Ne kérje a Chainstacket kriptovaluta eladására vagy vásárlására, hanem ajánlja fel, hogy beszéljen a vállalati blokklánc keretrendszerekről, és boldogan válaszolnak.
Sisak
Ez a Kubernetes csomag (diagram) kezelője. A legintuitívabb és leguniverzálisabb módja az alkalmazásoknak a Kubernetes-fürtökhöz való eljuttatásának.
Természetesen sokkal inkább strukturális és ipari megközelítésről beszélünk, mint saját YAML-jegyzékek létrehozásáról és kis segédprogramok írásáról.
A Helm a legjobb, ami jelenleg elérhető és népszerű.
Miért Helm? Elsősorban azért, mert a CNCF támogatja. A Cloud Native egy nagy szervezet, és a Kubernetes, etcd, Fluentd és mások projektek anyavállalata.
Egy másik fontos tény, hogy a Helm nagyon népszerű projekt. Amikor 2019 januárjában elkezdtem beszélni arról, hogyan tehetem biztonságossá a Helmet, a projektnek ezer csillaga volt a GitHubon. Májusig 12 ezren voltak.
Sok embert érdekel a Helm, így ha még nem is használja, akkor is hasznára válik, ha megismeri a biztonságát. A biztonság fontos.
A Helm alapcsapatát a Microsoft Azure támogatja, ezért sok mástól eltérően meglehetősen stabil projekt. A Helm 3 Alpha 2 július közepén megjelent megjelenése azt jelzi, hogy elég sokan dolgoznak a projekten, és van kedvük és energiájuk a Helm fejlesztésére és továbbfejlesztésére.
A Helm a Kubernetes alkalmazáskezelésének számos alapvető problémáját megoldja.
- Alkalmazási csomagolás. Még egy olyan alkalmazás is, mint a „Hello, World” a WordPress-en, már több szolgáltatásból áll, és ezeket együtt szeretné csomagolni.
- Az alkalmazások kezelésével járó bonyolultság kezelése.
- Életciklus, amely nem ér véget az alkalmazás telepítése vagy üzembe helyezése után. Továbbra is él, frissítésre szorul, a Helm segít ebben, és igyekszik megfelelő intézkedéseket és irányelveket hozni ehhez.
Zsákolás áttekinthető módon van megszervezve: a metaadatok teljes összhangban vannak a Linux, Windows vagy MacOS rendszeres csomagkezelő munkájával. Vagyis egy adattár, függőségek a különböző csomagoktól, az alkalmazások metainformációi, beállítások, konfigurációs szolgáltatások, információindexelés stb. A Helm lehetővé teszi mindezek beszerzését és felhasználását alkalmazásokhoz.
Komplexitás menedzsment. Ha sok azonos típusú alkalmazása van, akkor paraméterezésre van szükség. A sablonok innen származnak, de hogy ne kelljen saját módszert találnia a sablonok létrehozására, használhatja a Helm által kínált lehetőségeket.
Alkalmazás életciklus-kezelés - szerintem ez a legérdekesebb és legmegoldatlanabb kérdés. Ezért jöttem vissza a napokban Helmbe. Figyelnünk kellett az alkalmazás életciklusát, és ehhez a paradigmához akartuk áthelyezni a CI/CD-t és az alkalmazásciklusokat.
A Helm lehetővé teszi, hogy:
- telepítések kezelése, bevezeti a konfiguráció és a felülvizsgálat fogalmát;
- sikeresen végrehajtani a visszaállítást;
- horgokat használjon különböző eseményekhez;
- adjon hozzá további alkalmazásellenőrzéseket, és válaszoljon az eredményekre.
Ráadásul A sisakban „elemek” vannak - rengeteg ízletes dolog, amely beépíthető pluginok formájában, leegyszerűsítve az életét. A beépülő modulok önállóan is írhatók, meglehetősen elszigeteltek, és nem igényelnek harmonikus architektúrát. Ha valamit meg akarunk valósítani, azt javaslom, hogy tegyük meg pluginként, majd esetleg vegyük fel az upstreambe.
A Helm három fő koncepción alapul:
- Chart Repo — leírása és paraméterezési tömbje a manifeszthez.
- Config -azaz az alkalmazott értékek (szöveg, számértékek stb.).
- Engedje összegyűjti a két felső komponenst, és együtt válnak Release-be. A kiadások verziózhatók, ezáltal szervezett életciklus érhető el: kicsi a telepítéskor és nagy a frissítés, leminősítés vagy visszaállítás idején.
Helm építészet
Az ábra koncepcionálisan ábrázolja a Helm magas szintű architektúráját.
Hadd emlékeztesselek arra, hogy Helm valami Kuberneteshez kapcsolódik. Ezért nem nélkülözhetjük a Kubernetes-klasztert (téglalapot). A kube-apiserver összetevő a mesteren található. Helm nélkül megvan a Kubeconfig. A Helm egy kis binárist hoz, ha lehet annak nevezni, a Helm CLI segédprogramot, amely számítógépre, laptopra, nagyszámítógépre - bármire - telepíthető.
De ez nem elég. A Helmnek van egy Tiller nevű szerverkomponense. A Helm érdekeit képviseli a klaszteren belül; ez egy alkalmazás a Kubernetes klaszteren belül, mint bármely más.
A Chart Repo következő összetevője a diagramokat tartalmazó adattár. Létezik egy hivatalos adattár, és lehet egy vállalat vagy projekt privát tárolója.
Kölcsönhatás
Nézzük meg, hogyan hatnak egymásra az architektúra összetevői, amikor egy alkalmazást Helm segítségével szeretnénk telepíteni.
- Beszélünk
Helm install, nyissa meg a tárat (Chart Repo), és kap egy Helm diagramot.
- A Helm segédprogram (Helm CLI) együttműködik a Kubeconfig-gal, hogy kitalálja, melyik fürttel kell kapcsolatba lépni.
- Miután megkapta ezt az információt, a segédprogram a klaszterünkben található Tiller-re hivatkozik, mint alkalmazásra.
- Tiller meghívja a Kube-apiservert, hogy műveleteket hajtson végre a Kubernetesben, hozzon létre néhány objektumot (szolgáltatások, pod-ok, replikák, titkok stb.).
Ezután bonyolultabbá tesszük a diagramot, hogy meglássuk azt a támadási vektort, amelynek a teljes Helm architektúra ki van téve. És akkor megpróbáljuk megvédeni őt.
Támadás vektor
Az első lehetséges gyenge pont az privilegizált API-használó. A rendszer részeként ez egy hacker, aki adminisztrátori hozzáférést kapott a Helm CLI-hez.
Privilegizált API felhasználó veszélyt is jelenthet, ha valahol a közelben van. Egy ilyen felhasználónak más kontextusa lesz, például rögzíthető egy fürt névtérben a Kubeconfig beállításaiban.
A legérdekesebb támadási vektor egy olyan folyamat lehet, amely valahol Tiller közelében egy klaszteren belül található, és hozzáférhet hozzá. Ez lehet egy webszerver vagy mikroszolgáltatás, amely látja a fürt hálózati környezetét.
Egy egzotikus, de egyre népszerűbb támadási változat a Chart Repo. Egy gátlástalan szerző által készített diagram nem biztonságos forrásokat tartalmazhat, és ezt a hittel kiegészítheti. Vagy helyettesítheti a hivatalos adattárból letöltött diagramot, és például létrehozhat egy erőforrást házirendek formájában, és kiterjesztheti a hozzáférését.
Próbáljuk meg elhárítani mind a négy oldalról érkező támadásokat, és kitaláljuk, hol vannak problémák a Helm architektúrában, és hol nincsenek.
Nagyítsuk ki a diagramot, adjunk hozzá további elemeket, de az összes alapvető összetevőt megtartjuk.
A Helm CLI kommunikál a Chart Repo-val, interakcióba lép a Kubeconfig-gal, és a munka átkerül a fürtbe a Tiller komponensbe.
A Tillert két objektum képviseli:
- Tiller-deploy svc, amely egy bizonyos szolgáltatást tesz közzé;
- Tiller-deploy pod (a diagramban egyetlen példányban egy replikában), amelyen a teljes betöltés fut, amely hozzáfér a fürthöz.
Az interakcióhoz különböző protokollokat és sémákat használnak. Biztonsági szempontból leginkább a következők érdekelnek bennünket:
- A mechanizmus, amellyel a Helm CLI hozzáfér a chart repóhoz: milyen protokoll, van-e hitelesítés, és mit lehet vele tenni.
- Az a protokoll, amellyel a Helm CLI a kubectl használatával kommunikál a Tillerrel. Ez a fürtbe telepített RPC-kiszolgáló.
- Maga a Tiller elérhető a fürtben található mikroszolgáltatások számára, amelyek kölcsönhatásba lépnek a Kube-apiserverrel.
Beszéljük meg ezeket a területeket sorban.
RBAC
Nincs értelme a Helm vagy a fürtön belüli bármely más szolgáltatás biztonságáról beszélni, hacsak nincs engedélyezve az RBAC.
Úgy tűnik, nem ez a legfrissebb ajánlás, de biztos vagyok benne, hogy sokan még mindig nem engedélyezték az RBAC-t még élesben sem, mert nagy felhajtás és sok mindent konfigurálni kell. Én azonban erre biztatlak.
— az RBAC webhelyjogásza. Hatalmas mennyiségű érdekes anyagot tartalmaz, amelyek segítenek az RBAC beállításában, megmutatják, miért jó, és hogyan lehet alapvetően együtt élni vele a gyártás során.
Megpróbálom elmagyarázni, hogyan működik a Tiller és az RBAC. A Tiller a fürtön belül egy bizonyos szolgáltatási fiók alatt működik. Általában, ha az RBAC nincs konfigurálva, akkor ez lesz a szuperfelhasználó. Az alapkonfigurációban Tiller adminisztrátor lesz. Ezért mondják gyakran, hogy a Tiller egy SSH-alagút a fürthöz. Valójában ez igaz, így a fenti diagramban az alapértelmezett szolgáltatásfiók helyett használhat külön dedikált szolgáltatásfiókot.
Amikor inicializálja a Helmet és első alkalommal telepíti a kiszolgálóra, a szolgáltatásfiókot a segítségével állíthatja be --service-account. Ez lehetővé teszi a minimálisan szükséges jogosultságokkal rendelkező felhasználó használatát. Igaz, létre kell hoznia egy ilyen „füzért”: Role és RoleBinding.
Sajnos Helm ezt nem teszi meg helyetted. Önnek vagy a Kubernetes-fürt rendszergazdájának előzetesen elő kell készítenie a szerepkörök és szerepkörök készletét a szolgáltatásfiókhoz a Helm átadásához.
Felmerül a kérdés – mi a különbség a Role és a ClusterRole között? A különbség az, hogy a ClusterRole minden névtérben működik, ellentétben a normál Roles-okkal és RoleBinding-ekkel, amelyek csak egy speciális névtérben működnek. Beállíthat házirendeket a teljes fürthöz és az összes névtérhez, vagy személyre szabhatja az egyes névtereket külön-külön.
Érdemes megemlíteni, hogy az RBAC egy másik nagy problémát is megold. Sokan panaszkodnak, hogy a Helm sajnos nem többbérletes (nem támogatja a többbérletet). Ha több csapat fogyaszt egy fürtöt és használja a Helmet, akkor alapvetően lehetetlen házirendeket beállítani és hozzáférésüket korlátozni ezen a fürtön belül, mert van egy bizonyos szolgáltatásfiók, amely alatt a Helm fut, és ez alól hozza létre a fürt összes erőforrását. , ami néha nagyon kényelmetlen. Ez igaz – mint maga a bináris fájl, mint a folyamat, Helm Tillernek nincs fogalma a többbérletről.
Van azonban egy nagyszerű módszer, amely lehetővé teszi a Tiller többszöri futtatását egy fürtben. Ezzel nincs is gond, a Tiller minden névtérben elindítható. Így kontextusként használhatja az RBAC-ot, a Kubeconfig-ot, és korlátozhatja a hozzáférést egy speciális Helm-hez.
Így fog kinézni.
Például két Kubeconfig van kontextussal a különböző csapatokhoz (két névtér): X Team a fejlesztőcsapat és az adminisztrátori fürt számára. Az adminisztrációs fürtnek saját széles Tillerje van, amely a Kube-rendszer névterében található, egy megfelelően fejlett szolgáltatási fiókkal. És külön névtér a fejlesztőcsapat számára, szolgáltatásaikat egy speciális névtérbe telepíthetik majd.
Ez egy működő megközelítés, a Tiller nem annyira energiaéhes, hogy nagyban befolyásolja a költségvetését. Ez az egyik gyors megoldás.
Nyugodtan konfiguráld külön a Tillert, és biztosítsd a Kubeconfig kontextust a csapat, egy adott fejlesztő vagy a környezet számára: Dev, Staging, Production (kétséges, hogy minden ugyanazon a fürtön lesz, de ezt meg lehet tenni).
Folytatva történetünket, váltsunk az RBAC-ról, és beszéljünk a ConfigMapsről.
ConfigMaps
A Helm a ConfigMaps programot használja adattárként. Amikor az architektúráról beszéltünk, sehol nem volt adatbázis, amely információkat tárolna a kiadásokról, konfigurációkról, visszaállításokról stb. Erre a ConfigMaps szolgál.
A ConfigMaps fő problémája ismert – elvileg nem biztonságosak; érzékeny adatokat nem lehet tárolni. Mindenről beszélünk, aminek nem szabad túllépnie a szolgáltatáson, például a jelszavakról. A Helm számára jelenleg az a legnatívabb módja, hogy a ConfigMaps használatáról átvált a titkok használatára.
Ez nagyon egyszerűen történik. Írja felül a Tiller beállítást, és adja meg, hogy a tárhely titkos legyen. Ezután minden telepítéshez nem egy ConfigMap-et kap, hanem egy titkot.
Lehet vitatkozni, hogy maguk a titkok furcsa fogalom, és nem túl biztonságosak. Érdemes azonban megérteni, hogy maguk a Kubernetes fejlesztők csinálják ezt. Az 1.10-es verziótól kezdve, i.e. Már jó ideje – legalábbis nyilvános felhőkben – lehetséges a megfelelő tárhely összekapcsolása a titkok tárolásával. A csapat jelenleg azon dolgozik, hogyan lehetne jobban elosztani a titkokhoz, egyedi podokhoz vagy más entitásokhoz való hozzáférést.
Jobb, ha a Storage Helm-et titkokba helyezi át, és ezek pedig központilag védettek.
Természetesen az is marad 1 MB adattárolási korlát. A Helm itt az etcd-t használja elosztott tárhelyként a ConfigMaps számára. És ott úgy gondolták, hogy ez megfelelő adatcsomag replikációhoz stb. Érdekes vita folyik erről a Redditen, javaslom, hogy találd meg ezt a vicces olvasmányt hétvégére, vagy olvasd el a kivonatot .
Chart Repos
A diagramok a társadalmilag leginkább kiszolgáltatottak, és az „Ember a közepén” forrásává válhatnak, különösen, ha részvénymegoldást használ. Először is a HTTP-n keresztül elérhető adattárakról beszélünk.
Feltétlenül ki kell tennie a Helm Repo-t HTTPS-en keresztül – ez a legjobb megoldás, és olcsó.
Ügyeljen rá diagram aláírási mechanizmus. A technológia pokolian egyszerű. Ez ugyanaz, amit a GitHubon használ, egy normál PGP-gépen nyilvános és privát kulcsokkal. Állítsa be, és győződjön meg arról, hogy rendelkezik a szükséges kulcsokkal és mindent aláír, hogy valóban ez az Ön diagramja.
Továbbá, A Helm kliens támogatja a TLS-t (nem szerveroldali HTTP értelemben, hanem kölcsönös TLS). A kommunikációhoz szerver- és ügyfélkulcsokat használhat. Őszintén szólva nem használok ilyen mechanizmust, mert nem szeretem a kölcsönös tanúsítványokat. Alapvetően, - a Helm Repo for Helm 2 beállításának fő eszköze - támogatja az alapvető hitelesítést is. Használhatja az alapvető hitelesítést, ha kényelmesebb és csendesebb.
Van egy plugin is , amely lehetővé teszi a Chart Repos tárolását a Google Cloud Storage szolgáltatásban. Ez meglehetősen kényelmes, nagyszerűen működik és meglehetősen biztonságos, mert az összes leírt mechanizmust újrahasznosítják.
Ha engedélyezi a HTTPS-t vagy a TLS-t, használja az mTLS-t, és engedélyezi az alapvető hitelesítést a kockázatok további csökkentése érdekében, biztonságos kommunikációs csatornát kap a Helm CLI-vel és a Chart Repo-val.
gRPC API
A következő lépés nagyon fontos - a fürtben található Tiller biztonságossá tétele, amely egyrészt egy szerver, másrészt maga is hozzáfér más összetevőkhöz, és megpróbál úgy tenni, mintha valaki lenne.
Ahogy már mondtam, a Tiller egy olyan szolgáltatás, amely felfedi a gRPC-t, a Helm kliens a gRPC-n keresztül érkezik hozzá. Alapértelmezés szerint a TLS természetesen le van tiltva. Hogy ez miért történt, az vitatható kérdés, számomra úgy tűnik, hogy az elején egyszerűsíteni kell a beállítást.
Gyártáshoz és akár színpadra állításhoz javaslom a TLS engedélyezését a gRPC-n.
Véleményem szerint, ellentétben az mTLS-szel a diagramokhoz, ez itt helyénvaló, és nagyon egyszerűen történik - PQI infrastruktúra létrehozása, tanúsítvány létrehozása, Tiller elindítása, a tanúsítvány átvitele az inicializálás során. Ezt követően végrehajthatja az összes Helm parancsot, bemutatva magát a generált tanúsítvánnyal és privát kulccsal.
Így megvédheti magát minden, a fürtön kívülről érkező, Tillerhez intézett kéréssel szemben.
Tehát biztosítottuk a kapcsolati csatornát a Tiller felé, már megbeszéltük az RBAC-t, és módosítottuk a Kubernetes apiserver jogait, csökkentve a tartományt, amellyel interakcióba léphet.
Védett Helm
Nézzük a végső diagramot. Ugyanaz az architektúra ugyanazokkal a nyilakkal.
Most már minden kapcsolat biztonságosan megrajzolható zölddel:
- a Chart Repo esetében TLS-t vagy mTLS-t és alapszintű hitelesítést használunk;
- mTLS for Tiller, és ez gRPC szolgáltatásként van kitéve TLS-sel, tanúsítványokat használunk;
- a fürt speciális szolgáltatásfiókot használ Role és RoleBinding funkcióval.
Jelentősen biztosítottuk a klasztert, de valaki okos azt mondta:
"Csak egy teljesen biztonságos megoldás lehet: egy kikapcsolt számítógép, amely egy betondobozban van elhelyezve, és katonák őrzik."
Az adatok kezelésének és új támadási vektorok megtalálásának különböző módjai vannak. Biztos vagyok azonban abban, hogy ezek az ajánlások elérik az alapvető biztonsági szabványt.
Prémium
Ez a rész nem kapcsolódik közvetlenül a biztonsághoz, de hasznos is lesz. Mutatok néhány érdekességet, amiről kevesen tudnak. Például, hogyan kereshet grafikonokat – hivatalos és nem hivatalos.
Az adattárban Jelenleg körülbelül 300 diagram és két adatfolyam létezik: stabil és inkubátor. Bárki, aki hozzájárul, jól tudja, milyen nehéz az inkubátorból az istállóba jutni, és milyen könnyű az istállóból kirepülni. Ez azonban nem a legjobb eszköz a Prometheus és bármi más grafikonok kereséséhez, egyetlen egyszerű okból - ez nem egy portál, ahol kényelmesen kereshet csomagokat.
De van szolgáltatás , ami sokkal kényelmesebbé teszi a diagramok megtalálását. A legfontosabb, hogy sokkal több külső adattár és közel 800 bűbáj áll rendelkezésre. Ezenkívül csatlakoztathatja az adattárat, ha valamilyen okból nem szeretné elküldeni a diagramjait az istállóba.
Próbáld ki a hub.helm.sh-t, és fejlesztjük együtt. Ez a szolgáltatás a Helm projekt alatt működik, és még hozzá is járulhat a felhasználói felületéhez, ha front-end fejlesztő vagy, és csak a megjelenést szeretné javítani.
Szeretném felhívni a figyelmet arra is Nyissa meg a Service Broker API integrációját. Nehézkesnek és tisztázatlannak hangzik, de megoldja azokat a problémákat, amelyekkel mindenki szembesül. Hadd magyarázzam el egy egyszerű példával.
Van egy Kubernetes-fürt, amelyben egy klasszikus alkalmazást szeretnénk futtatni - a WordPress-t. Általában egy adatbázis szükséges a teljes funkcionalitáshoz. Számos különböző megoldás létezik, például elindíthatja saját állapotnyilvántartó szolgáltatását. Ez nem túl kényelmes, de sokan megteszik.
Mások, mint mi a Chainstacknél, felügyelt adatbázisokat használnak szervereikhez, mint például a MySQL vagy a PostgreSQL. Ezért az adatbázisaink valahol a felhőben találhatók.
De egy probléma adódik: össze kell kapcsolnunk a szolgáltatásunkat egy adatbázissal, létre kell hoznunk egy adatbázist, át kell vinnünk a hitelesítő adatokat, és valahogyan kezelnünk kell. Mindezt általában manuálisan végzi el a rendszergazda vagy a fejlesztő. És nincs probléma, ha kevés az alkalmazás. Ha sok van belőlük, kombájnra van szükség. Van ilyen betakarítógép - ez a Service Broker. Lehetővé teszi egy speciális bővítmény használatát egy nyilvános felhőfürthöz, és erőforrásokat rendelhet meg a szolgáltatótól a Brokeren keresztül, mintha az API lenne. Ehhez natív Kubernetes-eszközöket használhat.
Ez nagyon egyszerű. Lekérdezheti például a felügyelt MySQL-t az Azure-ban egy alapszinttel (ez konfigurálható). Az Azure API használatával az adatbázis létrejön és előkészíti a használatra. Ebbe nem kell beleavatkoznod, ezért a plugin felelős. Például az OSBA (Azure-bővítmény) visszaadja a hitelesítő adatokat a szolgáltatásnak, és átadja azt a Helmnek. Használhatja a WordPress-t a felhőalapú MySQL-lel, egyáltalán nem foglalkozhat felügyelt adatbázisokkal, és nem kell aggódnia a belső állapotteljes szolgáltatások miatt.
Elmondhatjuk, hogy a Helm olyan ragasztóként működik, amely egyrészt lehetővé teszi a szolgáltatások telepítését, másrészt felemészti a felhőszolgáltatók erőforrásait.
Megírhatja saját beépülő modulját, és az egész történetet a helyszínen használhatja. Ezután egyszerűen saját beépülő modulja lesz a vállalati felhőszolgáltató számára. Azt javaslom, hogy próbálja ki ezt a megközelítést, különösen akkor, ha nagy léptékű, és gyorsan szeretné telepíteni a fejlesztőt, az állomásozást vagy a teljes infrastruktúrát egy szolgáltatáshoz. Ez megkönnyíti a műveletek vagy a DevOps életét.
Egy másik lelet, amit már említettem helm-gcs bővítmény, amely lehetővé teszi a Google-buckets (objektumtároló) használatát Helm-diagramok tárolására.
Csak négy parancsra van szüksége a használat megkezdéséhez:
- telepítse a bővítményt;
- kezdeményezni;
- állítsa be a gcp-ben található vödör elérési útját;
- táblázatok közzététele a szokásos módon.
A szépség az, hogy a natív gcp módszert fogják használni az engedélyezéshez. Használhat szolgáltatásfiókot, fejlesztői fiókot, amit csak akar. Nagyon kényelmes és nem kerül semmibe a működtetése. Ha Ön, mint én, az opsless filozófiát hirdeti, akkor ez nagyon kényelmes lesz, különösen kis csapatok számára.
Alternatívák
A Helm nem az egyetlen szolgáltatásmenedzsment megoldás. Sok a kérdés ezzel kapcsolatban, valószínűleg ezért is jelent meg olyan gyorsan a harmadik verzió. Természetesen vannak alternatívák.
Ezek lehetnek speciális megoldások, például Ksonnet vagy Metaparticle. A klasszikus infrastruktúra-kezelő eszközeidet (Ansible, Terraform, Chef stb.) használhatod ugyanazokra a célokra, amelyekről beszéltem.
Végre van megoldás , melynek népszerűsége egyre nő.
Az Operator Framework a Helm legjobb alternatívája, amelyet meg kell fontolni.
Inkább a CNCF-ben és a Kubernetesben honos, de a belépési korlát sokkal magasabb, többet kell programoznia és kevesebbet kell leírnia.
Különféle kiegészítők léteznek, mint például a Draft, Scaffold. Sokkal könnyebbé teszik az életet, például leegyszerűsítik a Helm elküldésének és elindításának ciklusát a fejlesztők számára a tesztkörnyezet telepítéséhez. Én felhatalmazóknak nevezném őket.
Itt van egy vizuális diagram, ahol minden található.
Az x tengelyen az Ön személyes ellenőrzésének szintje van a történések felett, az ordinátán - a Kubernetes honosságának szintje. A Helm 2. verziója valahol középre esik. A 3-as verzióban ez nem óriási, de mind az irányítás, mind a natívság szintje javult. A Ksonnet szintű megoldások még a Helm 2-nél is gyengébbek. Érdemes azonban megnézni, mi van még ezen a világon. Természetesen a konfigurációkezelő az Ön irányítása alatt áll, de ez egyáltalán nem natív a Kubernetesben.
Az Operator Framework abszolút a Kubernetesben honos, és lehetővé teszi, hogy sokkal elegánsabban és alaposabban kezelje (de ne feledje a belépő szintet). Inkább ez egy speciális alkalmazásra és a hozzá tartozó menedzsment létrehozására alkalmas, nem pedig egy tömeges betakarítógép, amely nagyszámú alkalmazást csomagol a Helm segítségével.
A bővítők egyszerűen javítják egy kicsit a vezérlést, kiegészítik a munkafolyamatot, vagy levágják a CI/CD csővezetékeket.
Helm jövője
A jó hír az, hogy jön a Helm 3. A Helm 3.0.0-alpha.2 alfa verziója már megjelent, ki lehet próbálni. Meglehetősen stabil, de a funkcionalitás továbbra is korlátozott.
Miért kell a Helm 3? Először is ez a történet arról szól Tiller eltűnése, komponensként. Ez, ahogy már érted, óriási előrelépés, mert az építészet biztonsága szempontjából minden leegyszerűsödik.
Amikor a Helm 2-t létrehozták, ami a Kubernetes 1.8 vagy még korábban volt, sok koncepció még kiforratlan volt. Például a CRD-koncepciót jelenleg aktívan alkalmazzák, és Helm meg is fogja tenni használja a CRD-tszerkezetek tárolására. Lehetséges lesz csak a kliens használata, a szerverrész karbantartása nem. Ennek megfelelően a natív Kubernetes parancsokat használja a struktúrákkal és erőforrásokkal való munkavégzéshez. Ez óriási előrelépés.
Meg fog jelenni natív OCI adattárak támogatása (Open Container Initiative). Ez egy hatalmas kezdeményezés, és a Helmet elsősorban a grafikonok közzététele érdekli. Odáig ért, hogy például a Docker Hub számos OCI szabványt támogat. Nem tippelek, de talán a klasszikus Docker adattárszolgáltatók lehetőséget fognak adni a Helm-diagramok tárolására.
A számomra vitatott történet az Lua támogatás, mint sablonozó motor szkriptek írásához. Nem vagyok nagy Lua rajongó, de ez egy teljesen opcionális funkció lenne. Ezt háromszor ellenőriztem - a Lua használatára nem lesz szükség. Ezért akik szeretnék használni a Lua-t, akik szeretik a Go-t, csatlakozzanak hatalmas táborunkhoz, és használják ehhez a go-tmpl-t.
Végül az, ami határozottan hiányzott séma megjelenése és adattípus érvényesítése. Nem lesz többé probléma az int-tel vagy a stringgel, nem kell a nullát dupla idézőjelbe tenni. Megjelenik egy JSONS-séma, amely lehetővé teszi ennek kifejezett leírását az értékekhez.
Erősen át lesz dolgozva eseményvezérelt modell. Koncepcionálisan már leírták. Nézze meg a Helm 3 ágat, és látni fogja, hogy hány esemény, hook és egyéb dolog került hozzáadásra, ami nagyban leegyszerűsíti, másrészt pedig növeli a telepítési folyamatok és az azokra adott reakciók irányítását.
A Helm 3 egyszerűbb, biztonságosabb és szórakoztatóbb lesz, nem azért, mert nem szeretjük a Helm 2-t, hanem azért, mert a Kubernetes egyre fejlettebb. Ennek megfelelően a Helm felhasználhatja a Kubernetes fejlesztéseit, és kiváló menedzsereket hozhat létre a Kubernetes számára.
A másik jó hír az Alexander Khayorov elmondja neked, Emlékeztetünk arra, hogy a fejlesztési, tesztelési és üzemeltetési folyamatok integrációjáról szóló konferenciát Moszkvában tartják szeptember 30-án és október 1-jén. Augusztus 20-ig még megteheti és mondja el nekünk a megoldással kapcsolatos tapasztalatait a DevOps megközelítés feladatai.
Kövesse a konferencia ellenőrző pontjait és híreit a címen и .
Forrás: will.com