Aloita Kubernetesin käyttö hyvin

Kun aloitat Cloud Native -matkasi, sinun on tehtävä tärkeitä valintoja pilvipalveluntarjoajien, Continuous Deploymentin sekä ympäristöjen määrittelyn ja eriyttämisen suhteen. Tämä opas auttaa sinua tekemään oikeat valinnat jakamalla tuotannossa ajettavista Cloud Native -sovelluksista opittuja asioita.

Kubernetesista on tullut konttien orkestroinnin de facto -alusta. Kun autamme eri kokoisia ja eri toimialoilla toimivia asiakkaita aloittamaan Cloud Native -matkansa Kubernetesin parissa, tuemme heitä perusteltujen päätösten ja teknologiavalintojen tekemisessä. Pilvipalveluntarjoajien, CI-työkalujen, Continuous Deployment -putkien ja muiden ratkaisujen valintaan ei ole yhtä kaikille sopivaa vaihtoehtoa, joten oikeiden päätösten tekeminen heti alussa on tärkeää. Muuten menetetty aika ja raha voivat tulla kalliiksi.

Tässä blogissa käymme läpi tärkeitä asioita, joita kohtaat tehdessäsi päätöksiä ja teknologiavalintoja Kubernetesin käyttöönoton alkuvaiheessa. Kirjoitus on suunnattu kaikille, jotka ovat aloittamassa Cloud Native- ja Kubernetes-matkaansa, sekä niille, jotka ovat jo aloittaneet ja haluavat varmistaa valintojensa toimivuuden.

Valitse oikea alusta

Kubernetes-klustereita voi hallinnoida itse tai pilvipalveluntarjoaja voi hallinnoida niitä. Nyrkkisääntönä kannattaa käyttää hallinnoitua Kubernetes-palvelua, ellei on-premises-ympäristössä itse hallinnoidulle klusterille ole painavaa teknistä tai juridista syytä. Itse hallinnoidut klusterit edellyttävät tiimiltä erittäin erikoistunutta osaamista sekä jatkuvia infrastruktuuri- ja ylläpitokustannuksia.

Jos valitset hallinnoidun Kubernetes-palvelun, varmista, että valitset oikean palveluntarjoajan. Valintaan vaikuttavat muun muassa seuraavat tekijät:

• Tiimisi tuntemus palveluntarjoajan palveluista.

• Palveluntarjoajan hallinnoidun Kubernetes-ratkaisun kypsyys sekä sen ominaisuudet ja tekniset rajoitukset. Esimerkiksi se, tukeeko ratkaisu alueellista redundanssia tai klusterin automaattista skaalautumista. Lisäksi on tärkeää selvittää, tukeeko se podien tietoturvakäytäntöjä ja verkkokäytäntöjä.

• Tarvitsetko muita saman palveluntarjoajan pilvipalveluita? Jos sovelluksesi esimerkiksi tarvitsee AWS:n DynamoDB-tietokannan, kannattaa käyttää AWS EKS:ää samalla alueella kuin DynamoDB-tietokantaa. Näin voit vähentää datan käytön viivettä.

• Palveluntarjoajan hinnoittelu, SLA ja tukipaketit.

Yleisesti ottaen, jos tarvitset yksinkertaisen Kubernetes-klusterin, mikä tahansa kolmesta suuresta pilvipalveluntarjoajasta – AWS, Google tai Azure – sopii hyvin. Kokemuksemme mukaan Googlen GKE on kuitenkin helpoin ottaa käyttöön, ja se on markkinoiden kypsin hallinnoitu Kubernetes-ratkaisu.

Päätä, miten erotat ympäristöt toisistaan

Useimmiten käytössäsi on vähintään kaksi ympäristöä: dev/test ja prod. Miten ne kannattaa erottaa Kubernetesissa? Vaihtoehtoja on kaksi: yksi klusteri ympäristöä kohden tai yksi namespace ympäristöä kohden. Namespacejen käyttäminen ympäristöjen erottamiseen pienentää kustannuksia, koska infrastruktuuri on yhteinen. Se on kuitenkin riskialttiimpaa kehittäjien ja operaattoreiden inhimillisten virheiden vuoksi. Virheiden ja käyttöoikeusongelmien välttäminen on mahdollista, mutta se edellyttää tiimiltä vahvaa osaamista toteutuksessa ja seurannassa. Infrastruktuurikustannusten ja käyttöoikeuksien hallintaan sekä tietoturvaan tarvittavan työmäärän välillä on tehtävä kompromissi.

