Technológia- és szemléletváltás, Kubernetesszel

A Kubernetes mára számos nagyvállalatnál megvetette a lábát, amelyek sora folyamatosan növekszik - a technológiaváltás azonban akkor lehet igazán működőképes, ha ahhoz szemléletváltás is párosul. Az új alapokra a legacy megoldások ráerőltetése helyett modern alkalmazásokat érdemes felhúzni, ráadásul miután a Kubernets elmossa a határt a különböző "Ops" területek között, olyan szakértőket kell hozzá kinevelni, akik szélességében értik a vállalat által használt technológiai stacket, nem csak egy-egy területre fókuszálnak - lényegében az egész céges IT újragondolására van szükség.

NAGY FALAT, DE MEGÉRI

Ez nem kis feladat, de érdemes belevágni, a befektetett erőforrások ugyanis megtérülnek, ahogy azt az elmúlt években a Telekom is megtapasztalta. A vállaltnál 2018-ban indult a tervezési folyamat, ekkorra fogalmazódott meg az igény, hogy a cég privát felhő platformot akar létrehozni. Ehhez VMware virtualizációs infrastruktúra állt rendelkezésére, így nem meglepő módon első körben VMware NSX-V multi tenant környezetet hozott létre, amelyre aztán vanilla Kubernetes került - az éles használatra kész klaszterek létrehozásához pedig Ansible Towert, illetve a nyílt forrású KubeSpray projektet vetette be a cég.

Mint azt Szelestey Péter a Magyar Telekom Cloudification Product Ownere a június 8-i HWSW free! Kubernetes meetupon tartott előadásában elmondta, a projekt 2019-ben több új mérföldkövet is kipipálhatott - az új szolgáltatásokkal pedig elsősorban a DevOps csapatok munkáját tette könnyebbé. Ez először a GitLab Enterprise bevezetését jelentette, a CI/CD folyamatokhoz, de a csapat az Artifactory univerzális bináriskezelő rendszert, illetve egy olyan Fluent Bit megoldást is munkába állított, amellyel az Elasticsearch-Logstash-Kibana triumvirátusba tudta továbbítani a begyűjtött logokat - említést érdemel továbbá a Prometheus Operator is, amelyet ekkor a cég monitoring szolgáltatásként használt.

A fejlesztések természetesen a pandémia által sújtott 2020-as évben sem álltak le, ekkor azok hangsúlya a biztonságra helyeződött át, kezdve a Hashicorp Vault szolgáltatás bevezetésével, a secretek kezeléséhez - hogy a különböző titkok, jelszavak, tanúsítványok és különböző egyéb érzékeny adatok ne magán a K8s platformon tárolódjanak, hanem egy külső rendszeren. Az autentikációra a vállalat a Dex nyílt forrású szolgáltatást kezdte használni, az ingress szolgáltatások külső IP címekkel való ellátásához pedig a MetalLB-hez nyúlt.

FÓKUSZBAN AZ AUTOMATIZÁCIÓ

Idén újabb fontos mérföldkő várható, a Telekom egy nagyszabású migrációs folyamatba fogott bele: a meglévő három, Kubernetes multi-tenant klaszterét költözteti az említett NSX-V-ről NSX-T-re. Ez azért is komoly váltás a cég életében, mert utóbbi megoldás sokkal biztonságosabb hálózatot biztosít, illetve mind a klaszterek, mind a DevOps kollégák számára egy magabiztosabban kezelhető, hálózati és fejlesztési szempontból is biztonságosabb környezetet teremt, ahol a deployment folyamatok is felgyorsulhatnak. A váltással, illetve a technológiai stack összeválogatásánál fontos cél volt továbbá a különböző fejlesztési és üzemeltetési folyamatok széles körű automatizálhatósága, ezzel pedig a kollégák is tehermentesítése is - az NSX-T ehhez egy sokkal átfogóbb, komplexebb megoldást kínál.

Az igénykezelés teljes körű automatizációja is folyamatban van, hogy akár gombnyomásra létrehozhatók legyenek namespace-ek, amelyekbe aztán azonnal deploy-olhatók alkalmazások, microservice-ek. Ezen felül a vállalat Service Mesh bevezetésének lehetőségeit is vizsgálja, hogy a Layer 7 hálózati rétegben történő kommunikációt, autentikációt meg tudja valósítani. Ami a jövőre vonatkozó további elképzeléseket illeti, már a Hybrid Cloud is felkerült a cég térképére, hogy akár AWS vagy Azure termékekkel is ki tudja terjeszteni saját felhőszolgáltatását - így az időszakos projekteket akár publikus felhőbe ki lehet majd helyezni.

