This content originally appeared on DEV Community and was authored by Samia Khan
I wanted to refresh my EKS knowledge and deploy an app manually to a cluster.
I followed this video and decided to experiment with EKS Auto Mode. The app uses a MongoDB backend with persistent EBS volumes deployed as a StatefulSet with a primary and two secondary replicas. When deploying this on a cluster with Auto Mode for some reason it wouldn't schedule the pods for creation. I spent a bit of time troubleshooting but decided instead to create a new cluster without Auto Mode and created a node group with 2 nodes. I might revisit this project again and reattempt it with Auto Mode. These are roughly the steps I followed:
- Created an EKS role and cluster
- Created another role for the node group and created the node group with 2 nodes
- Added the EBS add on which is needed for the persistent volumes
- Created the MongoDB and API deployments
- Created the Load Balancer service
- Created the App deployment
After creating the Load Balancer service, I couldn't reach the endpoint when doing a curl. This was because even though the service was created, it had no endpoints because there was a label mismatch in my service configuration. My service was defined like this:
spec:
selector:
app: api
which meant it was looking for all pods in this namespace with the label app=api and trying to route traffic to them but my pods were labelled like this:
labels:
role: api
env: demo
So the load balancer was unable to find any pods with app=api and had nowhere to forward traffic to. Once the label was fixed and the service redeployed i could see the endpoints and reach the URL.
Labels are Important!
- Pod selection: Services and controllers use labels to select target Pods.
- Resource grouping: Organise objects by app, environment, team, etc.
- Deployment strategies: Enable canary, blue/green, and version-based rollouts.
- Monitoring & logging: Filter metrics and logs in tools like Prometheus or Grafana.
- Network policies: Apply security rules based on Pod labels.
What is a StatefulSet?
A StatefulSet is a Kubernetes controller used to manage stateful applications. Unlike Deployments which are for stateless apps, StatefulSets give each Pod a unique, stable identity and persistent storage.
StatefulSets provide the following features, typically in combination with a Headless Service:
- Stable Pod Names: e.g. mongo-0, mongo-1, mongo-2
- Stable Network Identity: Each Pod has a unique DNS name
- Persistent Volumes: Each Pod gets its own persistent volume claim (PVC) that is not reused by other Pods
- Ordered Deployment and Scaling: Pods are created or terminated in order
What is a Service?
Since Pods are ephemeral and have dynamic IPs, a Service provides a consistent way to communicate with them. It is a method for exposing a network application that is running as one or more Pods in your cluster.
A Service allows:
- Load balancing across matching Pods
- Service discovery within the cluster
- Decoupling between application components
Service Types:
- ClusterIP: Exposes the service on an internal IP within the cluster and is only accessible from within the cluster.
- NodePort: Exposes the service on a static port on each node.
- LoadBalancer: Provisions an external IP via the cloud provider’s load balancer for applications needing external access.
- ExternalName: Maps the service to an external DNS name (e.g. example.com). Doesn’t proxy traffic, just returns the DNS name.
- Headless Service (ClusterIP: None): No ClusterIP is assigned. Used to expose each Pod’s DNS directly, essential for apps like StatefulSets or databases needing direct Pod-to-Pod communication.
This content originally appeared on DEV Community and was authored by Samia Khan
Samia Khan | Sciencx (2025-07-12T15:18:20+00:00) Deploying a Voting App on AWS EKS. Retrieved from https://www.scien.cx/2025/07/12/deploying-a-voting-app-on-aws-eks/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.