Alcuni link in questa pagina sono link di affiliazione: se ti registri tramite questi link, il sito riceve una commissione senza costi aggiuntivi per te. Prezzi e consigli non cambiano.

Quattro argomenti che hanno attirato l’attenzione questa settimana, con il nostro parere su ciascuno. Gli originali sono linkati: leggili. Questa pagina spiega solo perché contano per un piccolo setup self-hosted.

1. Un resources: {} vuoto declassa silenziosamente i tuoi pod su Kubernetes da 1.34 a 1.36

Originale: An Empty resources: {} Makes Kubernetes 1.34 to 1.36 Pods BestEffort su devops-daily.com (anche su dev.to).

L’affermazione: se un pod imposta spec.resources: {} a livello di pod, il kubelet lo classifica come BestEffort anche quando ogni container ha requests e limits. Gli autori l’hanno misurato su k3s 1.34, 1.35 e 1.36: oom_score_adj è salito a 1000 e, accanto a un vicino molto carico, un pod che aveva richiesto mezza CPU ne otteneva da 0.06 a 0.08 core invece di circa 0.57. Una quota di namespace che blocca i pod BestEffort lo ha rifiutato. Su 1.37.1 le classi erano corrette. L’executor Kubernetes di GitLab Runner genera quel blocco vuoto nelle versioni da 18.10.0 a 19.4.3.

Il nostro parere: una correzione utile anche a un luogo comune. L’articolo mostra che l’affermazione diffusa “questi pod vengono sfrattati per primi” è sbagliata; l’ordine di eviction del kubelet non è cambiato. Controlla il tuo cluster in dieci secondi:

kubectl get pods -A -o custom-columns=NS:.metadata.namespace,POD:.metadata.name,QOS:.status.qosClass | grep BestEffort

Se un carico di lavoro che ha dei limits compare qui, hai trovato il problema. Se preferisci vedere la classe QoS in un’interfaccia, il nostro confronto delle GUI per Kubernetes copre gli strumenti che la mostrano a colpo d’occhio.

2. Un OpenStick da 10 USD come server domestico

Originale: What I run on my $10 USD OpenStick homelab (825 punti e 137 commenti su Hacker News).

L’hardware: quattro core Cortex-A53 a 1 GHz, 512 MB di RAM (circa 450 MB utilizzabili), 4 GB di eMMC, Debian con systemd e Podman, raffreddamento passivo. L’autore vi fa girare AdGuard Home (circa 40 MB) e alcune piccole utility.

Il nostro parere: la parte interessante non è il gadget, ma la disciplina sul budget. Servizi misurati in decine di megabyte sono il default giusto per un blocker DNS, un monitor di uptime o un notificatore. Quando un servizio supera i 512 MB, il passo successivo onesto è un piccolo VPS invece di una macchina più grande sotto la scrivania; il nostro confronto dei VPS mostra cosa offrono oggi da 4 a 6 EUR al mese.

3. HolyArrs: uno stack multimediale self-hosted da 15 MB

Originale: HolyArrs su GitHub, pubblicato come “Show HN: A 15 MB self-hosted Netflix and Spotify for your media server” (circa 160 punti e 125 commenti su Hacker News).

Il progetto sostituisce sei app multimediali separate con un unico binario: circa 15 MB da scaricare, circa 140 MB di RAM a riposo con 10.000 titoli, build per amd64, arm64 e armv7, licenza AGPL-3.0.

Il nostro parere: dopo lo sfruttamento di Plex di questa stagione, una superficie di attacco più piccola è ciò che attira l’attenzione. Un solo binario piccolo è più facile da verificare di sei app, ma un progetto giovane non ha ancora una storia di sicurezza. Nota che 15 MB è il download, non l’impronta in memoria: con 140 MB a riposo starebbe appena sull’OpenStick qui sopra. Qualunque cosa tu scelga, tienila dietro a un reverse proxy senza porta pubblicata direttamente; Docker aggira ufw per le porte pubblicate, cosa che abbiamo misurato nelle nostre trappole di Docker in produzione.

4. NVIDIA pubblica NVKE, un piano di gestione per Kubernetes GPU

Originale: dsx-ai-factory/nvke (124 punti e 30 commenti su Hacker News).

NVKE è un piano di gestione in cui ogni cluster di carico di lavoro ottiene il proprio control plane, etcd e node pool. Il README la definisce una preview e sconsiglia l’uso in produzione. Un quickstart locale avvia un piano di gestione e un cluster di carico di lavoro su macchine simulate, così puoi provarla senza hardware GPU.

Il nostro parere: irrilevante per un singolo server, rilevante come segnale che il cluster per cliente sta diventando un prodotto confezionato. Se gestisci uno o due cluster, continua con k3s e riconsidera NVKE quando l’etichetta preview sarà sparita.

Cosa faremmo questa settimana

  • Esegui il controllo BestEffort qui sopra su ogni cluster da 1.34 a 1.36.
  • Se usi l’executor Kubernetes di GitLab Runner, aggiorna alla 19.5.0 o successiva, come raccomanda il rapporto originale.
  • Non spostare nulla di critico su software in preview.