Build1 distinct publisher3 min readPublished
A Node reimplementation of the Kubernetes API found that kubectl v1.34.1 negotiates discovery first and then asks the server for a pre-rendered table, which puts most of the compatibility work in headers rather than in resource schemas.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The ordering is what decides whether the rest of your server ever executes. kubectl will not guess at what a server supports, so it asks GET /api and GET /apis first, requesting aggregated discovery from apidiscovery.k8s.io and falling back to plain application/json if that is not offered [4]. Against a server that 404s, the author's capture shows five attempts to each endpoint and then a clean give-up [5]. That is ten requests, none of them for a pod [6]. The PodList handler you are proudest of is dead code until two near-empty documents exist [7].
Then the content type. Once discovery succeeds, `kubectl get pods` sends Accept: application/json;as=Table;v=v1;g=meta.k8s.io before it will accept plain JSON [8]. The server answers with column definitions and rows of already-rendered cells, and the client prints them nearly verbatim, which means the NAME READY STATUS RESTARTS AGE line is a string the API server picked [9]. Sixty lines of Node that answer the three discovery paths and return a one-row Table are enough to make a real kubectl print NAME and demo-pod [10]. A control plane with no concept of a pod can still display one convincingly, which is worth knowing before you treat kubectl output as evidence.
The author calls the design genuinely good, and the reason holds up: display logic lives on the server, so `kubectl get` renders resource types the binary has never heard of, including CRDs that shipped after it was built [11]. The bill goes to whoever writes the server. Around 55 kinds in that repo each need their own table() with their own columns, and every column carries a type, a format, a priority and a description [12]. Pods alone define five columns, so twenty metadata values for one kind's list view [15]. Streaming adds a state requirement: column definitions belong on the first watch event only, because repeating them on each update makes the client re-print headers [13].
What would have to be true for these captures to transfer. They were taken against kubectl v1.34.1 [3], so the five retries and the exact Accept lists are properties of one client build, not constants of the protocol. What generalises is the shape: discovery is negotiated, list output is negotiated, and both happen before any resource logic runs. The demonstration also covers `kubectl get pods` and nothing else [14]. Treat the sixty-line stub as a proof about one verb.
The repo itself is a Node reimplementation of the core APIs on MongoDB instead of etcd, running pods as sibling Docker containers [1]. Its author's own read on why strangers finally looked is that the README made a claim you can falsify in one command, while his earlier repos led with how they were built and went unread [2].
Ranked by verification strength, evidence, and original report placement.
The repo Megapixel99/nodejs-k8s reimplements Kubernetes core APIs in Node (pods, deployments, replica sets, services, jobs, namespaces, configmaps and others), backed by MongoDB instead of etcd, and runs "pods" as sibling Docker containers.
All of the author's header captures were made against kubectl v1.34.1.
Before fetching a single pod, kubectl sends GET /api?timeout=32s and GET /apis?timeout=32s with an Accept header requesting application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList and the v2beta1 variant, falling back to plain application/json if the server does not offer aggregated discovery.
Pointed at a server that returns 404, kubectl hit /api and /apis five times each in the author's capture and then gave up without ever requesting a pod.
The author says discovery is the thing to implement first, that a flawless PodList handler will never be reached because the client refuses to guess what the server supports, and that two endpoints returning almost-empty JSON are the difference between nothing working and everything working.
After discovery succeeds, kubectl get pods requests GET /api/v1/namespaces/default/pods with Accept: application/json;as=Table;v=v1;g=meta.k8s.io, then the v1beta1 table variant, then plain application/json.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
A dependency check in the liveness probe turns one outage into two1 distinct publisher
build
912MB to 108MB is mostly typing now, and that weakens the base-image excuse in review1 distinct publisher
build
Your meter now runs on someone else's machine: signed receipts, fsync, and failing open1 distinct publisher
build
Exit code 137 is the kernel collecting on a bet you did not know it placed1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One terminal, but cheap to check
Everything traces to a single developer's captures, which would normally cap this much lower. It doesn't, because the central assertions are the cheapest kind to falsify: sixty printed lines of Node, one kubeconfig, one command, and the claimed output either appears or it doesn't. The soft spot is scope rather than sourcing — the captures are pinned to kubectl v1.34.1 and nobody in this reporting has re-run them anywhere else.
No usage numbers of any kind
We know the repository exists and that its author believes strangers read it. We do not know how many, whether anyone runs it, forks it, depends on it, or has pointed a controller at it. A demo that satisfies kubectl on the author's machine tells us the protocol work lands; it says nothing about uptake, and this reporting offers no substitute figure.
One verb behind a broad promise
"Fool kubectl" is doing slightly more work than the demonstration. Listing pods works end to end; describe, apply, logs and exec are never put in front of the same server, and the client-go path that operators and controllers actually use is left half-described. Against that, the protocol findings themselves are if anything undersold — that the header row is a server-chosen string is a bigger fact than the post's shrug about it suggests. Net: a small overreach in framing, not in substance.
Self-promotion, left in plain sight
The author is his own subject: the post advertises his repository, and he says outright that a falsifiable README promise is what got the project read — an admission that publishing what works pays. That pull shows in the shape of the piece, which ends on the parts that work and trails off in the protobuf section that presumably doesn't yet. Disclosed pressure is easier to price than hidden pressure, and there is no sponsor, vendor or funding interest anywhere in it.
Firm on mechanics, thin on reach
Take the handshake and the table at close to face value: they are internally consistent, backed by quoted headers, and reproducible in a minute. Hold the surroundings loosely. Whether all ~55 kinds really round-trip in the repo, whether the watch header trick behaves as described under load, and whether any of this survives a different kubectl build are all things we are taking on one person's word.