Katkat
Back

Scheduling Four Apps at Once on Kubernetes and a Node-Feedback Scheduler Plugin

PinterestSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

A Kubernetes scheduling exercise for a senior infrastructure role: four applications request scheduling at the same time, and the candidate must ask the questions that settle capacity, priority, placement and coordination, then commit to a plan. A second part designs a scheduler plugin that uses signals reported by nodes.

You are in a technical-depth interview for a senior backend infrastructure role on a team that runs its workloads on Kubernetes. After some discussion of Kubernetes scheduling and your day-to-day work, the interviewer poses an open scenario: four applications all request to be scheduled onto the cluster at the same time. You are not given a specification. Instead, you are asked to ask the right questions.

Expect the interviewer to volunteer nothing and to stay noncommittal when you propose constraints. The exercise is to drive it yourself: decide which unknowns actually matter, explain what each answer would change, and still arrive at a defensible plan.

Later in the same interview, the conversation turns to a scheduling problem the team is facing, and one approach that comes up is having nodes feed information back to the scheduler through a scheduler plugin. Part 2 asks you to design that.

Clarifying Questions

  • Is the goal only to surface the right questions, or should you also end with a concrete placement and rollout plan once you have fixed your assumptions?
  • May you change cluster-level configuration (scheduler profiles, priority classes, quotas, node pools), or only the four applications' own manifests?
  • Is the cluster's size fixed for this exercise, or can capacity be added?

Part 1 — Ask the right questions, then commit to a plan

Four applications request scheduling at the same time on one Kubernetes cluster. List the questions you would ask, grouped by the scheduling decision each one drives, and explain how different answers would change what you do. Then pick explicit assumptions for anything left unanswered and describe how you would get all four applications placed and running.

What This Part Should Cover

  • Questions organized by the decision they drive, not as an unordered checklist
  • How the scheduler handles simultaneous requests, and what happens when capacity runs short
  • The mapping from each answer to a concrete Kubernetes mechanism or policy
  • A committed plan under stated assumptions rather than an open-ended list

Part 2 — Feed node-side signals back into scheduling

The team's exact problem is not specified here. Assume it is this: the scheduler places pods using the resource requests the pods declare, but what nodes actually experience (real CPU and memory use, contention, pressure) can differ a lot from those declarations, so some placements turn out badly. Design a mechanism in which nodes report signals back to the scheduler and a scheduler plugin uses them. Cover which signals are reported, how they reach the scheduler, where the plugin hooks into scheduling, and how you make it safe to roll out.

What This Part Should Cover

  • The choice of signals and how they are collected and published
  • Where in the scheduling cycle the plugin acts, and whether it filters, scores, or both
  • Staleness, burst behavior, and fallback when node data is missing
  • A safe rollout and a way to measure whether placements improved

Hints

Hint 1

Make every question pay for itself: For each question, name the scheduling decision that changes with the answer. A question whose answer changes nothing is noise.

Hint 2

Take "at the same time" literally: Think about how the scheduler actually consumes four simultaneous requests, and what goes wrong if not everything fits.

Hint 3

Keep the hot path local: Think about what the scheduler can afford to do for every candidate node of every pod, and where the node data should already be by then.

Hint 4

Metrics lag behind decisions: Consider what happens when many pods are scheduled in a burst and every one of them sees the same lightly loaded node.

Follow-up questions

  • Two of the four applications are batch jobs whose workers are useless unless all of them start. What goes wrong with the default scheduler, and what would you add?
  • After your plugin ships, pods that were placed well at admission drift into hot spots as load changes. Does the scheduler fix that, and if not, what does?
  • The node-reporting agent crashes on a fifth of the nodes. How should the plugin behave, and how would you notice?
  • How would you show, before a cluster-wide rollout, that the plugin improves placements rather than just moving problems elsewhere?