Pienille tiimeille suosittelemme yhtä klusteria kutakin ympäristöä kohden.

Voit myös sijoittaa klusterit erillisiin virtuaalisiin tai fyysisiin verkkoihin ja/tai erillisiin pilviprojekteihin tai -tileihin. Tämä luo selkeämmän erottelun, jonka avulla voit ylläpitää tiukkoja käyttöoikeuksia prod-ympäristöihin ja samalla kokeilla Kubernetes-asetuksia dev-klusterissa. Näin voit turvallisesti ottaa käyttöön tiettyjä Kubernetes-ominaisuuksia tai testata uudempia Kubernetes-versioita.

Standardoi k8s-asetuksesi

Kun olet valinnut alustan Kubernetes-klustereiden käyttöönotolle, seuraava kysymys on, miten otat klusterit käyttöön ja ylläpidät niitä. Useimmissa tapauksissa sinun on hallittava useampaa kuin yhtä klusteria, joten on tärkeää välttää niiden välistä konfiguraatioiden eriytymistä. Sinulla voi esimerkiksi olla dev- ja prod-klusterit, ja haluat varmistaa, että niiden konfiguraatiot ovat samat ja että niiden noodeilla on samat käyttö- ja todennusoikeudet muihin pilvipalveluihin. Tämä on tärkeää, koska siirrät dev-ympäristössä käyttöön otetun sovelluksesi prod-ympäristöön etkä halua kohdata ikäviä yllätyksiä.

Suosittelemme tähän infrastructure as code -lähestymistapaa, jossa määrittelet klusterin konfiguraation koodina ja ylläpidät konfiguraatioita versionhallintajärjestelmässä. Kun klusterikonfiguraatio on koodina, voit luoda uuden, identtisen klusterin jonkin uuden asian testaamista varten häiritsemättä kehittäjien työnkulkua.

Suosittelemme myös käyttämään putkea klustereiden käyttöönottoon ja ylläpitoon versionhallinnassa olevien konfiguraatioiden muutosten perusteella. Tätä kutsutaan usein nimellä GitOps.

Käsittele apuohjelmia infrastruktuurina

Apuohjelmat ovat kolmannen osapuolen työkaluja tai palveluita, jotka otat käyttöön klusterissasi. Näitä voivat olla esimerkiksi Prometheuksen kaltaiset monitorointityökalut tai SSL-varmenteiden hallintatyökalut, kuten cert-manager. Apuohjelmia tulisi käsitellä osana infrastruktuuria: ne otetaan käyttöön koodista klusteria luotaessa, ja niitä ylläpidetään klusterin tavoin putken avulla. Se voi olla jopa erillinen työ samassa putkessa, joka luo klusterin. Etuna on, että voit helposti luoda klusterin uudelleen tai kopioida sen kaikkine kolmannen osapuolen apuohjelmineen. Oma avoimen lähdekoodin työkalumme Helmsman soveltuu kolmannen osapuolen apuohjelmasovellusten käyttöönoton orkestrointiin.

Käytä namespaceja oikein

Kubernetes-namespacet ovat virtuaalisia erottimia yhden klusterin sisällä. Niitä käytetään usein tiimien ja sovellusten erottamiseen. Huomioi namespaceja käyttäessäsi seuraavat asiat:

• Moniasiakasklusterissa anna kehittäjille pääsy vain niihin namespaceihin, joita he tarvitsevat. Hyödynnä tähän Kubernetes RBACia.

• Secrets ovat namespace-kohtaisia objekteja, eikä niihin voi päästä käsiksi toisesta namespacesta. Jos useat eri namespaceihin käyttöönotetut sovellukset tarvitsevat pääsyn samoihin salaisuuksiin, sinun on joko a) otettava sovellukset käyttöön samassa namespacessa, b) kopioitava salaisuudet namespacejen välillä ja pidettävä ne synkronoituna manuaalisesti tai, mikä vielä parempaa, c) käytettävä salaisuuksien hallintatyökalua, kuten Vaultia.

