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.

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.medium / k8s.gp1.large / k8s.gp1.xlarge / k8s.gp1.2xlarge), 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.

Klyngetillegg er valgfrie komponenter som plattformen installerer for deg; katalogen finnes i portalen, i fm kubernetes addon list og i datakilden frostmoln_kubernetes_addons. Velg dem når du oppretter klyngen, eller legg til ett i etterkant i en klynge som kjører — fra klyngens fane Tillegg i portalen, med fm kubernetes cluster add-addons, eller ved å sende hele det ønskede settet med tillegg til API-et eller Terraform. Et tillegg som legges til senere starter sin egen synkronisering og trer i kraft vanligvis i løpet av noen minutter; kan ikke den synkroniseringen startes, skjer det først ved plattformens neste synkronisering, inntil en time. Du kan også fjerne et tillegg — fra de samme stedene, med fm kubernetes cluster remove-addons, eller i API-et ved å fjerne nøkkelen fra addons og navngi den i remove (Terraform gjør begge deler for deg når du fjerner nøkkelen). En fjerning sletter objektene tillegget installerte, så du må navngi det du fjerner i stedet for at det utledes av et kortere sett; portalen ber deg bekrefte. Det som aldri slettes for deg: tilleggets navnerom, eventuelle CustomResourceDefinition, StorageClass eller CSIDriver det opprettet, og alt du selv har lagt i det navnerommet — inkludert hemmeligheter. Klynger som ble opprettet før den enkelte muligheten kom, kan ikke ta imot et nytt tillegg, eller ikke fjerne ett, og sier fra når du prøver. På en klynge der kontrollplanet er eldre enn tillegget External Secrets Operator, godtas tillegget, men installeres aldri — opprett i så fall en ny klynge. Se veiledningen, som også beskriver hva du må gjøre før du fjerner det. Om tillegget Workload Identity, se Arbeidslastidentitet.

Tillegg krever utgående trafikk fra nodene dine

Et tilleggs oppstrøms containerbilder hentes fra et offentlig register når podene starter — de er ikke forhåndslastet på nodene dine, i motsetning til alt klyngen selv trenger. Arbeidsnodene dine trenger derfor utgående HTTPS til det registeret: ExternalDNS henter kontrollerbildet sitt fra registry.k8s.io, External Secrets Operator henter bildet sitt fra ghcr.io, og Workload Identity henter bildet sitt fra registry.sweden.frostmoln.cloud (og bytter token med api.frostmoln.cloud).

Filtrerer du utgående trafikk per vertsnavn, må du tillate de kjente vertene: ghcr.io sammen med pkg-containers.githubusercontent.com, som den omdirigerer hentingen til, registry.sweden.frostmoln.cloud og registry.k8s.io. registry.k8s.io alene er likevel ikke nok — hentingen omdirigeres til skybaserte lagringssteder på andre domener, valgt ut fra din utgående adresse. For å finne en slik vert, se i loggen for utgående trafikk hvilken vert den mislykkede hentingen ble omdirigert til, og tillat den også. Som siste utvei kan du tillate utgående HTTPS fra nodepoolen; det er bredere enn nødvendig, så foretrekk de spesifikke vertene der du kan liste dem opp.

Plattformen sjekker ikke dette, og kan ikke gjøre det: tilgjengeligheten hører til ditt eget VPC i det øyeblikket hentingen skjer, du kan når som helst endre rutene og sikkerhetsgruppene dine, og hver nye node henter bildet på nytt. Å velge et tillegg nodene dine ikke når lykkes derfor — og deretter blir podene stående i ImagePullBackOff:

kubectl -n external-dns get pods
# NAME                            READY   STATUS             RESTARTS   AGE
# external-dns-7d4b8c9f5d-x2klm   0/2     ImagePullBackOff   0          4m

Åpne utgående trafikk fra arbeidsnodene, så prøves hentingen automatisk på nytt innen noen minutter — du trenger ikke slette poden. ExternalDNS' andre forutsetning gjelder fortsatt: den trenger en legitimasjon, enten en Workload Identity-binding (anbefalt, fra tilleggsversjon v0.22.0-4) eller en API-nøkkelhemmelighet frostmoln-dns. Inntil den har en, startes webhook-containeren på nytt med no credential (CrashLoopBackOff). På versjoner før v0.22.0-4 venter den i CreateContainerConfigError. Se ExternalDNS.

