Kubernetes technical support: setting up the cluster is the

WebDisk Blog · category: Public cloud · reading time: ~7 minutes

In brief:- A Kubernetes cluster looks its best on the day it is launched. The real work begins later: three releases a year, backups of the etcd database, monitoring, security and someone who picks up the alert at night.- Good technical support is not "help when something stops working", but a continuous process: updates, a tested backup, insight into what is happening in the cluster (observability) and clear rules for responding.- In the WebDisk cloud you can run a managed Kubernetes cluster (WebDisk K8s) or build your own on IaaS infrastructure – and our team will help with migration planning and configuration. >Not working with a terminal? Skip the article's single command block – the rest of the article gets by without it.

Kubernetes has become the standard way of running applications built from microservices – small, independently deployed services – including in companies that did not start out "in the cloud" at all. The typical picture in companies that have been developing their software for years looks like this: some systems run on classic virtual machines, some in Docker containers or in Docker Swarm (an older, simpler way of running containers across many servers), and only the newest projects run in a Kubernetes cluster. Such a hybrid environment is not a backlog to catch up on, but the natural result of successive, sensible decisions taken over the years.

There is a trap in this, however, one talked about less often than the migration itself: a cluster that has been set up is not the same as a cluster that is maintained. Launching Kubernetes has never been simpler; keeping it healthy for years to come still requires work, knowledge and on-call duty. In this article we show what that work involves, what good Kubernetes technical support should cover and what Kubernetes looks like in the WebDisk cloud.

This text is addressed both to teams that are only considering migration and to those that already have a cluster – and want an honest answer to the question of who actually looks after it.

Why is setting up a Kubernetes cluster only the beginning?

Setting up a cluster is a matter of hours today – installers and cloud platforms have taken most of the former complexity off administrators' hands. The difficulty has moved elsewhere: to everything that happens after the launch. Four examples:

The release cycle. Kubernetes publishes three releases a year, and each one receives fixes – including security fixes – for about 14 months. A cluster that has not been updated for a year and a bit falls out of that window, and catching up is not a single leap: you move up version by version, without skipping any.
Deprecated APIs. Successive releases remove obsolete interfaces. A deployment manifest that worked flawlessly for two years may fail to apply after an upgrade – which is why a review of the APIs in use is part of every planned update.
Certificates. Cluster components authenticate to one another with TLS certificates of limited validity – in typical installations, one year. An expired certificate in the cluster's management layer (the control plane) can cut administrators off from the cluster in a single morning.
etcd. This is the database in which the cluster keeps its entire state: deployment definitions, configuration, secrets. Without a regular etcd backup – and without a tested restore – a serious control plane failure means rebuilding the cluster from scratch.

None of these points is exotic; it is ordinary, repeatable administration. The only question is whether someone in the organisation has it among their duties – or whether it just happens "on the side", for as long as it happens at all.

What should good Kubernetes technical support cover?

When you assess a support offer – an external one, or your own team's capabilities – check whether it covers five areas:

Updates and lifecycle. Planned update windows for the control plane and the nodes, a review of deprecated APIs before every version bump, keeping an eye on certificate validity. Boring – and that is exactly why it is the first thing to drop out of an overloaded team's calendar.
Backup and restore testing. A regular backup of etcd and – separately – of application data on volumes. A backup that no one has ever restored is not a backup but a hope; we covered the principles of sensible backup in more detail in the article Cloud backup – the foundation of modern IT security.
Monitoring and alerting. Metrics of the control plane, the nodes and the applications themselves, plus alerts that reach the person on duty – on the provider's side or on yours; this is one of the most frequently omitted points of a contract, so settle it in advance. Tuning matters too: a system that fires pointless alerts a hundred times a day teaches people to ignore alerts.
Security. Role-based access control (RBAC – the Kubernetes mechanism that decides who may perform which operation), operating system updates on the nodes, scanning container images for known vulnerabilities, network policies between services. We describe how we build the security layers of our own platform in the article Open source security stack at WebDisk.
Incident response. An established reporting path, a clear division of responsibility between the provider and the customer, and procedures for emergency scenarios – written down before they are needed.

If you want to check the condition of your own cluster quickly, start with three commands:

# which API server version – compare it with the Kubernetes release calendar (fixes ~14 months)
kubectl version

# node health and consistency of their versions
kubectl get nodes -o wide

# warnings from the entire cluster
kubectl get events -A --field-selector type=Warning

And one question that no command will answer: when did someone last restore an etcd backup in a test environment? If the answer is "never" – that is the first item on the task list, even before the conversation about expanding the cluster.

Migration is a process, not a weekend move