• Voit määrittää resurssikiintiöt namespace-kohtaisesti. Näin voit asettaa rajoituksia tiimeille tai sovellusryhmille.

• Voit käyttää verkkokäytäntöjä) sallimaan tai estämään liikenteen eri namespaceihin käyttöönotettujen sovellusten välillä.

• Kubernetes-resurssien nimet (esim. deploymentit, podit jne.) ovat yksilöllisiä namespacen sisällä. Voit siis joko ottaa saman sovelluksen eri versiot käyttöön eri namespaceissa tai tehdä resurssien nimistä dynaamisia. Tämä onnistuu paketoimalla sovelluksesi Helmillä.

Helm-deployment

Helm on Kubernetesin paketinhallintatyökalu. Sen avulla voit paketoida ja jakaa määritettäviä Kubernetes-deployment-malleja sovelluksillesi. Suosittelemme käyttämään Helmiä sovellusten käyttöönotossa pelkkien Kubernetes YAML -mallien sijaan. Helm-paketit eli chartit mahdollistavat mallien uudelleenkäytön konfiguraatioparametrien avulla. Näin voit ottaa sovelluksestasi helposti käyttöön useita instansseja eri ympäristöihin eri asetuksilla ilman päällekkäistä koodia tai malleja.

Helm 2.x edellyttää, että klusteriin otetaan käyttöön palvelinpuolen komponentti nimeltä Tiller. Helm 3.0 poistaa Tillerin, mutta se on tällä hetkellä alpha-julkaisu. Koska käytät toistaiseksi Helm 2.x:ää, sinun on mietittävä, miten otat Tillerin käyttöön ja suojaat sen. Huomioi seuraavat asiat:

• Tillerillä on täydet käyttöoikeudet klusteriin. Varmista siis, että noudatat sen käyttöönotossa suositeltuja tietoturva-asetuksia.

• Suosittelemme sisällyttämään Tiller-deploymentin klusteriputkeesi. Tämä helpottaa klusteriasetusten kopiointia sekä katastrofipalautumista. Avoimen lähdekoodin työkalullamme Helmsmanilla voit ottaa käyttöön suojattuja Tillereitä.

• Ota usean vuokralaisen klusterissa käyttöön yksi Tiller tiimiä kohden sen omassa namespacessa ja määritä RBAC rajaamaan Tillerin käyttöoikeudet vain kyseiseen namespaceen.

Sovellusten Continuous Deployment (CD)

Sovellusten tiheää julkaisemista pidetään hyvänä käytäntönä, sillä se vähentää epäonnistumisriskejä ja nopeuttaa palautumista häiriötilanteista (lähde: The state of DevOps report 2019). Kun käytät Kubernetesia ja Helmiä, tarvitset automatisoidun putken, joka ottaa muutoksesi jatkuvasti käyttöön K8S:ään.

Kuva 1 esittää tyypillisen CD-putken K8S:ään käyttöönotetuille Cloud Native -sovelluksille.

Kun suunnittelet putkeasi, mieti, miten haluat edistää sovelluksen dev/test-ympäristöstä prod-ympäristöön. Voit tehdä tämän yhdellä putkella manuaalisia hyväksyntöjä käyttäen tai jakaa dev- ja prod-putket erilleen. Yhtä kaikille sopivaa ratkaisua ei ole, mutta pyri aina käyttämään yksinkertaisinta putkikonfiguraatiota, kunnes sinulla on hyvät syyt tehdä siitä monimutkaisempi. Huomioi myös kehittäjien helppous työnkulkua suunnitellessasi. Jos kehittäjän on esimerkiksi tehtävä muutoksia useaan repoon saadakseen pienen bugikorjauksensa prodiin, työnkulku ei todennäköisesti ole riittävän helppo kannustaakseen nopeisiin ja tiheisiin deploymenteihin.

Helm-chartit ja -repot

Kun paketoit sovelluksiasi Helm-charteiksi, huomioi seuraavat asiat:

