The number of users or the attraction of capital alone does not determine the time of migration to Kubernetes. Startups with high traffic and simple architecture may be stable on multiple managed VMs; teams with dozens of independent services, daily releases, and failover obligations a few nodes earlier than Kubernetes are valued.
Quick answer:When another host is not acceptable for a failure domain, workloads on multiple nodes must be scheduled, multiple teams have independent release, and the desired state/rollout standard generates more value than the cluster cost, the Kubernetes pilot makes sense.
Real signs of need.
- SLO requires endurance of node or zone failure.
- The number of service and manual deployments has exceeded the team's capacity.
- Workloads have different sources and timing.
- Several teams need standard access and self-service.
- Roll-out, autoscaling or policy declarative are often required.
- The cost of dedicated automation on VMs has increased from the shared platform.
If the database is still a single point of failure, the transfer of the app to the cluster may not change the SLO.
False signs.
Big companies use, we have microservice, we want to be cloud-native or Kubernetes automatically scale is not a requirement.
First requirement: Repeatable image
Each workload must have a copy image, correct main process, graceful shutdown, and external configuration. If the team is still patching inside the live container or a floating tag is deployed, Kubernetes will not hide the drift. The same artifact must be built in CI, tested, and digested to promote staging and production.
Second requirement: Health and Resource Profile
Readiness/liveness should be meaningful. Know the actual CPU and memory of each service for requests/limits; break down scheduling parameters or make OOM. Measure startup time, concurrency, and dependencies.Monitoring guideBaseline describes the decision needed.
Third requirement: CI/CD and Rollback
Manual manifest action from people's laptops does not make the cluster reliable. lint, policy, diff, approval, promotion, and copy registration are required. Code rollback must be compatible with data migration. Kubernetes executes rollout, but does not make business decisions and schema compatibility.
The fourth requirement: Observability.
Pods are ephemeral and may be portable; local logs and SSH-axis are not sufficient. Metric, log, trace, event, audit and correlation are required. alert should be from the service and user perspective, not just the number of pods. Without observability, self-healing can repeat the crash and shorten the evidence.
Requirement five: State strategy
PersistentVolume is not replication and backup alone. Managed database or object storage can reduce the risk of migration. If the stateful workload goes into the cluster, an operator, storage class, topology, backup and restore drill are required.
Control plane managed or self-managed?
Managed Kubernetes assigns patch and availability control plane to the provider, but node pool, network, workload, RBAC, cost and upgrade compatibility are still the responsibility of the team. The cluster gives more control and adds the etcd/control plane operation. For small teams, managed is usually a more logical checkpoint, rather than an automated response.
At least the team and the ownership.
There is no magic number for the number of people. Owners must be specific for the cluster, security, release and incident, and there must be real on-call coverage. If only one person knows Kubernetes, the bus factor and the time of the vacation are risk factors. Documents, runbooks, break-glass access and team training are part of the migration cost.
Governance and Guardrail.
The developer should not have cluster-admin access for each deployment. Define namespace, service account, RBAC limit, policy admission, quota and audit before self-service. Secrets should not appear in manifest plaintext or log pipeline. guardrail should provide quick feedback in CI; the vague policy that only blocks production encourages the team to bypass.
Upgrade and API deprecation cycles
Kubernetes and add-ons have lifetime support. Before any upgrade, check out out outdated APIs, compatibility ingress/CNI/CSI, node drain, PodDisruptionBudget, and replacement capacity. A test cluster and rollout node pool are required. If the team does not have regular time for this cycle, a higher-level managed platform may be a more appropriate choice.
Hidden costs
In addition to the node and control plane, load balancer, egress, storage, registry, log/metric, backup and multiple environments are costly. Over-estimated requests waste capacity and underestimate instability. Add engineering time for upgrade, policy and incident to the cost model.
Is one cluster enough for all environments?
Cluster sharing reduces costs but complicates the blast radius and access boundary. Namespace separation is not the same as account or cluster separation. Data sensitivity, teams, compliance and fault tolerance are metrics. Production and development should not affect resources without policies and quotas.
Network architecture and Ingress
Service discovery, ingress, TLS, DNS, and NetworkPolicy must be designed. Transferring Nginx and Compose ports to multiple objects without understanding the traffic path, outage. First document the flow of the client to the app and dependency.The Docker Network guideIt clarifies the basic concepts of name, port and exposure.
When is it worth it to autoscal?
When the workload is stateless, the appropriate metric and dependency capacity are specified. HPA on the CPU is not appropriate for each service; queue length or latency may be better.
The low-risk pilot.
- Choose a stateless and non-living service.
- SLO, take the cost and time of the current operation baseline.
- Prepare CI/CD, secret, probe and resource before deployment.
- Practice failure node, rollout and rollback.
- See log, metric and actual cost for at least one cycle.
- Compare the result to Compose/PaaS.
- Then decide on the public platform.
Pilot's success rate
It's not enough to just run the iPod. Measure deployment and recovery time, failure rate, number of manual steps, cost, on-call time, and developer satisfaction. If the platform team spends more time maintaining the tool and the release speed is not improved, review the scope or tool.
Pilot stop.
Write down what circumstances you won't continue to work on: over budget costs, no owner on-call, slower recovery than baseline, unresolved state dependence or security complexity without sufficient force. Pilot stop is not a failure; it prevents cost locking. Keep artifact, observations and gaps to be re-evaluated in a timely manner.
Disaster Recovery of the Cluster
The declarative workload definition is useful, but registry, secret, DNS, data and provider access must be recoverable. For self-management clusters, control planes, etc. also require a separate design; in managed service, check the region backup and reconstruction limitations. A second cluster without practicing cutover is just a cost, not a proven DR.
The migration route is a step-by-step process.
First, move the stateless service, then the low-risk worker and dependency. Don't move the database just to complete the chart. Design DNS/traffic cutover, rollback to the previous platform, and limited dual-running. Avoid big bang migration of multiple services and data at once.
When should we reevaluate the decision?
The decision is not necessarily permanent. After a noticeable change in the SLO, repeat the assessment of the number of teams, deployment frequency, multi-area need, or incident cost. Keep previous decision indicators and assumptions to be based on the next discussion. Periodic review prevents two extremes: early migration due to tool excitement and long stay on an architecture that no longer covers the failure domain or the speed of business deployment.
When are we not getting Kubernetes?
If the product-market fit is being tested, you have one or two services, deployment is low, and a VM has capacity, improving Compose/PaaS is likely to be more profitable.Compose and Kubernetes comparisonMaintain the ability to migrate in the future with a good image and contract.
Common Mistakes
- Migration simultaneously with app, database and CI
- No requests/limits and valid probes.
- A specialist without a successor.
- Cluster production without an upgrade plan.
- Assuming managed means no operation.
- Ignoring the excess and observability cost
- The definition of success is just the number of pods.
For independent assessment
If the actual cost and current operations have gone up but it's not clear Kubernetes is the cure,DevOps is a startup.It can assess readiness, SLO, cost and pilot without early commitment to a platform.
Common Questions
How many Kubernetes users are needed?
It doesn't have a fixed threshold; architecture, SLO, deployment and team are more important than the number of users.
Is Microservice the Kubernetes?
No, multiple services can be run with other tools. Operational complexity is the criterion.
Should we add the database to the cluster?
It's not necessary; managed databases are often an independent, less risky option.
How long does immigration take?
Depending on the maturity of the image, CI/CD, state and team, the pilot shows real-time better than the general estimate.