Után bemutatjuk a bátyját - . Ez egy nyílt forráskódú projekt, amely rendszerösszetevők telepítésére szolgál egy Kubernetes-fürtbe, amelyeket bővítményeknek nevezhetünk.
Miért van egyáltalán kiegészítés?
Nem titok, hogy a Kubernetes nem egy kész all-in-one termék, és egy „felnőtt” klaszter felépítéséhez különféle kiegészítésekre lesz szükség. Az Addon-operator segít telepíteni, konfigurálni és naprakészen tartani ezeket a kiegészítőket.
A fürt további összetevőinek szükségességét a cikk tartalmazza Kollégák . Röviden, a Kubernetes helyzete jelenleg olyan, hogy egy egyszerű „play around” telepítésnél meg lehet boldogulni a dobozból kikerült komponensekkel, a fejlesztőknek és a tesztelésnek meg lehet adni az Ingress-t, de egy teljes telepítéshez, ami kb. mondhatja azt, hogy „a termelés készen áll”, hozzá kell adnia egy tucat különböző kiegészítővel: valamit a megfigyeléshez, valamit a naplózáshoz, ne felejtse el a bemenetet és a tanúsítványkezelőt, válasszon csomópontcsoportokat, vegyen fel hálózati házirendeket, szezont sysctl és pod autoscaler beállításokkal...
Mik a velük való munka sajátosságai?
Amint azt a gyakorlat mutatja, az ügy nem korlátozódik egy telepítésre. A fürt kényelmes használatához frissíteni kell a bővítményeket, le kell tiltani (el kell távolítani a fürtből), és néhányat tesztelni kell, mielőtt telepítené őket az éles fürtbe.
Szóval, lehet, hogy az Ansible elég lesz itt? Talán. De Általában a teljes értékű kiegészítők nem élnek beállítások nélkül. Ezek a beállítások a fürtváltozattól függően eltérőek lehetnek (aws, gce, azure, bare-metal, do, ...). Egyes beállításokat nem lehet előre megadni, azokat a fürtből kell beszerezni. És a fürt nem statikus: bizonyos beállításoknál figyelnie kell a változásokat. És itt már hiányzik az Ansible: kell egy olyan program, ami klaszterben él, pl. Kubernetes operátor.
Akik a munkahelyükön kipróbálták , azt mondják majd, hogy a kiegészítők telepítésének és frissítésének, valamint a felügyeleti beállításoknak a feladatai teljesen megoldhatók shell-operátor számára. Írhat egy szkriptet, amely elvégzi a feltételes feltételt kubectl apply és figyelje meg például a ConfigMap-et, ahol a beállítások tárolódnak. Körülbelül ez az addon-operator megvalósítása.
Hogyan szerveződik ez az addon-operatorban?
Egy új megoldás létrehozásakor a következő elvek alapján jártunk el:
- A kiegészítő telepítőjének támogatnia kell sablon és deklaratív konfiguráció. Nem készítünk olyan mágikus szkripteket, amelyek bővítményeket telepítenek. Az Addon-operator a Helmet használja a kiegészítők telepítéséhez. A telepítéshez létre kell hoznia egy diagramot, és ki kell választania a konfigurációhoz használt értékeket.
- A beállítások lehetnek telepítéskor generál, ők tudnak kap a klaszterbőlVagy frissítéseket kapni, figyeli a fürt erőforrásait. Ezeket a műveleteket horgok segítségével lehet végrehajtani.
- A beállítások lehetnek klaszterben tároljuk. A beállítások fürtben való tárolásához létrejön egy ConfigMap/addon-operator, és az Addon-operator figyeli a ConfigMap változásait. Az Addon-operator egyszerű konvenciók használatával hozzáférést biztosít a horgoknak a beállításokhoz.
- A kiegészítés a beállításoktól függ. Ha a beállítások megváltoztak, akkor az Addon-operátor új értékekkel jeleníti meg a Helm diagramot. A Helm diagram, a hozzá tartozó értékek és a horgok kombinációját modulnak neveztük (további részletekért lásd alább).
- Színreállítás. Nincsenek mágikus kiadási szkriptek. A frissítési mechanizmus hasonló egy normál alkalmazáshoz – gyűjtse össze a bővítményeket és a hozzá tartozó operátorokat egy képbe, címkézze meg és tegye közzé.
- Az eredmény ellenőrzése. Az Addon-operátor mérőszámokat biztosíthat a Prometheus számára.
Mi az a padding az addon-operatorban?
Hozzáadásnak tekinthető minden, ami új funkciókat ad a fürthöz. Például az Ingress telepítése nagyszerű példa a kiegészítőkre. Ez lehet bármilyen operátor vagy vezérlő saját CRD-vel: prometheus-operator, cert-manager, kube-controller-manager stb. Vagy valami kicsi, de könnyebben használható - például titkos másoló, amely új névterekbe másolja a rendszerleíró adatbázis titkait, vagy sysctl tuner, amely konfigurálja a sysctl paramétereket az új csomópontokon.
A kiegészítők megvalósításához az Addon-operator számos koncepciót kínál:
- Helm diagram különféle szoftverek telepítésére használják a fürtbe - például Prometheus, Grafana, nginx-ingress. Ha a szükséges komponens rendelkezik Helm diagrammal, akkor az Addon-operator segítségével nagyon egyszerű lesz telepíteni.
- Értéktárolás. A kormánydiagramok általában sok különböző beállítással rendelkeznek, amelyek idővel változhatnak. Az Addon-operator támogatja ezeknek a beállításoknak a tárolását, és figyelemmel kísérheti azok változásait, hogy újratelepítse a Helm diagramot új értékekkel.
- Horgok olyan végrehajtható fájlok, amelyeket az Addon-operátor eseményeken futtat, és amelyek hozzáférnek az értékek tárolásához. A horog képes figyelni a fürt változásait és frissíteni az értékeket az értéktárban. Azok. A hook segítségével felderítést végezhet, hogy indításkor vagy ütemezetten gyűjtsön értékeket a fürtből, vagy folyamatos felderítést végezhet, a klaszter változásai alapján gyűjtve az értékeket a fürtből.
- Modul egy Helm diagram, egy értéktár és horgok kombinációja. A modulok engedélyezhetők vagy letilthatók. Egy modul letiltása az összes Helm diagram kiadás törlését jelenti. A modulok dinamikusan engedélyezhetik magukat, például ha az összes szükséges modul engedélyezve van, vagy ha a Discovery megtalálta a szükséges paramétereket a horgokban - ez egy kiegészítő engedélyezett szkript segítségével történik.
- Globális horgok. Ezek „önmagukban” lévő horgok, nem szerepelnek a modulokban, és hozzáférnek egy globális értéktárhoz, amelynek értékei elérhetők a modulokban lévő összes hook számára.
Hogyan működnek együtt ezek a részek? Nézzük a képet a dokumentációból:
Két munkaforgatókönyv létezik:
- A globális horgot egy esemény váltja ki – például, amikor a fürtben lévő erőforrás megváltozik. Ez a horog feldolgozza a változásokat, és beírja az új értékeket a globális értéktárba. Az Addon-operator észreveszi, hogy a globális tárhely megváltozott, és elindítja az összes modult. Minden modul a horgok segítségével meghatározza, hogy engedélyezni kell-e, és frissíti az értéktárat. Ha a modul engedélyezve van, az Addon-operátor elindítja a Helm diagram telepítését. Ebben az esetben a Helm-diagram hozzáfér a modul- és a globális tárolóból származó értékekhez.
- A második forgatókönyv egyszerűbb: a modul hookját egy esemény indítja el, és megváltoztatja az értékeket a modul értéktárában. Az Addon-operator észreveszi ezt, és elindítja a Helm diagramot frissített értékekkel.
Az összeadás megvalósítható egyetlen horogként, vagy egy Helm diagramként, ill akár több függő modulként is - ez a fürtbe telepített komponens összetettségétől és a konfigurációs rugalmasság kívánt szintjétől függ. Például az adattárban () van egy sysctl-tuner kiegészítő, amely egy egyszerű modulként egy horoggal és egy Helm diagrammal, valamint az értéktár használatával valósítható meg, amely lehetővé teszi a beállítások hozzáadását a ConfigMap szerkesztésével.
Frissítések kézbesítése
Néhány szó az Addon-operator által telepített összetevőfrissítések megszervezéséről.
Az Addon-operator fürtben való futtatásához szüksége van építs egy képet kiegészítésekkel hook és Helm diagram fájlok formájában adjon hozzá egy bináris fájlt addon-operator és minden, ami a horgokhoz kell: bash, kubectl, jq, python stb. Ezután ezt a képet szokásos alkalmazásként ki lehet helyezni a fürtbe, és valószínűleg meg akarja szervezni egyik vagy másik címkézési sémát. Ha kevés a fürt, ugyanaz a megközelítés lehet megfelelő, mint az alkalmazásoknál: új kiadás, új verzió, menjen az összes fürthöz, és javítsa a Pods képét. Jelentős számú klaszterre történő kiterjesztés esetén azonban a csatornáról történő önfrissítés koncepciója megfelelőbb volt számunkra.
Így csináljuk:
- A csatorna lényegében egy azonosító, amely bármire beállítható (például dev/stage/ea/stable).
- A csatorna neve a képcímke. Amikor frissítéseket kell közzétennie egy csatornán, a rendszer egy új képet állít össze, és a csatorna nevével látja el.
- Amikor egy új kép jelenik meg a rendszerleíró adatbázisban, az Addon-operator újraindul, és elindul az új lemezképpel.
Ez nem a legjobb gyakorlat, ahogyan az a cikkben le van írva . Nem ajánlott ezt megtenni, de beszélünk egy szokásos alkalmazás, amely ugyanabban a fürtben él. Az Addon-operator esetében egy alkalmazás egy csomó Telepítés fürtökben szétszórva, és az önfrissítés sokat segít és megkönnyíti az életet.
A csatornák segítenek és tesztelésben: ha van segédfürt, beállíthatja a csatornához stage és a csatornákon való közzététel előtt a frissítéseket görgesse bele ea и stable. Ha klaszterrel a csatornán ea hiba történt, átválthat rá stable, miközben a klaszter problémáját vizsgálják. Ha a fürt kikerül az aktív támogatásból, akkor átvált a "lefagyott" csatornájára – pl. freeze-2019-03-20.
A horgok és Helm diagramok frissítése mellett szükség lehet frissítés és harmadik féltől származó összetevő. Például észrevett egy hibát a feltételes csomópont-exportőrben, és még azt is kitalálta, hogyan javítsa ki. Ezután megnyitotta a PR-t, és arra vár, hogy az új kiadás végigmenjen az összes fürtön, és növelje a kép verzióját. Annak érdekében, hogy ne várjon a végtelenségig, megépítheti a csomópont-exportőrt, és átválthat rá, mielőtt elfogadná a PR-t.
Általánosságban elmondható, hogy ez az Addon-operátor nélkül is megtehető, de az Addon-operatorral a node-exporter telepítésére szolgáló modul egy lerakatban lesz látható, a kép készítéséhez szükséges Dockerfile ott tartható, így minden résztvevő számára könnyebb lesz. a folyamat, hogy megértsük, mi történik... És ha több klaszter van, akkor könnyebbé válik a PR tesztelése és egy új verzió bevezetése!
A komponensfrissítésnek ez a szervezése nálunk sikeresen működik, de minden más megfelelő séma megvalósítható - elvégre ebben az esetben az Addon-operator egy egyszerű bináris fájl.
Következtetés
Az Addon-operatorban megvalósított alapelvek lehetővé teszik a fürtben lévő kiegészítők létrehozásának, tesztelésének, telepítésének és frissítésének átlátható folyamatát, hasonlóan a hagyományos alkalmazások fejlesztési folyamataihoz.
Az Addon-operator bővítményei modul formátumban (Helm chart + horgok) nyilvánosan elérhetővé tehetők. Mi, a Flant cég a nyár folyamán tervezzük, hogy fejlesztéseinket ilyen kiegészítések formájában publikáljuk. Csatlakozzon a fejlesztéshez a GitHubon (, ), próbálja meg elkészíteni a saját kiegészítését az alapján и , várd a híreket a Habréról és a mi !
PS
Olvassa el blogunkon is:
- «";
- «".
Forrás: will.com