Thursday, August 13, 2026

Kubernetes ports glitch while creating Master & Worker nodes



~$ sudo kubeadm init --pod-network-cidr=192.168.0.0/16

#The above command is used to create LAN based Kubernetes Master Node

 how to stop these services


LISTEN 0      4096            127.0.0.1:10257      0.0.0.0:*    users:(("kube-controller",pid=3421,fd=4))                                                                                      

LISTEN 0      4096            127.0.0.1:10259      0.0.0.0:*    users:(("kube-scheduler",pid=3396,fd=4))                                                                                       

LISTEN 0      4096                    *:6443             *:*    users:(("kube-apiserver",pid=3378,fd=4))                                                                                       

LISTEN 0      4096                    *:10250            *:*    users:(("kubelet",pid=3026,fd=17))    

These processes (kube-apiserver, kube-controller, kube-scheduler, and kubelet) represent the core control plane of a Kubernetes cluster.

How you stop them depends entirely on how Kubernetes was installed on your machine. You should choose the method below that matches your setup.

Method 1: If using kubeadm (Standard Linux Install)

In a standard kubeadm setup, the kubelet acts as the parent service that keeps everything else running. The actual API server, controller, and scheduler run as "static pods" managed by the kubelet. Stopping the kubelet stops all of them.

Run the following commands:

Bash
# 1. Stop the main Kubernetes agent service
sudo systemctl stop kubelet

# 2. Disable it so it doesn't restart on boot (optional)
sudo systemctl disable kubelet
Note: Because the API server, controller, and scheduler run inside containers (Docker or containerd), they might take a few seconds to clean up after the kubelet stops. If they are still listening, you can force-clear the containers:

Bash
sudo crictl rmp -f $(sudo crictl ps -q)
# Or if you use Docker:
docker stop $(docker ps -q -f name=k8s_)

Method 2: If using MiniKube or MicroK8s

If you are running a local development environment, use its native CLI tool to shut it down cleanly.

For Minikube:

Bash
minikube stop
For MicroK8s:

Bash
microk8s stop
For K3s:

Bash
sudo systemctl stop k3s

Method 3: The Nuclear Option (Force Kill)

If this is a broken environment, a test machine, or you just want to immediately release those ports without caring about cluster health, you can stop them using their Process IDs (PIDs) from your console output:

Bash
# Kill them gracefully via PID
sudo kill 3421 3396 3378 3026

# If they don't stop, force kill them
sudo kill -9 3421 3396 3378 3026

How to Verify They Are Gone

To confirm that the ports (6443, 10250, 10257, 10259) are completely free, run the socket statistics command again:

Bash
sudo ss -tulpn | grep -E '10257|10259|6443|10250'
If the command returns absolute silence, the services are successfully stopped.





Other Errors:-
I0813 21:47:32.926550   33540 version.go:260] remote version is much newer: v1.36.3; falling back to: stable-1.35
[init] Using Kubernetes version: v1.35.7
[preflight] Running pre-flight checks
[WARNING Service-kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[preflight] Some fatal errors occurred:
[ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]: /etc/kubernetes/manifests/kube-apiserver.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml]: /etc/kubernetes/manifests/kube-controller-manager.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml]: /etc/kubernetes/manifests/kube-scheduler.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-etcd.yaml]: /etc/kubernetes/manifests/etcd.yaml already exists
[ERROR Port-2379]: Port 2379 is in use
[ERROR Port-2380]: Port 2380 is in use
[ERROR DirAvailable--var-lib-etcd]: /var/lib/etcd is not empty
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
error: error execution phase preflight: preflight checks failed
To see the stack trace of this error execute with --v=5 or higher


[ERROR Port-2379]: Port 2379 is in use

[ERROR Port-2380]: Port 2380 is in use


how to resolve the ports use while creating LAN based Kubernetes Master Node


These errors mean that etcd (Kubernetes' distributed database) is either already running on this machine or a previous installation attempt failed and left the processes hanging. Ports 2379 (client communication) and 2380 (peer-to-peer routing) are strictly reserved for etcd.

Since you are initializing a new master node using kubeadm init, you need to clear these ports so the installer can spin up its own instance of etcd.

Step 1: Nuke Residual Kubernetes State

If you previously attempted to run kubeadm init and it failed, it likely left etcd containers running in the background. Use the built-in reset tool to safely tear them down.

Bash
# Reset the current kubeadm state, stop static pods, and clean up network interfaces
sudo kubeadm reset -f
After running this, check if the ports are clear. If the error still occurs during initialization, proceed to Step 2.

Step 2: Identify and Kill What's Using the Ports

If a native etcd Linux service or stray containers are holding onto the ports, you must stop them manually.

Option A: If it's running as a system systemd service

Sometimes an older or standalone instance of etcd was installed via the OS package manager (apt or yum).

Bash
sudo systemctl stop etcd
sudo systemctl disable etcd  # Prevents it from hijacking the port on next boot

Option B: If it's a stray container

If the kubeadm reset tool missed a hanging container:

Bash
# For containerd (default in modern Kubernetes)
sudo crictl rm -f $(sudo crictl ps -a -q --name etcd)

# For Docker environments
docker rm -f $(docker ps -a -q --filter name=etcd)

Option C: The Force Kill Method

If you just want to immediately release the ports regardless of what application is holding them hostage:

Bash
# Find the Process IDs (PIDs) using the ports and kill them
sudo fuser -k 2379/tcp
sudo fuser -k 2380/tcp

Step 3: Clean up Residual etcd Data

Kubernetes will refuse to initialize if it detects stale data from a previous etcd database run. Delete the old database directory:

Bash
sudo rm -rf /var/lib/etcd/

Step 4: Verify and Retry

Before typing the kubeadm init command again, verify that absolutely nothing is listening on those ports:

Bash
sudo ss -tulpn | grep -E '2379|2380'
If it returns empty, the ports are completely clear. You can now safely kick off your cluster setup:
Bash
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=<YOUR_LAN_IP>




It is important to collect `token-kubernetes-master-node`

sudo kubeadm init --pod-network-cidr=192.168.0.0/16
I0813 22:08:42.259129   35029 version.go:260] remote version is much newer: v1.36.3; falling back to: stable-1.35
[init] Using Kubernetes version: v1.35.7
[preflight] Running pre-flight checks
[WARNING Service-kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [inc kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.29.95]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [inc localhost] and IPs [192.168.29.95 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [inc localhost] and IPs [192.168.29.95 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests"
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 763.648µs
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://192.168.29.95:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-scheduler is healthy after 11.918537ms
[control-plane-check] kube-controller-manager is healthy after 11.581767ms
[control-plane-check] kube-apiserver is healthy after 1.501701595s
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node inc as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node inc as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: o0koxr.yzht29874x22g17d
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Configured RBAC rules to allow the API server kubelet client certificate to access the kubelet API
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.29.95:6443 --token o0koxr.yzht29874x22g17d \
--discovery-token-ca-cert-hash sha256:da2813be604851ddbb5731d346b228d810fe27f66a405873f8e025bc7108b4c3 



Success !






Double Success ! Half of the work got over !