DEV Community: Demuxer

Right-size Kubernetes CPU and memory requests from 7 days of Prometheus

Demuxer — Tue, 10 Nov 2026 20:07:11 +0000

Most CPU and memory requests are set once, by a guess, and never looked at again. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows how it compares each container's requests with what it used over the last seven days.

The problem

A request reserves CPU and memory on a node whether the container uses it or not. To check one, you query Prometheus by hand, something like a percentile of the CPU rate and the peak of the memory working set per pod, write the numbers down, open the manifest, compare, and edit the YAML. Doing that for every workload in a cluster takes an afternoon, so it rarely gets done.

How Kuberniq does it

In the Analysis tool window, choose Recommendations.
Under Information, "The container requests more than it uses" lists the workloads. Select recommendations/feature-store.
The detail says that the container requests more than it uses, with 390m of CPU left over across its 3 replicas, and a table of current and recommended values: CPU request 490m to 360m, memory request 2.6 GiB to 2.6 GiB, memory limit 4 GiB to 2.9 GiB. The table says where the numbers come from, "7 days of Prometheus at monitoring/prometheus", and how: CPU at the 95th percentile of the average per pod, memory at the peak per pod. That's the screenshot.
Apply Recommendation… opens "Compare Deployment feature-store", with the 2 changes between In the cluster and After applying.
Apply sends them, and Kuberniq confirms with "Recommendation applied to feature-store."

What it doesn't do yet

The recommendation covers the CPU request, the memory request and the memory limit. It doesn't set a CPU limit and doesn't change an autoscaler. It needs history to work from, and it changes the object in the cluster, not the manifest in your repository, so a Helm chart or a GitOps sync will put the old values back until you change them there too. There's also no Linux build; it runs on macOS and Windows.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you size requests by hand today, we'd like to know whether the 95th percentile and the peak are the numbers you'd pick.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Frightsizing

Edit Kubernetes YAML against the cluster's own schema, and see the diff before you apply

Demuxer — Tue, 10 Nov 2026 20:00:54 +0000

Changing a manifest in a live cluster is quick to do and easy to get wrong. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows its YAML editor, which checks each field against the schema the cluster serves and shows the diff before anything is sent.

The problem

kubectl edit deployment web opens the manifest in your terminal editor, with no idea of what each field accepts. Type replicas: "three" and you only find out when you save and the API server refuses it. Once the edit goes through, you don't get a view of what changed against what was in the cluster unless you keep a copy and run kubectl diff on it.

How Kuberniq does it

Open Deployments and click web. The manifest opens in an editor tab, with Compare… and Apply at the top.
On line 15, change replicas: 2 to replicas: "three". Kuberniq marks the value as you type, and hovering it shows spec.replicas, its type, integer, and the documentation the cluster serves for it: "Number of desired pods…"
Change it to replicas: 3 and the marker goes away.
Compare… opens "Compare Deployment web", with In the cluster on the left and After applying on the right, and 1 change: replicas: 2 becomes replicas: 3. That's the screenshot.
Apply sends the change, and Kuberniq confirms with "Deployment web applied".

What it doesn't do yet

Kuberniq edits the object in the cluster, not the file in your Git repository. If the Deployment comes from Helm, Kustomize or a GitOps tool, the next sync puts back what the repository says, so make the same change there. There's also no Linux build; it runs on macOS and Windows.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you edit manifests in the cluster, we'd like to know what you'd want the editor to check that it doesn't yet.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Fyaml-editor

From a failed Kubernetes pod to its log and a shell, in one window

Demuxer — Tue, 10 Nov 2026 19:54:33 +0000

A pod fails, and the next ten minutes go to finding out why. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows how it takes you from the failure to the log and to a shell in a container.

The problem

In a terminal, you find the pod with kubectl get pods -n shop, copy its name with the random suffix, run kubectl logs worker-6c8d9b7f4-qz8mt --previous to see why the last run ended, and then kubectl exec -it api-7d9f8c6b5d-m4h7c -c api -- sh to look from inside a neighbour pod. Every step needs the exact name of a pod that may already have been replaced.

How Kuberniq does it

When a pod fails, Kuberniq shows a notification. In our demo cluster it reads "The pod worker-6c8d9b7f4-qz8mt failed", with a View log button.
View log opens the Logs tool window on that pod. The screenshot shows worker-6c8d9b7f4-qz8mt in CrashLoopBackOff, and its log: three attempts to reach rabbitmq.shop.svc.cluster.local, then level=fatal msg="cannot consume the queue without a broker". The toolbar follows the end of the log, wraps long lines, shows timestamps and downloads the log.
To look from inside another pod, open Pods, type api- in the filter, right-click api-7d9f8c6b5d-m4h7c and choose Open Terminal. The Terminal tool window opens a shell in the container api, at /app #.

The Pods table also shows the CPU and memory of each pod and how they compare with its requests and limits, so a pod near its memory limit stands out before you open anything.

What it doesn't do yet

Kuberniq shows the log the cluster still keeps for the container. When the pod is deleted, its log goes with it, and Kuberniq doesn't store logs anywhere of its own or search across them over time. There's also no Linux build; it runs on macOS and Windows.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you debug pods from the terminal today, we'd like to know which step you'd still do there after trying Kuberniq.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Flogs-terminal

Find what's broken across every namespace of a Kubernetes cluster

Demuxer — Tue, 10 Nov 2026 19:48:14 +0000

When a service misbehaves, the first question is where in the cluster the problem is. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows its analysis, which answers that question for the whole cluster at once.

The problem

Without a tool, the search is a round of commands. You run kubectl get pods -A and scan for anything that isn't Running, kubectl describe pod on each suspect to read its events, kubectl get nodes to see whether a node dropped out, and then you look up what ImagePullBackOff or OOMKilled means in that case and what to do about it. On a cluster with a couple of hundred pods spread over dozens of namespaces, the one canary that can't pull its image is easy to miss.

How Kuberniq does it

Open the cluster and set the namespace dropdown to All namespaces.
Open Overview and pick a range: 1 h, 6 h, 24 h or 7 d. The summary shows nodes ready, pods running, pending and failed, CPU and memory requested against allocatable and used, and restarts, with charts of CPU and memory from the cluster's Prometheus. In the screenshot, 13 of 14 nodes are ready, 242 pods are running and 3 have failed.
The Analysis tool window at the bottom groups the findings into Errors, Warnings and Information, and the tabs narrow them to Failures, Reliability or Recommendations.
Select a finding to read it. In the screenshot, under Errors (6), "The image cannot be pulled" points at search/search-api-canary-rrql5bqvl-mmlmx. The detail says that the container cannot pull ghcr.io/shop/search-api:2.15.0-rc.1, then Why: "the name or the tag does not exist, the registry asks for a credential the pod does not have, or the registry does not answer", and What to do: "Check the name and the tag of the image and, for a private registry, the imagePullSecrets of the pod."

The same list has a node that is not ready, a container that restarts in a loop and a container that went past its memory limit, each with its own Why and What to do.

What it doesn't do yet

The analysis says what to do, and you make the fix yourself; the exception is the CPU and memory recommendations, which you apply through a diff. It reads the cluster when you open it and when you analyze again, so it doesn't watch the cluster while Kuberniq is closed and doesn't send alerts to chat or to a pager. The rules are the ones Kuberniq ships with, and you can't write your own.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you try the analysis on one of your clusters, we'd like to know which finding it missed and which one you'd rather not see.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Fanalysis

Open every cluster in your kubeconfig, with no account

Demuxer — Tue, 10 Nov 2026 19:47:24 +0000

Most people who run Kubernetes keep several clusters in one kubeconfig: production, staging, one on the laptop, sometimes one per region or per customer. At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this article shows how it opens those clusters.

