Som plattformteam etterstreber vi å bygge de kapabilitetene det faktisk er behov for. Noen ganger bygger man løsninger for å etterleve strategier. Hvis man styrer ut i fra sistnevnte er det ikke alltid man treffer på førstnevnte, selv om strategien i seg selv er god.
Dette er historien om når Kartverket bygde et hybrid service mesh som fungerte akkurat slik det skulle.
Og hvorfor vi aldri burde ha bygget det.
Advarsel: artikkelen inneholder flere fremmedord enn Dagbladets lørdagskryssord.
Hos Kartverket har man de siste 5 årene bygget opp en imponerende applikasjonsplattform; SKIP. Med fokus på battle-testet teknologi som Kubernetes (GKE/GDC), Istio kombinert med egne abstraksjoner (1, 2) og CLI-verktøy har man bygget opp en rigg som leverer redusert kognitiv last, brukervennlighet, robusthet og tilgjengelighet hver eneste dag.
La oss ta en kikk under panseret for å se hvordan plattformen henger sammen.
Teknisk arkitektur
Et SKIP-cluster i dag er et vanilla Kubernetes-cluster som kjører nøye utvalgte komponenter. Disse komponentene spinnes opp ved provisjonering, før brukernes egne workloads blir deployet. Komponentene er for det meste open source, mikset med noe kommersiell software. Denne miksen kombinert med vår egen operator sørger for bl.a. at vi iveretar følgende for produktteams applikasjoner:
- runtime-sikkerhetsscanning
- zero trust networking
- telemetry-innsamling
- TLS-sertifikater
- routing
- tilgjengelighet
- …
Hvert av de 3 miljøene (sandbox, dev, prod) består av 2 clustre, en arkitektur vi internt kaller SemiMonocluster™. Det betyr at vi har ett stort cluster on-prem og ett i allmenn sky som er satt opp veldig likt (tilpasset hardware/leverandørmiljøet hvor det kjører).
Dette gir produktteamene valgfrihet og fleksibilitet til hvor de ønsker å kjøre applikasjonene sine (f.eks. Eiendomsregisteret, Grunnboken eller Norgeskart) avhengig av budsjett, skaleringsbehov og sikkerhetsvurderinger.
Et "behov" oppstår
I 2021 ble det utarbeidet en skystrategi i Kartverket. I dette dokumentet finner man bl.a. følgende:
«Kartverkets systemer skal bruke allmenn sky der det er egnet. I de tilfellene der allmenn sky ikke velges, skal det være som resultat av helhetlig vurdering av kost/nytte og risiko.»
«Kartverkets systemer inkluderer tjenester med krav til sikkerhet og kostnader som er vanskelig å drifte på allmenn sky. Kartverket må derfor ha privat sky infrastruktur.»
«Med hybrid skyplattform vil Kartverket utnytte potensialet i både offentlig og privat driftet skyplattform, og kan dra nytte av en elastisk infrastruktur i kombinasjon med egne datasentre.»
Kartverket hadde på det tidspunktet strategien ble skrevet kun tilstedeværelse i egne datasentre. Videre jobbet man et par år med å vurdere teknologier, leverandører og bygge basiskapabiliteter for å kunne levere et godt produkt på en lokasjon.
Etter litt over et år hadde teamet anledning til å løfte blikket og fokusere på å etterleve skystrategien.
Den 1. februar 2023 mønstret jeg ombord på SKIP, og allerede to dager etter ble jeg invitert inn i et møte hvor jeg sammen med tech lead Bård Ove Hoel ble briefet på ambisjonene om å etablere en motsvarighet til dagens on-prem i allmenn sky, og videre etablere et hybrid service mesh ("multi-cluster").
På daværende tidspunkt var det betydelige mengder buzz internt i teamet og hos ulike teknologiledere i umiddelbar nærhet. Vi hadde dog fått null henvendelser fra produktteam. Det var nok fordi de ikke visste at de trengte et hybrid service mesh enda.
Et krevende utgangspunkt
På daværende tidspunkt var teamet fortsatt relativt nytt, og Bekk hadde nylig blitt valgt som ny konsulentpartner. Det betydde at omtrent halvparten av teammedlemmene på SKIP og ~10 produktteam hadde blitt skiftet ut.
Parallelt med dette hadde man byttet ut en del komponenter på plattformen (i fart), laget en egen operator som et hobbyprosjekt (som ble profesjonalisert) og man jobbet med å innføre ArgoCD.
På toppen av dette var minimal erfaring med service mesh generelt og Istio spesielt.
SKIPs implementasjon av hybridsky
Allmenn sky
Det første steget for å realisere en hybrid sky, var å etablere SKIP i allmenn sky på GCP. Det ble brukt betydelig tid på IP-adresseplaner (viktig for vårt oppsett med Istio), etablering av prosjektstruktur i GCP og oppsett av Shared VPC, VPN, BGP-peering, NAT og routing. Denne prosessen tok tid å få korrekt grunnet mange ulike komponenter som skulle passe med hverandre på tvers av nettverkstopologier og fordi brannmuren on-prem kun kan endres tirsdag og torsdag ~kl 12.
Etter infrastrukturen var oppe, provisjonerte vi opp GKE-clustre. Alt er selvsagt deklarativt og reproduserbart med Terraform. Deretter ble toolingen vår GitOps'et inn med ArgoCD og kustomize.
Dette funket ikke overraskende som et frittstående cluster. Men vi skulle videre til en hybrid hverdag hvor tjenester kunne leve på unike lokasjoner eller i parallell på to ulike lokasjoner og kommunisere sømløst uten at man nødvendigvis hadde noe forhold til hvor tjenestene kjørte rent teknisk.
Hybrid service mesh med Istio
Kort om Anthos Service Mesh
Kartverket bruker Google sin produktportfølje for containerdrift. I den finner vi det som tidligere var kjent som Anthos Service Mesh (ASM, nå Cloud Service Mesh). Dette er en Google-flavor av Istio som både fjerner funksjonalitet man finner i open-source-varianten og legger til støtte for flere verdiøkende tjenester:
- Managed PKI/CA-infrastruktur for low-effort sertifikatutstedelse
- Tilbyr et managed control plane og automatisk utrulling av nye versjoner
- God observability med flotte dashboards, alertingmuligheter og kunne få et single plane of glass på tvers av clustre
Dette kjørte vi i flere år, men etterhvert som vår bruk av Istio økte var det for mange begrensninger i denne varianten til at vi kunne fortsette bruken av ASM. I tillegg hadde vi begrensninger on-prem som gjorde at vi ikke kunne bruke Googles sin managed versjon. Dette gjorde at vi til slutt migrerte til open source Istio, når vi satt igjen i ett "worst of both worlds"-scenario hvor vi både måtte betale for tjenesten (med begrensninger) og drifte den selv.
I tillegg til bruk av Istio for tjeneste-til-tjeneste kommunikasjon bruker vi ingress gateways for å ta imot trafikk utenfra, både internt og eksternt. Her termineres TLS og sender det til riktig applikasjon med mTLS.
For å kunne etablere vårt multi-cluster oppsett i modusen "multi-primary on different networks" gjorde vi følgende:
- Dobbeltsjekket at vi hadde satt opp distinkte CIDRs overalt i infrastruktur-oppsettet (on-prem og i allmenn sky)
- Konfigurerte opp delt trust (først vha. Googles PKI-infrastruktur, senere distinkte intermediate CA's per cluster med delt root CA)
- Installerte east-west gateways som sender/mottar trafikk adressert til en tjeneste i et annet cluster
- Konfigurerte
istiodtil å operere i moduset multi-primary multi-network - Satt opp en Kubernetes service account med token som ga lesetilgang til apiserveren i hvert cluster og utvekslet disse på tvers
- Brukte VPN-oppsettet og tweaking av brannmursregler for å sørge for at
istiodpå hver side kunne nå hverandres API-server, samt at tilkobling til east-west gatewayene var mulig. - Eksponerte tjenestene i clustrene for east-west gatewayen
Jubelen var stor når vi endelig fikk dette til å fungere som tiltenkt i dokumentasjonen 🎉. For akkurat den var ofte uferdig og/eller utdatert, spesielt i perioden som vi jobbet med ASM.
Sing Hallelujah
Med fungerende hybrid service mesh opplevde vi at vi virkelig hadde levert på skystrategien. Med skinnende teknologi i hånd dro tech lead og undertegnede ut på en markedsføringsturné:
- Presentasjoner på interne fagdager
- Interne allmøter hvor alle i organisasjonen kunne dukke opp
- Bloggposter om hybrid Kubernetes i produksjon (1, 2, 3) 🫣
Med denne turnéen hadde vi sett for en adopsjon av early adopters som gradvis økte til å omfatte de fleste produktteams (det passer ikke for alle).
Etterhvert som tiden gikk så innså vi at produktteamene ikke hadde tid til å ta i bruk funksjonaliteten i den takten vi tenkte. Vi observerte skiftende planer og litt manglende tooling fra vår side kunne være painpoints.
Vi fortsatte vår misjonering til alle som ville høre på. Etter en stund måtte vi ta en fot i bakken når adopsjonskurven vår endte med å se ganske annerledes ut.
Det viste seg at det var kun tech lead og jeg (n=2) som brukte den hybride funksjonaliteten i vårt service mesh. Etter å ha vedlikeholdt det fra sent 2023 til våren 2025 måtte vi ta en ærlig fot i bakken med teamet.
Vi overveide alternativene vi hadde fremfor oss:
- fortsette å støtte hybrid service mesh
- avvikle den hybride funksjonaliteten i service meshet
Etter en kjapp kaffekopp var vi samstemte i plattformteamet at det var bedre å "kill your darlings" fremfor å gå dypere inn i sunk cost fallacy. I våre notater har vi begrunnet det å avvikle støtten med:
- reduserer kompleksitet (for SKIP og produktteamene)
- lavere vedlikeholdskostnader
- forenkler feilsøking
- krever migrering til nye løsninger for de som bruker denne funksjonaliteten (et team vurderte det i samme tidsrom).
Så dermed fjernet vi konfigurasjonen som skulle til for at dette skulle fungere i praksis, og hvert cluster var nå igjen sin egen isolerte øy.
Lessons learned
Hybridmesh er stein i skoen
- Det krever vedlikehold og overvåkning. Nye versjoner av Istio (eller Envoy) som endrer subtilt på oppførsel og blips på nettverksinfrastruktur kan få store konsekvenser
- Ustabilitet kan forekomme. Vi opplevde bl.a. at service account tokens som utløpte, gjorde enkelte av våre plattformtjenester ubrukelig trege. Vi er ganske sikre på at dette skyldes brukerfeil (dvs SKIP) fremfor Istios design
- Vi fant lite offentlig informasjon om andre brukere av Istio multi-cluster. Det gjorde feilsøking og oppsett mer komplisert. I etterkant har vi kommet over flere foredrag og andre ressurser.
Vær produktorientert
Siden du leser denne julekalenderen er dette neppe en overraskelse, og det burde det ikke ha vært for SKIP-teamet heller, det er tross alt modus operandi. Vi er dog blitt ekstra bevisst på å være kritiske til ønsker som kommer fra eget ekkokammer og utfordre det som etterspørres, internt i teamet eller ei.
Avstå fra nerdeporno på jobb
En applikasjonsplattform skal være stabil, det innebærer ofte å vurdere ulike former for teknologi. Boring Technology Club er en god rettesnor. KISS.
Plot twist!
Høsten 2025 har vi hørt fra både produktteam og andre plattformteam på Kartverket at de ønsker seg funksjonalitet som muliggjøres via et hybrid service mesh.
Dette har kommet gjennom formelle og uformelle kanaler og vi har gjennomført møter med interessenter for å faktisk få tak på det reelle brukerbehovet, og utfordret løsningen underveis.
Everything old is new again, vi får se om 2026 blir året hybrid service mesh returnerer til Kartverket.