A distributed registry that only ever points to reachable instances

Consul keeps a live map of healthy services

A service registry is only as useful as its honesty. Consul keeps a catalog of registered instances and attaches health checks to them, so a caller asking where a healthy instance of a service lives gets an answer that changes as reality changes. Registration is trivial; the check is the whole product, because a registry that lists dead instances is worse than a static list — it actively routes traffic into a hole. ...

April 6, 2028 · 4 min · XB Field Notes
A listen-on-demand hook that spawns the service on first connect.

Socket activation starts a service only when needed

The port is always ready while the process only starts when someone knocks, a neat trick for rare but heavy services. Every idle daemon costs something: resident memory, periodic wakeups, patch surface, log noise. Multiplied across dozens of seldom-used services on one host, the tax funds nothing. Socket activation inverts the deal — the kernel holds the listening socket, systemd owns it before any daemon exists, and the service process is born only when the first connection arrives carrying real work. ...

February 1, 2028 · 4 min · XB Field Notes
A per-node listening port plus the cluster load-balancer behind it.

NodePort publishes a service on every node's fixed port

A Service of type NodePort does one blunt thing: it reserves a port in the 30000-32767 range and makes every node in the cluster listen on it. kube-proxy programs the same forwarding rule into the iptables or IPVS tables of every machine, so curl <any-node-ip>:<nodePort> reaches the Service no matter which node answers. That is the whole appeal — external reachability with no cloud load balancer, no DNS record and no ingress controller. ...

May 11, 2027 · 5 min · XB Field Notes
A virtual IP plus DNS name that fronts a selection of pods.

A Service gives a pod a stable virtual address

The selector turns the Service from a fixed Endpoint into a live view: refresh happens in the background, and a client never edits its config when pods restart. Declared, then given an address A Service turns the constant churn of pods into a stable name. You declare a selector (which pods), a port, and a protocol, and the control plane assigns a virtual IP (cluster IP) and a DNS name that stay fixed while everything behind them keeps changing. The stable name is the contract for every other resource: a Deployment, an Ingress, or another pod can address a service by name without caring which concrete pod exists right now. That indirection is what lets the runtime rearrange the membership without a client ever noticing. ...

February 9, 2027 · 5 min · XB Field Notes