[{"content":" 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ää.\nKlusterin 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.\nKä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.\nLinkit # 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.\nOsa Linkki Kuvaus Klusterirepo oke-gitops-cluster Ajossa olevan OKE-labin infra- ja GitOps-rakenne. Mallipohja oke-gitops-template Yleiskäyttöisempi lähtöpiste vastaavan klusterin rakentamiseen. Grafana public dashboard Rajattu julkinen näkymä klusterin mittareihin. Status status.hanhela.org Ulkoinen saatavuusseuranta valituille palveluille. 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.\nOracle 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.\nHalusin 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ä.\nMitä tämä osoittaa? # Tämän labin kautta olen harjoitellut erityisesti:\npilvi-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.\nMiten kokonaisuus toimii? # Klusterin perusidea on yksinkertainen: infra rakennetaan koodina, sovellukset kuvataan manifesteina ja muutokset viedään sisään Gitin kautta.\nMuutokset: 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.\nNäin sovellusten julkaisu ja liikenteen reititys pysyvät erillisinä, mutta hallittavina osina samaa kokonaisuutta.\nKeskeiset komponentit # Osa Komponentit Kuvaus Kubernetes-alusta OKE Hallittu Kubernetes-klusteri Oracle Cloudissa. IaC OpenTofu Rakentaa OCI-verkon, OKE-klusterin ja tukiresurssit. GitOps FluxCD Pitää klusterin tilan Git-repon mukaisena. Julkinen liikenne OCI Network Load Balancer, Envoy Gateway, Gateway API Reitittää julkisen HTTPS-liikenteen palveluille ilman perinteisiä Ingress-resursseja. TLS ja DNS cert-manager, ExternalDNS, Cloudflare DNS-01 Luo TLS-sertifikaatit ja hallitsee DNS-tietueita automaattisesti. Salaisuudet OCI Vault, External Secrets Operator Säilyttää salaisuudet OCI Vaultissa ja synkronoi ne Kubernetesiin. Tallennus Longhorn Tarjoaa pysyvän tallennuskerroksen klusterin sisällä. Mittarit ja lokit Prometheus, Grafana, Loki, Alloy Kerää mittarit ja lokit sekä näyttää ne dashboardeissa. Uptime-seuranta Better Stack Valvoo palveluiden saatavuutta klusterin ulkopuolelta. GitOps-työnkulku # Muutokset tehdään ensin GitHubiin. Flux seuraa repoa ja pitää klusterin tilan siellä kuvatun tavoitetilan mukaisena.\nKä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.\nRepo 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.\nFluxin 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.\nOsa Kuvaus Controllers Klusterin kontrollerit, kuten cert-manager, Envoy Gateway, External Secrets Operator, Longhorn ja metrics-server. Configs Kontrollerien käyttämät asetukset, kuten Gatewayt, ClusterIssuerit, ExternalSecretit ja StorageClassit. Addons Avustavat komponentit, kuten ExternalDNS, kube-prometheus-stack, Loki, Alloy ja Better Stack heartbeat. Apps Varsinaiset sovellukset ja testipalvelut. Tämä pitää riippuvuudet selkeinä. Ensin asennetaan kontrollerit, sitten niiden asetukset, sen jälkeen tukevat lisäosat ja lopuksi sovellukset.\nMallipohjarepo # 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.\nMallipohja ei yritä olla musta laatikko. Rakenteesta pitää nähdä, mitä rakennetaan OpenTofun avulla, mitä Flux asentaa klusteriin ja miten eri kerrokset liittyvät toisiinsa.\nRajaus # 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.\nRepo 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.\n","date":"04.06.2026","externalUrl":null,"permalink":"/fi/posts/kubernetes-lab/","section":"Kirjoitukset","summary":"OKE-pohjainen Kubernetes-lab, jossa käytetään GitOpsia, Gateway API:a, observability-työkaluja ja muutamia julkisia testipalveluita.","title":"Kubernetes Lab","type":"posts"},{"content":"Tämän blogin voisi julkaista paljon helpomminkin. Simppeli Hugo-blogi sopii hyvin esimerkiksi GitHub Pagesiin tai Cloudflare Pagesiin, eikä sen ajaminen Kubernetes-klusterissa todellakaan ole kovin järkevää korkean ylläpitokuorman takia.\nTässä tapauksessa tarkoitus oli kuitenkin ajaa blogia samalla tavalla kuin muitakin klusterin pieniä palveluita. Sivusto rakennetaan kontti-imageksi, image julkaistaan GitHub Container Registryyn ja Flux asentaa sovelluksen Kubernetes-klusteriin Helm-chartin avulla.\nKoodi löytyy kahdesta reposta:\nhanhela.org oke-gitops-cluster Ensimmäinen repo sisältää itse blogin: Hugo-sisällön, teeman asetukset, Dockerfile-tiedoston, GitHub Actions -workflow\u0026rsquo;n ja Helm-chartin. Toinen repo sisältää klusterin GitOps-konfiguraation, eli sen miten sovellus ajetaan OKE-klusterissa.\nEn käy tässä postauksessa läpi jokaista YAML-tiedostoa. Ne löytyvät repoista. Tämä on lyhyt kuvaus siitä, miten kokonaisuus toimii ja miksi osat on jaettu näin.\nKokonaisuus lyhyesti # Julkaisuketju on melko suoraviivainen:\nHugo source -\u0026gt; GitHub Actions -\u0026gt; GHCR -\u0026gt; Flux -\u0026gt; HelmRelease -\u0026gt; Kubernetes Kun blogin lähdekoodi muuttuu, GitHub Actions rakentaa uuden image-version ja julkaisee sen GitHub Container Registryyn. Koska klusteri käyttää Oracle Cloudin Ampere A1 -nodeja, image rakennetaan myös linux/arm64-arkkitehtuurille.\nKlusterin puolella Flux seuraa GitOps-repoa. Kun blogin HelmRelease tai sen arvot muuttuvat, Flux sovittaa klusterin tilan vastaamaan repossa olevaa määrittelyä. Käytännössä en siis asenna blogia käsin omalta koneeltani, vaan muutos kulkee Gitin kautta.\nHugosta ajettavaksi imageksi # Hugo rakentaa sivuston staattisiksi tiedostoiksi. Ajossa blogi ei tarvitse Hugoa, Go-työkaluja tai lähdekoodia. Se tarvitsee vain web-palvelimen, joka tarjoilee valmiin public/-hakemiston.\nSiksi image rakennetaan kahdessa vaiheessa. Ensin Hugo tekee staattisen sivuston. Sen jälkeen valmis sivusto kopioidaan nginxin tarjoiltavaksi. Runtime-vaiheessa kontti on vain nginx ja staattiset tiedostot.\nTämä pitää ajettavan imagen yksinkertaisena. Kubernetesin näkökulmasta blogi on tavallinen HTTP-palvelu: podi kuuntelee porttia 8080, Service ohjaa liikenteen podille ja Gateway hoitaa julkisen sisääntulon.\nHelm-chart sovelluksen mukana # Blogin Helm-chart on samassa repossa kuin itse sovellus. Se kuvaa sovelluksen perusrakenteen: Deploymentin, Servicen, probet, resurssipyynnöt ja PodDisruptionBudgetin.\nKlusterikohtaiset asetukset ovat GitOps-repossa. Siellä määritellään esimerkiksi imagen repository, tagi, replikamäärä, resurssirajat ja julkinen hostname. Tämä jako on selkeä: sovellusrepo kertoo, millainen sovellus on, ja GitOps-repo kertoo, miten juuri tämä klusteri ajaa sitä.\nChart voi luoda blogille myös HTTPRouten. GitOps-repossa HelmReleaselle annetaan tämän klusterin arvot: käytettävä Gateway, hostname ja imagen asetukset.\nYksinkertaisen blog.example.com-julkaisun olennaiset HelmRelease-arvot voisivat näyttää tältä:\nvalues: fullnameOverride: blog image: repository: ghcr.io/example/blog tag: main pullPolicy: Always gateway: enabled: true routes: - name: public parentRefs: - name: public namespace: envoy-gateway-system sectionName: https hostnames: - blog.example.com Sama mekanismi taipuu tarvittaessa myös apex-domainiin. Chart tukee useampaa routea, joten yksi route voi ohjata example.com-osoitteen Serviceen ja toinen route voi uudelleenohjata blog.example.com- tai www.example.com-osoitteet takaisin apex-domainiin.\nTällaiselle blogille Helm ei ole teknisesti pakollinen. Yksinkertainen Deployment ja Service riittäisivät. Käytän sitä silti, koska sama malli sopii myöhemmin muihinkin sovelluksiin. Pieni blogi on hyvä paikka pitää julkaisutapa kunnossa ilman, että itse sovellus monimutkaistaa asiaa.\nReititys ja DNS # Blogin kontti tarjoilee HTTP:tä vain klusterin sisällä. TLS, julkiset hostnamet ja sisääntuleva liikenne hoidetaan Gateway API:n kautta.\nYksinkertaisessa tapauksessa liikenne kulkee näin:\nblog.example.com -\u0026gt; Cloudflare DNS -\u0026gt; OCI Load Balancer -\u0026gt; Envoy Gateway -\u0026gt; Service -\u0026gt; Pod Gateway itse kuuluu klusterille. Blogin chart luo vain sovelluksen oman reitin silloin, kun GitOps-repo kytkee sen päälle Helm-arvoilla. Silloin blogikerros pysyy pienenä: namespace, Fluxin GitRepository, HelmRelease ja Kustomization riittävät.\nExternalDNS tekee Cloudflareen tarvittavan DNS-recordin Kubernetes-resurssien perusteella. Tämä on mukavaa arjessa, koska hostname ei jää käsin kliksutelluksi asetukseksi Cloudflaren käyttöliittymään. Se elää samassa GitOps-prosessissa kuin muukin klusterin reititys.\nMitä tästä jäi käteen # Staattinen sivusto ei tarvitse Kubernetes-klusteria, eikä tämä postaus yritä väittää muuta. Monelle Hugo-blogille GitHub Pages tai Cloudflare Pages olisi järkevämpi ja kevyempi ratkaisu.\nTässä projektissa blogi toimii pienenä, julkisena sovelluksena, jolla voin harjoitella ja testata koko julkaisuputkea. Muutos lähtee Gitistä, image rakentuu automaattisesti, Flux vie sen klusteriin ja liikenne ohjautuu Gatewayn kautta ulos.\nHyödyllisin osa on vastuiden jako. Blogirepo sisältää sovelluksen. GitOps-repo sisältää klusterin tavan ajaa sitä. Helm-chart antaa sovellukselle toistettavan muodon, tarvittaessa myös reitityksen. Gateway ja ExternalDNS hoitavat julkaisun ulospäin.\nKun tämä toimii yksinkertaisella Hugo-blogilla, samaa mallia voi käyttää myös muissa pienissä palveluissa. Blogi on tässä hyvä harjoituskohde juuri siksi, että se on teknisesti yksinkertainen ja sen toimivuus on helppo tarkistaa selaimella.\n","date":"08.06.2026","externalUrl":null,"permalink":"/fi/posts/hugo-blogin-julkaisu-kubernetesiin-helmilla-ja-gitopsilla/","section":"Kirjoitukset","summary":"Kuvaus siitä, miten tämä Hugo-blogi paketoidaan kontti-imageksi, julkaistaan Helm-chartilla ja ajetaan Kubernetesissä Fluxin hallitsemana sovelluksena.","title":"Hugo-blogin ajaminen Kubernetesissä Helmillä ja GitOpsilla","type":"posts"},{"content":"Halusin testata, mitä Kubernetes-klusterissani oikeasti tapahtuu, kun yksi worker-node vaihdetaan lennossa. Pelkkä podien lopullinen tila ei vielä kerro, miltä huolto näyttää palvelun käyttäjän näkökulmasta. Siksi ajoin testin ulkopuolelta julkista palvelua vasten.\nTesti tehtiin Kubernetes Labissä. Julkinen liikenne kulki OCI Network Load Balancerin kautta Envoy Gatewaylle, ja sieltä edelleen whoami-palveluun.\nKlusterissa oli siis kolme worker-nodea, Longhorn storage ja FluxCD hoitamassa manifestien sovitusta. whoami ei itsessään käytä Longhornia, mutta Longhorn oli testissä mukana siksi, että noden vaihto vaikuttaa koko klusteriin. Jos storage jää huonoon tilaan, node replacement ei ole oikeasti onnistunut, vaikka testipalvelu sattuisikin vastaamaan.\nTavoite oli yksinkertainen: vaihdetaan yksi node ja katsotaan, tuleeko julkiseen HTTP-liikenteeseen katkoksia.\nLähtötilanne # Ennen testiä tarkistin, että klusteri oli terve:\nkubectl get nodes -o wide kubectl -n envoy-gateway-system get ds,pods -o wide kubectl -n whoami get ds,pods -o wide kubectl -n longhorn-system get volumes.longhorn.io flux get kustomizations -n flux-system Lähtötilassa kaikki näytti hyvältä: nodet olivat Ready, Envoy Gateway oli asetettu DaemonSetiksi, whoami-podeja oli kolme ja Longhorn-volyymit olivat terveitä.\nAjoin whoami-palvelua vasten pientä shellillä tehtyä curl-looppia:\nwhile true; do ts=\u0026#34;$(date --iso-8601=seconds)\u0026#34; tmp=\u0026#34;$(mktemp)\u0026#34; metrics=\u0026#34;$(curl -sS -m 3 -o \u0026#34;$tmp\u0026#34; \\ -w \u0026#39;code=%{http_code} time=%{time_total}\u0026#39; \\ https://whoami.hanhela.org/ 2\u0026gt;\u0026amp;1)\u0026#34; rc=$? if [ \u0026#34;$rc\u0026#34; -eq 0 ] \u0026amp;\u0026amp; printf \u0026#39;%s\u0026#39; \u0026#34;$metrics\u0026#34; | grep -q \u0026#39;code=200\u0026#39;; then host=\u0026#34;$(sed -n \u0026#39;s/^Hostname: //p\u0026#39; \u0026#34;$tmp\u0026#34; | head -1)\u0026#34; echo \u0026#34;$ts OK $metrics host=$host\u0026#34; else echo \u0026#34;$ts FAIL rc=$rc $metrics\u0026#34; fi rm -f \u0026#34;$tmp\u0026#34; sleep 1 done | tee /tmp/whoami-ha-test.log Tämän pitäisi kertoa sekunnin välein, tuliko HTTP 200 vai timeout, ja mikä whoami-podi vastasi.\nNode vaihtoon # Noden vaihto tehtiin omalla skriptillä, joka vaihtaa OKE-node poolista yhden noden kerrallaan. Ennen varsinaista ajoa skripti tekee dry-runin, tarkistaa tavoiteversion ja varmistaa Longhornin tilanteen. Koodi löytyy GitHubista.\nVarsinainen ajo oli tämän tyyppinen:\n./scripts/replace-outdated-nodes.sh --force --max-replacements 1 \\ | tee /tmp/oke-node-replacement.log Skriptin osalta testi meni lopulta hyvin. Node vaihtui, uusi node liittyi klusteriin ja Longhorn palautui terveeksi. Vanhaan nodeen jääneet stale-replikat saatiin siivottua pois.\nLokin lopussa näkyi se mitä hain:\nDeleting stale Longhorn replica ... on removed node ... Removing stale Longhorn node ... after Kubernetes node removal Longhorn is healthy Replacement completed for ocid1.instance... Done. Replaced nodes in this run: 1 Klusterin sisäisen tilan näkökulmasta node replacement siis onnistui.\nOliko se katkoton? # Ei täysin.\nTestiin tuli noden vaihdon aikana muutamia timeoutteja:\nFAIL rc=28 curl: (28) Operation timed out after 3002 milliseconds with 0 bytes received Tämä oli testin tärkein tulos. Kubernetesin näkökulmasta kaikki palautui nätisti, mutta käyttäjän näkökulmasta osa pyynnöistä epäonnistui huollon aikana.\nTarkkaa syytä en pysty todistamaan pelkästään tämän testin perusteella. Oma arvaukseni on, että katkos liittyi useamman asian ajoitukseen: vanha node poistui, uusi node liittyi mukaan, OCI Network Load Balancer päivitti backendejä ja Envoy Gatewayn podit käynnistyivät uudella nodella. Uuden noden alkuvaiheessa näkyi myös Flanneliin liittyvä virhe:\nplugin type=\u0026#34;flannel\u0026#34; failed (add): loadFlannelSubnetEnv failed: open /run/flannel/subnet.env: no such file or directory Tämä korjaantui itsestään, mutta se kertoo hyvin miksi pelkkä node Ready ei aina tarkoita, että node on heti valmis ottamaan vastaan julkista liikennettä.\nMitä tästä jäi käteen? # Testi ei todistanut täydellistä nollakatkoista HA:ta. Se oli silti hyödyllinen testi.\nNode vaihtui onnistuneesti, uusi node liittyi klusteriin ja Longhorn palautui terveeksi. Klusterin sisäinen tila näytti huollon jälkeen hyvältä. Julkisen liikenteen näkökulmasta tulos ei kuitenkaan ollut täydellinen, muutamien pyyntöjen aikakatkaisujen takia.\nSe on oikeastaan koko testin opetus. Korkeaa saatavuutta ei kannata arvioida vain klusterin sisältä. kubectl get pods voi näyttää lopulta hyvältä, vaikka käyttäjä olisi nähnyt huollon aikana virheen. Yksinkertainen ulkopuolelta ajettu curl-looppi kertoi tässä enemmän kuin pelkkä Kubernetesin oma status.\nMinulle testi oli onnistunut, vaikka tulos ei ollut täydellinen. Nyt tiedän paremmin, miten tämä klusteri käyttäytyy node-huollon aikana ja missä sen rajat tulevat vastaan.\n","date":"05.06.2026","externalUrl":null,"permalink":"/fi/posts/korkean-saatavuuden-testaaminen-kubernetesissa/","section":"Kirjoitukset","summary":"Yksinkertainen OKE-klusterissa tehtävä saatavuustesti, jossa tarkasteltiin noden poistumisen vaikutusta julkiseen blogipalveluun.","title":"Korkean saatavuuden testaaminen Kubernetesissa","type":"posts"},{"content":" Profiili # Olen tietojenkäsittelyn tradenomiksi valmistuva alanvaihtaja. Tämänhetkinen ammatillinen suuntani painottuu Linuxiin, Kubernetes-käyttöympäristöihin, GitOpsiin, DevOps-käytäntöihin ja cloud native -infraan.\nEnnen IT-alalle siirtymistä olen työskennellyt yli kymmenen vuotta tuotanto- ja laboratorioympäristöissä. Taustani on kehittänyt järjestelmällisyyttä, tarkkuutta, prosessien noudattamista, laadunvarmistusta ja käytännön ongelmanratkaisua. Näitä vahvuuksia haluan yhdistää tekniseen osaamiseen pilvi-infran, DevOpsin ja alustaympäristöjen parissa.\nViimeaikainen työkokemus # Aika Työnantaja Rooli Tiivistelmä 2026 Kabei Oy Järjestelmäasiantuntija, työharjoittelu Pilvi-infrastruktuuri, Linux-palvelimet, konttipalvelut, VPN-yhteydet ja tekninen dokumentointi. 2019– Ultraprint Oy Operaattori Painetun elektroniikan tuotanto, prosessien seuranta ja laadunvarmistus. 2015–2018 Endomines Oy Laborantti Geologisten näytteiden esikäsittely, analysointi, laadunvalvonta ja dokumentointi. 2014 Outokumpu Stainless Oy Laborantti Metallurgiset analyysit, näytteenkäsittely ja laboratoriotyö teollisuusympäristössä. Koulutus # Aika Oppilaitos Tutkinto Keskeiset opinnot 2023– Karelia AMK Tradenomi, tietojenkäsittely Ohjelmistokehitys, IT-infrastruktuurit, tietoturva, automaatio ja järjestelmäintegraatiot. 2013–2014 Ammattiopisto Lappia Laboratorioalan perustutkinto Laboratoriotyö, kemiallinen analytiikka, laiteanalytiikka, bioanalytiikka, laadunvalvonta ja teollisuuden prosessit. 2008 Merikosken lukio Ylioppilastutkinto Yleissivistävä koulutus. Tekninen suunta # Tavoitteeni on työllistyä IT-alalle tehtäviin, joissa pääsen hyödyntämään sekä teknistä osaamistani että aiempaa kokemustani tuotanto- ja laboratorioympäristöistä. Erityisesti minua kiinnostavat teollinen DevOps, cloud native -ympäristöt, Linux, Kubernetes, GitOps, automaatio ja järjestelmien käytännön ylläpito.\nLataa CV:n PDF-versio\n","externalUrl":null,"permalink":"/fi/cv/","section":"Antti Hanhela","summary":"Profiili # Olen tietojenkäsittelyn tradenomiksi valmistuva alanvaihtaja. Tämänhetkinen ammatillinen suuntani painottuu Linuxiin, Kubernetes-käyttöympäristöihin, GitOpsiin, DevOps-käytäntöihin ja cloud native -infraan.\n","title":"Curriculum Vitae","type":"page"},{"content":"Olen tietojenkäsittelyn tradenomiksi valmistuva alanvaihtaja, joka on kiinnostunut erityisesti Linuxista, Kubernetesista, DevOpsista, GitOpsista ja cloud native -ympäristöistä.\nTaustani on tuotanto- ja laboratorioympäristöissä, joissa tarkkuus, järjestelmällisyys, laadunvarmistus ja prosessien noudattaminen ovat olleet keskeisiä osia työtä. Haluan yhdistää tätä käytännön kokemusta uuteen IT-osaamiseen.\nTämä sivusto on henkilökohtainen tekninen blogi. Pääesimerkkinä toimii Kubernetes Lab -kirjoituksessa kuvattu OKE-pohjainen Kubernetes- ja GitOps-ympäristö. Tarkempi dokumentaatio ja manifestit pidetään GitHub-repoissa.\n","externalUrl":null,"permalink":"/fi/about/","section":"Antti Hanhela","summary":"Olen tietojenkäsittelyn tradenomiksi valmistuva alanvaihtaja, joka on kiinnostunut erityisesti Linuxista, Kubernetesista, DevOpsista, GitOpsista ja cloud native -ympäristöistä.\nTaustani on tuotanto- ja laboratorioympäristöissä, joissa tarkkuus, järjestelmällisyys, laadunvarmistus ja prosessien noudattaminen ovat olleet keskeisiä osia työtä. Haluan yhdistää tätä käytännön kokemusta uuteen IT-osaamiseen.\n","title":"Minusta","type":"page"}]