Hanterad Kubernetes

Frostmoln Hanterad Kubernetes kör kluster på Frostmoln-beräkning. Du hanterar dina arbetslaster; plattformen tillhandahåller och hanterar styrplanet, arbetarnoderna, API-lastbalanseraren och din kubeconfig.

Skapa ett kluster

I portalen, gå till Kubernetes → Kluster → Skapa och välj:

• Namn.
• Kubernetes-version — för närvarande 1.34 eller 1.35 (den rekommenderade versionen är markerad); rullgardinsmenyn är källan till sanning.
• Styrplansnivå:
  • Standard (development) — en dedikerad styrplansnod.
  • Production (production) — tre dedikerade styrplansnoder (HA-kvorum), produktions-SLA.
• VPC + subnät som klustret körs i (regionen ärvs från VPC:t).
• En initial nodpool — ett namn, en nodstorlek (k8s.gp1.medium / k8s.gp1.large / k8s.gp1.xlarge / k8s.gp1.2xlarge) och ett nodantal.

Det finns inget ingress-val vid skapandet. Hur din egen trafik når dina arbetslaster avgörs inne i klustret, efteråt — se Nå dina arbetslaster.

Klustertillägg är valfria komponenter som plattformen installerar åt dig; katalogen finns i portalen, i fm kubernetes addon list och i datakällan frostmoln_kubernetes_addons. Välj dem när du skapar klustret, eller lägg till ett i efterhand i ett kluster som körs — från klustrets flik Tillägg i portalen, med fm kubernetes cluster add-addons, eller genom att skicka hela den önskade uppsättningen tillägg till API:et eller Terraform. Ett tillägg som läggs till senare startar en egen synkronisering och träder i kraft vanligtvis inom några minuter; om den synkroniseringen inte kan startas sker det i stället vid plattformens nästa synkronisering, upp till en timme. Du kan även ta bort ett tillägg — från samma ställen, med fm kubernetes cluster remove-addons, eller i API:et genom att ta bort nyckeln ur addons och namnge den i remove (Terraform gör båda åt dig när du tar bort nyckeln). En borttagning raderar de objekt tillägget installerade, så du måste namnge vad du tar bort i stället för att det härleds ur en kortare uppsättning; portalen ber dig bekräfta. Det som aldrig raderas åt dig: tilläggets namnrymd, eventuella CustomResourceDefinition, StorageClass eller CSIDriver det skapat, och allt du själv lagt i den namnrymden — inklusive hemligheter. Kluster som skapades innan respektive funktion fanns kan inte ta emot ett nytt tillägg, eller inte ta bort ett, och säger ifrån när du försöker. På ett kluster vars styrplan är äldre än tillägget External Secrets Operatorgodtas tillägget men installeras aldrig — skapa i så fall ett nytt kluster. Se guiden, som också beskriver vad du ska göra innan du tar bort det. Om tillägget Workload Identity, se Arbetsbelastningsidentitet.

Tillägg kräver utgående trafik från dina noder

Ett tilläggs uppströms containeravbildningar hämtas från ett publikt register när dess poddar startar — de är inte förinstallerade på dina noder, till skillnad från allt som klustret självt behöver. Dina arbetsnoder behöver därför utgående HTTPS till det registret: ExternalDNS hämtar sin styrenhetsavbildning från registry.k8s.io, External Secrets Operator hämtar sin avbildning från ghcr.io, och Workload Identity hämtar sin avbildning från registry.sweden.frostmoln.cloud (och byter tokens med api.frostmoln.cloud).

Om du filtrerar utgående trafik per värdnamn, tillåt de kända värdarna: ghcr.io tillsammans med pkg-containers.githubusercontent.com, dit den omdirigerar hämtningen, registry.sweden.frostmoln.cloud och registry.k8s.io. Men registry.k8s.io ensamt räcker inte — hämtningen omdirigeras till molnbaserade lagringsplatser på andra domäner, valda utifrån din utgående adress. För att hitta en sådan värd, leta i din logg över utgående trafik efter värden som den misslyckade hämtningen omdirigerades till, och tillåt även den. Som sista utväg kan du tillåta utgående HTTPS från nodpoolen; det är bredare än nödvändigt, så föredra de specifika värdarna där du kan räkna upp dem.

