Before You Move to Kubernetes, Assess Why Deployments Are Failing

When deployments become unreliable, the proposed fix is often a bigger platform.

Someone suggests Kubernetes. The argument sounds reasonable: containers are standard, rollouts are controlled, failed workloads restart, and scaling is built in. Those capabilities are real. Kubernetes provides service discovery, load balancing, automated rollouts and rollbacks, self-healing, and horizontal scaling (Kubernetes overview).

But a platform can only solve the problems it is designed to solve.

It cannot decide what “healthy” means for your application. It cannot make an unreliable test suite trustworthy. It cannot recover a database that was never backed up correctly. It cannot remove an undocumented manual step that happens outside the deployment system. It cannot give ownership to a release process that nobody owns.

Before changing platforms, assess the path you already have—from a developer’s commit to a working release in front of a customer. The right result may be Kubernetes. It may also be a smaller correction to your pipeline, runtime, rollback procedure, or operating habits.

The point is not to avoid Kubernetes. The point is to earn the complexity.

Start with the failure, not the tool#

“Deployments are unreliable” is a symptom. It is not yet a diagnosis.

Ask for the last three examples. For each one, write down:

What changed?
Which step failed?
How was the failure detected?
What did customers or staff experience?
How long did recovery take?
Was rollback attempted?
Which part required a person to remember something?
Did the same failure happen before?

This usually produces a more useful problem statement.

Instead of “we need Kubernetes,” you may discover:

builds are not reproducible;
production configuration is edited by hand;
database migrations run without a safe compatibility window;
the pipeline reports success before the application is actually healthy;
staging does not resemble the production path;
nobody has tested rollback;
a release depends on one person with local credentials;
failures are first reported by customers;
the team cannot connect a deployed version to its source revision.

Kubernetes might help with some runtime concerns. It will not automatically correct the rest.

Map the deployment path on one page#

A useful assessment starts with a plain map. Keep it simple enough that a founder, developer, and operator can point to the same steps.

For example:

Code is merged.
A build starts.
Tests and checks run.
An artifact is created and identified.
Configuration and secrets are supplied.
The artifact is deployed to a test or staging environment.
A person or system approves production.
Production is updated.
Health is checked.
The release is accepted, stopped, or rolled back.

For every step, record four things:

owner;
system of record;
success signal;
recovery action.

Blank spaces are findings. If three people give three different answers, that is also a finding.

Google’s SRE guidance treats a reliable release process as the full path from source to deployment, with repeatable builds, intentional configuration changes, testing, packaging, deployment, canarying, and rollback (Google SRE book: Release Engineering). A small company does not need Google’s machinery, but it benefits from the same basic discipline: know what was built, know what changed, and know how to retreat safely.

Check the artifact before the platform#

A deployment is easier to trust when the artifact is identifiable and repeatable.

You should be able to answer:

What exact revision is running?
Can the same revision be rebuilt predictably?
Are dependency versions controlled?
Is the artifact promoted between environments, or rebuilt differently for each one?
Can operators connect an alert or customer report to a release?
Are configuration changes tracked separately from code changes?

If those answers are unclear, changing the scheduler will not make the release traceable.

For a small team, the solution may be modest: produce one versioned container image, attach the source revision, store it in a registry, and deploy that same artifact through each environment. That is often more valuable than replacing the whole runtime.

Test what happens after “deploy succeeded”#

A green pipeline is not the same thing as a healthy application.

The deployment system needs a meaningful check after the new version starts. That check should cover the smallest useful slice of customer value—not merely whether a process exists.

Depending on the application, that might mean:

the service answers on its health endpoint;
the application can connect to its required datastore;
a read-only request completes;
a queue consumer can receive work;
the public route serves the expected version;
an essential integration is reachable without sending real customer data.

The check should be fast, safe, and tied to a decision. If it fails, does the rollout stop? Does traffic remain on the prior version? Does a person receive an actionable signal?

Kubernetes supports health checks, controlled rollouts, desired-state reconciliation, and Deployment rollback mechanics (Kubernetes overview; Kubernetes Deployments). Those are useful capabilities. They still depend on the team defining the right health signals and operating the release safely.

Prove rollback before you need it#

Many teams have a rollback command. Fewer have a rollback they have exercised.

A credible rollback answer covers more than application code:

Is the previous artifact still available?
Can the platform route traffic back to it?
Are database changes backward-compatible?
Did the release change external state that cannot simply be reversed?
Can configuration return to the prior known-good version?
Who is authorized to make the decision?
How will the team know recovery worked?

If rollback depends on restoring data, test the restore. A backup is not useful merely because a job says it completed.

If rollback is unsafe after a database migration, use a different release pattern: split schema and application changes, preserve compatibility during the transition, or use a forward fix with an explicit recovery plan.

The assessment should not demand one universal method. It should make the actual constraint visible.

Review the human steps without blaming the humans#

Manual is not automatically bad. Undocumented, unaudited, and fragile is bad.

A small team may reasonably keep a production approval step. The question is whether that step has a clear owner, clear information, and a safe fallback.

Look for:

