A Kubernetes-t a Microsoft Azure-ben létrehozni olyan, mint házat építeni: biztos alapok nélkül lehetetlen. Az Azure Kubernetes Service (AKS) best practice megoldásokról Farkas Lóránd részéről tudhattunk meg bővebb információkat, az Azure webinár sorozatunk egyik előadásában.

Ismered az AKS-t? Remek! Mindent tudsz az Azure-ról? Akkor lapozz a cikk végére, mert itt elsősorban azoknak foglaltuk össze a technológia lényegét, akik konkrét példákon keresztül keresnek megoldásokat az ügyfelüknél meglévő problémákra. Ha mégsem vagy olyan biztos a dolgodban, és szívesen tanulnál, akkor ez az öt perc befektetett figyelem garantáltan megtérül.

Minden az alapoknál kezdődik

Ahhoz, hogy a Kubernetest létrehozzuk az Azure felhőben, magában az Azure-ben kell rendet tennünk ahhoz, hogy az ügyfeleinknek úgy tudjuk azt átadni, hogy az használható legyen. Ahogy egy házat, az Azure-környezetet is érdemes megtervezni és az igények alapos felmérése után nekilátni a munkának. Itt is biztos alapokra van szükség, hogy arra a későbbiekben lehessen még több „szintet” ráépíteni.

Amikor kiépítjük az Azure-környezetet, először is meg kell érteni, hogy az ügyfeleinknek milyen elvárásaik vannak a felhővel kapcsolatban. Azzal is kell számolnunk, hogy az ügyfél hogyan szerezze meg azt a tudást, amely egy ilyen infrastruktúra üzemeltetéséhez szükséges, Emellett meg kell értenünk azt, hogy mi a motivációjuk és mit szeretnének elérni.

Egy landing zone akkor jó, ha időtálló és jól strukturált

Az ügyféligény megismerése után elkezdhetjük építeni a landing zone-t. Ennek is időtállónak kell lennie: kezdetben az egyszerűségre kell törekedni, de úgy, hogy ne szabjunk határt a későbbi fejlesztéseknek, akár expanziónak, például abban az esetben, ha a cégünk felvásárol egy másik céget. A Microsoft által elképzelt metódus része, hogy az ügyfelek a teljesen kezdő szintről egészen a szakértői fázisig juthassanak.

Jól szabályozott, megalapozott menedzsment nélkül nincs rendszer

Technikai oldalról ez azt jelenti, hogy egy Enterprise-scale landing zone-t kezdünk el kiépíteni. Ennek igen sok eleme van, amelyek mentén döntéseket hozhatunk, és úgy van kialakítva, hogy van egy Management Group struktúra, amik tulajdonképpen a hagyományos Active Directory-ban az Organization Unit-oknak megfelelő konténerek.

Célszerű a Managament Group struktúra alapokat már az elején kialakítani, mindennek nincsen semmilyen költsége. Ezek azt a célt szolgálják, hogy házirendeket tudjunk érvényesíteni a különféle erőforrásainkra – hasonlóan ahogy az Azure Active Directory-ban -, tehát Azure Policy-ket szeretnénk érvényesíteni. Lényegében egy alapvető Azure Policy szettet érvényesítünk a tetején, és lefelé haladva ezt egyre szigorúbbá tehetjük.

Fontos, hogy amit az elején megtettünk, a következő szinteken a további elem is meg fogja örökölni.

Mire van szüksége egy cégnek? Mindenekelőtt megosztott erőforrásokra (központi tűzfal, központi site-to-site VPN, központi domain kontrollerek, központi fájlszerver). Ezeket általában egy hub-and-spoke hálózati modellbe szeretnénk implementálni. A hub and spoke modell már több mint 5 éve létezik. A hub alkotja a központi erőforrásokat, és vannak az úgynevezett spoke-ok. A spoke-ból lehet több is, azaz akár több alkalmazást is létrehozhatunk. Az a szabály érvényesül, hogy a spoke-ok egymás között alapértelmezett módban nem tudnak kommunikálni, ami fontos, ha perimétereket szeretnénk definiálni. Mindenki a központi tűzfalon keresztül megy ki, és a központi site-to-site VPN-t használja, így tudnak kommunikálni a központtal.

