Demo-Nginx Scaling History

This document tracks the scaling changes made to the demo-nginx deployment for capacity planning and audit purposes.

Scaling Timeline

2026-01-12: Scale to 5 Replicas

Change: Increased from 3 to 5 replicas
Reason: Enhanced capacity and improved high availability
Impact:

Additional 2 pod instances for better load distribution
Improved resilience against node failures
Better handling of traffic spikes
Total resource allocation:
- CPU requests: 500m (5 × 100m)
- Memory requests: 640Mi (5 × 128Mi)
- CPU limits: 1000m (5 × 200m)
- Memory limits: 1280Mi (5 × 256Mi)

Commit: 0669ac66c8a651f74b4c16a4618db03bdd843c02
Deployment Method: GitOps via ArgoCD automatic sync

2026-01-12: Scale to 3 Replicas

Change: Increased from 2 to 3 replicas
Reason: Initial scaling for improved availability
Commit: d5ffa97159ec391de950dc2d861361074ff3eee8

Initial Deployment: 2 Replicas

Change: Initial deployment with 2 replicas
Reason: Baseline deployment for demo application

Current Configuration

Replicas: 5
Namespace: demo-app
Image: docker.io/vladcrypto/demo-nginx:main-50
Service Type: ClusterIP
Port: 80
Health Checks: Liveness and Readiness probes enabled
Monitoring: Prometheus scraping enabled

Scaling Guidelines

When to Scale Up

CPU utilization consistently above 70%
Memory utilization consistently above 75%
Response time degradation observed
Preparing for expected traffic increase
Node maintenance requires pod redistribution

When to Scale Down

CPU utilization consistently below 30% for extended period
Cost optimization requirements
Application usage patterns indicate over-provisioning

Resource Considerations

Each replica consumes:

CPU Request: 100m
Memory Request: 128Mi
CPU Limit: 200m
Memory Limit: 256Mi

Total cluster resources for 5 replicas:

Total CPU Requests: 500m (0.5 cores)
Total Memory Requests: 640Mi (~0.625 GB)
Total CPU Limits: 1000m (1 core)
Total Memory Limits: 1280Mi (~1.25 GB)

Monitoring and Alerts

Monitor the following metrics in Grafana:

Pod CPU/Memory utilization
Request latency
Error rates
Pod restart count
Service availability

Rollback Procedure

If issues arise after scaling:

Revert the deployment.yaml in Git:
```
git revert <commit-hash>
git push
```
ArgoCD will automatically sync the change

Or manually scale via kubectl:

kubectl scale deployment demo-nginx -n demo-app --replicas=<previous-count>

CICD_GUIDE.md - CI/CD pipeline documentation
ROLLBACK_MANUAL.md - Detailed rollback procedures
README.md - General application documentation

Notes

All scaling operations are tracked in Git for audit trail
ArgoCD manages automatic synchronization from Git to cluster
Changes follow GitOps principles for declarative infrastructure
Scaling decisions should be data-driven based on monitoring metrics

3.1 KiB Raw Blame History Unescape Escape