Selectel Managed Kubernetes: where infrastructure breaks
A Managed Kubernetes cluster in Selectel comes up in minutes, so the first problems become noticeable not at launch but on the third or fourth release.
The configuration becomes overgrown with edits made by hand directly in prod: someone adjusted container limits, someone added a node via the panel. A month later no one can reproduce the working state—and any update turns into an experiment on live traffic.
The most expensive bottleneck is nodes without reserve. When there is one pool and load grows in a jump (launch, season, advertising campaign), new pods go into pending and some requests fail.
If pod disruption budgets and readiness probes are not set, a scheduled node image update removes several service instances at once—the user sees errors where no one changed anything.
Unpredictable growth finishes it off: autoscaling without warmed nodes and correct resource requests reacts with a delay of several minutes, and it is during those minutes that availability is lost.
Manual edits in prod also break rollback: cluster state diverges from the repository, and during an incident it is unclear which version to return to. The price is the same—unplanned downtime, which costs more than the infrastructure itself.
We break down how this is closed: configuration as code in Terraform, pools with reserve for peaks, and a GitOps loop where manual editing is physically impossible.
What a managed cluster gives in daily operations
A managed cluster covers the layer of work that does not create the product: control plane updates, replacement of failed nodes, certificate rotation, diagnostic collection.
Selectel is responsible for this on its side, while we describe the configuration declaratively—the infrastructure state lives in the repository and is reproduced repeatedly, without manual edits on the live environment.
The speed of bringing up environments changes by an order of magnitude: a site for version validation comes up in minutes and receives the same dependencies as the production environment.
Autoscaling under load works by rules, not by a call to the on-call engineer. The worker node pool expands when CPU utilization and the number of tasks in the queue stay above the threshold longer than a specified window, and shrinks back when traffic subsides.
A morning spike or a sale stops turning into a queue of requests, and during quiet hours the cluster does not hold idle resources.
A separate effect is managed behavior during failures. If a node fails, the load moves to live ones, and readiness checks do not let traffic through to an unhealthy application instance.
Service recovery time is measured in seconds and does not depend on whether anyone managed to see the notification; an unsuccessful release is rolled back from version history.
Downtime reduction is achieved not by the heroism of the on-call engineer, but by the platform extinguishing typical failures before the user notices them.
In operations, this looks like identical rules across all environments, reproducible configuration, and predictable reaction to a peak—instead of manual operations that depend on who is on shift today.
Deployment options: managed nodes or your own
Choosing a scheme in Selectel Managed Kubernetes is not an argument of "cloud or your own servers," but three different distributions of responsibility.
It determines who handles node updates, how the pool scales under load, and how deeply you can influence pod placement.
Managed node groups cover the typical case: the platform handles the lifecycle of machines, updates, and autoscaling by metrics, while we describe the composition of groups declaratively and keep the configuration in Git.
Your own nodes inside the cluster are needed when special images, local disks, or strict placement rules are required. A hybrid is connected when part of the environment—databases, brokers, legacy services—remains outside the cluster.
| Option | When it fits | Limitations |
|---|---|---|
| Fully managed platform | Typical services without special requirements for image and disk | Host settings are closed, updates follow the platform schedule |
| Your own nodes inside the cluster | Your own images, local disks, special placement rules | We take on updates and replacement of failed machines |
| Hybrid: part of the load outside the cluster | Services that cannot be moved quickly | Two areas of responsibility, shared monitoring and network access are configured separately |
We check platform limitations before choosing a scheme: quotas for pools, available node configurations in the zone, network policies, and the fact that the control layer is closed to intervention. Taken into account in advance, they do not force a cluster rework as load grows.
Implementation order: from audit to handover to support
The order of work is fixed: each step relies on the artifacts of the previous one, so a stage cannot be skipped without losing the result. Below is how managed Kubernetes implementation on Selectel proceeds: from inventory to handover to operations.
-
Infrastructure audit. We collect an inventory: which services run, peak loads and traffic profile, external dependencies, who owns access, where single points of failure currently are. The result is a map of the current state and a list of risks that we close before migration.
-
Cluster design. We define node pools for different types of load, distribution across availability zones, quotas, network topology, storage, and update policy. We agree on the design before deployment: edits at the design stage are cheaper than edits in a running environment.
-
Deployment. We describe the cluster and pools in Terraform, keep service manifests in a Git repository, and roll them out via GitOps. We enable autoscaling immediately—both at the node level and at the pod level, with different reactions to smooth growth and a sharp spike.
-
Fault tolerance testing. We take down a node and an entire zone, measure pod rescheduling time and autoscaler behavior under a load profile. We close the bottlenecks found before acceptance, not during operations.
-
Work acceptance. Checklist: monitoring and alert coverage, backups with verified recovery, role-based access, logs, compliance with the agreed design. We record metrics before and after—response time, downtime, rollout speed.
-
Handover to support. We provide the standard operations regulations, cluster design, rollout and policy descriptions, access by roles. We walk the on-call shift through updates and rollbacks so the team can work without us going forward.
What remains in the repository and documentation
We hand over a cluster on Selectel Managed Kubernetes not as panel access, but as a repository from which the infrastructure is reproduced in full.
Our team leaves, but your engineers still have a working description of configurations, access policies, and regulations—using them, the platform can be developed and incidents can be investigated without us.
- Infrastructure as code: the cluster, node pools, networks, and load balancers are described declaratively, the state is brought up from scratch in one sequence, and changes go through review before application.
- Autoscaling settings: trigger thresholds, minimum and maximum nodes, behavior at peak load, and scale-down rules—it is visible why the cluster expands exactly this way.
- GitOps configuration description: directory structure, environment binding, the procedure for reconciling discrepancies between the repository and live state.
- Access policies: roles and bindings, separation of rights between teams and service accounts, abandonment of shared keys and manual exceptions.
- Cluster designs: topology, traffic paths, placement across availability zones, points whose failure does not bring down the service.
- Cluster documentation: how to deploy from scratch, how to update a major version, how to collect diagnostics, and what to look at first during a failure.
- Support regulations: update frequency, maintenance windows, incident response procedure, and the boundaries of responsibility of the parties.
- Rules for working with secrets: where values are stored, how they are rotated, and who has access—the values themselves are not in the repository.
Case: migrating a loaded service without downtime
A service with daily peak load lived on three dedicated machines: deployment was done by hand, and rollback took an evening.
During sale hours, the order processing queue grew, and the on-call engineer manually brought up another machine—according to an instruction that no one had updated for a long time.
We moved the environment to Selectel Managed Kubernetes: the application was packaged into containers, secrets and configurations were moved into declarative manifests, and the cluster state was described in Terraform.
Traffic was migrated gradually—5% of requests to the new environment, then 25, 50, and 100%. At each step we compared the error rate and response time, and if there was a deviation, the weight returned back within minutes.
What changed in the metrics
- Version deployment time: from 40 minutes of manual steps to 6 minutes of an automated pass.
- Rollback to the previous version: from an evening to one weight switch, less than two minutes.
- Fault tolerance: when a node fails, containers move to free ones, and the error rate at peak dropped by about four times.
- Peak load: nodes are added by schedule and metrics in advance, not when the queue has already grown.
Autoscaling thresholds and container eviction rules were configured based on actual measurements, not a reference book. Reserve for peaks appeared, and manual on-call duty for engineers went away.
Kubernetes by hand or a managed service
A managed service—for example, Selectel Managed Kubernetes—takes over the control layer: master nodes, cluster state storage, version updates, certificate rotation, recovery after zone failure.
What remains on the team's side is what describes workloads: manifests, access policies, limits, network rules—and this does not depend on the option.
A self-managed cluster is justified when the platform does not cover requirements: your own node images with kernel patches, non-standard admission controllers, strict pinning to specific versions.
The price for this is ongoing operations—updates with manual window selection, on-call duty, state backups, network incident investigation.
| Area | Kubernetes on your own | Managed service |
|---|---|---|
| Master nodes and cluster state | we install, patch, restore ourselves | on the platform side |
| Version updates | manually, with a downtime window | in stages, with rollback |
| Zone failure | your own on-call shift, your own instructions | handled by the platform |
| Node autoscaling | your own rules and metrics | built-in plus your own rules |
| Network, balancing, disks | integrations for the task | ready-made, within the catalog |
| Workloads and access policies | our team | our team |
A hybrid is chosen more often: a managed control layer plus your own node pools described in Terraform together with the network and access rights.
The platform is responsible for master node fault tolerance, while the team controls runtime versions, workload placement, and the update procedure.
Technical doubts before starting work
Before starting, they check not tools but risks: what will happen to an already running cluster, who holds access, and how to roll back changes. Below are answers to frequent questions from the evaluation stage, including working with the Selectel managed service.
Can a running cluster be migrated without downtime?
We bring up the target cluster, deploy workloads from manifests, verify services, and only then switch external traffic. Downtime is minutes for the switch, and the old environment remains open as a path back.
How do platform updates proceed?
We update in waves by node groups: first the service pool, then the worker ones. Before eviction, workloads move to healthy nodes, so there is no overall downtime, and we check compatibility with the target version in advance.
How is access granted and where are secrets stored?
We distribute by roles through a single authentication provider, without one-off keys for each engineer. Secrets are stored in a protected vault and injected during deployment—no open values remain in manifests and logs.
What if an update went wrong?
Manifests are versioned, so returning to the previous state is one command; for data, we record recovery points. We rehearse the rollback procedure before it is needed.
How do you handle uneven load?
We configure autoscaling by several metrics: CPU utilization, queue length, active connections. The lower pool boundary dampens peak spikes, and the upper one limits resource consumption.
Let's discuss your task and come back with a plan
An estimate "based on a description in a messenger" almost always diverges from reality: other environments, access schemes, and fault tolerance requirements surface.
That is why before calculating we ask for a minimal set of inputs—it is enough to understand the scope of work and risks without unloading the entire internal kitchen.
To discuss the task substantively, send:
- a list of services and environments that must run in the managed cluster;
- current configurations, manifests, and network designs, if containerization has already begun;
- load profile: peaks, daily rhythm, autoscaling requirements;
- restrictions on access, environment isolation, and maintenance windows;
- fault tolerance requirements and acceptable recovery time;
- what you have already tried and why the result was not satisfactory.
Then the order of work is predictable. We review the inputs, clarify disputed points, and come back with an estimate of work: composition of stages, labor costs, dependencies on your side.
Then—an implementation plan with readiness criteria at each step, so that the intermediate result is checked rather than taken on faith. After launch, support remains: update regulations, incident response, and documentation handover to your team.
Describe the task—we will come back with an estimate and implementation plan.