Ennek nyomán bemutatjuk idősebb testvérét — . Ez egy Open Source projekt, amelyet a Kubernetes klaszterben használt rendszerkomponensek telepítésére használnak, amelyeket egy közös szóval kiegészítőknek nevezhetünk.
Miért is szükség van kiegészítőkre?
Nem titok, hogy a Kubernetes nem egy kész, mindent egyesítő termék, és egy „felnőtt” klaszter létrehozásához különféle kiegészítőkre lesz szükség. Az addon-operator segít telepíteni, konfigurálni és fenntartani ezeket a kiegészítőket naprakészen.
A klaszter további összetevőinek szükségességét tárgyalja a kollégák . Röviden, a Kubernetes helyzete jelenleg olyan, hogy egy egyszerű telepítéshez, hogy „játszadozzunk”, elegendőek a dobozból kivett összetevők, fejlesztők és tesztelés céljára használhatunk Ingress-t, de egy teljes telepítéshez, amelyről elmondható, hogy „a production készen áll”, körülbelül tucatnyi különböző kiegészítőt kell hozzáadni: valamit a monitorozáshoz, valamit a naplózáshoz, ne felejtsük el az ingress-t és a cert-manager-t, ki kell jelölni a csomópontcsoportokat, hálózati szabályokat kell hozzáadni, sysctl beállításokkal és pod autoscaler-rel fűszerezni...
Mi jellemzi a velük való munkát?
A gyakorlat azt mutatja, hogy csupán a telepítéssel nem ér véget a dolog. A klaszterrel való kényelmes munka érdekében a kiegészítőket frissíteni, letiltani (eltávolítani a klaszterből), és néhányat tesztelni kell a production klaszterbe való telepítés előtt.
Nos, talán elég lenne az Ansible itt? Lehetséges. De a teljes kiegészítők általában nem élnek anélkül, hogybeállításokra lenne szükség. Ezek a beállítások eltérhetnek a klaszter típusától (aws, gce, azure, bare-metal, do, ...). Néhány beállítást nem lehet előre megadni — azokat a klaszterből kell beszerezni. A klaszter nem statikus: egyes beállításokhoz figyelni kell a változásokat. És itt már nem elég az Ansible; szükség van egy programra, amely a klaszterben él, azaz Kubernetes Operatorra.
Akik kipróbálták a munkájuk során , elmondják, hogy a kiegészítők telepítésének és frissítésének feladatait, valamint a beállítások nyomon követését a segítségével meg lehet oldani a shell-operator számára. Írhatsz egy scriptet, amely feltételesen kubectl apply és figyelni fog például a ConfigMap-re, ahol a beállításokat tárolják. Hasonlóan ezt valósítja meg az addon-operator.
Hogyan van ez megszervezve az addon-operatorban?
Új megoldás létrehozásakor az alábbi elvekből indultunk ki:
- A kiegészítő telepítőnek támogatnia kell a sablonkezelést és a deklaratív konfigurációt. Nem készítünk varázslatos szkripteket, amelyek kiegészítőket telepítenek. Az Addon-operator a Helm-et használja a kiegészítők telepítésére. A telepítéshez létre kell hozni egy chartot, és ki kell emelni a values értékeket, amelyeket a konfiguráláshoz használnak.
- A beállításokat telepítéskor lehet generálni, ezeket lehet lekérni a klaszterből, vagy frissítéseket, a klaszter erőforrásainak figyelésével lehet kapni. Ezeket az operációkat horgok segítségével lehet megvalósítani.
- A beállításokat a klaszterben tárolni. A klaszterben a beállítások tárolásához ConfigMap/addon-operator jön létre, és az Addon-operator figyelemmel kíséri ennek a ConfigMapnek a változásait. Az Addon-operator egyszerű egyezmények révén hozzáférést biztosít a horgok számára a beállításokhoz.
- A kiegészítő a beállításoktól függ. Ha a beállítások megváltoznak, az Addon-operator új values értékekkel indítja el a Helm-chartot. A Helm-chart, a hozzá tartozó values és a horgok együttesét modulnak neveztük (további részletek alább).
- Staging. Nincsenek varázslatos kiadási szkriptek. A frissítési mechanizmus hasonlít egy normál alkalmazáséhoz — a kiegészítőket és az addon-operator-t egy képként összegyűjtjük, címkézzük és kiadjuk.
- Eredmények ellenőrzése. Az Addon-operator képes metrikákat átadni a Prometheus számára.
Mi a kiegészítő az addon-operator esetében?
Kiegészítőnek tekinthető minden, ami új funkciókat ad a klaszterhez. Például az Ingress telepítése — remek példa egy kiegészítőre. Ez lehet bármilyen operátor vagy vezérlő, saját CRD-vel: prometheus-operator, cert-manager, kube-controller-manager stb. Vagy valami kisebb, de megkönnyíti az üzemeltetést — például secret copier, amely registry titkokat másol új névtérbe, vagy sysctl tuner, amely a sysctl paramétereket állítja be új csomópontokon.
A kiegészítők megvalósításához az Addon-operator több koncepciót biztosít:
- Helm-chart a klaszterbe különböző szoftverek telepítésére használatos — például Prometheus, Grafana, nginx-ingress. Ha a szükséges komponensnek van Helm-chartja, akkor a telepítése az Addon-operator segítségével nagyon egyszerű lesz.
- Values tároló. A Helm-chartok általában sok különféle beállítással rendelkeznek, amelyek idővel változhatnak. Az Addon-operator támogatja ezen beállítások tárolását és képes nyomon követni a változásaikat, hogy új értékekkel újratelepítse a Helm-chartot.
- Hookok — olyan végrehajtható fájlok, amelyeket az Addon-operator események hatására indít el, és hozzáférnek az értéktárolóhoz. A horgok figyelhetik a klaszterben történt változásokat, és frissíthetik az értékeket az értéktárolóban. Azaz a horgok segítségével megvalósítható a felfedezés, hogy indításkor vagy ütemezés alapján értékeket gyűjtsünk a klaszterből, vagy folyamatos felfedezés, amely során a klaszterben végbemenő változások alapján gyűjtjük az értékeket.
- Modul — a Helm-diagram, az értéktároló és a horgok összessége. A modulok engedélyezhetők vagy letilthatók. A modul letiltása a Helm-diagram összes kiadásának eltávolítását jelenti. A modulok dinamikusan tartalmazhatják önmagukat, például, ha az összes szükséges modul engedélyezve van, vagy ha a horgok felfedezése megtalálta a megfelelő paramétereket – ezt a segédprogram enabled-skript segítségével hajtják végre.
- Globális horgok. Ezek a horgok „önállóan”, nem modulokba vannak ágyazva, és hozzáférnek a globális értéktárolóhoz, amelyből az értékek minden horg számára elérhetők a modulokban.
Hogyan működnek együtt ezek a részek? Nézzük meg a dokumentációban található képet:
Két működési forgatókönyv van:
- A globális horgot esemény indítja – például amikor az erőforrás változik a klaszterben. Ez a horg kezeli a változásokat, és új értékeket ír a globális értéktárolóba. Az Addon-operator észleli, hogy a globális tároló megváltozott, és elindítja az összes modult. Minden modul a saját horgainak segítségével meghatározza, hogy be kell-e kapcsolódnia, és frissíti az értéktárolóját. Ha a modul be van kapcsolva, az Addon-operator elindítja a Helm-diagram telepítését. A Helm-diagram számára elérhetők az értékek a modul tárolójából és a globális tárolóból.
- A második forgatókönyv egyszerűbb: a modulhoz kapcsolódó horgot esemény indítja, amely megváltoztatja az értékeket a modul értéktárolójában. Az Addon-operator észleli ezt, és elindítja a Helm-diagramot a frissített értékekkel.
Az kiegészítés egyetlen horgo formájában is megvalósítható, vagy egy Helm-diagram formájában, vagy még akár több függő modulként is — ez a klaszterbe telepített komponens bonyolultságától és a szükséges beállítási rugalmasság szintjétől függ. Például a repozitóriumban () van egy kiegészítés, a sysctl-tuner, amely megvalósítható egyszerű modul horggal és Helm-diagrammal, valamint értéktároló használatával, ami lehetővé teszi a beállítások hozzáadását a ConfigMap szerkesztésével.
Frissítések szállítása
Néhány szó a komponensek frissítési folyamatáról, amelyeket az Addon-operator telepít.
Az Addon-operator indításához a klaszterben szükséges készíteni egy képet a kiegészítőkről hook fájlok és Helm chartok formájában, hozzáadni a bináris fájlt addon-operator és mindent, ami szükséges a hookokhoz: bash, kubectl, jq, python stb. Ezután ezt a képet a klaszterbe lehet telepíteni, mint egy szokásos alkalmazást, és valószínűleg szeretné szervezni valamilyen címkét. Ha csak néhány klaszter van, a hozzáállás hasonló lehet az alkalmazásokhoz: új verzió, új kiadás, végigmenni minden klaszteren és módosítani a Pod-ok image-ét. De ha érzékelhető számú klaszterre történik a telepítés, akkor a legjobban a csatornából való önfrissítés koncepciója illik nekünk.
Nálunk ez így működik:
- A csatorna lényegében egy azonosító, amelyet bármilyen névvel be lehet állítani (például dev/stage/ea/stable).
- A csatorna neve a kép címkéje. Amikor frissítéseket kell kiadni a csatornára, új képet készítenek és a csatorna nevével címkézik.
- Amikor a registry-ben új kép jelenik meg, az Addon-operator újraindul és az új képpel indul.
Ez nem a legjobb gyakorlat, amiről a szó esik. Ilyen megoldást nem javasolt alkalmazni, de ez egy szokásos alkalmazás, amely egy klaszterben fut.Az Addon-operator esetében az alkalmazás több Deployment-ből áll, amelyek a klaszterek között szétszórva találhatók, és az önfrissítés nagyon sokat segít és megkönnyíti az életet.
A csatornák segítenek a tesztelésben is:ha van egy segéd klaszter, azt beállíthatja a csatornára stage és frissítéseket telepíthet rá, mielőtt a csatornák felé történne. ea és stable. Ha van egy hiba a csatornás klaszterrel, át lehet kapcsolni másra, ea míg folyik a probléma vizsgálata. Ha a klaszter kikerült az aktív támogatás alól, a saját «megfagyott» csatornájára vált — például, stablefreeze-2019-03-20 A hookok és Helm chartok frissítésein kívül szükség lehet.
külső komponens frissítésére is . Például, ha észlel egy hibát a feltételezett node-exporter-ben, és még a javításhoz is kitalált egy megoldást. Ezután PR-t nyitott, és várja az új kiadást, hogy végigmenjen minden klaszteren és növelje a kép verzióját. Hogy ne kelljen határozatlan ideig várni, létre lehet hozni saját node-exporter-t és rá lehet váltani, amíg a PR-t elfogadják..
Alapvetően ezt lehet Addon-operator nélkül is megvalósítani, de az Addon-operatorral a node-exporter telepítő modul látható egyetlen adattárban, a saját képünk Dockerfile-ját itt tarthatjuk, így a folyamat minden résztvevője könnyebben megérti, mi történik... Ha több klaszter is van, akkor könnyebb tesztelni a PR-jét és a új verziót telepíteni!
A komponensek frissítési szervezete sikeresen működik nálunk, de bármilyen más megfelelő sémát is megvalósíthatunk – hiszen ebben az esetben az Addon-operator egy egyszerű bináris fájl.
Zárás
Az Addon-operatorban megvalósított elvek lehetővé teszik az átlátható folyamatok létrehozását, tesztelését, telepítését és frissítését a klaszterben, hasonlóan a hagyományos alkalmazásfejlesztési folyamatokhoz.
Az Addon-operator kiegészítői modulformátumban (Helm-chart + hookok) széles körben elérhetővé tehetők. Mi, a Flant cég, tervezzük, hogy nyáron közzétegyük az ilyen kiegészítőként megvalósított fejlesztéseinket. Csatlakozzon a fejlesztéshez a GitHub-on (, ), próbálja meg elkészíteni a saját kiegészítőjét a és alapján, kövesse a híreinket a Habr-on és a mi !
P.S.
Olvasson további információkat a blogunkban:
- «»;
- «».
Forrás: habr.com