Plattformen kontrollerar inte detta, och kan inte göra det: åtkomsten hör till ditt eget VPC i det ögonblick hämtningen sker, du kan när som helst ändra dina rutter och säkerhetsgrupper, och varje ny nod hämtar avbildningen igen. Att välja ett tillägg som dina noder inte når lyckas därför — och sedan blir dess poddar kvar i ImagePullBackOff:

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

Öppna utgående trafik från dina arbetsnoder så görs hämtningen om automatiskt inom några minuter — du behöver inte ta bort podden. ExternalDNS andra förutsättning gäller fortfarande: den behöver en uppgift, antingen en bindning för Workload Identity (rekommenderas, från tilläggsversion v0.22.0-4) eller en API-nyckelhemlighet frostmoln-dns. Tills den har en startas dess webhook-container om med no credential (CrashLoopBackOff). I versioner före v0.22.0-4 väntar den i CreateContainerConfigError. Se ExternalDNS.

Medan tillägget inte kör varken publiceras eller städas de DNS-poster det hanterar — en post för en borttagen Service kan leva kvar och fortsätta peka på en adress som senare kan tilldelas om.

Ditt kluster självt påverkas aldrig. Allt som krävs för att starta ett kluster och hålla det Ready är förinstallerat på nodavbildningen och fungerar helt utan utgående trafik.

CLI & Terraform

Hanterad Kubernetes hanteras från portalen, med fm-CLI:t eller med Terraform. CLI:t har en komplett kommandogrupp fm kubernetes — kluster, nodpooler och katalogerna för nodstorlekar / nivåer / versioner / tillägg; se fm kubernetes-referensen. I Terraform använder du frostmoln_kubernetes_cluster (med sin initiala nodpool och klustertillägg), frostmoln_kubernetes_node_pool för ytterligare pooler, samt katalogdatakällorna frostmoln_kubernetes_versions / _tiers / _flavors / _addons — se Terraform-referensen. När du väl har en kubeconfig använder du kubectl, Helm och dina vanliga Kubernetes-verktyg mot klustret som vanligt.

Tilläggsversioner

Varje tillägg som har versioner är fäst vid en av dem. Den fästa versionen är den du bad om; den tillämpade versionen är den som plattformen senast bekräftade att den installerade. Det är två separata uppgifter som alltid visas tillsammans: när du flyttar en fästning ligger den tillämpade versionen efter tills ändringens egen synkronisering tillämpar den, vanligtvis inom några minuter; om den synkroniseringen inte kan startas sker det vid plattformens nästa synkronisering i stället, upp till en timme. En ändring som inte går att tillämpa flyttar inte tillbaka fästningen — plattformen fortsätter att försöka, och du backar genom att själv flytta tillbaka fästningen.

• Portalen — klustrets flik Tillägg har kortet Tilläggsversioner med varje tilläggs fästa version, tillämpade version och tillstånd. Byt version flyttar en fästning.

• CLI — lista versionerna du kan fästa, visa fäst och tillämpad version sida vid sida, och flytta en fästning:

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

  add-addons tar samma upprepningsbara flagga --version, och det gör även remove-addons för ett tillägg du behåller; cluster create tar den som --addon-version.

• Terraform — mappen addon_versions på frostmoln_kubernetes_cluster fäster de tillägg den namnger (varje nyckel måste också finnas i addons) och ändras på plats. Datakällan frostmoln_kubernetes_addon_versions listar versionerna du kan fästa; frostmoln_kubernetes_cluster_addons läser varje tilläggs fästa och tillämpade version.

Versionerna listas i plattformens ordning, med den rekommenderade markerad. Ordningen är ingen rangordning: sortera aldrig versionssträngar och anta inte att den sista är nyast — kopiera en version exakt som den listas. En utfasad version kan fortfarande fästas men är på väg bort. En version utan support listas inte och kan inte fästas på nytt; ett kluster som redan är fäst vid en sådan fortsätter att köra den, och fästningen visar den statusen så att du vet att du ska flytta den. Ett tillägg du väljer utan att ange en version — när klustret skapas eller senare — får sin rekommenderade version. För att fästa en annan version när du skapar ett kluster: i portalen väljer du den i tilläggets Version-lista, som visas när tillägget har en annan version än den rekommenderade och står på Rekommenderad från början; med CLI:t anger du --addon-version <addon>=<version> till fm kubernetes cluster create en gång per tillägg; i Terraform sätter du addon_versions tillsammans med en uttryckligt angiven uppsättning addons, och den skickas med begäran om att skapa klustret. Varje tillägg du fäster måste vara ett som klustret får. En fästning för något annat tillägg, eller för en version som inte listas, avvisas och inget kluster skapas.

