Elosztott Kubernetes PaaS vezérlő sík

(Ankur Singla) (november 15 , 2019)

Szerzők : Ankur Singla , Harshad Nakil

Ez a blog az első olyan blogsorozatban, amely különböző aspektusokkal foglalkozik azzal, mi kellett ahhoz, hogy felépítsük és működtessük a SaaS szolgáltatás:

  1. Elosztott Kubernetes PaaS vezérlősík
  2. (Elosztott alkalmazások globális szolgáltatási hálója)
  3. (Az elosztott infrastruktúra, alkalmazások és adatok platformbiztonsága)
  4. (Az elosztott klaszterek alkalmazása és hálózati biztonsága)
  5. Megfigyelhetőség globálisan elosztott platformon keresztül
  6. Globálisan elosztott platform működése és SRE-je
  7. Golang szolgáltatási keretrendszer az elosztott mikroszolgáltatáshoz s

Ahogy korábbi blogunkban leírtuk, ügyfeleink összetett és sokféle üzleti megoldást építenek – például intelligens gyártás, video-kriminalisztika a közbiztonság érdekében, algoritmikus kereskedelem, telco 5G hálózatok – és ezért mindig bekapcsolt, összekapcsolt és megbízható élményt kell nyújtanunk ezeknek az alkalmazásoknak és végfelhasználóiknak.

Mivel ezek az alkalmazások több fürtben futhatott felhő szolgáltatókon vagy az ügyfelek szélén, platform csapatunknak elosztott vezérlősíkot és PaaS szolgáltatást kellett építenie a többszörös bérlős Kubernetes-fürtök telepítéséhez, biztonságossá tételéhez és üzemeltetéséhez. Ez az elosztott vezérlősík számos működési, méretezési és teljesítményelőnyt nyújtott, amelyeket előadásunkban ( videó link ) – pl hogyan lehet ezernyi éles K8-fürtöt kezelni a GitOps segítségével – és külön blogbejegyzésként is a következő hetekben.

TL; DR (Összefoglaló)

  1. Nem találtuk egy egyszerűen használható megoldás a piacon, amely megoldhatja a felhőszolgáltatókon, magánfelhőkben vagy több élhelyen elosztott több alkalmazásfürt telepítésének, biztonságának és üzemeltetésének problémáját.
  2. Nem találtunk robusztus A Kubernetes disztribúció vagy a PaaS (pl. OpenShift, Cloud Foundry stb.) Átfogó biztonsági és operatív szolgáltatásokat nyújtott az elosztott klaszterekhez – például PKI-alapú identitás, RBAC és felhasználói hozzáférés-kezelés, titkok és kulcskezelés a felhőszolgáltatók között , több fürtből álló szolgáltatási háló, megfigyelhetőség és naplózási naplók, vagy alkalmazás- és hálózatbiztonság.
  3. Az Anthos (Google), az Azure Arc (Microsoft) és a Rancher több fürtöt kezelő állomás és több különböző szolgáltatás csomagolása ; Elemzésünk az volt, hogy ezek nem oldották volna meg az üzemeltetési, méretezési, biztonsági és több bérleti követelményeket, amelyek az alkalmazás és az infrastruktúra szolgáltatásaihoz több klaszteren keresztül vonatkoztak.
  4. Saját elosztott vezérlősíkot kellett építenünk a a kezelt PaaS, amely a Kubernetes tetejére épül. Vanília Kubernetes-sel kezdtük, majd jelentős változásokat hajtottunk végre a DevOps és az SRE csapataink számára szükséges platformszolgáltatások nyújtásában. Ezenkívül egy vezérlősíkot kellett építenünk a nagyszámú elosztott klaszter kezelésére és a többlakásos bérlet biztosítására heterogén infrastruktúrán keresztül (élen, hálózatunkban és több felhőszolgáltatóban).

Kubernetes az App Management számára: Miért & Hogyan

A Kubernetes-t (K8s) választottuk az elosztott alkalmazások kezelésére szolgáló platformunk magjának, mivel gazdag funkcionalitást kínál anélkül, hogy túlságosan előírnánk – rugalmasságot biztosítva az ügyfelek számára fontos dolgok újításában. Ezt használtuk alapként szolgáltatásunk építésének megkezdéséhez, és a K8-ok növekvő népszerűségével könnyebb megtalálni azokat a fejlesztőket és üzemeltetőket is, akik ismerik azt.

