Kubernetes Lab

TL;DR

#

Tämä on oma Kubernetes-labini Oracle Cloudissa. Se ei ole pelkkä paikallinen kokeilu, vaan oikeasti ajossa oleva pieni pilviympäristö, jossa harjoittelen kaikkea Kubernetesiin liittyvää.

Klusterin infra rakennetaan OpenTofun avulla, ja Kubernetes-resurssit hallitaan Gitistä FluxCD:llä. Julkinen HTTPS-liikenne kulkee OCI Network Load Balancerin ja Envoy Gatewayn kautta. Mukana ovat myös TLS, DNS, tallennus, mittarit, lokit ja ulkoinen saatavuusseuranta.

Käytännössä labin tarkoitus on näyttää, miten pilvessä ajettava Kubernetes-ympäristö voidaan rakentaa toistettavasti, pitää hallinnassa GitOpsilla ja valvoa ulkopuolelta. Samalla se toimii omana harjoitusympäristönäni, jossa voin testata päivityksiä, julkaisutapoja ja inframuutoksia turvallisesti mutta realistisesti.

Linkit

#

Jos haluat tutustua ympäristöön tarkemmin, tärkeimmät linkit ovat tässä. Koodi kertoo miten ympäristö on rakennettu, Grafana näyttää valittuja mittareita ja status-sivu näyttää ulkoisen saatavuusseurannan.

Miksi tämä lab on olemassa?

#

Halusin ympäristön, jossa Kubernetesiä ei tarvitse opetella vain yksittäisinä komentoina tai paikallisina testeinä. Tavoitteena on pitää yllä pientä mutta todellista kokonaisuutta, jossa samat perusasiat tulevat vastaan kuin isommissakin ympäristöissä: verkko, julkaisu, sertifikaatit, salaisuudet, tallennus, valvonta ja dokumentointi.

Oracle Kubernetes Engine sopii tähän hyvin, koska labia voi ajaa edullisesti ja joissain tapauksissa jopa ilmaiseksi. Samalla ympäristö vastaa melko hyvin tuotantoympäristöä, koska kyseessä on hallittu Kubernetes-palvelu eikä pelkkä paikallinen harjoitusklusteri.

Halusin myös, että labia käytetään pääosin komentoriviltä eikä yksittäisinä klikkauksina pilven käyttöliittymässä. Pilven käyttöliittymä on toki hyödyllinen tarkistamiseen ja hallintaan, mutta tämän labin pääasiallinen työnkulku on koodin, komentorivin ja Gitin ympärillä. Klusterin voi alustaa, validoida, ajaa ylös, purkaa ja rakentaa uudelleen toistettavasti. Myös nodejen päivitys hoituu erillisellä skriptillä.

Mitä tämä osoittaa?

#

Tämän labin kautta olen harjoitellut erityisesti:

• pilvi-infran rakentamista koodina
• Kubernetes-resurssien hallintaa GitOps-mallilla
• HTTPS-reititystä Gateway API:n avulla
• sertifikaattien, DNS:n ja salaisuuksien automatisointia
• pysyvän tallennuksen käyttöä Kubernetesissä
• mittareiden, lokien ja ulkoisen saatavuusseurannan rakentamista
• ympäristön dokumentointia niin, että sen voi ymmärtää ja rakentaa uudelleen

Tärkeintä ei ole yksittäinen työkalu, vaan se että eri osat muodostavat toimivan kokonaisuuden. Infra, GitOps, julkaisu, valvonta ja dokumentaatio tukevat samaa ympäristöä eivätkä jää irrallisiksi kokeiluiksi.

Miten kokonaisuus toimii?

#

Klusterin perusidea on yksinkertainen: infra rakennetaan koodina, sovellukset kuvataan manifesteina ja muutokset viedään sisään Gitin kautta.

Muutokset:
GitHub → FluxCD → Kubernetes-resurssit

Julkinen liikenne:
Internet → OCI Network Load Balancer → Envoy Gateway → Kubernetes Service → Pod

Muutokset tehdään ensin Git-repoon. FluxCD seuraa repoa ja vie klusteria kohti siellä kuvattua tavoitetilaa. Julkinen liikenne taas saapuu ensin OCI Network Load Balancerille, jonka jälkeen Envoy Gateway reitittää HTTPS-liikenteen oikeille Kubernetes-palveluille.

Näin sovellusten julkaisu ja liikenteen reititys pysyvät erillisinä, mutta hallittavina osina samaa kokonaisuutta.

Keskeiset komponentit

#

GitOps-työnkulku

#

Muutokset tehdään ensin GitHubiin. Flux seuraa repoa ja pitää klusterin tilan siellä kuvatun tavoitetilan mukaisena.

Käytännössä uusi palvelu lisätään tekemällä sille manifestit repoon ja viemällä muutos Gitin kautta päähaaraan. Kun muutos on yhdistetty, Flux havaitsee sen ja alkaa sovittaa klusteria uuteen tilaan. Jos jokin menee pieleen, se näkyy sekä Fluxin tilassa että valvontatyökaluissa.

Repo jakautuu pääosin kahteen osaan. terraform/ sisältää labin infran: peruspilviresurssit, OKE-klusterin ja Fluxin käyttöönoton. gitops/ sisältää Kubernetes-puolen: klusterikohtaiset asetukset, infrakontrollerit, lisäosat ja sovellusten manifestit.

Fluxin kanssa repositorion rakenne on valittavissa, kunhan Fluxin Kustomizationit osoittavat oikeisiin polkuihin (lue lisää Fluxin dokumentaatiosta). Tässä repossa klusterikohtainen clusters-hakemisto kokoaa ympäristön Kustomizationit, ja varsinainen klusterin sisältö on jaettu neljään kerrokseen.

Tämä pitää riippuvuudet selkeinä. Ensin asennetaan kontrollerit, sitten niiden asetukset, sen jälkeen tukevat lisäosat ja lopuksi sovellukset.

Mallipohjarepo

#

Varsinainen klusterirepo kuvaa omaa ajossa olevaa ympäristöäni. Sen rinnalle tein erillisen OKE GitOps -mallipohjan, joka toimii siistimpänä lähtöpisteenä vastaavan klusterin rakentamiseen.

Mallipohja ei yritä olla musta laatikko. Rakenteesta pitää nähdä, mitä rakennetaan OpenTofun avulla, mitä Flux asentaa klusteriin ja miten eri kerrokset liittyvät toisiinsa.

Rajaus

#

Tämä on henkilökohtainen labra, ei valmis tuotantoalusta. Pidän ympäristön tarkoituksella pienenä, jotta pystyn ymmärtämään, ylläpitämään ja dokumentoimaan sen kunnolla.

Repo voi toimia hyödyllisenä esimerkkinä, mutta sitä ei ole tarkoitettu kopioitavaksi sellaisenaan tuotantoon. Se heijastaa omaa oppimisympäristöäni, valintojani ja rajoitteitani. Ideoita saa käyttää, mutta kokonaisuutta ei kannata kopioida sokeasti.