Hämta din kubeconfig

När klustret körs, använd Ladda ner Kubeconfig på klustrets detaljsida. Peka kubectl mot den så är du inne:

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

API-slutpunkten är privat för ditt VPC

Kubernetes API-servern (port 6443) lyssnar på en adress inuti ditt eget VPC och tar emot anslutningar endast därifrån. Det finns ingen publik adress för den, och ingen inställning som ger den en.

Så kubectl behöver en väg in i ditt VPC. Det finns två:

• Låt CLI:t tunnla åt dig. fm kubernetes cluster kubeconfig <cluster-id> --exec --file ./kubeconfig skriver en kubeconfig som öppnar sin egen tunnel vid behov, så en terminal räcker och ingen klientnyckel skrivs till disk — inloggningsuppgiften hämtas vid varje anrop. Det kräver en API-nyckel med både kubernetes:read och sessions:write; en nyckel med enbart kubernetes:* täcker läsningen men inte sessionen. En session varar i högst 60 minuter och stängs efter 10 minuter utan trafik, så en långkörande eller tyst kubectl-ström klipps där; insticksmodulen öppnar en ny tunnel för nästa kommando. En omstart av plattformen eller ett nätverksavbrott kan avsluta en session tidigare, på samma sätt. Använd --proxy i stället om du hellre kör tunneln själv med fm kubernetes cluster proxy i en andra terminal — då skrivs klientnyckeln in i kubeconfig-filen.
• Kör kubectl inuti ditt VPC, vanligtvis från en instans du äger där.

Inte alla styrplan kan betjäna de här tunnlarna. Om fm svarar att detta kluster inte kan det hjälper det inte att försöka igen — använd vägen inifrån ditt VPC och kontakta supporten.

Utan någon av dem kommer kommandona ovan, körda direkt från en laptop eller från en CI-körare utanför ditt VPC, att göra timeout: din kubeconfig är korrekt, nätverksvägen är det inte. Detsamma gäller Helm och Terraforms kubernetes- och helm-providers.

Klustrets autentiseringsuppgifter genereras och hålls säkert av plattformen — nodernas uppstartsbootstrap överför aldrig hemligheter tillbaka.

Klustrets slutpunkt är inte till för din trafik. Den är till för kubectl, Helm och din CI. Din egen trafik går till adressen för en lastbalanserare som du begär inifrån klustret — se Nå dina arbetslaster. Att peka en applikations DNS-post mot klustrets slutpunkt är precis det misstag den här skillnaden finns för att förhindra.

Nå dina arbetslaster

Ett kluster kommer utan lastbalanserare för din egen trafik. Du får en på Kubernetes standardsätt: skapa en Service av type: LoadBalancer, så tillhandahåller plattformen en lastbalanserare för den tjänsten, håller dina poddar kopplade som dess medlemmar och skriver tillbaka adressen till tjänsten.

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 visas som EXTERNAL-IP är den du ska peka din DNS mot.

En ingress-controller fungerar på samma sätt. Installera den du föredrar (Traefik, ingress-nginx, …) och exponera den med en type: LoadBalancer-tjänst i stället för en NodePort-tjänst. Det finns inga reserverade nodportar att låsa längre: Kubernetes väljer nodportarna själv och du behöver aldrig känna till dem. TLS termineras i ditt kluster, med dina egna certifikat — plattformen hanterar aldrig dina nycklar. Vad du mer kan installera, och vilka värden vissa diagram behöver, finns i Vad du kan göra i ditt kluster.

Några egenskaper värda att känna till:

• Varje sådan tjänst får sin egen lastbalanserare. Den visas i din vanliga lastbalanserarlista och debiteras som en lastbalanserare, precis som alla andra.
• Hantera den från Kubernetes, inte från lastbalanserar-API:t. Tjänsten är det som lastbalanseraren stäms av mot: ändra dess portar eller selektor så följer lastbalanseraren med.
• Raderar du tjänsten försvinner dess lastbalanserare med den. Ta bort dina tjänster innan du raderar klustret, så att inget lämnas kvar.
• Kubernetes API-slutpunkt är separat och är inte en av dessa — den tillhandahålls av plattformen, inte av någon av dina tjänster.

Publik eller intern

