fbpx

Mikä on Kubernetes ja mitä hyötyä siitä on?

Kubernetes on tärkeimpiä työkaluja, mitä modernissa pilviympäristöissä tarvitaan.

Tiedätkö, mikä Kubernetes oikein on? Haluaisitko ymmärtää, mistä Kubernetisissa oikein on kyse? Entä mitä hyötyä Kubernetesista on?

Kun olet lukenut tämän kirjoituksen, ymmärrät, mikä Kubernetes on, mihin sitä käytetään, ja miksi se on niin tärkeä teknologia.

Kubernetes

Koska et välttämättä halua lukea kirjoitusta kokonaan, kerron aluksi hyvin lyhyesti, mikä Kubernetes on.

Mikä Kubernetes on?

Kubernetes on avoimeen koodiin perustuva järjestelmä, jota tarvitaan konttien ajamiseen ja hallintaan palvelunklusterin päällä. Kuberneteksen avulla voidaan käynnistää sovelluksen tarvitsema ryhmä kontteja ja päättää millä palvelimilla kontit käynnistetään. Kuberneteksen avulla voidaan myös seurata, toimivatko kontit halutusti. Kubernetes muodostaa konesalin palvelimista yhden suuren laskentaresurssin, jonka käyttöä se optimoi ja automatisoi ilman, että ihmisen tarvitsee tehdä päätöksiä siitä, minkä palvelimen päällä kontteja ajetaan.

Miksi sanoin johdannossa, että Kubernetes on yksi tärkeimmistä pilvimaailman teknologioista?

Kubernetesin merkitys on helpompi ymmärtää, kun ymmärtää, miten ohjelmistokehitys on kehittynyt viime vuosina. Käsitellään sen vuoksi sitä, miten ja miksi sovellukset ovat alkaneet muuttaa muotoaan.

Sovellukset ovat muuttumassa suurista möhkäleistä mikropalveluiksi

Aiemmin sovellukset olivat suuria monoliitteja, jotka muodostivat käytännössä yhden tai muutaman prosessin, joita ajettiin muutaman palvelimen päällä.

Suurin osa käytössä olevista sovelluksista on edelleen tällaisia monoliitteja eli möhkäleitä.

monoliitti

Mikä on monoliitti?

Geologiassa sana monoliitti tarkoittaa yhdestä kivestä muodostuvaa vuorta. IT-maailmassa monoliitti viittaa yhden laitteen tai ohjelmiston muodostamaan suureen kokonaisuuteen. Osuva suomenkielinen käännös voisi olla möhkäle.

Suuren "möhkäle-sovelluksen" päivittäminen on vaivalloista. Yleensä sovelluksia päivitetään sen vuoksi harvakseltaan. Aina kun sovelluskehittäjät ovat lopulta saaneet käännettyä ”möhkäleen” uuden koodin, antavat he sovelluksen konesalin operoijille, jotka puolestaan asentavat sen tuotantopalvelimille.

Kun ”möhkäleen” yhtä ominaisuutta pitää päivittää, täytyy koko sovellus päivittää. Kun sovelluksen eri osia pikkuhiljaa päivitetään, sovelluksen sisäinen rakenne vähitellen monimutkaistuu ja koodin ylläpito vaikeutuu. Tämän vuoksi voisi sanoa, että sovellusten laatu heikkenee herkästi ajan myötä.

Sovelluksen tarvitseman kapasiteetin kasvattamiselle on kaksi vaihtoehtoa

Perinteistä möhkälemäistä sovellusta ajetaan yleensä yhden tai muutaman palvelimen muodostaman kokonaisuuden päällä. Jos sovelluksen kuorma kasvaa ja tarvitaan lisää tehoa, pitää yleensä päivittää palvelimia jykevämmäksi lisäämällä prosessoritehoa, keskusmuistia tai päivittämällä muita palvelimen komponentteja.

Palvelimen päivittäminen tehokkaammaksi ei yleensä vaadi sovellukseen mitään muutoksia. Tätä skaalaustapaa sanotaan ylöspäin skaalaamiseksi (englanniksi scale up).

Ylöspäin päivittämisessä ei ole mitään ongelmia, niin kauan kuin sovellusta voidaan ajaa yhdellä tavallisella palvelinraudalla. Jos tehontarve edelleen kasvaa, palvelimen koon kasvattaminen voi kuitenkin muuttua kalliiksi, koska halvan peruspalvelimen sijaan aletaan tarvita suuritehoisia erikoispalvelimia.