• Jos useilla sovelluksilla/palveluilla on identtiset tai hyvin samankaltaiset Kubernetes-deployment-mallit (esim. deployment, service ja ingress), luo jaettu chart, joka voidaan konfiguroida palvelemaan kaikkia näitä sovelluksia. Näin voit keskittyä yhden chartin kehittämiseen ja vahvistamiseen useiden samankaltaisten chartien sijaan.

• Miten hallitset Helm-chartejasi? Ja miten jaat niitä tarvittaessa sisäisesti tai ulkoisesti?

Kannattaa myös miettiä, missä tallennat Helm-charttisi ja miten käytät niitä. Yleisesti käytetään kolmea mallia:

1) Pidä Helm-chart-hakemisto osana sovelluksesi VCS-repoa.

Tämän lähestymistavan etuna on, että kaikki on yhdessä paikassa. Haittoja ovat kuitenkin:

• monimutkainen putken toteutus, jotta voit versioida ja julkaista chartin erikseen sovelluksesta (ellet päätä julkaista chartia ja sovellusta aina yhdessä, vaikka chart ei olisi muuttunut).

• Jos muita sovelluksia (muissa VCS-repoissa) otetaan käyttöön samalla chartilla, repoissasi on päällekkäistä koodia.

• Et voi jakaa chartiasi antamatta pääsyä sovelluksesi VCS-repoon.

2) Pidä Helm-charteille erillinen VCS-repo ja tarjoa ne Helm-reposta.

Tämän lähestymistavan etuja ovat:

• Versioidut chartit, joita tarjotaan julkisista tai yksityisistä Helm-repositorioista.

• Mahdollisuus käyttää samaa chartia useissa sovelluksissa silloin, kun se sopii, ilman koodin kahdentamista.

Tämän lähestymistavan suurin haittapuoli on, että jos sovelluksesi muuttuu tavalla, joka edellyttää muutosta Helm-chartiin, sinun on ensin tehtävä muutos Helm-chartiin erikseen ja vasta sitten otettava sovelluskoodin muutos käyttöön.

3) Koska chartien muutokset ovat yleisiä sovelluskehityksen alkuvaiheessa, voit yhdistää lähestymistapoja 1 ja 2 sovelluskehityksen eri vaiheissa. Ensimmäistä lähestymistapaa voi käyttää alussa, ja kun sovellus vakiintuu, voi siirtyä toiseen lähestymistapaan.

Vaikka edellä kuvatuissa malleissa on toimivia vaihtoehtoja eri tilanteisiin, valinnan tulisi perustua käyttötapaukseesi sekä kunkin vaihtoehdon etujen ja haittojen punnitsemiseen.

Klusterin tilan ylläpito

On tärkeää varautua vikatilanteisiin. Kannattaa pohtia esimerkiksi seuraavia tilanteita: mitä tapahtuu, kun sovelluksia poistetaan? Entä jos koko klusteri poistetaan? Mitä jos haluamme luoda klusterista samanlaisen kopion toiselle pilvialueelle?

Jotta olet valmis kaikkiin näihin tilanteisiin, klusterin tila on varmuuskopioitava ja tallennettava turvalliseen paikkaan. Onneksi tähän on saatavilla työkaluja. Olemme käyttäneet menestyksekkäästi VMWaren Veleroa. Velero mahdollistaa klusterin tilan (deploymentit, volumet jne.) säännöllisen varmuuskopioinnin ja tallentamisen pilvitallennustilaan. Klusterin snapshotteja voi käyttää klusterin tilan palauttamiseen milloin tahansa. Mutta mitä jos itse klusteri täytyy luoda uudelleen? Jos otat klusterin käyttöön koodista, kuten edellä käsittelimme, voit luoda klusterin uudelleen samalla versionhallintaan tallennetulla koodilla, jolla loit sen alun perin, ja palauttaa sen tilan Velero-snapshotin avulla.

Lopuksi

Alussa on helppoa ja houkuttelevaa oikaista. Se on aivan hyväksyttävää oppimis- ja kokeiluvaiheessa. Kun kuitenkin alat rakentaa Kubernetes-ympäristöjäsi, varmista, että teet asiat heti alusta alkaen oikein, vaikka se vaatisi enemmän aikaa ja vaivaa. Se maksaa itsensä takaisin tulevaisuudessa!