tutorial

Uptime monitoring for Kasten K10

Kasten K10 by Veeam is the leading Kubernetes-native backup and disaster recovery platform. It protects stateful workloads in Kubernetes — databases, persist...

Kasten K10 by Veeam is the leading Kubernetes-native backup and disaster recovery platform. It protects stateful workloads in Kubernetes — databases, persistent volumes, Helm releases — with policy-driven backup, restore, and migration capabilities. When K10 goes down, your backup jobs stop running silently. By the time you need to restore from a backup during an incident, you discover the backups haven't been taken in days.

This tutorial covers production-grade uptime monitoring for Kasten K10 using Vigilmon. We will walk through:

  • Monitoring the K10 dashboard web UI (/k10/#/)
  • Monitoring the K10 API health check endpoint (/k10/v0.0/k10pods/)
  • Monitoring backup job status
  • Heartbeat monitoring for scheduled backup policies
  • SSL certificate alerts for the K10 dashboard

Prerequisites

  • Kasten K10 installed in a Kubernetes cluster (version 5.x or 6.x)
  • kubectl access to the cluster with the K10 namespace (kasten-io)
  • A free account at vigilmon.online

Part 1: Expose the K10 dashboard for external monitoring

K10's dashboard is deployed as a service inside Kubernetes, typically in the kasten-io namespace. By default it is only accessible from within the cluster or via kubectl port-forward.

Option A: NodePort service

Expose K10 on a NodePort for monitoring purposes:

kubectl patch svc gateway -n kasten-io \
  -p '{"spec": {"type": "NodePort"}}'

Get the assigned port:

kubectl get svc gateway -n kasten-io
# NAME      TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)        AGE
# gateway   NodePort   10.96.0.123    <none>       80:31234/TCP   5d

Access the dashboard at http://NODE_IP:31234/k10/#/.

Option B: Ingress

Create an Ingress resource for the K10 gateway:

# k10-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: k10-ingress
  namespace: kasten-io
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - k10.example.com
      secretName: k10-tls
  rules:
    - host: k10.example.com
      http:
        paths:
          - path: /k10
            pathType: Prefix
            backend:
              service:
                name: gateway
                port:
                  number: 80

Apply it:

kubectl apply -f k10-ingress.yaml

Verify the dashboard responds:

curl -o /dev/null -w "%{http_code}" https://k10.example.com/k10/#/

Expected: 200.

Part 2: Monitor the K10 dashboard web UI

  1. Log in to vigilmon.online and click Add Monitor.
  2. Choose HTTP(S) monitor.
  3. Enter: https://k10.example.com/k10/#/
  4. Set interval to 1 minute.
  5. Add a keyword check: must contain Kasten (present in the K10 dashboard page title).
  6. Add your alert channel.
  7. Click Save.

The keyword check confirms the K10 frontend loaded correctly, not just that the web server responded.

Part 3: Monitor the K10 API health endpoint

K10 exposes an API at /k10/v0.0/k10pods/ that returns a JSON list of K10 component pods and their status. This is a more reliable health indicator than the UI, because it directly queries the K10 control plane:

curl -s https://k10.example.com/k10/v0.0/k10pods/ | python3 -m json.tool | head -30

Expected output (partial):

{
  "pods": [
    {
      "name": "catalog-svc-...",
      "namespace": "kasten-io",
      "phase": "Running",
      ...
    },
    ...
  ]
}

If K10 components are crashing, their phase will be CrashLoopBackOff or Pending. The endpoint itself will return HTTP 200 as long as the gateway is up, but the pod statuses reflect the actual system health.

Add a Vigilmon HTTP monitor:

  1. Click Add Monitor → HTTP(S) monitor.
  2. Enter: https://k10.example.com/k10/v0.0/k10pods/
  3. Set interval to 2 minutes.
  4. Add a keyword check: must contain "phase": "Running".
  5. Add your alert channel.
  6. Click Save.

The keyword check ensures at least one K10 pod is in the Running phase, not just that the API responded.

Part 4: Monitor the backup job status endpoint

K10 exposes backup job status via its API. Query recent jobs to verify backups are completing successfully:

# Get all completed backup actions
curl -s "https://k10.example.com/k10/v0.0/actions?state=complete&type=backup" \
  | python3 -m json.tool | head -20

Expected output (partial):

{
  "actions": [
    {
      "type": "backup",
      "state": "complete",
      "startTime": "2026-07-12T02:00:00Z",
      ...
    }
  ]
}

Add a Vigilmon HTTP monitor for the actions endpoint:

  1. Click Add Monitor → HTTP(S) monitor.
  2. Enter: https://k10.example.com/k10/v0.0/actions?state=complete&type=backup
  3. Set interval to 10 minutes.
  4. Add a keyword check: must contain "type": "backup".
  5. Add your alert channel.
  6. Click Save.

This checks that the K10 actions API is responding and returning backup job data.

Part 5: Heartbeat monitoring for scheduled backup policies

K10 backup policies run on Kubernetes cron schedules. The most reliable way to know whether backups are actually completing is to have your backup verification script send a heartbeat to Vigilmon after each successful backup.

Create the heartbeat monitor in Vigilmon

  1. In Vigilmon, click Add Monitor → Heartbeat monitor.
  2. Name it: K10 daily backup policy.
  3. Set expected interval to 24 hours (or match your backup frequency).
  4. Set grace period to 2 hours.
  5. Copy the heartbeat URL.
  6. Click Save.

Create a post-backup verification CronJob

K10 supports post-backup hooks. The simplest approach is a Kubernetes CronJob that checks whether backup jobs completed and sends a heartbeat:

# k10-backup-verifier.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: k10-backup-verifier
  namespace: kasten-io
spec:
  schedule: "0 6 * * *"   # 6 AM daily — runs after your nightly backup policy
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: verifier
              image: curlimages/curl:8.6.0
              env:
                - name: HEARTBEAT_URL
                  value: "https://vigilmon.online/api/heartbeat/YOUR_TOKEN"
                - name: K10_API
                  value: "http://gateway.kasten-io.svc.cluster.local/k10/v0.0"
              command:
                - /bin/sh
                - -c
                - |
                  set -e
                  echo "Checking K10 backup status..."

                  # Get most recent completed backup actions
                  RESULT=$(curl -fsS "${K10_API}/actions?state=complete&type=backup" 2>/dev/null)

                  if echo "$RESULT" | grep -q '"type": "backup"'; then
                    echo "K10 backup jobs found — sending heartbeat"
                    curl -fsS --retry 3 "${HEARTBEAT_URL}"
                    echo "Heartbeat sent"
                  else
                    echo "ERROR: No completed backup jobs found in K10 API" >&2
                    exit 1
                  fi

Apply it:

kubectl apply -f k10-backup-verifier.yaml

The CronJob runs at 6 AM daily. If K10 completed backup jobs, the heartbeat is sent. If no backups are found — because K10 is down, the policy was disabled, or the backup failed — the job exits with error and Vigilmon never receives the heartbeat, triggering an alert.

Part 6: SSL certificate monitoring

K10's dashboard is served over HTTPS. Whether you use cert-manager with Let's Encrypt or a manually imported certificate, it can expire. Add an SSL monitor:

  1. In Vigilmon, click Add Monitor → SSL monitor.
  2. Enter your K10 hostname: k10.example.com.
  3. Set alert threshold to 14 days before expiry.
  4. Add your alert channel.
  5. Click Save.

Check the certificate expiry manually:

openssl s_client -connect k10.example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

If you use cert-manager, verify the certificate status:

kubectl get certificate -n kasten-io k10-tls -o jsonpath='{.status.conditions[*]}'

A Ready: True condition with a recent lastTransitionTime means the certificate is valid and has been renewed.

Part 7: Kubernetes-native monitoring sidecar

For more granular K10 monitoring, deploy a lightweight CronJob that polls K10's internal pod status and only sends a heartbeat when all K10 pods are healthy:

#!/usr/bin/env python3
# k10-monitor.py — runs as a Kubernetes CronJob

import os
import sys
import json
import urllib.request

K10_API = os.environ.get("K10_API", "http://gateway.kasten-io.svc.cluster.local/k10/v0.0")
HEARTBEAT_URL = os.environ.get("HEARTBEAT_URL", "")

def check_k10_pods():
    url = f"{K10_API}/k10pods/"
    with urllib.request.urlopen(url, timeout=10) as resp:
        data = json.loads(resp.read())
    pods = data.get("pods", [])
    running = [p for p in pods if p.get("phase") == "Running"]
    print(f"K10 pods: {len(running)}/{len(pods)} running")
    return len(running) > 0

def send_heartbeat():
    if not HEARTBEAT_URL:
        print("No HEARTBEAT_URL set, skipping")
        return
    with urllib.request.urlopen(HEARTBEAT_URL, timeout=10) as resp:
        print(f"Heartbeat sent: {resp.status}")

if __name__ == "__main__":
    try:
        healthy = check_k10_pods()
        if healthy:
            send_heartbeat()
        else:
            print("ERROR: No K10 pods running", file=sys.stderr)
            sys.exit(1)
    except Exception as e:
        print(f"ERROR: {e}", file=sys.stderr)
        sys.exit(1)

Package this as a Docker image, deploy as a Kubernetes CronJob in the kasten-io namespace, and set the HEARTBEAT_URL environment variable from a Kubernetes Secret.

Summary

Your Kasten K10 deployment now has five layers of monitoring:

  1. Dashboard UI check — confirms K10's frontend is serving the dashboard at /k10/#/, keyword-checked for Kasten.
  2. K10 pods API check — confirms the K10 control plane is running and /k10/v0.0/k10pods/ shows pods in the Running phase.
  3. Backup actions API check — confirms the K10 actions API returns completed backup job data.
  4. Heartbeat monitor — your daily backup verifier CronJob pings Vigilmon after confirming backups completed; missing pings trigger alerts.
  5. SSL certificate monitor — alerts you 14 days before the K10 dashboard certificate expires.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any failure in your K10 backup infrastructure — before a missed backup becomes a disaster recovery crisis.

Monitor your Kasten K10 infrastructure free at vigilmon.online

#kasten #k10 #kubernetes #backup #disasterrecovery #monitoring #devops

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