Kubernetesin tulevaisuus – DEVOPS Conference -takkatulen ääressä käydyn keskustelun tärkeimmät opit

Konttien orkestroinnista ohjaustasoon

Moni meistä ajattelee Kubernetesia konttien orkestrointialustana. Kerrot tarvitsevasi kolme kopiota, tietyn määrän muistia ja suorittimen kapasiteettia. Sitten pääsetkin jo vauhtiin kiiltävien uusien konttien kanssa.

Kubernetes on kuitenkin kehittynyt verkon mukana paljon muuksikin. Ajattele, miten verkko on muuttunut: kaikki verkkopalvelinta ylläpitävät eivät tarvitse verkkosivustoa. HTTP-protokollaa voidaan silti hyödyntää tiedon siirtämiseen esimerkiksi REST API:n kautta.

Kun asiaa ajattelee, Kubernetesin erottaa aiemmista työkaluista, kuten Puppetista, Chefistä ja Ansibleista, tilan hallinnan käsite. Se perustuu promise theoryyn: määrittelet, mitä haluat tapahtuvan, ja julkaiset sen datana. Tämä eroaa skriptauksesta, jossa kirjoitat jotain Rubylla, Pythonilla tai Bashilla ja suoritat sen koneella.

Kuvaat siis tietokannan, annat kuvauksen API-palvelimelle, jonka tehtävänä on käynnistää ohjain. Ohjain seuraa ja ymmärtää dataa sekä tuottaa sinulle tietokannan. Konttien orkestroinnissa keskeisiä tilan tarkastamiseen ja vertaamiseen käytettyjä ohjaussilmukkaa ja ohjaustasoa hyödynnetään nyt paljon laajemmin. Tästä on tullut Kubernetesin supervoima.

Tämä laajentaa Kubernetesin käyttötapaukset lukuisiin uusiin ja kiinnostaviin kohteisiin. Crossplanen kaltaiset työkalut ja ratkaisut hyödyntävät ohjaustason toiminnallisuutta täysimääräisesti. Kontit ovat silloin lähes sivuosassa.

Kypsyyden merkkejä: distrokuume iskee

Tämän muutoksen myötä Kubernetes kypsyy, aivan kuten Linux teki hyvinä vanhoina aikoina.

Jos asennat Kubernetesin alusta alkaen samaan tapaan kuin aiemmin rakensit omia käyttöjärjestelmädistroja, meillä on uutisia: on olemassa parempi tapa. Red Hatin, CentOSin, Debianin ja SUSEn kaltaisten valmiiksi paketoitujen Linux-versioiden tavoin saatavilla on nyt valmiiksi paketoituja Kubernetes-ratkaisuja, kuten Google Cloudin GKE, AWS:n EKS ja Azuren AKS. Jos haluat säilyttää hieman enemmän riippumattomuutta, vaihtoehtona on OpenShift.

Sinun ei enää tarvitse käyttää aikaa ja vaivaa oman distron rakentamiseen alusta asti: valmiiden distrojen avulla pääset keskittymään olennaiseen ja kehittämään alustaasi paljon nopeammin.

Siilojen kesyttäminen API:lla

Todetaan tosiasiat: maailma on aina ollut siiloutunut. Toimintamalli on aina ollut jotakuinkin tämä: "anna meille koodisi, niin ajamme nipun skriptejä ja logiikkaa, ja jotenkin se päätyy ympäristöön." Jos jokin hajosi, kokoonnuitte selvittämään ongelmaa. Samaa toistettiin pitkään yhä uudelleen.

Siilot pitää murtaa, eikö niin? Kyllä, mutta kun asiaa ajattelee, siilot ovat haitallisia vain silloin, kun niiden välillä ei ole mitään tapaa kommunikoida. Siilo ei tunnu niin eristyneeltä, kun käytössä on API.

Moni asia toimii edelleen samalla tavoin kuin 15 vuotta sitten. Kirjoitat koodia, ajat testejä, luot artefakteja ja annat sitten ihmisten määritellä tarvitsemansa ympäristöt. Kubernetes muuttaa oikeastaan viimeisen vaiheen. Kaikille kehittäjille ei tarvitse opettaa Dockeria, Vagrantia, Puppetia tai Ansiblea. Ne ovat vain keino päästä päämäärään.