Toinen tapa kasvattaa sovellukselle annettavaa palvelintehoa on lisätä kapasiteettia nykyisen palvelimen rinnalle eli skaalata palvelua ulospäin (englanniksi scale out). Tämä on usein halvempaa, koska skaalaamisessa voidaan käyttää halpoja peruspalvelimia. Ongelmaksi muodostuu helposti sovelluksen rakenne.

Kaikkiin sovelluksiin ei voi lisätä rinnakkain toimivia noodeja. Rinnakkaisten noodien lisääminen vaatii usein sovelluksen rakenteen muuttamista, eli sovelluksen koodia pitää alkaa muuttaa. Lisäksi joitakin sovelluksen osia voi olla erittäin vaikea skaalata ulos.

Monoliittisen sovelluksen ongelma on se, että jos yhtä sovelluksen osaa ei pysty skaalaamaan ulospäin, koko sovellus muuttuu mahdottomaksi skaalata.

Sovelluksia pilkotaan mikropalveluiksi

Sovellusten skaalaaminen on yksi syy, miksi perinteisiä monoliittisia sovelluksia on pyritty pilkkomaan pienempiin, itsenäisiin sovelluksiin. Tällöin puhutaan yleensä mikropalveluista.

Lue lisää mikropalveluista kirjoituksestani Mitä mikropalvelut ovat?

Alla oleva kuva esittää perinteistä sovellusta, jossa on yksi prosessi. Oikealla on sama sovellus rakennettuna mikropalveluiden avulla. Siinä sovellus on jaettu useaan mikropalveluun, joista kukin toteuttaa yhden toiminnallisuuden.

monoliitti vs mikropalvelu

Mikropalvelujen ulkoiset rajapinnat on yleensä hyvin määritelty. Vaikka palvelu voi muuttua sisältä, sen ulkoinen rajapinta muuttuu yleensä melko vähän. Tämän vuoksi mikropalveluista muodostuvaa sovellusta voidaan päivittää yleensä mikropalvelu kerrallaan.

Miten mikropalveluja skaalataan?

Mikropalveluja voi skaalata palvelu kerrallaan. Tämän vuoksi riittää, että skaalataan juuri sitä palvelua, joka tarvitsee lisää resursseja. Enää ei tarvitsekaan skaalata koko sovellusta siksi, että yksi sovelluksen osa tarvitsee lisää resursseja.

Mikropalvelun skaalaaminen muodostaa uuden ongelman

Vaikka mikropalvelujen skaalaaminen ja päivittäminen on periaatteessa helpompaa kuin perinteisen monoliittisen sovelluksen, liittyy niihin myös ongelmia.

Koska perinteinen sovellus koostuu pienestä määrästä suuria kokonaisuuksia, sitä on helpompi hallita. On helppoa tietää, mille palvelimelle uusi sovellus pitää asentaa, koska vaihtoehtoja on vähän.

Kun sovellus alkaa koostumaan isosta määrästä pieniä komponentteja, alkaa olla vaikeampaa tietää, mille palvelimelle mikäkin sovelluskomponentti kannattaa asentaa. Mitä isommaksi mikropalvelujen määrä kasvaa, sitä hankalammaksi niiden muodostaman kokonaisuuden hallinta muodostuu.

Alla oleva kuva esittää esimerkkiä tilanteesta, jossa palvelimille on asennettu suuri määrä komponentteja. Sen tietäminen, millä palvelimella pyörii mitäkin palveluita, ja mikä prosessi pyörii milläkin palvelimella voi muuttua haastavaksi.

Mikropalveluiden sijoittelu palvelimille

Mikropalvelujen helppo päivitettävyys muodostaa toisen uuden ongelman

Kun kehitetään perinteisiä sovelluksia, palvelut koostuvat pienemmästä määrästä erilaisia ohjelmistokomponentteja. Tällöin niiden tarvitsemien komponenttien ylläpito palvelimilla on suhteellisen helppoa.

Koska mikropalveluja voi päivittää palvelu kerrallaan, palvelut alkavat helposti kehittyä eri suuntiin. Varsinkin palveluissa, joissa eri tiimit kehittävät eri palvelun osia, aletaan herkästi käyttämään eri kirjastoja ja kirjastojen eri versioita, sovellusten tarvitsemien eri komponenttien määrä kasvaa voimakkaasti. Tällöin palvelimien ylläpito muuttuu hankalaksi.

