Column

Every list of Kubernetes benefits reads the same way: self-healing, horizontal scaling, portability across clouds, no vendor lock-in. All of that is true. What the lists leave out is the condition attached to every one of them — someone has to build and keep running the control plane, the autoscalers, the CI/CD pipeline, and the upgrade process that make those benefits real. If nobody does that work, "self-healing" quietly becomes "paged at 2 a.m."

That's the actual decision facing most teams that are past the "should we use Kubernetes" question and into the "who runs it" question: do you get those benefits by running the cluster yourselves, or by paying someone to run it so the benefits show up without the operational weight behind them?

What self-healing and autoscaling actually require from you

Kubernetes doesn't restart a crashed pod because it's smart by default — it does it because a controller is watching the declared state and reconciling against it, continuously. The same is true for scaling: a Horizontal Pod Autoscaler doesn't know your application needs more replicas unless something is feeding it the right metrics and someone has set sane thresholds, cooldown windows, and resource requests. Get those wrong and autoscaling either does nothing during a traffic spike or flaps pods up and down in a way that makes things worse, not better.

Kubo's built-in autoscaling with HPA, VPA, and KEDA walks through exactly how much tuning sits behind "the cluster scales itself" — metric sources, scaling policies, and the gap between CPU-based and event-driven autoscaling. Read it with the self-managed path in mind: every one of those steps is something your team either configures once on a managed platform, or owns forever on your own cluster.

Self-healing has a second, quieter requirement too: it only protects you from failures the system already knows how to detect. A node silently running out of disk, a misconfigured liveness probe that never fails, or a control plane component that degrades without crashing — those don't get self-healed. They get discovered by whoever is watching the cluster, which again is a person, not a feature.

The failure mode here is rarely dramatic. It's an HPA target set to 80% CPU on a workload that's actually memory-bound, so the autoscaler never fires during the one traffic spike it was supposed to handle. Or a liveness probe pointed at the wrong port after a refactor, quietly restarting a healthy pod in a loop for weeks before anyone notices the error budget draining. These aren't Kubernetes failing — they're Kubernetes doing exactly what it was configured to do, which is the entire point: the benefit only exists if the configuration behind it is correct and kept correct as the application changes.

The parts of the stack nobody mentions until they're broken

The benefits pitch usually stops at the scheduler. The actual list of things a self-managed cluster needs is longer: a CI/CD pipeline that builds images, runs checks, and deploys safely; TLS and ingress; a monitoring and alerting stack that catches problems before users do; and a plan for upgrading Kubernetes itself every few months without downtime.

None of that is exotic — it's documented, well-understood work — but it's also where most of the "hidden cost" of self-hosting actually lives. Building a Kubernetes CI/CD pipeline with GitHub Actions is a good example of what "just deploy it" turns into in practice: service accounts, image registries, rollout strategies, and secrets management, all before a single feature ships.

Teams coming from a simpler setup feel this most acutely during the move itself. Migrating from Docker Compose to Kubernetes means translating a single docker-compose.yml into Deployments, Services, ConfigMaps, and Secrets — and then building the ingress, health checks, and scaling rules that Compose never asked for. The migration guide is useful precisely because it makes that gap concrete: a working Compose file and a production-ready Kubernetes setup are not the same amount of work, even when they run the same containers.

Then there's the upgrade treadmill. Kubernetes ships a new minor version roughly every four months, and the Kubernetes project only supports the most recent three. Falling behind isn't a one-time inconvenience — it compounds, because deprecated APIs get removed, not just deprecated, and a cluster that's two versions behind can turn a routine upgrade into a weekend of rewriting manifests. Someone has to track that calendar, test upgrades in a staging environment, and schedule the maintenance windows. It's necessary work, and it's also work that produces zero new features for users.

This is where most teams stall: the application is ready to run on Kubernetes, but self-hosting means standing up ingress, TLS certificates, a CI/CD pipeline, and monitoring before any of the advertised benefits actually show up for users. Kubo gives you standard Kubernetes with that plumbing already wired — closer to the workflow of a managed platform, without locking you into one vendor's APIs.

So who actually captures the benefits?

Self-managing Kubernetes is a legitimate choice, and plenty of teams make it work — but it works because someone on the team treats cluster operations as real, ongoing responsibility, not a one-time setup task. If you have that person or that team already, the benefits in the list at the top of this article are genuinely yours to keep, and you're not the audience for a managed platform.

If you don't — if "who's on call for the cluster" doesn't have a clean answer, or the honest plan is "we'll figure out upgrades when we get there" — then self-managing doesn't actually deliver self-healing, scaling, or portability. It delivers the promise of those things, with the operational work as an unpaid prerequisite. A managed platform doesn't remove Kubernetes' benefits; it removes the condition attached to them, by having someone else run the control plane, the autoscalers, and the upgrade process as their job.

There's also a cost that doesn't show up on an invoice: the opportunity cost of whoever ends up owning the cluster. On a small team, that's usually a backend engineer who could otherwise be shipping product features, not debugging why a node pool won't drain. The hourly rate for that time is almost always higher than the monthly difference between a self-hosted node and a managed plan — it's just easier to see the second number than the first.

Choosing the version you can actually run

If you're a solo developer or running a small project, the Ashigaru plan starts at ¥8,800/month; most small to mid-size teams land on Ronin at ¥17,600/month. Both give you standard Kubernetes — the same APIs, the same manifests, the same ecosystem of tools — with the autoscaling, ingress, and upgrade operations already handled. Compare the plans and start with the one that matches your team's current workload, not the one you'd need once you've also hired someone to run the cluster.