A useful Kubernetes discussion starts with the infrastructure team's waiting list. What is waiting: access approval, environment creation, releases or manual recovery after failure? A cluster cannot resolve a delayed contract or missing application tests. Repeated engineering work around starting and replacing applications is a more plausible target.
Consider a company running employee requests, an equipment catalogue and document processing. Product teams release independently, but each deployment needs special administrator instructions. Kubernetes can give them a common way to describe execution. Somebody still has to turn that mechanism into a service those teams can use.
Maintaining a declared state
A team specifies the image, replica count, resource requirements and configuration. Controllers compare the desired state with what exists and try to close the gap. When an instance is lost, the appropriate controller creates a replacement and the scheduler looks for somewhere to run it.
“Try” matters. Without available capacity, a reachable image or suitable storage, the replacement does not become ready. Kubernetes can act on rules; it cannot promise a resource that does not exist. Its official overview describes both capabilities and boundaries.
Someone must still build and test the application. Kubernetes does not turn source code into correct software or determine whether an employee request was processed properly. Nor must every database move into the cluster: an application can use a separately managed database.
Starting is not the same as serving
The document service has started but is still loading templates. Routing requests to it immediately creates failures. Readiness should represent its ability to accept work. Liveness answers a different question: would restarting the process help? Confusing them can cause useless restarts during an external database outage.
These are application rules executed by the platform; the Health Checks article explores the distinction. Updates also require correct shutdown: stop taking documents, finish current work or leave it safe to retry.
A gradual rollout does not establish version compatibility. Old and new instances may coexist and must understand shared data and interfaces. Restoring an old image does not undo a database migration. A Deployment controls instance replacement, while the consequences for business operations remain the team's responsibility.
Resource settings need evidence
A resource request helps the scheduler choose a node. A limit constrains use of the corresponding resource. They serve different purposes. Understated requests may place workloads together that interfere under real load; exaggerated requests can leave capacity poorly used.
A CPU limit can restrict available processing time. Memory pressure beyond the allowed allocation may terminate a process rather than merely slow it. Test settings against representative work, including startup and large documents. The resource-management documentation explains these distinctions.
Increasing replica counts needs an autoscaling policy and infrastructure with room to grow. A database or external processor may not tolerate the resulting increase in requests. The useful capacity measure is completed work across the whole workflow, not the number of green application instances.
A shared cluster can create a shared incident
Putting products in one cluster simplifies some tasks but creates common dependencies: networking, storage, permissions and platform extensions. Namespaces alone do not provide complete isolation. Appropriate access controls, quotas and network restrictions are needed; some risks justify separate clusters.
Replica placement must match the failure being protected against. Several copies that depend on one node or one failure zone do not survive its loss simply because there are several of them. Check remaining capacity and data access after relocation.
For node maintenance, a PodDisruptionBudget can limit certain voluntary disruptions. It does not prevent hardware failure or replace the application's rollout controls. The disruption guidance states these boundaries. Knowing the exact protection is more useful than treating a configured budget as an availability guarantee.
Managed still needs an owner
A provider may operate the control plane and other components, depending on the offering. Applications, data, permissions and workload configuration remain company concerns. Someone must also assess platform upgrades, watch spending and investigate why work cannot be scheduled.
That responsibility needs people and a useful outcome for product teams. Otherwise the former queue for manual deployments becomes a queue for the only engineer who understands the cluster. Ask which actions developers will perform independently and where specialist involvement remains necessary.
There is no universal service count at which Kubernetes pays off. Release frequency, repeated operational work, placement requirements and maintenance capability matter. Managed container execution may solve the same problem with less platform work owned by the company.
A pilot should therefore include the ordinary development experience, not just an administrator's demonstration. Can a team obtain a test environment, find its logs, change a resource setting and release a fix through a supported process? Requiring a platform specialist at every step changes the economics considerably.
Compare a complete operating cycle
Take a representative service through deployment, increased load, instance failure, node maintenance and version reversal. Add data recovery for stateful workloads. Record engineering intervention, team waiting time and user-visible consequences, including attempts that fail.
Compare this with the current setup and a simpler managed platform. Include on-call work, upgrades and maintenance of the developer-facing deployment process. An impressive demonstration in which a deleted container reappears tests only a small fraction of the responsibility the company is considering taking on.