Chapter 76: DevOps Projects Part 6: Kubernetes Canary Helm RBAC NetworkPolicy Quotas EKS Microservices Velero Upgrade

76.7 Project 46: Microservices e-commerce demo on Kubernetes

By Ravindra Bagale Last updated: 28 October 2026

Friends, a shop is many small services. Today we deploy catalog, cart, checkout and frontend, wire Services and Ingress, curl each API, and scale catalog alone.

What you will build in this project

Four Deployments and Services.
Ingress with two paths.
curl proofs.
Scale catalog note.

1. Start from a real company story

At Meesho in Bengaluru, Ishita split a monolith cart that froze every sale event.

Four services and clear DNS names cut MTTR. Rough past cost of freezes: about ₹60 lakh.

Today we build that mini shop.

Picture 1: Ingress → frontend ; /api/catalog → catalog ; cart ; checkout

Ravindra Bagale's Tip

Students put every container in one Pod. That is not microservices. One Deployment per service. Keep that habit.

2. Start and prepare

Step 1: Why microservices

Why: Small services. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: echo. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 1: a1

Type this:

echo 'Microservices: small services that own their data and talk over the network'

You will see:

Microservices: small services that own their data and talk over the network

What it means: What microservices are.

Example 2: a2

Type this:

echo 'Lab shop: frontend + catalog API + cart API + checkout API'

You will see:

Lab shop: frontend + catalog API + cart API + checkout API

What it means: Four services.

Example 3: a3

Type this:

echo 'One namespace shop-demo keeps the lab simple'

You will see:

One namespace shop-demo keeps the lab simple

What it means: Namespace tip.

Step 2: Catalog YAML

Why: First service. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf catalog. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 4: b1

Type this:

echo 'kubectl create namespace shop-demo'

You will see:

kubectl create namespace shop-demo

What it means: Create namespace.

Example 5: b2

Type this:

mkdir -p /tmp/k8s46 && printf '%s\n' 'apiVersion: apps/v1' 'kind: Deployment' 'metadata: {name: catalog, namespace: shop-demo}' 'spec:' '  replicas: 2' '  selector: {matchLabels: {app: catalog}}' '  template:' '    metadata: {labels: {app: catalog}}' '    spec:' '      containers:' '      - name: api' '        image: hashicorp/http-echo:1.0' '        args: ["-text=catalog-ok"]' '        ports: [{containerPort: 5678}]' > /tmp/k8s46/catalog.yaml && head -6 /tmp/k8s46/catalog.yaml

You will see:

