Avoimen lähdekoodin Kubernetes-ympäristöä käytetään ohjelmistokonttien hallintaan. Sen tärkein vahvuus on skaalautuvuus, mutta Kubernetes mahdollistaa myös koodin monipuolisen testaamisen. Test Automation Developer Mikko Jakonen kertoo nyt, milloin Kubernetes ja testausautomaatio ovat toimiva pari – ja millaisiin projekteihin kannattaa valita jokin muu ratkaisu.
Kubernetes on ohjelmistokonttipohjainen monipalvelinympäristö. Kontit (englanniksi containers) puolestaan ovat standardisoituja yksiköitä, joiden avulla devaaja voi paketoida ja siirtää koodia vaivattomasti testaus-, staging- ja tuotantoympäristöihin.
Kubernetesin käyttömahdollisuudet ovat laajat, eivätkä rajoitu vain testaamiseen. Oma roolini Cinialla kuitenkin liittyy juuri testausympäristöihin ja CI-putkien rakentamiseen. Siksi olen tehnyt tuttavuutta Kubernetesin kanssa ennen kaikkea testausautomaation näkökulmasta.
Tässä blogitekstissä jaan kokemuksiani siitä:
- miten Kubernetes-klusteri pystytetään
- mitä sudenkuoppia rakennusvaiheessa kannattaa välttää
- millaista testausautomaatiota me Cinialla olemme toteuttaneet Kubernetes-ympäristössä sekä
- milloin Kubernetes on toimiva ratkaisu, milloin taas ei paras mahdollinen.
Kubernetes-klusterin rakentaminen pähkinänkuoressa
1) Verkot ja arkkitehtuuri
On hyvä selvittää heti aluksi, missä verkoissa tuleva ohjelmistoratkaisu toimii. Mitkä osat ovat yksityisessä verkossa, ja mihin osiin järjestelmää taas on yhteys joko internetistä tai jostakin toisesta, ulkoisesta verkosta? Testikäyttöön tarkoitettua klusteria ei monesti haluta avata julki-internetiin, joten kannattaa miettiä, miten yhteydet tarjotaan projektin jäsenille ja rajoitetaan muulta maailmalta.
2) Kubernetes-distribuution valinta
Vanilla Kubernetes vai managed Kubernetes? Suosittelen valmiita työkaluja (managed), joita joku on joskus osuvasti verrannut Linux-distribuutioihin. Sopiva työkalu kannattaa valita sen mukaan, mitä pilviteknologiaa projektissa muutoin käytetään. Esimerkiksi AWS:lle on kehitetty oma Kubernetes-distribuutionsa (EKS), Azurelle omansa (AKS). Tarjolla on myös pilviagnostisempia vaihtoehtoja, kuten Rancher.
3) Valitun Kubernetes-distribuution konfigurointi
Konfiguroinnin parhaita käytäntöjä varten kannattaa kääntyä valitun distribuution (esimerkiksi EKS, AKS) valmistajan puoleen. Jokaisella valmismallilla on omat erityispiirteensä. Lisäksi on viisasta kehittää tiimien kokemusten perusteella yrityksen omia best practice -ohjeita Kubernetesin konfigurointiin.
4) Järjestelmän konfigurointi ja konttien välisten yhteyksien määrittely
Kun klusteri on pystytetty, on vielä konfiguroitava se järjestelmä, jota klusterissa on tarkoitus pyörittää. Ajettavien konttien määritykset kannattaa toteuttaa Helm-työkalulla. Se auttaa pitämään konfiguraatioon tarvittavan YAML-määrän hallinnassa ja versioitavissa. Testijärjestelmää pystytettäessä klusterin sisään voi pystyttää konteissa kaikki tarvittavat palvelut, kuten rajapinnat, tietokannat ja viestijonot. Tuotantokäytössä esimerkiksi tietokantojen kannattaa tyypillisesti olla omilla palvelimillaan klusterin ulkopuolella.
Mihin Kubernetes-klusterin rakentajan kannattaa erityisesti kiinnittää huomiota?
Päivittämiseen on viisasta varautua jo suunnitteluvaiheessa. Jokaisessa Kubernetes-distribuutiossa (esim. EKS, AKS) on siihen omat toimintatapansa. Jos päivitykset tulevat eteen vasta silloin, kun kiire on jo tulenpalava, joudut todennäköisesti tekemään paljon lisätyötä.
Toiseksi, kannattaa kiinnittää erityistä huomiota ulkoiseen rajapintaan (Kubernetes-termeissä ingress), eli siihen miten tarvittaviin palveluihin saa yhteyden klusterin ulkopuolelta. Näihin on tällä hetkellä haastavaa löytää selkeitä ohjeita valmiista Kubernetes-dokumentaatioista. Tapoja on erilaisia: esimerkiksi AWS-ympäristöön sopiva keino on tehdä kuormantasaaja (AWS Load Balancer), jonka kautta liikenne kulkee sovelluksen rajapintaan. Painotan jälleen verkkoarkkitehtuurin huolellista pohtimista: kannattaa olla selkeä idea siitä, mitä tarvitsee julkaista ulospäin.
Lue myös: AWS IaC: Templaateista TypeScriptiin
Kubernetes ja testausautomaation mahdollisuudet: Kokemuksia IoT-ratkaisusta
Päädyin alunperin Kubernetesin pariin, kun etsin testausratkaisua monimutkaiseen järjestelmäprojektiin. Kyseessä on IoT-ratkaisu, jossa kentällä toimivat laitteet lähettävät valtavia määriä dataa analysoitavaksi. Lopulta datasta muodostetaan näkymiä asiakkaan tarpeisiin.
Tiheästi toistuvat testit
Projektin ohjelmistoarkkitehtuuriin kuuluu mikropalveluita (microservices) eli pieniä backendeja, jotka keskustelevat toistensa kanssa. Kun niitä on paljon, järjestelmästä tulee raskas. Samalla kokonaisuutta halutaan testata mahdollisimman usein. Tätä yhtälöä ei voi ratkaista yhdellä virtuaalipalvelimella. Useiden rinnakkaisten instanssien tiheä, automaattinen testaaminen onnistuu, kun ohjelmisto pakataan kontteihin ja kontit hajautetaan Kubernetes-klusteriin.
Koodin eri haarojen yhtäaikainen testaaminen
Testaustiheyden lisäksi Kubernetes mahdollistaa siis sen, että voimme testata koodin eri haaroja yhtä aikaa. Näin saamme testausautomaation avulla mahdollisimman aikaisessa vaiheessa ilmoituksen, jos jotakin haaraa on korjattava.
IoT-laitteiden simulaatiot
Kun itse järjestelmäkin toimii Kubernetes-ympäristössä, voimme hyödyntää testaamisessa myös simulaatiota. Toisin sanoen voimme rakentaa aitoja laitteita simuloivia lisäelementtejä, jotka lähettävät dataa eteenpäin käsiteltäväksi.
Kubernetes ei keksi pyörää uudelleen, kun puhutaan testausautomaatiosta. Esimerkiksi jatkuvaa regressiotestausta voi toteuttaa muissakin ympäristöissä. Sen sijaan Kubernetes tuo skaalautuvuutta ja uudenlaisen mittakaavan testaamiseen.
Lue myös: Arkkitehtuurin pohjatyöt kuntoon: IoT-datan käsittely ohjelmistokehittäjän näkökulmasta
Milloin Kubernetes ei ole paras mahdollinen ratkaisu?
Kubernetes on laaja, melko raskaskin järjestelmä. Sitä ei siksi kannata ottaa mukaan aivan pieniin projekteihin. Niissä voi edelleen toimia tuttu ja simppeli ratkaisu: yksi kehityspalvelin, jolla myös testaajat työskentelevät. Yksittäisellä palvelimella työskenneltäessä Docker Compose mahdollistaa konttien hyödyntämisen pienellä vaivalla. Tämän mallin ongelmana on oikeastaan vain skaalautuvuus. Ohjelmistoratkaisun kasvaessa myös erilaisia testejä kun on tehtävä enemmän.
Pienten projektien kesken jaettu Kubernetes voisi olla yksi tulevaisuuden vaihtoehto. Eri projektit saisivat siis kapasiteettia testikuormien pyörittämiseen yhdestä, yhteisestä klusterista.
Ohjelmistokonttien hallintaan on toki muitakin vaihtoehtoja. Docker Swarm on helppokäyttöisyytensä ansiosta näppärä tapa tutustua konttiorkestraation maailmaan, vaikka sen ominaisuudet eivät ehkä riitäkään monimutkaisimpiin projekteihin. Amazon Elastic Container Service (ECS) on myös eräs vaihtoehto AWS-kehittäjille. Juuri Kubernetesissa pystyin kuitenkin hallinnoimaan kontteja Helm-työkalun avulla – sille ei löydy vastinetta ECS:stä.
Kontit ovat tulleet jäädäkseen
Konttien hyödyntäminen ohjelmistokehityksessä tulee varmasti yleistymään edelleen. Sen vuoksi uskon, että myös Kubernetesin rooli kasvaa sekä tuotanto-, kehitys- että testausympäristönä. Kattavat ominaisuudet ja helppokäyttöisyys eivät vielä kulje käsi kädessä, mutta työkalut varmasti kehittyvät sitä kohti.