Ez azt jelenti, hogy sok termelési szintű Kubernetes-fürt telepítése és kezelése hibrid környezetben (több felhő, hálózati POP és élhelyek) nem túl egyszerű, mivel nincsenek out-out -box megoldások a Kubernetes számára, amelyek képesek:

  1. Harmonizálni a heterogén infrastrukturális erőforrásokat automatizált fürtözéssel, méretezéssel és nulla érintéssel történő kiépítéssel; ez különösen fájdalmas volt a szélén és a hálózati PoP-jainkban.
  2. Nagy teljesítményű és megbízható kapcsolatot biztosítson az eltérő helyeken – különösen a felhő szolgáltatók keresztezésekor és az élhelyekről érkezve
  3. Oldja meg a biztonságot A szállítás közbeni adatok, a nyugalmi állapotban lévő adatok, a titkok, a kulcsok és a hálózat… mindezt egy egységes PKI-identitás támasztja alá, amely a széleken, a hálózaton és a felhőn keresztül működik.
  4. Igazi multi-bérlet biztosítása – bérlői elszigeteltség és biztonsági garanciák – azzal a képességgel, hogy ugyanazon klasztereken futtassák a termelési és fejlesztési munkaterheléseket a belső és az ügyfelek igényeihez
  5. Megfigyelhetőséget és műveleteket biztosítsanak az elosztott klasztereken keresztül, amelyek központi politikába és szándékba kapcsolódnak, komplex építés nélkül naplók és metrikák összegyűjtése

Többféle koncepcióbizonyítás után több felhőszolgáltatóval és nyílt forráskódú platformokkal, például GKE, AKS, EKS és RKE, valamint az OpenShift és a Cloud Foundry – rájöttünk hogy egyikük sem találkozhatott az összes fi-val a fenti követelményeket. Ennek eredményeként úgy döntöttünk, hogy létrehozunk egy saját PaaS-t – kezdve a „vanília” Kubernetes-től, és számos kiegészítést tettünk – az identitás, a hálózatépítés, a biztonság, a bérbeadás, a naplózás, a metrikák stb. Érdekében. Miközben a Kubernetes-t belső igényeink kielégítésére használjuk, néhány kemény döntést kellett meghoznunk, például nem szabad kitenni ezeket a Kubernetes-fürtöket közvetlenül belső felhasználóinknak és / vagy ügyfeleinknek a munkaterhelésük futtatása érdekében (erről később is többet tudhatunk meg, mivel a multi-bérlet kulcsfontosságú cél volt számunkra).

A számos új szolgáltatás mellett, amelyeket hozzá kellett adnunk, szükség volt a munkaterhelések / szolgáltatások futtatására az ügyfelek munkaterhelésével együtt a széleken, a hálózatunkon, valamint a nyilvános / magánfelhőkben. Ez azt jelentette, hogy további képességeket kellett kiépítenünk ahhoz, hogy több fürtöt kezeljünk több környezetben … mindezek globális hálózatunk és elosztott alkalmazásátjáróink segítségével csatlakoztak ahhoz, hogy nulla megbízhatóságot és alkalmazásszintű kapcsolatot biztosítsunk ezeken a klasztereken.

Kemény rész: Több albérlet és több fürt a Kubernetes számára

Az egyetlen Kubernetes fürtben futó alkalmazások építése és működtetése nem triviális feladat, még akkor sem, ha felhő szolgáltató által kezelt fürtöt fogyasztunk. Ezért gyakori, hogy a DevOps és az SRE csapatok minimalizálják az általános költségeket, és nem foglalkoznak sok klaszter összetettségével. Elég gyakori, hogy a csapatok egy nagy Kubernetes-fürtöt építenek, és minden típusú erőforrást ugyanabba a fürtbe helyeznek. Bár ez nagyszerűnek tűnik, mert egyszerűsíthetik a műveleteket és a fürtöt a maximális számítási hatékonyság és költség érdekében futtathatják, ez több okból sem a legjobb ötlet. Először is, a termelési munkaterhelések iránti igények nagyon eltérnek a dev-teszttől és a stádiumoktól – az instabil fejlesztési munkaterhelések problémákat okozhatnak a stabilabb termelési munkaterheléseknél.

A változatos munkaterhelések szükségletein túl a K8s biztonsága és az elkülönítési korlátozások egy másik meghajtó a multi-cluster számára. A K8-ok biztonságának és erőforrás-elszigetelésének megoldására tipikus megközelítés az, hogy független klasztereket hozzon létre minden bérlő számára egy több bérlős modell segítségével. Bár ez megvalósítható a felhőben, a szélén nem lehetséges több fürt futtatása. Az Edge webhelyek számítási és tárolási erőforrásokkal kapcsolatos korlátozásokkal és korlátozott hálózati sávszélességgel rendelkeznek, hogy naplókat és mutatókat küldjenek az egyes további fürtökről a központi felhőbe.