kind: Deployment
metadata: {name: catalog

What it means: Catalog Deployment.

Example 6: b3

Type this:

printf '%s\n' 'apiVersion: v1' 'kind: Service' 'metadata: {name: catalog, namespace: shop-demo}' 'spec:' '  selector: {app: catalog}' '  ports: [{port: 80, targetPort: 5678}]' > /tmp/k8s46/catalog-svc.yaml && cat /tmp/k8s46/catalog-svc.yaml

You will see:

kind: Service

What it means: Catalog Service.

Step 3: Cart YAML

Why: Second service. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf cart. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 7: c1

Type this:

printf '%s\n' 'apiVersion: apps/v1' 'kind: Deployment' 'metadata: {name: cart, namespace: shop-demo}' 'spec:' '  replicas: 2' '  selector: {matchLabels: {app: cart}}' '  template:' '    metadata: {labels: {app: cart}}' '    spec:' '      containers:' '      - name: api' '        image: hashicorp/http-echo:1.0' '        args: ["-text=cart-ok"]' '        ports: [{containerPort: 5678}]' > /tmp/k8s46/cart.yaml

You will see:

What it means: Cart Deployment file.

Example 8: c2

Type this:

printf '%s\n' 'apiVersion: v1' 'kind: Service' 'metadata: {name: cart, namespace: shop-demo}' 'spec:' '  selector: {app: cart}' '  ports: [{port: 80, targetPort: 5678}]' > /tmp/k8s46/cart-svc.yaml && echo cart-yaml-ready

You will see:

cart-yaml-ready

What it means: Cart Service file.

Example 9: c3

Type this:

echo 'kubectl apply -f /tmp/k8s46/catalog.yaml -f /tmp/k8s46/catalog-svc.yaml -f /tmp/k8s46/cart.yaml -f /tmp/k8s46/cart-svc.yaml'

You will see:

kubectl apply -f ...

What it means: Apply catalog and cart.

3. Build the main pieces

Step 4: Checkout frontend

Why: UI and pay path. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf checkout. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 10: d1

Type this:

printf '%s\n' 'apiVersion: apps/v1' 'kind: Deployment' 'metadata: {name: checkout, namespace: shop-demo}' 'spec:' '  replicas: 2' '  selector: {matchLabels: {app: checkout}}' '  template:' '    metadata: {labels: {app: checkout}}' '    spec:' '      containers:' '      - name: api' '        image: hashicorp/http-echo:1.0' '        args: ["-text=checkout-ok"]' '        ports: [{containerPort: 5678}]' '---' 'apiVersion: v1' 'kind: Service' 'metadata: {name: checkout, namespace: shop-demo}' 'spec:' '  selector: {app: checkout}' '  ports: [{port: 80, targetPort: 5678}]' > /tmp/k8s46/checkout.yaml && echo checkout-ready

You will see:

checkout-ready

What it means: Checkout Deploy+Service.

Example 11: d2

Type this:

printf '%s\n' 'apiVersion: apps/v1' 'kind: Deployment' 'metadata: {name: frontend, namespace: shop-demo}' 'spec:' '  replicas: 2' '  selector: {matchLabels: {app: frontend}}' '  template:' '    metadata: {labels: {app: frontend}}' '    spec:' '      containers:' '      - name: web' '        image: nginx:1.27-alpine' '        ports: [{containerPort: 80}]' '---' 'apiVersion: v1' 'kind: Service' 'metadata: {name: frontend, namespace: shop-demo}' 'spec:' '  type: ClusterIP' '  selector: {app: frontend}' '  ports: [{port: 80}]' > /tmp/k8s46/frontend.yaml && echo frontend-ready

You will see:

frontend-ready

What it means: Frontend Deploy+Service.

Example 12: d3

Type this:

echo 'kubectl apply -f /tmp/k8s46/checkout.yaml -f /tmp/k8s46/frontend.yaml'

You will see:

kubectl apply -f ...

What it means: Apply checkout and frontend.

Step 5: get status DNS

Why: Status. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: get. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 13: e1

Type this:

echo 'kubectl get deploy,svc -n shop-demo'

You will see:

kubectl get deploy,svc -n shop-demo

What it means: Four Deployments and Services.

Example 14: e2

Type this:

echo 'kubectl rollout status deploy/catalog -n shop-demo'

You will see:

kubectl rollout status deploy/catalog -n shop-demo

What it means: Wait catalog Ready.

Example 15: e3

Type this:

echo 'DNS names: catalog.shop-demo.svc cart.shop-demo.svc checkout.shop-demo.svc'

You will see:

DNS names: catalog.shop-demo.svc cart.shop-demo.svc checkout.shop-demo.svc

What it means: In-cluster DNS.

Step 6: curl proofs

Why: Prove. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: curl. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 16: f1

Type this:

echo 'kubectl run curl -n shop-demo --rm -it --image=curlimages/curl --restart=Never -- curl -s http://catalog'

You will see:

kubectl run curl ... -- curl -s http://catalog

What it means: Expect catalog-ok.

Example 17: f2

Type this:

echo 'kubectl run curl2 -n shop-demo --rm -it --image=curlimages/curl --restart=Never -- curl -s http://cart'

You will see:

kubectl run curl2 ... -- curl -s http://cart

What it means: Expect cart-ok.

Example 18: f3

Type this:

echo 'kubectl run curl3 -n shop-demo --rm -it --image=curlimages/curl --restart=Never -- curl -s http://checkout'

You will see:

kubectl run curl3 ... -- curl -s http://checkout

What it means: Expect checkout-ok.

4. Automate and verify

Step 7: Ingress

Why: Edge. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf ing. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 19: g1

Type this:

printf '%s\n' 'apiVersion: networking.k8s.io/v1' 'kind: Ingress' 'metadata: {name: shop, namespace: shop-demo}' 'spec:' '  ingressClassName: nginx' '  rules:' '  - host: shop.example.local' '    http:' '      paths:' '      - path: /' '        pathType: Prefix' '        backend: {service: {name: frontend, port: {number: 80}}}' '      - path: /api/catalog' '        pathType: Prefix' '        backend: {service: {name: catalog, port: {number: 80}}}' > /tmp/k8s46/ing.yaml && grep path /tmp/k8s46/ing.yaml

You will see:

path: /
path: /api/catalog

What it means: Ingress routes frontend and catalog.

Example 20: g2

Type this:

echo 'kubectl apply -f /tmp/k8s46/ing.yaml'

You will see:

kubectl apply -f /tmp/k8s46/ing.yaml

What it means: Apply Ingress.

Example 21: g3

Type this:

echo 'Path-based routing keeps one host for the shop'

You will see:

Path-based routing keeps one host for the shop

What it means: Routing tip.

Step 8: Config NetworkPolicy

Why: Hardening. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: configmap. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 22: h1

Type this:

echo 'ConfigMap per service for non-secret config; Secret for tokens'

You will see:

ConfigMap per service for non-secret config; Secret for tokens

What it means: Config tip.

Example 23: h2

Type this:

echo 'kubectl create configmap catalog-cfg -n shop-demo --from-literal=CURRENCY=INR'

You will see:

kubectl create configmap catalog-cfg -n shop-demo --from-literal=CURRENCY=INR

What it means: Example ConfigMap.

Example 24: h3

Type this:

echo 'NetworkPolicy tip: only frontend may call checkout in a hardened shop'

You will see:

NetworkPolicy tip: only frontend may call checkout in a hardened shop

What it means: Security tip.

Step 9: Scale

Why: Independence. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: scale. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 25: i1

Type this:

echo 'Independent Deployments mean catalog can scale without touching cart'

You will see:

Independent Deployments mean catalog can scale without touching cart

What it means: Scale tip.

Example 26: i2

Type this:

echo 'kubectl scale deploy/catalog -n shop-demo --replicas=3'

You will see:

kubectl scale deploy/catalog -n shop-demo --replicas=3

What it means: Scale catalog.

Example 27: i3

Type this:

echo 'HPA from project 36 can sit on each Deployment later'

You will see:

HPA from project 36 can sit on each Deployment later

What it means: Bridge.

5. Harden and accept

Step 10: Failure drill

Why: Resilience. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: delete pod. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 28: j1

Type this:

echo 'Failure drill: kubectl delete pod -l app=cart -n shop-demo'

You will see:

Failure drill: kubectl delete pod -l app=cart -n shop-demo

What it means: Cart Pods recreate.

Example 29: j2

Type this:

echo 'kubectl get pods -n shop-demo -l app=cart'

You will see:

kubectl get pods -n shop-demo -l app=cart

What it means: New cart Pods Ready.

Example 30: j3

Type this:

echo 'Each service should have its own readinessProbe'

You will see:

Each service should have its own readinessProbe

What it means: Probe tip.

Step 11: Cleanup

Why: Cleanup. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: cleanup. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 31: k1

Type this:

echo 'Optional cleanup: kubectl delete ns shop-demo'

You will see:

Optional cleanup: kubectl delete ns shop-demo

What it means: Cleanup.

Example 32: k2

Type this:

echo 'Save the four Deployments Services and Ingress in your notebook'

You will see:

Save the four Deployments Services and Ingress in your notebook

What it means: Artifact.

Example 33: k3

Type this:

echo 'Next project backs up the cluster with Velero'

You will see:

Next project backs up the cluster with Velero

What it means: Bridge.

Step 12: Acceptance

Why: Ishita signs off. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: All green. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 34: z1

Type this:

echo 'Four services respond catalog-ok cart-ok checkout-ok'

You will see:

Four services respond catalog-ok cart-ok checkout-ok

What it means: Checklist curls.

Example 35: z2

Type this:

echo 'Ingress paths for / and /api/catalog'

You will see:

Ingress paths for / and /api/catalog

What it means: Checklist Ingress.

Example 36: z3

Type this:

echo 'Ishita: PASS'

You will see:

Ishita: PASS

What it means: Project 46 accepted.

Check yourself

Q1. Who fixed Meesho?

Ishita

Q2. Catalog image tip?

hashicorp/http-echo

Q3. Cart curl expect?

cart-ok

Q4. Ingress host tip?

shop.example.local

Q5. Scale command family?

kubectl scale

Q6. Namespace?

shop-demo

Friends, you ran a four-service shop on Kubernetes. Did you understand? Let us try it once more. Add NetworkPolicy so only frontend reaches checkout.

Lab: try at home

Create namespace.
Apply catalog cart checkout frontend.
curl each Service.
Apply Ingress.
Scale and failure drill.

Recap

One Deployment per service.
Cluster DNS names.
Path routing.
Independent scale.
Probes per service.