Container Orchestration (MCAD)
Deploy a Node.js microservices application on Kubernetes, ensuring proper configuration, service discovery, and inter-service communication.
This deployment was performed on an on-prem Kubernetes cluster using Docker Desktop, not on EKS or any cloud provider.
The application consists of four containerized Node.js microservices:
| Service Name | Port |
|---|---|
| User Service | 3000 |
| Product Service | 3001 |
| Order Service | 3002 |
| Gateway Service | 3003 |
-
Kubernetes (Docker Desktop -- On-Prem)
-
kubectl
-
Docker
-
NGINX Ingress Controller
submission/ ├── deployments/ │ ├── user-service.yaml │ ├── product-service.yaml │ ├── order-service.yaml │ └── gateway-service.yaml ├── services/ │ ├── user-service.yaml │ ├── product-service.yaml │ ├── order-service.yaml │ └── gateway-service.yaml ├── ingress/ │ └── ingress.yaml ├── screenshots/ │ ├── pods.png │ ├── service-test.png │ └── logs.png ├── user-service/ ├── product-service/ ├── order-service/ └── gateway-service/
Each Deployment includes:
-
Correct container image reference
-
Resource requests and limits
-
Environment variables
-
Liveness and readiness probes
-
Proper labels and selectors
-
All services use ClusterIP
-
Enables internal Kubernetes DNS-based service discovery
-
Correct port mapping for each microservice
kubectl apply -f submission/deployments/ kubectl apply -f submission/services/ kubectl apply -f submission/ingress/ingress.yaml
kubectl get pods -o wide kubectl get svc kubectl get ingress
A temporary curl pod was used to validate Kubernetes DNS and service connectivity:
kubectl run curlpod --image=curlimages/curl -it --restart=Never -- sh
Inside the pod:
nslookup user-service curl -v http://user-service:3000
This confirms:
-
Kubernetes DNS resolution
-
ClusterIP service discovery
-
TCP connectivity between services
Note: HTTP
404 Not Foundresponses are expected because the services do not expose a root (/) endpoint.
A404confirms that the service is reachable and the application is running.
kubectl logs -l app=gateway-service --tail=100
Gateway logs confirm communication with downstream services.
NGINX Ingress Controller was enabled and configured with the following routes:
| Path | Backend Service |
|---|---|
/api/users |
User Service |
/api/products |
Product Service |
/api/orders |
Order Service |
/ |
Gateway Service |
Ingress Host:
micro.local
Ingress was tested using port-forwarding:
kubectl -n ingress-nginx port-forward svc/ingress-nginx-controller 8080:80
The following screenshots are included as evidence:
-
pods.png -- Running pods (
kubectl get pods -o wide) -
service-test.png -- DNS resolution and service connectivity test
-
logs.png -- Gateway service logs showing communication
- Ensure Docker images are built locally when using Docker Desktop Kubernetes:
docker build -t user-service:latest ./submission/user-service
-
Some services do not expose
/or/healthendpoints. -
DNS resolution and TCP connectivity were used instead to validate service communication.
All microservices were successfully deployed on Kubernetes with:
-
Proper service discovery
-
Internal communication using ClusterIP
-
Resource management and health probes
-
Optional ingress routing
This fulfills all requirements of Skill Test 2 -- Container Orchestration.
📸 Screenshots (Attach in Submission)
DEEPIKA NARENDRAN
DevOps Technical Lead | MCAD Program\
[DevOps B13] Skill Test 2 -- Cloud & Container Orchestration Microservices Kubernetes Deployment Assessment
📧 deepika2.ytb@gmail.com
💼 GitHub: JoinDeeHub
📍 Bengaluru, India