How to fix port 6443 is in use in Kubernetes

KubernetesBEGINNERMEDIUMUpdated Dec 6, 2025· 233 views

The port 6443 in use error during kubeadm init means another process or container is already binding to the Kubernetes API server port. This typically happens from a previous cluster installation that wasn't fully cleaned up.

Quick fix

Fixes port 6443 is in use

sudo netstat -tulpn | grep 6443
# or
sudo lsof -Pi :6443
  1. Identify what is using port 6443
  2. Clean up from previous cluster installation
  3. Kill blocking process
  4. Ensure container runtime is running
kubernetes — error
sudo netstat -tulpn | grep 6443
# or
sudo lsof -Pi :6443
port 6443 is in use

What this error means

Kubeadm init performs preflight checks and fails if port 6443 (the standard API server port) is already in use by another process. This prevents kubeadm from starting the API server. The port is usually taken by stale containers or processes from a previous Kubernetes installation.

Typical symptoms

  • Error: "[ERROR Port-6443]: Port 6443 is in use" during kubeadm init
  • Appears alongside other port conflicts (10250, 10259, 10257)
  • kubectl commands fail with "connection refused" after initialization
  • Docker shows kube-apiserver containers in CrashLoopBackOff state
  • netstat/lsof shows port 6443 bound to unexpected process

Common causes

  1. Stale processes from previous Kubernetes cluster installation
  2. Previous kubeadm init was not properly cleaned up with kubeadm reset
  3. Load balancer (HAproxy, nginx) binding to port 6443 in HA setup
  4. Docker containers from previous cluster still running
  5. API server startup delay on initial init
  6. Container runtime not running or misconfigured

How to fix "port 6443 is in use"

1Identify what is using port 6443

Check which process has the port:

bash
sudo netstat -tulpn | grep 6443
# or
sudo lsof -Pi :6443

Note the process name and PID. Common blockers:
- Docker container (stale kube-apiserver)
- HAproxy/nginx (load balancer in HA setup)
- Previous kubelet process

2Clean up from previous cluster installation

If from previous cluster:

bash
sudo kubeadm reset -f
sudo rm -rf /etc/kubernetes /var/lib/kubernetes /var/lib/kubelet /etc/cni/net.d ~/.kube
sudo docker rm -f $(docker ps -a -q)  # Remove all containers
sudo iptables -F && sudo iptables -X  # Flush firewall rules

This completely removes all Kubernetes state.

3Kill blocking process

If kubeadm reset didn't free the port:

bash
# From netstat/lsof output, get the PID and kill it:
sudo kill -9 <PID>

# Or force kill all docker containers:
sudo docker rm -f $(docker ps -a -q)

Then verify port is free:

bash
sudo netstat -tulpn | grep 6443
# Should show nothing
4Ensure container runtime is running

Check if Docker/containerd is working:

bash
sudo systemctl status docker
# or
sudo systemctl status containerd

If not running, start it:

bash
sudo systemctl start docker

Test connectivity:

bash
sudo docker ps
sudo ctr containers list  # For containerd
5For HA setups, verify load balancer config

If using HAproxy/nginx for load balancing:

yaml
# HAproxy should forward to API servers, not bind to 6443:
listen api-server
  bind <load-balancer-ip>:443  # NOT 6443
  default_backend api-servers

backend api-servers
  server master1 <master1-ip>:6443 check
  server master2 <master2-ip>:6443 check
  server master3 <master3-ip>:6443 check

Then run:

bash
kubeadm init --control-plane-endpoint=<load-balancer-ip>:443

Note: endpoint port (443) differs from API server port (6443).

6Run kubeadm init with preflight check enabled

Start fresh after cleanup:

bash
sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --control-plane-endpoint=<control-plane-ip>:6443

If still fails with port in use, verify cleanup was complete:

bash
sudo docker ps -a  # Should be empty
sudo systemctl status etcd  # Should not be running
7Wait for API server startup on initial kubeadm init

API server takes 20-30 seconds to become ready. Don't panic if it's initially unreachable:

bash
# Monitor startup:
kubectl get nodes -w

# Or check logs:
sudo journalctl -u kubelet -f
sudo docker logs -f <api-server-container>

Give it 30-60 seconds after kubeadm init completes before testing kubectl commands.

8Verify cri-dockerd is installed (Docker post-1.24)

Docker 1.24+ removed Kubernetes support. Need cri-dockerd adapter:

bash
# Check if installed:
which cri-dockerd

# Install if missing:
wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.6/cri-dockerd-0.2.6.amd64.tgz
tar -xzf cri-dockerd-0.2.6.amd64.tgz
sudo mv cri-dockerd/cri-dockerd /usr/local/bin/

# Then run kubeadm:
kubeadm init --cri-socket /run/cri-dockerd.sock

Without cri-dockerd, kubelet cannot start containers.

9Check entire preflight checklist

Run preflight checks separately:

bash
sudo kubeadm init phase preflight

This shows all issues before trying full init. Fix each one:
- Ports: 6443, 10250, 10251, 10252, 10255, 2379, 2380
- Kernel modules: overlay, br_netfilter
- Swap: must be disabled
- System requirements: RAM, CPU

Advanced notes

Port conflicts are usually from incomplete cleanup of previous installations. kubeadm reset removes most artifacts but sometimes leaves Docker containers or stale processes. For CI/CD environments where kubeadm init runs in containers, ensure privileged mode and proper volume mounts. In HA setups, the load balancer endpoint and API server port are different—the LB forwards external connections on one port to API servers on port 6443. For Docker Desktop, the built-in Kubernetes uses port 6443 too; use different VM or container for custom kubeadm. WSL2 may have port conflicts with Windows host; use network namespace isolation if needed.

Frequently asked questions

What does "port 6443 is in use" mean?
Kubeadm init performs preflight checks and fails if port 6443 (the standard API server port) is already in use by another process. This prevents kubeadm from starting the API server. The port is usually taken by stale containers or processes from a previous Kubernetes installation.
How do I fix "port 6443 is in use"?
The port 6443 in use error during kubeadm init means another process or container is already binding to the Kubernetes API server port. This typically happens from a previous cluster installation that wasn't fully cleaned up.
What causes "port 6443 is in use"?
Stale processes from previous Kubernetes cluster installation Previous kubeadm init was not properly cleaned up with kubeadm reset Load balancer (HAproxy, nginx) binding to port 6443 in HA setup
Is the "port 6443 is in use" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading