Administrert Kubernetes

Frostmoln Administrert Kubernetes kjører klynger på Frostmoln-databehandling. Du administrerer arbeidslastene; plattformen klargjør og administrerer kontrollplanet, arbeidernodene, API-lastbalanseren og din kubeconfig.

Pilot — tilgang gis per tenant

Administrert Kubernetes rulles ut som en pilot. Det vises i portalen kun for tenanter som har fått tildelt kubernetes-rettigheten — hvis du ikke ser Kubernetes i navigasjonen, er det ikke aktivert for tenanten din ennå. Kontakt support for å be om tilgang (det finnes ingen selvbetjent aktivering under piloten).

Opprette en klynge

I portalen går du til Kubernetes → Klynger → Opprett og velger:

• Navn.
• Kubernetes-versjon — for øyeblikket 1.34 eller 1.35 (den anbefalte versjonen er merket); nedtrekkslisten er fasiten.
• Kontrollplan-nivå:
  • Standard (development) — én dedikert kontrollplannode.
  • Production (production) — tre dedikerte kontrollplannoder (HA-kvorum), produksjons-SLA.
• VPC + subnett klyngen kjører i (regionen arves fra VPC-en).
• En innledende nodepool — et navn, en nodestørrelse (k8s.gp1.small / k8s.gp1.medium / k8s.gp1.large), og et nodeantall.

Det finnes ingen inngangsinnstilling ved opprettelse. Hvordan din egen trafikk når arbeidslastene dine avgjøres inne i klyngen, i etterkant — se Nå arbeidslastene dine.

CLI & Terraform

Administrert Kubernetes administreres fra portalen, med fm-CLI-en eller med Terraform. CLI-en har en komplett kommandogruppe fm kubernetes — klynger, nodepooler og katalogene over nodestørrelser / nivåer / versjoner / tillegg; se fm kubernetes-referansen. I Terraform bruker du frostmoln_kubernetes_cluster (med sin innledende nodepool og klyngetillegg), frostmoln_kubernetes_node_pool for ekstra pooler, og katalogdatakildene frostmoln_kubernetes_versions / _tiers / _flavors / _addons — se Terraform-referansen. Når du har en kubeconfig bruker du kubectl, Helm og dine vanlige Kubernetes-verktøy mot klyngen som vanlig.

Hent din kubeconfig

Når klyngen kjører, bruk Last ned Kubeconfig på klyngens detaljside. Pek kubectl mot den, og du er inne:

export KUBECONFIG=~/Downloads/my-cluster-kubeconfig.yaml
kubectl get nodes

Kubernetes API-serveren nås gjennom et dedikert lastbalansert endepunkt (port 6443). Klyngens påloggingsinformasjon genereres og holdes sikkert av plattformen — nodeoppstart overfører aldri hemmeligheter tilbake.

Klyngens endepunkt er ikke ment for trafikken din. Det er for kubectl, Helm og CI-en din. Din egen trafikk går til adressen til en lastbalanserer du ber om inne fra klyngen — se Nå arbeidslastene dine. Å peke en applikasjons DNS-oppføring mot klyngens endepunkt er nettopp den feilen dette skillet finnes for å forhindre.

Nå arbeidslastene dine

En klynge kommer uten lastbalanserer for din egen trafikk. Du får en på Kubernetes' standardmåte: opprett en Service av type: LoadBalancer, og plattformen klargjør en lastbalanserer for den tjenesten, holder podene dine tilkoblet som medlemmer, og skriver adressen tilbake til tjenesten.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - name: https
      port: 443
      targetPort: 8443

kubectl get service web --watch
# NAME   TYPE           EXTERNAL-IP   PORT(S)
# web    LoadBalancer   10.20.4.17    443:31274/TCP

Adressen som vises som EXTERNAL-IP er den du skal peke DNS-en din mot.

En ingress-kontroller fungerer på samme måte. Installer den du foretrekker (Traefik, ingress-nginx, …) og eksponer den med en type: LoadBalancer-tjeneste i stedet for en NodePort-tjeneste. Det finnes ikke lenger reserverte nodeporter å låse: Kubernetes velger nodeportene selv, og du trenger aldri å kjenne dem. TLS termineres i klyngen din, med dine egne sertifikater — plattformen håndterer aldri nøklene dine.

Noen egenskaper verdt å kjenne til:

