Kubernetes Challenges: Why Self-Managed Clusters Get Hard to Run

Kubernetes challenges on a self-managed cluster come from work that carries on long after go-live. That work falls into eight areas: upgrades and version skew, etcd care, certificates and high availability, node patching, networking and storage add-ons, hardening, cluster observability, and the people who carry skills, on-call and audit evidence. Kubernetes is the open-source system that schedules and runs containers across a group of servers. See how Kubernetes works for the core ideas.

The reader here is a platform lead, IT head or CTO in India or the GCC. Their team runs its own control plane, in a cloud account or on its own servers. A large share of the kubernetes complexity sits in that layer, and it grows with each cluster you add. Each section names one burden and the owner question behind it. However, this is not a troubleshooting guide. It does not compare platforms, and moving an application into containers is set out in an order of work for moving an application onto a cluster.

Kubernetes Challenges Begin With the Upgrade Treadmill

The Kubernetes project sets the release rhythm for every cluster. As a result, the upgrade plan follows the project’s calendar, whatever else is on the roadmap.

Release Rhythm and Support Window as of November 2026

The project ships a new minor version about three times a year, and each one has a fixed support life. As of November 2026, these are the figures your plan has to follow:

• Release rhythm: minor releases arrive about three times a year, according to the project’s release cycle page.
• Branches kept: the project maintains branches for the latest three minor versions: 1.37, 1.36 and 1.35.
• Support life: each minor version gets about one year of standard patch support. With the two-month maintenance period added, that comes to roughly 14 months.
• Patch rhythm: the project plans patch releases monthly, according to the project’s patch release page.
• A recent end of life: version 1.34 reached end of life on 27 October 2026.

In other words, a version you install today has just under a year of fixes ahead of it. After that, security patches stop and the version falls out of the support window.

In Signisys’s working view, a cluster that goes a year or more without an upgrade is at the edge of support or past it. Three new minors arrive in that time, and each carries only about 14 months of patches in total. For example, a Mumbai lender still on 1.34 would now run a version with no project patches. The upgrade becomes a standing job on the team’s calendar.

Version Skew Sets the Upgrade Order

Version skew is the gap allowed between versions of different cluster parts. It decides the order of every upgrade. The Kubernetes version skew policy sets the limits:

• In a high-availability cluster, the newest and oldest API servers must be within one minor version of each other.
• The kubelet, the agent that runs on each node and starts its containers, must not be newer than the API server. It may be up to three minor versions older.
• The project’s upgrade guide states that skipping minor versions when upgrading is unsupported.

Together, these rules fix the sequence. First, the API servers move up one minor version, then the scheduler and controllers. Nodes may lag behind, but the policy warns that kubelets left three minor versions behind must be upgraded before the control plane moves again. A cluster two versions behind therefore needs two full hops, each with its own testing window.

Each hop also touches the add-ons. An add-on is a component installed on top of Kubernetes, such as the network plugin or a storage driver. Each one supports a limited range of Kubernetes versions. We recommend retesting every add-on at every hop, because a plugin that worked before may not support the new version. As a result, one late upgrade can turn into several weekends of work for a small team.

Kubernetes Challenges in the Control Plane and etcd

The control plane is the set of components that runs the cluster: the API server, the scheduler and the controllers. On a self-managed cluster, this layer belongs to your team, along with the data store beneath it.

etcd Backups and Restore Tests

etcd is the key-value store that holds all cluster state. Losing it means losing the record of everything running on the cluster. The project’s guidance is direct on three points, set out in the project’s etcd operations guide:

• Have a backup plan for the etcd data before you depend on it.
• Run etcd with an odd number of members, so a majority can still agree when one member fails.
• Encrypt the snapshot files, because they contain sensitive cluster data.

A backup on its own is only half the job. We recommend treating any backup with no recorded restore test as untested. The restore tells you whether the snapshot is complete and whether the team knows the procedure. It also shows how long the cluster stays down.

In practice, that means a written restore procedure and a test cluster to restore into. It also means a dated record of each test and how long it took. For instance, a Dubai retailer might hold a year of monthly snapshots and still not know whether any of them works. The record is also what an auditor asks for, which the people section below covers.

Ownership matters too. If one engineer holds the restore steps in their head, the backup protects data but not the business.

Certificates and High Availability