The problem

In a terminal, moving between clusters means changing the current context. You run kubectl config get-contexts to see the names, kubectl config use-context shop-prod to pick one, and from then on every command in every shell goes to that cluster until someone changes it again. kubectx makes the switch shorter, but the current context is still one setting that all your terminals share. Some desktop clients add a step of their own before you see anything, such as signing in to an account with them.

How Kuberniq does it

Kuberniq reads the same kubeconfig as kubectl, from KUBECONFIG or ~/.kube/config, and asks for no account.

The welcome screen lists every context in the file, each with its cluster and the address of its API server. In our demo, shop-prod is an EKS context, shown with its ARN and its eks.amazonaws.com endpoint. With many contexts, Search clusters narrows the list, and Reload reads the file again after you change it.
Select the context and click Open.
A window opens on that cluster. On the left, the Resources tree groups the kinds into Workloads, Network, Configuration, Storage, Access control, Cluster and Custom resources, with a count next to each kind. At the top, the namespace dropdown picks one namespace or All namespaces, and the status bar shows the version the cluster reports, here Kubernetes v1.33.1-eks-7b0f2a1.
Pick All namespaces and every table covers the whole cluster. The screenshot shows shop-prod that way: 246 pods and 49 Deployments, listed with their namespace, ready replicas and age.

The credentials stay where they are: Kuberniq reads them from the kubeconfig and doesn't copy them to an account or a service of ours.

What it doesn't do yet

Kuberniq doesn't discover clusters on its own. If a cluster isn't in your kubeconfig, or kubectl can't reach it from there, it won't show up in Kuberniq either. There's also no Linux build; it runs on macOS and Windows.

Try it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. If you keep many contexts in one kubeconfig, we'd like to hear how you move between them today and where Kuberniq gets in the way.

Download Kuberniq from its page: https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to%2Fkubeconfig

Lens and Headlamp didn't fit how we debug Kubernetes, so we built a desktop client

Demuxer — Tue, 10 Nov 2026 18:57:21 +0000

At Demuxer we build Kuberniq, a desktop Kubernetes client for macOS and Windows, and this post is about why we wrote it when Lens and Headlamp already exist.

What we didn't like

This is our opinion, as a team that used both. Lens was our client for a long time, and we tried Headlamp when it shipped a desktop app. Both list resources, show logs and open a shell well, and many people are happy with them. Our problem was usability, for the one thing we do most.

A pod fails. In either app we'd find it, and then our hands went back to the terminal anyway: kubectl describe pod for the events, kubectl logs --previous for the run that died, kubectl edit deployment to fix it. If a field had the wrong type, we learned it when the API server refused the save. On top of that, Lens asks for a Lens ID to register the app, and we wanted to open the kubeconfig we already had and nothing else.

What Kuberniq does instead

It reads ~/.kube/config and KUBECONFIG without an account and without copying credentials, and each context opens as a window on that cluster.

The analysis goes over every namespace and lists findings such as a container restarting in a loop, a container killed for going past its memory limit, an image that cannot be pulled, or a node that is not ready. Each finding says what was seen, why it happens and what to do.

The YAML editor validates against the OpenAPI schema the cluster serves. Write replicas: "three" and it is marked as you type, next to the documentation of spec.replicas. Before anything reaches the cluster, Compare shows the diff between what's there and what you're about to apply.

The recommendations compare each container's requests with 7 days of Prometheus: CPU at the 95th percentile of the average per pod, memory at the peak per pod. Applying one goes through the same diff.

There's also logs per pod or per workload, a terminal, scale, restart, rollback to a revision, a timeline and a topology.

Getting it

The free license covers personal projects, study, teaching and open source, with the whole app and no account. There's no Linux build, which both Lens and Headlamp have.

If you use Lens or Headlamp, we'd like to know which part of their usability works for you and which part sends you back to kubectl.

https://demuxer.dev/kuberniq?utm_source=devto&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=dev-to