Continuous deployment of microservices to Kubernetes using GitOps principles, with advanced traffic management and observability
Kubernetes-based deployment of the Bookinfo microservices application to AWS EKS, managed declaratively using ArgoCD. Implements GitOps principles for infrastructure management, with Istio service mesh providing traffic management, security, and comprehensive observability through Grafana, Prometheus, and Kiali.
Git Repository (Source of Truth)
↓
ArgoCD (Continuous Sync)
↓
AWS EKS Cluster
├─→ Bookinfo Microservices
├─→ Istio Service Mesh
└─→ Observability Stack
├─ Prometheus (Metrics)
├─ Grafana (Visualization)
└─ Kiali (Service Mesh Dashboard)
Istio service mesh managing microservices communication
Real-time visualization of service topology and health
Traffic flow patterns and request rates between microservices
Prometheus scraping and storing application metrics
Time-series metrics visualization
Grafana dashboards with Prometheus data source
Productpage microservice exposed via Istio Gateway
Internal service pages accessible within the mesh
| Category | Tools |
|---|---|
| GitOps | ArgoCD |
| Container Orchestration | Kubernetes (AWS EKS) |
| Service Mesh | Istio |
| Monitoring | Prometheus, Grafana, Kiali |
| Cloud Platform | AWS (EKS, EC2, VPC) |
| Application | Bookinfo Microservices |
- ✅ GitOps Workflow: Git repository as single source of truth for deployments
- ✅ Automated Sync: ArgoCD continuously monitors and deploys changes
- ✅ Traffic Management: Istio-based traffic splitting and routing
- ✅ Observability: Full-stack monitoring with Prometheus, Grafana, Kiali
- ✅ Service Mesh: Istio handling service-to-service communication
- ✅ Canary Deployments: Weighted traffic distribution between service versions
- Source of Truth: All Kubernetes manifests stored in Git
- Automated Sync: ArgoCD continuously ensures manifests are applied to the cluster
- Declarative Deployment: Desired state defined in YAML manifests
- Self-Healing: ArgoCD ensures cluster state matches Git state
- Audit Trail: All changes tracked via Git commits
The Productpage deployment references the latest container image tag (userashik187/productpage-app:latest).
When the CI pipeline builds and pushes a new image to Docker Hub, Kubernetes pulls the updated image when the Productpage pod is recreated. This behavior demonstrates Kubernetes image lifecycle management rather than a fully versioned GitOps rollout.
Learning Point: A production enhancement would implement versioned image tags (e.g., v1.0.0, v1.0.1) or ArgoCD Image Updater for deterministic Git-driven deployments with proper rollback capabilities.
- CI pipeline builds and pushes the Productpage container image to Docker Hub using the
latesttag - Kubernetes deployments reference this image in the manifests
- When Productpage pods are recreated, Kubernetes pulls the updated image automatically
- ArgoCD ensures that the Kubernetes manifests remain consistent with the Git repository
The deployment includes advanced traffic management configurations:
Implements weighted traffic distribution across review service versions:
- v1: 6% traffic
- v2: 17% traffic
- v3: 77% traffic
Enables canary deployments and A/B testing without code changes.
Defines service subsets for traffic routing:
- Version-based routing (v1, v2, v3)
- Load balancing policies
- Connection pool settings
Exposes the application externally via Istio Ingress Gateway:
- HTTP traffic on port 8080
- Route configuration for productpage endpoints
- External access control
Service Mesh Security:
- Istio-managed service-to-service communication with support for mTLS
- Service-to-service authentication capabilities
- Network policy enforcement via Istio
Monitoring Stack:
- Prometheus: Metrics collection from all pods
- Grafana: Custom dashboards for visualization
- Kiali: Service mesh topology and health checks
.
├── bookinfo.yaml # Main application manifests
├── bookinfo-gateway.yaml # Istio Gateway configuration
├── vs.yml # Virtual Service for traffic routing
├── ds.yml # Destination Rules for subsets
├── live_snapshots/ # Screenshots of running deployment
└── README.md # This file
- AWS Account with EKS access
- kubectl configured for EKS cluster
- ArgoCD installed on cluster
- Istio installed with demo profile
- Configure ArgoCD application pointing to this repository
- Set sync policy to automatic
- ArgoCD will deploy all manifests to the cluster
- Access application via Istio Ingress Gateway
# Kiali dashboard
istioctl dashboard kiali
# Grafana dashboard
istioctl dashboard grafana
# Prometheus UI
istioctl dashboard prometheus- Implementing GitOps workflows with ArgoCD for declarative infrastructure management
- Managing service mesh traffic with Istio VirtualServices and DestinationRules
- Configuring comprehensive observability using Prometheus, Grafana, and Kiali
- Deploying and managing microservices on AWS EKS
- Implementing canary deployments with weighted traffic distribution
- Understanding service-to-service communication patterns in mesh architecture
- Key Insight: Difference between declarative infrastructure (GitOps) and versioned deployments (proper CD)
This project demonstrates foundational concepts. For production use, I would implement:
- Versioned Image Tags: Replace
:latestwith semantic versioning (e.g.,v1.0.0) - ArgoCD Image Updater: Automate manifest updates when new images are pushed
- Automated Rollbacks: Configure health checks to trigger automatic rollbacks on failure
- Secret Management: Use AWS Secrets Manager or Sealed Secrets instead of plain Kubernetes secrets
- Multi-environment Strategy: Separate dev/staging/prod with environment-specific configurations
- CI/CD Integration: Add automated testing and deployment gates between environments
- CI Pipeline with Jenkins - Builds container images deployed by this CD pipeline
Application: Bookinfo microservices (4 services: productpage, details, reviews, ratings)
Cluster: AWS EKS (Kubernetes 1.x)
Service Mesh: Istio 1.x (demo profile)
GitOps Tool: ArgoCD
Deployment Strategy: Rolling updates with traffic shifting
Built with ❤️ demonstrating modern cloud-native deployment practices