The control plane talks to its nodes and its own parts over certificates, and those certificates expire. On clusters built with the project’s cluster setup tool, client certificates expire after one year by default. That same tool renews them during a control plane upgrade, according to the project’s kubeadm certificate guide. The kubelet’s own client certificate rotates separately.

That link between upgrades and renewal is easy to miss. A team that upgrades on time renews its certificates as a side effect. On the other hand, a team that delays upgrades past a year may find the API server rejecting expired client certificates one morning. Nothing in the code has changed.

High availability adds a second duty. For a control plane that survives the loss of a machine, the team runs several control plane nodes. Each has its own API server, with etcd members spread across them. Those nodes must stay within the one-minor rule for high-availability clusters during every upgrade. Consequently, each hop is a rolling change across several machines, with a check between each one.

Kubernetes Challenges Below the Workloads: Nodes and Add-ons

Between the cloud account and the application sit the nodes and the add-ons. Both need patching and testing, and both are easy to forget once the applications are running.

Node Patching and Replacement

Every node runs an operating system that needs security patches, and a kubelet that must stay within the skew rules. As a result, node work comes from two calendars at once: operating system patches and Kubernetes upgrades.

The sequence is to drain a node, patch or replace it, and return it to service. Draining moves its workloads to other nodes first, and the skew policy states that in-place minor kubelet upgrades are unsupported. However, that only works when the other nodes have room to take the load. We recommend enough spare capacity to drain at least one node at a time without workloads failing to start. For sizing that spare room, see matching node size to real demand.

Some teams prefer replacement to patching in place. In that model, a new node joins with the current image and an old one leaves. Even so, the team still has to build, test and update those images, then roll them through each node group.

For example, a Riyadh logistics firm with three clusters could face dozens of node replacements in one monthly patch cycle. In each case, someone has to schedule them, watch them, and confirm each workload came back.

Networking and Storage Add-ons

On a self-managed cluster, your team picks, upgrades and tests the network plugin, the storage drivers and the ingress. The ingress routes outside traffic into the cluster. Each add-on has its own release rhythm, and each version supports only certain Kubernetes versions. We recommend a written matrix of which add-on version runs with which Kubernetes version, checked before every upgrade.

Defaults matter as well. By default, a pod allows all inbound and outbound connections until a network policy selects it, according to the project’s network policy page. In addition, a network policy takes effect only when the network plugin supports it. That ties security back to the add-on choice.

These choices grow harder at scale. Kubernetes challenges here multiply with each cluster and each cloud. In particular, two clusters on different plugins or storage drivers need two sets of tests and two sets of skills. Clusters built by hand also drift apart; see how test and production clusters stop matching.

For instance, an insurer in Bengaluru might run one storage driver in its test cluster and another in production. A change that passes in test can then fail in production for reasons nobody can reproduce.

Kubernetes Challenges That Recur: Hardening and Cluster Observability

Hardening and cluster observability are both easy to set up once and leave alone. Both need a named owner after go-live, because each upgrade and each new workload changes what they have to cover.

Hardening That Has to Be Repeated

On a self-managed cluster, hardening repeats. Every upgrade, new namespace and new team can undo part of it. The project’s Pod Security Standards page defines three profiles for how much a workload may do. Specifically, Privileged places no limits, Baseline blocks known privilege escalations, and Restricted follows current hardening practice. Your team decides which profile fits each namespace, applies it, and keeps it applied as workloads change.

Access needs the same care. Role-based access decides who can read, change or delete what in the cluster. Over time, admin rights tend to spread as teams ask for quick fixes. We recommend reviewing role bindings and cluster admin rights after each upgrade and team change. Also record who signed off each one. In addition, network policies from the add-ons section need review whenever a new service is added.

The burden here is the ongoing work. Scored security checks for production clusters are a separate topic, outside this article. Here, the point is simpler: hardening needs a person, a calendar entry and a record, or it fades with each change.

Watching Cluster Health

Cluster observability means watching the cluster itself, not only the containers on it. Container logs show what an application did. However, they do not show an etcd member falling behind or a certificate close to expiry. Nor do they show a node short of memory or an add-on failing after an upgrade.

On a self-managed cluster, your team collects logs, metrics and alerts for four layers:

• Control plane: API server errors and latency, scheduler and controller health.
• etcd: member health, leader changes, database size and backup success.
• Nodes: CPU, memory, disk pressure and kubelet status.
• Add-ons: network plugin, storage driver and ingress health after each change.