Az automatizációban, a hatékonyabb orkesztrációban, a klaszterek legyártásában, frissítésében, illetve karbantartásában a vRA (VMware vRealize Automation), illetve a vRO (VMware vRealize Orchestrator) is rendkívül hasznosnak bizonyultak. Előbbit a cég az IaaS réteg legyártásához veti be, a blueprint létrehozásától a node-menedzsmenten át az OS clone és build feladatokig, utóbbit, a vRO-t pedig a Kubernetes klaszterek elkészítéséhez szükséges lépések automatizálásához, valamint az Ansible Tower felé kommunikációs interfészként. Az Ansible Tower A K8s klaszter node-ok telepítéséért, menedzseléséért, frissítéséért és karbantartásáért felel, nagy előnye továbbá, hogy a kérések fogadásához dedikált API-val rendelkezik, ami nagyban segíti az automatizációt.

Szintén rendkívül hasznos eszköz a korábban is említett, nyílt forrású Kubespray, amellyel "instant" production ready K8s klaszterek hozhatók létre, meghatározott számú hosttal, master és worker node-dal - ennek megfelelően a Telekomnál az éles használatra kész klaszterek legyártása már gombnyomásra történik, tokkal-vonóval.

NEM VOLT SÉTAGALOPP

Persze ahhoz, hogy a mai állapothoz eljuthasson, a vállalatnak egy sor kihívást is le kellett küzdenie. Erre jó példa volt a hálózat megfelelően biztonságos működési modellre való felhúzása. A művelethez a fejlesztőcsapatnak a belső biztonsági előírásokhoz igazodva, saját, telekomos IP címtartományokat kellett behirdetnie - minden egyes microservice együttes egyedi IP címtartománnyal kellett rendelkezzen a beazonosíthatóság érdekében. A csapat MetalLB baremetal loadbalancerrel futott neki a K8s LoadBalancer típusú szolgáltatások számára az egyedi külső IP-k kiosztásának - ugyanakkor miután a cég által alkalmazott a BGP protokoll csak egy session felépítésére képes peer szomszédjával node páronként, és ezt a kapcsolatot a node-okban a Calico már lefoglalta, a MetalLB már nem tudott ugyanazzal a BGP routerrel összekapcsolódni. Ekkor még a Calico 3.4 sem volt képes loadbalancer típusú szolgáltatások külső IP címeinek meghirdetésére. A cég végül Calico route reflector node-ok bevetésével oldotta meg a közvetett peeringet, a Calcico 3.10.0-val pedig a külső címek hirdetése is végre natívan támogatottá vált.

Természetesen az átállással a működési modell is alaposan átalakult az elmúlt években, a Telekom agilis fejlesztésre tért át, a klasszikus, mindenhol kézi beavatkozást igénylő vízesés modell helyett fejlett CI/CD folyamatokat bevezetve, mindezt GitLabra támaszkodva. Ezzel a release-ek és az MVP-k leszállítása is felgyorsult, illetve a DevOps kollégákat is sikerült sokkal inkább tehermentesíteni. Az új CI/CD folyamatoknak hála a manuális munkavégzés átlagos 15 órája helyett a cég ma már 10 perc alatt létre tud hozni olyan namespace-eket, amelyekbe azonnal tud alkalmazásokat telepíteni. A vállalat öt különböző környezeten közel száz microservice együttest működtet - K8s klaszterenként pedig több mint ezer podot tudhat magáénak.

A 2018 óta tett erőfeszítések tehát egyértelműen meghozták gyümölcsüket a Telekomnál: a Kubernetes bevezetése nagyságrendekkel hatékonyabb technológiai és szervezeti működést is magával hozott, a befektetett erőforrások megtérülése körül mára nem maradt kérdőjel. Ha Te is szeretnél részese lenni a Telekom Kubernetes-sztorinak, akkor nézz szét a nyitott pozíciók között!

[A Magyar Telekom megbízásából készített, fizetett anyag.]