Kun Terraform ei enää riitä: control plane -ratkaisujen käyttöönotto

Upboundin perustaja ja toimitusjohtaja Bassam Tabbara kuvasi Crossplane Community Dayn keynotessaan osuvasti, että Kubernetesin supervoimat ovat:

1. deklaratiivinen hallinta halutun tilan perusteella

2. automatisoitu controller-logiikka, joka sovittaa halutun tilan todelliseen tilaan

Tämä toimintamalli on yksi syy siihen, miksi voimme hallita helposti satoja laskentasolmuja ja tuhansia kontteja, niiden välistä verkkoliikennettä, automaattista skaalausta ja niin edelleen.

Toinen syy on se, että deklaratiivinen API toimii hyödyllisellä abstraktiotasolla ilman kognitiivista ylikuormitusta. Kubernetes Deploymentin avulla voimme esimerkiksi määrittää kontti-imagen ja käynnissä olevien replikoiden määrän, minkä jälkeen Kubernetes-controllerit huolehtivat ajoituksesta, monitoroinnista, uudelleenkäynnistyksistä ja muusta.

Justin Garrisonin ja Kris Novan kirja ”Cloud Native Infrastructure” määrittelee Cloud Native Infrastructuren seuraavasti: ”…infrastruktuuri, joka on piilotettu hyödyllisten abstraktioiden taakse ja jota hallitaan ohjelmistolla APIen kautta…”. Kirjassa kuvataan myös reconciler-malli – uuden Control planes -paradigman ydin, jonka odotetaan korvaavan perinteisempiä Infrastructure-as-Code-työkaluja, kuten Terraformin.

Lähde: Bassam Tabbaran keynote, johon viitattiin alussa

Yhdisteltävyys – avain pilven käytön skaalaamiseen

On olennaista, että control planet tarjoavat hyödyllisiä abstraktioita. Pilvialustat ovat valtavia ja monimutkaisia, ja ne tarjoavat tyypillisesti satoja palveluita, joista jokaisessa on lukuisia eri konfiguraatioita ja asetuksia.

Tämä on merkittävä pilven käyttöönottoa rajoittava tekijä. Platform- ja SRE-tiimien voidaan odottaa edistävän pilven käyttöä, mutta kaikkien kehittäjien osaamisen kehittäminen pilven hyödyntämiseen ei yleensä skaalaudu. Kun ”keskivertokehittäjä” katsoo pilveä, hän saattaa nähdä tämän: paljon erikokoisia ja -värisiä rakennuspalikoita:

…vaikka todellisuudessa hän haluaisi vain seuraavan, jossa ainoa valinnanvara on väri:

Pilvialustan yleiskäyttöisyys tarkoittaa, ettei se tarjoa oikeaa abstraktiota suurimmalle osalle kehittäjistä. Kubernetes API tarjoaa abstraktion laskentasolmuista, Dockerin kaltaisista container runtimeista, verkkoyhteyksistä ja tallennuksesta. Tämä helpottaa sovellusten käyttöönottoa ja operointia konttiklusterissa huomattavasti.

Yhdisteltävyys tarkoittaa kykyä rakentaa korkeamman tason abstraktioita alemman tason abstraktioiden avulla, ja se on avain minkä tahansa teknologian – myös pilven – käyttöönoton skaalaamiseen. Mutta älä luota vain sanaani, vaan katso, mitä Kelsey Hightower kertoo Crossplanesta ja yhdisteltävyydestä.

Terraformin kasvukivut

Terraformissa yhdisteltävyys toteutuu moduuleina. Terraform-moduulien käyttö on suuri harppaus eteenpäin, mutta ne ovat vain malleja, jotka tuottavat kaikki pienemmät komponentit. Moduuleista rakennettujen alustojen hallinta muuttuu nopeasti pienempien komponenttien hallinnaksi – Terraform-moduulit ovat erittäin vuotava abstraktio.

Suurten monoliittisten infrastruktuurien hallinta on hankalaa. Tätä korjataan usein pilkkomalla infrastruktuuri pienempiin osiin eli ”kerrosarkkitehtuuriin”, jossa jokainen osa on itsenäinen Terraform plan ja kerrosten välisiä riippuvuuksia hallitaan remote staten avulla.

Vaikka tämä on monoliittista arkkitehtuuria parempi ratkaisu, se on silti hauras ja edellyttää riippuvuuksien vuoksi yksittäisten kerrosten manuaalista orkestrointia.

