What are Jenkins agents (nodes) and how does distributed builds work?
Learn what Jenkins agents (nodes) are, how the controller distributes builds across executors using labels, and why it scales CI/CD, with interview questions.
Expected Interview Answer
Jenkins agents (nodes) are separate machines or containers that connect to the Jenkins controller and actually run build jobs, letting Jenkins distribute work across many executors instead of running everything on the controller.
The controller schedules jobs, stores configuration, and serves the UI, while agents provide executors that pick up and run the assigned pipeline steps. Agents connect over SSH, an inbound TCP/WebSocket connection, or as ephemeral containers (for example Kubernetes pods), and jobs are routed to them using labels. Distributed builds let you scale out capacity, run jobs on different operating systems or toolchains, and keep the controller lightweight and secure by never building on it.
- Scales build capacity horizontally across many machines
- Runs jobs on the right OS or toolchain via labels
- Keeps the controller lightweight and more secure
- Enables parallel builds with more executors
- Supports ephemeral, on-demand agents (containers, cloud, Kubernetes)
AI Mentor Explanation
The Jenkins controller is like the team captain who sets the field and decides who bowls next, but never bowls every over himself. The agents are the bowlers in the attack, each with a specialty (pace, spin) matched by label to the situation. Distributed builds are the captain rotating overs across many bowlers so no one tires and the workload spreads, keeping the whole innings moving efficiently.
Step-by-Step Explanation
Step 1
Controller schedules the job
The controller decides a job needs to run and looks for a free executor.
Step 2
Match by label
It selects an agent whose labels satisfy the job's node/label requirement.
Step 3
Establish the connection
The agent connects via SSH, inbound TCP/WebSocket, or as an ephemeral container.
Step 4
Execute on an executor
The agent runs the pipeline steps in one of its executor slots and streams logs back.
Step 5
Report and free up
Results return to the controller; the executor (or ephemeral agent) is released for reuse.
What Interviewer Expects
- Controller vs agent responsibilities
- That agents provide executors that run the actual builds
- How labels route jobs to the right agents
- The connection methods: SSH, inbound, ephemeral containers
- Why you avoid building on the controller
Common Mistakes
- Saying the controller runs all the builds itself
- Confusing executors with agents (an agent hosts multiple executors)
- Forgetting labels are how jobs target specific agents
- Ignoring the security reason for not building on the controller
Best Answer (HR Friendly)
“Jenkins agents are extra machines that do the actual build work, while the main Jenkins controller just organizes and assigns the jobs. Spreading builds across many agents lets Jenkins run more work at once, use the right kind of machine for each job, and keep the main server fast and secure.”
Code Example
pipeline {
agent { label 'linux && docker' }
stages {
stage('Test') {
steps { sh 'pytest' }
}
}
}Follow-up Questions
- What is the difference between an agent and an executor?
- How do labels route jobs to specific agents?
- Why is it discouraged to run builds on the controller?
- How do ephemeral Kubernetes agents work in Jenkins?
MCQ Practice
1. What does a Jenkins agent primarily do?
Agents provide executors that run build jobs; the controller schedules and coordinates them.
2. How are jobs routed to a specific agent?
Labels on agents are matched against a job's label requirement to route work.
3. Which is an agent connection method in Jenkins?
Agents connect via SSH, inbound TCP/WebSocket, or as ephemeral containers.
Flash Cards
What is a Jenkins controller? — The machine that schedules jobs, stores config, and serves the UI.
What is a Jenkins agent? — A machine or container that runs build jobs on its executors.
How are jobs targeted to agents? — Through labels matched against the job's node requirement.
Why not build on the controller? — To keep it lightweight and secure; builds belong on agents.