Managed Kubernetes from VK Cloud: where the cluster breaks
Managed Kubernetes from VK Cloud takes over the control plane for the team, but the cluster itself remains a manual work area.
Nodes are added through the control panel upon developer requests; pools exist with heterogeneous machine types and labels; autoscaling is enabled formally.
After a few months, no one can explain why a particular workload is pinned to this specific pool and what will happen if it is removed.
Meanwhile, configurations sprawl: some changes go through Helm, some through editing manifests directly, some manually in the panel. The cluster state stops matching the repository, and rollback to the previous release turns into a separate operation with an unclear outcome.
Cluster configuration loses reproducibility: a new environment takes longer to assemble than fixing the existing one.
A separate infrastructure bottleneck is behavior during zone failure and version updates. If pod distribution rules across zones and planned eviction are not defined, during an incident the load does not move but waits for manual intervention from the on-call engineer.
Updates happen without draining nodes, versions diverge, some system components do not come up — and the release is postponed indefinitely.
The cost of such a mode is predictable: releases wait for windows, the on-call engineer puts out the same incidents, and every change is discussed with an eye on the previous failure. We explain how this is addressed.
What changes after moving to a managed cluster
A managed VK Cloud cluster takes over the control components: updates, certificates, and availability of service nodes. On our side remain workloads, policies, and observability — and this is where measurable shifts appear.
Release rollout and rollback speed
Release uses a rolling update strategy with readiness probes: traffic is removed from the old pod only after the new one is ready to accept requests, so the rollout does not turn into a downtime window.
The maxSurge and maxUnavailable parameters limit how many replicas are kept above the norm and how many can be temporarily taken out — the update completes in minutes even under load.
Rollback comes down to reverting to the previous deployment revision, not rebuilding the environment manually; we verify the practice against the pod lifecycle description.
Fault tolerance and recovery time
Nodes are distributed across availability zones, and node groups autoscale based on actual resource requests: a pod that did not have enough space does not wait for an engineer.
PodDisruptionBudget prevents planned maintenance from bringing the service down entirely, and when a node fails, the scheduler recreates the workload on live nodes — recovery takes minutes instead of hours of manual troubleshooting.
The class of failures “resources ran out in the zone” and “forgot to bring up a node” goes away; the share of manual operations in maintenance drops to isolated actions.
Deployment modes: managed, own nodes, hybrid
The platform offers three deployment schemes, and the choice between them is not about “better or worse,” but about how much control your team actually needs.
| Option | When it fits | Limitations |
|---|---|---|
| Fully managed | No in-house operations team, need fast environments | The provider sets versions, network, and control panel updates |
| Managed control panel, own nodes | Non-standard machines, custom images, strict placement requirements | Nodes, their updates, and scaling are on your side |
| Hybrid scheme | Data must remain in your own environment or you already have your own hardware | Network and routing between environments are more complex, access is worked out separately |
Where the responsibility boundary with the provider lies
The provider is responsible for the control panel: its availability, updates, certificates, and cluster state storage.
Everything above — worker nodes, network policies, access roles, load balancing, volumes, and the applications themselves — remains with your team, even if the nodes are also managed.
Guarantees cover the control panel, not your service, so we design application alerts and observability as your area from the very beginning.
When a hybrid scheme is justified
Hybrid is justified when there is a requirement to keep data in your own environment, when hardware has already been purchased and must be used, or when services are sensitive to latency to a specific site.
If the only reason is “we want full control,” the scheme does not pay off: the number of failure points grows, and updates and incident troubleshooting become more complex.
Implementation order: from audit to handover to support
We structure the work so that each stage produces a verifiable result, not an “in progress” status. Below is how the implementation of a Managed Kubernetes cluster looks from the first conversation to the point when it runs without our involvement.
How the audit is conducted and what goes into the design
Infrastructure audit begins with fact gathering: which services are already running, how they are connected, where the failure points are, and what resource headroom is needed at peak.
The output is a cluster design with the number of nodes, environment labeling, and network policy boundaries: what is accessible to whom and why exactly so.
- Audit of the current environment — inventory of services, dependencies, and load profile.
- Design and resource calculation — cluster topology, node pools, limits, autoscaling.
- Environment labeling — separate environments for development, testing, and production, namespace isolation, access roles.
- Network and policies — segmentation, ingress and egress traffic rules, secret storage.
- Failure testing — controlled decommissioning of nodes and zones.
- Handover to support — procedures, monitoring, training for your team.
Failure testing before handover
We consider the cluster ready only after it has survived the loss of a node or zone without manual intervention. We deliberately shut down components, observe how the load is redistributed, and record the recovery time. The test results along with operating instructions go to your team.
What we hand over after cluster delivery
Delivery of a cluster in VK Cloud is not access to the control panel, but a set of artifacts that your team uses to continue working independently.
- Environment design: separate environments for development, pre-production, and production workloads — each with its own namespaces, quotas, and limits.
- Manifests and configurations in a git repository: a single source of truth, changes go through review, cluster state is reproduced from scratch.
- Image registry with a retention policy: fresh builds remain available for rollback, old ones are cleaned up automatically, storage volume does not grow.
- Monitoring and alerts: nodes, pods, and key services are monitored, each threshold has a notification route to the on-call engineer.
- Cluster documentation: network design, failure points, responsible contacts, and on-call instructions in case a node becomes unavailable.
Access policies and team roles
Permissions are granted on the principle of least privilege: developers do not have access to the production environment, service accounts are separated from human accounts.
All actions are recorded in an audit log, and roles are described so that a new engineer can be onboarded in an evening without rebuilding access from scratch.
Update and backup procedures
The update window, rollout procedure, and rollback plan to the previous node version are fixed.
Backups are taken on schedule — separately for cluster configuration and volume data; once a quarter we test recovery on a test environment rather than relying on the mere existence of backups.
Case study: migrating a service to a managed cluster
A service with a daily traffic peak ran on three manually assembled virtual machines: updating the version turned into a night operation of a dozen steps, and a node failure meant manual migration and recovery over several hours.
Migration to a managed VK Cloud cluster began not with the move, but with an inventory: we described dependencies and separated state from the application so that data did not move together with containers.
What we changed
Rollout was moved to declarative manifests: what used to be done manually according to a checklist is now applied with a single command — the number of manual operations dropped from a dozen to one.
Updates proceed with gradual instance replacement and readiness checks, so release downtime dropped to zero instead of a night window.
Fault tolerance stopped being manual work: a failed node is replaced automatically, instances move to live ones, and recovery time dropped from hours to minutes.
Under peak load, we enabled autoscaling based on utilization and queue length — the cluster adds capacity before the queue grows, not after a failure.
What was achieved
After several months: daily releases instead of once a week, zero unavailability during updates, and at peak the service handles three times the previous load while maintaining target response.
We published a breakdown of this migration case with before-and-after metrics separately — with the cluster design and update policies.
How does a managed cluster differ from your own on your servers?
In your own cluster on your servers, all responsibility lies with your team: deploy the control layer, ensure its fault tolerance, monitor certificates, update state storage, fix the network between nodes. Here the provider is responsible only for the machines and the channel. Any failure of the control layer is an incident for your on-call shift.
In a managed cluster, the boundary is different. The control panel — the control layer, its scaling, state backups, certificates, and version changes — is covered by the provider. You are left with worker nodes and what runs on them.
Nodes are already your area. Their size, groups, maintenance windows, and update policy are chosen by the team, while the provider supplies the mechanism: nodes are drained one by one, and the load is relocated.
But for node updates not to turn into downtime, readiness checks and a disruption budget are needed — you configure them, not the provider.
Then begins what is not delegated to anyone: access and secrets, network policies between services, resource limits, and collection of application logs and metrics. The provider does not know your domain, so these layers are designed and maintained by the team.
The choice comes down to where the team creates more value. If it is stronger in platform than in product, your own cluster gives full control over versions and network settings.
If the value is in the product, a managed environment in VK Cloud removes control layer maintenance, leaving you with workload architecture and application observability.
Technical concerns before starting work
In managed Kubernetes from VK Cloud, the provider covers some tasks, but the customer's engineers still ask the same set of questions: what happens to the load during cutover, who is responsible for updates, how the environment will survive zone loss. Below are short answers to five of them.
How is the load migrated without downtime?
We bring up the target environment next to the current one, deploy the services, and test them on a portion of traffic. We switch the load balancer routes in shares; the old environment remains live until the migration is complete — reverting a route takes seconds.
Who is responsible for version updates?
The provider updates the control part in agreed windows; we update the workers: in waves across node groups, with pod eviction and respect for disruption budgets. We keep the current branch and the previous minor release.
What happens if an availability zone fails?
Nodes are distributed across zones by placement rules, so pods from the lost zone are rescheduled in the surviving ones. For services with disks, we place replicas in different zones in advance — otherwise the volume becomes unavailable along with the zone.
How does the environment scale under load growth?
Pods scale based on metrics, and nodes are added automatically when capacity is insufficient. The condition is correct resource requests and limits; otherwise the scheduler will not see the real demand — we verify this with a load test before launch.
How are roles and access separated?
Namespaces for teams and environments, roles with the minimum required permissions, separate credentials for each person and for service systems, an audit log of actions on the cluster. We grant access for a period, not “just in case.”
Let's discuss the task: what we clarify before starting work
Estimation for migrating services to managed Kubernetes in VK Cloud is not calculated by a template: the effort depends on the number of services, how they relate to state, and acceptable downtime.
Therefore, before starting, we review the inputs — from them an implementation plan is assembled with stages, responsible parties, and a readiness criterion at each step.
What we need from you to come back with an estimate and plan:
- Load profile: how many services, which ones store state, how traffic behaves during daily and weekly peaks.
- Availability requirements: acceptable downtime, whether zone-level fault tolerance is needed, which maintenance windows are acceptable.
- Current environment: what is already running — virtual machines, build pipelines, monitoring, secret and configuration storage.
- Security constraints: network policies, separation of access between teams, requirements for action auditing and log retention.
- Migration timeline: hard dates, services that cannot be stopped, and the order for decommissioning old environments.
- Integrations: image registry, load balancers, DNS, queues, external databases, and dependencies on related teams.
Based on these inputs, we fix the migration sequence, rollback points, and how the load is switched without losing requests. Describe the task — we will come back with an estimate and work plan.