Kubernetes ReplicaSet vs Deployment: Essential Guide to Choosing the Right One 2025
Post 8 of 70 in the series “Mastering Kubernetes: A Practical Journey from Beginner to CKA”
Table of Contents
🔥 TL;DR
- ReplicaSets ensure a specific number of identical pods are always running – they’re the workhorses behind pod scaling
- Deployments manage ReplicaSets and add rolling updates, rollbacks, and declarative updates – use them 99% of the time
- Direct ReplicaSet usage is rare but crucial for understanding how Kubernetes maintains desired state
- Rolling updates let you deploy new versions with zero downtime by gradually replacing old pods with new ones
- Understanding both controllers is essential for debugging scaling issues and deployment failures
Introduction: Kubernetes Replicaset vs Deployment
Imagine you’re managing a popular restaurant chain. You need to ensure each location has exactly three chefs working at all times – if one chef calls in sick, you immediately hire a replacement. That’s what ReplicaSets do for pods. But now imagine you want to train all your chefs on a new recipe without shutting down any restaurants. You’d gradually replace chefs one by one, ensuring service never stops. That’s what Deployments add on top of ReplicaSets – intelligent management of changes over time.
What we’ll learn today:
- How ReplicaSets maintain your desired pod count through failures and scaling
- When and why Deployments are almost always the better choice
- Implementing zero-downtime rolling updates for production applications
- Debugging common scaling and update scenarios that trip up teams
Why this matters: I’ve debugged countless production incidents where teams created ReplicaSets directly instead of using Deployments, then struggled with updates. I’ve also seen applications go down because rolling update configurations weren’t properly tested. Understanding the relationship between these controllers isn’t just academic – it’s what enables reliable, scalable applications. Companies like GitHub and Shopify deploy code hundreds of times per day using these exact patterns.
Series context: In our previous post, we mastered individual pods – how to create, configure, and debug them. Now we’re scaling up to understand how Kubernetes manages multiple pods automatically. The single pod you learned to create is the template that ReplicaSets use to maintain availability, and Deployments use to manage updates safely.
Prerequisites
What you need to know:
- Pod fundamentals and YAML structure (covered in Post #7)
- Basic understanding of labels and selectors
- Kubernetes cluster architecture concepts
- kubectl command basics
📌 Quick Refresher: ReplicaSets use label selectors to find and manage pods. If you create a pod with labels that match a ReplicaSet’s selector, the ReplicaSet will “adopt” it and count it toward the desired replica count.
Tools required:
- Access to a multi-node Kubernetes cluster (for realistic scaling demos)
- kubectl with cluster admin privileges
- Text editor for YAML manifests
- Terminal access for real-time monitoring
Previous posts to read:
- Post #7: Your First Pod (essential for understanding what gets replicated)
- Post #6: Kube-Scheduler (helpful for understanding where replicas get placed)
Estimated time: 45-55 minutes including hands-on scaling and update experiments
Step-by-Step Tutorial
Theory First: Understanding the Controller Hierarchy
Before diving into YAML, let’s understand the relationship between these controllers:
Why did Kubernetes create this three-layer architecture instead of having Deployments manage pods directly?
Separation of concerns. ReplicaSets handle the “how many” problem (scaling), while Deployments handle the “how to change” problem (updates). This design lets you swap out the update strategy without changing the scaling logic.
Step 1: Creating and Understanding ReplicaSets
Let’s start by creating a ReplicaSet to see how it maintains pod replicas:
# basic-replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: web-server-rs
labels:
app: web-server
controller: replicaset
spec:
replicas: 3 # Desired number of pod replicas
selector:
matchLabels:
app: web-server
version: v1
template: # Pod template - same as pod spec
metadata:
labels:
app: web-server
version: v1
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
containers:
- name: nginx
image: nginxinc/nginx-unprivileged:1.20-alpine # Non-root nginx image
ports:
- containerPort: 8080 # Non-root nginx runs on 8080
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
Creating and observing ReplicaSet behavior:
# Create the ReplicaSet
kubectl apply -f basic-replicaset.yaml
# Watch pods get created
kubectl get pods -l app=web-server -w
# Check ReplicaSet status
kubectl get replicaset web-server-rs
kubectl describe replicaset web-server-rs
🛠️ Your Turn: Create the ReplicaSet and verify all 3 pods are running:
kubectl apply -f basic-replicaset.yaml
kubectl get pods -l app=web-server --show-labels
kubectl get rs web-server-rs -o wide
Step 2: Testing ReplicaSet Self-Healing
Now let’s see the ReplicaSet’s self-healing in action:
# Delete one pod to simulate failure
POD_TO_DELETE=$(kubectl get pods -l app=web-server -o jsonpath='{.items[0].metadata.name}')
echo "Deleting pod: $POD_TO_DELETE"
kubectl delete pod $POD_TO_DELETE
# Watch the ReplicaSet create a replacement immediately
kubectl get pods -l app=web-server -w
⚠️ **Caution:** If you delete a ReplicaSet without deleting its pods, you create "orphaned" pods that are no longer managed by any controller. Always use Deployments in production to avoid this scenario.
# Scale the ReplicaSet up and down
kubectl scale replicaset web-server-rs --replicas=5
kubectl get pods -l app=web-server
kubectl scale replicaset web-server-rs --replicas=2
kubectl get pods -l app=web-server -w
Understanding what happened:
# Check events to see the controller's decisions
kubectl get events --sort-by=.metadata.creationTimestamp | grep web-server-rs
# Examine the ReplicaSet controller's work
kubectl describe replicaset web-server-rs | grep -A 10 Events
🛠️ Your Turn: Test self-healing by deleting multiple pods at once:
kubectl delete pods -l app=web-server --wait=false
kubectl get pods -l app=web-server -w
# Watch the ReplicaSet quickly recreate all missing pods
Step 3: Creating Your First Deployment
Now let’s see why Deployments are usually better. Here’s the same application as a Deployment:
# web-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server-deployment
labels:
app: web-server
controller: deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Can create 1 extra pod during updates
maxUnavailable: 1 # Can have 1 pod unavailable during updates
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
version: v2 # Note: different version label
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
containers:
- name: nginx
image: nginxinc/nginx-unprivileged:1.21-alpine # Newer version, non-root
ports:
- containerPort: 8080 # Non-root nginx port
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
Observing Deployment structure:
# Create the Deployment
kubectl apply -f web-deployment.yaml
# See how Deployment creates ReplicaSet automatically
kubectl get deployments
kubectl get replicasets
kubectl get pods
# Notice the naming pattern: deployment-name-replicaset-hash-pod-hash
kubectl get pods -o wide
🛠️ Your Turn: Create the deployment and explore the object hierarchy:
kubectl apply -f web-deployment.yaml
kubectl get deploy,rs,pods -l app=web-server
kubectl describe deployment web-server-deployment | head -20
Step 4: Rolling Updates in Action
Here’s where Deployments really shine – zero-downtime updates:
# Check current deployment status
kubectl rollout status deployment/web-server-deployment
# Update the image to trigger a rolling update
kubectl set image deployment/web-server-deployment nginx=nginxinc/nginx-unprivileged:1.22-alpine
# Watch the rolling update happen in real-time
kubectl rollout status deployment/web-server-deployment -w
# In another terminal, watch pods being created and terminated
kubectl get pods -l app=web-server -w --show-labels
Understanding the rolling update process:
# See the ReplicaSet history
kubectl get replicasets -l app=web-server
# Check rollout history with timestamps
kubectl rollout history deployment/web-server-deployment
# View detailed information about a specific revision
kubectl rollout history deployment/web-server-deployment --revision=2
📌 **Note:** By default, Deployments retain only 10 revisions. Set `revisionHistoryLimit` in your deployment spec for longer audit trails or compliance requirements.
Step 5: Advanced Rolling Update Strategies
Let’s customize the rolling update behavior for different scenarios:
Conservative Update Strategy (Minimal Risk)
# conservative-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: conservative-app
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Only 1 extra pod at a time
maxUnavailable: 0 # Never have fewer than desired replicas
selector:
matchLabels:
app: conservative-app
template:
metadata:
labels:
app: conservative-app
spec:
containers:
- name: app
image: nginx:alpine
resources:
requests:
cpu: "50m"
memory: "64Mi"
Aggressive Update Strategy (Fast Deployment)
# aggressive-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: aggressive-app
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3 # Create 3 extra pods
maxUnavailable: 2 # Can have 2 pods down
selector:
matchLabels:
app: aggressive-app
template:
metadata:
labels:
app: aggressive-app
spec:
containers:
- name: app
image: nginx:alpine
resources:
requests:
cpu: "50m"
memory: "64Mi"
🛠️ Your Turn: Compare update speeds between conservative and aggressive strategies:
# Create both deployments
kubectl apply -f conservative-deployment.yaml
kubectl apply -f aggressive-deployment.yaml
# Trigger updates simultaneously and compare
kubectl set image deployment/conservative-app app=nginx:1.21-alpine &
kubectl set image deployment/aggressive-app app=nginx:1.21-alpine &
# Watch both updates
kubectl get pods -l app=conservative-app -w &
kubectl get pods -l app=aggressive-app -w &
🧠 Knowledge Check
What happens if you delete a ReplicaSet but not its pods?
The pods continue running but become “orphaned” – no controller manages them anymore
Can you have maxSurge: 0 and maxUnavailable: 0 in a rolling update?
No, this would prevent any updates from happening since no pods could be created or terminated
Why might you choose ReplicaSet over Deployment?
Very rare cases where you never want updates, like persistent storage controllers or when building custom controllers
Step 6: Rollback and Recovery Scenarios
When updates go wrong, Deployments provide powerful recovery options:
# Simulate a problematic deployment
kubectl set image deployment/web-server-deployment nginx=nginxinc/nginx-unprivileged:broken-tag
# Watch it fail
kubectl rollout status deployment/web-server-deployment
# Rollback to previous version
kubectl rollout undo deployment/web-server-deployment
# Verify rollback succeeded
kubectl get pods -l app=web-server -o jsonpath='{.items[*].spec.containers[0].image}'
# Should show previous image version
# Rollback to a specific revision
kubectl rollout undo deployment/web-server-deployment --to-revision=1
# Pause a deployment mid-rollout (useful for canary testing)
kubectl set image deployment/web-server-deployment nginx=nginxinc/nginx-unprivileged:1.23-alpine
kubectl rollout pause deployment/web-server-deployment
# Check status - some pods will be new version, some old
kubectl get pods -l app=web-server --show-labels
# Resume when ready
kubectl rollout resume deployment/web-server-deployment
💡 **Future Learning:** For more advanced patterns like canary deployments, stay tuned for Post #25 on Advanced Deployment Strategies.
Advanced rollback scenarios:
# Set revision history limit to control storage
kubectl patch deployment web-server-deployment -p '{"spec":{"revisionHistoryLimit":5}}'
# Scale during an update (affects both old and new ReplicaSets)
kubectl scale deployment web-server-deployment --replicas=10
# Check resource usage during updates
kubectl top pods -l app=web-server
🛠️ Your Turn: Practice emergency rollback procedures:
# Deploy a broken image
kubectl set image deployment/web-server-deployment nginx=nginxinc/nginx-unprivileged:nonexistent
# Wait for failure, then quick rollback
kubectl rollout undo deployment/web-server-deployment
# Verify application is healthy again
kubectl get pods -l app=web-server
kubectl get pods -l app=web-server -o jsonpath='{.items[*].spec.containers[0].image}'
# Should show the previous working image version
Verification Steps:
- ✅ You understand how ReplicaSets maintain desired pod count
- ✅ You can explain why Deployments are preferred over direct ReplicaSet usage
- ✅ You’ve successfully performed rolling updates and rollbacks
- ✅ You can customize update strategies for different scenarios
- ✅ You know how to debug scaling and update issues
Real-World Scenarios
Scenario 1: E-commerce Platform Black Friday Preparation
The Challenge: Last year, I worked with an e-commerce company preparing for Black Friday. They needed to scale their checkout service from 5 replicas to 50, then deploy a critical bug fix without any downtime during peak shopping hours.
Initial scaling strategy:
# checkout-service-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-service
labels:
app: checkout-service
business-critical: "true"
spec:
replicas: 5 # Normal traffic load
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2 # Can create 2 extra pods during updates
maxUnavailable: 0 # Never reduce capacity during updates
selector:
matchLabels:
app: checkout-service
template:
metadata:
labels:
app: checkout-service
version: v2.1.0
spec:
containers:
- name: checkout
image: company/checkout:v2.1.0
ports:
- containerPort: 8080
resources:
requests:
cpu: "300m"
memory: "512Mi"
limits:
cpu: "1000m"
memory: "1Gi"
# Careful health checks for financial transactions
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 60 # Longer delay for complex startup
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 2 # Quick removal from load balancer
# Pod-level configuration
restartPolicy: Always
terminationGracePeriodSeconds: 30
# Security context
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
# Image pull secrets
imagePullSecrets:
- name: company-registry-secret
Black Friday scaling and deployment:
# Pre-traffic scaling (30 minutes before expected surge)
kubectl scale deployment checkout-service --replicas=50
# Verify successful scaling
kubectl get deployment checkout-service -o=jsonpath='{.status.availableReplicas}'
# Should show: 50
# Monitor pod distribution across nodes
kubectl get pods -l app=checkout-service -o wide
kubectl get pods -l app=checkout-service -o wide | wc -l
# Should show: 50 running pods
# Critical bug fix deployment during peak traffic
kubectl set image deployment/checkout-service checkout=company/checkout:v2.1.1
Black Friday scaling and deployment:
# Pre-traffic scaling (30 minutes before expected surge)
kubectl scale deployment checkout-service --replicas=50
# Monitor pod distribution across nodes
kubectl get pods -l app=checkout-service -o wide
# Critical bug fix deployment during peak traffic
kubectl set image deployment/checkout-service checkout=company/checkout:v2.1.1
# Real-time monitoring during update
kubectl get pods -l app=checkout-service --watch &
kubectl rollout status deployment/checkout-service -w
# Metrics showed zero downtime and successful handling of 10x traffic
Results achieved:
- Scaled from 5 to 50 replicas in under 3 minutes
- Zero-downtime deployment of critical fix during peak traffic
- Handled 10x normal transaction volume without service interruption
- Automatic scale-down after traffic returned to normal
Scenario 2: Microservices Update Coordination
Netflix’s Deployment Patterns (based on public engineering talks):
# Sophisticated deployment for microservices
apiVersion: apps/v1
kind: Deployment
metadata:
name: recommendation-service
annotations:
deployment.kubernetes.io/revision: "1"
spec:
replicas: 20
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # Allow 25% extra pods (5 additional)
maxUnavailable: 25% # Allow 25% unavailable (5 pods down)
selector:
matchLabels:
app: recommendation-service
template:
metadata:
labels:
app: recommendation-service
version: v3.2.1
spec:
containers:
- name: recommendation-engine
image: netflix/recommendations:v3.2.1
ports:
- containerPort: 8080
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2000m"
memory: "4Gi"
# Aggressive health checks for user-facing services
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 45
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 15
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
env:
- name: JAVA_OPTS
value: "-Xms1g -Xmx3g -XX:+UseG1GC"
- name: SERVICE_VERSION
value: "v3.2.1"
# Pod-level configuration
restartPolicy: Always
terminationGracePeriodSeconds: 30
# Security context
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
Enterprise deployment coordination:
# Coordinated deployment across multiple services
kubectl set image deployment/user-service app=netflix/user:v2.1.0
kubectl set image deployment/recommendation-service recommendation-engine=netflix/recommendations:v3.2.1
kubectl set image deployment/content-service content=netflix/content:v1.8.0
# Monitor all deployments simultaneously
kubectl get deployments -w
# Automated rollback if any service fails health checks
for deployment in user-service recommendation-service content-service; do
if ! kubectl rollout status deployment/$deployment --timeout=300s; then
kubectl rollout undo deployment/$deployment
fi
done
Key patterns for enterprise deployments:
- Percentage-based surge/unavailable: Scales with replica count automatically
- Sophisticated health checks: Separate liveness and readiness endpoints
- Resource optimization: Carefully tuned based on service profiling
- Coordinated rollbacks: Automated failure detection and recovery
- Version tracking: Clear labeling for deployment correlation
Common enterprise mistakes I’ve observed:
- Using ReplicaSets directly instead of Deployments (makes updates painful)
- Overly aggressive maxUnavailable settings causing service degradation
- Not testing rollback procedures before they’re needed
- Insufficient resource requests leading to pod eviction during updates
- Missing or inadequate health checks causing traffic to broken pods
Troubleshooting Tips
Common Error 1: “Deployment stuck in progressing state”
Issue: Rolling update never completes successfully Solution:
# Check deployment status and conditions
kubectl describe deployment <deployment-name> | grep -A 10 Conditions
# Look for pod startup issues
kubectl get pods -l app=<app-name>
kubectl describe pod <failing-pod-name>
# Common causes and fixes:
# 1. Image pull failures
kubectl get events --sort-by=.metadata.creationTimestamp | grep Failed
# 2. Readiness probe failures
kubectl logs <pod-name>
kubectl describe pod <pod-name> | grep -A 5 Readiness
# 3. Resource constraints
kubectl describe nodes | grep -A 5 "Allocated resources"
# Emergency rollback
kubectl rollout undo deployment/<deployment-name>
Common Error 2: “ReplicaSet scaling issues”
Issue: Pods not scaling up or being terminated unexpectedly
Solution:
# Check ReplicaSet status
kubectl describe replicaset <rs-name> | grep -A 10 Events
# Verify label selectors match
kubectl get replicaset <rs-name> -o jsonpath='{.spec.selector}'
kubectl get pods --show-labels | grep <app-name>
# Check for resource quotas
kubectl describe namespace <namespace> | grep -A 10 "Resource Quotas"
# Look for node capacity issues
kubectl describe nodes | grep -E "Allocatable|Non-terminated Pods"
Common Error 3: “Rolling update taking too long”
Issue: Update process is slower than expected Solution:
# Check current rollout status
kubectl rollout status deployment/<deployment-name> --watch=true
# Analyze update strategy settings
kubectl get deployment <deployment-name> -o jsonpath='{.spec.strategy}'
# Monitor pod readiness delays
kubectl get pods -l app=<app-name> --watch
# Common optimizations:
# 1. Increase maxSurge for faster updates
kubectl patch deployment <deployment-name> -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":"50%"}}}}'
# 2. Decrease readiness probe delays
kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container-name>","readinessProbe":{"initialDelaySeconds":5}}]}}}}'
Common Error 4: “Pods stuck in terminating state during updates”
Issue: Old pods won’t terminate cleanly during rolling updates Solution:
# Check for stuck terminating pods
kubectl get pods -l app=<app-name> | grep Terminating
# Check pod logs for shutdown issues
kubectl logs <terminating-pod-name>
# Examine termination grace period
kubectl get pod <pod-name> -o jsonpath='{.spec.terminationGracePeriodSeconds}'
# Force delete if necessary (use carefully)
kubectl delete pod <pod-name> --force --grace-period=0
# Prevent future issues by handling SIGTERM properly in your application
Debug Commands:
# Essential scaling and deployment debugging
kubectl get deploy,rs,pods -l app=<app-name> # Full hierarchy view
kubectl describe deployment <deployment-name> # Detailed deployment info
kubectl rollout status deployment/<deployment-name> # Current rollout status
kubectl rollout history deployment/<deployment-name> # Deployment history
# Scaling and resource analysis
kubectl top pods -l app=<app-name> # Resource usage
kubectl get events --sort-by=.metadata.creationTimestamp | tail -20 # Recent events
kubectl describe nodes | grep -A 10 "Allocated resources" # Node capacity
# Update monitoring
kubectl get pods -l app=<app-name> -w --show-labels # Watch pod changes
kubectl logs -f deployment/<deployment-name> # Follow deployment logs
Where to get help:
- Kubernetes Deployments Documentation
- ReplicaSets Documentation
- CNCF Slack #kubernetes-users channel
Next Steps
What’s coming next: In Post #9, we’ll explore “Services: Exposing Your Applications to the World.” You’ll discover how to provide stable network endpoints for your scaled applications, building on the multiple pods we can now create and manage. Services solve the “how do I reach my pods?” problem that becomes critical once you have multiple replicas.
Additional learning:
- Experiment with Horizontal Pod Autoscaling for automatic scaling
- Explore DaemonSets for node-specific workloads
Practice challenges:
- Scaling strategies: Test different maxSurge/maxUnavailable combinations and measure update times
- Failure scenarios: Practice rollbacks during simulated outages and resource constraints
- Resource optimization: Find optimal resource requests/limits for smooth scaling
- Multi-service coordination: Deploy related services with proper update sequencing
- Custom metrics scaling: Implement HPA with custom metrics for advanced scaling scenarios
Community engagement: Share your scaling adventures! What’s the largest deployment you’ve managed? Which rolling update strategies work best for your applications? Have you discovered any creative patterns for coordinating multiple service updates?
FAQ Section
When would I ever create a ReplicaSet directly instead of using a Deployment?
Very rarely! The main cases are: building custom controllers, managing legacy applications that should never update, or specific batch job patterns. 99% of the time, use Deployments.
Can I change the rolling update strategy of a running Deployment?
Yes! You can modify the strategy using kubectl patch or by editing the deployment. The new strategy takes effect on the next update.
What happens if I scale a Deployment during a rolling update?
Kubernetes adjusts both the old and new ReplicaSets proportionally. The scaling operation applies to the total desired count across both ReplicaSets.
How do I ensure zero downtime during updates?
Set maxUnavailable: 0, implement proper readiness probes, ensure sufficient cluster resources for surge pods, and test rollback procedures. Also verify your application handles graceful shutdown.
Can multiple Deployments manage the same pods?
No, this would cause conflicts. Each pod should be managed by exactly one controller. However, multiple Deployments can have similar label selectors as long as the full selector is unique.
Complete Production Deployment Template
# production-deployment-template.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: production-app
labels:
app: production-app
version: v1.0.0
tier: api
annotations:
deployment.kubernetes.io/revision: "1"
kubernetes.io/change-cause: "Initial deployment v1.0.0"
spec:
replicas: 6
revisionHistoryLimit: 5 # Keep last 5 versions for rollback
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2 # Can create 2 extra pods during update
maxUnavailable: 1 # Can have 1 pod unavailable
selector:
matchLabels:
app: production-app
template:
metadata:
labels:
app: production-app
version: v1.0.0
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
containers:
- name: app
image: myregistry.io/production-app:v1.0.0
ports:
- containerPort: 8080
name: http
- containerPort: 9090
name: metrics
# Resource management
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "1000m"
memory: "512Mi"
# Environment configuration
env:
- name: ENV
value: "production"
- name: LOG_LEVEL
value: "info"
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
# Health checks
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
# Graceful shutdown
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 15"]
# Volume mounts
volumeMounts:
- name: config
mountPath: /etc/config
readOnly: true
- name: temp
mountPath: /tmp
# Pod-level configuration
restartPolicy: Always
terminationGracePeriodSeconds: 30
# Volumes
volumes:
- name: config
configMap:
name: app-config
- name: temp
emptyDir:
sizeLimit: 1Gi
# Image pull secrets
imagePullSecrets:
- name: registry-secret
</details>
🔗 Series Navigation
Previous: Post #7 – Your First Pod: From YAML to Running Container
Next: Post #9 – Services: Exposing Your Applications to the World
Progress: You’re now 11% through the Kubernetes Fundamentals series! 🎉
💡 Pro Tip: Always test your rolling update strategy in a staging environment that mirrors production. Pay special attention to resource requests – insufficient resources can cause updates to stall when the cluster can’t create surge pods.
📧 Never miss an update: Subscribe to get notified when new posts in this series are published. Next, we’re exploring Services – the networking layer that makes your scaled applications reachable and reliable!
Tags: kubernetes, replicasets, deployments, rolling-updates, scaling, controllers, zero-downtime, production-deployment, troubleshooting, cka-prep