How to Monitor Kindnet with Vigilmon (HTTP + TCP + Alerts)

Kindnet is the default CNI plugin shipped with kind (Kubernetes IN Docker) clusters. It provides a simple, lightweight overlay network using VXLAN or host-gateway routing, assigning each node a pod CIDR from the cluster's broader pod network and installing per-node routes so pods on different nodes can reach each other. Kind clusters are used heavily for local development, CI/CD pipelines, and integration testing — environments where network reliability is often assumed but rarely verified. When Kindnet is working correctly, pod-to-pod traffic routes transparently across nodes and services resolve as expected. When Kindnet fails — because a route is missing, a node restarts without re-initialising the CNI, or an IP address conflict arises from rapid cluster churn — pods lose connectivity silently while Kubernetes reports all workloads as healthy. Vigilmon provides the external perspective that Kindnet cannot give itself: continuous uptime and latency checks from outside your infrastructure that catch networking failures before your CI pipeline, integration tests, or local developer environment produces confusing, hard-to-diagnose errors. You can add your first monitor for free, no credit card required.

Why Kindnet needs external monitoring

Node restart clears pod routes without triggering a Kubernetes event. Kindnet installs per-node routing rules that tell each node how to reach pods on every other node. When a kind node container restarts — a common event in Docker-based environments due to memory pressure, daemon restarts, or CI runner cleanup — the routing table is cleared and Kindnet must re-converge. During this window, inter-node pod traffic is silently dropped. Kubernetes does not generate a node condition for missing CNI routes, and readiness probes that run within the same node always pass. An external HTTP monitor probing a pod service endpoint detects this inter-node connectivity gap.
IP address exhaustion from rapid pod churn leaves new pods unschedulable with no visible error. Kind clusters used in CI pipelines create and destroy pods at high frequency. If pod IP allocations are not properly released — due to a Kindnet IPAM bug, a stale lease file, or a hard node kill — the per-node CIDR fills up and new pods remain in Pending state with a cryptic failedScheduling event. The service endpoint count drops below expected, but active connections to surviving pods continue to succeed, masking the capacity degradation. An external HTTP monitor with a response time baseline catches the increased latency that results when fewer healthy pods serve the same request load.
Host-gateway mode breaks when Docker bridge network topology changes. Kindnet can run in host-gateway mode, where it installs direct routes via each node's Docker bridge IP instead of using VXLAN encapsulation. If the Docker network is recreated — after a docker network prune, a Docker daemon restart, or a Docker Desktop update — the bridge IPs change but the stale routes in Kindnet's routing table still point to the old IPs. Pod traffic is silently blackholed until Kindnet re-reconciles, which requires a controller restart. An external HTTP monitor detects this blackhole because requests to service endpoints stop returning responses.
VXLAN encapsulation failures after kernel update silently drop overlay traffic. In VXLAN mode, Kindnet creates a VXLAN tunnel interface (kindnet-vxlan) and forwards all inter-node pod traffic through it. After a Linux kernel update on the host running Docker, VXLAN socket behaviour or UDP port binding can change in ways that cause the VXLAN interface to stop forwarding packets without returning any error. The interface remains UP in ip link show, Kindnet logs no error, and Kubernetes continues routing traffic to the VXLAN interface — which silently discards it. An external HTTP monitor targeting a cross-node pod service endpoint is the only signal that detects this class of failure.
Kindnet DaemonSet pod crash leaves a node without CNI, breaking all new pod scheduling on that node. Kindnet runs as a DaemonSet pod on each kind node. If the Kindnet pod on a node crashes and enters CrashLoopBackOff — due to a misconfigured ConfigMap, an incompatible binary for the host kernel, or an OOM kill — all new pods scheduled on that node fail to get a network interface and stay in ContainerCreating. Existing pods on that node retain their interfaces, so service traffic still flows through those pods and no immediate outage is visible. An external HTTP monitor with a pod distribution expectation catches the gradual capacity erosion as existing healthy pods on that node are eventually rescheduled elsewhere.

What you'll need

A running kind cluster with Kindnet as the CNI and at least one service accessible from outside the cluster
The public hostname or IP for a Kindnet-networked service endpoint, for example http://kindnet-service.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Kindnet workload health endpoints