Alla oleva kuva esittää tällaista tilannetta. Ylläpitäjän kannalta tilanne on herkästi painajaismainen. Jos samalle palvelimelle asennetut eri kirjastot eivät toimikaan keskenään, ollaan vaikeuksissa. Joka kerta kun sovelluksia tai kirjastoja päivitetään, on mahdollista, että sovellus lakkaa toimimasta.

Sovellusten väliset riippuvuudet

Kehitysympäristön, testauksen ja tuotannon pitäisi olla samannäköisiä

Sovelluskehittäjien kannalta yksi suurimmista ongelmista ovat erot sovelluskehitys-, testaus- ja tuotantoympäristöjen välillä. Sovelluskehittäjän kone näyttää aivan erilaiselta kuin testausympäristö saatikka tuotantopalvelin.

Erot eivät kuitenkaan jää vain näiden ympäristöjen välille. Yhtä lailla eroja voi olla tuotantopalvelimien välillä. On haastavaa pitää tuotantopalvelimia täsmälleen samannäköisenä. Toinen ongelma, minkä jokainen sovelluksia ylläpitävä kohtaa, on tuotantoympäristön muuttuminen ajan myötä.

Kun tuotantopalvelimille asennetaan tietoturvapäivityksiä, alkaa tuotantoympäristö muuttumaan verrattuna alkuperäiseen ympäristöön, johon sovellus on rakennettu. Jokainen muutos on potentiaalinen ongelmien aiheuttaja.

Lisäksi sovelluskehittäjät ajavat koneellaan yleensä vain yhtä sovellusta kerrallaan. Tuotantoympäristössä voi samalla palvelimella olla useampia sovelluksia. Tämä voi johtaa ristiriitoihin tarvittavien komponenttien suhteen.

Ei ihme, että perinteisessä mallissa moni ylläpitäjä haluaa laittaa yhdelle palvelimelle vain yhden sovelluksen. Muuten riippuvuuksien ja yhteensopivuuksien hallinta menee liian vaikeaksi.

Ratkaisuna tähän on rakentaa yksi paketti, joka sisältää sovelluksen ja sen tarvitsemat komponentit. Kontit tekevät juuri tämän.

Kontit ovat ratkaisu sovelluksien riippuvuusongelman ratkaisemiseksi

Kontit ovat tapa standardoida sovelluksen tarvitsema ajoympäristö yhteen pakettiin, jota voidaan siirrellä helposti ympäristöstä toiseen. Konttien avulla voidaan helpottaa sovelluskehitystä, koska ajoympäristö pysyy vakiona kehittäjän koneelta testaukseen ja tuotantoympäristöön saakka. Lue lisää konttiympäristöstä kirjoituksestani Konttiteknologia – mitä kontit ovat ja mitä hyötyä niistä on?

Tunnetuin ohjelmisto, jolla rakennetaan ja ajetaan kontteja, on Docker. Pelkällä Docker Enginellä, joka on Dockerin peruskomponentti, ei konttimaailmassa kuitenkaan pötkitä pitkälle. Dockerin kaveriksi tarvitaan työkalu, jonka avulla kontteja voi käytännössä laittaa ajoon, valvoa ja esimerkiksi käynnistää uudelleen. Kubernetes on auttaa juuri tässä. Kubernetes on suosituin ratkaisu, jota käytetään konttien hallintaan.

Lue lisää Dockerista kirjoituksestani Mikä on Docker ja mitä hyötyä siitä on?

 

Kubernetes on työkalu, jota tarvitaan konttiympäristön ajamiseen käytännössä.

Mistä Kubernetes on peräisin?

Sana Kubernetes on kreikkaa ja tarkoittaa kuljettajaa tai ruorimiestä.

Kubernetes perustuu Googlen kehittämään konesalin hallintajärjestelmään. Lähes kaikki Googlen sovellukset perustuvat kontteihin, joita hallitaan Googlen itse kehittämällä orkestrointityökalulla nimeltä Borg.

Google

Googlen ympäristössä on lukematon määrä klustereita ja niiden päällä ajettavia kontteja. Ympäristössä käynnistetään viikossa yli 2 miljardia konttia, joten voi vaan kuvitella ongelmia, joita palveluiden kehityksessä on kohdattu.

