tutorial

Monitoring Kind (Kubernetes in Docker) with Vigilmon: Local Cluster API Health, Ingress Connectivity, Port Forwarding & TLS Certificate Alerts

How to monitor Kind (Kubernetes in Docker) local development clusters with Vigilmon — API server health, ingress-nginx connectivity, port-forwarded service monitoring, and TLS certificate alerting for local Kubernetes environments.

Kind (Kubernetes in Docker) is a tool for running local Kubernetes clusters using Docker containers as nodes, making it the go-to choice for local development, CI pipeline testing, and Kubernetes contributor testing. Each Kind cluster runs as a set of Docker containers — control plane nodes and worker nodes — with the Kubernetes API server, etcd, and all system components running inside those containers. Kind clusters are ephemeral by design: they're created in seconds, run for the duration of a CI job or development session, and deleted when no longer needed. But teams increasingly run longer-lived Kind clusters for local integration testing, multi-service development environments, and shared team development clusters — and these persistent Kind clusters need monitoring. When a Docker daemon restart kills all Kind node containers, the cluster is completely unavailable until the containers are restarted. When ingress-nginx inside Kind loses its port mapping to the host, no external traffic reaches the cluster even though the API server is healthy. Vigilmon gives you external visibility into Kind clusters that matter: API server health through port-forwarded endpoints, application HTTP monitoring through ingress-nginx, and TLS certificate monitoring for locally-trusted certificates.

What You'll Build

  • HTTP monitors on the Kind API server health endpoint (via port forwarding or host network)
  • HTTP monitors on applications served through ingress-nginx in Kind
  • TCP monitors on Kind's exposed node ports to detect container-level failures
  • SSL certificate monitors for HTTPS endpoints served through Kind
  • A failure mode table covering Kind-specific failure scenarios
  • An alerting runbook for persistent Kind clusters used in development and CI

Prerequisites

  • A Kind cluster with at least one worker node
  • ingress-nginx installed and configured with host port mappings (ports 80 and 443)
  • At least one application deployed with an Ingress resource
  • A free account at vigilmon.online

Step 1: Understand Kind's Health Surface

Kind runs Kubernetes inside Docker containers. The API server is accessible on the host machine through a randomly assigned or explicitly configured port. Before setting up monitors, identify the Kind cluster's external ports:

# List Kind clusters
kind get clusters

# Get cluster API server port
kubectl cluster-info --context kind-<cluster-name>
# Returns: https://127.0.0.1:<api-port>

# Inspect Kind node container port mappings
docker ps --filter "label=io.x-k8s.kind.cluster=<cluster-name>" \
  --format "{{.Names}}: {{.Ports}}"

# Verify API server health
curl -k https://127.0.0.1:<api-port>/healthz

# Check ingress-nginx service
kubectl get svc -n ingress-nginx ingress-nginx-controller

The key monitoring surfaces for a persistent Kind cluster are:

  1. The Kubernetes API server /healthz endpoint (control plane health)
  2. Applications served through ingress-nginx (workload health)
  3. Port 80/443 on the Kind host (ingress-nginx port mapping health)
  4. TLS certificates for any HTTPS services

Step 2: Configure Kind for External Monitoring Access

By default, Kind's API server binds to 127.0.0.1, making it inaccessible to external monitors. For a persistent Kind cluster that needs monitoring, configure Kind with explicit port mappings when creating the cluster:

# kind-config.yaml — Kind cluster with monitoring-friendly configuration
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    kubeadmConfigPatches:
      - |
        kind: InitConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            node-labels: "ingress-ready=true"
    extraPortMappings:
      - containerPort: 80
        hostPort: 80
        protocol: TCP
      - containerPort: 443
        hostPort: 443
        protocol: TCP
  - role: worker
  - role: worker

Create the cluster with this configuration:

kind create cluster --config kind-config.yaml --name monitoring-cluster

For API server monitoring, create the cluster with an explicit API server address:

# Or use kind with an explicit kubeconfig that references the host machine's IP
# rather than 127.0.0.1 for remote access
kind get kubeconfig --name monitoring-cluster | \
  sed 's/127.0.0.1/your-host-machine-ip/g' > ~/.kube/kind-remote.yaml

Step 3: Monitor the Kind API Server

The Kind Kubernetes API server is the single most important health check for a persistent Kind cluster. When a Docker daemon restart, Docker Desktop update, or container OOM event kills the Kind node containers, the API server becomes unreachable immediately:

# Get the API server port for your Kind cluster
kubectl cluster-info --context kind-monitoring-cluster
# Example: https://127.0.0.1:52688 (use your host IP for external access)
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://your-host-machine.example.com:<api-port>/healthz (replace with your host machine's accessible IP or hostname and Kind API port).
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: Kind API server /healthz.
  8. Click Save.

TLS note: Kind uses a self-signed certificate for the API server. Add --tls-san your-host-ip to the kubeadm config in your Kind configuration file to include your host IP in the certificate SAN, ensuring Vigilmon's HTTPS monitor can validate the certificate — or use a keyword-only HTTP check if TLS validation is not needed.

Step 4: Monitor Applications Through ingress-nginx

ingress-nginx in Kind forwards traffic from the Docker host's port 80/443 through the container network to your application pods. This is the end-to-end path your applications use for HTTP/HTTPS access, and it's the layer most likely to break when Docker networks are recreated or container port mappings are lost:

