The Monday Morning That Changed Everything
I watched a senior engineer stare at his laptop screen for three solid minutes, completely silent, while our production traffic ground to a halt. We had just pushed what should have been a routine update to our user service. Instead, half our pods were stuck in a crash loop, and the other half were serving stale data from a cache that should have been cleared twenty minutes ago.
The rollout strategy we had chosen looked perfect in our staging environment. Rolling updates with readiness probes, graceful shutdown handling, the works. But production has a way of exposing assumptions you didn’t know you were making. That morning taught me more about Kubernetes deployment strategies than six months of documentation reading ever could.
Start With Recreate, Then Graduate
Every team wants to jump straight to blue-green deployments or canary releases. I get it. The advanced strategies sound impressive in architecture reviews. But if you’re running your first production Kubernetes workload, start with the recreate strategy. Yes, you’ll have downtime. Yes, it feels primitive. But you’ll understand exactly what’s happening when things go wrong.
The recreate strategy terminates all existing pods before creating new ones. It’s brutal and obvious. When I work with teams deploying their first service, I make them use recreate for at least two weeks. You learn how long your application actually takes to start up. You discover which dependencies fail during pod initialization. You figure out if your health checks are lying to you.
Here’s what a basic recreate deployment looks like in practice. Set your strategy type to Recreate in your deployment spec. Watch the old pods terminate completely before new ones start. Time the entire process from kubectl apply to full service availability. This baseline timing becomes crucial when you move to more sophisticated strategies.
Rolling Updates: The Default You Need to Understand
Once you’ve mastered recreate, rolling updates become your daily driver. Kubernetes defaults to rolling updates for good reason. They provide zero-downtime deployments when configured correctly. But that “when configured correctly” part is where most teams stumble.
The key parameters are maxUnavailable and maxSurge. I typically start new teams with maxUnavailable set to 0 and maxSurge set to 1. This means Kubernetes will create one new pod before terminating any old pods. Your service stays at full capacity throughout the rollout. It’s conservative, but it works.
Here’s where teams often mess up. They set maxUnavailable to 25% to speed up deployments, then wonder why their service becomes unresponsive during updates. The math is unforgiving. If you’re running 4 replicas and set maxUnavailable to 25%, you lose 1 pod immediately. If that remaining capacity can’t handle your traffic, users notice.
When Simple Strategies Aren’t Enough
You’ll know it’s time for advanced strategies when rolling updates start causing problems they’re supposed to solve. Maybe your application takes 60 seconds to warm up its caches, and users hit cold pods during rollouts. Maybe you need to test new versions with real traffic before committing fully. These are signals to consider blue-green or canary deployments.
Blue-green deployments run two identical production environments. You deploy to the inactive environment, verify everything works, then switch traffic over. The switch is instant, and rollback is just another switch. I’ve seen this work brilliantly for teams with complex startup sequences or strict uptime requirements. The downside is resource usage. You’re running double capacity during deployments.
Canary deployments gradually shift traffic from old to new versions. Start by sending 5% of requests to the new version. If metrics look good, increase to 25%, then 50%, then 100%. This approach catches issues before they affect all users. But canary deployments require sophisticated traffic splitting and monitoring. Don’t attempt this until your observability stack is rock solid.
The Infrastructure Nobody Talks About
Deployment strategies are only as good as the infrastructure supporting them. I’ve seen perfect blue-green setups fail because the load balancer took 30 seconds to recognize new endpoints. I’ve watched canary deployments become meaningless because the service mesh wasn’t configured to respect traffic weights.
Your ingress controller matters enormously. NGINX Ingress Controller handles endpoint updates differently than Traefik or Istio Gateway. Test how quickly your chosen controller picks up new pods and drops old ones. Measure this in your actual environment with your actual traffic patterns. Don’t rely on vendor claims.
Readiness and liveness probes deserve special attention. Your readiness probe should verify that your application can actually serve traffic, not just that it has started. I typically implement readiness probes that check database connectivity and cache warmth. If your probe passes but users get 500 errors, the probe is wrong.
Consider how your application shuts down. Kubernetes sends SIGTERM, waits for your configured grace period, then sends SIGKILL. If your application doesn’t handle SIGTERM properly, rolling updates become disruptive even with perfect configuration. Implement graceful shutdown that finishes in-flight requests but rejects new ones.
Building Confidence Through Repetition
The best deployment strategy is the one your team can execute confidently under pressure. That means practice. Run deployments during business hours. Simulate failures during rollouts. Document exactly what happens when things go wrong and how to recover quickly.
Keep deployment logs for every release. Note timing, resource usage, and any anomalies. Over time, you’ll see patterns that inform better strategies. Maybe your Java service needs 2 minutes to reach full performance, suggesting different maxSurge settings. Maybe database migrations during deployments cause cascading failures, pointing toward maintenance windows.
What deployment strategy will you try first? Start simple, measure everything, and graduate to complexity only when simpler approaches create real problems. The infrastructure will teach you what it needs if you listen carefully enough.