Blog
Thoughts on engineering, design, and building great products.
CoreDNS: Calling Each Other by Name in the Cluster
Pods can already talk by IP, but a pod's IP changes every time it's reborn, so no one hard-codes them. CoreDNS fills that gap: it runs as a workload right in the cluster, sits behind a Service at exactly the 10.32.0.10 that kubelet has been pointing pods at, and resolves Service names into ClusterIPs. This article deploys CoreDNS by hand — RBAC, ConfigMap, Deployment, Service — then tests a pod resolving both internal and external names.
Wiring Up Pod Networking by Hand: CNI bridge and VPC Routes
The previous theory article laid the groundwork; this one does the assembly. We write the CNI bridge + host-local config for each worker, add routes in the VPC route table so pod-to-pod across nodes works, then watch the two nodes finally flip to Ready. At the end we create two real pods on two different nodes and ping between them — each pod gets an IP from its node's range, and packets cross nodes without NAT.
The Kubernetes Network Model
Before wiring up pod networking in the next article, you need to understand what kind of network model Kubernetes demands: one IP per pod, every pod talking directly with no NAT. This article walks through the model's four foundational requirements, the four kinds of in-cluster communication, why pod-to-pod across nodes is the hard part, the two families of solutions (overlay and native routing), and where CNI fits — laying the groundwork for the hands-on wiring next.
kube-proxy: Turning a ClusterIP Into a Real Destination
A Kubernetes Service is a virtual IP — it isn't bound to any machine. kube-proxy is the component that turns that virtual IP into forwarding rules on each node, so traffic to a ClusterIP lands on a real pod behind it. This article installs kube-proxy in iptables mode on two workers, dissects the NAT chains it generates, then curls a ClusterIP directly to watch it work — all without pod networking yet.
kubelet: Bringing the Workers Into the Cluster
The kubelet is the only process on a worker that talks to the api-server and gives orders to containerd. This article distributes the certificate for each node, writes a KubeletConfiguration pointing at the containerd socket, builds the systemd unit, then watches the two workers register into the cluster — and understands why they show up as NotReady rather than Ready.
Container Runtime and CRI: Installing containerd on the Workers
The kubelet doesn't run containers itself — it delegates that to a container runtime through a standard interface called CRI. This article explains what CRI is, who does what in the kubelet → containerd → runc stack, then installs containerd v2.3 and runc on the two workers, sets the cgroup driver to match the kubelet, and verifies it all with crictl.
HAProxy Consolidates Three API Servers, and Remote kubectl
Three api-servers are running, but clients need to know which one to call. This article stands up HAProxy on lb-0 to consolidate them into a single address in TCP passthrough mode — preserving end-to-end mTLS, then configures kubectl on your laptop to point at the Elastic IP and sets up the RBAC so the api-server can call down to the kubelet.