Google on kehittänyt Borg-järjestelmäänsä jo vuodesta 2003. Koska Borg on täysin Googlen kehittämää ja omistamaa teknologiaa, sen kehittämisessä on voitu olettaa enemmän asioita kuin yleisesti saatavassa Kuberneteksessa.

Kubernetesia on kehittetty vuodesta 2014. Siinä on pyritty ottamaan oppia niistä haasteista, joihin Google on Borgin kanssa törmännyt.

Google käyttää uusien palveluidensa ajamiseen tyypillisesti omaa Google Cloud Platform (GCP) alustaansa, jota se myy kaikille muillekin. Tätä alustaa hallitaan Kuberneteksella. Borg säilyy vanhemman infrastruktuurin orkestrointityökaluna.

Mihin Kubernetesta oikein tarvitaan? Miksei konttiympäristöä voi hallita perinteisin menetelmin? Lue eteenpäin, niin saat tietää vastauksen.

Tilaa ILMAINEN opas

Opas pilvi konesali

Pilvistrategian laatimiseksi

Tilaa ilmainen 32-sivuinen opas, jossa kerron, mitä ottaa huomioon, kun haluat uudistaa IT-ympäristöä pilvipalvelujen avulla.

 

 

Mihin Kubernetesta tarvitaan?

Käsittelen tässä osuudessa sitä, mihin Kubernetesta oikein tarvitaan. Kun olet lukenut tämän osuuden, ymmärrät paremmin, miksi konttiympäristö tarvitsee Kuberneteksen kaltaista työkalua.

  • Kun useasta kontista koostuva sovellus halutaan käynnistää tuotantoympäristössä, pitää tietää, mitä kaikkia kontteja sovelluksen ajamiseen tarvitaan. Kubernetes on työkalu, joka tietää, mitä kontteja sovellus tarvitsee. Kubernetekselle kerrotaan, mitä kontteja tarvitaan, ja kun sovellus halutaan käynnistää, se osaa käynnistää kaikki tarvittavat kontit.
  • Koska tuotantoympäristössä ei kontteja yleensä ajeta yhden palvelimen päällä, pitää sovellusta käynnistettäessä tietää, mille palvelimille kontit kannattaa sijoittaa. Kubernetes on työkalu, joka sijoittaa kontit tuotantoympäristöön. Kuberneteksen avulla siis päätetään, millä palvelimilla ajetaan mitäkin kontteja.
  • Kun tuotantoympäristöön on käynnistelty kontteja, pitäisi tietää, millä palvelimilla on mitäkin kontteja ajossa. Kubernetes pitää kirjaa siitä, mitä kontteja milläkin alustapalvelimella ajetaan.
  • Kuberneteksen avulla voidaan seurata, toimivatko kontit halutusti. Sen avulla voidaan käynnistää vikaantuneita kontteja automaattisesti uudelleen.
  • Kuberneteksen avulla voidaan huolehtia sovelluksen skaalaamisesta kuormituksen lisääntyessä. Jos sovellus kuormittuu ja tarvitsee lisää kapasiteettia, osaa Kubernetes käynnistää automaattisesti uusia kontteja ja huolehtia niiden välisestä kuorman jaosta.
  • Kuberneteksen avulla voidaan päivittää sovelluksia, jotka koostuvat useista konteista. Kun kontteihin halutaan tehdä muutoksia, osaa Kubernetes päivittää kontit. Jos muutos ei suju halutusti, Kuberneteksen avulla voidaan ottaa käyttöön aiempi kontti.
  • Kuberneteksen avulla annetaan konteille niiden tarvitsemat IP-osoitteet ja huolehditaan sovelluksen julkaisemisesta käyttäjille.

Konttiympäristön ajamiseen liittyy siis käytännössä monenlaisia asioita, joista pitää huolehtia. Usein puhutaan palvelun tai järjestelmän orkestroinnista. Kubernetes on siis käytännössä konttien orkestrointityökalu (englanniksi Orchestration).

Mitä on orkestrointi?

Orkestrointi on tietokonejärjestelmien ja -ohjelmistojen automaattista konfigurointia, koordinoimista ja hallintaa.

Orkestrointia käytetään laajasti julkisissa pilvipalveluissa. Kun asiakas päättää käynnistää uuden virtuaalipalvelimen, orkestrointityökalu päättää ensin, mille palvelinraudalle se asennetaan. Päätöksen tekemiseen orkestrointityökalu tutkii asiakkaan pyytämän palvelimen ominaisuuksia (esimerkiksi muistin määrää, haluttua prosessorikapasiteettia ja palvelimesta tarjottavaa tallennustilaa). Sen jälkeen palvelin käynnistetään ja siihen kytketään tarvittavat verkot ja asiakkaan tilaama tallennustila.

