Search for a command to run...
No comments yet. Be the first to comment.
Follow my journey from DevOps Engineer to Kubestronaut as I explore Kubernetes, CNCF certifications, cloud-native technologies, and hands-on learning. In this series, I share my experiences preparing for and passing certifications such as CKA, CKAD, and CKS, along with exam strategies, study resources, troubleshooting lessons, and practical insights gained from real-world Kubernetes environments. Whether you're just starting with Kubernetes or pursuing advanced CNCF certifications, I hope these experiences help guide your own cloud-native journey.
When I first started learning Kubernetes, I thought that if a Pod showed a Running status, everything was working correctly. The application was running.The container hadn’t crashed.The deployment was
Kubernetes Control Plane explained in a practical way for engineers who manage real-world clusters. Introduction When I first started learning Kubernetes, I could create Pods, Deployments, and Service
Kubernetes networking is one of the most important — and often most confusing — topics for beginners. Pods have IP addresses, Services have virtual IPs, DNS magically resolves names, Ingress routes tr
One of the most common questions developers ask when they start working with Kubernetes is: “What actually happens when a user sends a request to my application?” We deploy Pods, create Services, co
Most developers know that Kubernetes can automatically restart failed applications. But have you ever wondered what actually happens behind the scenes when a Pod crashes? When I first started learning
When developers first start learning Kubernetes, they quickly understand Pods and Deployments. You create a Deployment, Kubernetes creates Pods, and your application starts running. Simple, right? Not
Shahzad Ahmad | Kubernetes, DevOps & Cloud Native Journey
32 posts
Senior DevOps Engineer documenting my journey through Kubernetes, CNCF certifications, cloud-native technologies, platform engineering, and automation. Here you'll find hands-on tutorials, certification experiences (CKA, CKAD, CKS), exam strategies, troubleshooting guides, and lessons learned from real-world DevOps and Kubernetes environments. My goal is to share practical knowledge, help others in their cloud-native journey, and ultimately document the path from DevOps Engineer to Kubestronaut.
Moving Beyond “kubectl apply” and Understanding What Makes Applications Production-Ready
When I first started working with Kubernetes, I thought my responsibility as a developer ended once my container image was built and deployed.
Write a Dockerfile.
Build an image.
Create a Deployment.
Done.
Or so I thought.
As I spent more time preparing for CNCF certifications and working with production workloads, I realized Kubernetes provides far more than just a platform to run containers. It offers a rich set of features that help developers build resilient, scalable, secure, and maintainable applications.
The problem is that many developers only interact with Deployments and Pods while missing the features that make Kubernetes truly powerful.
In this article, I’ll share the Kubernetes features every developer should understand, even if you’re not a platform engineer.
One of the first mistakes developers make is embedding environment-specific values directly inside applications.
Things like:
Database URLs
Feature flags
API endpoints
Logging configurations
should not be hardcoded.
Kubernetes provides ConfigMaps to separate configuration from application code.
Instead of rebuilding an image for every environment, the same container image can run in:
Development
Testing
Staging
Production
with different configurations.
This follows the Twelve-Factor App methodology and simplifies deployments significantly.
Example:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
APP_ENV: production
LOG_LEVEL: info
Your application simply reads these values as environment variables.
Passwords and API keys should never be stored in:
Git repositories
Docker images
Source code
Kubernetes Secrets provide a mechanism to store sensitive data separately from application logic.
Examples include:
Database passwords
TLS certificates
OAuth tokens
Cloud credentials
Security incidents often happen because credentials are exposed accidentally.
Using Secrets makes security practices much cleaner and easier to manage.
Applications sometimes become unhealthy without actually crashing.
Examples:
Deadlocks
Memory issues
Hung threads
Stuck database connections
Without health checks, Kubernetes assumes the application is healthy.
A Liveness Probe tells Kubernetes:
“If this endpoint stops responding, restart my container.
Example:
livenessProbe:
httpGet:
path: /health
port: 8080
Many production outages can be resolved automatically when Kubernetes is allowed to restart unhealthy containers.
An application may be running but not ready to serve requests.
Examples:
Startup still in progress
Database connection not established
Cache not initialized
A Readiness Probe prevents traffic from reaching the application until it is actually ready.
Without readiness probes, users may receive errors during deployments and startup events.
Containers are not infinite.
Every application consumes:
CPU
Memory
Kubernetes allows developers to specify how much resources an application requires.
Example:
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
Proper resource settings help:
Prevent noisy neighbors
Improve scheduling
Reduce cluster costs
Avoid unexpected OOMKills
One of Kubernetes’ most valuable features is automatic scaling.
Instead of manually increasing replicas, HPA can scale applications based on metrics.
Example:
minReplicas: 2
maxReplicas: 10
When traffic increases:
2 Pods → 4 Pods → 8 Pods
When traffic decreases:
8 Pods → 4 Pods → 2 Pods
Applications can handle traffic spikes automatically without human intervention.
Before Kubernetes, deployments often involved downtime.
Kubernetes Deployments support rolling updates out of the box.
Instead of replacing all instances at once:
Old Version → New Version
Pod 1 replaced
Pod 2 replaced
Pod 3 replaced
Traffic continues flowing throughout the update.
Users experience minimal disruption during releases.
Even great engineers deploy bugs.
The real question is:
How quickly can you recover?
Kubernetes stores deployment history and allows quick rollback.
Example:
kubectl rollout undo deployment/myapp
Recovery often matters more than perfection.
As clusters grow, organization becomes important.
Namespaces help separate workloads.
Examples:
development
testing
staging
production
Namespaces prevent accidental interference between environments and teams.
Applications need to be accessible from outside the cluster.
Ingress provides:
URL routing
TLS termination
Domain management
Reverse proxy functionality
Example:
api.company.com
app.company.com
blog.company.com
can all share the same Kubernetes cluster.
Ingress simplifies exposing applications to users while reducing infrastructure complexity.
Containers are temporary.
Data often isn’t.
Kubernetes provides Persistent Volumes for stateful applications.
Examples:
Databases
File storage
Shared application data
Understanding storage is critical when applications need to retain information across restarts.
By default, applications inside a cluster can often communicate freely.
Network Policies allow you to define who can talk to whom.
Example:
Frontend → Backend ✓
Backend → Database ✓
Frontend → Database ✗
This significantly improves application security and reduces lateral movement risks.
The most important lesson I learned is that Kubernetes is not merely a container orchestrator.
It is a platform that provides built-in capabilities for:
Configuration management
Security
Scaling
High availability
Traffic management
Disaster recovery
Developers who understand these features write applications that are far easier to operate in production.
And that’s the real goal.
Not just deploying containers.
But building applications that survive real-world production environments.
Many developers learn Kubernetes by focusing only on Pods, Deployments, and Services.
Those are important.
But the real power of Kubernetes comes from the ecosystem of features surrounding them.
If you’re starting your Kubernetes journey, focus on understanding these capabilities:
✅ ConfigMaps
✅ Secrets
✅ Probes
✅ Resource Limits
✅ HPA
✅ Rolling Updates
✅ Rollbacks
✅ Namespaces
✅ Ingress
✅ Persistent Volumes
✅ Network Policies
Master these, and you’ll begin thinking like a cloud-native developer rather than someone simply deploying containers.
If you’re preparing for Kubernetes certifications, pursuing the Kubestronaut journey, or working in the cloud-native ecosystem, I’d love to connect.
Follow me for more articles on Kubernetes, CNCF certifications, DevOps, Platform Engineering, and Cloud-Native technologies.
LinkedIn: https://www.linkedin.com/in/shahzadaliahmad/
LFX Profile: https://openprofile.dev/profile/shahzadahmad91
Credly: https://www.credly.com/users/shahzadahmad
Website: https://shahzadahmad.dev/
If you found this article helpful, consider sharing it with others in the Kubernetes community.