Tink vs kube-proxy
kube-proxy watches Kubernetes Services and programs iptables, IPVS, or nftables so ClusterIP traffic moves. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.
kube-proxy programs VIPs. Tink answers “why is this VPS sick?”
Accidental sysadmins land on kube-proxy because every Kubernetes node runs it and every kube-prometheus diagram scrapes :10249. Then the volume fills, nginx dies, and the dataplane histograms stay green — the VPS was never a Service. A filling /var is a Tink warning; it is not a kube-proxy job unless the packet filter already knew.
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 kube-proxy if you already operate Kubernetes and need Service dataplane programming. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | kube-proxy |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — a cluster, a CNI, kube-proxy (or kube-proxy-free dataplane), scrape of :10249, and dashboards for sync latency |
| What you get | Working monitoring, diagnosis, and approved fixes | Service VIP programming. The box is still yours to diagnose and SSH |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Free software (Apache 2.0). You still pay for Kubernetes, Prometheus, Grafana, and the engineer who owns iptables vs IPVS |
| Hidden costs | None — fully managed | iptables rule explosion, IPVS conntrack, nftables mode, and a second tool that actually watches the Linux host |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | None on the OS — kube-proxy only programs ClusterIP/NodePort/LoadBalancer paths the API already defined |
| Configuration | None after install — heuristics and AI | mode (iptables/ipvs/nftables), conntrack, kubeconfig, and which kubeproxy_* series you actually graph |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | No — kube-proxy serves sync histograms. You still ssh and iptables-save to learn why traffic died |
| Fix execution | Proposes and executes approved commands with an audit trail | Dataplane only — kube-proxy cannot free disk, restart nginx, or rotate a cert |
| Alerting | Built-in across 8 channels | None — Prometheus must scrape :10249 and a PromQL rule must fire before anyone is paged |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Only if you already wrote a PromQL forecast on sync duration. kube-proxy does not predict host fill |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — kube-proxy does not read auth.log, journald, or host firewall state |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | A missing kube-proxy scrape is a Prom gap — only if Prometheus still runs and the node still answers |
| Public status page | Shareable URL with 90-day history | None — kube-proxy has no customer-facing status page |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — a kubeproxy_sync_proxy_rules dump is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire Prometheus into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | /metrics on :10249. No mechanic you text when /var filled on a VPS that is not in the cluster |
| Learning curve | None — works after install | Steep — Kubernetes Services, iptables vs IPVS, conntrack, Prometheus, and which dataplane metrics actually mean the box is sick |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Kubernetes and need Service dataplane series, not a sick-VPS mechanic |
When kube-proxy is the right choice
Keep kube-proxy when you already want that exact job:
- Kubernetes Service dataplane — you need ClusterIP/NodePort programming, not a mechanic on a quiet VPS.
- An existing kube-prometheus stack — scrape of :10249 and Grafana dashboards already exist, and someone owns iptables vs IPVS.
- Cluster-level questions — sync latency, conntrack, and endpoint programming matter more than host nginx, certs, and SSH.
- Hosts that only exist as Nodes — you already run Kubernetes, not a sick-box SSH loop.
The real cost of “just scrape kube-proxy”
kube-proxy is on every Kubernetes node. A working ops loop for five Linux boxes is not:
- A kubeproxy_sync_proxy_rules histogram still means you SSH in and change the box by hand
- Host fill, nginx, certs, and SSH brute-force never appear unless they are Services Prometheus already scraped
- A filling /var is a Tink disk warning on every scan — kube-proxy will stay quiet until the packet filter already knew
- A single VPS with no cluster still needs a mechanic, not an iptables mode flag
For a 5-server team, Tink Mechanic at $45/month is cheaper than kube-proxy plus the engineer who keeps Prometheus scrapes and iptables vs IPVS alive, and every scan includes a diagnosis a quiet :10249 /metrics dump will not type.
No iptables homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs kube-state-metrics · Tink vs Prometheus · Tink vs cAdvisor