Category: PaaS and containers
Managed Kubernetes on your provider: EKS, GKE, AKS, Hetzner or your own servers
Your Kubernetes cluster, on the provider you already use, with someone who upgrades it on time, knows how to restore it and keeps an eye on what it costs.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
In short
Managed Kubernetes, in our case, means administering your Kubernetes cluster in your own account: EKS, GKE, AKS, DOKS, OVH, Hetzner or your own servers. We take care of version and node upgrades, add-ons, ingress and certificates, autoscaling, GitOps deployment, observability, Velero backups and their tested restore, costs and security.
What do we take care of in your cluster?
A Kubernetes cluster is not finished the day it is created. Every few months there is a new version, add-ons go out of date, certificates are renewed and spending grows without anyone deciding it. This is what we maintain:
Versions and nodes
We upgrade the control plane, renew the node groups and remove APIs that are going away before they break a deployment.
Add-ons
CNI, CSI, CoreDNS, metrics-server, cert-manager and the ingress controller, in versions compatible with the cluster.
Ingress and certificates
Incoming traffic, certificates that renew themselves and DNS records managed from the cluster.
Autoscaling
HPA for pods and Cluster Autoscaler or Karpenter for nodes, with realistic resource requests.
GitOps
Argo CD or Flux: every change goes in through the repository and can be reverted.
Observability
Prometheus, Grafana and centralised logs, with alerts that come with their runbook.
Backups
Velero with resources and volumes outside the cluster, and a restore we have tested.
Costs
Right-sizing of nodes and workloads, cleanup of orphaned resources and review of egress traffic.
Security
RBAC, network policies and pod admission, which we go into in Kubernetes hardening.
Managed control plane or your own cluster?
The first decision is who maintains the API and etcd. On EKS, GKE, AKS, DOKS and OVH the provider does; with k3s, Talos or kubeadm on Hetzner or on your servers, we do. If you are interested in Hetzner specifically, we explain it in Kubernetes on Hetzner. Neither option is better in the abstract:
| Criterion | Managed control plane (EKS, GKE, AKS, DOKS, OVH) | Self-managed (k3s, Talos, kubeadm on Hetzner or your own servers) |
|---|---|---|
| Who maintains the API and etcd | The provider | Us, with etcd backups and high availability |
| Infrastructure cost | Higher, especially in traffic and add-on services | Lower, with more operational work |
| Cloud integration | Deep: identities, load balancers, volumes | Whatever the provider’s CCM and CSI give, or none on your own servers |
| Version pace | Set by the provider’s support calendar | Set by you, without letting it expire |
| When we recommend it | You are already on that cloud, or need its managed services | Steady workloads, tight costs or data that must stay on your machines |
Which problems do we find when we inherit a cluster?
- Versions adrift: the control plane on one version, the nodes two behind and the add-ons untouched since they were installed.
- Postponed upgrades: nobody dares to upgrade because something broke last time, and the cluster is approaching end of support.
- Spending that grows by itself: large half-empty nodes, test environments left on overnight and volumes from pods that no longer exist.
- No runbooks: the alerts go off, but nothing is written down about what to do, and only one person knows how it was set up.
- Untested backups: Velero installed, but nobody has ever restored a complete namespace.
- Changes by hand: what is in the cluster no longer matches the repository.
How do we carry out a version upgrade?
Kubernetes only allows a limited version difference between the API and the nodes’ kubelets, and the control plane is upgraded one minor version at a time. That is why we always work with the same procedure:
Review
We look for the deprecated APIs your manifests and charts use, and check which version of each add-on supports the target version.
Rehearsal
We first upgrade a test or staging cluster with the same workloads.
Control plane
We go up one minor version, and only one, in the window agreed with you.
Nodes
We renew the node groups by draining them one at a time, respecting each application’s disruption budgets.
Check
We review alerts, deployments and certificates, and note down what changed and what is left for next time.
How do we know the backups work?
A Kubernetes backup that has never been restored is an assumption. We configure Velero to store resources and volumes in object storage in another account or with another provider, and every so often we restore a complete namespace on a separate cluster to check that the applications start with their data. For databases with a lot of data we prefer their own backup system, as we explain in managed PostgreSQL.
What if we want to change provider?
Moving a cluster between EKS, GKE, AKS or another provider is above all an inventory job. What has to be translated are the pieces specific to each cloud: storage classes, load balancer annotations, workload identities, secrets and managed databases. With the cluster in GitOps, the new one is brought up in parallel from the same repository, the data is moved with Velero or with replication and traffic is switched service by service. Before starting we compare costs against your real bills in cloud migrations and costs.
What does day-to-day support look like?
Every month you receive a report with versions, incidents, spend and the latest test restore. If you are looking for something broader than the cluster, we include it in SRE as a service.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Hetzner
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| AWS | EKS with managed node groups or Karpenter, AWS Load Balancer Controller, EBS CSI and per-pod IAM permissions. | EKS versions have an end-of-standard-support date; after that date, extended support is charged separately. |
| Google Cloud | GKE Standard or Autopilot, with a chosen release channel and defined maintenance windows. | Google upgrades the control plane on its own: what matters is that the channel and windows fit with your deployments. |
| Azure | AKS with system and user node pools, automatic upgrades configured and workload identity with Microsoft Entra ID. | It is worth separating the node pools so that the application ones can be renewed without touching the system ones. |
| DigitalOcean | DOKS with node autoscaling, DigitalOcean load balancers and volumes. | |
| OVH | OVHcloud Managed Kubernetes Service, with Public Cloud nodes and block storage. | |
| Hetzner | No managed Kubernetes: we set up the control plane with k3s, Talos or kubeadm, integrated with Hetzner load balancers and volumes. | Lower infrastructure cost in exchange for also running the control plane. |
| Own server | k3s, Talos or kubeadm on your servers or on virtual machines, with your own load balancer and storage. | The hardware, the network and persistent storage become part of the job. |
What is included
- Cluster inventory: version, add-ons, workloads, permissions and whatever is not in code.
- Upgrade schedule for Kubernetes, the nodes and the add-ons, without skipping minor versions.
- Ingress, automatic certificates and external DNS reviewed and in the repository.
- Pod and node autoscaling with requests and limits matched to real usage.
- GitOps deployment with Argo CD or Flux, with the cluster state in Git.
- Metrics, logs and alerts for the cluster and the applications, with a runbook for each alert.
- Velero backups outside the cluster and a documented test restore.
- Cost review: oversized nodes, orphaned volumes, forgotten load balancers and traffic.
Frequently asked questions
If we already pay for EKS, GKE or AKS, what is left to manage?
Almost everything that is not the control plane: the nodes, the add-ons, the ingress, the certificates, the backups, the permissions, the alerts and the spend. The provider maintains the API and etcd; what runs on top is still yours.
How often does Kubernetes need upgrading?
Kubernetes publishes a minor version roughly every four months and maintains patches for the three most recent ones. In practice, a production cluster needs a planned upgrade two or three times a year so that it does not fall out of support.
Do you work in our account or in yours?
In yours. The cluster, the billing and the code are yours; we log in with named access that you can revoke. If we ever stop working together, everything keeps running and is documented.
Is Kubernetes worth it for our team?
If you have few applications and nobody to run it, often not. A self-hosted PaaS or a few well-managed servers cover many cases with fewer pieces. We tell you before setting anything up.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
- Kubernetes: version skew policy between components (Version Skew Policy)
- Velero: restore reference (official documentation)
Reviewed on