Deploying and Scaling a Kubernetes Guestbook Application

This project demonstrates how to build, deploy, and scale a simple Guestbook application on Kubernetes. The workflow covers containerization, autoscaling, and safe rollout practices—core competencies for cloud-native operations.

---

Step 1: Build and Deploy the Guestbook Image

We begin by building and pushing the application image:

# install dependencies
FROM golang:1.18 AS builder
#set working directory
WORKDIR /app
# copy script 
COPY main.go .
# commands to initialise project
RUN go mod init guestbook
RUN go mod tidy
RUN go build -o main main.go
# container image
FROM ubuntu:18.04 
#Copy all files to image
COPY --from=builder /app/main /app/guestbook
COPY public/index.html /app/public/index.html
COPY public/script.js /app/public/script.js
COPY public/style.css /app/public/style.css
COPY public/jquery.min.js /app/public/jquery.min.js
WORKDIR /app
CMD ["./guestbook"]
# expose the container port to listen to requests
EXPOSE 3000

deployment.yaml stating all deployment configurations:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook
spec:
  replicas: 1
  selector:
    matchLabels:
      app: guestbook
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook
        image: us.icr.io/sn-labs-arorahardik0/guestbook:v1
        ports:
        - containerPort: 3000

Docker commands to build image and push to IBM cloud registry:

docker build -t us.icr.io/$MY_NAMESPACE/guestbook:v1 .
docker push us.icr.io/$MY_NAMESPACE/guestbook:v1

Best Practice Validation

Following a method recommended by Google employees, I validated that the image in the manifest existed and could be pulled:

kubectl get events -n $MY_NAMESPACE --sort-by=.metadata.creationTimestamp

kubectl apply -f deployment.yaml

This prevents invalid or broken deployments caused by incorrect image references.

---

Step 2: Autoscaling with HPA

Next, I enabled the Horizontal Pod Autoscaler (HPA) to automatically adjust replicas based on load:

kubectl autoscale deployment guestbook --cpu-percent=50 --min=1 --max=5

To simulate load and test scaling behavior:

kubectl run -i --tty load-generator --rm \
  --image=busybox:1.36.0 --restart=Never -- \
  /bin/sh -c "while sleep 0.01; do wget -q -O- https://arorahardik0-3000.theiaopenshiftnext-1-labs-prod-theiaopenshift-4-tor01.proxy.cognitiveclass.ai/; 
done"

I then observed scaling in real time:

---

Step 3: Rolling Updates and Rollbacks

I tested deployment resilience by updating the app (v2 image). After pushing the updated image, I changed the deployment.yaml and re-applied:

kubectl apply -f deployment.yaml

Rollout History and Rollback

View rollout history:

kubectl rollout history deployment/guestbook

Then getting details for a particular version:

If required, rollback safely to a previous version:

kubectl rollout undo deployment/guestbook --to-revision=1

This guarantees production safety by allowing quick recovery from failed updates.

---

Key Takeaway

• Autoscaling: HPA ensures applications adapt to varying workloads without manual intervention.

• Operational Safety: Rolling updates and rollbacks safeguard against failures.

• Validation: Using kubectl get events confirms image pullability before rollout.

---

This project shows how even a simple app like Guestbook can highlight enterprise-grade Kubernetes workflows: build → deploy → scale → update.

---