NAIS · 01

Plattformmodell og arkitektur

Forstå NAIS som et produkt for autonome team, modellen for team/miljø/workload og hvordan kontrakten kobles til Kubernetes og Google Cloud.

25 minGrunnleggendeGjennomgått 22. august 2026

NAIS er et plattformprodukt

NAIS skal gi team de tekniske kapabilitetene de trenger for å utvikle og kjøre programvare sikkert, uten at hvert team blir et Kubernetes-plattformteam. Plattformen tilbyr byggeklosser for runtime, identitet, trafikk, data, observability, secrets, levering og drift.

Driftsidéen er viktig: Et uhindret tverrfaglig team som kan ta ansvar for det det bygger, lærer raskere enn et team som sender enhver produksjonsendring til en separat driftskø. NAIS fjerner derfor repeterbar plattformkompleksitet samtidig som produktteamet beholder innsikten og kontrollene det trenger.

Fire prinsipper følger:

  1. Selvbetjening: ønsket tilstand deklareres gjennom versjonerte manifester, Console eller plattform-API-er.
  2. Paved roads: trygge standarder og integrerte kapabiliteter gjør den vanlige veien enklere.
  3. Teameierskap: produktteamet eier kode, data, brukerutfall og produksjonsoppførsel.
  4. Plattform som produkt: NAIS har brukere, dokumentasjon, API-er, konsoll, støtte og en kontrakt i utvikling – ikke bare clustere.

Les Hva er NAIS? og Hva er et team?.

Kjernebegrepene

NAIS-begrepPraktisk betydningUnderliggende idé
TeamPersoner med ansvar for relaterte workloads og ressurserEierskaps- og tilgangsgrense
TenantEn organisasjon eller plattforminstallasjon som bruker NAISOverordnet organisasjonskontekst
Miljø / clusterEt runtime-mål som utvikling eller produksjonKubernetes-cluster; skymiljøer bruker GKE
NamespaceTeamets scope inne i en clusterKubernetes Namespace
WorkloadKode som kjører som Application eller NaisjobKubernetes-ressurser og plattformintegrasjoner
RessursData- eller plattformkapabilitet teamet ber omCustom resource og/eller administrert tjeneste

Et team er ikke bare en tilgangsgruppe. Det bør speile personene som kan utvikle og drifte workloadene. Hvis eierskapet er uklart, kan ikke manifester og dashboards kompensere.

Miljøgrenser er viktige. Utvikling og produksjon skiller seg i identiteter, data, eksponering, pålitelighet og endringskontroll. «Det virket i dev» beviser byggeveien, ikke produksjonsberedskap.

I dagens skyarkitektur har hvert team også et dedikert Google Cloud-prosjekt for hvert miljø. En forespurt bucket blir for eksempel provisionert i teamets prosjekt for det tilsvarende miljøet. Kubernetes-namespace og Google Cloud-prosjekt uttrykker dermed beslektede team-/miljøgrenser i ulike lag.

Lagene under utviklerkontrakten

I et skymiljø kan stacken forenkles slik:

Produktteam
  └─ NAIS-manifest / Console / API
      └─ Naiserator og operators for kapabiliteter
          └─ Kubernetes-ressurser og plattformkomponenter
              └─ GKE-, Google Cloud- og Aiven-tjenester

En NAIS Application er en Kubernetes Custom Resource. Kjerneoperatoren Naiserator observerer ønsket tilstand og produserer Kubernetes-ressursene og integrasjonene spesifikasjonen krever. Andre operators håndterer kapabiliteter som identitet eller data.

Dette er en reconciliation-modell, ikke et engangsscript. Hvis noen endrer en generert ressurs eller leverandørinnstilling manuelt, kan en operator gjenopprette deklarert tilstand. Varige endringer hører hjemme i den støttede deklarasjonen eller administrasjonsflaten.

Abstraksjon uten illusjon

NAIS lar en utvikler si «kjør dette imaget med to replikaer, eksponer denne ingressen, tillat denne caller-en og koble til denne databasen». Plattformen kan oversette intensjonen til Deployments, Services, ingress-ressurser, identiteter, policies og konfigurasjon av administrerte tjenester.

Abstraksjonen får ikke de underliggende egenskapene til å forsvinne:

  • GKE-plassering definerer fortsatt feildomener og kapasitet;
  • Google Cloud IAM styrer fortsatt tilgang til skyressurser;
  • VPC- og Kubernetes-nettverk frakter fortsatt trafikken;
  • Cloud SQL har fortsatt egenskaper for connections, tilgjengelighet og recovery;
  • Aiven Kafka har fortsatt partitions, offsets og skjemahensyn;
  • Kubernetes starter og flytter fortsatt containere på nytt.

Produktteam trenger ikke drifte hvert lag, men arkitekter bør vite hvilket lag som eier en oppførsel når risiko eller feil skal analyseres.

Delt ansvar

PlattformansvarProduktteamets ansvar
Clustere og delte plattformkomponenterApplikasjonskode og faglig korrekthet
Operators, CRD-er, automasjon og støttede standarderWorkload-manifester og ressursvalg
Integrasjoner for identitet, data og telemetriRiktig identitetsbruk og faglig autorisasjon
Plattformdokumentasjon, Console, API-er og støtteDataformål, personvern, livssyklus og recovery-krav
Plattformtilgjengelighet og oppgraderingsveiProdukt-SLO-er, varsler, hendelser, avhengigheter og kostnad

Den nøyaktige grensen varierer med kapabiliteten. En administrert database kan ha automatisert infrastrukturbackup, mens teamet fortsatt må vite om forretningstjenesten kan gjenopprettes innen påkrevd RPO og RTO.

Arkitekturkontroll

Et team ber plattformgruppen «eie produksjon» fordi NAIS eier Kubernetes. Skriv om utsagnet som en eksplisitt ansvarsmodell.

Et godt svar sier at plattformteamet eier delt runtime, operators, støttede integrasjoner og plattformtilgjengelighet. Produktteamet eier om tjenesten virker for brukerne, kvalitet på kode og avhengigheter, manifester, faglig tilgang, data, SLO-er, respons på varsler, recovery-krav og produkthendelser. Begge sider trenger en eskaleringskontrakt ved plattformfeil.

Offisielle studielenker

Google Cloud-bro

Se grunnlagsmodulen for Google Cloud for å forstå prosjektene, lokasjonene og faktureringsmodellen under NAIS. NAIS endrer grensesnittet produktteamet bruker, mens skyens ressurshierarki fortsatt inngår i plattformteamets kontrollplan.