Pluto is the Fairwinds tool that scans Helm releases, manifests, and live clusters for deprecated and removed Kubernetes API versions — catching the API drift that causes cluster upgrade failures before they hit production. When the Pluto binary is missing from your CI runners, deprecated API checks silently disappear from your pipeline: pull requests merge without catching resources that will break on the next Kubernetes minor version upgrade. When you run Pluto as a web service or integrate it with a dashboard, availability gaps mean your security and compliance posture reports go stale. Vigilmon gives you a monitoring layer around Pluto's operational infrastructure — CI artifact hosting, any API dashboard surfaces, and the certificates that keep them trusted.
What You'll Build
- An HTTP monitor on a Pluto artifact server or release endpoint to detect binary unavailability
- A TCP check confirming CI-accessible Pluto infrastructure is reachable
- SSL certificate monitoring for any Pluto-fronted web services or dashboards
- A runbook table mapping Vigilmon alerts to specific pipeline remediation steps
Prerequisites
- Pluto v5.0.0+ installed in your CI pipeline or as a container image
- A Kubernetes cluster with Helm releases to scan
- Optionally: a Pluto dashboard or API service (e.g., Fairwinds Insights integration)
- A free account at vigilmon.online
Step 1: Understand Pluto's Operational Footprint
Pluto is primarily a CLI tool — it runs as a binary in CI pipelines and produces exit code 1 when deprecated APIs are found. Its operational surface includes:
# Run Pluto against the live cluster
pluto detect-all-in-cluster
# Scan a specific namespace
pluto detect-all-in-cluster -n production
# Scan Helm releases
pluto detect-helm -owide
# Check against a specific target version
pluto detect-helm --target-versions k8s=v1.32.0
# Output in JSON for CI parsing
pluto detect-all-in-cluster -o json
For monitoring purposes, Pluto's availability concerns break into two categories:
-
Binary availability: The Pluto release artifact must be downloadable to CI runners. If GitHub Releases or your internal artifact mirror goes down, CI jobs that install Pluto on boot will fail.
-
Dashboard/API availability: Teams using Fairwinds Insights or a self-hosted Pluto web service need that endpoint to be up for compliance reports.
Step 2: Monitor the Pluto Release Artifact Endpoint
If your CI pipelines download Pluto at job start (common in ephemeral runner environments), the download endpoint is a hard dependency. Your internal artifact mirror or proxy is typically more relevant to monitor than the upstream GitHub URL, since you control its SLA:
# Typical CI installation pattern
PLUTO_VERSION="v5.21.0"
curl -L https://artifacts.example.com/pluto/${PLUTO_VERSION}/pluto_linux_amd64.tar.gz -o pluto.tar.gz
tar xzf pluto.tar.gz
chmod +x pluto
./pluto detect-helm
To monitor your internal artifact mirror:
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://artifacts.example.com/pluto/health(or a specific release tarball URL that returns a known status). - Check interval: 5 minutes.
- Response timeout: 15 seconds.
- Expected status:
200. - Label:
Pluto artifact mirror. - Click Save.
If you use a checksum verification file as your health probe:
# Use the SHA256SUMS file as a lightweight availability check
curl -I https://artifacts.example.com/pluto/v5.21.0/SHA256SUMS
# Should return 200 with Content-Length > 0
This monitor catches:
- Internal artifact mirror outages that break CI job startup
- Network partition between CI runner network and artifact storage
- Storage backend failures that return
503or empty responses - Nginx/proxy configuration changes that accidentally block the
/pluto/path
Step 3: Monitor a Pluto-Integrated Dashboard (Fairwinds Insights)
Teams using Fairwinds Insights get a hosted dashboard where Pluto findings are aggregated across clusters and namespaces. If you self-host any Insights components or a custom Pluto reporting service, those endpoints need availability monitoring:
# Verify your Pluto reporting service is up
curl https://pluto-dashboard.example.com/api/health
# Expected: {"status": "ok"}
# Check report generation endpoint
curl https://pluto-dashboard.example.com/api/v1/reports/latest
In Vigilmon:
- Add Monitor → HTTP.
- URL:
https://pluto-dashboard.example.com/api/health. - Check interval: 2 minutes.
- Response timeout: 10 seconds.
- Expected status:
200. - Keyword:
okorstatus(depending on your response format). - Label:
Pluto dashboard API. - Click Save.
Report freshness vs. availability: Vigilmon checks whether the endpoint responds — not whether the Pluto reports inside it are up-to-date. For freshness monitoring, add a second HTTP check on a
/reports/latestendpoint and verify thetimestampfield in the response is within your expected scan interval.
Step 4: Monitor the Pluto CI Webhook or Status API
If you've integrated Pluto findings into a status API that GitHub Actions or GitLab CI queries to gate pull request merges, that API needs uptime monitoring:
# Example GitHub Actions step that checks Pluto status API
- name: Check deprecated APIs
run: |
RESULT=$(curl -sf https://pluto-status.example.com/api/v1/check \
-H "Authorization: Bearer $PLUTO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"cluster": "production", "namespace": "default"}')
echo "$RESULT" | jq -e '.deprecated_count == 0'
Monitor this status API endpoint:
- Add Monitor → HTTP.
- URL:
https://pluto-status.example.com/api/v1/health. - Check interval: 2 minutes.
- Response timeout: 10 seconds.
- Expected status:
200. - Label:
Pluto status API. - Click Save.
When this monitor fires, PRs that rely on the status gate will fail with curl: (7) Failed to connect rather than producing meaningful Pluto output — engineers see CI failures without understanding the root cause.
Step 5: Run Pluto in Your CI Pipeline for Cluster Health Gating
Beyond monitoring Pluto's own infrastructure, integrate Pluto into your deployment pipeline so deprecated API detection is automatic:
# .github/workflows/pluto-check.yml
name: Deprecated API Check
on:
pull_request:
branches: [main]
schedule:
- cron: '0 6 * * 1-5' # Daily on weekdays
jobs:
pluto-scan:
runs-on: ubuntu-latest
steps:
- name: Install Pluto
run: |
wget https://artifacts.example.com/pluto/v5.21.0/pluto_linux_amd64.tar.gz
tar xzf pluto_linux_amd64.tar.gz
chmod +x pluto
sudo mv pluto /usr/local/bin/
- name: Scan Helm releases
run: |
pluto detect-helm \
--target-versions k8s=v1.32.0 \
--ignore-deprecations \ # Only fail on removals
-o json > pluto-results.json
cat pluto-results.json | jq '.items[] | select(.removed == true)'
- name: Fail on removed APIs
run: |
REMOVED=$(cat pluto-results.json | jq '[.items[] | select(.removed == true)] | length')
if [ "$REMOVED" -gt 0 ]; then
echo "ERROR: $REMOVED removed API(s) found — upgrade will fail"
exit 1
fi
This pipeline check is the primary value of Pluto. Vigilmon monitors that the infrastructure supporting this check is available — so you know when the check itself starts silently skipping.
Step 6: Monitor SSL Certificates
Any Pluto web service or artifact endpoint you expose over HTTPS needs certificate monitoring:
# Check your artifact mirror certificate
openssl s_client -connect artifacts.example.com:443 2>/dev/null | openssl x509 -noout -dates
# Check your Pluto dashboard certificate
openssl s_client -connect pluto-dashboard.example.com:443 2>/dev/null | openssl x509 -noout -dates
In Vigilmon:
- Add Monitor → SSL Certificate.
- Domain:
artifacts.example.com. - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Repeat for pluto-dashboard.example.com and any other Pluto-related domains.
CI certificate trust: CI runners that install Pluto from HTTPS sources verify the server certificate using the system CA bundle. An expired or misconfigured certificate on your artifact mirror causes CI jobs to fail with
SSL certificate problem: certificate has expired— and all deprecated API checks stop running silently.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action |
|---|---|---|
| Artifact mirror | Non-200 or connection error | CI jobs will fail to install Pluto; check artifact storage; pin to a local copy |
| Dashboard API | Non-200 or keyword missing | Reports unavailable; check dashboard service; use pluto detect-all-in-cluster directly |
| Status API | Non-200 | CI gates will fail; disable required status checks temporarily while investigating |
| SSL certificate | < 30 days to expiry | Renew certificate; check cert-manager or manual renewal process |
Alert routing: Route artifact mirror and SSL alerts to the platform team. Route dashboard API alerts to the security/compliance team who owns the reports.
Common Pluto Infrastructure Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Internal artifact mirror goes down | HTTP monitor fails; CI jobs cannot install Pluto binary | | Dashboard service OOM killed | Dashboard API returns 502; compliance reports become stale | | SSL certificate expires on artifact mirror | HTTP monitor returns SSL error; all CI Pluto installs fail | | Status API database connection lost | Status API returns 500; PRs silently fail or skip the deprecated-API gate | | Network partition between CI and artifact storage | TCP or HTTP check times out; mirrors the exact failure CI runners experience | | Helm chart upgrade removes the Pluto container image tag | Pluto scans stop; not caught by external monitoring — use image tag pinning | | Pluto API token expires | Status API returns 401; requires token rotation |
Pluto catches the deprecated API drift that causes Kubernetes cluster upgrade failures — but only when it's actually running in your CI pipelines. Vigilmon monitors the artifact hosting, dashboard services, and SSL certificates that keep Pluto operational, so you're not discovering that deprecated API checks have been silently skipping for two weeks right before a major cluster upgrade.
Start monitoring your Pluto infrastructure in under 5 minutes — register free at vigilmon.online.