Som standard får en tjänsts lastbalanserare en intern adress från klustrets eget subnät — nåbar inifrån VPC:t, inte från internet. För att exponera den publikt, annotera tjänsten:

• En publik IP från poolen — frostmoln.se/lb-scheme: public. Plattformen tilldelar en publik IP, kopplar den till lastbalanseraren, publicerar den som tjänstens EXTERNAL-IP, och frigör den när du tar bort tjänsten.
• Ta med din egen publika IP — sätt även frostmoln.se/lb-public-ip-id: <public-ip-id>. Plattformen använder en publik IP du redan äger (den får inte redan vara i bruk) och behåller den när du tar bort tjänsten. Värdet är den publika IP:ns id (en UUID), inte dess adress — hitta det i listan över publika IP:er eller med CLI:t.

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
  # Vem som får nå den — se varningen nedan.
  loadBalancerSourceRanges:
    - 203.0.113.0/24

För att återanvända en publik IP du redan har, lägg till dess id vid sidan av schemat:

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

En publik tjänst utan källintervall är öppen mot hela internet

loadBalancerSourceRanges är åtkomstkontrollen för en publik lastbalanserare: datavägen bevarar klientens källadress, så det är verklig filtrering, inte en ledtråd. Utelämna det och tjänsten är nåbar från 0.0.0.0/0 — samma standard som hos andra moln. Sätt det till de CIDR-block som ska kunna nå tjänsten.

Vad plattformen registrerar på din Service

Medan plattformen arbetar med en Services lastbalanserare registrerar den Kubernetes-händelser på Servicen, med de orsaker som en molnleverantörs controller använder, så att kubectl describe service <name> visar läget:

• EnsuringLoadBalancer när den börjar skapa lastbalanseraren eller tillämpa en ändring på den;
• EnsuredLoadBalancer när det är klart, eller UpdatedLoadBalancer när bara uppsättningen noder bakom den har ändrats;
• DeletingLoadBalancer och sedan DeletedLoadBalancer när Servicen tas bort eller slutar vara type: LoadBalancer (för en borttagen Service listas de fortfarande av kubectl get events i dess namnrymd);
• en varning, SyncLoadBalancerFailed, vid varje försök som misslyckas. Servicen står kvar på EXTERNAL-IP <pending>, och meddelandet börjar med Error syncing load balancer: failed to ensure load balancer: följt av den specifika orsaken — PublicIPNotFound eller PublicIPInUse för ett eget id som inte är ditt eller redan används, PublicIPForbidden för en uttömd Public IP-pool eller kvot, RealiseFailed för allt annat — och vad du kan göra åt det.

En Service som inte har ändrats får inga händelser när plattformen kontrollerar den igen. Ett kluster vars kontrollplan är äldre än dessa händelser registrerar bara varningen, med den specifika orsaken som händelsens orsak; de övriga visas när kontrollplanet har uppgraderats. Kubernetes behåller händelser i en timme.

Den automatiska ingress-lastbalanseraren för arbetsnoder är borttagen

Kluster fick tidigare en ingress-lastbalanserare vid skapandet, som vidarebefordrade TCP 80 och 443 till fasta nodportar på varje arbetsnod, valt med inställningen ingressScheme (ingress_scheme i Terraform) och en valfri medtagen egen adress. Allt det är borta: det finns ingen ingress-inställning när du skapar ett kluster, och inga fasta nodportar att publicera. Använd en Service av type: LoadBalancer enligt ovan.

API-slutpunktens exponering är inte en inställning

Det finns ingen scheme-inställning på ett kluster, och inte heller publicIpId — båda avvisas. Svaret är fast, inte bara plattformsbestämt: API-slutpunkten är privat för ditt VPC, alltid. Se Hämta din kubeconfig.

Nodpooler

Ett kluster har en eller flera nodpooler — grupper av arbetarnoder av en given storlek. Från klustrets detaljsida kan du:

• Lägga till en nodpool (namn, storlek, nodantal), valfritt med labels och taints för schemaläggning (labels och taints är tills vidare endast tillgängliga i portalen — Terraform-resursen stöder dem inte ännu).
• Skala en pool genom att ange ett nytt nodantal.
• Radera en pool.

Skala manuellt tills vidare

Klusterets autoskalning är ännu inte tillgänglig — ange nodantalet explicit och skala pooler manuellt allteftersom din arbetslast ändras.

Beständig lagring