Több Kubernetes-fürt problémájának kezeléséhez kiértékeltük a Ranchert a a Kubernetes-fürtjeink (amikor elindítottuk, az Anthos és az Azure Arc nem létezett) és a KubeFed. Az akkor elérhető két megközelítés (és ma is ugyanaz a helyzet volt):

  1. A több fürtből álló felügyelet (pl. Rancher) egy központi konzolról lehetővé tette volna számunkra, hogy több fürtöt telepítsünk bárhol, és végezzen életciklus-kezelési műveleteket, például frissítéseket, visszagörgetést stb. Ezek közül a rendszerek közül néhány lehetővé tette egy egyedi klaszter megszólítását automatizálással az alkalmazások konfigurálásához és telepítéséhez
  2. Másik megközelítés a Kubernetes telepítése klaszter összevonás (KubeFed) vezérlő sík és több fizikai klasztert úgy nézhet ki, mint egy klaszter. Ez a projekt éppen akkor kezdődött, amikor néztük, és még ma is csak alfa stádiumban van.

A GCP Anthos és az Azure Arc nemrégiben tett bejelentése után átértékeltük eredeti döntésünket: elosztott vezérlősíkot építeni, és a következtetés az volt, hogy még ez a két új ajánlat sem tudott volna megoldani két kritikus problémát az elosztott klaszterekkel.Ez a két kulcsfontosságú képesség, amelyre a platformunkhoz szükségünk volt:

  1. Több klaszter flottaként történő kezelése annak érdekében, hogy megoldja a műveleteket az egész fürtön vagy egy logikai csoportban – olyan műveletek, mint a konfiguráció, telepítés, mérőszámok, stb. Ez kritikus jelentőségű, mivel csökkenteni akarjuk az SRE-csapataink működési költségeit, javítani a DevOps hibakeresési képességét és javítani a rendszerünk skálázhatóságát.
  2. Képesség egyéni fizikai feldarabolásra A Kubernetes klaszter több bérlésre a fizikai fürtök felpörgetése nélkül – ez különösen kritikus az erőforrásokkal szűkös környezetekben, ahol nem akarunk új fizikai fürtöket felvenni csak a több albérletbe

E két probléma megoldásához új technikával kellett előállnunk – elosztott vezérlősík – hogy megoldjuk a „Több” fürtöt, és a „több klaszter” ekvivalensét biztosítja az erőforrás-korlátozásban történő bérbeadáshoz d környezetek.

Elosztott vezérlősík: Hogyan sikerült elérnünk a több fürtös Kuberneteseket

Platform csapatunk úgy döntött, hogy felépít egy elosztott vezérlősíkot a Kubernetes számára, amely azonban a csapatunk számára kiteszi a Kubernetes API-kat , ezek az API-k olyan „virtuális” fürtökből származnak, amelyek csak a vezérlősíkunkban léteznek – egy virtuális K8s (vK8s) API-kiszolgáló egy virtuális K8s-fürthöz (amint az a 1. ábrán látható ). Ez a vezérlősík a felhasználó szándékát több, a szélünkön futó fizikai Kubernetes-fürtre, hálózati POP-jainkra és nyilvános felhőalapú helyekre is feltérképezi. Ezekhez a fizikai fürtökhöz csak az elosztott vezérlő síkunk férhet hozzá, és nem minden bérlő / felhasználó.

1. ábra: Elosztott vezérlősík

Ez a vezérlő sík minden bérlőhöz egy vagy több „virtuális” alkalmazásfürtöt biztosít, ahol telepíthetik alkalmazásukat ) és a konfiguráció alapján a vezérlősík több fizikai Kubernetes-fürtön replikálja és kezeli azt. A konfigurációs és telepítési műveletek mellett a megfigyelési műveletek is követik ezt a „virtuális” fürtöt anélkül, hogy több fizikai fürtből származó adatok gyűjtésére és szétválasztására szerszámokat kellene építeni.

Vegyünk egy minta felhasználói felület alkalmazást, amelynek neve productpage, ahol A felhasználói szándék az, hogy 3 helyen osztva futtassa – pa2-par, ny8-nyc és ams9-ams, mindegyikben 2 replika. Amint a felhasználó létrehoz egy vK8s objektumot, és egy virtuális fürthöz csatolja, amely azonnal létrehoz egy vK8s API kiszolgálót, amely használható a szokásos kubectl-lel.

Következő lépésként a felhasználó letölti a virtuális kubeconfig fájlt. fürtöt, és létrehoz egy normál yaml-t egy K8s-telepítés leírására a termékoldalhoz.

