Introduction

If you learned Kubernetes from older guides, you may expect the scheduler on port 10251 and the controller-manager on port 10252. In modern Kubernetes, those ports are usually absent because they were the old insecure HTTP endpoints, and control-plane components now use secure HTTPS ports instead.

What Changed

Historically, these ports were associated with unauthenticated or less secure control-plane endpoints:

• '10251 for kube-scheduler'
• '10252 for kube-controller-manager'

Current Kubernetes documentation lists different defaults for the control plane:

• '10259 for kube-scheduler'
• '10257 for kube-controller-manager'

That change reflects a security hardening move. The old ports were part of the insecure serving path. Modern clusters prefer authenticated and authorized HTTPS endpoints, and many distributions disable the old insecure ports entirely.

Why the Old Ports Disappeared

There are two main reasons.

First, the insecure ports exposed sensitive component endpoints over plain HTTP. Even when bound only to localhost or a control-plane address, they were not a good long-term security model.

Second, Kubernetes standardized around secure serving for health checks, metrics, and administrative endpoints. That means:

• TLS is used,
• authentication can be enforced,
• authorization can be applied,
• operators have a clearer security posture.

So the ports did not vanish randomly. They were replaced as part of the broader removal of insecure serving defaults.

What You See in Real Clusters

In a current cluster, the static pod manifest for the scheduler or controller-manager often includes a secure port similar to this:

1spec:
2  containers:
3    - name: kube-scheduler
4      command:
5        - kube-scheduler
6        - --secure-port=10259

And for the controller manager:

1spec:
2  containers:
3    - name: kube-controller-manager
4      command:
5        - kube-controller-manager
6        - --secure-port=10257

If you search for listeners on 10251 or 10252, you may find nothing at all. That is expected on hardened or newer Kubernetes setups.

Why kubectl get componentstatuses Often Confuses People

A classic symptom is seeing scheduler or controller-manager appear unhealthy because an old workflow tries to query 127.0.0.1:10251 or 127.0.0.1:10252. Those checks reflect older assumptions.

On newer clusters, that usually means the checker is outdated, not that the control plane is broken.

A better approach is to:

• inspect the static pod manifests,
• check the secure ports actually configured,
• use component logs,
• use modern health endpoints exposed on the secure listener.

For example, on a control-plane node you might inspect the manifests like this:

grep -E -- '--secure-port|--port|--bind-address' /etc/kubernetes/manifests/kube-scheduler.yaml
grep -E -- '--secure-port|--port|--bind-address' /etc/kubernetes/manifests/kube-controller-manager.yaml

That gives you the live configuration rather than relying on an older blog post.

Firewall and Monitoring Implications

If you are designing firewall rules, allow the ports your cluster actually uses, not the ones an old tutorial listed. Current Kubernetes documentation shows 10259 and 10257 for these components.

If you scrape metrics or probe health endpoints, update those targets as well. Monitoring systems that still expect the insecure ports will fail with connection-refused errors until their configuration is updated.

Could the Old Ports Still Exist?

Yes, but only in older Kubernetes versions, custom builds, or clusters deliberately configured with insecure serving options. That is the exception now, not the baseline.

So if someone asks "why are 10251 and 10252 not used," the practical answer is: because modern Kubernetes moved the scheduler and controller-manager to secure ports and phased out the insecure ones.

Common Pitfalls

The biggest mistake is copying firewall rules or health checks from outdated Kubernetes installation guides. Those guides often describe insecure ports that are no longer the default in current clusters.

Another issue is assuming that a missing listener on 10251 or 10252 means the component failed to start. In many cases, it simply means the component is serving on 10259 or 10257 instead.

Teams also forget to update Prometheus targets and readiness checks when upgrading older clusters.

Summary

• '10251 and 10252 were historically associated with insecure scheduler and controller-manager endpoints.'
• Modern Kubernetes typically uses secure HTTPS ports 10259 and 10257 instead.
• Missing listeners on 10251 and 10252 are usually normal in newer clusters.
• Old health checks and monitoring configs often need to be updated after upgrades.
• Check the actual component manifests and current Kubernetes port documentation rather than relying on legacy examples.