Ha pedig egymással szeretnének kommunikálni a különféle spoke-ok, akkor ezt a központi tűzfalon keresztül lehet megtenni. Ez akkor lesz fontos, ha például van egy production és egy DevOps környezetünk, hiszen ekkor alapvető, hogy ezek egymással ne tudjanak kommunikálni. Mindez ebben a koncepcióban megoldható.

A Government első szabálya, hogy amit lehet, tiltsunk le. Nem azért, mert nem bízunk meg másokban, hanem mert egy apró tévedés is jelentős negatív kihatással lehet a rendszerre.

Landing zónák igény szerint méretre szabhatóak

A landing zónákból számos féle-fajta létezik, akár külön subscription-be is szervezhetők. Egy kis cég esetében például lehet, hogy egy subscription-ben lesz az összes alkalmazás, és egy subscription-ben lesz a központ. Egy nagyvállalatnál már külön landing zone-ban lehet az AKS, a Windows Virtual Desktop, az üzleti alkalmazások, és így tovább. A subscription-öknek eleve vannak limitációi, de nincs extra költsége annak, ha nekünk 2 van belőlük vagy 10, ugyanis az Azure irányelvek segítségével biztosítható, hogy ne legyen emiatt káosz a háttérben. Ezáltal jobban felépíthető a least-privileged access model, hogy kinek mihez van jogosultsága, és demokratizálni tudjuk a különféle erőforrások használatát.

Egy nagyobb cégnél tehát egy központi subscription tartalmazza a teljes biztonságot és menedzsmentet is. Egy másik subscription-be kerül a connectivity – itt csak a központi tűzfal és a site-to-site VPN található. Egy további subscription-be pedig a domain controller-eket helyezzük el. A landing zónákból pedig lehet számtalan, mindegyik egy hub-and-spoke-kal lesz a connectivity-vel összecsatolva.

Ha egy egyszerű Kubernetes klasztert szeretnénk felépíteni, ahol 2 darab subscription-t használunk, akkor 1-et megtartunk a Hub-nak és egyet megtartunk a Spoke-nak, így az ábrán látható módon nézne ki az acrhitektúra.

A Sandbox-ok arra vannak fenntartva, ha szeretnénk egy olyan homokozót, ahol semmi szabály nincs a költségvisszafogáson kívül; itt az Azure szabályrendszerekből nyilván sokkal kevesebb érvényesül. Másfelől tény, hogy a Sandbox-nak nincsen semmilyen kapcsolata a production-környezettel, tehát a Sandbox lényegében egy elszigetelt zóna (DMZ).

Hasznos infó a Microsoft Azure és a Kubernetes integrációjáról

Aki igazán napra kész szeretne lenni, a Microsoft nemrég frissített javaslatait megtekintheti az Identity and Access Management Consideration for AKS-t a következő linkre kattintva: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/aks/eslz-identity-and-access-management . Mindezek közvetlenül a termékfejlesztésért felelős osztálytól jönnek. A Cloud Solutions Framework dokumentációnak egy kifejezetten Kubernetes-re kifejlesztett leírása is megtalálható a Microsoft nevezett oldalán. A Design considerations és a Design recommendations része kifejezetten a Kubernetes-re érvényes. Egy fontos kitétel, hogy ha Kubernetes-t hozunk létre, akkor érdemes Azure AD-val integrálni.

A példákból érdemes tanulni: egy autómosó bevezetése az AKS felhőtechnológiai megoldásába

A Microsoftnál Szabó Márk, DevOps-és mérnök létrehozott egy pash alapokon elindított Carwash alkalmazást, amelynek a web része app service plan-ek alatt fut, API-t és LogicApp-ot is használ. Az egész Azure-re integrált és a cél az volt, hogy szeretné az egészet Azure-be deploy-olni. Az IT-csapat pedig létrehozott egy, a korábbi landing zone-hoz képest egyszerűsített, annak 3 subscription-os változatát. Ebből van a központi, ahova a központi menedzsment került, az identity és a correctivity. Ha nincs szükségünk identity-re, akkor ezt a resource group-ot nem hozzuk létre. Ha connectivity-re és site-to-site VPN-re sincs szükségünk, akkor ezt a részt nem hozzuk létre. A Corp Landing Zone-on kifejezetten olyan alkalmazások futnak, amelyek nem ’lógnak’ ki az internetre, amíg az Online Landing Zone-on olyanok, amelyek igen.

