How to Monitor Admiral (Istio Multi-Cluster Service Mesh) with Vigilmon

Admiral is a Kubernetes controller that automates Istio multi-cluster service discovery and global traffic routing. It manages ServiceEntry, VirtualService, and DestinationRule objects across clusters so that services in one mesh can seamlessly reach services in another — without operators manually maintaining cross-cluster Istio configuration.

That automation is powerful, but it also introduces failure modes that are invisible to Kubernetes health probes. A pod can be Running and Ready while Admiral's cross-cluster routing is broken, stale, or pointing at the wrong cluster endpoint.

This tutorial shows you how to set up external uptime monitoring for Admiral-managed services using Vigilmon — free tier, no credit card required.

Why Admiral-managed services need external monitoring

Admiral's job is to propagate routing configuration across clusters. When it works, traffic flows transparently. When something breaks, the failure is often silent:

• Admiral controller crashes or falls behind — Istio config in downstream clusters becomes stale; traffic routes to removed instances
• Cross-cluster DNS resolution fails — Admiral-managed global FQDNs stop resolving in one cluster while returning 200 locally
• VirtualService weight misconfiguration — a canary weight update misfires and 100% of traffic goes to the wrong cluster
• ServiceEntry sync lag — a newly deployed service isn't propagated to all clusters yet; requests from remote clusters fail with 503
• mTLS policy drift — PeerAuthentication or DestinationRule changes in one cluster break cross-cluster mTLS, causing connection resets

Kubernetes readinessProbe and livenessProbe check the pod from inside the cluster. They cannot detect routing failures that only appear when traffic crosses cluster boundaries. External monitoring from Vigilmon probes your global service endpoint the same way your users do — from outside, end-to-end.

What you'll need

• A multi-cluster Kubernetes setup with Istio and Admiral installed
• At least one service exposed via Istio Ingress Gateway with a global DNS name
• A free Vigilmon account

Step 1: Confirm your global service endpoint is reachable

Admiral creates ServiceEntry objects that make services from remote clusters appear as if they are local. Your Istio IngressGateway exposes these to the outside world.

Find your IngressGateway external IP:

kubectl get svc istio-ingressgateway -n istio-system
# NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)
# istio-ingressgateway   LoadBalancer   10.96.10.100   203.0.113.10    80:31380/TCP,443:31390/TCP

Verify your service responds through the gateway:

curl -H "Host: my-service.global" http://203.0.113.10/health
# {"status":"ok","cluster":"us-east-1","instance":"pod-abc123"}

If you have a real DNS name pointing to the gateway:

curl https://my-service.example.com/health
# {"status":"ok","cluster":"us-east-1","instance":"pod-abc123"}

Confirm your health endpoint returns HTTP 200 before proceeding.

Step 2: Add an HTTP monitor in Vigilmon

1. Sign in to vigilmon.online and go to Monitors → New Monitor
2. Select HTTP / HTTPS as the monitor type
3. Enter your global service URL: https://my-service.example.com/health
4. Set the check interval to 1 minute
5. Under Expected response, configure:
   • Status code: 200
   • (Optional) Response body contains: "status":"ok"
6. Save the monitor

Vigilmon probes your endpoint from multiple geographic regions simultaneously. If Admiral's cross-cluster routing breaks and requests start failing in any region, Vigilmon detects it within minutes regardless of what Kubernetes reports internally.

Multi-region consensus for mesh routing failures

Admiral routes traffic globally. A routing failure might affect requests originating from one geographic region but not another — for example, if Admiral's ServiceEntry sync only failed for one cluster's Istio configuration. Vigilmon's multi-region consensus runs probes from multiple locations and requires agreement before firing an alert. This means:

• Single-region blips don't trigger false positives
• Genuine cross-cluster routing failures are caught within seconds
• You get accurate signal about which regions are affected

Step 3: Monitor individual cluster Ingress endpoints

In addition to your global DNS endpoint, it's useful to monitor each cluster's IngressGateway directly. This tells you whether a failure is global or cluster-specific.

For each cluster (e.g., us-east-1, eu-west-1):

