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.

Power users figured this out early: speaking a prompt gives you 10x more context in half the time. You include the edge cases, the examples, the tone you want — because talking is fast enough that you don't skip them.

Wispr Flow captures everything you say and turns it into clean, structured text for any AI tool. Speak messy. Get polished input. Paste into ChatGPT, Claude, Cursor, or wherever you work.

89% of messages sent with zero edits. 4x faster than typing. Works system-wide on Mac, Windows, and iPhone.

Start flowing free

Powered by: Jobsurface.com

Browse 659 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Every time you deploy a pod to Kubernetes, something has to decide which node it runs on. That decision happens automatically, and most engineers take it for granted until it starts producing results they did not expect, pods landing on already busy nodes, GPU workloads scheduled onto CPU only machines, or latency sensitive services placed far from the data they need. Understanding how the scheduler makes its decisions is the first step to controlling them.

The scheduler is one of four components that make up the Kubernetes control plane, which runs on the master node. The API Server is the single entry point for all cluster operations, every kubectl command, every controller action, every scheduler decision goes through it. etcd is the distributed key/value store that persists all cluster state. The Controller Manager runs the control loops that keep the cluster in its desired state. if a Deployment says it needs three replicas and only two are running, the Controller Manager notices and creates a third. The Scheduler watches for pods that have been created but not yet assigned to a node, and decides where they should run.

On each worker node, the kubelet is the local agent that talks to the API Server and manages the pods assigned to that node. It is responsible for starting and stopping containers, running health checks, and reporting node and pod status back to the control plane. kube-proxy maintains the network rules that allow pods to reach each other and services to route traffic to the correct pods. The container runtime containerd in most modern clusters does the actual work of pulling images and running container processes.

The scheduler has visibility into the entire cluster through the API Server. It knows which nodes exist, what resources they have available, what pods are already running on them, and what constraints those pods have declared. Every scheduling decision is made using that information.

When a new pod is created, the scheduler picks it up from a queue of unscheduled pods and runs it through a two phase process: filtering and scoring.

Filtering starts by collecting all available nodes in the cluster. The scheduler then runs a set of filter functions against each node. A pod requesting 4 CPU and 8 GB of memory (example set condition) is immediately filtered out of any node that cannot satisfy those requests. But resource availability is just one filter. The scheduler also checks whether the node is marked as unschedulable, whether the pod's required volumes can be bound to that node, whether the pod tolerates any taints the node has applied, whether the pod has a node name or node affinity requirement that restricts placement, and whether inter-pod affinity or anti-affinity rules allow the pod to land on that node given what is already running there.

Each filter function is independent and the pod must pass all of them for a node to remain in contention. A node that has enough CPU but not enough memory fails the resource filter and is out. A node that has the resources but carries a taint the pod cannot tolerate is also out. The feasible set that emerges from filtering can be anywhere from zero nodes which results in the pod staying in Pending state to every node in the cluster.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)