Messze nem minden szerverplatform, még a legnagyobb és legskálázhatóbbak sem elégítik ki az igényeket. Bár a Kubernetes önállóan jól működik, lehet, hogy hiányzik neki a szükséges komponensek egyensúlyához. Mindig talál egy specifikus esetet, amely figyelmen kívül hagyja a szükségleteidet, vagy amikor a Kubernetes alapértelmezett telepítésével nem működik — például adatbázis-támogatás vagy CDN működés.
Itt jönnek a kiegészítők, elágazások és egyéb finomságok ennek a konténerorchestrátornak a támogatására, amelyet a legszélesebb közösség támogat. Ebben a cikkben a 11 legjobbat mutatjuk be, amit találtunk. Magunk is nagyon is érdekesnek találjuk őket, és szeretnénk gyakorlatiasan — kis csavarokra és anyákra szétszedni és megnézni, hogy mi van belül. Egyesek remekül kiegészítik a Kubernetes klasztert, míg mások segítenek megoldani specifikus feladatokat, amelyek nem valósulnak meg a Kubernetes alapértelmezett szállításában.
Gatekeeper: irányítás politikák felett
Projekt (OPA) lehetőséget biztosít politikák létrehozására a Kubernetes alkalmazásfelhő-artefaktusai felett, kezdve az ingress-től egészen a service mesh-ig. natív lehetőséget biztosít a Kubernetes-hez, hogy automatikusan alkalmazza a politikákat a klaszterben, valamint ellenőrzi a politikát sértő eseményeket vagy erőforrásokat. Mindez a Kubernetes viszonylag új mechanizmusán keresztül történik, a Webhooks hozzáféréskezelőn keresztül, amely a források változásakor lép működésbe. A Gatekeeper segítségével az OPA politikák a Kubernetes klasztered állapotának részévé válnak, anélkül, hogy folyamatos felügyeletre lenne szükség.
Gravity: Áthelyezhető Kubernetes klaszterek
Ha szeretnéd telepíteni az alkalmazást Kubernetes-be, sok alkalmazás rendelkezik Helm chart-tal, amely irányítja és automatizálja ezt a folyamatot. De mi a helyzet, ha szeretnéd a Kubernetes klasztered „ahogy van” telepíteni valahol máshol?
állapotképeket készít a Kubernetes klaszterekről, a konténerképek regiszteréről, valamint az elindított alkalmazásokról, amelyeket „alkalmazáscsomagoknak” neveznek. Az ilyen csomag, amely egy egyszerű fájl .tar, bármely olyan helyen replikálhatja a klasztert, ahol a Kubernetes működni tud.
A Gravity ellenőrzi azt is, hogy a célinfrastruktúra viselkedése megegyezik-e az eredetiéval, és hogy a Kubernetes környezet a céloldalon elérhető-e. A Gravity fizetős változata biztonsági funkciókat is hozzáad, beleértve az RBAC-t és a biztonsági beállítások több klaszter implementáció közötti szinkronizálásának lehetőségét.
A legutóbbi fő verzió, a Gravity 7, képes a Gravity képet egy meglévő Kubernetes klaszterre telepíteni, ahelyett, hogy egy teljesen új klasztert telepítene a képből. A Gravity 7 más képből telepített klaszterekkel is képes működni. Ezenkívül a Gravity támogatja az SELinux-ot, és natívan működik a Teleport SSH átjáróval.
Kaniko: Konténerek építése Kubernetes klaszterben
A konténerek többsége a konténerstackon kívüli rendszereken készül. Néha azonban szükséges konténert építeni a konténerstackon belül, például egy működő konténerben vagy egy Kubernetes klaszterben.
konténereket épít a konténeres környezetben, de nem függ a konténerizáló szolgáltatástól, például a Dockertól. Ehelyett a Kaniko kinyeri a fájlrendszert az alapértelmezett képből, végrehajtja az összes építési parancsot a felhasználói térben a kinyert fájlrendszer fölött, és minden parancs után készít egy pillanatképet a fájlrendszerről.
Megjegyzés: A Kaniko jelenleg (2020 május) nem képes Windows konténereket építeni. jegyzet: fordító) nem képes Windows konténereket építeni.
Kubecost: A Kubernetes indítási költségei
A legtöbb Kubernetes adminisztrációs eszköz a használhatóságra, a megfigyelésre és a podok belső viselkedésének megértésére van kiélezve. De mi a helyzet a Kubernetes indításához kapcsolódó költségek megfigyelésével – forintban és fillérben?
valós időben kezeli a Kubernetes paramétereket, így a fő felhőszolgáltatók által üzemeltetett klaszterekből származó aktuális költséginformációk a panelre kerülnek, havi bontásban minden klaszterre. Az operatív memória, a CPU-idő, a GPU és a tárolórendszer költségei a Kubernetes komponensei (konténer, pod, szolgáltatás stb.) szerint vannak felosztva.
A Kubecost emellett nyomon követi a klasztereken kívüli erőforrások költségeit is, például az Amazon S3 tárolókat, bár ez AWS-re korlátozódik. A költségadatokat elküldhetjük a Prometheusnak, így a klaszter viselkedését programozottan is módosíthatjuk.
A Kubecost ingyenes a használatra, ha elegendő adatod van a 15 napos naplókból. A prémium funkciók havi 199 dollártól kezdődnek 50 csomópont monitorozásához.
KubeDB: Harci adatbázisok futtatása Kubernetesben
Az adatbázisok indítása érdekelt Kubernetesben elég bonyolult. Találsz Kubernetes operátorokat MySQL, PostgreSQL, MongoDB és Redis számára, de mindegyiknek megvannak a hátrányai. A Kubernetes alapfunkciói általában nem oldanak meg közvetlenül számos specifikus adatbázis-problémát.
segít létrehozni a saját Kubernetes operátorait az adatbázisok kezelésére. A biztonsági mentés, másolás, monitorozás, pillanatképek készítése és deklaratív adatbázis-képzés az alkotóelemei. Ne feledd, hogy a funkciók támogatása az adatbázistól függ. Például a klaszter létrehozása működik PostgreSQL esetén, de nem MySQL esetén ( van, ahogyan helyesen megjegyezted , jegyzet: fordító).
Kube-monkey: Chaos Monkey Kuberneteshez
A stressztesztelés legmegbízhatóbb módjának a véletlenszerű leállások számítanak. Ez az elmélet áll a Netflix Chaos Monkey mögött, egy kaotikus mérnöki eszköz, amely véletlenszerűen kikapcsol virtuális gépeket és konténereket a termelési környezetben, hogy ösztönözze a fejlesztőket arra, hogy tartósabb rendszereket alkossanak. — a stressztesztelés ugyanazon alapelvének megvalósítása Kubernetes klaszterekhez. Véletlenszerűen leállítja a te által megadott klaszter moduljait, és beállítható, hogy meghatározott időközönként működjön.
Kubernetes Ingress Controller AWS-hez
A Kubernetes külső terheléselosztót és klaszter hálózati szolgáltatásokat biztosít egy úgynevezett szolgáltatáson keresztül, Az AWS terheléselosztási funkciókat biztosít, de nem köti össze őket automatikusan a Kubernetes hasonló funkcióival. betölti ezt az űrt.
Automatikusan kezeli az AWS erőforrásokat minden ingress objektum számára a klaszterben, létrehozva a terheléselosztókat az új ingress erőforrásokhoz, és eltávolítja a terheléselosztókat az erőforrások törlésekor. A CloudFormation-t használja annak biztosítására, hogy a klaszter állapota érintetlen maradjon. Továbbá támogatja a CloudWatch Alarm beállításokat és automatikusan kezeli a klaszterben használt egyéb elemeket, például az SSL tanúsítványokat és az EC2 Auto Scaling Groups-t.
Kubespray: Kubernetes automatikus telepítése
automatizálja a kész, ipari használatra kész Kubernetes klaszter telepítését, kezdve a 'fém' szerverek telepítésével, egészen a legfontosabb nyilvános felhőkig. Az Ansible-t (Vagrant — kiegészítőként) használja a telepítés elindításához és a választott hálózati bővítménnyel (például Flannel, Calico és mások) rendelkező, nagy rendelkezésre állású klaszter létrehozásához a kiválasztott népszerű Linux disztribúción a 'fém' szerverekre történő telepítéskor.
Skaffold: Iteratív fejlesztés Kuberneteshez
— az egyik Google-eszköz, amelyet a Kubernetes alkalmazások folyamatos integrációjának (CI) szervezésére alkalmaznak. Amint módosítja a forrást, a skaffold automatikusan érzékeli ezt, elindítja a build és a telepítési folyamatokat, és figyelmezteti Önt, ha bármilyen hiba merül fel. A skaffold teljesen a kliens oldalán fut, így némi finomhangolásra lehet szükség a telepítés vagy frissítés során. Használható meglévő CI/CD folyamatokkal, és kölcsönhatásba léphet néhány külső build eszközzel, főként a Google Bazel-jával.
Teresa: Egyszerű PaaS Kubernetesen
ez egy alkalmazástelepítő rendszer, amely az egyszerűsített PaaS-t a Kubernetes fölé helyezi. A csapatokra bontott felhasználók telepíthetik és kezelhetik a saját alkalmazásaikat. Ez egy kicsit megkönnyíti a munkát azoknak, akik bíznak ebben az alkalmazásban, és nem akarnak foglalkozni a Kubernetes-szel és annak összetettségével.
Tilt: Folyamatos konténerfrissítések küldése Kubernetes klaszterbe
, a Windmill Engineering által fejlesztett eszköz, figyeli a különböző Dockerfile fájlok változásait, majd fokozatosan telepíti a megfelelő konténereket a Kubernetes klaszterbe. Gyakorlatilag lehetővé teszi a termelési klaszter valós idejű frissítését a Dockerfile fájlok egyszerű frissítésével. A Tilt a klaszterben végzi a build folyamatot, a forráskód — mindaz, amit módosítani kell. Állapotfelvételt is készíthet a klaszter állapotáról, és rögzítheti a hiba aktiválásának körülményeit közvetlenül a Tiltből, hogy megossza azokat a csapattagokkal a hibakereséshez.
P.S. Mindezeket az eszközöket többször is vizsgáltuk kíváncsi kezeinkkel. Hogy valós gyakorlatokat mutassunk be már (remélem!) offline intenzívek során februárban. 2021. február 8–10. És Február 12-14. Őszintén szólva, mi is vágyunk a meleg és energetikailag feltöltő offline tanulás légkörére. Bármennyire is fejlettek a technológiák, nem pótolják az élő emberi kommunikációt és azt a különleges légkört, amikor az azonos érdeklődésű emberek összegyűlnek.
Forrás: habr.com
