tutorial

Monitoring KubeNav with Vigilmon: Kubernetes Cluster API Connectivity, Auth Token Health & Backend Proxy Availability Alerts

How to monitor KubeNav with Vigilmon — Kubernetes API server connectivity monitoring, kubeconfig authentication health, KubeNav backend proxy availability, and multi-cluster access reliability.

KubeNav is a multi-platform Kubernetes cluster browser — available on iOS, Android, macOS, Linux, and Windows — that gives engineers on-the-go access to pods, deployments, logs, and cluster events directly from their phones or desktops. When the Kubernetes API server becomes unreachable from a mobile network, KubeNav goes silent: engineers cannot check pod restarts, read logs, or troubleshoot incidents away from their workstations. When authentication tokens expire, KubeNav returns cryptic 401 errors with no context about which kubeconfig entry has gone stale. When KubeNav's optional backend proxy (used in enterprise deployments to avoid exposing the API server directly to mobile clients) crashes, the entire mobile management capability is lost. Vigilmon gives you external visibility into the API server endpoints that KubeNav relies on, the proxy health for enterprise deployments, and TLS certificate validity on every connection path.

What You'll Build

  • HTTP monitors on each Kubernetes API server endpoint that KubeNav connects to
  • SSL certificate monitors for API server and KubeNav proxy TLS endpoints
  • TCP monitors to verify network reachability of API server ports from external networks
  • HTTP monitor on the KubeNav backend proxy (for enterprise deployments)
  • Alerting runbook for diagnosing KubeNav connectivity failures

Prerequisites

  • One or more Kubernetes clusters with API servers accessible over the internet or VPN
  • KubeNav installed on iOS, Android, macOS, or desktop (from kubenav.io or app stores)
  • Optionally: KubeNav backend proxy deployed for enterprise/firewalled environments
  • A free account at vigilmon.online

Step 1: Understand KubeNav's Connectivity Model

KubeNav connects to Kubernetes clusters using kubeconfig files. In the default (direct) mode, it connects directly from the mobile/desktop client to the Kubernetes API server over HTTPS. In enterprise deployments, a backend proxy is deployed in-cluster to forward requests.

# Verify your API server is externally reachable
curl -k https://api.your-cluster.example.com:6443/healthz
# Expected: ok

# Check the API server certificate
echo | openssl s_client -connect api.your-cluster.example.com:6443 2>/dev/null | \
  openssl x509 -noout -dates -subject

# For multi-cluster KubeNav setups, check each API server
for CLUSTER in cluster1 cluster2 cluster3; do
  echo "=== $CLUSTER ==="
  curl -sk https://${CLUSTER}-api.example.com:6443/healthz
done

KubeNav's failure modes break down into:

  1. API server unreachable from mobile networks (firewall, DNS, routing)
  2. TLS certificate errors on the API server (expired or hostname mismatch)
  3. Authentication token expiry (OIDC, service account, or kubeconfig tokens)
  4. KubeNav backend proxy unavailable (enterprise deployments)

Step 2: Monitor Each Kubernetes API Server Endpoint

Add an HTTP monitor for each API server that KubeNav connects to. The /healthz endpoint requires no authentication and confirms that the API server is accepting connections:

# Test API server health endpoint (no auth required)
curl -k https://api.your-cluster.example.com:6443/healthz
# Expected: ok (plain text)

# For clusters with valid TLS certs (no -k needed)
curl https://api.your-cluster.example.com:6443/healthz

For each Kubernetes cluster KubeNav manages:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.your-cluster.example.com:6443/healthz.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: cluster1 API server (KubeNav).
  8. Click Save.

Repeat for each cluster. This monitor detects API server outages, network partitions, and firewall changes that block KubeNav connections.

Step 3: Monitor API Server TLS Certificates

TLS certificate expiry on the API server is the most common silent cause of KubeNav connectivity failures. Expired API server certificates cause all KubeNav connections to fail with TLS handshake errors, and mobile clients show unhelpful "connection failed" messages without indicating the root cause:

# Check the API server certificate expiry
echo | openssl s_client -connect api.your-cluster.example.com:6443 2>/dev/null | \
  openssl x509 -noout -enddate
# notAfter=Jan 15 00:00:00 2026 GMT

For each API server:

  1. Add Monitor → SSL Certificate.
  2. Domain: api.your-cluster.example.com (port 6443 — specify port if Vigilmon supports non-443 SSL checks).
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

kubeadm-managed clusters: kubeadm-provisioned API server certificates expire after 1 year by default. They auto-renew on kubeadm upgrade but NOT on rolling node upgrades alone. The 30-day Vigilmon alert gives you time to run kubeadm certs renew all proactively.

Step 4: Monitor API Server TCP Reachability

An HTTP monitor checks the application layer, but TCP connectivity confirms whether the network path is open from external clients (simulating a KubeNav mobile connection from a cellular network or remote office):

  1. Add Monitor → TCP.
  2. Host: api.your-cluster.example.com.
  3. Port: 6443.
  4. Check interval: 60 seconds.
  5. Label: cluster1 API server TCP (6443).
  6. Click Save.

