3. juni 2026|Artikler

Kubernetes på Proxmox

Av Torkild

Denne veiledningen viser hvordan man enkelt kan sette opp et fungerende Kubernetes-labmiljø på Proxmox. For å få utbytte av den bør man allerede være komfortabel med Linux/terminal, SSH-nøkler, grunnleggende Proxmox-administrasjon, nettverk og ha kjennskap til sentrale Kubernetes-begreper.

For å eksperimentere med Kubernetes trenger vi en klynge vi kan starte, rive ned og bygge opp igjen deterministisk og ofte. Full Kubernetes er relativt tungt å installere og drifte. Derfor har det vokst frem flere lettvektsdistribusjoner som beholder Kubernetes API-et, men reduserer kompleksitet og ressursbruk. Disse brukes ofte i lab, edge-miljøer, CI-systemer eller små produksjonsinstallasjoner.

Til denne laben har jeg valgt k3s, men der er også andre gode alternativer.

k0s er en lettvektsdistribusjon fra Mirantis som forsøker å levere “ren Kubernetes” uten ekstra kompleksitet. Den distribueres som én binærfil og skiller tydelig mellom control plane og worker_´-noder. Den har få føringer og gir god kontroll over hvilke komponenter som brukes. Dette kan være en fordel i enkelte oppsett, men innebærer mer konfigurering og færre standardvalg sammenlignet med f.eks. k3s.

MicroK8s er Canonical sin lettvektsdistribusjon, primært rettet mot utvikling og små servermiljøer. Den installeres vanligvis via snap-pakker og tilbyr mange funksjoner som kan aktiveres eller deaktiveres som moduler, for eksempel ingress, registry eller observerbarhetsverktøy. Den er relativt enkel å ta i bruk, men snap-basert distribusjon og noe tyngre komponentsett gjør at den ikke alltid passer like godt i minimaliserte servermiljøer. Canonical promoterer et «dashboard» som gjør det enkelt å holde oversikten – men dette er ikke lenger vedlikeholdt.

Minikube er først og fremst laget for lokal utvikling. Formålet er å teste applikasjoner mot Kubernetes-APIet uten å sette opp en faktisk klynge. Den brukes derfor nesten utelukkende i utviklings- og testmiljøer og er normalt ikke aktuell som plattform for varige installasjoner. Minikube er utrolig nyttig for å dra opp en testrigg på egen arbeidsstasjon/laptop.

kind (Kubernetes in Docker) er et verktøy som starter Kubernetes-noder som Docker-containere. Det brukes særlig i CI-systemer og i utvikling av Kubernetes-komponenter, fordi klynger kan opprettes og fjernes svært raskt. Arkitekturen gjør den godt egnet til automatiserte tester, men mindre egnet til langvarig drift eller realistiske produksjonslignende miljøer.

k3s er utviklet av Rancher (nå SUSE). Den er designet for å være en svært kompakt Kubernetes-distribusjon som kan installeres med én kommando. Den pakker mange komponenter i én binærfil og bruker enklere standardvalg, for eksempel SQLite i små installasjoner eller [etcd]() i større. I tillegg inkluderer den en ferdig konfigurert og lettvekts stakk med containerd som container runtime, Flannel for nettverk, CoreDNS for tjenesteoppslag og Traefik som ingress-controller. Flere kontrollplan-komponenter som API-server, scheduler og controller manager kjøres samlet i én prosess, noe som reduserer ressursbruk og kompleksitet. K3s leverer også innebygde mekanismer for enkel lastbalansering og lagring, og er særlig godt egnet for edge, IoT og utviklingsmiljøer der man ønsker en fullverdig Kubernetes-opplevelse med minimalt overhead.

Krav til denne lab-en

Å sette opp en Kubernetes-lab som denne for hånd er noe komplisert, tidkrevende og det er fort gjort å gjøre feil. Derfor har vi her en rekke skript som forenkler denne prosessen og sørger for at det blir likt hver eneste gang. Her kunne man helt sikkert brukt Terraform og kanskje Ansible i stedet. Men dette vil innføre noen ekstra teknologier som vi ikke er helt klare for akkurat nå. Kravene vi stiller til oppsettet er som følger:

Kunne kjøre skript fra en Proxmox VE-vert (typisk som root). Se f.eks. Sett opp en lab med Proxmox for veiledning.
SSH-tilgang fra Proxmox-verten til opprettede VM-er med ~/.ssh/id_ed25519 (opprettes automatisk av lab.sh up hvis den mangler).
Verktøy brukt av skriptene inkluderer qm, ip, ssh, awk, sed, grep, ping, xargs, virt-customize, kubectl. Disse må være installert på Proxmox-verten. På Debian/Proxmox leveres virt-customize normalt av pakken libguestfs-tools.
Maskinvarekrav til VM-ene:
CPU: standardtildelingen er 10 vCPU totalt (server 4 + workers 3 x 2).
RAM: standardtildelingen er 30 GiB fordelt på alle nodene (server 6 GiB + workers 3 x 8 GiB). Merk at server-noden trenger omtrent 2,5GiB og worker-nodene i underkant 1,5GiB bare for å fungere.
Disk: minst 130 GiB VM-disk (40 + 3 x 30 GiB), pluss ekstra plass til Proxmox, snutter, logger og konteinerbilder.
Total CPU-, RAM- og diskbruk følger direkte av oppsettet: WORKER_IDS_CSV, SERVER_CORES, WORKER_CORES, SERVER_MEMORY_MB, WORKER_MEMORY_MB, SERVER_DISK_GB og WORKER_DISK_GB.
Nok RAM og CPU til å drive gateway-noden: 1 kjerne og 512 MiB RAM.

Worker-antallet styres av WORKER_IDS_CSV i scripts/lab-config.env. Når listen endres og man kjører ./lab.sh up på nytt, opprettes worker-noder som mangler og worker-noder som er tatt ut av listen fjernes. Hvis man vil holde worker-MAC-er faste, bruk WORKER_MACS_CSV med samme antall elementer som WORKER_IDS_CSV.

Litt om cloud-init

cloud-init er nøkkelen til at denne laben og de enkelte nodene kan bygges likt hver gang. I stedet for skripting eller manuell kjøring inne i hver enkelt VM beskriver vi ønsket oppsett i filer som brukes ved oppstart av nye noder.

I denne veiledningen brukes cloud-init til å:

sette nettverkskonfigurasjon (IP, gateway, DHCP/statisk).
installere og konfigurere tjenester på gateway (DNS, DHCP, NAT, NTP).
opprette brukere og SSH-tilgang.

Resultatet er raskere reprovisjonering, færre feil og et miljø som er enklere å feilsøke.

Nettverket

En viktig komponent i dette oppsettet er nettverket. Vi ønsker full kontroll samt å isolere laben fra resten av lokalnettet.

Målet er å få en k3s-lab som er:

isolert fra resten av lokalnettet
forutsigbar (faste IP-er eller kontrollert DHCP)
enkel å feilsøke
trygg å eksperimentere i (egen DHCP/DNS/NAT)

Det viktigste prinsippet er: én DHCP-server per L2-segment. Hvis LAN-ruter og lab-gateway deler samme segment, kan noder få IP fra feil server. Det gir tilfeldig oppførsel, feil default gateway og vanskelig feilsøking. Derfor legges k3s-nodene på en egen bridge (vmbr1) – denne har ikke en egen fysisk tilkobling, men går via vmbr0 som er den brua til LAN som blir laget når vi installerer Proxmox.

Topologien over viser to soner:

vmbr0 (WAN/LAN): Proxmox-verten og gatewayens WAN-side.
vmbr1 (lab-LAN): control plane + workers bak lab-gw.

lab-gw er eneste vei ut av lab-LAN og håndterer DHCP, DNS, NTP og NAT.

La oss komme i gang

Sjekk ut kildekoden med alle skriptene og veiledninger til Proxmoxverten – dette er viktig da skriptene må kjøres fra Proxmox. I roten av det vi har sjekket ut finner vi en README.md som forklarer oppsettet, sammen med skriptet lab.sh – det er dette vi trenger for å sette opp lab-en.

�� Hvis miljøvariabelen TAILSCALE_AUTH_KEY er satt, vil Tailscale settes opp på control plane noden (k3s-server-1). Dette gjør det mulig å nå klyngen via Kubernetes-APIet fra f.eks. arbeidsstasjon gjennom et Tailnet.

I skriptet skjer følgende:

oppretter SSH-nøkkelpakke (~/.ssh/id_ed25519 og .pub), og legger den offentlige nøkkelen ligger i ~/.ssh/authorized_keys
starter nettverksbru, lager mal for VM-ene, lab-gateway, noder og klyngeinstallasjon i riktig rekkefølge
starter alle VM-ene og venter til alt er klart

Sluttrapporten fra å kjøre lab.sh up skal bli noe som dette:

Server kubeconfig (on server node): /etc/rancher/k3s/k3s.yaml
Client kubeconfig (local): ./kubeconfig-k3s.yaml
Client API endpoint in kubeconfig: https://k3s-controlplane.tailad1f0.ts.net:6443
Host kubeconfig copy: /root/.kube/clusters/proxmox-k3s.yaml
Host kubeconfig merged into: /root/.kube/config
Host context updated: proxmox-k3s
Host API endpoint in kubeconfig: https://10.42.0.11:6443

Verify on this Proxmox host:
  kubectl config use-context proxmox-k3s && kubectl get nodes

