AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms10 business days
To start a Kubernetes engagement
Scoping through first sprint
100%
Senior engineers, US-based
No offshore handoff on cluster operations
Every sprint
Working software on a preview URL
Not a status deck between milestones
100%
Manifests and Helm charts you own
In your own cluster, from the first commit
Cluster architecture
The primitives that actually decide whether a cluster is reliable
Kubernetes has a large API surface, and most production incidents trace back to a handful of decisions in this list, not the exotic parts of the spec nobody uses.
Managed control plane, almost always
EKS, GKE, or AKS run the control plane — the API server, etcd, the scheduler — so your team isn't the one patching etcd or diagnosing a quorum loss at 3am. Self-hosting the control plane is rarely justified outside specific regulatory or air-gapped requirements, and it's the single highest-effort part of running Kubernetes yourself.
Namespaces are an organizational boundary, not a security one
Namespaces separate resources logically — by team, environment, or service — but by default nothing stops a pod in one namespace from reaching a service in another. Real isolation needs NetworkPolicies and RBAC layered on top, not just namespace names.
Deployments, StatefulSets, and DaemonSets solve different problems
A Deployment is right for stateless, interchangeable pods. A StatefulSet is right for anything that needs a stable identity and storage across restarts — a database, a message broker. A DaemonSet runs one pod per node — a log collector, a monitoring agent. Using a Deployment for something that needed a StatefulSet is one of the more common causes of data loss on a restart.
Resource requests and limits are the difference between a scheduler and a guess
Without requests and limits set, the scheduler is packing pods onto nodes with no real information about what they need, and a single runaway pod can starve its neighbors. Setting these accurately — from real usage data, not a guess — is one of the highest-leverage changes a cluster review finds.
Persistent storage is a CSI driver decision, not an afterthought
PersistentVolumes and PersistentVolumeClaims abstract storage, but the actual behavior — performance, availability zone constraints, whether a volume can move with a pod — comes from the CSI driver underneath. Choosing it deliberately for the workload avoids discovering its limits during an incident.
Ingress and service mesh are separate decisions
An Ingress controller routes external traffic into the cluster. A service mesh like Istio or Linkerd adds mutual TLS, retries, and fine-grained traffic control between services inside the cluster. Most clusters need the first and don't yet need the second — a mesh's operational overhead is real and worth deferring until the service count justifies it.
Operating a cluster
What keeps a cluster healthy after the first workload ships
The initial deployment is the easy part. What decides whether a cluster is still trustworthy a year later is how these get handled from day one.
GitOps over manual kubectl apply
ArgoCD or Flux reconciling cluster state from a Git repository means every change is reviewed, versioned, and reversible — and it means the cluster's actual state matches what's in source control, instead of drifting from manual changes nobody documented. This is the single change that most improves a cluster's long-term trustworthiness.
Helm charts as the packaging layer, kept simple
Helm templates Kubernetes manifests into reusable, versioned packages. The failure mode isn't using Helm — it's a chart so deeply parameterized that nobody can read the rendered output anymore. A chart your team can read and modify beats one that's technically more flexible and functionally a black box.
Autoscaling needs three layers, not one
The Horizontal Pod Autoscaler adds pod replicas under load. The Vertical Pod Autoscaler adjusts a pod's resource requests over time. The Cluster Autoscaler adds and removes nodes. Configuring only the first and assuming the cluster scales is a common gap — nodes don't appear on their own.
RBAC scoped per team or service, not cluster-admin for convenience
Granting broad access early because a deadline was close, then never narrowing it, is the same failure pattern as overly broad IAM policies in any cloud — just harder to notice because kubectl doesn't surface it the way a cloud console does.
Secrets need a real solution, not a ConfigMap
Kubernetes Secrets are only base64-encoded by default, not encrypted at rest unless you configure encryption explicitly. Most production clusters pair Kubernetes with a secrets manager — Vault, or a cloud provider's native secrets service — synced in via an operator, rather than trusting the built-in object alone.
Upgrades are a recurring cost, not a one-time migration
Kubernetes ships a new minor version roughly every four months, and managed providers deprecate old versions on a real schedule. A cluster that's never budgeted for upgrade work eventually gets forced into one under time pressure, which is a worse position than a routine quarterly bump.
What's involved
Kubernetes engagement types
What moves the scope is not pod count — it's how much of the current cluster state lives only in someone's memory or a manual runbook, and how many services have to move together during a migration.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Cluster health audit | Fixed scope | 1 – 3 weeks | RBAC and network policy review, resource request/limit audit, and a prioritized list of what has to change before scaling further. |
| New cluster build-out | Fixed scope | 4 – 10 weeks | Managed cluster provisioned on EKS, GKE, or AKS, with GitOps deployment, autoscaling, and namespace/RBAC structure defined as code. |
| Migration to Kubernetes | Fixed scope | 8 – 16 weeks | Existing services containerized and moved onto a cluster, sequenced so nothing ships as a big-bang cutover. |
| Service mesh or multi-cluster architecture | Fixed scope | 6 – 14 weeks | Istio or Linkerd adoption, or a multi-cluster topology for genuine multi-region or multi-tenant requirements. |
| Ongoing cluster operations | Ongoing retainer | Ongoing | Standing ownership of upgrades, on-call, and capacity planning through the next version bump and the next traffic spike. |
Ranges assume US-based senior engineers and include the RBAC and secrets-management work a cheaper quote often strips out. The audit exists as its own first step because it's the fastest way to find out how much of a cluster's current state is undocumented before anyone commits to the rest.
When Kubernetes is the wrong tool
Signs a workload doesn't need Kubernetes yet
This page assumes Kubernetes is the right call for what you're running. It's worth stating plainly when it isn't, because reversing an over-built cluster later is a much bigger project than not building it in the first place.
Fewer than a dozen services
A managed container service — ECS/Fargate, Cloud Run, Azure Container Apps — runs the same workloads with far less operational surface for a small service count. Kubernetes's flexibility earns its overhead at a scale many teams haven't reached.
No genuine multi-cloud requirement
Kubernetes's portability is valuable when multi-cloud is a real, active requirement — not when it's an insurance policy against a scenario that hasn't happened and probably won't. Adopting it for portability you're not using is overhead without the benefit.
No platform team, and no plan to build one
Kubernetes rewards having someone whose actual job is operating the cluster. Without that role — even a shared, part-time one — a cluster tends to accumulate configuration nobody fully understands within the first year.
Mostly short, event-triggered workloads
A webhook handler, a nightly job, an image resize — these fit serverless functions better than a cluster built to run long-lived services. Forcing them onto Kubernetes adds packaging and deployment overhead for work that doesn't need a running pod most of the time.
The team's actual motivation is the resume line
"It's what the job postings ask for" is the reason we hear most often when we ask why a cluster exists, and it's the one adoption path most likely to produce a cluster nobody can fully explain eighteen months later.
If any of this describes your situation, our DevOps page covers the managed-container alternative in more depth, and we'll say so plainly in a scoping call rather than build the cluster you asked for anyway.
Migration
Moving onto Kubernetes, or moving off an over-built cluster
Both directions are real projects we're asked to run, and they're not symmetric — one is materially harder than the other.
Onto Kubernetes: containerize before you orchestrate
A service has to run correctly and statelessly in a container before Kubernetes adds any value — orchestrating a service that wasn't designed to restart cleanly just automates the same failures faster. Containerization work often reveals hidden state (local file writes, in-memory sessions) that has to be externalized first.
Onto Kubernetes: sequence by dependency, not by ease
Migrating the easiest service first feels productive and often teaches the least. Migrating a representative service — one with a database dependency, one with background jobs — surfaces the real problems (secrets, storage, networking) while there's still time to fix the pattern before the rest follow.
Off an over-built cluster: the config-map dependencies are the hidden cost
By the time three teams have written deployment YAML assuming a cluster exists, the actual migration-off work is untangling dependencies nobody documented — service discovery, shared secrets, cross-namespace networking — not just moving the application code itself.
Off an over-built cluster: a full migration off isn't always the right call
Sometimes the fix for an over-built cluster is a smaller, better-configured one rather than abandoning Kubernetes entirely — especially once real investment has gone into the deployment pipeline around it. We'll assess honestly which is the smaller project.
Either direction: the database usually sets the real timeline
Running a stateful workload like a database inside Kubernetes, versus keeping it on a managed service outside the cluster, is a decision worth making deliberately — a managed database (RDS, Cloud SQL, Azure SQL) outside the cluster is still the right default for most teams, migration or not.
Hiring
What to look for when hiring a Kubernetes engineer
Someone who's deployed an app to a cluster following a tutorial is different from someone who's debugged why a cluster's nodes stopped scaling under real production load.
Incident experience with the scheduler, not just the app layer
Ask about a specific scheduling or autoscaling failure they've debugged — a pod stuck Pending, a node pool that didn't scale in time. The answer reveals whether they understand the layer underneath the YAML.
GitOps fluency, not just kubectl familiarity
Someone comfortable running kubectl apply by hand in production, without a reconciliation loop behind it, is a different skill level than someone who's built and maintained an ArgoCD or Flux pipeline a team actually trusts.
RBAC and NetworkPolicy literacy
A candidate who defaults to scoping access narrowly, and can explain why a namespace boundary alone doesn't provide network isolation, is the difference between a cluster that's secure by design and one that's secure until someone finds the gap.
Certifications (CKA, CKAD) as a signal, not a substitute
The Certified Kubernetes Administrator and Application Developer credentials show real, hands-on exam preparation. They don't show judgment about when a workload doesn't need a cluster at all — that only shows up in how someone talks through a real architecture decision.
Comfort saying the cluster is oversized
The engineers worth hiring will tell you when your node pool is bigger than your traffic justifies, instead of quietly leaving the padding in place because it's easier than the rightsizing conversation.
Related
Related services
What Kubernetes work usually connects to.
Questions
Common questions about Kubernetes development
What teams ask before a first call.
A cluster health audit is the smallest engagement here, and a full migration onto Kubernetes or a new cluster build-out is a larger one. An ongoing operations retainer is priced to the environment rather than sold as a fixed headcount.
What moves the number most is how much of the current cluster configuration lives only in someone's memory or a manual runbook, and how many services have to be containerized and sequenced during a migration. The audit exists to answer that before the rest gets quoted.
Designs cluster architecture — namespace structure, RBAC, autoscaling, storage — and builds the GitOps pipeline that deploys to it, so changes are reviewed and versioned rather than applied by hand. A good Kubernetes engineer also owns the parts that don't show up in a demo: resource requests set from real usage data, secrets management that isn't a base64-encoded ConfigMap, and an upgrade cadence that doesn't wait for a forced deprecation.
Maybe not yet. Kubernetes earns its operational overhead at specific thresholds — a service count in the dozens or more, a genuine multi-cloud requirement, or a platform team whose actual job is running the cluster. Below that, a managed container service is very often the cheaper, more reliable, and simpler choice, not just the easier one.
Our DevOps page covers this specific decision in more depth, since it's really a platform-choice question that comes before any Kubernetes-specific architecture work.
Use a managed one — EKS, GKE, or AKS — almost every time. Self-hosting your own control plane means patching etcd, managing quorum, and diagnosing control-plane failures yourself, and it's rarely justified outside specific regulatory or air-gapped requirements.
Letting the cloud provider run the control plane while your team focuses on what runs on top of it is the real middle ground most teams should land on.
A Deployment manages stateless, interchangeable pods — any replica can be replaced without consequence, which fits most application servers. A StatefulSet manages pods that need a stable identity and persistent storage tied to that identity across restarts, which fits databases, message brokers, and anything else where "which specific instance" matters.
Using a Deployment for a workload that actually needed a StatefulSet is one of the more common causes of data loss when a pod restarts, because the storage and identity guarantees a stateful workload needs simply aren't there.
Kubernetes Secrets are base64-encoded, not encrypted, by default unless you explicitly configure encryption at rest — a detail that surprises teams who assume the object type implies real protection. Most production clusters we build pair Kubernetes with an external secrets manager, synced in through an operator, rather than relying on the built-in object alone.
This is a decision worth making before the first secret is created, since migrating secret storage after the fact means touching every workload that reads one.
Yes. The real work is usually containerizing services correctly first — externalizing hidden state like local file writes or in-memory sessions — before orchestration adds any value, then sequencing the migration by dependency rather than by which service is easiest to move first.
We'll also tell you honestly if a service doesn't actually need to move — not everything in an estate benefits from running on a cluster, and a managed database or a serverless function is sometimes the better home for a specific piece even after the rest has moved.
Often, yes. A cluster health audit usually finds that the fix is a smaller, better-configured cluster with real RBAC boundaries and correctly set resource limits, not abandoning Kubernetes entirely — especially once real investment has already gone into the GitOps pipeline around it.
We'll assess your specific cluster honestly and tell you if a full migration off is actually the smaller project, which does happen, but isn't the default recommendation.