Kluster levereras med en Frostmoln CSI-lagringsklass, frostmoln-block (standard-StorageClass), backad av Frostmoln-blocklagring. Skapa en PersistentVolumeClaim så tillhandahålls och kopplas en volym automatiskt; volymer stöder utökning i drift.

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

Varje claims volym syns också i din volymlista, märkt Kubernetes. Se Kubernetes-volymer för hur de hanteras och vad som händer med dem när du tar bort klustret.

Nätverk

Klustrets CNI är Cilium. Klusternoder når internet endast om klustrets VPC har en Gateway — utan en har noderna varken utgående åtkomst, DNS-uppslag eller anslutning till hanterade tjänster, så lägg själv till en Gateway i VPC:t om de behöver något av det. Att skapa ett kluster lägger aldrig till en åt dig. Noderna är isolerade från Frostmolns interna nätverk oavsett — dina arbetslaster körs i sitt eget tenant-nätverk. Nå API-servern via klusterslutpunkten ovan, och exponera dina egna tjänster med en Service av type: LoadBalancer (se Nå dina arbetslaster).

Vad du kan göra i ditt kluster

Du är klustrets administratör. Din kubeconfig kan skapa vilken resurs som helst i dina egna namnrymder, och varje klusteromfattande resurs som plattformen inte reserverar — även CustomResourceDefinitions, ClusterRoles och ClusterRoleBindings (med valfria verb, även *) och admission-webhooks. Du installerar alltså operatorer från deras officiella Helm-diagram: Traefik (med sin CRD-provider), Argo CD, cert-manager (inklusive dess webhook), Kyverno, CloudNativePG, kube-prometheus-stack och liknande.

ServiceAccounts som du skapar omfattas av samma regler som din kubeconfig.

Det här är reserverat för Frostmoln

• Plattformens namnrymder — kube-system, kube-public, kube-node-lease, frostmoln-system, frostmoln-workload-identity, external-secrets och namnrymderna för tillägg som Frostmoln installerar åt dig (till exempel external-dns). Du kan se vad som körs där men inte ändra det. Undantaget är frostmoln-dns-hemligheten som du skapar i ExternalDNS namnrymd: den förblir din. I de sex som nämns först (kube-system till external-secrets) kan din kubeconfig inte heller läsa Secrets, ConfigMaps eller poddloggar. Tilläggens namnrymder innehåller inga plattformsautentiseringsuppgifter, så deras Secrets och ConfigMaps kan du läsa, en namnrymd i taget: en läsning över alla namnrymder (kubectl get secrets -A) nekas, eftersom den omfattar plattformsnamnrymderna.
• Klusterinfrastruktur — Nodes, StorageClasses, CSI-drivrutiner och PersistentVolumes (begär lagring med en PersistentVolumeClaim, se Beständig lagring), APIServices, API Priority and Fairness (FlowSchemas) och ServiceCIDRs.
• Plattformens API-grupper — CustomResourceDefinitions i frostmoln.cloud, frostmoln.se, cilium.io, external-secrets.io, k8s.io och kubernetes.io (och deras underdomäner), samt objekt i Ciliums (till exempel CiliumNetworkPolicy) och plattformens grupper. Använd en vanlig NetworkPolicy för nätverksregler; dina egna ExternalSecrets och SecretStores går bra.
• Services — en Service får inte sätta spec.externalIPs, och du kan inte själv skriva en Services status: lastbalanserarens adresser kommer från plattformen, så använd type: LoadBalancer. API-serverns egen kubernetes-Service i namnrymden default och dess endpoints är också reserverade. En lastbalanserar-controller som du kör själv (till exempel MetalLB eller kube-vip) kan därför inte tilldela adresser; använd type: LoadBalancer, som Frostmoln tillhandahåller (se Nå dina arbetslaster).
• Admission-policyer — ValidatingAdmissionPolicies och MutatingAdmissionPolicies. Använd en admission-webhook i stället.
• Identitet — att utge sig för att vara något annat än dina egna ServiceAccounts, och certifikatsignering via kubernetes.io-signerarna.
• Pod Security — Pod Security restricted tillämpas i hela klustret och en namnrymds Pod Security-etiketter kan inte ändras, så privilegierade poddar och poddar med hostNetwork, hostPID eller hostPath avvisas.
• Systemprioritetsklasser — poddar i dina namnrymder kan inte använda system-node-critical eller system-cluster-critical, eller någon prioritet över 1000000000, och de två klasserna kan inte ändras; de håller plattformens egna poddar schemaläggningsbara. Skapa en egen PriorityClass i stället. Ett diagram som som standard använder en systemklass, till exempel metrics-server, behöver värdet priorityClassName satt till din klass eller till en tom sträng.
• Kontrollplanets slutpunkter — kontrollplanets metrik- och felsökningsslutpunkter. Via Kubernetes-API:t är kubelet-API:t begränsat till nodernas metrik och statistik (nodes/metrics, nodes/stats); nodes/proxy och nodes/log är inte tillgängliga. Verktyg som når kubelet via API-serverns proxy — till exempel Grafana Alloy eller k8s-monitoring som skrapar /api/v1/nodes/<node>/proxy/metrics/cadvisor, eller Fluent Bit med Use_Kubelet On — avvisas; konfigurera dem att skrapa kubelet direkt på noden (som kube-prometheus-stack och metrics-server gör), vilket använder de tillåtna behörigheterna för nodmetrik och statistik.