Verify Kindnet is running and that a service endpoint is reachable before configuring Vigilmon monitors.

# Check Kindnet DaemonSet is running on all nodes
kubectl get daemonset -n kube-system kindnet
# Expected:
# NAME      DESIRED   CURRENT   READY   ...
# kindnet   2         2         2       ...

# Check Kindnet pods are healthy on every node
kubectl get pods -n kube-system -l app=kindnet -o wide

# Verify pod-to-pod routing works across nodes
# Get the IP of a pod on node-1
POD1_IP=$(kubectl get pod <pod-on-node-1> -o jsonpath='{.status.podIP}')
# Ping it from a pod on node-2
kubectl exec -n <namespace> <pod-on-node-2> -- ping -c 3 $POD1_IP

# Check Kindnet has installed routes on a node
docker exec kind-worker ip route show | grep -E "via|podCIDR"
# Expected output (host-gateway mode):
# 10.244.0.0/24 via 172.18.0.2 dev eth0
# 10.244.1.0/24 via 172.18.0.3 dev eth0

# Check the VXLAN interface if running in VXLAN mode
docker exec kind-worker ip link show kindnet-vxlan

# Verify service endpoint is reachable
kubectl get svc -A | grep NodePort
curl -I http://kindnet-service.example.com/health
# Expected:
# HTTP/1.1 200 OK

If you are using port-forwarding for local development:

# Forward a service port for testing
kubectl port-forward svc/<service-name> 8080:80

# Test the forwarded endpoint
curl -I http://localhost:8080/health
# Expected:
# HTTP/1.1 200 OK
# content-type: application/json

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Kindnet-networked service endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: http://kindnet-service.example.com/health
Set Check interval to 60 seconds and Expected status code to 200.
Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor for cross-node connectivity validation

Since Kindnet failures often only affect cross-node traffic while same-node traffic continues to work, it is important to monitor a service that requires requests to travel across nodes:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL for a service known to be deployed on multiple nodes: http://kindnet-service.example.com/health
Set Expected status code to 200 and Timeout to 10 seconds.
Add a keyword check for "status":"ok" to verify the response body reflects a healthy application state, not a cached response from a degraded replica.
Click Save Monitor.

Why external monitoring catches what internal checks miss

Kindnet failures are invisible inside the cluster. When a routing table is stale, the host-gateway routes are gone, or a VXLAN tunnel silently drops packets, Kubernetes readiness probes that run within the same node continue to pass because they probe the local pod directly without traversing the Kindnet overlay. Vigilmon operates from outside your infrastructure, routing through the same network path your users or CI consumers use. It surfaces inter-node connectivity failures — the exact failures that Kindnet is responsible for — that application-internal checks structurally cannot detect.

Step 3: Monitor Kindnet's TCP port

A TCP monitor verifies that the Kindnet-networked service is accepting connections at the transport layer, independent of any application health check logic.

In Vigilmon, click Add Monitor.
Set Monitor type to TCP.
Enter Host: kindnet-service.example.com and Port: 80 (or the relevant service port).
Set Check interval to 60 seconds.
Click Save Monitor.

Find exposed ports for kind cluster services:

# List NodePort services in the kind cluster
kubectl get svc -A -o wide | grep NodePort

# Find what ports the kind control-plane container exposes
docker port kind-control-plane

# Sample output:
# 6443/tcp -> 0.0.0.0:6443
# 80/tcp -> 0.0.0.0:30080
# 443/tcp -> 0.0.0.0:30443

# Test TCP connectivity to a NodePort
nc -zv 127.0.0.1 30080
# Expected: Connection to 127.0.0.1 30080 port [tcp/*] succeeded!

# Check what the service pod is listening on
kubectl exec -n <namespace> <service-pod> -- ss -tlnp

Step 4: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels and click Add Channel.
Choose Email and enter the address that should receive notifications (for example, dev-team@example.com or a CI notification alias).
Assign this channel to all Kindnet monitors created in Steps 2 and 3.
Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or a CI/CD notification system, add a webhook channel:

In Alert Channels, click Add Channel and choose Webhook.
Paste your endpoint URL.
Vigilmon will POST the following JSON payload when a monitor transitions to down:

{
  "monitor_id": "mon_kindnet_health",
  "monitor_name": "Kindnet service /health",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "http://kindnet-service.example.com/health"
}

