Francesco Oghabi

K3s: Kubernetes Senza il Peso di Kubernetes

K3s spiegato da chi lo usa in produzione. Quando ha senso, come installarlo, e cosa aspettarsi da Kubernetes in 512MB di RAM.

Kubernetes e fantastico finche non devi farlo girare su una Raspberry Pi. O su un VPS da 1GB di RAM. O su 50 dispositivi edge sparsi per il mondo. Il "vanilla" Kubernetes ha bisogno di risorse che in certi scenari semplicemente non ci sono.

K3s nasce per risolvere questo problema. E Kubernetes, ma ridotto all'osso. Stesso API, stessi concetti, un decimo delle risorse. Lo uso da tre anni in vari contesti e ho imparato dove brilla e dove ha limiti.

Cos'e K3s

K3s e una distribuzione Kubernetes certificata, creata da Rancher (ora parte di SUSE). "Certificata" significa che passa tutti i test di conformita Kubernetes. Se funziona su K8s, funziona su K3s. Stesso kubectl, stessi manifest, stesso tutto.

La differenza sta in come e fatto:

  • Singolo binario — tutto il control plane in un eseguibile da ~70MB
  • SQLite come default — niente etcd cluster da gestire (ma puoi usare etcd o altri database se vuoi)
  • Componenti opzionali rimossi — niente cloud provider integrati, storage driver ridotti al minimo
  • Traefik incluso — ingress controller gia pronto out of the box
  • Containerd invece di Docker — piu leggero e comunque lo standard ormai

Il risultato e un Kubernetes che gira con 512MB di RAM su un server, 200MB per gli agent. Numeri impensabili per un cluster standard.

Quando Ha Senso Usarlo

Non usare K3s solo perche e "piu semplice". Se hai risorse, usa una distribuzione standard. K3s ha senso in scenari specifici.

Edge Computing

Il caso d'uso principale. Hai dispositivi distribuiti — negozi, fabbriche, punti vendita — e vuoi deployare applicazioni containerizzate. K3s gira su ARM, su x86, su hardware modesto. Puoi avere lo stesso workflow Kubernetes che usi nel data center anche su una macchina in un magazzino.

Sviluppo Locale

Un cluster K3s sul laptop per testare i tuoi manifest prima di deployare in staging. Piu leggero di Minikube, piu simile a un cluster reale di Kind. Se il tuo laptop non e un mostro di potenza, K3s e gentile con le risorse.

Home Lab

Vuoi sperimentare con Kubernetes a casa ma hai solo Raspberry Pi o vecchi PC? K3s e perfetto. Ho un cluster di 3 Pi che fa girare Home Assistant, Grafana, e vari servizi personali. Funziona benissimo.

VPS Piccoli

Quei VPS da 5€/mese con 1-2GB di RAM. Un Kubernetes standard non ci gira. K3s si, e ti lascia anche risorse per i tuoi workload.

CI/CD

Cluster effimeri per test. Creare un cluster K3s richiede secondi, non minuti. Per pipeline che hanno bisogno di testare deployment Kubernetes, K3s e ideale.

Installazione

L'installazione di K3s e quasi imbarazzantemente semplice.

Server (Control Plane)

curl -sfL https://get.k3s.io | sh -

Si, e tutto. Un comando. Dopo qualche secondo hai un cluster funzionante. Il kubeconfig e in /etc/rancher/k3s/k3s.yaml.

# Verifica
sudo k3s kubectl get nodes

Agent (Worker Nodes)

Sul server, recupera il token:

sudo cat /var/lib/rancher/k3s/server/node-token

Sugli agent:

curl -sfL https://get.k3s.io | K3S_URL=https://server-ip:6443 K3S_TOKEN=token-dal-server sh -

Fatto. L'agent si collega al server e appare come nodo nel cluster.

Configurazione

Puoi configurare K3s con flag o con file YAML in /etc/rancher/k3s/config.yaml:

# /etc/rancher/k3s/config.yaml
write-kubeconfig-mode: "0644"
tls-san:
  - "k3s.example.com"
  - "192.168.1.100"
disable:
  - traefik  # Se vuoi usare un altro ingress

High Availability

K3s supporta HA con due approcci:

Embedded etcd (consigliato)

Da K3s 1.19+ puoi avere un cluster etcd embeddato. Servono almeno 3 server.

# Primo server
curl -sfL https://get.k3s.io | sh -s - server --cluster-init

# Altri server
curl -sfL https://get.k3s.io | sh -s - server \
  --server https://first-server:6443 \
  --token token-dal-primo-server

Database Esterno

Puoi usare MySQL, PostgreSQL, o etcd esterno come datastore:

curl -sfL https://get.k3s.io | sh -s - server \
  --datastore-endpoint="mysql://user:pass@tcp(host:3306)/k3s"

Per la maggior parte degli usi, embedded etcd funziona bene. Database esterno ha senso se hai gia un database managed che vuoi riutilizzare.

Networking

K3s usa Flannel come CNI di default con VXLAN. Funziona, e semplice, non richiede configurazione. Per la maggior parte degli scenari edge e piu che sufficiente.

Se hai bisogno di network policy, Flannel non le supporta. Puoi sostituirlo con Calico:

curl -sfL https://get.k3s.io | sh -s - --flannel-backend=none \
  --disable-network-policy

# Poi installa Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Per scenari con requisiti di rete particolari (multi-cluster, service mesh), Cilium e un'altra opzione supportata.

Storage

K3s include Local Path Provisioner di default. Crea volumi sulla macchina locale. Per sviluppo e testing va bene, per produzione dipende dal caso.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 1Gi

Per storage distribuito in cluster multi-nodo, Longhorn (di cui ho parlato in un altro articolo) si integra perfettamente con K3s. Stessa azienda, pensati per funzionare insieme.

Traefik: Ingress Incluso

K3s installa Traefik come ingress controller di default. E gia configurato e funzionante. Puoi creare Ingress resources e funzionano immediatamente.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Se preferisci nginx-ingress o altro, puoi disabilitare Traefik:

curl -sfL https://get.k3s.io | sh -s - --disable=traefik

K3s vs K8s: Differenze Pratiche

Sulla carta sono compatibili. In pratica, qualche differenza c'e.

Cosa Funziona Uguale

  • Tutti i workload standard (Deployment, StatefulSet, DaemonSet, etc.)
  • Helm charts
  • Kubectl e tutti i tool CLI
  • La maggior parte degli operator
  • Service mesh (Istio, Linkerd)

Cosa E Diverso

  • Niente cloud provider integrati (se ti servono, installali separatamente)
  • Default storage e local-path, non cloud volumes
  • Alcune feature enterprise (audit logging avanzato, encryption at rest) richiedono configurazione extra
  • Il control plane e un processo singolo, non pod separati

Cosa Puo Non Funzionare

  • Alcuni operator che assumono di girare su cluster "standard" possono avere problemi
  • Tool che si aspettano etcd accessibile direttamente
  • Alcune dashboard che fanno assunzioni sul layout del cluster

In tre anni di uso, ho trovato forse 2-3 Helm chart che avevano problemi su K3s, e in genere erano bug dei chart, non di K3s.

Upgrade

Gli upgrade di K3s sono semplici. Ri-esegui lo script di installazione e lui si aggiorna:

curl -sfL https://get.k3s.io | sh -

Per cluster HA, aggiorna un server alla volta. Per cluster con agent, aggiorna prima i server poi gli agent.

K3s supporta anche un sistema di auto-upgrade con un controller dedicato:

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml

Crei dei Plan che definiscono la versione target, e il controller aggiorna i nodi automaticamente con rolling update.

Monitoring

K3s non include monitoring out of the box, ma integrarlo e facile.

# kube-prometheus-stack via Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack

Occhio alle risorse: kube-prometheus-stack di default vuole parecchia memoria. Su cluster edge potrebbe essere troppo. In quel caso, un Prometheus standalone con configurazione minimale funziona meglio.

Backup

Il datastore e la cosa critica da backuppare.

SQLite (default)

# Il database e un file
sudo cp /var/lib/rancher/k3s/server/db/state.db /backup/

Embedded etcd

k3s etcd-snapshot save --name backup-name
# Snapshot salvato in /var/lib/rancher/k3s/server/db/snapshots/

Per restore:

k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot

Scenari Reali

Qualche esempio di come uso K3s in produzione.

Retail edge — Cluster K3s su hardware in negozi. Ogni negozio ha il suo mini-cluster che fa caching locale, sincronizzazione dati, e gira applicazioni specifiche. GitOps con Fleet per gestire deployment su decine di cluster.

Home lab — 3 Raspberry Pi 4 con K3s, Longhorn per storage, ArgoCD per deployment. Costa meno di un caffe al mese di elettricita e mi permette di sperimentare come su un cluster vero.

Sviluppo — K3s su laptop per testare manifest e chart prima di pushare. Parte in 20 secondi, si ferma in 5. Non devo aspettare che Minikube booti una VM.

Conclusione

K3s non e un sostituto di Kubernetes standard per cluster grossi e complessi. E Kubernetes per scenari dove il "vero" Kubernetes sarebbe overkill o impossibile.

Se hai edge computing, risorse limitate, o vuoi Kubernetes senza il peso operativo di un cluster enterprise, K3s e probabilmente quello che cerchi. Se hai un data center con risorse infinite e team dedicati, usa una distribuzione standard.

Come sempre, lo strumento giusto dipende dal problema. K3s risolve problemi specifici molto bene. Per quei problemi, e la scelta ovvia.

Kubernetes non deve per forza essere pesante. A volte meno e meglio.