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

1. In the Analysis tool window, choose Recommendations.
2. Under Information, "The container requests more than it uses" lists the workloads. Select recommendations/feature-store.
3. 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.
4. Apply Recommendation… opens "Compare Deployment feature-store", with the 2 changes between In the cluster and After applying.
5. 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=hashnode&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=hashnode%2Frightsizing

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

1. Open Deployments and click web. The manifest opens in an editor tab, with Compare… and Apply at the top.
2. 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…"
3. Change it to replicas: 3 and the marker goes away.
4. 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.
5. 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=hashnode&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=hashnode%2Fyaml-editor

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

1. 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.
2. 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.
3. 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=hashnode&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=hashnode%2Flogs-terminal

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

1. Open the cluster and set the namespace dropdown to All namespaces.
2. 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.
3. 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.
4. 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=hashnode&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=hashnode%2Fanalysis

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.

1. 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.
2. Select the context and click Open.
3. 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.
4. 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=hashnode&utm_medium=organic&utm_campaign=kuberniq-desktop&utm_content=hashnode%2Fkubeconfig