Repeat for each cluster. When a firewall rule blocks the API server port for external IPs, the TCP monitor fires while internal cluster monitors remain green — exactly the scenario where KubeNav users on mobile networks lose connectivity but kubectl from within the office continues working.

Step 5: Monitor the KubeNav Backend Proxy (Enterprise Deployments)

Enterprise KubeNav deployments route all mobile API requests through a backend proxy deployed inside the cluster. The proxy exposes a single HTTPS endpoint that KubeNav clients connect to, with the proxy forwarding requests to each API server internally. If the proxy pod crashes, all KubeNav mobile access fails:

# Check if you're using the KubeNav backend proxy
kubectl get deployments -n kubenav
# Look for: kubenav-backend or similar

# Check the proxy service
kubectl get svc -n kubenav
# Look for: LoadBalancer or NodePort service exposing port 14122

# Test the proxy health endpoint
curl https://kubenav-proxy.example.com:14122/api/v1/health
# Expected: 200 OK or similar health response
  1. Add Monitor → HTTP.
  2. URL: https://kubenav-proxy.example.com:14122/api/v1/health.
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Label: KubeNav backend proxy.
  6. Click Save.

Also add a TCP monitor on the proxy port:

  1. Add Monitor → TCP.
  2. Host: kubenav-proxy.example.com.
  3. Port: 14122.
  4. Check interval: 60 seconds.
  5. Label: KubeNav proxy TCP (14122).
  6. Click Save.

Step 6: Monitor OIDC and Authentication Provider Endpoints

KubeNav supports OIDC authentication for enterprise clusters. When the OIDC provider (Dex, Keycloak, Okta, etc.) becomes unavailable, KubeNav cannot refresh tokens and all cluster connections fail with 401 errors. Monitor the OIDC discovery endpoint:

# Test the OIDC discovery endpoint
curl https://dex.example.com/.well-known/openid-configuration | jq '.issuer'
# Expected: your OIDC issuer URL

# Test the OIDC token endpoint
curl -X POST https://dex.example.com/token \
  -d "grant_type=client_credentials&client_id=kubenav&client_secret=secret"

For the OIDC provider:

  1. Add Monitor → HTTP.
  2. URL: https://dex.example.com/.well-known/openid-configuration.
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: issuer (always present in OIDC discovery JSON).
  6. Label: OIDC provider (KubeNav auth).
  7. Click Save.

Also add an SSL monitor for the OIDC provider's certificate — an expired OIDC TLS cert causes the same silent failure as an expired API server cert.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels and response runbooks for KubeNav's connectivity stack:

| Monitor | Trigger | Immediate action | |---|---|---| | API server HTTP /healthz | Non-200 or timeout | Check API server pods on control plane nodes; check cloud provider API server health (EKS/GKE/AKS) | | API server TLS certificate | < 30 days | Run kubeadm certs renew all on control plane; update kubeconfig certs for all KubeNav users | | API server TCP (6443) | Connection refused | Check firewall rules; verify Security Group / VPC rules allow 6443 from external IPs | | KubeNav backend proxy HTTP | Non-200 | Check proxy pod: kubectl get pods -n kubenav; restart deployment | | KubeNav proxy TCP (14122) | Connection refused | Check LoadBalancer service; verify firewall allows port 14122 from mobile client IPs | | OIDC provider | Non-200 or keyword missing | Check OIDC provider pods/service; users must re-authenticate after provider restores |

Alert grouping: Create a kubenav-connectivity monitor group per cluster. When a cluster's API server goes down, the HTTP and TCP monitors fire together — the group view shows exactly which cluster lost connectivity, which is essential when managing multiple clusters via KubeNav.

Common KubeNav Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon signal | |---|---| | API server control plane node failure | HTTP and TCP monitors fire; KubeNav shows "connection refused" | | API server certificate expires (kubeadm 1-year default) | SSL monitor fires at 30-day threshold; all KubeNav connections fail on expiry day | | Firewall rule change blocks port 6443 from external IPs | TCP monitor fires; internal monitoring stays green (mobile-specific failure) | | OIDC provider pod crash | OIDC HTTP monitor fires; KubeNav token refresh fails silently | | KubeNav backend proxy OOMKilled | Proxy HTTP and TCP monitors fire; all mobile access fails while internal kubectl still works | | Cloud provider maintenance takes down API server | HTTP monitor fires; correlates with cloud provider status page | | API server overloaded (high request latency) | HTTP monitor shows slow response time approaching timeout threshold | | VPN IP range change blocks mobile to API server | TCP monitor fires from external check points | | kubeconfig service account token revoked by admin | API server returns 401 (auth-layer failure; HTTP monitor still returns 200 on /healthz) | | DNS record for API server updated with TTL not respected | HTTP and TCP monitors fire during propagation window |

KubeNav makes Kubernetes cluster management mobile-native — but that mobility depends on reliable network connectivity from cellular and remote networks to your API servers. Vigilmon gives you external visibility into every connectivity layer: API server HTTP health, TCP reachability from external networks, TLS certificate validity, OIDC provider availability, and enterprise proxy health. When a firewall change blocks KubeNav users on mobile from reaching the API server while office kubectl continues working, Vigilmon catches the discrepancy instantly.

Start monitoring your KubeNav connectivity stack 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