Workstation access (kubectl/k9s):
  Gateway (lab-gw):
     WAN IP: 10.0.0.107
     LAN IP: 10.42.0.1
  1) Copy kubeconfig from this Proxmox host:
     scp root@<proxmox-host>:/root/proxmox-scripts/kubeconfig-k3s.yaml ~/.kube/clusters/proxmox-k3s.yaml
  2) Merge into your local kubeconfig:
     KUBECONFIG="$HOME/.kube/clusters/proxmox-k3s.yaml:$HOME/.kube/config" kubectl config view --flatten > ~/.kube/config.new && mv ~/.kube/config.new ~/.kube/config
  3) Select context and verify API access:
     kubectl config use-context proxmox-k3s && kubectl get nodes

Legg merke til gateway-en sin WAN IP. Det er denne vi skal bruke når vi fra utsiden kommuniserer med tjenester inne i klyngen. Denne er tildelt av DHCP-serveren som står på vmbr0. På Proxmox-verten settes kubecontext opp automatisk med serverens LAN IP, så kubectl get nodes kan kjøres direkte. Følg oppskriften under hvis du vil bruke arbeidsstasjonen din.

NAME           STATUS   ROLES           AGE   VERSION
k3s-server-1   Ready    control-plane   13m   v1.34.4+k3s1
k3s-worker-1   Ready    <none>          13m   v1.34.4+k3s1
k3s-worker-2   Ready    <none>          13m   v1.34.4+k3s1
k3s-worker-3   Ready    <none>          13m   v1.34.4+k3s1

Legg til K3s-kontekst i eksisterende kubeconfig på arbeidsstasjonen

Kopier konfigurasjon fra Proxmox-verten (der scripts/k3s-install-cluster.sh ble kjørt). Denne delen gjelder bare arbeidsstasjonen; på Proxmox-verten er konteksten allerede lagt til automatisk med intern server-IP. Merk at vi forutsetter at du har satt opp Tailscale på Proxmox-verten.

mkdir -p ~/.kube/clusters
scp root@proxmox.tailad1f0.ts.net:/root/proxmox-scripts/kubeconfig-k3s.yaml ~/.kube/clusters/proxmox-k3s.yaml
chmod 600 ~/.kube/clusters/proxmox-k3s.yaml

Den genererte konfigurasjon bruker allerede konteksten proxmox-k3s. Ta sikkerhetskopi og flett inn med eksisterende kubeconfig.

cp ~/.kube/config ~/.kube/config.bak.$(date +%Y%m%d%H%M%S)
KUBECONFIG="$HOME/.kube/clusters/proxmox-k3s.yaml:$HOME/.kube/config" \
  kubectl config view --flatten > ~/.kube/config.new && mv ~/.kube/config.new ~/.kube/config

Verifiser og bytt kontekst

kubectl config get-contexts
kubectl config use-context proxmox-k3s
kubectl get nodes

Kjør merge-steget på nytt hver gang kubeconfigen regenereres på Proxmox-verten.

“Hello World” via gateway

Nå som klyngen er oppe kan vi verifisere både Kubernetes og gateway-ruting med en liten test-applikasjon. Vi lager to kopier (replika) av samme applikasjon (Deployment). Fortsetter så med en Service som peker på applikasjonen samt en Ingress som peker på Service-instansen.

Kjør fra Proxmox-verten (eller arbeidsstasjon med riktig kubeconfig):

cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello:plain-text
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
spec:
  ingressClassName: traefik
  rules:
  - host: hello.lab
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello
            port:
              number: 80
EOF

Hvis vi nå kjører et par curl-kall mot denne tjenesten får vi noe som dette:

root@proxmox:~# curl -s -H 'Host: hello.lab' http://10.0.0.107/ | head
Server address: 10.244.3.3:80
Server name: hello-7fc9b7988b-brhrj
Date: 06/Apr/2026:20:56:13 +0000
URI: /
Request ID: 61b4fd0743861270b7bbe674c59b9e9e
root@proxmox:~# curl -s -H 'Host: hello.lab' http://10.0.0.107/ | head
Server address: 10.244.4.3:80
Server name: hello-7fc9b7988b-2ngrl
Date: 06/Apr/2026:20:56:14 +0000
URI: /
Request ID: 8ec1d01451fc5ebff669fea7940327bd

Legg merke til at vi for hvert kall til tjenesten får svar fra en ny pod. Dette er Traefik sin default lastbalansering, Weighted Round Robin i praksis. Her ser vi også at Server address slettes ikke er nodene sine IP-addresser, men fra pod-nettet (10.244.x.x).

Oppsummering

I denne veiledningen har vi bygd en komplett Kubernetes-lab på Proxmox, med isolert labnett, gateway for NAT/DHCP/DNS, og fire noder (en server og tre worker).

Til slutt har vi verifisert oppsettet med en enkel applikasjon, og sett i praksis hvordan lastbalansering mellom podder fungerer. Vi har nå en reproduserbar lab som gjør det enkelt å teste Kubernetes i et kontrollert miljø.

Relaterte artikler

Hopp til nedenfor elementlisten