Mens tillegget ikke kjører, blir DNS-postene det håndterer verken publisert eller ryddet opp — en post for en slettet Service kan leve videre og fortsette å peke på en adresse som senere kan tildeles på nytt.

Selve klyngen påvirkes aldri. Alt som trengs for å starte en klynge og holde den Ready er forhåndslastet på nodebildet og virker helt uten utgående trafikk.

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.

Tilleggsversjoner

Hvert tillegg som har versjoner, er fastlåst til én av dem. Den fastlåste versjonen er den du ba om; den brukte versjonen er den plattformen sist bekreftet at den installerte. Det er to separate opplysninger som alltid vises sammen: når du flytter en fastlåsing, henger den brukte versjonen etter til endringens egen synkronisering tar den i bruk, vanligvis i løpet av noen minutter; kan ikke den synkroniseringen startes, skjer det først ved plattformens neste synkronisering, inntil en time. En endring som ikke kan tas i bruk, flytter ikke fastlåsingen tilbake — plattformen fortsetter å prøve, og du ruller tilbake ved å flytte fastlåsingen tilbake selv.

• Portalen — klyngens fane Tillegg har kortet Tilleggsversjoner med hvert tilleggs fastlåste versjon, brukte versjon og tilstand. Bytt versjon flytter en fastlåsing.

• CLI — list versjonene du kan fastlåse, vis fastlåst og brukt versjon side om side, og flytt en fastlåsing:

  fm kubernetes addon versions <addon>
  fm kubernetes cluster addons <cluster-id>
  fm kubernetes cluster pin-addons <cluster-id> --version <addon>=<version>

  add-addons tar det samme gjentakbare flagget --version, og det gjør også remove-addons for et tillegg du beholder; cluster create tar det som --addon-version.

• Terraform — kartet addon_versions på frostmoln_kubernetes_cluster fastlåser tilleggene det navngir (hver nøkkel må også finnes i addons), og endres på stedet. Datakilden frostmoln_kubernetes_addon_versions lister versjonene du kan fastlåse; frostmoln_kubernetes_cluster_addons leser hvert tilleggs fastlåste og brukte versjon.

Versjonene listes i plattformens rekkefølge, med den anbefalte markert. Rekkefølgen er ingen rangering: sorter aldri versjonsstrenger, og anta ikke at den siste er nyest — kopier en versjon nøyaktig slik den listes. En utfaset versjon kan fortsatt fastlåses, men er på vei ut. En versjon uten støtte listes ikke og kan ikke fastlåses på nytt; en klynge som allerede er fastlåst til en slik, fortsetter å kjøre den, og fastlåsingen viser den statusen slik at du vet at du bør flytte den. Et tillegg du velger uten å oppgi en versjon — ved opprettelse eller senere — får sin anbefalte versjon. For å fastlåse en annen versjon når du oppretter en klynge: i portalen velger du den i tilleggets Versjon-liste, som vises når tillegget har en annen versjon enn den anbefalte, og som står på Anbefalt fra start; med CLI-en oppgir du --addon-version <addon>=<version> til fm kubernetes cluster create én gang per tillegg; i Terraform setter du addon_versions sammen med et eksplisitt angitt sett addons, og det sendes med forespørselen om å opprette klyngen. Hvert tillegg du fastlåser, må være ett som klyngen får. En fastlåsing for et hvilket som helst annet tillegg, eller for en versjon som ikke listes, avvises, og ingen klynge opprettes.

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

API-endepunktet er privat for VPC-en din

Kubernetes API-serveren (port 6443) lytter på en adresse inne i din egen VPC, og tar imot tilkoblinger kun derfra. Det finnes ingen offentlig adresse for den, og ingen innstilling som gir den en.

kubectl trenger derfor en rute inn i VPC-en. Det finnes to:

• La CLI-en tunnelere for deg. fm kubernetes cluster kubeconfig <cluster-id> --exec --file ./kubeconfig skriver en kubeconfig som åpner sin egen tunnel ved behov, så én terminal er nok og ingen klientnøkkel skrives til disk — legitimasjonen hentes per kall. Det krever en API-nøkkel med både kubernetes:read og sessions:write; en nøkkel med bare kubernetes:* dekker lesingen, ikke sesjonen. En sesjon varer i høyst 60 minutter og lukkes etter 10 minutter uten trafikk, så en langtkjørende eller stille kubectl-strøm blir kuttet der; programtillegget åpner en ny tunnel for neste kommando. En omstart av plattformen eller et nettverksbrudd kan avslutte en sesjon tidligere på samme måte. Bruk --proxy i stedet hvis du heller vil kjøre tunnelen selv med fm kubernetes cluster proxy i en andre terminal — da skrives klientnøkkelen inn i kubeconfig-filen.
• Kjør kubectl inne i VPC-en, vanligvis fra en instans du eier der.

