Every time you deploy an application to Kubernetes, something happens at port 10250 that most people never think about. The control plane—distant, orchestrating, perfect in its intentions—needs to actually talk to the machine where your code runs. It needs to know: is the container alive? Can I execute a command in it? What are its logs? Who is running inside? That conversation happens here, on port 10250, where the kubelet listens.
The kubelet is the node agent. It's the bridge between abstraction and reality. While the Kubernetes API server sits in the control plane thinking in terms of pods and deployments and desired states, the kubelet stands on each worker node, boots in hand, and actually makes things happen. It talks to the container runtime. It starts containers. It watches them live and die. And on port 10250, it exposes a REST API so that the control plane—and anyone else with network access—can ask it questions and give it orders. 1
The Problem It Solves: From Borg to Kubernetes
To understand port 10250, you have to understand why Kubernetes exists.
Google ran container workloads at scale for fifteen years before anyone outside the company knew what a container was. Their internal system was called Borg, and it managed hundreds of thousands of jobs across massive clusters of machines. Borg worked. It had to—it was running the entire Google infrastructure. But it was enormous, tightly coupled to Google's specific hardware and requirements, and completely closed to the world. 2
In 2014, three Google engineers—Joe Beda, Brendan Burns, and Craig McLuckie—looked at what Borg had learned them and asked a different question: What if we rebuilt this for the world? What if we made it open, modular, container-native? What if we kept the intelligence of orchestration but stripped away the monolith? 3
Kubernetes was the answer. And it inherited Borg's DNA: the concept of pods (groups of containers that work together), the idea of declarative state (you describe what you want, the system makes it happen), the principle of self-healing (if something dies, restart it automatically). But for Kubernetes to work at all, it needed a way for the control plane to communicate with the nodes. It needed a node agent—a piece of software on every machine that could receive instructions and report back on what's actually happening.
That agent is the kubelet. And port 10250 is its voice.
How It Works: The REST API at the Boundary
The kubelet listens on port 10250 with a REST API. The architecture is deceptively simple: HTTP. Standard HTTP. No special protocol. Just endpoints that you can call.
The /pods endpoint returns the list of pods running on the node—a window into what the kubelet is actually managing. 4
The /exec endpoint is where things get intimate. If you want to run a command inside a container—to debug it, to inspect it, to understand what's happening in there—you POST to /exec, and the kubelet opens a bidirectional stream (via SPDY or WebSocket) and connects your stdin, stdout, and stderr directly to the container. You're typing. The container is responding. The kubelet is the medium. 4
The /logs endpoint streams the container's logs back to you. Every print statement, every error, every debug message that the application inside wrote to stdout—the kubelet fetches it and sends it over the network.
The /metrics endpoint exposes raw performance data: how much CPU is the container using? How much memory? What about disk I/O? The kubelet has been watching, and here it tells you everything.
There are no protocols here, no proprietary compression, no custom handshakes. Just HTTP methods and JSON responses. The kubelet is not trying to hide. It is trying to be transparent—to expose the reality of what's running on this machine in the clearest possible way. 4
The Security Crisis That Never Went Away
Here is the genuine strangeness of port 10250: it is open by default.
Unless you explicitly configure it otherwise, the kubelet accepts every request. No authentication required. No bearer token. No client certificate. By default, requests that come to port 10250 are given the username system:anonymous and the group system:unauthenticated. The assumption was that this port would never be exposed to the public Internet. It would live inside a private network, behind a firewall, accessible only to the control plane and internal monitoring tools.
But assumptions are not firewalls.
Researchers have found hundreds of kubelet APIs sitting on the open Internet, accessible to anyone. And when they're accessible to anyone, what do you think happens? Attackers execute arbitrary code inside your containers. They read your environment variables (where your API keys and database passwords are usually stored). They install cryptominers. They exfiltrate data. They pivot from the compromised node to other parts of your infrastructure. 5
The vulnerability is not in the protocol. The vulnerability is in the trust boundary. The kubelet is honest—perhaps too honest. It tells you everything if you ask. The problem is that the people deploying Kubernetes often don't ask: Should I be telling this to everyone? 5
Google Cloud's answer was to disable the read-only port (10255) entirely in their managed Kubernetes service. Amazon and Azure implemented network policies that restrict access to port 10250 to only authorized sources. But countless self-managed Kubernetes clusters sit with port 10250 wide open, broadcasting their pod manifests and logs to the Internet, waiting for someone to ask for a shell. 1
What Actually Flows Through This Port
Every command you type into a Kubernetes pod goes through port 10250. When you run:
What actually happens: your kubectl command talks to the API server, the API server finds the kubelet running on the node where the pod is scheduled, the API server tells the kubelet "open a shell to stdin/stdout/stderr inside this container," the kubelet connects to the container runtime, and a WebSocket stream opens back to your terminal. Every keystroke you type travels from your machine to the API server to the kubelet to the container runtime and back again. It's a tunnel, and port 10250 is the gateway.
When you stream logs:
Same thing. The kubelet reads from the container runtime's log file, streams it back as HTTP response bodies, and your terminal sees the lines in real time.
When an orchestration system needs to make a decision—"Is this pod healthy? Should I restart it? Can I move it to another node?"—it queries the kubelet on port 10250. The kubelet responds with resource usage, container status, health check results. The entire feedback loop of Kubernetes runs on these REST calls. 4
This is the bloodstream of the Internet's distributed nervous system. Every containerized application in production—and there are billions of them—has a kubelet watching over it, waiting on port 10250 to be asked questions.
Related Ports: The Kubelet's Neighbors
Port 10248 — The health check port. This listens only on localhost and requires no authentication. It's there so monitoring systems can ask "is the kubelet alive?" without needing credentials. Simpler, safer, isolated. 1
Port 10255 — The read-only kubelet API. This used to mirror most of the endpoints from port 10250, but marked read-only. It was originally intended as a safer alternative, but Google found it so dangerous that they deprecated it entirely in newer Kubernetes versions. Now it's mostly gone. 1
Port 10250 — The read-write port. This is the full power. Execution, logs, metrics, pod information, everything. The boundary where abstraction meets reality.
Port 6443 — The Kubernetes API server. The orchestrator, the brain. Port 10250 is where the API server talks to the nodes; port 6443 is where everything else talks to the API server.
Port 2379, 2380 — etcd, the distributed database where Kubernetes stores all cluster state. The control plane reads from etcd and tells the kubelets what to do; the kubelets report back to the API server which writes to etcd. A loop.
FAQ: Questions People Actually Search For
Q: Is port 10250 dangerous?
A: Port 10250 itself is not dangerous. But unrestricted access to port 10250 is catastrophic. If an attacker can reach this port, they can execute arbitrary code inside your containers, read your secrets, and compromise your entire cluster. You should assume port 10250 should never be exposed to the Internet or untrusted networks. Firewall it. Restrict it to only the control plane and authorized monitoring systems. 5
Q: How do I secure port 10250?
A: Start by disabling anonymous authentication on the kubelet with --anonymous-auth=false. Configure certificate-based authentication so only the API server (and tools with valid client certificates) can access it. Network firewall the port so it's only reachable from trusted sources. And assume that if you can't control the network, you need encryption and authentication. 1
Q: What do people use port 10250 for?
A: The Kubernetes control plane uses it to execute commands, fetch logs, and monitor pod status. Monitoring systems use it to scrape metrics. Debugging tools use it for interactive shell access into containers. Kubelet itself uses it for intra-cluster communication. The entire orchestration system depends on these REST calls. 4
Q: What if I don't want to expose any kubelet API?
A: You can disable it with --port=0, but you'll break cluster functionality. The API server needs to talk to kubelets to do its job. Instead, secure it rather than hiding it. Use mutual TLS authentication, network policies, and firewall rules to ensure only authorized clients can reach it. 1
Q: Is the kubelet API documented?
A: Barely. The Kubernetes project's own documentation on kubelet API usage is notoriously sparse. Most people learn it by reading the source code or through painful trial and error. This is one of the darker corners of Kubernetes—powerful and dangerous, but not well explained. 4
The Port That Sees Everything
Port 10250 is where the invisible becomes visible. Inside the control plane, everything is abstraction: pods, deployments, services, replicas. But the kubelet sees the truth. It sees the actual processes running. It sees the memory being consumed. It sees the logs being written. It sees the containers living and dying.
And on port 10250, it tells you.
For years, this was fine. Kubernetes clusters ran inside private networks where port 10250 was implicit trust—the control plane talking to the nodes it created, monitoring systems checking health, everything inside the boundary. But the boundary dissolved. Kubernetes moved to the cloud. Networks became flatter. Security perimeters became complicated.
Now port 10250 sits on the boundary between what should be secret and what is broadcast. The kubelet doesn't know the difference. It just answers the questions. It's honest to a fault.
That honesty is its power. And its danger.
Trang này có hữu ích không?