Perinteisessä IT-ympäristössä tämä kaikki tehdään käsin. Asiantuntija päättää, mille fyysiselle palvelimelle kyseinen virtuaalikone kannattaa asentaa. Tämän jälkeen asiantuntija tekee käsin kaikki tarvittavat konfiguraatiot ja käynnistää virtuaalipalvelimen.

Orkestrointityökalu tekee siis tämän kaiken automaattisesti. Koska pilviympäristöt perustuvat automaattiseen (heti tapahtuvaan) käyttöönottoon, tarvitaan siihen työkalu, joka on käytännössä orkestrointityökalu.

Mitä hyötyä Kuberneteksesta on?

Luodaan lyhyt katsaus siihen, mitä hyötyä Kubernetesesta on.

  • Kubernetes piilottaa alleen koko datakeskuksen laitteistoineen ja eri komponentteineen. Se näyttää konesalin yhtenä valtavana resurssina, jota voidaan käyttää eri sovelluksien ajamiseen.
  • Kuberneteksen avulla voidaan automatisoida konttien sijoittelu palvelimille, käynnistäminen ja niiden tilan seuranta. Kubernetes auttaa tehostamaan IT-infran käyttöä, koska se pystyy optimoimaan palvelinresurssien käytön paljon tehokkaammin, mihin ihminen pystyy.
  • Kubernetes auttaa oman konesalin ylläpidossa, koska sen ansioista konesaliin voidaan tuoda uusia palveluita ilman, että tarvitaan lisää palvelinten ylläpitäjiä. Tämä tuo massiivisten pilvikonesalien tarjoajille valtavan mittakaavaedun verrattuna perinteiseen konesaliin, jota pidetään yllä pitkälti manuaalisesti.

Pilvipalveluiden tarjoajille Kubernetes on kultakaivos. Sen ansiosta pilvipalvelun tarjoajan (tai miksei konesalitarjoajan) ei tarvitse tietää, mitä kaikkea konesalissa ajetaan, koska Kubernetes hoitaa kaiken kuormien ajamiseen liittyvän hallinnan.

Kubernetesin pääkomponentit

Tässä osuudessa käsittelen sitä, millaisista osista Kubernetes koostuu. Jos Kubernetesia katsoo aivan ylätasolta, se koostuu Kubernetes masterista ja laskentaresursseista.

Kubernetes master on klusterin aivot. Se päättää, millä palvelimella ajetaan mitäkin sovelluksia. Sovelluskehittäjä antaa käytännössä Kubernetes masterille listan konteista, joita sovelluksen ajamiseen tarvitaan, ja master päättää sen jälkeen, mille palvelimille kontit sijoitellaan.

Kubernetes yksinkertaisesti

Kun perinteisessä palvelinympäristössä palvelinten ylläpitäjät päättävät, millä palvelimella ajetaan mitäkin sovellusta, Kubernetes huolehtii tästä ylläpitäjien puolesta.

Jos katsotaan tarkemmin masterin sisälle, sieltä löytyy seuraavia komponentteja:

  • API Server. API Server toimii rajapintana ylläpitäjien suuntaan samoin kuin työkuormia ajavien palvelimien suuntaan.
  • Nimi hieman harhaanjohtava, koska kyse ei varsinaisesti ole ajastimesta. Scheduler osoittaa sovelluksille paikat eri palvelimilta kulloisenkin tilanteen ja tarpeen mukaan.
  • Controller Manager. Controller Manager pitää silmällä kuormaa ajavia palvelimia, käynnistää vikaantuneita komponentteja jne.
  • Etcd on tietokanta, johon master tallettaa klusterin konfiguraatiotiedot.

Työkuormaa ajava palvelin sisältää seuraavia komponentteja:

  • Kubelet on komponentti, jonka kautta työkuormaa ajava palvelin keskustelee masterin kanssa.
  • Kube-proxy. Kube-proxy toimii rajapintana, kun sovellus, joka pyörii työkuormaa ajavan palvelimen noodilla haluaa keskustella klusterin ulkopuolisen maailman kanssa. Se käytännössä julkaisee sovelluksen klusterin ulkopuolelle.
  • Container Runtime. Container Runtime on esim. Docker Engine, joka käytännössä ajaa kontteja kyseisellä palvelimella.