Ikke alle klyngers kontrollplan kan betjene disse tunnelene. Hvis fm svarer at denne klyngen ikke kan det, hjelper det ikke å prøve igjen — bruk ruten inne i VPC-en og kontakt support.

Uten noen av dem vil kommandoene over, kjørt rett fra en laptop eller fra en CI-runner utenfor VPC-en, tidsavbrytes: kubeconfig-en er riktig, nettverksveien er det ikke. Det samme gjelder Helm og Terraforms kubernetes- og helm-providere.

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. Hva du ellers kan installere, og hvilke verdier enkelte charts trenger, står i Hva du kan gjøre i klyngen din.

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.

Offentlig eller intern

Som standard får en tjenestes lastbalanserer en intern adresse fra klyngens eget subnett — tilgjengelig innenfra VPC-en, ikke fra internett. For å eksponere den offentlig, annoter tjenesten:

• En offentlig IP fra poolen — frostmoln.se/lb-scheme: public. Plattformen tildeler en offentlig IP, kobler den til lastbalansereren, publiserer den som tjenestens EXTERNAL-IP, og frigjør den når du sletter tjenesten.
• Ta med din egen offentlige IP — sett også frostmoln.se/lb-public-ip-id: <public-ip-id>. Plattformen bruker en offentlig IP du allerede eier (den må ikke allerede være i bruk) og beholder den når du sletter tjenesten. Verdien er den offentlige IP-ens id (en UUID), ikke adressen — finn den i listen over offentlige IP-er eller med CLI-en.

apiVersion: v1
kind: Service
metadata:
  name: web
  annotations:
    frostmoln.se/lb-scheme: public
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - name: https
      port: 443
      targetPort: 8443
  # Hvem som kan nå den — se advarselen nedenfor.
  loadBalancerSourceRanges:
    - 203.0.113.0/24

For å gjenbruke en offentlig IP du allerede har, legg til id-en ved siden av schemaet:

metadata:
  annotations:
    frostmoln.se/lb-scheme: public
    frostmoln.se/lb-public-ip-id: 3f2504e0-4f89-41d3-9a0c-0305e82c3301

En offentlig tjeneste uten kildeområder er åpen mot hele internett

loadBalancerSourceRanges er tilgangskontrollen for en offentlig lastbalanserer: datastien bevarer klientens kildeadresse, så det er reell filtrering, ikke et hint. Utelat det og tjenesten er tilgjengelig fra 0.0.0.0/0 — samme standard som andre skyer. Sett det til CIDR-blokkene som skal kunne nå tjenesten.

Hva plattformen registrerer på din Service

Mens plattformen arbeider med en Services lastbalanserer, registrerer den Kubernetes-hendelser på Servicen med de årsakene en skyleverandørs controller bruker, slik at kubectl describe service <name> viser hvor den står:

• EnsuringLoadBalancer når den begynner å opprette lastbalansereren eller ta i bruk en endring på den;
• EnsuredLoadBalancer når det er ferdig, eller UpdatedLoadBalancer når bare settet med noder bak den er endret;
• DeletingLoadBalancer og deretter DeletedLoadBalancer når Servicen slettes eller slutter å være type: LoadBalancer (for en slettet Service vises de fortsatt av kubectl get events i navnerommet);
• en advarsel, SyncLoadBalancerFailed, ved hvert forsøk som mislykkes. Servicen blir stående på EXTERNAL-IP <pending>, og meldingen starter med Error syncing load balancer: failed to ensure load balancer: etterfulgt av den spesifikke årsaken — PublicIPNotFound eller PublicIPInUse for en ta-med-din-egen-id som ikke er din eller allerede er i bruk, PublicIPForbidden for en oppbrukt Public IP-pool eller kvote, RealiseFailed for alt annet — og hva du kan gjøre med det.