A telepítési specifikáció létrehozását követően , a felhasználó folytathatja a központi telepítés létrehozását ezen a virtuális fürtön:

Most, ha a felhasználó ellenőrzi bevetése szerint 6 replikát kezdtek el, mindegyik helyen 2-vel (pa2-par, ny8-nyc és ams9-ams).

A következő kimeneten 2 hüvely jelenik meg, amelyek az egyes helyeken futnak, egy adott fizikai csomóponthoz hozzárendelve

Ez az egyszerű példa bemutatja, hogy mennyire elenyésző percek alatt megszerezni bármely alkalmazás több fürtös replikációját telepítés és kezelési terhek nélkül. A szándék feltérképezése mellett az elosztott vezérlősík a virtuális fürt megfigyelhetőségét is biztosítja, nem pedig egyedi fürt alapon.

Elosztott vezérlés és centralizált menedzsment a több bérlethez

Mint láthatja a 2. ábrán , hogy központosított irányítási síkunk két nyilvános felhőszolgáltatón (egy-egy régión) fut – egy AWS és egy az Azure-ban (redundancia esetén). Ez a kezelési sík lehetővé teszi az SRE-nek, hogy bérlőket hozzon létre kemény, több bérleti joggal – pl. a VoltMesh szolgáltatásunkon dolgozó fejlesztőcsapat bérlő lehet, az ügyfélmegoldásokon dolgozó ügyfélmegoldási csapat pedig saját bérlő, saját felhasználókkal.

2. ábra: Több albérlet és több fürt

Ezek a bérlők mindegyike sokakat létrehozhat névtereket, és rendeljen hozzá egy felhasználói csoportot, hogy működjenek együtt ezeken a névtereken. Ezek a névterek nem Kubernetes névterek – ezek elkülönítési határok a platformunkon RBAC-szabályokkal és a felhasználók IAM-házirendjeivel.

Amikor egy névtéren lévő felhasználó létrehozni akar egy alkalmazásfürtöt, létrehoz egy vK8s objektumot, és ez viszont létrehoz egy vK8s API-kiszolgálót a kezelési síkunkban.Ezen vK8s objektum használatával a felhasználó létrehozhat telepítéseket, állapotjelző készleteket, PVC-ket stb., És a vezérlő sík biztosítja, hogy ezek a műveletek egy vagy több fizikai fürtön történjenek, a vK8s objektumhoz társított webhelyek alapján.

Mivel minden bérlő és felhasználó a szokásos K8s műveleteket módosítás nélkül használja, lehetővé teszi a rendszer kompatibilitását számos, az operátorok körében népszerű eszközzel – pl. Spinnaker, Helm, Jenkins stb.

Elosztott vezérlősíkból realizált nyereség

Az elosztott vezérlősík nagy előnye, hogy megoldotta az SRE és a DevOps működési költségeit csapatok. Most végre tudnak hajtani műveleteket (konfiguráció, telepítés, figyelés, házirend stb.) Egy virtuális fürtön keresztül, és a vezérlő sík automatikusan több fizikai fürtön fogja leképezni. A több fürt működésének egyszerűsítése mellett a vezérlősík megoldotta a több bérlés biztonsági és szigetelési problémáját is.

Ez az elosztott vezérlési sík javította azon fejlesztők termelékenységét is, akik új funkciókat kívánnak hozzáadni a platformunk – nem kell minden esetben új automatizálást építeniük, amikor olyan új szolgáltatásokat adnak hozzá, amelyek hatással vannak a konfigurációra vagy a műveletekre több fürtön keresztül. A szándékalapú konfigurációs modellt használják, és a vezérlősík tudja, mit kell tennie. Ezenkívül továbbra is kölcsönhatásba léphetnek ezzel az elosztott és többszörös fürtobjektummal – virtuális kubernetékkel – a kubectl használatával, és nem egy másik CLI használatával. mint egy éve, rájöttünk, hogy ez a globálisan elosztott vezérlõsík (amely a hálózati POP-jainkban fut) jelentõs méret-, teljesítmény- és megbízhatósági elõnyöket is nyújt – amit korai napjainkban még nem is gondoltunk. Erről a megállapításról a közelgő KubeCon előadásunkban és a következő hetekben külön blogbejegyzésként fogunk foglalkozni.

Folytatás… A globális terjesztésű SaaS szolgáltatásunk felépítése és működtetése a nyilvános felhőben számos alkalmazásfürttel, a magánhálózati PoP-kkal és az élhelyekkel készült. Következik a (Global Service Mesh for Distributed Apps)…