# Get the IngressGateway IP for each cluster
kubectl get svc istio-ingressgateway -n istio-system --context=cluster-us-east-1
kubectl get svc istio-ingressgateway -n istio-system --context=cluster-eu-west-1

Add a separate Vigilmon monitor for each cluster's IP or hostname:

| Monitor | URL | What it detects | |---------|-----|-----------------| | Global endpoint | https://my-service.example.com/health | End-to-end Admiral routing | | US cluster | http://203.0.113.10/health (Host: my-service.global) | US-east IngressGateway health | | EU cluster | http://203.0.113.20/health (Host: my-service.global) | EU-west IngressGateway health |

When your global monitor fires but one cluster monitor stays green, you know Admiral's cross-cluster routing — not the application itself — is the failure point.

Step 4: Monitor the Admiral controller itself

Admiral runs as a Deployment in your Kubernetes cluster. You can expose a health endpoint and monitor it:

kubectl get pods -n admiral
# NAME                       READY   STATUS    RESTARTS   AGE
# admiral-6d8b9f7c4-xk2p9   1/1     Running   0          3d

kubectl get svc -n admiral

If Admiral exposes a metrics or health port (often :8080), add it as a TCP monitor in Vigilmon:

1. Go to Monitors → New Monitor → TCP Port
2. Enter the node or load balancer IP and port for the Admiral health endpoint
3. Save the monitor

This catches Admiral controller crashes and restarts before they have time to cause routing degradation.

Step 5: Verify Admiral's ServiceEntry propagation

A useful pattern is to add a dedicated probe endpoint in each cluster that reports which cluster it's running in. This lets you verify Admiral is routing traffic to the right cluster:

# cluster-identity endpoint (example annotation in your service)
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-identity
data:
  cluster: "us-east-1"
  region: "us-east"

Your /health response can include this:

{
  "status": "ok",
  "cluster": "us-east-1",
  "admiral_route": "cross-cluster"
}

In Vigilmon, use the Response body contains check to assert which cluster is serving traffic. If Admiral misconfigures weights and traffic shifts to the wrong cluster, the body assertion fails and Vigilmon raises an alert.

Step 6: Configure alert channels

1. In Vigilmon, go to Alert Channels → Add Channel
2. Choose Email for immediate notification or Webhook for integration with Slack, PagerDuty, or Opsgenie
3. Assign alert channels to your Admiral monitors

When Vigilmon detects a cross-cluster routing failure, your team gets notified immediately. During incident response, check Admiral's logs to see if a sync error or API conflict caused the failure:

kubectl logs -n admiral -l app=admiral --tail=100 | grep -E "ERROR|WARN|sync|ServiceEntry"

Check whether ServiceEntry objects are current across clusters:

kubectl get serviceentry -A --context=cluster-us-east-1
kubectl get serviceentry -A --context=cluster-eu-west-1

Step 7: Create a status page for your mesh services

1. In Vigilmon, go to Status Pages → New Status Page
2. Name it "Multi-Cluster Mesh Services" or similar
3. Add all Admiral-related monitors grouped by cluster or service
4. Publish the page

Share the status page URL with your platform team and dependent service owners. When Admiral incidents happen, stakeholders can self-serve status instead of filing tickets.

Monitoring summary

| Monitor | Type | Purpose | |---------|------|---------| | https://my-service.example.com/health | HTTP | Global routing end-to-end | | Per-cluster IngressGateway IPs | HTTP | Cluster-specific gateway health | | Admiral controller health port | TCP | Controller liveness | | Response body cluster assertion | HTTP | Correct cluster is serving traffic |

What's next

• Heartbeat monitors — if you run Admiral sync jobs or custom controllers, use Vigilmon heartbeats to ensure they check in on schedule
• SSL certificate monitoring — Vigilmon tracks your IngressGateway TLS certs and alerts before they expire; critical in multi-cluster setups where cert-manager runs per cluster
• Latency tracking — Vigilmon's response time history helps you spot degraded cross-cluster routing before it becomes complete failure

Start monitoring your Admiral-managed mesh today at vigilmon.online — free tier, no credit card required.