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.

Pilot — åtkomst beviljas per tenant

Hanterad Kubernetes rullas ut som en pilot. Den visas i portalen endast för tenanter som har beviljats behörigheten kubernetes — om du inte ser Kubernetes i navigeringen är det inte aktiverat för din tenant ännu. Kontakta supporten för att begära åtkomst (det finns ingen självbetjäningsaktivering under piloten).

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.small / k8s.gp1.medium / k8s.gp1.large) 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.

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.

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

Kubernetes API-servern nås genom en dedikerad lastbalanserad slutpunkt (port 6443). 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.

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.

Endast interna adresser idag — ingen publik ingångspunkt ännu

En lastbalanserare som tillhandahålls för en Service får en intern adress, från klustrets eget subnät: nåbar inifrån VPC:t, inte från internet. En publik adress för en sådan tjänst är ännu inte byggd, så en arbetslast i klustret har just nu ingen stödd publik ingångspunkt. Om din arbetslast måste vara nåbar från internet är det inte något det här klustret kan göra idag.

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. Hur Kubernetes API-slutpunkt exponeras avgörs av plattformen, inte per kluster — att skicka scheme avvisas.

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

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

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).
• Ingen publik adress för en arbetslast-lastbalanserare ännu — en lastbalanserare som tillhandahålls för en Service av type: LoadBalancer är intern i VPC:t.
• 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