Tavoitteena on, että joku voi määritellä, mitä hän tarvitsee sinulta, ja että tämä tieto voidaan taustalla toteuttaa halutun mukaiseksi. Kubernetes tekee siitä helppoa. Näin siilojen merkitys vähenee huomattavasti.

Tämä on kuin sopimus palveluiden tai järjestelmien pyytämisestä: se määrittelee epäsuorasti, miten toimitaan ja mitä on odotettavissa. Tällainen määritelmä luo lupauksen tai SLA-sopimuksen tunteen, ja arjesta tulee paljon helpommin hallittavaa.

Tämän lähestymistavan vertaaminen Terraformiin voi helpottaa sen ymmärtämistä. Terraformissa (yksinkertaistamme hieman, tiedämme sen) kirjoitat Terraform-koodia tiedostoon kannettavallasi, ja se suoritetaan vain, kun käynnistät sen. Kun kannettava tietokoneesi tai keskuspalvelin, jolla käytit Terraformia, on sammutettuna, mitään ei tapahdu. Terraform ei voi tehdä mitään, ennen kuin se käynnistetään uudelleen.

Kubernetes toimii toisin. Ohjain tarkkailee jatkuvasti, ympäri vuorokauden, tavoitetilaasi ja pyrkii sovittamaan sen todellisuuteen. Järjestelmä tuntuu itsekorjaavalta, koska se ymmärtää, ettei ole hetkeä, jolloin et haluaisi määritellyn tilan toteutuvan.

Kubernetes rakastaa putkia – ja päinvastoin

Yksi Kubernetesin hienoista puolista on, että voit siirtyä Infrastructure as Codesta (IaC) Infrastructure as Dataan (IaD).

Ero ei ehkä kuulosta suurelta, mutta saat merkittäviä hyötyjä, kuten mahdollisuuden rakentaa pipeline.

Koodilla pipelinejen rakentaminen on hankalaa, sillä yksi työkalu ei välttämättä ymmärrä aiemmin käyttämäsi syntaksin ja skriptauskielen rakennetta. Kun muutat infrastruktuurin dataksi, voit tehdä todella hyödyllisiä asioita, kuten lisätä mukaan käytäntöjä. Tämä parantaa merkittävästi resurssien tehokasta ja turvallista hallintaa.

Tilallinen vai tilaton – siinäkö kysymys?

Jotkut haluaisivat kääriä kaiken Kubernetesin sisään. Ja toki myös tilallisia palveluita voi ajaa Kubernetesissa, mutta Kubernetes voi tulla vastaan vain puoliväliin asti.

Useimmat SQL-tietokannat, kuten Postgres ja MySQL, kaipaavat vakautta: niitä ei ole suunniteltu sietämään vaihtuvia IP-osoitteita ja satunnaisia konevikaantumisia. Jos haluat ajaa tällaisia tietokantoja Kubernetesissa, tarvitset avuksi operaattorin, kuten Vitessin, joka on MySQL:n horisontaaliseen skaalaukseen tarkoitettu tietokantojen klusterointijärjestelmä.

Toinen vaihtoehto (jos se on käytettävissä) on hyödyntää tietokantoihin hallinnoituja palveluita ja määrittää Kubernetesissa toimivat sovelluksesi käyttämään niitä. Tietokantojen käyttäminen hallinnoituna palveluna voi myös vähentää useiden tietokantojen ylläpidon kuormaa, mikä kannustaa pitämään vaikutusalueen pienenä ja rajaamaan mahdollisten ongelmien seurauksia.

Muista: Kubernetes on vain niin hyvä kuin infrastruktuuri, jonka päällä se toimii

Joskus meiltä kysytään, voiko Kubernetesia ajaa on-prem-ympäristössä. Vastaus on kyllä, tavallaan. Todellinen kysymys on: kannattaako niin tehdä?

Se riippuu täysin tarpeistasi ja infrastasi. Kubernetes on vain niin hyvä kuin infrastruktuuri, jonka päällä se toimii. On-prem Kubernetes voi olla vain niin hyvä kuin taustalla oleva laskenta-alusta, jonka päälle se on asennettu. Jos haluat ajaa Kubernetesia on-prem-ympäristössä, kysy itseltäsi, pystytkö tarjoamaan palveluita samalla tasolla kuin pilvipalveluntarjoajat. Kubernetes edellyttää alleen IaaS-kerroksen, joka tarjoaa koneiden automatisoinnin sekä pääsyn tallennukseen ja verkkoihin. Älä siis unohda perusasioita.