En Service som ikke er endret, får ingen hendelser når plattformen sjekker den på nytt. En klynge med et kontrollplan som er eldre enn disse hendelsene, registrerer bare advarselen, med den spesifikke årsaken som hendelsens årsak; de øvrige vises når kontrollplanet er oppgradert. Kubernetes beholder hendelser i én time.

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, og heller ingen publicIpId — begge avvises. Svaret er fast, ikke bare plattformsbestemt: API-endepunktet er privat for VPC-en din, alltid. Se Hent din kubeconfig.

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

Hvert claims volum vises også i volumlisten din, merket Kubernetes. Se Kubernetes-volumer for hvordan de administreres og hva som skjer med dem når du sletter klyngen.

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).

Hva du kan gjøre i klyngen din

Du er klyngens administrator. Kubeconfigen din kan opprette enhver ressurs i dine egne navnerom, og enhver klyngeomfattende ressurs som plattformen ikke reserverer — inkludert CustomResourceDefinitions, ClusterRoles og ClusterRoleBindings (med alle verb, også *) og admission-webhooks. Du installerer altså operatorer fra de offisielle Helm-chartene deres: Traefik (med CRD-provideren sin), Argo CD, cert-manager (inkludert webhooken), Kyverno, CloudNativePG, kube-prometheus-stack og lignende.

ServiceAccounts du oppretter, er underlagt de samme reglene som kubeconfigen din.

Dette er forbeholdt Frostmoln

• Plattformens navnerom — kube-system, kube-public, kube-node-lease, frostmoln-system, frostmoln-workload-identity, external-secrets og navnerommene til tillegg som Frostmoln installerer for deg (for eksempel external-dns). Du kan se hva som kjører der, men ikke endre det. Unntaket er frostmoln-dns-hemmeligheten du oppretter i ExternalDNS-navnerommet: den forblir din. I de seks som nevnes først (kube-system til external-secrets) kan kubeconfigen din heller ikke lese Secrets, ConfigMaps eller pod-logger. Navnerommene til tilleggene inneholder ingen plattformlegitimasjon, så Secrets og ConfigMaps der kan du lese, ett navnerom om gangen: en lesing på tvers av alle navnerom (kubectl get secrets -A) avvises, fordi den omfatter plattformnavnerommene.
• Klyngeinfrastruktur — Nodes, StorageClasses, CSI-drivere og PersistentVolumes (be om lagring med en PersistentVolumeClaim, se Persistent lagring), APIServices, API Priority and Fairness (FlowSchemas) og ServiceCIDRs.
• Plattformens API-grupper — CustomResourceDefinitions i frostmoln.cloud, frostmoln.se, cilium.io, external-secrets.io, k8s.io og kubernetes.io (og underdomenene deres), og objekter i Ciliums (for eksempel CiliumNetworkPolicy) og plattformens grupper. Bruk en vanlig NetworkPolicy for nettverksregler; dine egne ExternalSecrets og SecretStores går fint.
• Services — en Service kan ikke sette spec.externalIPs, og du kan ikke selv skrive en Services status: lastbalanseringsadresser kommer fra plattformen, så bruk type: LoadBalancer. API-serverens egen kubernetes-Service i navnerommet default og endepunktene dens er også reservert. En lastbalanseringskontroller du kjører selv (for eksempel MetalLB eller kube-vip), kan derfor ikke tildele adresser; bruk type: LoadBalancer, som Frostmoln leverer (se Nå arbeidslastene dine).
• Admission-policyer — ValidatingAdmissionPolicies og MutatingAdmissionPolicies. Bruk en admission-webhook i stedet.
• Identitet — å utgi seg for å være noe annet enn dine egne ServiceAccounts, og sertifikatsignering via kubernetes.io-signererne.
• Pod Security — Pod Security restricted håndheves i hele klyngen, og et navneroms Pod Security-etiketter kan ikke endres, så privilegerte poder og poder med hostNetwork, hostPID eller hostPath avvises.
• Systemprioritetsklasser — poder i dine navnerom kan ikke bruke system-node-critical eller system-cluster-critical, eller noen prioritet over 1000000000, og de to klassene kan ikke endres; de holder plattformens egne poder planleggbare. Opprett din egen PriorityClass i stedet. Et chart som som standard bruker en systemklasse, for eksempel metrics-server, trenger verdien priorityClassName satt til din klasse eller til en tom streng.
• Kontrollplanets endepunkter — kontrollplanets metrikk- og feilsøkingsendepunkter. Via Kubernetes-API-et er kubelet-API-et begrenset til nodenes metrikker og statistikk (nodes/metrics, nodes/stats); nodes/proxy og nodes/log er ikke tilgjengelige. Verktøy som når kubelet via API-serverens proxy — for eksempel Grafana Alloy eller k8s-monitoring som skraper /api/v1/nodes/<node>/proxy/metrics/cadvisor, eller Fluent Bit med Use_Kubelet On — avvises; konfigurer dem til å skrape kubelet direkte på noden (slik kube-prometheus-stack og metrics-server gjør), som bruker de tillatte rettighetene for nodemetrikker og -statistikk.