• Hver slik tjeneste får sin egen lastbalanserer. Den vises i den vanlige lastbalanser-listen din og faktureres som en lastbalanserer, som alle andre.
• Administrer den fra Kubernetes, ikke fra lastbalanser-API-et. Tjenesten er det lastbalansereren avstemmes mot: endre portene eller selektoren dens, og lastbalansereren følger med.
• Sletter du tjenesten, forsvinner lastbalansereren med den. Fjern tjenestene dine før du sletter klyngen, så ingenting blir stående igjen.
• Kubernetes API-endepunktet er separat og er ikke en av disse — det klargjøres av plattformen, ikke av en tjeneste hos deg.

Bare interne adresser i dag — ingen offentlig inngang ennå

En lastbalanserer som klargjøres for en Service får en intern adresse, fra klyngens eget subnett: tilgjengelig innenfra VPC-en, ikke fra internett. En offentlig adresse for en slik tjeneste er ikke bygget ennå, så en arbeidslast i klyngen har foreløpig ingen støttet offentlig inngang. Hvis arbeidslasten din må være tilgjengelig fra internett, er det ikke noe denne klyngen kan gjøre i dag.

Den automatiske inngangs-lastbalansereren for arbeidsnoder er fjernet

Klynger fikk tidligere en inngangs-lastbalanserer ved opprettelse, som videresendte TCP 80 og 443 til faste nodeporter på hver arbeidsnode, valgt med innstillingen ingressScheme (ingress_scheme i Terraform) og en valgfri ta-med-din-egen-adresse. Alt det er borte: det finnes ingen inngangsinnstilling når du oppretter en klynge, og ingen faste nodeporter å publisere. Bruk en Service av type: LoadBalancer, som over.

API-endepunktets eksponering er ikke en innstilling

Det finnes ingen scheme-innstilling på en klynge. Hvordan Kubernetes API-endepunktet eksponeres avgjøres av plattformen, ikke per klynge — å sende scheme avvises.

Nodepooler

En klynge har én eller flere nodepooler — grupper av arbeidernoder av en gitt størrelse. Fra klyngens detaljside kan du:

• Legge til en nodepool (navn, størrelse, nodeantall), eventuelt med etiketter og taints for planlegging (etiketter og taints er foreløpig kun tilgjengelige i portalen — Terraform-ressursen støtter dem ikke ennå).
• Skalere en pool ved å sette et nytt nodeantall.
• Slette en pool.

Skaler manuelt foreløpig

Klynge-autoskalering er ennå ikke tilgjengelig — sett nodeantallet eksplisitt og skaler pooler manuelt etter hvert som arbeidslasten din endres.

Persistent lagring

Klynger leveres med en Frostmoln CSI-lagringsklasse, frostmoln-block (standard StorageClass), med Frostmoln-blokklagring som backend. Opprett en PersistentVolumeClaim, så klargjøres og kobles et volum til automatisk; volumer støtter utvidelse på nett.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ['ReadWriteOnce']
  storageClassName: frostmoln-block
  resources:
    requests:
      storage: 20Gi

Nettverk

Klyngens CNI er Cilium. Klyngenoder når internett bare hvis klyngens VPC har en Gateway — uten en har nodene verken utgående tilgang, navneoppslag eller tilkobling til administrerte tjenester, så legg selv til en Gateway i VPC-en hvis de trenger noe av det. Å opprette en klynge legger aldri til en for deg. Nodene er isolert fra Frostmolns interne nettverk uansett — arbeidslastene dine kjører i sitt eget tenant-nettverk. Nå API-serveren via klyngeendepunktet ovenfor, og eksponer dine egne tjenester med en Service av type: LoadBalancer (se Nå arbeidslastene dine).

Begrensninger

• Én sone per klynge — noder plasseres i klyngens region/subnett; ingen multi-AZ-spredning i dag.
• Cilium er den eneste CNI-en — den er ikke kundevalgbar.
• Ingen versjonsoppgraderinger på stedet ennå — velg versjonen din ved opprettelse.
• Autoskalering er ennå ikke tilgjengelig (skaler nodepooler manuelt).
• Ingen offentlig adresse for en arbeidslast-lastbalanserer ennå — en lastbalanserer som klargjøres for en Service av type: LoadBalancer er intern i VPC-en.
• Sletting av en klynge fjerner nodene, API-lastbalansereren og dens lagrede påloggingsinformasjon.

Relatert

• Databehandling / Instanser · Nettverk: VPC-er · Nettverk: Gateway
• Nettverk: Lastbalansere · Fakturering