From Plesk to Kubernetes
You've run a Plesk / cPanel setup for years. You know what a vhost is. You've clicked "add domain", you've opened phpMyAdmin, you've scheduled a cron job from a web form. Good news: everything you already know still has a name here. You're just going to read YAML instead of clicking dropdowns, and the system watches a Git repo instead of a hosting panel's database.
New to the Kubernetes terms below? The glossary maps each one onto its Plesk equivalent in a single table.
This page is the welcome mat. The rest of the Concepts section builds on it.
What stays the same
- There's still one website per customer. We still call them "clients". Today we have one — wecare — and more will come.
- Each site still has a database, a cache, an app runtime, and a way to expose HTTP to the internet. MariaDB, Redis, PHP-FPM + nginx, Traefik + Cloudflare. Same pieces, different names.
- Backups still happen on a schedule. Hourly physical backups + daily SQL dumps, same as you'd expect.
- When something breaks, you read logs. Same instinct, slightly different tooling (Grafana + Loki instead of tailing
/var/log/nginx/*).
What changes
- Nothing lives on a single server anymore. Pods (containers) float across a fleet of Hetzner Cloud VMs, scheduled by Kubernetes. You don't SSH into "the web server" — there isn't one. You query the cluster.
- Configuration is a Git commit, not a form submission. Want to change wecare's PHP memory limit? You edit a YAML file, commit, push. A process called ArgoCD notices the change within a minute and applies it.
- Secrets are encrypted in the repo. The password for wecare's database is literally sitting in the Git history — but encrypted so only the cluster can decrypt it. This is called Sealed Secrets.
- "The server" scales itself. When traffic grows, more pods spin up automatically (KEDA). When that exhausts the fleet, more VMs get created (cluster-autoscaler). You mostly watch this happen.
Plesk → Kubernetes cheat-sheet
| What you called it in Plesk | What it's called here | Where to read more |
|---|---|---|
| Adding a new domain | Onboarding a client | Runbook |
/var/www/html/ | PersistentVolumeClaim ("PVC") | Primer |
| Apache/nginx vhost | Ingress + Service | Ingress |
| Cron in Plesk's UI | CronJob YAML | Primer |
| phpMyAdmin | Exec into the MariaDB pod with mysql, or port-forward phpMyAdmin from the cluster | Coming soon |
| Cron logs tail | Loki in Grafana | Observability |
| Changing PHP settings via Plesk form | Editing a ConfigMap YAML + commit | Deploy an update |
| "FTP the site up" | docker push a new image tag, commit new tag to repo | Deploy an update |
A full glossary with external reading links lives at Reference → Glossary.
The mental flip
Plesk was imperative: you clicked a button, the system did the thing right now, and state lived in Plesk's database.
This setup is declarative: you describe "this is what should exist", commit it, and a controller continuously makes reality match the description. If you change reality directly (e.g., kubectl delete something) without updating the repo, the controller re-creates the thing within a minute.
The repo is the truth. Remember that one sentence; it explains most of the day-to-day.
When to worry vs. when not to
- 🟢 Don't worry about what node a pod lands on — K8s decides.
- 🟢 Don't worry about starting/stopping services — controllers do it.
- 🟢 Don't worry about typing commands to restart things — usually it's "edit the YAML, commit, push, done".
- 🟠 Do worry when you see
kubectl applyorkubectl editused as a verb in chat — that's an imperative change that ArgoCD will revert within minutes. - 🔴 Do worry when Grafana goes red or the Google Chat alert channel fires — that's the signal to open the runbook.
Next up
Read the Kubernetes primer next to learn the 7 concepts that cover 90% of what you'll see. It's intentionally short.