Admission-webhooks

En webhook må peke på en Service i klyngen din, ikke på en URL. Hvis alle regler gjelder dine egne CRD-API-grupper, godtas webhooken som den er. En webhook som fanger opp innebygde ressurser — Pods, Deployments, Services og så videre — må i tillegg:

• sette timeoutSeconds til 10 eller lavere;
• sette sideEffects: None (eller NoneOnDryRun);
• utelate plattformens navnerom og tilleggenes objekter med disse selektorene:

namespaceSelector:
  matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
        [
          kube-system,
          kube-public,
          kube-node-lease,
          frostmoln-system,
          frostmoln-workload-identity,
          external-secrets,
        ]
    - key: frostmoln.se/addon
      operator: DoesNotExist
objectSelector:
  matchExpressions:
    - key: frostmoln.se/addon
      operator: DoesNotExist

• liste opp ressursene i hver regel — ingen jokertegnressurs (* eller */status);
• hvis den fanger opp Services, Endpoints eller EndpointSlices, også føre opp default blant NotIn-verdiene for kubernetes.io/metadata.name — API-serveren vedlikeholder sine egne endepunkter der;
• ikke fange opp nodes, RBAC, CRD-er, admission-konfigurasjon, leases, sertifikater, lagrings- eller flowcontrol-ressurser, PersistentVolumes, IPAddresses, ServiceCIDRs eller PriorityClasses.

Verdier for Helm-charts

Argo CD, Traefik (rbac.enabled=true, med CRD-provideren sin) og CloudNativePG installeres med standardverdiene sine. Noen få andre charts trenger følgende:

• cert-manager — global.leaderElection.namespace=cert-manager; standardverdien legger leader-election-objektene i kube-system.

• kube-prometheus-stack — kontrollplanet er administrert og kan ikke skrapes, og chartets kontrollplankomponenter ville opprettet Services i kube-system. node-exporter trenger tilgang til verten, noe Pod Security avviser. Pek kubelet-tjenesten mot release-navnerommet ditt:

  kubeControllerManager:
    enabled: false
  kubeScheduler:
    enabled: false
  kubeEtcd:
    enabled: false
  kubeProxy:
    enabled: false
  coreDns:
    enabled: false
  kubeApiServer:
    enabled: false
  nodeExporter:
    enabled: false
  prometheusOperator:
    kubeletService:
      namespace: monitoring # release-navnerommet ditt

• Kyverno — når du legger til policyer, sett config.webhooks til namespaceSelector ovenfor pluss objectSelector (Kyvernos standardverdier utelater bare kube-system). TTL-oppryddingswebhooken og genereringen av ValidatingAdmissionPolicies er ikke tilgjengelige; policyene håndheves via webhookene.

• ingress-nginx — admission-webhooken fanger opp Ingress, en innebygd ressurs. Sett controller.admissionWebhooks.namespaceSelector til namespaceSelector ovenfor og controller.admissionWebhooks.objectSelector til objectSelector ovenfor (standard-timeouten og sideEffects: None oppfyller allerede kravene), eller slå av webhooken med controller.admissionWebhooks.enabled=false.

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).
• Kvoter begrenser klynger og noder per tenant. Sjekk kvotene dine og be om en økning før du oppretter en stor klynge.
• En arbeidslast-lastbalanserer er intern som standard — en Service av type: LoadBalancer får en intern VPC-adresse med mindre du annoterer den frostmoln.se/lb-scheme: public (se Nå arbeidslastene dine).
• Sletting av en klynge fjerner nodene, API-lastbalansereren og dens lagrede påloggingsinformasjon.

Relatert

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