Good support in fact begins before the cluster even exists. Migration to Kubernetes is rarely a one-off leap – it is a sequence of stages: an inventory (what already runs in containers, what is stateful, what stays on virtual machines), the choice of the first candidates, the move, observation, another batch. Part of an honest plan is also a list of applications that are not worth moving: a monolith running stably on a single virtual machine will not suddenly become a scalable microservice once containerised – it will gain a new layer of complexity instead.

We help with two scenarios, among others: moving environments from Docker Swarm to Kubernetes, and migrations of entire virtualisation environments to our cloud – we describe the latter topic in the article Migration from VMware to WebDisk Cloud Computing.

Kubernetes at WebDisk: a managed cluster or your own on IaaS

In our public cloud, Kubernetes is available in two ways:

Managed Kubernetes cluster (WebDisk K8s) – a service available to WebDisk Cloud users. The platform (built on Apache CloudStack) creates the cluster automatically, and you change the number of nodes from the panel (cloud.dco.webdisk.io), without manually touching each machine; we plan the cluster version upgrade together with you, because Kubernetes is upgraded one step at a time, release after release. "Managed" here means: the platform sets up the cluster and scales it for you. The etcd backup, certificate renewal, operating system updates on the nodes and monitoring of your applications remain on the cluster owner's side – unless we agree otherwise.
Your own cluster on IaaS – for teams that want full control over the distribution and the configuration. IaaS (Infrastructure as a Service) means that you rent virtual machines and a network from us, and build the environment on them with the tools you know; advanced teams can reach for Cluster API with the provider for CloudStack (automatic creation and recreation of clusters) or for the CloudStack Kubernetes Provider, which wires an existing cluster into the platform's network and load balancers.

Whichever route you take, you can call on our team for help – from consulting and a migration plan through to application configuration. We set the scope of such cooperation and its terms in the contract, so from the start it is clear what is on our side and what is on yours. We describe how our support looks behind the scenes – and the channels you can use to contact us – in the article WebDisk Support.

What will Kubernetes technical support not solve?

Outsourcing Kubernetes maintenance takes a real burden off the team, but a few things remain on the system owner's side – and it is better to know this before signing the contract than afterwards:

The decision on whether to use Kubernetes at all. Not every application gains from container orchestration. For many workloads a virtual machine remains the simpler and operationally cheaper choice – we wrote about the differences between cloud service models in the article Cloud as a Service, and about the costs of the public cloud – in the article Public cloud at a reasonable price.
The limits of the word "managed". A managed Kubernetes service sets up the cluster and scales it for you. The etcd backup, certificate renewal, operating system updates on the nodes and monitoring of your applications do not happen by themselves – someone has to have them among their duties: your team or ours, on the basis of a contract.
Changes in the application itself. Support will keep the cluster running, but it will not rewrite the architecture of an application that is not ready to work in containers.
Responsibility for the data. A backup of the cluster infrastructure is not the same as a backup policy for application data – the latter has to be designed deliberately and tested regularly.
Complexity itself. Kubernetes adds a layer of abstraction that has its costs. Good support manages that complexity – but does not remove it.

Frequently asked questions

Do I have to use Kubernetes in order to use the WebDisk cloud? No. Kubernetes is one of the options – alongside classic virtual machines, VPS and file services. If your workloads run well on VMs, migrating to containers is not a condition of using our platform.

I set the cluster up myself. Can I count on support? Yes – you can call on us at any stage: when planning a migration, after deploying on your own, and also for applications that have been running in our cloud from the start. We agree the scope individually, in the contract.

What does a "managed" Kubernetes cluster mean and what remains on my side? In WebDisk K8s, "managed" means: the platform sets up the cluster and scales it for you – you change the number of nodes from the panel. The etcd backup, certificate renewal, operating system updates on the nodes and monitoring of your applications remain on the cluster owner's side, unless we agree otherwise. It is worth having this division of responsibility written down in the contract before it is needed.

How often does a Kubernetes cluster need to be updated? Kubernetes publishes three releases a year, and each one receives fixes – including security fixes – for about 14 months. A cluster that has not been updated for a year and a bit falls out of that window, and the backlog is caught up version by version, without skipping any. A review of deprecated APIs should also be part of every planned update.

Is an etcd backup a full cluster backup? No. An etcd backup secures the state of the cluster: deployment definitions, configuration, secrets. Application data – databases, files on volumes – requires a separate backup strategy, with a separate restore test.

Where should a migration from a hybrid environment start? With an inventory: what already runs in containers, what is stateful, what is to stay on virtual machines. Then the choice of the first, non-critical application, migration, observation – and only then the next stages. An "all at once" plan is a common cause of failed migrations.

Summary

Kubernetes deserves its popularity – but together with it you buy obligations: updates, backups, monitoring, security and readiness to respond. If your team has them arranged – excellent. If not, it is worth talking about them before the first outage reminds you of them. Write to us – we will help plan a migration or review how your current cluster is maintained.

Kubernetes technical support: setting up the cluster is the easiest stage