By comparison, collection is the easy half. The hard half is deciding who reads the dashboards and which alerts page someone at night. We recommend that each alert carries an owner and a short note on what to check first. Otherwise, alerts pile up unread, and the first sign of trouble is a user complaint.

For example, a team in Doha might collect every metric yet page no one when etcd backups fail. The data exists, but the warning reaches nobody.

Kubernetes Challenges for People: Skills, On-Call and Audit

The eighth area sits with people rather than machines. Skills, the on-call rota and audit records decide whether the other seven areas get done on time.

Kubernetes Complexity Lands on a Few People

Kubernetes complexity tends to land on one or two engineers who know how the clusters were built. They hold the upgrade steps, the restore procedure and the add-on quirks. Their leave, illness or resignation then becomes a business risk. This is key-person risk, and on a self-managed estate it covers the whole platform.

The on-call rota makes it sharper. Someone has to answer a page when a node group fails or a certificate expires at night. With two engineers, each one is on call every other week, all year. Consequently, rest suffers and upgrades slip. The knowledge also stays with the same two people, because nobody else gets the practice.

More clusters multiply this work. Each new cluster, environment or region adds its own upgrades, backups, alerts and access reviews. The team, meanwhile, stays the same size. When leaders weigh the disadvantages of Kubernetes, this people load deserves equal weight with the technical work.

A common question is whether learning Kubernetes is difficult. The concepts can be learned. Running a production cluster safely, however, takes practice with real upgrades, restores and incident calls. We recommend at least three people who can each run an upgrade and a restore from the written procedure.

For instance, a Pune fintech firm might pair a second engineer on each monthly patch cycle. The procedure then gets written down and tested by a second pair of hands.

Audit Records for Regulated Firms in India and the GCC

At regulated firms in India and the GCC, auditors may ask how the cluster is run. What runs on it is only half the question. On a self-managed cluster, your team produces those records itself. The items an auditor may request include:

• upgrade records with dates, versions and who signed off each change;
• access reviews for role bindings and cluster admin rights;
• API audit logs showing who called the API server, what they did and when (the API server logs no audit events unless the team gives it an audit policy file);
• backup records and dated restore test results for etcd;
• where logs and backups are stored, and in which country.

The burden lies in the gathering. If each cluster keeps its own logs in its own format, someone pulls them together by hand for every audit. Consequently, the audit becomes a project of its own, on top of the upgrades and patching.

Symptoms That Trace Back to the Run Load

Five symptoms tend to show up when the run load is outpacing the team. Each one points back to a burden area above, which is where the lasting answer lies. This section names them only; it does not give fixes or commands.

When the same symptom returns, the Kubernetes challenges behind it may not be technical alone. For example, repeated certificate expiry points to an upgrade plan with no owner. Likewise, pods stuck in pending point to a capacity plan nobody reviews. Treating each incident on its own clears the alert, while the cause stays in place.

Signs a Team Has Outgrown Running Its Own Clusters

A team has outgrown its own clusters when the run load keeps pushing out planned work. Test your estate against these five signs:

1. The oldest cluster sits within two months of its version’s end of life, or past it.
2. No one has recorded an etcd restore test.
3. Upgrade and on-call knowledge sits with one or two people.
4. Add-on upgrades are held back because no one can test them.
5. Audit evidence is gathered by hand from each cluster.

One or two signs call for a plan and an owner. Three or more suggest the self-managed model costs the team more time than it gives back. At that stage, the Kubernetes challenges are structural rather than occasional.

One option then is to hand the control plane to a provider. On AWS and Azure managed services, the provider runs etcd and the control plane, including upgrades. On AWS your team starts them, unless support lapses and AWS forces one; Azure can automate them. With managed Kubernetes, the nodes, add-ons, hardening and workloads stay with you. The use case page sets out a provider-run control plane on AWS or Azure.

This article does not compare managed and self-managed clusters rule by rule, or weigh Kubernetes against serverless functions.

To be clear about our interest: Signisys offers application modernization and observability as a solution. Our DevOps and automation services team carries out this kind of review. A consultation reviews your estate against the eight burden areas and five signs above. It promises no result or saving. No charge, with a fixed scope.

Kubernetes Challenges FAQ: Questions IT Heads Ask