GPUs in Kubernetes and a 2 GB server: why Docker Compose is enough for a small business

This week the CNCF and Netflix published four technical write-ups on Kubernetes: how to share GPUs between tenants, why the autoscaler and the scheduler argue about node shape, how Netflix automatically trims its containers, and how Kyverno is moving into the Linux kernel. All of it solves the problems of companies with hundreds of teams. What a small business owner gets out of it is something else: understanding which of these problems they have at all, and not paying to solve the rest.

What came out

The CNCF on October 23 showed a lab built from two open projects. Kamaji runs each tenant's Kubernetes control plane as pods inside one shared cluster, and HAMi lets a pod ask for a slice of a GPU, memory in megabytes and a share of compute in percent. The author describes the problem in the first paragraph: Kubernetes hands out GPUs whole, and a pod that needs 4 GB out of 80 takes the entire card. The author assembled all of it on one machine with no physical GPU, through HAMi's mock plugin, on 4 cores and 8 GB of memory.

The CNCF on October 19 explained why a pod with a GPU can hang in pending when the region has capacity. The scheduler places a pod on an existing node, the autoscaler adds nodes, and for ten years these two loops never had to agree with each other. With accelerators, the autoscaler adds a node of the wrong shape, and the scheduler won't place the pod on it. The community's answer is called Dynamic Resource Allocation: instead of a number, “I need 2 GPUs,” the pod describes a structured request.

Netflix on October 14 told the story of the Stratum Resource Tuner. The video processing platform starts hundreds of thousands of containers a day, and the owners of each function set its limits in YAML: 8 CPUs, 18,000 MB of memory, 50,000 MB of disk. Those numbers are usually copied from a neighboring function and padded just in case. The tuner collects actual usage, issues a recommendation, verifies it with an experiment, applies or rejects it, and keeps watching the function. They started with workloads that don't mind latency: those account for 70 to 80% of usage.

The CNCF on October 15 described Nirmata Runtime for Kyverno. Regular Kyverno checks the manifest on the way in: is the pod described correctly. The new part works in the kernel through eBPF and LSM and answers a different question: is the pod doing what it promised. Every policy first runs in observe mode and shows what it would have blocked. The example in the article is about agents: the pod is allowed only the internal gateway to the model, reading credential files is denied, and a prompt injection inside the agent can't get around that, because the rule doesn't live in the agent's process.

Which of these problems a small business has

Take a car rental company. It has a booking website, a backend with a CRM integration and an app for managers: three or four containers and one team of one or two developers. There are no tenants whose control plane needs isolating. There is no GPU. An autoscaler isn't needed because the load is known: dozens of bookings a day.

Of the four articles, two ideas apply to a company like that. The first, from Netflix: container limits get set “with headroom” and never touched again, and then memory runs out at the least convenient moment. The second, from Nirmata: a container should see only what it is entitled to, and that rule doesn't depend on size. The rest solves problems three containers don't have, and Kubernetes adds a control plane that somebody has to update and fix.

How I do it

The “Coffee Together” service, which I designed and built in September and October 2026, and my site kononov.dev live on a shared server with 2 GB of memory, in Docker behind Nginx. The server is small, so the containers have hard memory limits, and during an update the old instance stops before the new one starts. If the build runs out of memory, the image is built off the server and uploaded ready-made. The service saves employees and administrators more than 100 hours a month, and no orchestrator was needed for that.

At the PDR company in the US the task is bigger: since 2022, our own server on Debian in Google Cloud has been running MariaDB, the API, the website and telephony on our own PBX, and the company has more than 30 people. There is no Kubernetes in that stack, and there have been no serious failures that needed a recovery since 2022. At that scale resources are easier to split by hand; an automatic tuner isn't needed.

What I would do

Count the containers and the teams. One team and fewer than ten services: one server, Docker Compose or a similarly simple setup behind Nginx. Discuss moving to Kubernetes when there are several teams with different permissions, a GPU, or load that changes several times over within a day.

Set a memory limit on every container and check it under load. Revisit in six months: that is the manual version of the Netflix tuner.

Decide what happens during an update. On a small server two instances won't fit, so the old one stops before the new one starts, and you need to know that in advance.

Build the image on another machine if the server is short on memory.

Restrict the container's network and secrets following the principle from the Nirmata article: only the addresses and files it needs for its work. You don't need eBPF for that; a Docker network and environment variables are enough.

Related materials

I wrote about the server as the center of a system in the article The server: data, access and process execution. Direction: infrastructure you can ship and restore. Cases: a group coffee ordering service on a 2 GB server and technical partner to a PDR company since 2021. From other reviews: when a backend is better off on your own server, zero trust for a 30-person company and how much observability a one-server system needs. Earlier I wrote about a shared GPU pool and the queue for it. If someone is offering you Kubernetes for three containers, tell me what runs today and how many people maintain it. Discuss your task.