Kubernetesin laajentaminen

Monet haluaisivat nähdä Kubernetesissa lisäyksiä ja parannuksia – ikään kuin voisi sekä säästää kakun että syödä sen.

Yleinen toive on monipuolisempi verkkopino. Kubernetesilla on tästä vahva näkemys: se esimerkiksi suosii yhtä omaa IP-osoitetta jokaiselle podille. Vasta hiljattain pääsimme siihen pisteeseen, että käytössä voi olla IPv4- ja IPv6-kaksois-IP-pinot.

Kubernetesia ei myöskään ole tarkoitettu alustaksi, vaan tavaksi rakentaa alustoja. Podit ja RBAC ovat vankkoja ja kypsiä ydinkonsepteja. Täydentävät osat, kuten admission controllerit, edistyneet verkko-ohjaimet ja muut vastaavat, kehittyvät edelleen oppiessamme lisää.

CNCF-maiseman uskomaton noutopöytä

Kun puhutaan Kubernetesin laajentamisesta, ei pidä unohtaa CNCF:n (Cloud Native Computing Foundation) landscapea. Se on erittäin kattava resurssi – mikä saattaa olla vuoden vähättelyä – ja sieltä löytyy paljon hienoa.

On kuitenkin muistettava, että kyseessä on valtava noutopöytä, ei luettelo suositelluista tai ”pakollisista” asioista. Kubernetes on joukko päätöksiä siitä, miten asiat tehdään. CNCF tarjoaa useita vaihtoehtoja samankaltaisiin tarpeisiin, ja monet niistä ovat edelleen kehitysvaiheessa ja kypsyvät.

Kubernetesin avulla voidaan määritellä operaattoreilla uusia työkuormatyyppejä, kuten korkean käytettävyyden Redis-klustereita. Valitettavasti operaattoreihin rakennetaan usein tiukka riippuvuus Kubernetesista. Operaattorit tulisi sen sijaan suunnitella Kubernetesista riippumattomiksi: esimerkiksi Redis-klusterin luomisen logiikan tulisi olla siirrettävissä ja käytettävissä API:n kautta. Se voidaan sitten integroida Kubernetesin kanssa CRD:iden avulla. Näin ratkaisut pysyvät joustavampina.

Mikä CNCF:ssä sitten on dopea?

Keskustelun lopuksi halusimme testata Kelseyn meemeistä tuttua dope-luokittelua: dope, pretty dope, extra dope ja super dope. Pyysimme Kelseytä arvioimaan muutamia kiinnostavia CNCF-projekteja. Tässä muutamia hänen valintojaan (lisää hyvää dopea löydät videolta…):

Vault (salaisuuksien hallinta): super dope

ArgoCD (deklaratiivinen GitOps): super dope

Keda (tapahtumaohjattu automaattinen skaalaus lukuisine lisäosineen): extra dope

Kaikkein superdopein projekti Kubernetesin itsensä jälkeen on Open Policy Agent (OPA). Se ei saa riittävästi tunnustusta siitä, mitä se tekee. Yhdessä Infrastructure as Datan kanssa OPA mahdollistaa käytäntöjen soveltamisen ennen kuin muutokset viedään versionhallintaan ja otetaan käyttöön.

Nopea yhteenveto

Fireside chatissa käsittelimme monia Kubernetesia ja sen tilannetta vuonna 2022 koskevia aiheita. Jos meidän pitäisi tiivistää kaikki kolmeen keskeiseen kohtaan, ne voisivat olla seuraavat:

1. Älä ajattele Kubernetesia enää vain konttien orkestrointialustana. Se on kehittynyt hallintatasoksi, jota voit hyödyntää paljon laajemmin – ja tästä on tullut Kubernetesin supervoima.

2. Kubernetes auttaa siirtymään Infrastructure as Codesta Infrastructure as Dataan ja vapauttamaan putkien todellisen voiman.

3. Voit ajaa Kubernetesin sisällä myös tilallisia palveluita, mutta mieti kahdesti, onko se järkevää. Hallinnoidut palvelut voivat vähentää ylläpidon kuormaa ja auttaa pitämään kokonaisuuden yksinkertaisena.

Kaiken kaikkiaan olemme innoissamme siitä, miten pitkälle Kubernetes on edennyt vuoden 2014 alusta lähtien. Ja odotamme innolla, miten pitkälle se voi kehittyä tulevina vuosina!