Oheinen kuva esittää Kubernetesin pääkomponentteja.

Kubernetes masterin ja worker node komponentit

Kubernet optimoi palvelin-infran käytön ihmistä paremmin

Yksi keskeinen Kubernet-klusterin ominaisuus on kuormapalvelimien kuormituksen optimointi. Kubernetin master tietää, mitä kontteja on ajossa milläkin palvelimella. Master voi siirrellä kontteja palvelimelta toiselle, jos se huomaa, että klusterin toimintaa voisi optimoida.

Perinteisessä palvelininfrassa ylläpitäjä päättää, millä palvelimella kannattaa ajaa mitäkin sovellusta. Tämä on suhteellisen yksinkertaista, kun ajetaan perinteisiä sovelluksia. Mitä isommaksi klusteri kasvaa ja mitä enemmän sovelluksia on, sitä työläämmäksi sovellusten sijoittelu kuitenkin muuttuu.

Kun sovellukset koostuvatkin konteista, jotka eivät häiritse toisiaan, mahdollisia vaihtoehtoja on lukematon määrä. Tietokone on paljon ihmistä parempi monimutkaisen klusterin toiminnan optimoimisessa. Tämän ansiosta infran käyttöä voidaan tehostaa huomattavasti verrattuna perinteiseen palvelin-infraan.

Master voi periaatteessa siirrellä sovelluksen kontit hajalleen eri puolille klusteria. Tämä voisi johtaa ongelmiin sovelluksen toiminnan kannalta. Tähän on kuitenkin ratkaisu: podit. Käsitellään sitä seuraavaksi.

Kubernetes-klusteri koostuu podeista

Yksi kaikkein keskeisin Kubernetsin komponentti on pod. Pod on ryhmä kontteja, jotka halutaan ajaa samalla kuormapalvelimella. Jokainen pod on käytännössä oma looginen kokonaisuutensa, jolle annetaan oma ip-osoite.

Pod voi siis koostua yhdestä tai useammasta kontista. Pod on tärkeä yksikkö, koska se pitää yhdessä ne kontit, joiden tulisi olla ohjelman toimimisen kannalta lähekkäin. Podien ansiosta ne kontit, joiden tulee olla lähellä toisiaan, eivät joudu liian kauaksi toisistaan.

Jokainen pod saa oman klusterin sisäisen ip-osoitteen, jonka avulla sovelluksen podit voivat liikennöidä toistensa kanssa. Pod ei näy klusterin ulkopuolelle millään tavalla.

Koska jokaisella podilla on oma ip-osoite, podit voivat keskustella keskenään. Näin podit, jotka muodostavat yhdessä sovelluksen, voivat keskustella toistensa kanssa.

Pod on siis keskeinen Kubernet-klusterin komponentti, jonka ansiosta klusterin käyttöä voidaan sekä optimoida että huolehtia sovellusten tarvitsemien konttien pysymisestä lähellä toisiaan.

Tarvitaan kuitenkin jotain muuta, jotta Kubernetes-klusterin sisällä olevien konttien muodostama sovellus voidaan julkaista käyttäjille. Tähän tarvitaan palveluja. Käsitellään niitä seuraavaksi.

Kubernetes julkaisee ulkomaailmaan palveluja

Vaikka jokaisella Kubernetesin podilla on oma ip-osoite, se ei pysty keskustelemaan ulkomaailman kanssa, koska podin ip-osoite on täysin klusterin sisäinen. Jotta sovelluksen voi julkaista käyttäjille, tarvitaan palvelu-objekti (service object).

Kun Kubernetes-klusteria pyytää julkaisemaan palvelun, se antaa palvelulle ip-osoitteen, johon klusterin ulkopuolelta pääsee kiinni.

Kubernetes luo samalla kuormantasaajan (load balancer), jonka avulla sovellukseen kohdistuvaa kuormaa voidaan alkaa jakaa useiden eri podien eli konttiryhmien välillä. Näin Kubernetes tarjoaa mahdollisuuden rakentaa sovellukseen sekä korkeaa käytettävyyttä että suorituskykyä.

Kubernetes julkaisee palveluja

Missä Kubernetesta voi ajaa?

