TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Join us for a live session featuring Alexey Bailkov, CTO, as we explore how AI-generated applications are changing Kubernetes optimization and what DevOps and platform leaders can do to keep infrastructure costs under control.
You will learn:
→ Why AI-generated applications often consume more CPU and memory than necessary.
→ Where HPA, Karpenter, and manual rightsizing leave optimization gaps.
→ Practical techniques to continuously optimize resource allocation without impacting application performance.
→ Real-world strategies for optimizing Kubernetes workloads you didn't build.
IN TODAY'S EDITION
🧠 Use Case
How Kubernetes Works Behind the Scenes
👀 Remote Jobs
Supabase is hiring a Release Engineer
Remote Location: Worldwide
CINC Systems is hiring a Principal Release Train Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
numaflow - A Kubernetes native, serverless platform for running scalable and reliable event driven applications, created by the Intuit Argo team.
🧠 USE CASE
How Kubernetes Works Behind the Scenes
Docker packages an application, its framework, and its libraries into a container image. A single Docker daemon runs on a single host operating system, and every container on that host is managed by that one daemon. Scaling out with Docker alone means manually picking a target machine and starting the container there by hand.
Kubernetes Runs Many Hosts
Kubernetes does not replace Docker. Docker, or another container runtime, still starts and stops the actual containers. Kubernetes sits above the runtime and treats every machine as a node in a cluster. A Kubernetes agent runs on each node and takes instructions from a central system, which decides which node runs which container, restarts containers that fail, and reroutes traffic when a node disappears. The daemon per host model becomes a cluster per fleet model. That central system is the control plane, and every node running application workloads is a worker node.
Inside The Control Plane
The control plane is the decision making layer of the cluster. Nothing in Kubernetes happens without passing through it first.
Kubernetes Architecture
The API server is the single entry point into the cluster. Every command from kubectl, every internal component watching for changes, and every controller reads from and writes to it. Nothing talks to etcd or a node directly, and every request is validated against the cluster's rules before it is accepted.
etcd is a distributed key value store holding the complete state of the cluster. Every pod definition, service, secret, and config map lives there as a record written through the API server. If etcd is lost, the cluster loses its memory of what it was supposed to run, which is why it is usually replicated and backed up.
The scheduler watches the API server for pods created but not yet assigned to a node. For each one, it checks available CPU and memory across nodes, along with any affinity rules, taints, and tolerations, and picks the best fit. It does not start the pod itself, it just writes the chosen node back to the API server.
The controller manager runs a set of control loops, one per object type. A deployment controller keeps running pod counts matching the requested replica count. A node controller marks unresponsive nodes unhealthy. Each loop reads current state from the API server, compares it against desired state in etcd, and issues whatever change closes the gap. This reconcile pattern is behind almost everything Kubernetes automates.
Inside The Worker Node
A worker node exists to run application pods, and three components make that possible.
The kubelet is the agent on every node, including the control plane node in most self-managed setups. It watches the API server for pods assigned to its node, and when it sees one, instructs the local container runtime to pull the image and start the containers. It also reports node health and pod status back continuously.
The container runtime actually creates and runs containers, the same job Docker performs on a single host. Kubernetes talks to it through the Container Runtime Interface, which is why containerd or CRI-O can be swapped in without changing anything else.
Kube-proxy handles networking on each node. Services get a stable virtual IP that does not change as pods behind it are replaced. Kube-proxy watches the API server for services and endpoints, and programs iptables rules so traffic sent to a service's virtual IP reaches one of the healthy pod IPs behind it. Larger clusters often switch to IPVS mode for better performance, but the job stays the same.
How A Pod Starts
kubectl sends the pod definition to the API server, which validates it and writes it into etcd.
The scheduler notices the unassigned pod, evaluates node resources, and writes its chosen node back to the API server.
The kubelet on that node sees the new assignment and pulls the image through the container runtime.
The runtime starts the containers, and the kubelet reports status back to the API server.
Kube-proxy updates its iptables rules so traffic can reach the new pod.
No component talks to another directly. Every step is a read or write against the API server, with etcd as the single source of truth, which is what lets Kubernetes survive individual component restarts without losing track of the cluster.
Join us for a live session featuring Alexey Bailkov, CTO, as we explore how AI-generated applications are changing Kubernetes optimization and what DevOps and platform leaders can do to keep infrastructure costs under control.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