A subscription-t megvizsgálva az láthatjuk, hogy a monitorozás és számos dolog a központi Log Analytics-munkaterület felé mutat. Itt vannak kifejezetten Kubernetes-szel kapcsolatos irányelvek. Például meg tudjuk azt mondani, hogy konténereket csak megbízható forrásból lehessen beszerezni, ahogy azt is megmondhatjuk a GitOps-ról, hogy ha több Kubernetes klasztert kell menedzselnünk, és az egyik felét a földön, a másikat pedig a felhőben szeretnénk tudni, akkor azt a GitOps segítségével megcsinálhatjuk. Ennek az a lényege, hogy kiválasztunk egy konfigurációs fájlt, amelyben definiáljuk, hogy mely namespace-ek legyenek ott, melyik szolgáltatások fussanak, és milyen jogosultságok legyenek beállítva.

A konfigurációs fájlt aztán felrakjuk egy privát GitHub fiókba, és ez az irányelv innentől kezdve érvényben van. Amint valaki létrehoz egy Kubernetes klasztert, eltelik pár perc, amíg észleli, hogy milyen konfigurációt alkalmazzon, majd letölti a GitHub-ról és érvényesíti az összes beállítást a Kubernetes klaszteren, ezáltal létrejönnek a pode-ok, a service-ek és a beállítások, amiket definiáltunk. Ekkor készen áll a klaszter arra, hogy oda alkalmazásokat telepítsünk.

Akkor hatékony egy DevOps csapat, ha a különböző szerepkörökhöz (IT szakember, programozó, stb.) meghatározott jogosultság és szerepkör (role) kapcsolható. Ugyanakkor hasznos lehet, hogy az alaprendszerben található több ezer jogosultság és szerepkör mellett custom role-ok is létrehozhatóak, amivel akár elemi szintű jogosultságok is beállíthatók. Ez fokozott védelmet jelent pl. az informatikai infrastruktúra konfigurációja esetén.

Így védjük ki, hogy a programozónk kárt tegyen a rendszerben

A Carwash app fejlesztése során arra volt szükség, hogy amikor a programozó létre szeretett volna hozni egy Kubernetes klasztert, akkor mindezt gyorsan és közvetlenebb módon megtehette, mégis a legnagyobb biztonság mellett. Fontos tehát kivédeni azt is, hogy olyan dolgokat hozzon létre feleslegesen, ami nem kell a munkájához. Nem kreálhat publikus IP-címet sem, hiszen ez már az IT kompetenciájába tartozik. Tekintve, hogy nem hálózati szakember, nem konfigurálhat hálózatot sem.

Lényeges az is, hogy ha a key vault-ot használja, képes legyen törölni, de ne tudjon véglegesen törölni. Az is fontos, hogy a programozó ne tudja a routing-táblát felülírni. Amikor a subscription létrejött, lehet, hogy be lett állítva a default route, azaz hogy minden adatforgalom a központi tűzfal felé megy. Lényeges, hogy a programozó ezt ne tudja felülírni. Ahogy az is fontos, hogy ne tudjon VPN-t létrehozni, meg express route-ot sem.

Az Azure policy-ből is számos jogosultság letiltható, amely szintén a rendszert védi a programozó esetleges hibái miatt. Az Allowed virtual machine size SKUs például egy olyan policy, ahol definiálható, hogy melyik pl. az a 2-3 géptípus, amit a programozó használhat.

Többet tudnál meg a Kubernetesről?
A harmadik részben egy nagyon érdekes logisztikai példát mutatunk be, ahol a Kubernetes valódi értéket tudott teremteni egy igen szabályozott környezetben is.

A teljes webinár itt érhető el. A több órás videókonferencia második témájáról korábbi írásunkból tájékozódhattok.

A 2009-ben alapított, 100%-ban magyar tulajdonú, budapesti vállalkozásunk, a Kvazar.cloud több száz viszonteladó partnerrel dolgozik együtt. Mi vagyunk az egyik legnagyobb Microsoft felhőszolgáltatás-közvetítő partner Magyarországon. Hogy mi köze van egy Microsoft disztribútor cégnek a cloud native technológiához? Elsősorban az, hogy a hagyományos disztribúciós szerepkörből felhőszolgáltatás-közvetítővé (közvetett CSP disztribútor) léptünk elő.

Lépj kapcsolatba velünk!