Kubernetesia ajetaan palvelimien päällä. Palvelimet voivat olla joko virtuaalisia tai yhtä hyvin fyysisiä bare metal -palvelimia. Kuberneteksen ideana on yhdistää palvelimia klustereiksi, joita käytetään konttien ajamiseen.

Koka Kubernetes toimii palvelininfran päällä, voi sitä ajaa yhtä hyvin omassa konesalissa tai julkisessa pilvessä.

Käsitellään tarkemmin kutakin vaihtoehtoa.

Kubernetes On Premises -ympäristössä

Jos Kubernetesia päättää ajaa omassa tai ulkoistuskumppanin konesalissa, tarvitaan ajamiseen joukko virtuaali- tai fyysisiä palvelimia.

Tällaisessa ratkaisussa täytyy jonkun pitää huoli myös näistä klusteriin kuuluvista palvelimista. Ja jos klusteri koostuu virtuaalipalvelimista, pitää myös niiden alustapalvelimia pitää yllä.

Kubernetes-klusterin rakentaminen ei ole ihan triviaali tehtävä, vaan se vaatii asiaan perehtymistä. Sen vuoksi moni päätyy ajamaan Kubernetesia julkisessa pilvessä.

Kubernetes julkisessa pilvessä

Kaikki suurimmat pilvipalvelujen tarjoajat Amazon AWS, Microsoft Azure ja Google Cloud Platform tarjoavat Kubernetes-klustereita palveluna.

Azurella on Azure Kubernetes Service (AKS), joka on valmis Kubernetes-ympäristö, jonka asiakas voi ottaa käyttöön. Itse klusterin hallinta ei maksa mitään. Asiakas maksaa vain klusterin ajamiseen tarvittavista virtuaalikoneista, verkoista ja esimerkiksi tallennustilasta.

Amazon AWS tarjoaa useampaa erilaista Kubernetes-palvelua. Esimerkiksi Amazon Elastic Kubernetes Service (Amazon EKS) tarjoaa Amazonin ylläpitämän Kubernetes-hallinnan, jolloin asiakas voi keskittyä työkuormien ajamiseen.

Google Cloud tarjoaa myös Kubernetes-palvelua. Google Kubernetes Engine on Googlen palvelu Kubernetes-klusterin ajamiseksi.

Tilaa ILMAINEN opas

Opas pilvi konesali

Pilvistrategian laatimiseksi

Tilaa ilmainen 32-sivuinen opas, jossa kerron, mitä ottaa huomioon, kun haluat uudistaa IT-ympäristöä pilvipalvelujen avulla.

 

 

Yhteenveto

Käsittelimme kirjoituksessa sitä, mikä Kubernetes on. Käsittelin sitä, miten ohjelmistot ovat muuttumassa ja miksi mikropalvelut ja kontit vaativat uusia työkaluja niiden luomien uusien ongelmien ratkomiseen. Kubernetesin avulla voidaan saavuttaa merkittäviä hyötyjä.

Kuberenetesin avulla tietokone optimoi infran käyttöä huomattavasti paremmin kuin mitä ihminen pystyy. Se myös automatisoi sovellusten käyttöönottoa, päivitystä ja skaalaamista. Palvelin-infran ylläpitoon tarvitaan yhä vähemmän ihmisiä.

Kun Kubernetesin hyödyt yhdistetään Docker-konttien potentiaaliin esimerkiksi Windows Server -lisenssisäästöissä, pitäisi asian alkaa kiinnostamaan IT-päättäjää, joka haluaa saada samalla joustavuutta että säästöjä.

Kubernetes on monimutkainen teknologia, josta on kirjoitettu kokonaisia kirjoja, ja sen käyttöön liittyy paljon asioita, mitkä on syytä ymmärtää. Se on kuitenkin esimerkki teknologioista, jotka todella muuttavat IT-ympäristöä verrattuna perinteiseen käsin ylläpidettävään palvelinympäristöön.

Yksi keskeinen ymmärrettävä asia Kubernetesin kohdalla on tietoturva. Toinen tärkeä asia, mitä on hyvä ymmärtää, on se, miten Kubernetes integroituu moderniin softankehitysputkeen. Kirjoittelen näistä asioista tulevissa kirjoituksissani.

Jos koit kirjoituksen hyödylliseksi, jaa se omalle verkostollesi. Tilaa myös uutiskirjeni, jonka ansiosta saat aina tiedon uusista kirjoituksista.

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

Annan luvan tallentaa tietoni ja hyväksyn tietosuojakäytännön.

Scroll to Top