# Verify ingress-nginx is routing correctly
curl http://localhost/healthz
# Or with a hostname:
curl -H "Host: myapp.example.com" http://localhost/health
  1. Add Monitor → HTTP.
  2. URL: https://myapp.example.com/health (your application's hostname configured in the Ingress resource).
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: your health response field.
  7. Label: myapp.example.com (Kind ingress-nginx).
  8. Click Save.

Local DNS note: For Kind to work with real hostnames, either use /etc/hosts entries pointing your test domains to the host machine's IP, or use a wildcard DNS entry (e.g., *.kind.local → 127.0.0.1). Vigilmon's monitors need to resolve the hostname from external DNS — for persistent internal clusters, configure a real subdomain pointing to your host machine's external IP.

Step 5: Monitor ingress-nginx Port Accessibility

The host port mappings from Kind to Docker (ports 80/443) are the bridge between external network access and the Kind cluster. A TCP monitor directly on these ports validates that the Docker port mapping is active and ingress-nginx is listening — separate from the application-level check:

  1. Add Monitor → TCP.

  2. Host: your-host-machine.example.com.

  3. Port: 443.

  4. Check interval: 60 seconds.

  5. Label: Kind host HTTPS TCP (443).

  6. Click Save.

  7. Add Monitor → TCP.

  8. Host: your-host-machine.example.com.

  9. Port: 80.

  10. Check interval: 60 seconds.

  11. Label: Kind host HTTP TCP (80).

  12. Click Save.

A TCP failure on port 443 while the Kind API server health check passes indicates that ingress-nginx has failed or the Docker port mapping has been lost — not a cluster-wide outage. Restart ingress-nginx: kubectl rollout restart deployment -n ingress-nginx ingress-nginx-controller.

Step 6: Monitor TLS Certificates for Kind HTTPS Services

Kind clusters using ingress-nginx with cert-manager or manually managed certificates need TLS certificate monitoring. Kind is commonly used with mkcert for locally-trusted certificates — but even locally-trusted certificates expire, and expired certificates break HTTPS for all developers working against the cluster:

# Check certificate expiry for a Kind ingress hostname
openssl s_client -connect myapp.example.com:443 -servername myapp.example.com 2>/dev/null \
  | openssl x509 -noout -dates

For each HTTPS hostname served through Kind's ingress:

  1. Add Monitor → SSL Certificate.
  2. Domain: myapp.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels and response runbooks:

| Monitor | Trigger | Immediate action | |---|---|---| | Kind API server /healthz | Non-200 or timeout | Check Docker containers: docker ps --filter "label=io.x-k8s.kind.cluster=<name>"; restart with kind restart cluster if available, or docker start $(docker ps -aq -f label=io.x-k8s.kind.cluster=<name>) | | Kind host TCP (443) | Connection refused | Ingress-nginx port mapping lost; check: docker ps --format "{{.Ports}}" -f name=<kind-node>; verify ingress-nginx pod is running | | Application HTTP | Non-200 | Check pod health: kubectl get pods; check ingress rules: kubectl get ingress; review ingress-nginx logs | | SSL certificate | < 30 days | Renew certificate; update Kubernetes Secret if manually managed; verify cert-manager is running | | Kind API TCP (api-port) | Connection refused | Kind control plane container may have crashed; check Docker container status and restart |

Alert grouping: Create a kind-cluster monitor group. When Docker Desktop restarts and kills all Kind containers, the API health, API TCP, and both ingress TCP monitors all fire simultaneously — the group view immediately signals a full cluster restart rather than individual component failures.

Common Kind Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon signal | |---|---| | Docker Desktop update restarts Docker daemon | All Kind monitors fire simultaneously (containers killed) | | Kind control plane container OOM killed | API /healthz and API TCP monitors fire; worker-hosted apps may still be reachable briefly | | ingress-nginx pod crash | Application HTTP monitors fire; API monitor continues passing | | Docker port mapping lost after host network change | TCP monitors for 80/443 fire; API monitor (on api-port) continues passing | | Kind worker node container killed | Application HTTP monitors for pods on that worker fire; API monitor passes | | TLS certificate expired for Kind ingress | SSL monitor fires at 30-day threshold; HTTP monitor fires on expiry with TLS error | | CoreDNS pod crash inside Kind | DNS-based HTTP monitors timeout; IP-based monitors continue passing | | Host machine goes to sleep (laptop lid close) | All monitors timeout simultaneously; recover when host wakes | | Kind cluster etcd data directory out of disk | API /healthz may return 500; new object creation fails | | Kernel network namespace leak from repeated cluster creation | Port mapping conflicts cause new cluster ingress to be unreachable; TCP monitors fail for new cluster |

Kind makes running full Kubernetes clusters locally as easy as a single kind create cluster command — but persistent Kind clusters used for integration testing, multi-service development, or shared team environments need the same monitoring discipline as production Kubernetes. Docker daemon restarts kill all Kind containers silently. ingress-nginx port mappings break when Docker networks are recreated. Certificates expire. Vigilmon gives you external visibility into all of these: API server health checks that fire within 60 seconds of a container crash, ingress TCP probes that detect port mapping failures before developers spend an hour debugging, and TLS certificate alerts that prevent certificate expiry from blocking the entire team's local development. When your Kind cluster is the foundation of your development workflow, treat it like production.

Start monitoring your Kind cluster in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles