Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko Fakulteta za matematiko in fiziko
Mihael Trajbariˇc
Razvoj Ansible zbirke za podporo Kubernetes
DIPLOMSKO DELO
INTERDISCIPLINARNI UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN MATEMATIKA
Mentor : izr. prof. dr. Mojca Ciglariˇ c Somentor : Dragan Radolovi´ c
Ljubljana, 2021
tatov diplomske naloge je potrebno pisno privoljenje avtorja, fakultete ter mentorja.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Kandidat: Mihael Trajbariˇc
Naslov: Razvoj Ansible zbirke za podporo Kubernetes
Vrsta naloge: Diplomska naloga na interdisciplinarnem univerzitetnem pro- gramu prve stopnje Raˇcunalniˇstvo in matematika
Mentor: izr. prof. dr. Mojca Ciglariˇc Somentor: Dragan Radolovi´c
Opis:
Kubernetes je zelo priljubljeno orodje za orkestracijo vsebnikov Docker. V kompleksnih okoljih z velikim ˇstevilom vsebnikov, platform in tehnologij, se za pomoˇc pri avtomatizaciji in orkestraciji uporabljajo namenska dodatna orodja, med katere sodi tudi Ansible. Zasnujte in implementirajte zbirko modulov Ansible, ki bodo podpirali upravljanje objektov Kubernetes. Pre- glejte obstojeˇce podobne zbirke in jih kritiˇcno ovrednotite, vaˇsa zasnova pa naj njihove teˇzave odpravi. Izdelano zbirko preizkusite in komentirajte.
Zahvaljujem se mentorici, izr. prof. dr. Mojci Ciglariˇc, za usmerjanje in nasvete pri pisanju naloge. Hvaleˇzen sem celotni ekipi podjetja XLAB d.
o. o., ki mi je stala ob strani: mentorju v podjetju Draganu Radolovi´cu, ki je prispeval idejo za nalogo in mi pomagal s popravki; koordinatorju projekta SODALITE dr. Danielu Vladuˇsiˇcu za strokovne nasvete in pomoˇc pri formu- liranju ideje; Ansible guruju Tadeju Borovˇsaku, ki mi je priskoˇcil na pomoˇc v trenutkih izgubljanja po Ansible ekosistemu. Velika zahvala gre moji druˇzini in dekletu za vso podporo med ˇstudijem.
Kazalo
Povzetek Abstract
1 Uvod 1
2 Opis platforme Kubernetes 5
2.1 Kratka zgodovina . . . 6
2.2 Arhitektura . . . 6
2.3 Opis pomembnejˇsih objektov . . . 8
2.4 Poslovni modeli . . . 10
3 Predstavitev orodja Red Hat Ansible 13 3.1 Osnovni koncepti . . . 14
3.2 Namestitev in distribucija vsebin . . . 16
4 Avtomatizacija Kubernetes 19 4.1 Upravljanje heterogenih aplikacij . . . 19
4.2 Operatorji . . . 23
4.3 Motivacija za razvoj nove zbirke . . . 24
5 Naˇcrtovanje in razvoj 27 5.1 Smernice za razvoj Ansible zbirk . . . 27
5.2 Naˇcrtovanje nove zbirke . . . 31
5.3 Izbira odvisnih komponent . . . 36
6.2 Teˇzave pri implementaciji . . . 42 6.3 Samodejni testi . . . 44 6.4 Preizkus reˇsitve . . . 45
7 Sklepne ugotovitve 49
Literatura 51
kratica angleˇsko slovensko API Application programming in-
terface
Aplikacijski programski vme- snik
CaaS Container as a Service Vsebnik kot storitev CI/CD Continuous Integration and
Continuous Delivery
Sprotna integracija in dostava CRI Container Runtime Interface Vmesnik za poganjanje vseb-
nikov
CRD Custom resource definition Definicija objekta po meri DNS Domain name system Sistem domenskih imen DSL Domain specific language Namenski domenski jezik HA High Availability Visoka razpoloˇzljivost HPC high performance computing Superraˇcunalniˇstvo
HTTP Hypertext Transfer Protocol Protokol za prenos hiperteksta HTTPS Hypertext Transfer Protocol
Secure
Varni protokol za prenos hi- perteksta
IaC Infrastructure as Code Infrastruktura kot koda IaaS Infrastructure as a Service Infrastruktura kot storitev IoT Internet of Things Internet stvari
IP Internet Protocol Internetni protokol IT Information tehnology Informacijska tehnologija JSON JavaScript Object Notation Objektna notacija za Java-
Script
k8s Kubernetes Kubernetes
PaaS Platform as a Service Platforma kot storitev REST Representational state trans-
fer
Reprezentativni prenos stanja
kratica angleˇsko slovensko
SaaS Software as a Service Programska oprema kot stori- tev
SDK Software developement kit Komplet za razvoj programske opreme
SRE Site Reliability Engineer Inˇzenir, odgovoren za zaneslji- vost delovanja strani
SSH Secure shell varna lupina
TDD Test driven developement Testno vodeni razvoj TOSCA Topology and Orchestration
Specification for Cloud Appli- cations
Specifikacija za topologijo in orkestracijo
VM Virtual Machine Virtualni raˇcunalnik YAGNI You aren’t gonna need it Ne boˇs ga potreboval YAML YAML Ain’t Markup Langu-
age
YAML ni oznaˇcevalni jezik WSL Windows Subsystem for Linux Windowsov podsistem za Li-
nux
Povzetek
Naslov: Razvoj Ansible zbirke za podporo Kubernetes Avtor: Mihael Trajbariˇc
Kubernetes je razˇsirjena platforma za orkestracijo vsebnikov. Omogoˇca opi- sovanje postavitev aplikacij na deklarativen naˇcin, elegantno dodajanje ali
odstranjevanje instanc komponent in spremljanje stanja ter upravljanje ˇzivljenjskega cikla takˇsnih aplikacij. Kljub bogatemu naboru funkcionalnosti pa ni pri-
merna za upravljanje sodobnih arhitektur heterogenih aplikacij, ki lahko teˇcejo na geografsko in tehnoloˇsko razliˇcni infrastrukturi v in na robu oblaka.
Diplomska naloga raziˇsˇce reˇsevanje problema preko integracije z orodjem Ansible. Poglobi se v implementacijo vsebin in raziˇsˇce dodatne prednosti takˇsnega pristopa. Najpomembnejˇsi prispevek je nova Ansible zbirka soda- lite.k8s, ki omogoˇca definiranje postavitev aplikacij s pomoˇcjo orodja Ansible na varen in enostaven naˇcin.
Kljuˇcne besede: kubernetes, vsebniki, avtomatizacija.
Abstract
Title: Developement of Ansible Collection for Kubernetes support Author: Mihael Trajbariˇc
Kubernetes is a Production-Grade Container Orchestration engine. It en- ables developers to describe application deployments in a declarative way, gracefully scales up or down, and manages the lifecycle of the components.
But despite rich functionality, it falls short in orchestrating modern hetero- geneous workloads that run on geographically and technologically different infrastructure in the cloud and on the cloud edge. Diploma thesis researches solving this problem via integration with Ansible. It explores details of im- plementing Ansible content and researches additional benefits of integration.
The most important achievement of this thesis is a new Ansible Collection sodalite.k8s, which allows the definition of application deployments with An- sible Playbooks in a safe and easy to use way.
Keywords: kubernetes, containers, automation.
Poglavje 1 Uvod
Tipiˇcno produkcijsko postavitev obiˇcajno sestavlja fiziˇcni streˇznik, na kate- rem teˇce streˇzniˇski operacijski sistem in na tem teˇcejo aplikacije. Takˇsen pristop ima kar nekaj slabosti. Ena slabost je vsekakor varnostni vidik, saj vse aplikacije ˇzivijo v istem okolju in tako vdor v eno lahko ogrozi tudi pre- ostale. Druga slabost pa je odsotnost mehanizma za delitev virov. Tako se lahko zgodi, da ena aplikacija lahko na primer obremeni procesor in tako upoˇcasni delovanje ostalih aplikacij.
Oba zgoraj opisana problema lahko reˇsimo z gostovanjem zgolj ene aplika- cije na posameznem streˇzniku. Takˇsna reˇsitev ni optimalna, saj obremenitev aplikacij obiˇcajno niha, streˇznik pa mora zadoˇsˇcati potrebam gostujoˇce apli- kacije tudi v najbolj obremenjenem stanju, tako da streˇzniˇski viri pri tem pristopu veˇcino ˇcasa niso uporabljeni v celoti. Takˇsna produkcijska postavi- tev je zato neuˇcinkovita, draga in neoptimalna [49].
Tovrstne teˇzave je reˇsil pojav virtualizacije (angl. hardware-based virtu- aliztaion). Kljuˇcna tehnologija, ki omogoˇca virtualizacijo je hipervizor. To je nizkonivojski program, ki skrbi za prevajanje zahtevkov med virtualnimi raˇcunalniki in strojno opremo [63]. Virtualizacija je tako omogoˇcila vzposta- vitev veˇc virtualnih raˇcunalnikov (Virtual Machine - VM) na enem samem fiziˇcnem streˇzniku. Takˇsen pristop moˇcno izboljˇsa varnost, saj vsaka apli- kacija biva v svojem izoliranem okolju brez dostopa do informacij ostalih
1
aplikacij. Prav tako virtualizacija reˇsi problem dodeljevanja virov, saj lahko VMjem dinamiˇcno, glede na trenutne potrebe gostujoˇce aplikacije, dodelju- jemo vire [61] [33].
V zadnjem ˇcasu je vse bolj popularna tudi virtualizacija na osnovi vsebni- kov (angl. container-based virtualization). Takˇsen pristop ne zahteva hiper- vizorja, saj vsebniki uporabljajo gostiteljevo jedro (angl. kernel). Ta lastnost sicer prepreˇcuje, da bi znotraj vsebnika poganjali drugaˇcen operacijski sis- tem, kot ga ima gostitelj, ima pa kar nekaj prednosti. Omogoˇca veliko bolj uˇcinkovito rabo streˇzniˇskih virov in manjˇse instance, ki se bistveno hitreje odzivajo na vklope in izklope kot VMji. ˇSe vedno pa ohrani veˇcino dobrih lastnosti VMjev, varno upravljanje in izolacijo ter enostavno migracijo med razliˇcnimi ponudniki (angl. vendors) [49] [33] [61].
Najbolj znana tehnologija za izvajanje vsebnikov, je Docker1, ki omogoˇca enostavno postavitev aplikacij v vsebnikov v razvojnem oziroma zgodnje produkcijskem okolju. Ko pa aplikacija zraste in se poveˇca kompleksnost upravljanja, pa lahko pri upravljanju poseˇzemo po enem izmedorkestratorev vsebnikov, med katerimi je najbolj znan Kubernetes2 [23].
Ker so lahko sodobne aplikacije sestavljene iz nekaj 10 ali pa celo veˇc kot 100 razliˇcnih komponent, hkrati pa lahko zaradi velike koliˇcine prometa ali ˇzelje po veˇcji zanesljivosti poganjamo veˇc instanc posameznih komponent, lahko kot upravljavci infrastrukture hitro pridemo do stanja, ko moramo upravljati z mnoˇzico naprav, na katerih ˇzelimo postaviti posamezne kompo- nente aplikacije, jih nastaviti in nato vzdrˇzevati. Ker takˇsni postopki vsebu- jejo veliko koliˇcino ponavljajoˇcih se nalog, se naravno pojavi potreba poavto- matizaciji posameznih nalog. Zaradi pojava kompleksnejˇsih aplikacij, katerih razliˇcne komponente teˇcejo na razliˇcnih platformah in razliˇcnih tehnologijah, pa sama avtomatizacija ne zadoˇsˇca, zato upravljavci obiˇcajno poseˇzemo tudi po orodjih za orkestracijo [22]. Pojem orkestracije tako zdruˇzuje razliˇcne prakse, ki skrbijo za postavitev in konfiguracijo naprav na razliˇcnih platfor-
1https://www.docker.com/
2https://kubernetes.io/
Diplomska naloga 3 mah.
Pri preprosti avtomatizaciji si lahko pomagamo s skriptami v lupini (angl.
Shell Scripts), v katerih naˇstejemo ˇzelene ukaze, pri kompleksnejˇsih nalogah pa je veliko laˇzje poseˇci po namenskih orodjih, med katerimi je na podroˇcju upravljanja (oblaˇcne) infrastrukture najbolje priljubljeno orodje Ansible3, ki se pogosto uporablja tudi za avtomatizacijo nalog v okviru orkestracije. Av- tomatizacija z Ansiblom je izjemno preprosta, uporabnik mora zgolj naˇsteti seznam naprav, ki bi jih rad upravljal, in nadeklarativni naˇcin opisati ˇzeleno stanje naprav, za dejansko uresniˇcitev uporabnikovih ˇzelja pa nato s pomoˇcjo ˇstevilnih razˇsiritev, imenovanih moduli, poskrbi Ansible.
Ansible ekosistem vsebuje ˇze pripravljene module za podporo praktiˇcno kakrˇsnekoli oblaˇcne infrastrukture, vendar pa vsi moduli niso narejeni naj- bolje. Modul, ki sledi dobrim praksam, mora biti specializiran, tj. avto- matizirati zgolj eno nalogo, prav tako pa mora intimno poznati podrobnosti delovanja APIja, preko katerega upravlja infrastrukturo. ˇCe temu ni tako, se naloga zagotavljanja pravilne uporabe APIja prenese na uporabnika, kar oteˇzuje uporabo orodja Ansible, uporabnik pa je obsojen na poglobljen ˇstudij dokumentacije platforme, ki bi jo rad avtomatiziral. Primer modula, ki ne sledi dobrim praksam zasnove, je kubernetes.core.k8s4, preko katerega An- sible podpira postavljanje in upravljanje aplikacij s pomoˇcjo platforme Ku- bernetes. Ker je Kubernetes izjemno priljubljena platforma, bi bil dodatek modula ali zbirke za podporo Kubernetes, narejen glede na standarde in dobre prakse razvoja, vsekakor dobrodoˇsla pridobitev za Ansible skupnost.
Cilj te diplomske naloge je zasnova in implementacija zbirke Ansible mo- dulov, ki bodo pokrivali upravljanje nekaterih pogostejˇsih Kubernetes objek- tov. Moduli morajo biti zasnovani na takˇsen naˇcin, da bodo ˇze prek zasnove vmesnika uporabnika usmerjali k njegovi pravilni uporabi. Vsebovati mo- rajo moˇcno validacijo vhodnih parametrov, hkrati pa morajo uporabniku prepreˇciti kreiranje kakrˇsnihkoli neveljavnih objektov. Celotna zbirka mora
3https://www.ansible.com/
4https://github.com/ansible-collections/kubernetes.core
biti tudi dobro dokumentirana. Z razvojnega vidika morajo biti moduli za- snovani tako, da jih bo enostavno vzdrˇzevati in razvijati tudi v prihodnosti, koda pa mora biti dobro pokrita s testnimi primeri, ki se morajo periodiˇcno samodejno izvajati.
V diplomski nalogi bomo najprej v poglavju 2 podrobneje predstavili platformo Kubernetes, nato bomo v poglavju 3 predstavili orodje za avto- matizacijo Ansible. Sledilo bo poglavje 4, ki razlaga ˇsirˇso sliko za integra- cijo uporabe orodja Ansible za upravljanje platforme Kubernetes, v katerem bomo predstavili dva primera uporabe te integracije, upravljanje heteroge- nih aplikacij in pisanje Kubernetes Operatorjev, zakljuˇcili pa z utemeljitvijo razlogov za razvoj nove Ansible zbirke. Konˇcno bomo v poglavju 5 predsta- vili naˇcrtovanje in razvoj nova Ansible zbirke, v poglavju 6 pa podrobnosti implementacije, teˇzave in rezultate konˇcnega testiranja.
Poglavje 2
Opis platforme Kubernetes
Kubernetes1 je odprtokodna platforma za orkestracijo vsebnikov. Ime ’Ku- bernetes’ izhaja iz grˇsˇcine in pomeni ladijski krmar. Pogosto se uporablja okrajˇsava k8s, ki je izpeljana iz dejstva, da je beseda Kubernetes sestavljena iz ˇcrk k, s in 8 ostalih ˇcrk med njima [49].
Orkestriranje vsebnikov s Kubernetes ima kar nekaj lepih lastnosti. Apli- kacije definiramo deklarativno, kar pomeni, da opiˇsemo ˇzeleno stanje, sis- tem pa nato poskrbi, da se naˇs naˇcrt uresniˇci. Platforma poleg orkestracije vsebnikov omogoˇca tudiorkestracijo diskov, skrbi zamreˇzne komunika- cije, saj samodejno dodeljuje IP naslove in DNS oznake. Ima svoj sistem za upravljanje z varnostno obˇcutljivimi podatki in konfiguracijami (angl. Se- crets and Configuration Management), kar omogoˇca deljenje konfigu- racij in tudi naknadno spreminjanje konfiguracije ˇze obstojeˇcim in delujoˇcim vsebnikom. Zanimiva je tudi sposobnost zdravljenja (angl. self-healing), samodejno primerjanje dejanskega stanja z ˇzelenim stanjem in nadomestilo zaustavljenih vsebnikov. Pomembna lastnost za zagotavljanje visoke raz- poloˇzljivosti (HA) pa je postopna nadgradnja instanc (Rollout) v primeru nadgradnje aplikacije na novo verzijo in avtomatsko vrnitev na prejˇsnjo ver- zijo (Rollback) v primeru napak, kar pa lahko naredimo tudi roˇcno [32].
1https://kubernetes.io/
5
2.1 Kratka zgodovina
Zametki projekta Kubernetes so se zaˇceli kazati, ko so pri Googlu2 leta 2003 zaˇceli z razvojem internega orodja za upravljanje vsebnikov, imenovanjega Borg. Zamislili so si ga kot eno platformo, na kateri bi lahko poganjali tako aplikacije (angl. long-running services) kot tudi opravila (angl. batch jobs).
Z zdruˇzitvijo je bila doseˇzena veˇcja uporaba virov, saj se lahko opravila izvajajo takrat, ko aplikacije niso preveˇc obremenjene. Zaradi postopnega razvoja in dodajanja novih orodji glede na trenutne potrebe je Borg postal precej kompleksno heterogeno orodje, zato so leta 2013 na podlagi preteklih izkuˇsenj razvili sistem Omega, ki je bil ˇse vedno miˇsljen za interno rabo. Leta 2014 so nato javnosti predstavili Kubernetes, ki je sicer nastal kot platforma za Googlov javni oblak, vendar pa je bil projekt ˇze od zaˇcetka odprtokoden, pri razvoju pa so sodelovala tudi druga podjetja. Leta 2015 je Google projekt prepustil fundaciji Cloud Native Computing Foundation (CNCF)3, ki zanj skrbi ˇse danes [10] [18].
2.2 Arhitektura
Z namenom boljˇsega razumevanja zasnove platforme Kubernetes bomo v tem poglavju predstavili pomembnejˇse arhitekturne komponente, ki sestavljajo platformo.
Gruˇca Kubernetes gostuje na enem ali veˇc vozliˇsˇcih (angl. Node).
Vozliˇsˇce je lahko VM ali fiziˇcni streˇznik, na katerem pa gostujejo stroki.
2.2.1 Komponente na kontrolni ravnini
Kontrolno raven (angl. Control Plane) sestavljajo komponente, ki upravljajo z gruˇco Kubernetes in skrbijo za globalne operacije. Mednje sodijo kube API streˇznik(angl. kube-apiserver), ki lahko sprejema tako zahtevke osta-
2https://about.google/
3https://landscape.cncf.io/
Diplomska naloga 7 lih k8s komponent znotraj gruˇce, kot zunanje zahtevke, s katerimi uporab- niki postavljajo aplikacije na platformo in lahko spremljajo njihovo delova- nje. Etcd je porazdeljena podatkovna baza, tipa kljuˇc-vrednost (angl. key- value), ki jo k8s uporablja za shranjevanje stanja gruˇce. Razvrˇsˇcevalnik (angl. Kube-scheduler) je komponenta, ki razporeja stroke na prosta vozliˇsˇca.
Pri tem upoˇsteva vrsto parametrov, kot so poraba virov, lokalnost in neka- tere uporabniˇske zahteve. Upravljalec krmilnikov(angl. Kube-controller- manager) je komponenta, ki skrbi za vrsto kontrolnih procesov. Med njegove naloge spadajo spremljanje stanja infrastrukture v gruˇci, aplikacij in ostalih objektov. Zadnji objekt pa je Upravljalec oblaˇcnih krmilnikov (angl.
cloud-controller-manager), ki upravlja z gruˇco glede na potrebe ponudnika oblaka (angl. cloud provider) [11] [20].
2.2.2 Komponente znotraj vozliˇ sˇ c
Vsako vozliˇsˇce poleg podov gosti tudi nekaj posebnih procesov, ki skrbijo za delovanje gostujoˇcih aplikacij. Kubelet je agent, ki skrbi da vsi vseb- niki delujejo. Kube-proxy s pomoˇcjo mreˇznih pravil skrbi za usmerjanje mreˇzne komunikacije. Izvajalec vsebnikov (angl. Container Runtime) je komponenta, ki poganja vsebnike. Kubernetes lahko v tej vlogi uporablja katerokoli implementacijo, narejeno po specifikaciji CRI (angl. Container Runtime Interface). Do verzije v1.20 je Kubernetes kot privzetega izvajalca vsebnikov uporabljal Docker Engine4, ki sicer ne ustreza CRI specifikaciji in je za integracijo potreboval dodatno komponentno, imenovano Dockershim.
Kubernetes sedaj privzeto uporablja CRI-O runtime, ki je laˇzji saj je bil na- mensko razvit prav za k8s, pogosto pa se uporablja tudi Containerd [49] [47]
[13].
4https://www.docker.com/
2.2.3 Dodatki
Vsaka gruˇca Kubernetes vsebuje tudi implementacijoDNS streˇznika, razliˇcne Kubernetes distribucije pa pogosto dodajajo tudi druge komponente, ki obo- gatijo uporabniˇsko izkuˇsnjo. Med pogostejˇse dodatke sodijonadzorna ploˇsˇca (angl. dashboard) in nadzornik vsebniˇskih virov (angl. Container Reso- urce Monitoring)[49] [11].
2.3 Opis pomembnejˇ sih objektov
V tem poglavju bomo predstavili znaˇcilnosti nekaterih pomembnejˇsih objek- tov v Kubernetes ekosistemu, s katerimi opisujemo postavitev aplikacij na Kubernetes platformo.
Imenski prostor. Na gruˇci Kubernetes lahko naenkrat svoje aplikacije pre- izkuˇsa in postavlja veˇc inˇzenirjev, po moˇznosti tudi iz razliˇcnih ekip.
Seveda je treba poskrbeti, da dobi vsak svoj prostor na gruˇci, kjer lahko opravlja svoje delo, brez da bi pri tem oviral ostale. Temu namenu sluˇzi imenski prostor (angl. Namespace), ki razdeli gruˇco na veˇc domen.
Tako mora biti ime posameznega Kubernetes objekta unikatno zgolj znotraj njegovega imenskega prostora.
Strok (angl. Pod, ime se nanaˇsa na npr. ’pod of whales’ - strok kitov) je najmanjˇsa enota v Kubernetes ekosistemu. Obiˇcajno vsebuje en vseb- nik, lahko pa tudi veˇc, tipiˇcno strok z veˇc vsebniki gosti aplikacijske komponente, ki so zelo trdno povezane. Delijo si en IP naslov, prav tako lahko dostopajo do enakih podatkovnih nosilcev, razvrˇsˇcevalnik pa jih zagotovo razporedi na isto vozliˇsˇce. Uporabnik obiˇcajno ne definira direktno tega objekta, paˇc pa ga definira v okviru kakˇsnega komple- ksnejˇsega objekta (postavitev, postavitev s stanjem) [52] [11].
Pomnilniˇski objekti. Vsebniki so po definiciji brez stanja (angl. stateless), vendar pa doloˇcene aplikacije, kot so podatkovne baze, vseeno potrebu-
Diplomska naloga 9 jejo nekakˇsen naˇcin za bolj trajno shranjevanje podatkov. S tem name- nom se lahko v vsebnik priklopipodatkovni nosilec (angl. Volume).
Kubernetes okolje loˇci porabnika in ponudnika (angl. provisoner and consumer), saj ti dve strani obiˇcajno zasedajo razliˇcne osebe. Nosilec mora priskrbeti administrator gruˇce, ki to lahko naredi na statiˇcni ali dinamiˇcni naˇcin. Administrator lahko vnaprej pripravi nekaj trajnih nosilcev (angl. PersistentVolume), lahko pa z objektom tipa Po- datkovni razred (angl. StorageClass), doloˇci parametre nosilcev, ki se nato dodeljujejo samodejno. Uporabnik nato naredi Zahtevo po trajnem nosilcu(angl. PersistentVolumeClaim), ki ji nato ponudnik ugodi in uporabniku dodeli nosilec [53] [20].
Konfiguracijski objekti. Konfiguracija (angl. ConfigMap) in Skriv- nost (angl. Secret) sta objekta, katerih glavni namen je hranjenje in posredovanje konfiguracije aplikacijam. Delujeta podobno, objekt Skrivnost je, kot nakazuje ime, namenjen hranjenju obˇcutljivih podat- kov (gesla, digitalna potrdila ipd.), objekt Konfiguracija pa se lahko uporablja za vse ostale spremenljivke. V vsebnike ju lahko priklopimo kot nosilec (angl. volume), tako se vrednosti spremenljivk preslikajo v vsebino datoteke, kar je uporabno za prenaˇsanje varnostno obˇcutljivih datotek, kot so npr. digitalna potrdila, kljuˇci ipd. ali pa kot niz okolj- skih spremenljivk [54] [50].
Postavitev (angl. Deployment) je glavni objekt za upravljanje aplikacij brez stanja skozi celotno ˇzivljenjsko dobo. Preko njega definiramo ˇzeleno postavitev aplikacije, jo nadgradimo na novo verzijo (angl. rol- lout) ali v primeru teˇzav vrnemo na prejˇsnjo verzijo (angl. rollback).
Vse te operacije nevidno izvajaupravljalec postavitev(angl. deplo- yment controller), ki hkrati tudi poskrbi, da se okvarjeni strok zamenja z novim in tako preko sistema zdravljenja ohranja ˇzeleno stanje [11].
Postavitev s stanjem (angl. StatefulSet) je objekt, podoben postavitvi, ki pa je namenjen aplikacijam, ki morajo hraniti stanje. Vsak strok
ima t.i. ’lepljivo identiteto’ (angl. sticky identity) in med sabo niso zamenljivi, prav tako pa ima vsak strok lahko svoj podatkovni nosilec.
Posodobitve se izvajajo po vrsti [57].
Storitev. Aplikacijo obiˇcajno sestavlja veˇc (enakovrednih) strokov. Vsak strok ima svoj IP naslov, prav tako pa strok ni stalen objekt, krmil- nik postavitev jih po potrebi briˇse in postavlja nove, kar predstavlja svojevrsten izziv za poˇsiljanje zahtevkov strokom. Pri tem pride prav storitev (angl. Service), ki ima stalen IP naslov, sprejema zahtevke in jih inteligentno poˇsilja strokom. Le te dinamiˇcno odkriva s pomoˇcjo t.i. selektorjev. ˇCeprav lahko storitev izpostavi IP tudi izven gruˇce, je njena primarna vloga sprejemanje notranjih zahtevkov [55].
Vhod (angl. Ingress) je namenjen sprejemanju tako HTTP kot HTTPS zahtevkov, ki prihajajo od odjemalcev izven gruˇce. S tem objektom definiramo pravila za usmerjanje, ki jih nato izpolnjuje vhodni kr- milnik (angl.Ingress Controller). Implementacija vhoda in vhodnega krmilnika se razlikuje med razliˇcnimi distribucijami in ponudniki plat- forme Kubernetes [51].
2.4 Poslovni modeli
Kubernetes lahko postavimo sami na praktiˇcno poljubni infrastrukturi, po- nujajo pa jo tudi ˇstevilni ponudniki storitev oblaˇcnega raˇcunalniˇstva. V tem poglavju si bomo pogledali prednosti in slabosti uporabe lastne Kubernetes gruˇce in jih primerjali z uporabo infrastrukture v gostovanju.
2.4.1 Na lastni infrastrukturi
Ker je Kubernetes odprtokodna platforma, prav tako je odprtokodnih veliko distribucij, ga lahko uporabniki gostijo sami, na svojih lastnih streˇznikih, vendar pa je za to potrebnega kar nekaj znanja [16] [5]. ˇZe namestitev same platforme ni enostavno opravilo, saj platforma Kubernetes ni monolit, ampak
Diplomska naloga 11 pester nabor razliˇcnih komponent, ki delujejo precej neodvisno druga od druge. To dejstvo oteˇzuje tudi nadzor, nadgradnje in nasploh razumevanje delovanja gruˇce [9].
2.4.2 Gostovanje
Kubernetes je tehnologija, ki jo v razliˇcnih oblikah in distribucijah ponujajo prav vsi velikani oblaˇcnega raˇcunalniˇstva [56]. Med najbolj priljubljenimi [5]
so Google Kubernetes Engine (GKE)5, Amazon Elastic Kubernetes Service (Amazon EKS)6, Azure Kubernetes Service (AKS)7 in IBM Cloud Kuberne- tes Service8. Upravljan (angl. managed) Kubernetes obiˇcajno uvrˇsˇcamo v kategorijo IaaS [30], nekateri pa kar v novo kategorijo CaaS (angl. Container as a service), saj Kubernetes odlikuje enostavnost uporabe, ki jo obiˇcajno sreˇcamo pri modelu PaaS, hkrati pa jo lahko moˇcno prilagodimo in preo- blikujemo glede na lastne potrebe, kot to lahko poˇcnemo z modelom PaaS [14].
5https://cloud.google.com/kubernetes-engine/
6https://aws.amazon.com/eks/
7https://azure.microsoft.com/en-gb/services/kubernetes-service/
8https://www.ibm.com/cloud/kubernetes-service
Poglavje 3
Predstavitev orodja Red Hat Ansible
Red Hat Ansible1je odprtokodno orodje za avtomatizacijo, ki ga lahko upora- bljamo za upravljanje konfiguracij, postavljanje aplikacij in upravljanje obla- kov. Ime je dobilo po fiktivni napravi, ki lahko poˇsilja sporoˇcila s hitrostjo, veˇcjo od hitrosti svetlobe [59]. Kot orodje z najveˇcjim trˇznim deleˇzem med orodji za upravljanje konfiguracij ima podporo velike skupnosti, zaupajo pa mu tudi ˇstevilni velikani, med drugim Intel, Cisco in Verizon [3].
Ansible je enostavno orodje, ki na ciljnih napravah (angl. remote host) ne nameˇsˇca agentov. V zaˇcetkih so bile te naprave primarno virtualni raˇcunalniki, do katerih, je orodje dostopalo preko povezave SSH2, danes pa lahko z njim avtomatiziramo tudi vse od vsebnikov, mreˇzne infrastrukture in raznih IaaS platform [7].
Ansible sledi deklarativnemu principu definicije infrastrukture kot kode (IaC), tako uporabnik namesto niza ukazov infrastrukturo upravlja preko opisa ˇzelenega stanja, ki ga potem platforma realizira. [7] [2]. Iz tega razloga razvijalci Ansible modulov stremijo k idempotentni implementaciji, kar po- meni, da bodo rezultati izvajanja Ansible skript vedno enaki ne glede na to,
1https://www.ansible.com/
2https://www.ssh.com/academy/ssh
13
kolikokrat je bila skripta pognana. Zaradi te lastnosti lahko s poganjanjem Ansible skripte preprosto preverimo, ˇce ima infrastruktura tako stanje, kot smo si ga zamislili brez strahu, da na kakrˇsenkoli naˇcin spreminjali infra- strukturo.
3.1 Osnovni koncepti
V tem poglavju bomo predstavili in razloˇzili pomembnejˇse koncepte v Ansible ekosistemu.
Kontrolna naprava (angl. Control node) je raˇcunalnik, ki ima nameˇsˇcen Ansible in izvaja ukaze ali Ansible skripte. Vlogo kontrolne naprave ima lahko poljuben raˇcunalnik z namaˇsˇcenim sistemom Linuxom ali MacOS, Windows naprave pa lahko nosijo to vlogo zgolj s pomoˇcjo WSLja3 [34] [37].
Ciljne naprave (angl. Managed nodes, tudi remote hosts) so naprave, ki jih Ansible upravlja. Ansibla na njih ni potrebno nameˇsˇcati, morajo pa imeti nameˇsˇcen Python [34].
Inventar (angl. Inventory) je seznam oddaljenih ciljnih naprav, ki jih ˇzelimo avtomatizirati. Navedemo jih preko domenskih imen ali IP naslovov.
Inventar podpira razvrˇsˇcanje ciljnih naprav na skupine, znotraj teh pa lahko definiramo tudi dodatne spremenljivke [38].
Modul (angl. module) je osnovna enota kode, ki jo Ansible lahko izvede [34].
Je samostojna implementacija algoritma spisanega npr. v Pythonu, s pomoˇcjo katere Ansible poskrbi, da se ˇzeleno stanje infrastrukture re- alizira. Ukazi se izvajajo na ciljnem sistemu, ki je obiˇcajno oddaljena ciljna naprava (angl. remote host), lahko pa tudi lokalno (angl. local- host) ali preko interakcije z APIjem. Modul definira vmesnik, sprejme
3https://docs.microsoft.com/en-us/windows/wsl/about
Diplomska naloga 15 argumente in vrne povratno informacijo preko objekta JSON na stan- dardni izhod [42].
Vsak modul je specializiran, tj. opravlja zgolj neko specifiˇcno nalogo, npr. poskrbi, da je virtualni raˇcunalnik priˇzgan, da je neka datoteka prisotna na ciljnem sistemu itd. [34]. Veˇcina modulov je idempoten- tnih, tj. rezultat enega klica je enak, kot ˇce bi modul uporabili veˇckrat in naj ne bi izvajali sprememb v primeru, da je trenutno stanje ˇze enako ˇzelenemu. ˇCeprav je jezik implementacije modulov poljuben, jih je veˇcina napisanih v jeziku Python [39].
Naloga (angl. task) je osnovna akcijska enota v Ansiblu. Z njo izberemo modul, ki ga ˇzelimo uporabiti in mu podamo parametre [34].
Skripta (angl. playbook) je urejen seznam nalog, napisan z jasno sintakso, ki temelji na jeziku YAML. [34]. Poleg nalog lahko v njej definiramo ciljne naprave, dodatne spremenljivke, uvozimo druge skripte ali defi- niramo oddaljenega uporabnika (angl. remote user) [44].
Vloga. Ansible modul je sposoben opraviti eno nalogo, dostikrat pa je ˇzeleno stanje kompleksnejˇse in ga ne moremo zagotoviti zgolj prek enega mo- dula z eno nalogo. V primeru specializiranih stanj si pomagamo s skripto, ˇce pa gre za uveljavitev nekega bolj sploˇsnega stanja, s katerim se pogosto sreˇca veliko uporabnikov (npr. zagotovitev, da je podat- kovna baza postavljena, paket pip prisoten na ciljnem sistemu ipd.), pa si pomagamo z vlogami (angl. Roles) [28]. Vloge med drugim vse- bujejo seznam nalog, ki so potrebne za zagotovitev stanja, privzete vrednosti spremenljivk, ki jih Ansible uporabi v primeru, da ne defini- ramo svojih, datoteke in predloge (angl. templates), ki se prenesejo na ciljne naprave. Vloge nato uporabimo v okviru skript [45].
Zbirka (angl. Ansible Collection) je distribucijski format, v katerem so lahko zapakirane skripte, moduli, vloge in druge Ansible vsebine [36].
Tipiˇcna zbirka vsebuje Ansible vsebine, ki so povezane z avtomatizacijo
neke platforme oz. tehnologije. Tako npr. zbirka community.docker4 vsebuje module, ki jih uporabnik potrebuje za avtomatizacijo tehnolo- gije Docker.
3.2 Namestitev in distribucija vsebin
Ker je Ansible orodje, ki ga uporablja ˇsirok spekter razliˇcnih uporabnikov, ki imajo razliˇcne potrebe in ˇzelje, ponuja Red Hat veˇc razliˇcnih paketov namestitve glede na ˇzeljeno koliˇcino vkljuˇcenih vsebin. V tem poglavju bomo naˇsteli namestitvene pakete in ostale distribucijske kanale.
3.2.1 Paket ansible-core
Jedrni paket (angl. Ansible Core) vsebuje minimalno potrebno za avtoma- tizacijo z Ansiblom. Vsebuje Ansible jezik, izvajalnik kode (angl. runtime) in nekaj osnovnih modulov. Namestimo s pomoˇcjo orodja pip z ukazompip install ansible-core. Koda paketa ansible-core, ki jo vzdrˇzuje Ansible Core ekipa, je dostopna na GitHubu5.
3.2.2 Paket skupnosti
Ansible paket skupnosti (angl. Ansible Community Package) vsebuje An- sible Core in zbirke, ki jih je napisala Ansible skupnost (angl. Community Collections). Vsaka izmed zbirk ima svojega skrbnika, ki jo vzdrˇzuje, koda pa je shranjena v namenskem repozitoriju na GitHubu. Razen tega mora vsaka zbirka zadostiti strogim pogojem, ˇce ˇzeli biti del Community paketa.
Paket skupnosti prav tako namestimo z orodjem pip z ukazompip install ansible[4].
4https://docs.ansible.com/ansible/latest/collections/community/docker/
5https://github.com/ansible/ansible
Diplomska naloga 17
3.2.3 Ansible Galaxy
Tretji naˇcin za deljenje in inˇstalacijo Ansible vsebin je Ansible Galaxy. To je portal, kamor lahko vsak objavi svoje vloge ali zbirke, uporabniki pa jih lahko nato prenaˇsajo in nameˇsˇcajo preko namenskega CLI orodjaansible-galaxy.
[8].
3.2.4 Komercialni distribucijski kanali
Vsi trije zgoraj opisani kanali za distribucijo vsebin so del community pa- keta, obstaja pa tudi verzija za komercialne uporabnike imenovana Ansible Automation Platform6, preko katere dobijo podjetja certificirane Ansible vsebine skupaj s podporo.
6https://www.ansible.com/products/automation-platform
Poglavje 4
Avtomatizacija Kubernetes
Kubernetes je platforma za orkestracijo vsebnikov, ki avtomatizira marsika- tero opravilo, povezano z upravljanjem vsebnikov. Obstajajo tudi Ansible zbirke za namestitev Kubernetes platforme na streˇznike. Zakaj bi bilo kori- stno s pomoˇcjo Ansibla avtomatizirati postavitev aplikacij na Kubernetes? V tem poglavju bomo predstavili ozadje avtomatizacije namestitve aplikacij na Kubernetes z Ansiblom in utemeljili potrebo po razvoju nove Ansible zbirke.
4.1 Upravljanje heterogenih aplikacij
Podroˇcje oblaˇcnega raˇcunalniˇstva je v zadnjem ˇcasu doˇzivelo hiter razvoj in sploˇsno priljubljenost, saj za ˇstevilne organizacije predstavlja nepogreˇsljiv del njihove IT infrastrukture [19]. Po drugi strani pa smo priˇca naglemu vzponu interneta stvari (IoT), kar prinaˇsa enormno ˇstevilo novih naprav v t.i. rob- nem raˇcunalniˇstvu (angl. edge computing) [31]. Takˇsna arhitektura prinaˇsa svojevrsten izziv, saj prinaˇsa potrebo po veˇcnivojskem upravljanju aplikacij, sestavljenih iz mnogih komponent na zelo razliˇcnih tipih infrastrukture [22].
Kako postaviti in upravljati aplikacijo, ki je porazdeljena med veˇc gruˇcami Kubernetes na razliˇcnih lokacijah ali celo deloma na Kubernetes platformi, deloma pa na kakˇsni drugi tehnologiji?
19
4.1.1 Federacija k8s gruˇ c
Federacija k8s gruˇc (angl. Kubernetes Federation) je tehnologija, ki omogoˇca postavitev in upravljanje aplikacije na veˇc razliˇcnih Kubernetes gruˇcah. [1].
Obstaja veˇc projektov, ki se ukvarjajo s tem problemom, najbolj razvit pa je KubeFed V2, ki postavi veˇc komponent, med drugim federacijski API streˇznik (angl. Federation API Server) in federacijski krmilnik (angl. Fede- ration Controller), preko katerih upravlja gruˇco gruˇc prekodefinicije posebnih Kubernetes objektov (CRD). Projekt je trenutno v beta fazi razvoja [21].
Tak pristop je povsem sprejemljiv za upravljanje aplikacij, kjer je na vseh gostiteljih postavljena gruˇca Kubernetes, vendar za heterogene aplika- cije to velikokrat ni dovolj, saj lahko del aplikacije teˇce tudi na infrastrukturi, kjer ne moremo namestit gruˇce Kubernetes, npr. na javnem oblaku ali su- perraˇcunalniku (HPC) [22].
4.1.2 TOSCA pristop
TOSCA je OASIS standard za opisovanje postavitve in upravljanje poraz- deljenih aplikacij na deklarativen naˇcin [6]. Zadnja verzija (1.3) uporablja YAML, prva verzija je bila napisana v jeziku XML [27]. Kljuˇcni pojmi za opis postavitve so predloga topologije (angl. Topology Template), predloga vozliˇsˇca (angl. Node Template) in predloga relacije (angl. Relationship Template). Predloga topologije opiˇse topologijo aplikacije s pomoˇcjo predlog vozliˇsˇc in relacij. Predloga vozliˇsˇca lahko predstavlja tako infrastrukturni re- surs kot aplikacijsko komponento (npr. VM ali podatkovno bazo), predloge relacij pa opisujejo relacije med vozliˇsˇci. Relacije lahko pomenijo gostovanje (podatkovna baza gostuje na VM), odvisnost (API streˇznik je odvisen od podatkovne baze) itd.[29].
TOSCO so razvili z namenom opisa postavitev in upravljanja aplikacij v oblaku neodvisno od ponudnika (angl. vendor-agnostic). TOSCA omogoˇca enostavno dodajanje novih tipov vozliˇsˇc in relacij, kar pripomore k univer- zalnosti rabe [22].
Diplomska naloga 21 Za realizacijo opisane oblaˇcne arhitekture potrebujemo namensko vme- sno opremo (angl. middleware) imenovanoorkestrator. Razliˇcni orkestratorji lahko realizirajo operacije (postavitev oblaˇcne aplikacije, odstranitev, konfi- guracija) s pomoˇcjo poljubnega programskega jezika [22]. Poglejmo si nekaj orkestratorjev in njihovih pristopov pri upravljanju s Kubernetes s pomoˇcjo jezika TOSCA.
Cloudify
Cloudify1 je odprtokoden orkestrator, ki omogoˇca upravljanje najrazliˇcnejˇse infrastrukture z uporabo jezika Cloudify DSL, ki temelji na standardu TO- SCA. Operacije realizira s pomoˇcjo vtiˇcnikov, ki so lahko namenjeni posame- znim oblaˇcnim ponudnikom (AWS, Azure, GCE), platformam (K8s, Open- Stack) ali pa poveˇzejo Cloudify z drugimi orodji za avtomatizacijo (npr. z Ansiblom). Vtiˇcniki so napisani v jeziku Python, ˇstevilni so uradno podprti, lahko pa jih razvijemo tudi sami [27].
Cloudify je zmogljiva reˇsitev za orkestracijo, vendar nas dejstvo, da upo- rablja lasten dialekt TOSCE (Cloudify DSL), zapre v njegov ekosistem (angl.
vendor lock-in). Delna reˇsitev za izognitev zapori je uporaba Ansible skript za realizacijo, ki jih lahko v Cloudify priklopimo preko uradno podprtega vtiˇcnika.
Turandot
Turandot2 je odprtokoden orkestrator, namensko razvit za postavljanje apli- kacij na Kubernetes gruˇce. Uporablja uradni dialekt TOSCE (verzijo 1.3), pri obdelavi pa si pomaga s Puccinijem3, ki TOSCO pretvori v vmesni for- mat, imenovan Clout4, ki spominja na bazo grafov (angl. Graph Database).
Operacije se realizirajo s pomoˇcjo JavaScripta, preko vtiˇcnikov pa podpira tudi Ansible [25].
1https://cloudify.co/
2https://turandot.puccini.cloud/
3https://puccini.cloud/
4https://puccini.cloud/clout/
Turandot ima do neke mere sposobnost orkestracije heterogenih aplikacij, saj lahko poleg Kubernetes objektov postavlja tudi VMje s pomoˇcjo tehno- logije KubeVirt5. Ta reˇsitev sicer ni idealna, saj KubeVirt zgolj omogoˇci postavljanje VMjev na gruˇco Kubernetes, ne more pa upravljati VMjev po- ljubnega oblaˇcnega ponudnika. Sicer obetaven pristop je trenutno ˇse v zaˇcetni fazi razvoja, tako da doloˇcene funkcionalnosti ˇse niso podprte [26].
Ubicity
Ubicity Orchestrator6 je trˇzni orkestrator, ki ga razvija Ubicity. Uporablja osnovno TOSCO (verzija 1.3) z dodatkom nekaterih funkcionalnosti, ki bodo dodane v standard TOSCA 2.07 [24]. Sposoben je upravljati s ˇsirokim nabo- rom najrazliˇcnejˇsih arhitektur. Zaradi zaprte narave projekta o njem ni prav veliko znanega, prav tako ni znano, kako daleˇc so priˇsli z razvojem.
xOpera
xOpera8 je lahkoten odprtokodni TOSCA orkestrator, ki ga v okviru projek- tov RADON9 in SODALITE10 razvija slovensko podjetje XLAB11. Orodje sledi UNIX filozofiji12 opravljanja zgolj ene naloge, vendar te dobro. Za opis infrastrukture uporablja osnovno TOSCO (verzija 1.3), za izvedbo ope- racij pa se zanaˇsa na Ansible skripte in odliˇcno podprt Ansible ekosistem, kar ji kljub osnovni funkcionalnosti omogoˇca upravljanje praktiˇcno poljubne oblaˇcne infrastrukture [12].
Poleg osnovnih ukazov za postavitev (angl. deploy) in odstranitev (angl.
undeploy) oblaˇcne infrastrukture omogoˇca tudi posodobitev (angl. update), ki posodobi oblaˇcno infrastrukturo glede na novo TOSCA predlogo (angl.
5https://kubevirt.io/
6https://ubicity.com/
7https://docs.oasis-open.org/tosca/TOSCA/v2.0/TOSCA-v2.0.html
8https://github.com/xlab-si/xopera-opera
9https://radon-h2020.eu/
10https://www.sodalite.eu/
11https://www.xlab.si/sl/
12https://en.wikipedia.org/wiki/Unix philosophy
Diplomska naloga 23 TOSCA Service Template). Pri tem ne odstranjuje in postavlja celotne apli- kacije, paˇc pa postavi oz. odstrani samo spremenjene dele [62]. Takˇsna lastnost je precej uporabna pri dinamiˇcnem preoblikovanju aplikacije glede na spremenjene potrebe (angl. refactoring) [22].
xOpera je sicer razmeroma novo orodje, vendar se hitro razvija, uporablja pa se tudi v ˇstevilnih evropskih raziskovalnih projektih, kot so CYBERWI- SER, DICE, FORTIKA, RADON in SODALITE [27].
4.1.3 Vloga Ansibla
Kot smo videli ima Ansible pomembno vlogo v ˇstevilnih pristopih za orke- stracijo infrastrukture, postavljene na Kubernetes platformi. Pri orkestraciji z xOpero ima nenadomestljivo vlogo, lahko pa ga tudi uporabimo v kom- binaciji s Turandotom in Cloudifyjem in tako ohranjamo neodvisnost od orkestratorja. Zaradi velikega ekosistema, ˇstevilnih vsebin, ki jih podpira bodisi Red Hat direktno ali pa skupnost, lahko s pomoˇcjo Ansibla name- stimo in upravljamo poljubno heterogeno aplikacijo na poljubno oblaˇcno ali robno infrastrukturo.
4.2 Operatorji
Kubernetes je zelo zmogljiv sistem za upravljanje aplikacijbrez stanja (angl.
stateless). V primeru, da eden izmed podov takˇsne aplikacije pade v napako, ga Kubernetes krmilnik preprosto izbriˇse in postavi novega. Prav tako pre- prosto doda ali odstrani stroke, ˇce se odloˇcimo, da bi radi izvedli horizontalno skaliranje.
Pri upravljanju aplikacij s stanjem, npr. raznih podatkovnih baz, pa se sreˇcamo z dodatnimi teˇzavami. Bazo je potrebno ob postavitvi tudi nastaviti, ˇce kakˇsna instanca pade v napako, je potrebno ob postavitvi vanjo prenesti kopijo podatkov iz drugih instanc, prav tako je pri bazah, ki niso narejene za porazdeljeno delovanje (npr. nekatere baze tipa SQL), potrebno skrbeti za sprotno kopiranje podatkov in ohranjanje identiˇcnega stanja med instancami.
Takˇsne izzive lahko reˇsujemo s Kubernetes Operatorji [15].
Operator je aplikacija, ki jo postavimo na gruˇco Kubernetes z namenom, da skrbi za naˇso aplikacijo, pri ˇcemer si pomaga s poglobljenim znanjem o njenem delovanju [58]. Kubernetes operator lahko skrbi za avtomatsko ska- liranje zapletene aplikacije, nadgradnjo na novo verzijo ali celo upravljanje gonilnikov v gruˇci s specializirano strojno opremo, npr. v gruˇci z grafiˇcnimi karticami. Lahko si ga predstavljamo kot nekakˇsnega avtomatiziranega ad- ministratorja (angl. Site Reliability Engineer, SRE)[15].
4.2.1 Razvoj operatorjev
Razvoj Kubernetes operatorja na najniˇzjem nivoju pomenidefiniranje po- sebnih objektov(angl. Custom Resource Definition, CRD) v gruˇco skupaj z dodatnimi programi, ki bodo dejansko izvajali operacije operatorja. Se- veda v pomoˇc razvoju tako zapletenih objektov, kot so operatorji, obstaja celotno razvojno okolje, Operator SDK13, ki pomaga pri gradnji, testiranju in pakiranju k8s operatorjev.
V okviru okolja lahko razvijamo aplikacije na tri naˇcine, preko HELM Charts14, zAnsiblom ali pa v jeziku GO15.
Ansible je torej razmeroma enostaven naˇcin razvoja operatorjev, ki pred- stavljajo pomemben del Kubernetes ekosistema, kar vsekakor predstavlja do- datno motivacijo za razvoj Ansible vsebin za podporo Kubernetes.
4.3 Motivacija za razvoj nove zbirke
V prejˇsnjih sekcijah smo predstavili kar nekaj razlogov za integracijo Ansibla s platformo Kubernetes, kar pa ˇse ni zadosten pogoj za razvoj nove zbirke, saj Ansible zbirka za podporo Kubernetes ˇze obstaja. Ker motivacija za razvoj nove zbirke leˇzi v slabostih obstojeˇce, bomo predstavili lastnosti zbirke
13https://sdk.operatorframework.io/
14https://helm.sh/
15https://golang.org/
Diplomska naloga 25 kubernetes.core
4.3.1 Obstojeˇ ca zbirka
Ansible zbirkakubernetes.core16vsebuje kar nekaj modulov za avtomatiza- cijo Kubernetes, med drugim tudi modulkubernetes.core.k8s, ki sprejme definicijo poljubnega Kubernetes objekta in ga postavi na obstojeˇco Kuber- netes gruˇco. Zakaj bi torej razvijali novo zbirko?
Izkaˇze se, da obstojeˇci modul (kubernetes.core.k8s) krˇsi eno izmed temeljnih naˇcel razvoja Ansible vsebin, prevzeto po UNIXu: Naredi zgolj eno stvar, vendar to dobro. Vsak dobro napisan Ansible modul mora tako vsebovati ravno prav funkcionalnosti in logike. V tem duhu je tudi smiselno, da kompleksen API raje razbijemo na manjˇse kose in vsak kos podpremo z lastnim modulom [41].
Kubernetes.core.k8smodul krˇsi to konvencijo, saj Kubernetes API vse- buje veˇc kot 100 razliˇcnih objektov [48] in je seveda s tem prevelik, da bi ga podprli zgolj z enim modulom. Modul tako ne vsebuje prav veliko logike, kar je pri tako obseˇznem APIju seveda praktiˇcno nemogoˇce. Implementacijo obstojeˇcega modula za Kubernetes v trenutnem stanju bi ˇse najbolje opisali kot lahkotno ovojnico (angl. wrapper), ki zgolj sprejme YAML definicijo poljubnega Kubernetes objekta in ga poˇslje na API.
Vsakrˇsno znanje o objektu je s tem prepuˇsˇceno uporabniku. Uporab- nik mora poznati podrobnosti oblike objekta, ki ga ˇzeli avtomatizirati, prav tako mora poznati vse lastnosti posameznih polj in njihove podatkovne tipe.
Delno lahko takˇsno logiko uporabnik implementira v Ansible skriptah, ki pa seveda niso namenjene temu. Modul kubernetes.core.k8s sicer ima moˇznost validacije, ki pa je zgolj opcijska funkcionalnost, dosegljiva preko namestitve dodatne Python knjiˇznice kubernetes-validate, kar tudi ni ustrezno nadomestilo za validacijo vhodnih argumentov, ki jo izvajajo do- bro napisani Ansible moduli.
Kljub temu, da modul ni razvit po konvencijah razvoja, pa vseeno igra
16https://github.com/ansible-collections/kubernetes.core
pomembno vlogo v podpori platforme Kubernetes z orodjem Ansible. Tako vsaj obstaja nekakˇsen naˇcin, s katerim lahko upravljamo Kubernetes [60].
Kljub temu pa bi bila dobrodoˇsla nova zbirka, ki bi na boljˇsi naˇcin podprla vsaj pomembnejˇse k8s objekte.
Poglavje 5
Naˇ crtovanje in razvoj
V prejˇsnjih poglavjih smo predstavili platformo Kubernetes, orodje Ansi- ble in razloge za njuno integracijo. V naslednjih poglavjih se bomo lotili naˇcrtovanja in implementacije Ansible zbirke, ki bo poskrbela avtomatiza- cijo Kubernetes na pravi naˇcin. Naˇcrtovanje bomo zaˇceli s pregledom dobrih praks in smernic razvoja Ansible vsebin.
5.1 Smernice za razvoj Ansible zbirk
Eden izmed pomembnejˇsih ciljev te naloge je vsekakor implementacija An- sible zbirke visoke kakovosti, po najviˇsjih standardih in zadnjih smernicah razvoja Ansible vsebin. Pri implementaciji zbirke za podporo Kubernetes so relevantne predvsem smernice za razvoj Ansible zbirk in Ansible modulov, ki jih bo nova zbirka vsebovala.
5.1.1 Smernice razvoja Ansible modulov
Vsak Ansible modul mora imeti natanˇcno doloˇcen namen. Pri naˇcrtovanju moramo slediti UNIXovi filozofiji opravljanje zgolj ene stvari, vendar dobro.
Modul mora imeti jasno in dobro definirano funkcionalnost. Od uporabnika ne sme priˇcakovati globoko poznavanje APIja, ki ga upravlja, logiko delo- vanja mora poznati modul in pri tem preko zasnove vmesnika in validacije
27
usmerjati uporabnika. Prav tako je potrebno pri razvoju paziti, da modul ne opravlja dela, ki ga ˇze sedaj dobro opravljajo drugi moduli. Kopiranje kode ni zaˇzeleno, saj je tako kodo veliko teˇzje vzdrˇzevati [41].
Ansible podaja nekaj smernic za razvoj vmesnika modula. Parameter, preko katerega se objekt naslavlja, se mora imenovati name. Podatkovni tip booleanmora sprejemati takotrue infalsekot tudiyes inno. Pri razvoju te funkcionalnosti, v skladu z Ansible smernicami, pomaga razred Ansible- Module. Vsekakor pa se je potrebno izogibati parametrom, ki naznanjajo imperativno naravo modula, kot na primer action ali command. Moduli so po definiciji deklarativni, kar mora biti vidno tudi v vmesniku [41].
Vsak Ansible modul mora biti napisani v jeziku Python, vsebovati pa mora nekaj standardnih poglavji v toˇcno doloˇcenem vrstnem redu [43]:
• deklaracija pythonovega interpreterja in UTF-8 kodiranja (angl. Python shebang & UTF-8 coding), ki naznanja, da je besedilo v datoteki koda jezika Python, napisana z UTF-8 kodiranjem,
• avtorske pravice in licenca (angl. Copyright and license),
• blok z dokumentacijo (angl. DOCUMENTATION block), ki v formatu YAML na opiˇse modul, njegovo delovanje in vmesnik,
• blok s primeri (angl. EXAMPLES block) z nekaj osnovnimi primeri uporabe modula,
• in blok z vrnjenimi vrednostmi (angl. RETURN block), ki v sintaksi YAML opiˇse format izhodnih vrednosti, ki jih modul vrne po zakljuˇcku.
Obveznim meta-poglavjem sledi obiˇcajna koda v jeziku Python, v kateri je implementirano delovanje modula. Pomoˇc pri implementaciji nudi Python modul ansible.module utils.basic.AnsibleModule, ki pomaga pri pre- verjanju veljavnosti vhodnih parametrov, in vraˇcanju izhodnih vrednosti, tako v primeru uspeˇsnega zakljuˇcka kot tudi v primeru napak.
Namesto privzetega modula (AnsibleModule) se lahko uporablja tudiAn- sibleTurboModule, ki pohitri zaporedne interakcije pri modulih, ki ciljno
Diplomska naloga 29 infrastrukturo upravljajo preko APIjev. Obiˇcajno prvi korak uporabe APIja vkljuˇcuje povezovanje in avtorizacijo, kar lahko traja tudi nekaj sekund. Ker vsak modul v Ansible skripti odpre svoj proces, ki ga po zakljuˇcku zapre, mora vsak klic modula samostojno poskrbeti za povezovanje in avtorizacijo z APIjem. ˇCe imamo v skripti 10 nalog, ki izvajajo klice na isti API, vsaka pa potrebuje 2s za povezovanje in avtorizacijo, se zaradi tega ˇcas izvajanja po nepotrebnem poveˇca ˇze kar za 20 sekund. AnsibleTurboModule teˇzavo reˇsuje tako, da odpreprikrit proces (angl. daemon process), v katerem se poveˇze z APIjem. Proces ostane odprt, tako da ga lahko uporabi naslednji modul v naslednji nalogi, s ˇcimer se izognemo nepotrebnemu zapravljanju ˇcasa [46].
Pri implementaciji Ansible vsebin pa moramo biti pozorni tudi na pod- poro obeh veˇcjih verzij jezika Python, tako Python 2.x kot tudi Python 3.x, kar pa ni enostavno. Kljub temu, da je verzija 3.0 izˇsla ˇze leta 2008 in je fundacija Python s 1. januarjem 2020 odpovedala podporo verzijam 2.x [17], obstaja ˇse vedno veliko naprav, ki podpirajo zgolj Python verzije 2.x. Uradne Ansible smernice za to podroˇcje zapovedujejo, da mora vsak modul podpi- rati vsaj Python 2.6 in vsaj Python 3.5, vendar se lahko podpori Python verzije 2.x odpovemo v primeru, da je to storila katera od odvisnosti, ki jih uporabljamo v modulu.
Vsak modul moramo tudi dodobra pokriti s testi, s ˇcimer se bomo bolj podrobno ukvarjali v poglavju o Ansible zbirkah [40].
5.1.2 Smernice razvoja Ansible zbirk
Ansible zbirka (angl. collection) je glavni format za distribucijo Ansible vsebin. Zbirka naj bi zadostila neki skupini povezanih primerov uporabe [35]. Vsaka Ansible zbirka mora slediti predpisani strukturi, ki je prikazana na 5.1. V nadaljevanju bomo predstavili pomembnejˇse objekte.
Datoteka galaxy.yml
Galaxy.yml je datoteka, ki vsebuje informacije glede zbirke, med drugim ime, imenski prostor (angl. namespace), verzijo, avtorje, druge Ansible zbirke, od
Slika 5.1: Struktura Ansible zbirke.
katerih je naˇsa odvisna in oznake za laˇzje iskanje.
Dokumentacija
Direktorij z dokumentacijo opisuje delovanje in uporabo Ansible vsebin, ki jih vsebuje zbirka. Dokumentacija za zbirke, ki jih vzdrˇzuje skupnost, mora biti napisana v formatu reStrucutredText (.rst). Obiˇcajno vsebino te mape ne napiˇsemo sami, paˇc pa se avtomatsko napolni na podlagi dokumentacije posameznih Ansible vsebin, npr. modulov s pomoˇcjo namenskega orodja Collection Prep Engine1 [35].
1https://github.com/ansible-network/collection prep
Diplomska naloga 31 Testi
Pomemben element dobro napisane zbirke so tudi testi, ki se nahajajo v mapi tests/. Testiranje poskrbi, da koda dela, kot je priˇcakovano in je dobro integrirana z ostalimi elementi tako Ansible ekosistema kot ciljne in- frastrukture. Vsaka Ansible zbirka mora imeti teste smiselnosti (angl. sa- nity), teste enote (angl. unit), zaˇzeleni pa so tudi integracijski testi (angl.
integration). Testi smiselnosti so standardni, dobimo jih skupaj z Ansible distribucijo, vkljuˇcujejo pa ˇsirok nabor testov, od preizkusa kompatibilnosti s posameznimi podprtimi verzijami Pythona, do preverjanja ujemanja doku- mentacije z vmesnikom modula in ustreznosti kode standardu PEP-8. Testi enote preverjajo delovanje (pomembnejˇsih) funkcij v naˇsi zbirki. Razvijalec jih je dolˇzan razviti sam, nahajajo pa se v podmapi unit/. Tudi integra- cijske test spiˇse razvijalec sam in jih obiˇcajno implementira v obliki Ansible skript, v katerih uporablja nove module, hkrati pa na testni infrastrukturi preverja, ˇce so moduli realizirali stanje na objektih na toˇcno tak naˇcin, kot je bilo zamiˇsljeno.
Teste smiselnosti in enote poganjamo z ukazoma ansible-test sanity in ansible-test units. Pri implementaciji integracijskih testih pomaga uporaba namenskih orodji, npr. molecule2. V tem primeru tudi ni nujno, da se nahajajo v mapi tests/, pogosto so molecule testi v namenski mapi mo- lecule/. Molecule teste po predhodni namestitvi orodja poganjamo z ukazom molecule test.
5.2 Naˇ crtovanje nove zbirke
V prejˇsnjem poglavju smo predstavili smernice za razvoj Ansible zbirk, v tem poglavju pa bomo zasnovali novo zbirko, pri ˇcemer bomo poskusili upoˇstevati smernice prejˇsnjega poglavja. Predstavili bomo ozadje poimenovanja, primer testne aplikacije, ki jo ˇzelimo postaviti z novo zbirko in glede na testni pri- mer doloˇcili module, ki jih bomo implementirali v okviru zbirke in njihove
2https://github.com/ansible-community/molecule
vmesnike.
5.2.1 Motivacija in ime
Ker je motivacija za nastanek nove Ansible zbirke priˇsla iz potreb projekta SODALITE, bo poimenovana sodalite.k8s. Zbirka poskuˇsa pokriti potrebe projekta glede orkestracije infrastrukture.
Ker je Kubernetes API prevelik, da bi s sodalite.k8s zbirko pokrili celega, prav tako pa je potreb na projektu preveˇc, smo se odloˇcili, da implementiramo module, potrebne za postavitev ene izmed aplikacij platforme SODALITE na k8s gruˇco.
5.2.2 xOpera REST API
Aplikacija, ki smo jo izbrali kot primer uporabe (angl. use-case) je xOpera REST API. To je API, zgrajen okoli orkestratorja xOpera, prilagojen na potrebe projekta SODALITE. Poleg orkestratorja vsebuje tudi integracijo z GIT streˇznikom (obiˇcajno Gitlab), na katerem uporabniki shranjujejo TO- SCA naˇcrte, informacije glede infrastrukture, ki jo upravlja, pa se hranijo v podatkovni bazi.
Aplikacijo sestavljata dve ”dokerizirani”komponenti, xopera-rest-api, API streˇznik, implementiran v jeziku Python s connexionom na osnovi ope- nAPI specifikacije in PostgreSQL v vlogi podatkovne baze.
Za postavitev aplikacije na gruˇco Kubernetes potrebujemo naslednje objekte:
• xopera-namespace (k8s Imenski prostor (angl. Namespace)),
• xopera-storage-class (k8s Pomnilniˇski razred (angl. StorageClass)),
• PostgreSQL:
– postgres-secrets (k8s Skrivnost (angl. Secret)), obˇcutljiva konfi- guracija baze,
Diplomska naloga 33 – postgres-pvc (k8s Zahteva po trajnem podatkovnem nosilcu (angl.
PersistentVolumeClaim)), zahteva po trajnem disku baze, – postgress-deployment (k8s Postavitev (angl. Deployment)), – postgress-service (k8s Storitev (angl. Service))
• xOpera REST API:
– xopera-secrets (k8s Skrivnost (angl. Secret)), obˇcutljiv del konfi- guracije,
– xopera-config (k8s Konfiguracija (angl. ConfigMap)), neobˇcutljiv del konfiguracije,
– xopera-secret-tls (k8s Skrivnost (angl. Secret)), certifikat in kljuˇc za TLS,
– xopera-deployment (k8s Postavitev (angl. Deployment)), – xopera-service (k8s Storitev (angl. Service)),
– xopera-ingress (k8s Vhod (angl. Ingress))
Ce bi to aplikacijo postavljali v pravo produkcijsko okolje, bi verjetnoˇ PostgreSQL postavili kot operator, ker pa uporaba operatorjev ni predmet te diplomske naloge, smo primer nekoliko poenostavili in jo postavili kot objekt tipa Postavitev (angl. Deployment) s pripetim podatkovnim nosilcem (angl.
PersistentVolume). V tem primeru baze ne moremo horizontalno skalirati, postavimo pa lahko zgolj eno samo instanco.
5.2.3 Moduli
Za pokritje potreb postavitve aplikacije xOpera REST API na Kubernetes potrebujemo naslednje module:
sodalite.k8s.namespace
Modul, ki postavi Namenski prostor (angl. Namespace), v katerega lahko nato postavimo aplikacijo. Ta modul ni nujno potreben za postavitev testne
aplikacije, ker bi lahko aplikacijo postavili tudi v privzet namenski prostor, vendar lahko pride prav na gruˇcah s ˇstevilnimi uporabniki iz razliˇcnih ekip.
sodalite.k8s.storage class
Kot smo omenili v poglavju 2.3, v Kubernetes okolju obstajata dva naˇcina za upravljanje s pomnilnikom, za implementacijo smo izbrali dinamiˇcni naˇcin.
Objekt tipa Pomnilniˇski razred (angl. StorageClass) je torej administratorski konec dinamiˇcnega dodeljevanja Trajnih podatkovnih nosilcev (angl. Persis- tantVolume).
sodalite.k8s.pvc
Pvc je okrajˇsava za PersistantVolumeClaim oziroma Zahtevo po trajnem po- datkovnem nosilcu, ki predstavlja uporabniˇski konec dinamiˇcnega dodeljeva- nja trajnih nosilcev. Za okrajˇsavo pri poimenovanju modula smo se doloˇcili, ker je v Ansible ekosistemu zaˇzeleno ˇcim bolj preprosto poimenovanje objek- tov, kratica pvc pa se tako ali tako pogosto uporablja tudi v Kubernetes svetu.
sodalite.k8s.config map
Objekt Konfiguracija (angl. ConfigMap) v testnem primeru potrebujemo za
referenco napostgres-service, ki jo potem podamo komponentixopera-rest-api.
sodalite.k8s.secret
Objekt Skrivnost (angl. Secret) je podoben objekt, kot Konfiguracija, ven- dar je namenjen hrambi obˇcutljivih podatkov. V testnem primeru ga upo- rabljamo za prenaˇsanje poverilnic (angl. credentials) za dostop do baze, poverilnic za povezavo na GitHub in hranjenje digitalnih potrdil za objekt tipa vhod (angl. Ingress).
Diplomska naloga 35 sodalite.k8s.deployment
Postavitev (angl. Deployment) je glavni objekt, s katerim na gruˇce Kuberne- tes postavljamo aplikacije. Objekt je orjaˇski, tako da v okviru te diplomske naloge ne bomo pokrili vseh moˇznosti, ki jih ponuja, paˇc pa zgolj tiste, ki jih potrebujemo za postavitev testne aplikacije in nekaj dodatnih parametrov, za katere obstaja velika verjetnost, da se bodo pojavili v kakˇsnem podobnem, sploˇsnem primeru uporabe tega modula.
sodalite.k8s.service
Objekt tipa Storitev (angl. Service) v testnem primeru uporabljamo, da lahko ostale komponente naslavljajo mnoˇzico strokov, ki poganjajo aplikacijo.
sodalite.k8s.ingress
Vhos (angl. Ingress) omogoˇci dostop do aplikacije od zunaj. Pri testnem primeru ga uporabljamo, da odpremo dostop do komponente xopera-rest-api od zunaj. Prav tako deluje kot namestniˇski streˇznik za zakljuˇcek ˇsifrirne povezave (angl. TLS Termination Proxy), ki omogoˇci uporabo protokola HTTPS.
5.2.4 Razvoj aplikacijskih vmesnikov
Modulov vmesnik je sestavljen iz (gnezdenih) vhodnih parametrov, ki jih uporabnik poda modulu. Dobra Ansible zbirka potrebuje jasno definiran in lahko berljiv vmesnik, ki je enostaven za razumevanje in uporabo [35]. V primeru zbirke sodalite.k8s moramo za zadostitev temu pogoju izbrati kom- promis med vmesnikom, ki je podoben strukturi K8s objektov ter zato po- tencialno globoko gnezden, in povsem eno nivojskim vmesnikom, ki obiˇcajno krasi enostavne Ansible module. Pri naˇcrtovanju posameznih vmesnikov smo tako poskusili ˇcim bolj sploˇsˇciti vmesnik in ˇcimbolj odstraniti gnezdenje, ven- dar ˇse vedno ohraniti jasnost, tako da bo povpreˇcen uporabnik platforme Kubernetes lahko ˇcimbolj enostavno uporabljal naˇso zbirko.
5.3 Izbira odvisnih komponent
Naslednji korak v razvoju Ansible zbirke je izbira odvisnih komponent, preko katerih bo upravljala s platformo Kubernetes. Naravna pot je interakcija s Kubernetes APIjem, ki ga izpostavi API server, podobno, kot to poˇcno Ansi- ble moduli, ki upravljajo s sodobnimi platformami in infrastrukturo, vendar pa pogosto ni potrebno implementirati interakcije z APIjem, saj obstajajo Python knjiˇznice, ki se ukvarjajo s tem. Tudi v primeru sodalite.k8s bomo najprej raziskali takˇsen pristop, nato pa raziskali moˇznost integracije obstojeˇce zbirke kubernetes.core
5.3.1 Izbira Python knjiˇ znice
Obstaja kar nekaj knjiˇznic, ki znajo komunicirati s Kubernetes APIjem. Pri izbiri bomo poskusili najti ˇcimbolj uradno knjiˇznico, za katero je ˇcimbolj verjetno, da jo bo ˇse naprej kdo podpiral in razvijal. Konec koncev gre pri vseh teh knjiˇznicah za odprtokodne projekte, kjer podpora ni samoumevna.
V oˇzji izbor sta priˇsli dve knjiˇznici, uraden Python odjemalec kuber- netes in odjemalec, napisan za distribucijo OpenShift, openshift. Kljub temu, da druga knjiˇznica ni uradna, jo podpira Red Hat, kar zagotavlja nek obˇcutek varnosti. Obe knjiˇznici imata dva naˇcina uporabe, prvi je klasiˇcni odjemalec, kjer vsak Kubernetes objekt postane Python objekt, ki ga nato lahko uporabljamo, drugi naˇcin pa je dinamiˇcni odjemalec, ki ima samo en objekt, ki sprejme Kubernetes definicijo (v JSON formatu) in jo realizira.
Izmed ˇstirih moˇznosti smo izbrali knjiˇznico kubernetes z dinamiˇcnim odjemalcem. Razlog za knjiˇznico kubernetes se nahaja v principu YA- GNI, ki pravi, da ni smiselno dodajati funkcionalnosti, ki je ne potrebujemo.
Ker z naˇso zbirko ne ciljamo na specifiˇcne lastnosti distribucije OpenShift, je bolj smiselno, da zato izberemo uradno knjiˇznico kubernetes. Dinamiˇcni odjemalec pa prinese poenostavljen razvoj naˇse zbirke. Ker za upravljanje kateregakoli Kubernetes objekta zadoˇsˇca zgolj en objekt (dinamiˇcni odjema- lec), lahko povezavo z odjemalcem implementiramo v nekakˇsni skupni funkciji
Diplomska naloga 37 in jo nato zgolj uporabimo v posameznih modulih. Vsak modul mora tako zgolj oblikovati k8s definicijo svojega objekta, ki jo potem poˇslje skupnemu odjemalcu.
5.3.2 Integracija zbirke kubernetes.core
Zbirkakubernetes.coreje ravno v ˇcasu razvoja nove zbirke doˇzivljala nagel razvoj. Nedavno je vzdrˇzevanje in razvoj zbirke prevzel Red Hat, ki ima glede nje verjetno velike naˇcrte [60]. Pred tem je zbirka v vlogi Python knjiˇznice zamenjala openshift odjemalca z uradnim Kubernetes odjemalcem. Zbliˇzanje smeri razvoja z naˇsim pristopom je prineslo nove moˇznosti integracije.
Kubernetes.core.k8s ni slab modul. Razvija ga precej resna institucija (Red Hat), ponuja kar napredne moˇznosti postavljanja Kubernetes objektov, razliˇcne naˇcine posodobitve objektov (angl. apply, force), podpira raznovr- stne naˇcine avtentikacije v gruˇco Kubernetes in moˇznost, da poˇcaka na po- stavitev (angl. wait). Edina teˇzava je, da bi moralo njegovo delo opravljati celotna zbirka, moduli pa bi morali namesto gotovega k8s objekta sprejeti seznam potrebnih in na njih izvesti temeljito validacijo [60].
Namesto, da bi sami implementirali interakcijo z APIjem in tako podvajali funkcionalnost, ki jo nudi obstojeˇci modulkubernetes.core.k8s, ga lahko uporabimo kot odvisnost. V naˇsi zbirki jasno definiramo in dokumentiramo parametre, sestavimo Kubernetes definicijo, jo validiramo, nato pa predamo modulu kubernetes.core.k8s, ki opravi avtomatizacijo in vrne rezultate.
Tako si lahko module nove zbirke predstavljamo kot pametno ovojnico okoli modula kubernetes.core.k8s. Najveˇcja prednost takˇsnega pristopa je za- gotovo manjˇsa koliˇcina kode, ki jo moramo implementirati kar poslediˇcno prinese tudi laˇzjo vzdrˇzevanje v prihodnosti.
5.3.3 Zasnova zbirke
Na tej toˇcki bi lahko zaˇceli z implementacijo zbirke, vendar pa je potrebno pred tem narediti ˇse en korak v naˇcrtovanju. Ker je ena izmed dobrih praks
razvoja tudi izognitev nepotrebnemu podvajanju kode, je dobra praksa tudi premik funkcionalnosti, ki se ponavlja, v loˇceno datoteko, od koder jo lahko nato uvozijo vsi moduli.
Skupne funkcije
Skupne funkcije lahko v okviru Ansible zbirke definiramo v direktorijumodul utils, kamor naselimo skupne funkcije. V naˇsi zbirki bomo tako implementirali sledeˇco funkcionalnost:
• AnsibleModule, uvoz turbo modula oz. navadnega modula, ˇce turbo modul ni na voljo,
• k8s connector, integracija z modulom kubernetes.core.k8s,
• args common, vhodni parametri, ki so skupni vsem modulom,
• validacijske funkcije za najrazliˇcnejˇse podatkovne tipe,
• clean dict, tehniˇcno funkcijo, ki iz definicije rekurzivno odstrani pra- zne vrednosti.
V mapidoc fragmentspa bomo implementirali dokumentacijo za skupne parametre in jo prav tako delili med moduli.
Moduli
Ko smo iz modula odstranili vso skupno funkcionalnost, modulu preostanejo samo ˇse tiste naloge, ki so specifiˇcne za doloˇceni modul. V vsakem modulu moramo tako:
• definirati vhodne argumente,
• dokumentirati modul, argumente in izhodne vrednosti,
• definirati nekaj preprostih primerov uporabe,
• sestaviti definicijo iz vhodnih parametrov in
Diplomska naloga 39
• izvesti validacijo nastale definicije.
Definicijo nato preko prikljuˇcka prepustimo modulukubernetes.core.k8s, ki opravi dejansko avtomatizacijo.
Poglavje 6
Implementacija in testiranje
V tem poglavju bomo predstavili proces implementacije zbirkekubernetes.core.
Proces implementacije razliˇcnih vidikov zbirke je veˇcinoma potekal soˇcasno, veliko je bilo tudi popravljanja ˇze implementiranih funkcij, saj je hkrati z implementacijo potekalo intenzivno uˇcenje in pridobivanje izkuˇsenj. Zaradi jasnosti bomo v naslednjih sekcijah krˇsili kronoloˇsko zaporedje dogodkov in predstavili potek implementacije na bolj urejen in smiseln naˇcin.
Zbirka je dostopna na Githubu1.
6.1 Postavitev razvojnega okolja
Kot glavno razvojno okolje (IDE) smo vzpostavili JetBrains Pycharm, ki je odliˇcno razvojno okolje za razvoj aplikacij v programskem jeziku Python in ima kar nekaj vtiˇcnikov, ki lahko izboljˇsajo uporabniˇsko izkuˇsnjo. Tako smo iz pestre zbirke vtiˇcnikov namestil vtiˇcnike za JSON, YAML in Ansible, ki validirajo napisano kodo, opozarjajo na nepravilnosti in predlagajo samo- dejne dopolnitve (angl. autocomplete). V razvojnem okolju smo naredili novo pythonovo virtualno okolje, kamor smo med drugim namestil pakete Ansible in Kubernetes, z uporabo orodja anisble-galaxy pa smo pripra- vili ogrodje (angl. skeleton) svoje nove zbirke in zraven namestili zbirko
1https://github.com/mihaTrajbaric/k8s
41
kubernetes.core, tako da smo lahko med razvojem testirali tudi integra- cijo. Kot testno okolje, na katerem smo roˇcno testirali nastajajoˇce module, smo uporabljaliminikube distribucijo Kubernetes, namenjeno uporabi na lo- kalnem raˇcunalniku. Distribucija minikube sicer uporablja zgolj eno gruˇco, ki lahko med drugim teˇce v virtualnem raˇcunalniku ali pa Docker vsebniku, kar pa povsem zadostuje za razvoj. Poleg tega ima tudi priroˇcno nadzorno ploˇsˇco, kjer lahko spremljamo dogajanje na gruˇci in implementacijo vhodnega krmilnika (angl. IngressController), s katerim lahko izpostavimo aplikacije navzven.
6.2 Teˇ zave pri implementaciji
Kubernetes ekosistem je kljub velikosti naˇceloma dobro dokumentiran, ne glede na to pa je dokumentacija na doloˇcenih mestih nedosledna, kar oteˇzuje implementacijo.
Veˇcina podatkovnih tipov, ki nastopajo v definicijah Kubernetes objek- tov, je jasno doloˇcenih in se jih da enostavno prenesti v okolje Python oz.
Ansible (npr. integer za zapis ˇstevil, string za zapis besedila itd.). Ob- stajajo pa tudi posebni tipi, ki zahtevajo veˇc dela. Takˇsen primer je tip IntOrString, ki ga v Ansiblu definiramo kot str, nato pa ga modul spre- meni v int, ˇce je vhodni podatek ˇstevilka.
Najveˇc teˇzav pa je bilo pri pisanju skupnih validacijskih funkcij glede na zahteve Kubernetes APIja. Nekateri parametri, predvsem gre tukaj za razliˇcna imena objektov, reference na druge objekte ipd. morajo poleg osnov- nega podatkovnega tipa, ki je najveˇckrat tipa string ustrezati tudi dodatnim pogojem, npr. DNS Subdomain Name glede na standard RFC 1123. Pri implementaciji lastnih validacijskih funkcij smo se zgledovali po validacijskih funkcijah, ki jih uporablja, API streˇznik platforme Kubernetes2.
Teˇzave nastopijo, ko je potrebno ugotoviti, kateri parameter v Kuberne- tes objektu mora ustrezati kateremu standardu. Ponekod je pri dokumen-
2https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/util/validation/validation.go
