When you’re running a microservices architecture, you’ve likely hit the point where a single Docker run command isn’t cutting it anymore. You need a system that can manage hundreds of containers, handle rolling updates, auto‑scale based on traffic, and provide health checks out of the box. Enter Kubernetes – the open‑source platform that turns container orchestration from a headache into a well‑tuned symphony. This guide will walk you through every step of orchestrating containers with Kubernetes, from cluster setup to advanced deployment strategies. By the end, you’ll have a production‑ready cluster and the knowledge to troubleshoot common pitfalls.
What You’ll Need
- A cloud account (AWS, GCP, Azure) or a local machine with
minikubeorkind - Docker installed and a Docker Hub or private registry account
- Kubectl CLI configured to talk to your cluster
- Helm (optional but highly recommended for package management)
- A text editor or IDE for YAML editing (VS Code, Vim, etc.)
- Basic familiarity with YAML and command‑line tools
Step 1: Spin Up Your Kubernetes Cluster
First things first – you need a cluster. For local experimentation, kind (Kubernetes IN Docker) is fast and lightweight. For production, let’s use eksctl to create an EKS cluster on AWS. The same pattern applies to GKE or AKS with their respective CLIs.
Local with kind:
brew install kind
kind create cluster --name teknozof
kubectl cluster-info --context kind-teknozof
Cloud with eksctl:
eksctl create cluster
--name teknozof-cluster
--region us-east-1
--nodegroup-name standard-workers
--node-type t3.medium
--nodes 3
--nodes-min 2
--nodes-max 5
--managed
Verify the nodes are ready:
kubectl get nodes
If you see all nodes in Ready state, you’re good to go.
Step 2: Build and Push Your Docker Image
We’ll use a simple Node.js app as an example. Create a Dockerfile:
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Build and push to Docker Hub:
docker build -t docker.io/your-username/teknozof-app:1.0 .
docker push docker.io/your-username/teknozof-app:1.0
Alternatively, use a private registry like ECR or GCR. The image tag must be fully qualified so Kubernetes can pull it.
Step 3: Create a Deployment and Service
Now we’ll create a Deployment to manage pod replicas and a ClusterIP Service to expose the app internally.
apiVersion: apps/v1
kind: Deployment
metadata:
name: teknozof-app
spec:
replicas: 3
selector:
matchLabels:
app: teknozof-app
template:
metadata:
labels:
app: teknozof-app
spec:
containers:
- name: app
image: docker.io/your-username/teknozof-app:1.0
ports:
- containerPort: 3000
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: teknozof-service
spec:
selector:
app: teknozof-app
ports:
- protocol: TCP
port: 80
targetPort: 3000
type: ClusterIP
Apply the manifest:
kubectl apply -f teknozof-app.yaml
Check that pods are running:
kubectl get pods -l app=teknozof-app -o wide
Verify the service:
kubectl get svc teknozof-service
Step 4: Expose the Service to the Internet
For external access, switch the service type to LoadBalancer (cloud) or use NodePort for local clusters. Here’s the LoadBalancer example:
kubectl patch svc teknozof-service -p '{"spec":{"type":"LoadBalancer"}}'
Wait a few minutes for the cloud provider to provision an external IP:
kubectl get svc teknozof-service -w
Once an EXTERNAL-IP appears, you can hit the app at http://EXTERNAL-IP. For kind you’ll need nodeport or ingress-nginx to expose.
Step 5: Implement Horizontal Pod Autoscaling
Scale your app automatically based on CPU usage. First, enable the metrics server:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Then create an HPA:
kubectl autoscale deployment teknozof-app
--cpu-percent=50
--min=3
--max=10
Monitor the HPA:
kubectl get hpa teknozof-app -w
When you generate traffic (e.g., using hey or wrk), you’ll see the replica count rise and fall accordingly.
Step 6: Deploy with Rolling Updates and Canary Releases
Kubernetes makes it trivial to roll out new versions with zero downtime. Update the image tag in the deployment YAML to 1.1 and apply:
kubectl set image deployment/teknozof-app app=docker.io/your-username/teknozof-app:1.1
Kubectl automatically performs a rolling update: it creates new pods with the new image, waits for readiness probes, then terminates old pods. You can monitor:
kubectl rollout status deployment/teknozof-app
For a canary strategy, create a second deployment with a smaller replica set and a separate service:
apiVersion: apps/v1
kind: Deployment
metadata:
name: teknozof-app-canary
spec:
replicas: 1
selector:
matchLabels:
app: teknozof-app-canary
template:
metadata:
labels:
app: teknozof-app-canary
spec:
containers:
- name: app
image: docker.io/your-username/teknozof-app:1.1
ports:
- containerPort: 3000
Expose it via a separate service and use an Ingress with path or header routing to shift a small percentage of traffic to the canary. Once validated, merge the canary into the main deployment.
Common Mistakes to Avoid
1. Ignoring Resource Requests & Limits
Without setting resources.requests and resources.limits, the scheduler may overcommit nodes, leading to OOM kills and flaky behavior. Always specify realistic CPU and memory values.
2. Forgetting Readiness Probes
Deployments without readiness checks can route traffic to pods that aren’t ready, causing 503 errors. Include a readinessProbe that matches your app’s health endpoint.
3. Over‑Scaling Without Monitoring
Auto‑scaling can create a sudden spike in pod count. Pair HPA with Prometheus/Grafana dashboards to spot performance regressions early.
4. Using latest Tags in Production
Image tags should be immutable (e.g., 1.0.3). Using latest can lead to unpredictable rollouts.
5. Not Cleaning Up Resources
Leaving dangling services or unused namespaces costs resources and can confuse logs. Use kubectl delete or helm uninstall when done.
Tips and Tricks
- Use
kubectl kustomizeorHelmto manage environment‑specific overrides. - Leverage
kubectl explainto understand field descriptions in real time. - Enable
PodDisruptionBudgetto maintain availability during node maintenance. - Automate CI/CD pipelines with Argo CD or Flux for GitOps workflows.
- Set up
ClusterRoleBindingfor fine‑grained RBAC to follow the principle of least privilege.
Frequently Asked Questions
What’s the difference between a Deployment and a StatefulSet?
A Deployment manages stateless pods, automatically rolling updates and scaling. A StatefulSet is for stateful workloads that require stable network identities and persistent storage, such as databases or Kafka brokers.
Can I run Kubernetes on a single VM for production?
Technically yes, but it’s not recommended. Production workloads benefit from multi‑node clusters for high availability, fault tolerance, and load balancing. Use managed services (EKS, GKE, AKS) or a multi‑node setup with kubeadm for critical environments.
How do I secure my cluster?
Start with RBAC, restrict API access, enable network policies, use secrets encryption, and keep the control plane isolated. For cloud providers, enable VPC isolation and use IAM roles for service accounts.
Conclusion
Orchestrating containers with Kubernetes isn’t just about deploying pods; it’s about building resilience, scalability, and maintainability into your application lifecycle. By following these steps—setting up a cluster, crafting robust deployments, exposing services, scaling intelligently, and deploying with confidence—you’ll have a solid foundation for any production workload. Remember to monitor, iterate, and keep your configurations declarative; Kubernetes rewards consistency and automation. Happy orchestrating!
