Skip to main content
Questions Categories Search Providers
Troubleshooting

How to Check if kube-proxy is Running [2026 Guide]

5 min read

How to Check if kube-proxy is Running: A Technical Guide

kube-proxy is a critical network component in every Kubernetes cluster. It manages network rules on each node, allowing network communication to your Pods from network sessions inside or outside of your cluster. If kube-proxy fails, services become unreachable, and applications effectively go offline.

In this comprehensive guide, we will explore multiple methods to verify if kube-proxy is running, ranging from standard kubectl commands to advanced node-level debugging and scraping metrics via Prometheus.

---

Method 1: Using kubectl (The Cluster View)

The most common and recommended way to check the status of kube-proxy is from the control plane using kubectl. This method works regardless of the underlying operating system of the nodes.

1.1 Checking the Pods

By default, kube-proxy runs as a DaemonSet in the kube-system namespace. This ensures one instance runs on every node (typically).

Command:

kubectl get pods -n kube-system | grep kube-proxy

Expected Output:

NAME               READY   STATUS    RESTARTS   AGE

kube-proxy-abc12   1/1     Running   0          12d kube-proxy-def34   1/1     Running   0          12d

Key Indicators:

  • STATUS: Should be Running. ImagePullBackOff or CrashLoopBackOff indicates a failure.
  • READY: Should be 1/1.

    • 1.2 Checking the DaemonSet Status

    Instead of checking individual pods, you can check the DaemonSet controller directly. This gives you a high-level view of how many nodes *should* have the proxy versus how many actually do.

    Command:

    kubectl get ds -n kube-system kube-proxy

    Output Analysis:

    NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE

    kube-proxy   3         3         3       3            3                     40d

  • DESIRED: Number of nodes that should run the pod.
  • READY: Number of pods actually running and ready. If READY < DESIRED, you have a problem.

    • ---

    Method 2: Node-Level Debugging (SSH Access)

    Sometimes kubectl shows the pod as Running, but the internal process is stuck. If you have SSH access to the worker nodes, you can verify the process OS-level details.

    2.1 Identifying the Process Management System

    Kubernetes nodes can run kube-proxy in different ways depending on the distro (e.g., Ubuntu, CentOS, Amazon Linux 2, CoreOS).

    1. As a Static Pod (Managed by Kubelet): Common in managed clusters (EKS, GKE). The pod config is in /etc/kubernetes/manifests/. You won't see a systemd service for it, but you will see the container process. 2. As a Systemd Service: Common in self-managed "bare metal" setups using kubeadm.

    2.2 Checking via Systemd

    If the node uses systemd, use the following command:

    sudo systemctl status kube-proxy

    Look for:

  • Active: active (running)

If it is inactive or failed, restart it with:

sudo systemctl restart kube-proxy

2.3 Checking Running Processes (Universal)

Regardless of the setup, the process must be running in the OS. If kube-proxy is running as a container (Docker or containerd), you won't see a kube-proxy binary process directly; instead, look for the container runtime (runc/crun).

However, if it is running as a native binary or you want to find the Container ID:

Generic process check


ps aux | grep kube-proxy

If you see output like kube-proxy --config=..., the process is alive.

2.4 Checking Ports (iptables/ipvs mode)

kube-proxy manages networking. You can verify if it is working by checking if it has manipulated the local firewall rules.

Check if iptables rules exist (Common in older clusters)


sudo iptables -t nat -L -n | grep KUBE 

Check if IPVS rules exist (Common in newer/high-scale clusters)


sudo ipvsadm -Ln

If these commands return empty results, kube-proxy may not be writing rules, or it might not be running at all.

---

Method 3: Log Analysis

Checking if the process is "Running" isn't enough; you need to ensure it is healthy. Logs reveal sync errors.

Viewing Logs:

kubectl logs -n kube-system  -f

Example


kubectl logs -n kube-system kube-proxy-abc12 -f

Common Healthy Log: "Using node IP" "Starting to serve"

Common Error Log: "Failed to list" "connection refused" (This indicates the proxy cannot reach the API server).

---

Python: Automating the Check

For Site Reliability Engineers (SREs) or developers automating cluster health checks, you can use the official Python client library to programmatically verify if kube-proxy is healthy.

Prerequisites

pip install kubernetes

Python Script

from kubernetes import client, config

from kubernetes.client.rest import ApiException


def check_kube_proxy_status(): # Load kubeconfig (usually located at ~/.kube/config) try: config.load_kube_config() except Exception: print("Error loading kubeconfig. Are you inside the cluster?") return


v1 = client.CoreV1Api() namespace = "kube-system" label_selector = "k8s-app=kube-proxy"


print(f"--- Checking kube-proxy status in namespace '{namespace}' ---")


try: # List pods with the kube-proxy label pods = v1.list_namespaced_pod(namespace, label_selector=label_selector)


if not pods.items: print("[CRITICAL] No kube-proxy pods found.") return


for pod in pods.items: pod_name = pod.metadata.name pod_node = pod.spec.node_name pod_phase = pod.status.phase pod_ip = pod.status.pod_ip


status_icon = "[OK]" if pod_phase == "Running" else "[FAIL]" print(f"{status_icon} Pod: {pod_name} | Node: {pod_node} | Status: {pod_phase} | IP: {pod_ip}")


except ApiException as e: print(f"Exception when calling CoreV1Api->list_namespaced_pod: {e}")


if __name__ == "__main__": check_kube_proxy_status()

Usage: Run this script locally (provided you have kubectl configured). It acts as a custom health check probe, alerting you if any proxy instances are down or not in the "Running" phase.

---

Advanced: Verifying via Metrics Server

If your cluster has the Kubernetes Metrics Server installed (standard in most 2025 clusters), you can check if kube-proxy is actually consuming resources (CPU/Memory). A running process that consumes 0 CPU and 0 Memory might be stuck.

kubectl top pods -n kube-system -l k8s-app=kube-proxy

Output:

NAME               CPU(cores)   MEMORY(bytes)

kube-proxy-abc12   12m          34Mi

*Note: m stands for milliCores. If you see results here, the process is alive and actively handling network traffic processing.*

Comparison: kubectl vs. Node Commands

| Method | Scope | Use Case | Pros | Cons | | :--- | :--- | :--- | :--- | :--- | | kubectl get pods | Cluster | Daily operations | No SSH required; works on managed clusters (EKS/GKE); central view | Doesn't see OS-level crashes if the container runtime lies | | kubectl logs | Cluster | Debugging API errors | Reveals sync loops and authentication failures | Can be spammy; high volume | | SSH / systemctl | Node | Deep debugging | Verifies the actual OS process state | Requires SSH access; tedious for many nodes | | IPTables / IPVS | Node | Network Verify | Confirms rules are actually written | Technical knowledge of networking required |

Conclusion

Checking if kube-proxy is running involves verifying two layers: 1. Control Plane: The DaemonSet controller reports the desired state. 2. Data Plane: The actual process on the node.

Always start with kubectl get ds -n kube-system kube-proxy. If the numbers match (Desired == Ready), your proxy is running. If you experience network issues despite the status being "Running," immediately dive into iptables or the container logs.

Share: