tutorial

Monitoring k0s with Vigilmon: Kubernetes Control Plane, API Server & Node Health

How to monitor k0s with Vigilmon — Kubernetes API server availability, node health, control plane components, and alerting for lightweight k8s cluster outages.

k0s is a lightweight, self-contained Kubernetes distribution by Mirantis that packages the entire control plane — API server, scheduler, controller manager, and etcd — into a single binary. Teams use k0s to run production-grade Kubernetes on edge devices, constrained VMs, and developer laptops without the overhead of kubeadm or managed cloud offerings. Its architecture means a single process handles what multi-component stacks spread across five or more systemd units; when that binary is healthy everything works, and when it degrades — due to resource pressure, disk exhaustion, or a bad upgrade — the entire cluster becomes unresponsive. Vigilmon gives you external visibility into the k0s API server, the cluster nodes, and the workloads running inside, so outages surface in your alerting channel before developers start filing bug reports.

What You'll Build

  • An HTTP monitor for the k0s Kubernetes API server health endpoint
  • A monitor for the k0s API server itself to detect authentication and availability failures
  • Node-level health checks for control plane and worker nodes
  • Monitors for workloads running inside your k0s cluster
  • SSL certificate monitoring for the k0s API server TLS endpoint
  • An alerting setup that separates control plane failures from application failures

Prerequisites

  • A running k0s cluster (k0s start or installed as a systemd service)
  • kubectl configured with a kubeconfig pointing to the cluster
  • A free account at vigilmon.online

Step 1: Verify k0s API Server Reachability

The k0s API server listens on port 6443 by default. Before setting up monitoring, confirm the server is externally reachable from your Vigilmon monitoring target:

# Check k0s API server health (unauthenticated)
curl -k https://your-k0s-host:6443/healthz

# Check with kubectl
kubectl get --raw='/healthz'
kubectl get --raw='/readyz'

A healthy response returns ok. If your k0s cluster is behind a firewall, expose the health endpoint or whitelist Vigilmon's IP range for the monitoring check.

Find the k0s API server address in your kubeconfig:

kubectl config view --raw | grep server
# Example: server: https://192.168.1.10:6443

Step 2: Monitor the k0s API Server Health Endpoint

The /healthz endpoint is the canonical liveness check for the Kubernetes API server. It returns ok when the API server is running and +Inf metrics are flowing:

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

k0s uses a self-signed certificate by default. If Vigilmon enforces certificate validation, either upload the cluster CA certificate or use the /readyz?verbose=true endpoint with a valid cert. For internal clusters, a separate lightweight health proxy on port 80 is common.

Step 3: Monitor the k0s API Server Readiness

The /readyz endpoint checks that all internal controllers and the API server itself have completed initialization and can serve requests. This is more meaningful than /healthz for detecting partial startup failures or degraded states:

  1. Add Monitor → HTTP.
  2. URL: https://your-k0s-host:6443/readyz.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: k0s API server (/readyz).
  8. Click Save.

Together, /healthz and /readyz give you early warning of both crashes and degraded-but-alive API servers that are failing some internal check (etcd connection lost, informer cache stale, leader election lost).

Step 4: Monitor the k0s etcd Metrics Endpoint

k0s bundles etcd as the cluster's persistent store. In single-node setups, etcd runs in the same process and its failure immediately kills the API server. In multi-node control plane setups, etcd cluster health is critical to keep watch on:

# Check etcd health via kubectl
kubectl get --raw='/healthz/etcd'

# Or query the etcd metrics endpoint if exposed
curl http://your-k0s-host:2381/metrics | head -20

For the etcd health check via the API server:

  1. Add Monitor → HTTP.
  2. URL: https://your-k0s-host:6443/healthz/etcd.
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: k0s etcd health.
  8. Click Save.

Step 5: Monitor Workloads Running in the k0s Cluster

k0s itself is a control plane and runtime — the applications it orchestrates are your real business concern. Monitor those workloads directly:

