Some links on this page are affiliate links: if you sign up through them, this site earns a commission at no extra cost to you. Prices and recommendations are not affected.

Four things that picked up attention this week, with what we think of each. The originals are linked; read them. This page only tells you why they matter for a small self-hosted setup.

1. An empty resources: {} quietly downgrades your pods on Kubernetes 1.34 to 1.36

Original: An Empty resources: {} Makes Kubernetes 1.34 to 1.36 Pods BestEffort on devops-daily.com (also on dev.to).

The claim: if a pod sets spec.resources: {} at pod level, the kubelet classifies it as BestEffort even when every container has requests and limits. The authors measured it on k3s 1.34, 1.35 and 1.36: oom_score_adj jumped to 1000, and next to a busy neighbour a pod that requested half a CPU got 0.06 to 0.08 cores instead of about 0.57. A namespace quota that blocks BestEffort pods rejected it. On 1.37.1 the classes were correct. GitLab Runner’s Kubernetes executor generates that empty block from version 18.10.0 to 19.4.3.

Our take: a useful correction to folklore as well. The article shows that the popular claim “these pods are evicted first” is wrong; the kubelet’s eviction order did not change. Check your cluster in ten seconds:

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

If a workload that has limits shows up there, you have found it. If you prefer to see QoS class in a UI, our Kubernetes GUI comparison covers the tools that show it at a glance.

2. A 10 USD OpenStick as a home server

Original: What I run on my $10 USD OpenStick homelab (825 points and 137 comments on Hacker News).

The hardware: four Cortex-A53 cores at 1 GHz, 512 MB of RAM (about 450 MB usable), 4 GB of eMMC, Debian with systemd and Podman, passively cooled. The author runs AdGuard Home (about 40 MB) and a handful of small utilities on it.

Our take: the interesting part is not the gadget, it is the budget discipline. Services measured in tens of megabytes are the right default for a DNS blocker, an uptime monitor or a notifier. When a service outgrows 512 MB, the next honest step is a small VPS rather than a bigger box under the desk; our VPS comparison shows what 4 to 6 EUR a month buys today.

3. HolyArrs: a 15 MB self-hosted media stack

Original: HolyArrs on GitHub, posted as “Show HN: A 15 MB self-hosted Netflix and Spotify for your media server” (about 160 points and 125 comments on Hacker News).

The project replaces six separate media apps with one binary: about 15 MB to download, about 140 MB of RAM idle with 10,000 titles, builds for amd64, arm64 and armv7, AGPL-3.0.

Our take: after the Plex exploitation earlier this season, a smaller attack surface is the selling point people are reacting to. One small binary is easier to audit than a stack of six apps, but a young project has no security track record yet. Note that 15 MB is the download, not the memory footprint: at 140 MB idle it would still fit on the OpenStick above, barely. Whatever you pick, keep it behind a reverse proxy with no directly published port; Docker bypasses ufw for published ports, which we measured in our Docker production gotchas.

4. NVIDIA publishes NVKE, a management plane for GPU Kubernetes

Original: dsx-ai-factory/nvke (124 points and 30 comments on Hacker News).

NVKE is a management plane in which every workload cluster gets its own control plane, etcd and node pools. The README labels it a preview and does not recommend it for production workloads. A local quickstart runs a management plane and a workload cluster on simulated machines, so you can try it without GPU hardware.

Our take: irrelevant for a single server, relevant as a signal that cluster-per-customer is turning into a packaged product. If you run one or two clusters, keep using k3s and revisit NVKE when the preview label is gone.

What we would do this week

  • Run the BestEffort check above on any 1.34 to 1.36 cluster.
  • If you use GitLab Runner’s Kubernetes executor, upgrade it to 19.5.0 or later, as the original report recommends.
  • Do not move anything production-grade onto preview software.