Administreret Kubernetes

Frostmoln Administreret Kubernetes kører klynger på Frostmoln compute. Du administrerer dine arbejdslaster; platformen klargør og administrerer kontrolplanet, arbejdernoderne, API-lastbalanceren og din kubeconfig.

Opret en klynge

Gå i portalen til Kubernetes → Klynger → Opret, og vælg:

• Navn.
• Kubernetes-version — i øjeblikket 1.34 eller 1.35 (den anbefalede version er markeret); rullemenuen er den autoritative kilde.
• Kontrolplan-niveau:
  • Standard (development) — én dedikeret kontrolplansnode.
  • Production (production) — tre dedikerede kontrolplansnoder (HA-kvorum), produktions-SLA.
• VPC + subnet, som klyngen kører i (regionen arves fra VPC'en).
• En indledende node pool — et navn, en nodestørrelse (k8s.gp1.medium / k8s.gp1.large / k8s.gp1.xlarge / k8s.gp1.2xlarge) og et nodeantal.

Der er ingen ingress-indstilling, når klyngen oprettes. Hvordan din egen trafik når dine arbejdslaster, afgøres inde i klyngen bagefter — se Nå dine arbejdslaster.

Klyngetilføjelser er valgfrie komponenter, som platformen installerer for dig; kataloget findes i portalen, i fm kubernetes addon list og i datakilden frostmoln_kubernetes_addons. Vælg dem, når du opretter klyngen, eller føj en til bagefter i en klynge, der kører — fra klyngens fane Tilføjelser i portalen, med fm kubernetes cluster add-addons eller ved at sende hele det ønskede sæt af tilføjelser til API'et eller Terraform. En tilføjelse, der føjes til senere, starter sin egen synkronisering og træder i kraft typisk inden for få minutter; kan den synkronisering ikke startes, sker det først ved platformens næste synkronisering, op til en time. Du kan også fjerne en — fra de samme steder, med fm kubernetes cluster remove-addons eller i API'et ved at fjerne nøglen fra addons og navngive den i remove (Terraform gør begge dele for dig, når du fjerner nøglen). En fjernelse sletter de objekter, tilføjelsen installerede, så du bliver bedt om at navngive det, du fjerner, i stedet for at det udledes af et kortere sæt; portalen beder dig bekræfte. Det, der aldrig slettes for dig: tilføjelsens navnerum, enhver CustomResourceDefinition, StorageClass eller CSIDriver, den har oprettet, og alt, du selv har lagt i det navnerum — inklusive legitimationsoplysninger. Klynger, der blev oprettet, før den enkelte funktion udkom, kan ikke modtage en ny tilføjelse eller kan ikke fjerne en, og de siger fra, når du prøver. På en klynge, hvis kontrolplan er ældre end tilføjelsen External Secrets Operator, accepteres tilføjelsen, men installeres aldrig — opret i så fald en ny klynge. Se guiden, som også beskriver, hvad du skal gøre, før du fjerner den. Om tilføjelsen Workload Identity, se Arbejdslastidentitet.

Tilføjelser kræver udgående adgang fra dine noder

En tilføjelses opstrøms containerimages hentes fra et offentligt register, når dens pods starter — de er ikke forudindlæst på dine noder, i modsætning til alt, hvad klyngen selv har brug for. Dine arbejdernoder har derfor brug for udgående HTTPS til det register: ExternalDNS henter sit controller-image fra registry.k8s.io, External Secrets Operator henter sit image fra ghcr.io, og Workload Identity henter sit image fra registry.sweden.frostmoln.cloud (og udveksler tokens med api.frostmoln.cloud).

Hvis du filtrerer udgående trafik på værtsnavn, så tillad de kendte værter: ghcr.io sammen med pkg-containers.githubusercontent.com, som den omdirigerer hentningen af images til, registry.sweden.frostmoln.cloud og registry.k8s.io. registry.k8s.io alene er dog ikke nok — hentningen af images omdirigeres til skybaserede lagringssteder på andre domæner, valgt ud fra din udgående adresse. Find sådan en vært i din log over udgående trafik: se, hvilken vært den mislykkede hentning blev omdirigeret til, og tillad også den. Som sidste udvej kan du tillade udgående HTTPS fra node poolen; det er bredere end nødvendigt, så foretræk de specifikke værter, hvor du kan angive dem.

Platformen kontrollerer ikke dette og kan ikke gøre det: adgangen hører til dit eget VPC i det øjeblik, hentningen sker, du kan til enhver tid ændre dine ruter og sikkerhedsgrupper, og hver ny node henter imaget igen. At vælge en tilføjelse, dine noder ikke kan nå, lykkes derfor — og derefter bliver dens pods stående i ImagePullBackOff:

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

Åbn for udgående trafik fra dine arbejdernoder, så forsøges hentningen automatisk igen inden for få minutter — du behøver ikke slette podden. ExternalDNS' anden forudsætning gælder stadig: den skal have en legitimationsoplysning, enten en Workload Identity-binding (anbefalet, fra tilføjelsesversion v0.22.0-4) eller en API-nøgle-Secret frostmoln-dns. Indtil den har en, genstartes dens webhook-container med no credential (CrashLoopBackOff). I versioner før v0.22.0-4 venter den i CreateContainerConfigError. Se ExternalDNS.

Mens tilføjelsen ikke kører, bliver de DNS-poster, den administrerer, hverken publiceret eller ryddet op — en post for en slettet Service kan overleve den og blive ved med at pege på en adresse, der senere kan blive tildelt igen.

Din klynge selv påvirkes aldrig. Alt, hvad der skal til for at starte en klynge og holde den Ready, er forudindlæst på node-imaget og virker helt uden udgående trafik.

CLI & Terraform

Administreret Kubernetes administreres fra portalen, med fm-CLI'en eller med Terraform. CLI'en har en komplet kommandogruppe fm kubernetes — klynger, node pools og katalogerne over nodestørrelser / niveauer / versioner / tilføjelser; se fm kubernetes-referencen. I Terraform bruger du frostmoln_kubernetes_cluster (med dens indledende node pool og klyngetilføjelser), frostmoln_kubernetes_node_pool til yderligere pools samt katalogdatakilderne frostmoln_kubernetes_versions / _tiers / _flavors / _addons — se Terraform-referencen. Når du først har en kubeconfig, bruger du kubectl, Helm og dine sædvanlige Kubernetes-værktøjer mod klyngen som normalt.

Tilføjelsesversioner

Hver tilføjelse, der har versioner, er fastlåst til en af dem. Den fastlåste version er den, du bad om; den anvendte version er den, platformen senest har bekræftet, at den installerede. Det er to separate oplysninger, som altid vises sammen: når du flytter en fastlåsning, halter den anvendte version bagefter, indtil ændringens egen synkronisering anvender den, typisk inden for få minutter; kan den synkronisering ikke startes, sker det først ved platformens næste synkronisering, op til en time. En ændring, der ikke kan anvendes, flytter ikke fastlåsningen tilbage — platformen bliver ved med at prøve, og du ruller tilbage ved selv at flytte fastlåsningen tilbage.

• Portalen — klyngens fane Tilføjelser har kortet Tilføjelsesversioner med hver tilføjelses fastlåste version, anvendte version og tilstand. Skift version flytter en fastlåsning.

• CLI — vis de versioner, du kan fastlåse, vis fastlåst og anvendt version side om side, og flyt en fastlåsning:

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

  add-addons tager det samme gentagelige flag --version, og det gør remove-addons også for en tilføjelse, du beholder; cluster create tager det som --addon-version.

• Terraform — mappet addon_versions på frostmoln_kubernetes_cluster fastlåser de tilføjelser, det navngiver (hver nøgle skal også være i addons), og ændres på stedet. Datakilden frostmoln_kubernetes_addon_versions viser de versioner, du kan fastlåse; frostmoln_kubernetes_cluster_addons læser hver tilføjelses fastlåste og anvendte version.

Versionerne vises i platformens rækkefølge med den anbefalede markeret. Rækkefølgen er ikke en rangordning: sortér aldrig versionsstrenge, og antag ikke, at den sidste er den nyeste — kopiér en version præcis, som den vises. En udfaset version kan stadig fastlåses, men er på vej ud. En version uden support vises ikke og kan ikke fastlåses på ny; en klynge, der allerede er fastlåst til en sådan, bliver ved med at køre den, og fastlåsningen viser den status, så du ved, at du skal flytte den. En tilføjelse, du vælger uden at angive en version — ved oprettelsen eller senere — får sin anbefalede version. For at fastlåse en anden version, når du opretter en klynge: i portalen vælger du den i tilføjelsens Version-liste, som vises, når tilføjelsen har en anden version end den anbefalede, og som står på Anbefalet fra start; med CLI'en angiver du --addon-version <addon>=<version> til fm kubernetes cluster create én gang pr. tilføjelse; i Terraform sætter du addon_versions sammen med et eksplicit angivet sæt addons, og det sendes med anmodningen om at oprette klyngen. Hver tilføjelse, du fastlåser, skal være en, som klyngen får. En fastlåsning for enhver anden tilføjelse eller for en version, der ikke vises, afvises, og der oprettes ingen klynge.

Hent din kubeconfig

Når klyngen kører, skal du bruge Download kubeconfig på klyngens detaljeside. Peg kubectl mod den, så er du inde:

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

API-endepunktet er privat for dit VPC

Kubernetes API-serveren (port 6443) lytter på en adresse inde i dit eget VPC, og den accepterer kun forbindelser derfra. Der findes ingen offentlig adresse til den og ingen indstilling, der giver den en.

Så kubectl har brug for en vej ind i VPC'en. Der er to:

• Lad CLI'en lave tunnelen for dig. fm kubernetes cluster kubeconfig <cluster-id> --exec --file ./kubeconfig skriver en kubeconfig, der åbner sin egen tunnel efter behov, så én terminal er nok, og ingen klientnøgle skrives til disken — legitimationsoplysningen hentes ved hvert kald. Den kræver en API-nøgle med både kubernetes:read og sessions:write; en nøgle, der kun er afgrænset til kubernetes:*, dækker læsningen, men ikke sessionen. En session varer højst 60 minutter og lukkes efter 10 minutter uden trafik, så en langvarig eller stille kubectl-strøm afbrydes der; plugin'et åbner en ny tunnel til den næste kommando. En genstart af platformen eller en netværksafbrydelse kan afslutte en session tidligere på samme måde. Brug --proxy i stedet, hvis du hellere selv vil køre tunnelen med fm kubernetes cluster proxy i en anden terminal — det skriver klientnøglen ind i kubeconfig-filen.
• Kør kubectl inde i VPC'en, typisk fra en instans, du ejer der.

Ikke alle klyngers kontrolplan kan betjene disse tunneler. Hvis fm svarer, at denne ikke kan, hjælper det ikke at prøve igen — brug vejen inde fra VPC'en, og kontakt supporten.

Uden nogen af delene vil kommandoerne ovenfor, kørt direkte fra en laptop eller fra en CI-runner uden for VPC'en, få timeout: kubeconfig'en er korrekt, netværksvejen er det ikke. Det samme gælder Helm og Terraforms kubernetes- og helm-providere.

Klyngens legitimationsoplysninger genereres og opbevares sikkert af platformen — nodernes bootstrap sender aldrig hemmeligheder tilbage.

Klyngens endepunkt er ikke til din trafik. Det er til kubectl, Helm og din CI. Din egen trafik går til adressen på en lastbalancer, som du beder om inde fra klyngen — se Nå dine arbejdslaster. At pege en applikations DNS-post mod klyngens endepunkt er præcis den fejl, som denne skelnen findes for at forhindre.

Nå dine arbejdslaster

En klynge leveres uden lastbalancer til din egen trafik. Du får en på Kubernetes' standardmåde: opret en Service af type: LoadBalancer, hvorefter platformen klargør en lastbalancer til den Service, holder dine pods tilkoblet som dens medlemmer og skriver adressen tilbage i Servicen.

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, der vises som EXTERNAL-IP, er den, du skal pege din DNS mod.

En ingress-controller fungerer på samme måde. Installer den, du foretrækker (Traefik, ingress-nginx, …), og eksponer den med en type: LoadBalancer-Service i stedet for en NodePort-Service. Der er ikke længere reserverede nodeporte at låse fast: Kubernetes vælger selv nodeportene, og du behøver aldrig kende dem. TLS termineres i din klynge med dine egne certifikater — platformen opbevarer aldrig dine nøgler. Hvad du ellers kan installere, og hvilke værdier nogle charts kræver, står i Hvad du kan gøre i din klynge.

Et par egenskaber, der er værd at kende:

• Hver sådan Service får sin egen lastbalancer. Den dukker op på din sædvanlige liste over lastbalancere og faktureres som en lastbalancer ligesom alle andre.
• Administrer den fra Kubernetes, ikke fra lastbalancer-API'et. Servicen er det, lastbalanceren afstemmes mod: ændrer du dens porte eller selector, følger lastbalanceren med.
• Sletter du Servicen, forsvinder dens lastbalancer med den. Fjern dine Services, før du sletter klyngen, så intet efterlades.
• Kubernetes API-endepunktet er separat og er ikke en af disse — det klargøres af platformen, ikke af en Service, du har oprettet.

Offentlig eller intern

Som standard får en Services lastbalancer en intern adresse fra klyngens eget subnet — den kan nås inde i VPC'en, ikke fra internettet. For at eksponere den offentligt skal du annotere Servicen:

• En offentlig IP-adresse fra puljen — frostmoln.se/lb-scheme: public. Platformen tildeler en offentlig IP-adresse, knytter den til lastbalanceren, publicerer den som Servicens EXTERNAL-IP og frigiver den, når du sletter Servicen.
• Medbring din egen offentlige IP-adresse — sæt også frostmoln.se/lb-public-ip-id: <public-ip-id>. Platformen bruger en offentlig IP-adresse, du allerede ejer (den må ikke være i brug i forvejen), og beholder den, når du sletter Servicen. Værdien er den offentlige IP-adresses id (en UUID), ikke dens adresse — find det på listen over offentlige IP-adresser 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 der må nå den — se advarslen nedenfor.
  loadBalancerSourceRanges:
    - 203.0.113.0/24

For at genbruge en offentlig IP-adresse, du allerede har, skal du tilføje dens id ved siden af schemaet:

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

En offentlig Service uden kildeintervaller er åben mod hele internettet

loadBalancerSourceRanges er adgangskontrollen for en offentlig lastbalancer: datastien bevarer klientens kildeadresse, så det er reel filtrering, ikke et fingerpeg. Udelad den, og Servicen kan nås fra 0.0.0.0/0 — samme standard som hos andre skyer. Sæt den til de CIDR-blokke, der skal kunne nå Servicen.

Hvad platformen registrerer på din Service

Mens platformen arbejder med en Services lastbalancer, registrerer den Kubernetes-hændelser på Servicen med de årsager, en cloududbyders controller bruger, så kubectl describe service <name> viser, hvor den står:

• EnsuringLoadBalancer, når den begynder at oprette lastbalanceren eller anvende en ændring på den;
• EnsuredLoadBalancer, når det er færdigt, eller UpdatedLoadBalancer, når kun sættet af noder bag den er ændret;
• DeletingLoadBalancer og derefter DeletedLoadBalancer, når Servicen slettes eller holder op med at være type: LoadBalancer (for en slettet Service vises de stadig af kubectl get events i dens navnerum);
• en advarsel, SyncLoadBalancerFailed, ved hvert forsøg, der mislykkes. Servicen bliver stående på EXTERNAL-IP <pending>, og beskeden starter med Error syncing load balancer: failed to ensure load balancer: efterfulgt af den specifikke årsag — PublicIPNotFound eller PublicIPInUse for et medbragt id, der ikke er dit eller allerede er i brug, PublicIPForbidden for en opbrugt Public IP-pulje eller kvote, RealiseFailed for alt andet — og hvad du kan gøre ved det.

En Service, der ikke er ændret, får ingen hændelser, når platformen kontrollerer den igen. En klynge, hvis kontrolplan er ældre end disse hændelser, registrerer kun advarslen med den specifikke årsag som hændelsens årsag; de øvrige vises, når kontrolplanet er opgraderet. Kubernetes gemmer hændelser i en time.

Den automatiske ingress-lastbalancer til arbejdernoder er fjernet

Klynger fik tidligere en ingress-lastbalancer ved oprettelsen, som videresendte TCP 80 og 443 til faste nodeporte på hver arbejdernode, valgt med indstillingen ingressScheme (ingress_scheme i Terraform) og en valgfri medbragt adresse. Alt det er væk: der er ingen ingress-indstilling, når du opretter en klynge, og ingen faste nodeporte at publicere. Brug en Service af type: LoadBalancer som ovenfor.

API-endepunktets eksponering er ikke en indstilling

Der er ingen scheme-indstilling på en klynge og heller ingen publicIpId — begge afvises. Svaret ligger fast og er ikke blot platformsbestemt: API-endepunktet er privat for dit VPC, altid. Se Hent din kubeconfig.

Node pools

En klynge har en eller flere node pools — grupper af arbejdernoder af en given størrelse. Fra klyngens detaljeside kan du:

• Tilføje en node pool (navn, størrelse, nodeantal), eventuelt med labels og taints til planlægning (labels og taints findes indtil videre kun i portalen — Terraform-ressourcen understøtter dem ikke endnu).
• Skalere en pool ved at angive et nyt nodeantal.
• Slette en pool.

Skalér manuelt indtil videre

Autoskalering af klynger er endnu ikke tilgængelig — angiv nodeantallet eksplicit, og skalér pools manuelt, efterhånden som din arbejdslast ændrer sig.

Vedvarende lagring

Klynger leveres med en Frostmoln CSI-lagringsklasse, frostmoln-block (standard-StorageClass), der bygger på Frostmoln bloklagring. Opret et PersistentVolumeClaim, så klargøres og tilknyttes et volumen automatisk; volumener understøtter udvidelse i drift.

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

Hvert claims volumen vises også i din volumenliste, mærket Kubernetes. Se Kubernetes-volumener for, hvordan de administreres, og hvad der sker med dem, når du sletter klyngen.

Netværk

Klyngens CNI er Cilium. Klyngenoder når kun internettet, hvis klyngens VPC har en Gateway — uden en har noderne hverken udgående adgang, DNS-opslag eller forbindelse til administrerede tjenester, så føj selv en Gateway til VPC'en, hvis de har brug for noget af det. At oprette en klynge tilføjer aldrig en for dig. Noderne er isoleret fra Frostmolns interne netværk under alle omstændigheder — dine arbejdslaster kører i deres eget tenant-netværk. Nå API-serveren gennem klyngeendepunktet ovenfor, og eksponer dine egne tjenester med en Service af type: LoadBalancer (se Nå dine arbejdslaster).

Hvad du kan gøre i din klynge

Du er klyngens administrator. Din kubeconfig kan oprette enhver ressource i dine egne navnerum og enhver klyngeomfattende ressource, som platformen ikke reserverer — herunder CustomResourceDefinitions, ClusterRoles og ClusterRoleBindings (med alle verber, også *) og admission-webhooks. Du installerer altså operatorer fra deres officielle Helm-charts: Traefik (med dens CRD-provider), Argo CD, cert-manager (inklusive dens webhook), Kyverno, CloudNativePG, kube-prometheus-stack og lignende.

ServiceAccounts, du opretter, er underlagt de samme regler som din kubeconfig.

Det forbeholder Frostmoln sig

• Platformens navnerum — kube-system, kube-public, kube-node-lease, frostmoln-system, frostmoln-workload-identity, external-secrets og navnerummene for tilføjelser, som Frostmoln installerer for dig (for eksempel external-dns). Du kan se, hvad der kører der, men ikke ændre det. Undtagelsen er frostmoln-dns-Secret'en, som du opretter i ExternalDNS' navnerum: den forbliver din. I de seks, der nævnes først (kube-system til external-secrets), kan din kubeconfig heller ikke læse Secrets, ConfigMaps eller pod-logs. Tilføjelsernes navnerum indeholder ingen platform-legitimationsoplysninger, så deres Secrets og ConfigMaps kan du læse, ét navnerum ad gangen: en læsning på tværs af alle navnerum (kubectl get secrets -A) afvises, fordi den omfatter platformnavnerummene.
• Klyngeinfrastruktur — Nodes, StorageClasses, CSI-drivere og PersistentVolumes (bestil lager med en PersistentVolumeClaim, se Vedvarende lagring), APIServices, API Priority and Fairness (FlowSchemas) og ServiceCIDRs.
• Platformens API-grupper — CustomResourceDefinitions i frostmoln.cloud, frostmoln.se, cilium.io, external-secrets.io, k8s.io og kubernetes.io (og deres underdomæner) samt objekter i Ciliums (for eksempel CiliumNetworkPolicy) og platformens grupper. Brug en almindelig NetworkPolicy til netværksregler; dine egne ExternalSecrets og SecretStores er i orden.
• Services — en Service må ikke sætte spec.externalIPs, og du kan ikke selv skrive en Services status: load balancer-adresser kommer fra platformen, så brug type: LoadBalancer. API-serverens egen kubernetes-Service i navnerummet default og dens endpoints er også forbeholdt. En load balancer-controller, du selv kører (for eksempel MetalLB eller kube-vip), kan derfor ikke tildele adresser; brug type: LoadBalancer, som Frostmoln leverer (se Nå dine arbejdslaster).
• Admission-politikker — ValidatingAdmissionPolicies og MutatingAdmissionPolicies. Brug en admission-webhook i stedet.
• Identitet — at udgive sig for at være andet end dine egne ServiceAccounts samt certifikatsignering via kubernetes.io-signerne.
• Pod Security — Pod Security restricted håndhæves i hele klyngen, og et navnerums Pod Security-labels kan ikke ændres, så privilegerede pods og pods med hostNetwork, hostPID eller hostPath afvises.
• Systemprioritetsklasser — pods i dine navnerum kan ikke bruge system-node-critical eller system-cluster-critical eller nogen prioritet over 1000000000, og de to klasser kan ikke ændres; de holder platformens egne pods planlægbare. Opret din egen PriorityClass i stedet. Et chart, der som standard bruger en systemklasse, for eksempel metrics-server, skal have værdien priorityClassName sat til din klasse eller til en tom streng.
• Kontrolplanets endpoints — kontrolplanets metrik- og debug-endpoints. Via Kubernetes-API'et er kubelet-API'et begrænset til nodernes metrikker og statistik (nodes/metrics, nodes/stats); nodes/proxy og nodes/log er ikke tilgængelige. Værktøjer, der når kubelet via API-serverens proxy — for eksempel Grafana Alloy eller k8s-monitoring, der scraper /api/v1/nodes/<node>/proxy/metrics/cadvisor, eller Fluent Bit med Use_Kubelet On — afvises; konfigurer dem til at scrape kubelet direkte på noden (som kube-prometheus-stack og metrics-server gør), hvilket bruger de tilladte rettigheder til nodemetrikker og -statistik.

Admission-webhooks

En webhook skal pege på en Service i din klynge, ikke på en URL. Hvis alle regler gælder dine egne CRD-API-grupper, accepteres webhooken, som den er. En webhook, der opfanger indbyggede ressourcer — Pods, Deployments, Services og så videre — skal desuden:

• sætte timeoutSeconds til 10 eller mindre;
• sætte sideEffects: None (eller NoneOnDryRun);
• udelukke platformens navnerum og tilføjelsernes objekter med disse selektorer:

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

• angive ressourcerne i hver regel — ingen wildcard-ressource (* eller */status);
• hvis den opfanger Services, Endpoints eller EndpointSlices, også angive default blandt NotIn-værdierne for kubernetes.io/metadata.name — API-serveren vedligeholder sine egne endpoints der;
• ikke opfange nodes, RBAC, CRD'er, admission-konfiguration, leases, certifikater, lager- eller flowcontrol-ressourcer, PersistentVolumes, IPAddresses, ServiceCIDRs eller PriorityClasses.

Værdier til Helm-charts

Argo CD, Traefik (rbac.enabled=true, med dens CRD-provider) og CloudNativePG installeres med deres standardværdier. Nogle få andre charts har brug for følgende:

• cert-manager — global.leaderElection.namespace=cert-manager; standarden lægger leader-election-objekterne i kube-system.

• kube-prometheus-stack — kontrolplanet er administreret og kan ikke scrapes, og chartets kontrolplankomponenter ville oprette Services i kube-system. node-exporter kræver adgang til værten, hvilket Pod Security afviser. Peg kubelet-Service'en mod dit release-navnerum:

  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 # dit release-navnerum

• Kyverno — når du tilføjer politikker, så sæt dens config.webhooks til namespaceSelector ovenfor plus objectSelector (Kyvernos standarder udelukker kun kube-system). Dens TTL-oprydningswebhook og dens generering af ValidatingAdmissionPolicies er ikke tilgængelige; politikkerne håndhæves via dens webhooks.

• ingress-nginx — dens admission-webhook opfanger Ingress, en indbygget ressource. Sæt controller.admissionWebhooks.namespaceSelector til namespaceSelector ovenfor og controller.admissionWebhooks.objectSelector til objectSelector ovenfor (dens standard-timeout og sideEffects: None opfylder allerede kravene), eller slå webhooken fra med controller.admissionWebhooks.enabled=false.

Begrænsninger

• Én zone pr. klynge — noder placeres i klyngens region/subnet; ingen multi-AZ-spredning i dag.
• Cilium er den eneste CNI — den kan ikke vælges af kunden.
• Ingen opgradering af version på stedet endnu — vælg din version, når du opretter klyngen.
• Autoskalering er endnu ikke tilgængelig (skalér node pools manuelt).
• Kvoter begrænser klynger og noder pr. tenant. Tjek dine kvoter, og anmod om en forhøjelse, før du opretter en stor klynge.
• En lastbalancer til arbejdslaster er intern som standard — en Service af type: LoadBalancer får en intern VPC-adresse, medmindre du annoterer den frostmoln.se/lb-scheme: public (se Nå dine arbejdslaster).
• Sletning af en klynge fjerner dens noder, dens API-lastbalancer og dens gemte legitimationsoplysninger.

Relateret

• Compute / Instanser · Netværk: VPC'er · Netværk: Gateway
• Netværk: Lastbalancere · Fakturering