Admission-webhooks

En webhook måste peka på en Service i ditt kluster, inte på en URL. Om varje regel gäller dina egna CRD-API-grupper godkänns webhooken som den är. En webhook som fångar upp inbyggda resurser — Pods, Deployments, Services och så vidare — måste dessutom:

• sätta timeoutSeconds till 10 eller lägre;
• sätta sideEffects: None (eller NoneOnDryRun);
• undanta plattformens namnrymder och tilläggens objekt med dessa 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

• lista resurserna i varje regel — ingen jokerteckenresurs (* eller */status);
• om den fångar upp Services, Endpoints eller EndpointSlices, även lista default bland NotIn-värdena för kubernetes.io/metadata.name — API-servern underhåller sina egna endpoints där;
• inte fånga upp nodes, RBAC, CRD:er, admission-konfiguration, leases, certifikat, lagrings- eller flowcontrol-resurser, PersistentVolumes, IPAddresses, ServiceCIDRs eller PriorityClasses.

Värden för Helm-diagram

Argo CD, Traefik (rbac.enabled=true, med sin CRD-provider) och CloudNativePG installeras med sina standardvärden. Några andra diagram behöver följande:

• cert-manager — global.leaderElection.namespace=cert-manager; standardvärdet lägger leader-election-objekten i kube-system.

• kube-prometheus-stack — kontrollplanet är hanterat och kan inte skrapas, och diagrammets kontrollplanskomponenter skulle skapa Services i kube-system. node-exporter behöver åtkomst till värden, vilket Pod Security avvisar. Peka kubelet-tjänsten mot din release-namnrymd:

  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 # din release-namnrymd

• Kyverno — när du lägger till policyer, sätt dess config.webhooks till namespaceSelector ovan plus objectSelector (Kyvernos standardvärden undantar bara kube-system). Dess TTL-städwebhook och dess generering av ValidatingAdmissionPolicies är inte tillgängliga; policyerna tillämpas via dess webhooks.

• ingress-nginx — dess admission-webhook fångar upp Ingress, en inbyggd resurs. Sätt controller.admissionWebhooks.namespaceSelector till namespaceSelector ovan och controller.admissionWebhooks.objectSelector till objectSelector ovan (dess standardtimeout och sideEffects: None uppfyller redan kraven), eller stäng av webhooken med controller.admissionWebhooks.enabled=false.

Begränsningar

• En zon per kluster — noder placeras i klustrets region/subnät; ingen multi-AZ-spridning idag.
• Cilium är den enda CNI:n — den är inte valbar för kunder.
• Inga uppgraderingar av versioner på plats ännu — välj din version när du skapar klustret.
• Autoskalning är ännu inte tillgänglig (skala nodpooler manuellt).
• Kvoter begränsar kluster och noder per tenant. Kontrollera dina kvoter och begär en höjning innan du skapar ett stort kluster.
• En arbetslast-lastbalanserare är intern som standard — en Service av type: LoadBalancer får en intern VPC-adress om du inte annoterar den frostmoln.se/lb-scheme: public (se Nå dina arbetslaster).
• Att radera ett kluster tar bort dess noder, dess API-lastbalanserare och dess lagrade autentiseringsuppgifter.

Relaterat

• Beräkning / Instanser · Nätverk: VPC:er · Nätverk: Gateway
• Nätverk: Lastbalanserare · Fakturering