# Find running services and their exposed ports
kubectl get services --all-namespaces

# Get NodePort or LoadBalancer endpoints
kubectl get services --all-namespaces -o wide | grep NodePort

For a web application exposed on a NodePort:

  1. Add Monitor → HTTP.
  2. URL: http://your-k0s-node:30080.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: (your app's expected response keyword, e.g. Welcome).
  7. Label: App in k0s cluster (NodePort 30080).
  8. Click Save.

For an ingress controller exposing applications on port 443:

  1. Add Monitor → HTTP.
  2. URL: https://your-k0s-ingress-host/your-app.
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Label: k0s ingress (your-app).
  6. Click Save.

Step 6: Monitor k0s Worker Node API Endpoints

In multi-node k0s clusters, each worker node runs k0s worker and exposes the kubelet API on port 10250. Unreachable kubelets mean pods on that node cannot be scheduled or health-checked by the control plane:

# Check kubelet health on a worker node
curl -k https://your-worker-node:10250/healthz

For each worker node:

  1. Add Monitor → HTTP.
  2. URL: https://your-worker-node-ip:10250/healthz.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: k0s worker kubelet (node-name).
  8. Click Save.

Kubelet HTTPS requires authentication in default k0s setups. If anonymous auth is disabled (recommended), monitor the node via a workload health check on that node instead, or expose a simple HTTP health endpoint with a DaemonSet probe.

Step 7: Monitor SSL Certificates

k0s generates self-signed certificates for the API server and kubelet during k0s install. These certificates have a fixed expiry that must be renewed before cluster operations break:

# Check API server cert expiry
openssl s_client -connect your-k0s-host:6443 -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: your-k0s-host (port 6443).
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

If you've added a custom domain in front of k0s via an ingress, monitor that certificate separately:

  1. Add Monitor → SSL Certificate.
  2. Domain: k0s.your-domain.com.
  3. Alert when expiry is within: 30 days.
  4. Click Save.

Step 8: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | k0s API /healthz | Non-200 or keyword missing | API server crashed; check systemctl status k0s | | k0s API /readyz | Non-200 or keyword missing | API server degraded; check etcd connectivity and leader election | | k0s etcd health | Non-200 or keyword missing | etcd unhealthy; check disk space and I/O latency | | App workload (NodePort) | Non-200 or timeout | Application pod down; check kubectl get pods | | Ingress endpoint | Non-200 or timeout | Ingress controller or upstream pod failure | | Worker kubelet | Non-200 or keyword missing | Node unresponsive; pods will not be scheduled | | SSL certificate | < 30 days to expiry | API server TLS will break; run k0s certs renew |

Alert routing: Route API server alerts to the platform team on-call immediately. Application monitors can route to the application team. Distinguish between "k0s is down" (all apps affected) and "app pod is down" (single service affected) in your runbooks.

Common k0s Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | k0s binary OOM-killed by kernel | API server /healthz fires; entire cluster unreachable | | etcd disk full — writes rejected | etcd health check fires; API server starts returning 500s | | k0s upgrade leaves API server in failed state | Both /healthz and /readyz fire during rollout | | Worker node network partition | Kubelet monitor fires; pods on node not rescheduled | | NodePort app pod crash-looping | Workload monitor fires; intermittent 503s from pod restart | | Ingress controller misconfigured after deploy | Ingress monitor fires; all routed services return 404 | | API server TLS cert expired | SSL monitor alerts at 30 days before kubectl fails | | DNS failure for k0s host | Monitor fires from Vigilmon external check |

k0s packages Kubernetes operational complexity into a single binary, but that simplicity doesn't remove the need for external observability. Vigilmon's external HTTP checks verify the API server is reachable and healthy from outside the cluster itself — the vantage point that matters when the node's internal metrics stack is also affected by the outage. Combine API server health checks with workload monitors and SSL expiry alerts for complete coverage of a k0s deployment.

Start monitoring your k0s 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