Deploying Microservices on Kubernetes with Helm — Lessons from the Trenches

Author: Taranpreet SIngh
Special thanks: Cloud Champ 🙌

Introduction

This blog documents my journey of deploying a microservices-based video-to-audio converter application using Kubernetes and Helm — but more importantly, the challenges I faced along the way and how I tackled them.

The experience taught me more than just YAML syntax or Helm charts — it gave me real insights into IAM roles, Kubernetes resource constraints, and the power of microservices architecture.

Project Summary (Briefly)

The app has four microservices:

• Auth (with PostgreSQL + JWT)

• Upload/Download (using MongoDB + RabbitMQ)

• Video Processor (MP4 → MP3 conversion)

• Notification (SNS/email alerts)

Each service runs as a separate Kubernetes deployment and communicates asynchronously.

🔗 https://github.com/12taran/microservices-python-app.git

---

Real-World Challenges I Faced (and Solved)

---

1. AWS EKS IAM Permissions — kubectl get nodes Not Working

When I set up my EKS cluster using eksctl, I ran into this issue:

kubectl get nodes

Error: No resources found / Unauthorized

Cause:

Although I had configured AWS CLI using my IAM user via:

aws configure

...my IAM user didn’t have the required permissions to access or manage the EKS cluster created via eksctl.

Solution:

For learning purposes, I temporarily switched to the root user (⚠️ not recommended in production), updated the kubeconfig using:

aws eks update-kubeconfig --region <region> --name <cluster-name>

Once I confirmed it worked, I made a note to later set up proper IAM roles and aws-auth config maps for safe and secure access — which I’ll cover in a follow-up post.

Lesson: Learning the fundamentals of IAM and role-based access in AWS is key before diving deep into Kubernetes on EKS.

---

2. Pod in Pending State — Disk Space Nightmare

Another real headache occurred when the notification service pod stayed stuck in a Pending state.

Diagnosis:

kubectl describe pod <pod-name>

Revealed the issue:

0/1 nodes are available: insufficient ephemeral storage.

My local minikube (or cloud node) was out of disk space.

Solution:

I simply scaled down some other services using:

kubectl scale deployment <deployment-name> --replicas=0

This freed up enough resources for the pending pod to be scheduled.

Why This Matters: Microservices FTW

Both of these problems actually highlighted the strengths of microservices:

• I could independently scale deployments up/down as needed (e.g., scale notification service to 0 temporarily).

• I didn’t need to bring down the entire application — each service runs in isolation.

• Fine-grained control allowed me to debug and fix issues per service.

---

Tech Stack

• Kubernetes + Helm: for orchestration and deployment

• RabbitMQ: decoupling services and handling async tasks

• PostgreSQL + MongoDB: for relational and document data

• SNS (email): notifications

• Python + FastAPI: lightweight services

---

Thanks to Cloud Champ

A special thanks to Cloud Champ, whose resources helped me overcome key Kubernetes and Helm challenges. Their hands-on, practical content is perfect for learning these tools deeply.

---

Final Thoughts

This was less about building a fancy product and more about understanding how to deploy, troubleshoot, and scale microservices in a cloud-native way. I'm still improving the architecture and will later revisit IAM permissions and monitoring.

If you're diving into Kubernetes and microservices — expect things to break. But that’s exactly where the learning happens.