Tink vs Flannel
Flannel is a Kubernetes overlay CNI. It also exposes flanneld subnet leases and overlay counters for Prometheus. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.
Flannel scrapes the overlay. Tink answers “why is this VPS sick?”
Accidental sysadmins land on Flannel because k3s and kubeadm tutorials ship VXLAN by default. Then the volume fills, nginx dies, and Grafana still shows a subnet lease — no PromQL matched host fill. A filling /var is a Tink warning; it is not a Flannel job unless the overlay itself is the failure.
Tink is the other job: detect the issue on the machine, say why it happened in plain English, propose the command, and run it only after you approve. Keep scraping Flannel if you already operate Kubernetes and need overlay SLOs. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | Flannel |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — kube-flannel DaemonSet, pod CIDR, VXLAN/host-gw backend, and prometheus.yml scrape |
| What you get | Working monitoring, diagnosis, and approved fixes | An overlay scrape target. Host disk fill, nginx, Postgres, and certs stay your problem until PromQL fires and you SSH in |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Open-source Flannel is free. You still pay Prometheus, Grafana, and the engineer who owns the overlay |
| Hidden costs | None — fully managed | flanneld lease churn, a full VXLAN interface, backend flaps, and a second tool to tell you the box is sick |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | flannel_overlay_errors and subnet lease gauges. Flannel does not watch host fill or a quiet cert unless you added another exporter |
| Configuration | None after install — heuristics and AI | pod CIDR, backend type, kube-subnet-mgr, and which PromQL actually pages you |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | You graph flannel_subnet in Grafana, then SSH in to change the box |
| Fix execution | Proposes and executes approved commands with an audit trail | Metrics only — Flannel cannot free disk, restart nginx, or rotate a cert |
| Alerting | Built-in across 8 channels | Not a Flannel job — Prometheus rules and Alertmanager have to fire |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Not a Flannel job — an overlay scrape does not forecast a quiet volume filling up |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — Flannel does not read auth.log, journald, or host firewall state |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | Silence if the agent dies — unless you built an up{job="flannel"} deadman check |
| Public status page | Shareable URL with 90-day history | None — Flannel has no customer-facing status page |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — a flanneld scrape target is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire Alertmanager into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | kubectl logs on kube-flannel and Grafana. No mechanic you text when /var filled and pods still got a subnet |
| Learning curve | None — works after install | Steep enough — VXLAN vs host-gw, lease renewal, MTU, and which overlay error actually pages |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Kubernetes and need Flannel overlay scrapes, not a sick-VPS mechanic |
When Flannel metrics are the right choice
Keep scraping Flannel when you already want that exact job:
- Kubernetes overlay SLOs — you need subnet leases, VXLAN/host-gw health, and overlay error counters, not a mechanic.
- Simple pod networking at cluster scale — flanneld, kube-subnet-mgr, and MTU matter more than host nginx, certs, and SSH on a quiet VPS.
- An existing Prometheus + Grafana stack — kube-flannel already runs, flanneld already scrapes, and someone owns the overlay.
- Hosts that only page on Flannel — you already run exporters and PromQL, not a sick-box SSH loop.
The real cost of “just scrape Flannel”
Flannel is the default overlay in a lot of first clusters. A working ops loop for five Linux boxes is not:
- A healthy flannel subnet lease still means you SSH in and change the box by hand
- Host fill, nginx, certs, and SSH brute-force never appear unless Prometheus scraped those signals and a rule fired
- A filling /var is a Tink disk warning on every scan — Flannel will stay quiet until the overlay itself is the failure
- A single VPS with a dead kube-flannel still needs a mechanic, not another CNI scrape
For a 5-server team, Tink Mechanic at $45/month is cheaper than Flannel plus the engineer who keeps Prometheus scrapes and overlay error rules alive, and every scan includes a diagnosis a quiet Grafana board will not type.
No VXLAN homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs Calico · Tink vs Cilium · Tink vs Prometheus