Assign all Kindnet monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

#!/bin/bash
# Kindnet alert runbook — run these in order when Vigilmon fires

echo "=== Kindnet DaemonSet status ==="
kubectl get daemonset -n kube-system kindnet

echo "=== Kindnet pod health per node ==="
kubectl get pods -n kube-system -l app=kindnet -o wide

echo "=== Recent Kindnet pod logs ==="
kubectl logs -n kube-system -l app=kindnet --tail=50

echo "=== Cluster node status ==="
kubectl get nodes -o wide

echo "=== Pod CIDR routes on workers ==="
for NODE in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== $NODE ==="
  docker exec $NODE ip route show 2>/dev/null | grep -E "podCIDR|10\.244|kindnet"
done

echo "=== HTTP endpoint response ==="
curl -sv http://kindnet-service.example.com/health 2>&1 | tail -20

echo "=== Service endpoints ==="
kubectl get endpoints -A

echo "=== Recent cluster events ==="
kubectl get events -A --sort-by='.lastTimestamp' | grep -i "cni\|kindnet\|network\|routing" | tail -20

echo "=== Port connectivity ==="
nc -zv kindnet-service.example.com 80

echo "=== Pod-to-pod connectivity test ==="
kubectl exec -n <namespace> <pod-name> -- ping -c 3 <other-pod-ip> || echo "Cross-pod ping FAILED"

Step 5: Create a public status page

A Vigilmon status page gives your development team and CI pipeline operators a single URL to check Kindnet cluster network health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as Kind Cluster Network and choose a subdomain like kind-cluster-status.vigilmon.page.
Add all monitors created in this tutorial: the /health HTTP monitor, the cross-node HTTP monitor, and the TCP port monitor.
Optionally add a description explaining that this kind cluster uses Kindnet for pod networking and that a monitor alert may indicate an overlay routing failure.
Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your CI pipeline documentation and team runbooks. When integration tests fail with unexplained connection errors, the status page is the first place to check whether Kindnet overlay routing is functioning correctly.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | http://kindnet-service.example.com/health | HTTP | Pod unreachable, service endpoint gone, CNI failure | | http://kindnet-service.example.com/health (cross-node) | HTTP | Inter-node routing failure, VXLAN tunnel drop, host-gateway stale route | | kindnet-service.example.com:80 | TCP | Transport-level connectivity loss, NodePort not forwarding |

# Quick-reference diagnostic one-liners when a Vigilmon alert fires

# 1. Are all Kindnet pods running?
kubectl get pods -n kube-system -l app=kindnet

# 2. Is the health endpoint responding?
curl -sf http://kindnet-service.example.com/health || echo "Health check FAILED"

# 3. Are there pod CIDR routes installed?
docker exec kind-worker ip route show | grep "10.244"

# 4. Is any Kindnet pod in CrashLoopBackOff?
kubectl get pods -n kube-system -l app=kindnet | grep -v Running

# 5. What errors appear in Kindnet logs?
kubectl logs -n kube-system -l app=kindnet --tail=20 | grep -i error

# 6. Are service endpoints populated?
kubectl get endpoints -A | grep -v "<none>"

# 7. Is port 80 open?
nc -zv kindnet-service.example.com 80 && echo "Port open" || echo "Port CLOSED"

# 8. Are nodes ready?
kubectl get nodes | grep -v Ready

What's next

Heartbeat monitoring for Kindnet route convergence — Configure a Kubernetes CronJob that checks the expected number of pod CIDR routes on each kind node and POSTs a heartbeat to a Vigilmon dead-man's-switch endpoint only when all routes are present. If Kindnet fails to re-converge after a node restart, the heartbeat stops and Vigilmon fires an alert before CI tests start producing confusing network errors.
SSL certificate monitoring — If your kind cluster exposes HTTPS endpoints via a local cert-manager installation or a self-signed certificate, add a Vigilmon SSL monitor to alert before certificate expiry causes CI test failures that look like network errors but are actually TLS rejections.
Response time baseline for CI regression detection — Use Vigilmon's response time history to establish a latency baseline for your kind cluster service endpoints. An abrupt increase in response time across CI runs can indicate a Kindnet routing degradation that slows inter-node traffic before it causes complete connectivity failures.

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.