Terraform on suunniteltu työkaluksi, jota ajetaan tarvittaessa aina, kun infrastruktuuria halutaan päivittää. Terraformin automatisointiin käytetään usein esimerkiksi Atlantisia, joka tuo Terraformiin GitOps/ChatOps-mallin. Tämä ei kuitenkaan havaitse driftia eikä korjaa viallisia infrastruktuurikomponentteja. Meidän on tunnistettava tällaiset tilanteet manuaalisesti ja ajettava Terraform uudelleen, koska malli on tapahtumapohjainen eikä perustu control planen reconciliation loopiin.

Käyttöoikeuksien hallinnassa GitOps-malli tarkoittaa, että jokainen source Git -repositorioomme pääsevä voi muuttaa infrastruktuuriamme. Emme voi erotella, kuka saa tehdä mitäkin meille mielekkään abstraktiotason perusteella. Voimme yrittää suunnitella Terraformin ajamiseen identiteettejä, kuten IAM-rooleja, joilla on eriytetyt oikeudet, mutta koska tämä perustuu pilven taustalla olevaan resurssimalliin, sen toteuttaminen oikein on hyvin vaikeaa.

Tämä palautuu siihen, että Terraform-moduulit ovat vuotavia abstraktioita. Sen sijaan haluamme, että käyttöoikeuksien hallinta määritellään sillä abstraktiotasolla, jolla toimimme. Kubernetesissa RBAC-malli koskee resursseja, kuten Deploymenteja ja Podeja namespacejen välillä, eikä meidän tarvitse välittää siitä, miten kontit ajoitetaan laskentasolmuille tai miten verkkojen eriyttäminen toteutetaan IP-tablesilla.

Katso myös, mitä Upboundin Nic Cope sanoo Terraformista ja Crossplanesta – hän ilmaisee asian paljon minua paremmin.

Voita muutosvastarinta

Control planejen käyttö tarkoittaa kontrollista luopumista. Siksi kokeneet SRE-tiimit saattavat epäröidä control planen luotettavuutta. Vaikka meidän on vielä nähtävä, miten esimerkiksi Crossplane pärjää tositilanteessa, otamme control planet lopulta käyttöön myös pilvessä. Yksityiskohtiin takertumatta, ne abstrahoimalla ja ”koneiden” annetaan hoitaa ne – se on luonnollinen kehitys teknologiassa.

Olemme nähneet tämän kehityksen käyttöjärjestelmistä ja kääntäjistä aina Kubernetesin kaltaisiin konttialustoihin asti. Koska tämä on väistämätön kehityssuunta, control planet kannattaa ottaa omakseen. Jos Crossplane ei löydä oikeaa tasapainoa ja abstraktiotasoa, seuraava control plane löytää.

Infrastruktuuria koskevan ajattelumallin muuttaminen

Ops- ja SRE-tiimit voivat pohtia, miten ne voivat varmistaa käytettävyyden ja saatavuuden, kun hallintatasot toimivat ”eventual consistency” -mallilla.

Huoli on aiheellinen, ja se tuo esiin toisen yleisen anti-patternin nykyisissä infrastruktuurisuunnitelmissa. Monilla organisaatioilla on esimerkiksi dev-, stage- ja production-Kubernetes-klusterit. Jos esimerkiksi muutamme production-klusterin tavoitetilaa, miten voimme taata, etteivät loppukäyttäjät koe sovelluksiemme olevan poissa käytöstä, kun hallintataso – johon meillä on suunnittelun vuoksi hyvin vähän vaikutusvaltaa – yhdenmukaistaa uuden tilan? Huoli on aiheellinen, mutta kysymys on väärä!

Huoli johtuu siitä, että production-klusterimme on lemmikki, ei karjaa.

Kubernetesin myötä opimme siirtymään yksittäisistä lemmikkipalvelimista karjamaisiin kontteihin: Kubernetes huolehti ominaisuuksista, kuten käytettävyydestä ja saatavuudesta, orkestroimalla useita kontteja. Seuraavaksi meidän on opittava soveltamaan samaa mallia koko infrastruktuuriin.

Emme saisi suunnitella yhden ainoan production-klusterin varaan. Sen sijaan meidän tulisi ymmärtää, että meillä voi milloin tahansa olla useita production-klustereita, ja huomioida tämä suunnittelussa – aivan kuten pidämme Kubernetes Deployments- ja Services-resursseja itsestäänselvyyksinä ja annamme Kubernetes Control planen huolehtia yksittäisten konttien hallinnan monimutkaisuudesta sekä sovelluksemme kokonaisominaisuuksista.