commands copied from old chat messages;
credentials stored on one laptop;
production edits that never reach version control;
releases timed around one person’s availability;
checklists that exist only in memory;
alerts that say something failed but not what to do next;
emergency fixes that bypass the normal path and are never reconciled.

The first improvement may be a one-page runbook, a permission change, and a tested recovery command. That is not glamorous. It is also far cheaper than migrating a broken process onto a more complicated platform.

When Kubernetes is warranted#

Kubernetes becomes a reasonable option when its capabilities answer observed requirements and the team can operate the additional system.

Signals can include:

several containerized services need consistent scheduling and service discovery;
the team needs controlled rolling updates across multiple replicas;
workloads need independent horizontal scaling;
the application needs stronger workload isolation or standardized resource controls;
multiple teams need a common deployment interface with clear platform ownership;
the organization is prepared to operate or buy a managed control plane, observability, access controls, upgrades, backup, and recovery.

Even then, distinguish the managed service from the operating model. A managed provider can reduce control-plane work. It does not own your application health, deployment design, access policy, cost controls, or incident response.

The Kubernetes documentation is direct about production requirements: a production-quality cluster needs planning for availability, scale, security and access, certificates, control-plane resilience, nodes, and etcd backup, among other concerns (Kubernetes: Production environment). That is appropriate when the business needs the capability. It is overhead when the business does not.

When Kubernetes is probably not the first move#

Pause before migrating when:

there is one modest application on one or two hosts;
traffic is stable and vertical scaling has room;
releases fail before the runtime is involved;
the team lacks a tested backup and recovery process;
no one will own cluster operations;
the application is not packaged consistently;
observability is weak enough that a new platform would add signals nobody can interpret;
the primary requirement is “modernization” rather than a specific operational need;
the proposed migration has no acceptance criteria beyond “running on Kubernetes.”

A clean virtual machine, a container runtime, a small pipeline, an external database, tested backups, and useful monitoring can be a professional production system. Simplicity is not the absence of engineering. It is the result of choosing fewer moving parts and operating them well.

A practical assessment checklist#

Use this before approving a platform migration.

Business and ownership#

What customer or business consequence makes this worth fixing now?
Who owns the release path?
What recovery time is actually required?
What support coverage can the team sustain?

Source and artifact#

Is every production release tied to a source revision?
Is the deployed artifact versioned and retained?
Is the build repeatable enough to investigate and recover?
Are dependencies controlled?

Pipeline#

Which checks must pass?
Which checks are slow, flaky, or routinely bypassed?
Are secrets kept out of logs and source?
Are approvals explicit and auditable?

Configuration and data#

Is production configuration versioned or otherwise traceable?
Are database migrations designed for safe rollout and recovery?
Are backups monitored?
Has restore been tested?

Runtime#

What marks an instance as ready to receive traffic?
What marks it as unhealthy?
What restarts automatically, and what should not?
Are resource constraints understood?

Release and recovery#

Is post-deployment health checked?
Can a rollout stop before all users are affected?
Has rollback been exercised?
Is the previous artifact and configuration available?

Observability#

Can the team connect a customer symptom to a release?
Are logs, metrics, and alerts actionable?
Who receives the signal?
What is the first recovery action?

Platform decision#

Which measured requirement does Kubernetes satisfy?
What simpler options were considered?
Who will own upgrades, access, observability, and recovery?
What will prove the migration improved the original problem?

A hypothetical example#

The following example is fictional.

A six-person software company deploys one web application and one background worker to a virtual machine. Releases fail often enough that the founder proposes Kubernetes.

The assessment finds that the virtual machine is not the main problem. The pipeline builds a different image for staging and production. Production environment variables are changed manually. The health check only confirms that the process started. A database migration runs before the new application version is ready, and rollback has never been tested.

The first plan is smaller than a migration:

Build one versioned image and promote it.
Move production configuration into a controlled, documented process.
Add a readiness check that verifies the application’s critical dependency.
Split the database change from the application cutover.
Retain the previous image and exercise recovery in staging.
Record deployment and recovery ownership.

After those changes, the company may still choose Kubernetes later. If it does, it will migrate a clearer release process instead of reproducing the same uncertainty on a new platform.

The useful decision#

A deployment assessment should not end with a diagram and a vague recommendation to “improve DevOps.” It should produce:

a current-state deployment map;
a short list of evidenced failure modes;
a ranked risk register;
a tested or clearly bounded recovery gap;
a 30/60/90-day plan;
an explicit recommendation to repair, simplify, or evaluate migration.

That gives a small team a decision it can act on.

If your deployments have become unreliable, start by tracing one release from commit to customer and one recovery from failure to health. If the result points to Kubernetes, you will know why. If it points to three smaller fixes, you may get reliability sooner and with less operational burden.

GV5 is developing a fixed-scope deployment reliability assessment for small software teams and agencies. If this is the problem in front of you, email [email protected] with a short description of the last failed release. We will first decide whether an assessment is useful; no platform migration is assumed.

Sources#

Kubernetes documentation: Overview
Kubernetes documentation: Deployments
Kubernetes documentation: Production environment
Google, Site Reliability Engineering: Release Engineering