
Microservices Patterns
- 309 installs
- 61 repo stars
- Updated June 13, 2026
- manutej/luxor-claude-marketplace
Apply microservices architecture patterns—service decomposition, messaging, sagas, API gateways, and resilience—for designing maintainable distributed backend systems.
About
Covers microservices architecture patterns including service decomposition, asynchronous messaging, distributed transactions, gateway routing, and resilience strategies for scalable backend systems.
- Service boundary decomposition
- Event-driven and messaging patterns
- Saga and transaction coordination
- API gateway integration
- Resilience and failure-handling design
Microservices Patterns by the numbers
- 309 all-time installs (skills.sh)
- +18 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #1,324 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/manutej/luxor-claude-marketplace --skill microservices-patternsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 309 |
|---|---|
| repo stars | ★ 61 |
| Last updated | June 13, 2026 |
| Repository | manutej/luxor-claude-marketplace ↗ |
What it does
Apply microservices architecture patterns—service decomposition, messaging, sagas, API gateways, and resilience—for designing maintainable distributed backend systems.
Files
Microservices Patterns
A comprehensive skill for building, deploying, and managing production-grade microservices architectures. This skill covers service mesh patterns, traffic management, resilience engineering, observability, security, and modern microservices best practices using Istio and Kubernetes.
When to Use This Skill
Use this skill when:
- Architecting microservices-based applications with distributed systems
- Implementing service mesh infrastructure for service-to-service communication
- Adding resilience patterns like circuit breakers, retries, and timeouts
- Managing traffic routing, load balancing, and canary deployments
- Implementing distributed tracing and observability across microservices
- Securing microservices with mTLS and authorization policies
- Troubleshooting cascading failures and service degradation
- Building fault-tolerant distributed systems
- Implementing blue-green deployments and A/B testing
- Managing multi-cluster microservices deployments
- Implementing chaos engineering and fault injection
- Migrating from monolithic to microservices architecture
Core Concepts
Microservices Architecture
Microservices architecture structures an application as a collection of loosely coupled services:
- Service Independence: Each service is independently deployable and scalable
- Domain-Driven Design: Services align with business capabilities
- Decentralized Data: Each service owns its data store
- API-First: Services communicate via well-defined APIs
- Polyglot Persistence: Different services can use different databases
- Failure Isolation: Service failures don't cascade across the system
Service Mesh Fundamentals
A service mesh is an infrastructure layer for handling service-to-service communication:
- Data Plane: Sidecar proxies (Envoy) deployed alongside each service
- Control Plane: Manages and configures proxies (Istio, Linkerd, Consul)
- Service Discovery: Automatic service registration and discovery
- Load Balancing: Intelligent traffic distribution across service instances
- Observability: Built-in metrics, logs, and distributed tracing
- Security: mTLS, authentication, and authorization
Istio Architecture
Istio is the most popular service mesh implementation:
Control Plane Components:
- Istiod: Unified control plane for service discovery, configuration, and certificate management
- Pilot: Traffic management and service discovery
- Citadel: Certificate authority for mTLS
- Galley: Configuration validation and distribution
Data Plane:
- Envoy Proxy: High-performance sidecar proxy for each service
- Iptables Rules: Transparent traffic interception
- Service Proxy: Handles all network traffic for the service
Key Service Mesh Patterns
1. Sidecar Pattern: Proxy deployed alongside application container 2. Service Discovery: Automatic registration and discovery of services 3. Traffic Splitting: Route percentage of traffic to different versions 4. Circuit Breaker: Prevent cascading failures 5. Retry Logic: Automatic retry with exponential backoff 6. Timeout Policies: Request timeout configuration 7. Fault Injection: Chaos testing in production 8. Rate Limiting: Protect services from overload 9. mTLS: Mutual TLS for service-to-service encryption 10. Distributed Tracing: Request flow across services
Traffic Management
Virtual Services
Virtual services define routing rules for traffic within the mesh:
Key Features:
- HTTP/TCP/TLS Routing: Protocol-specific routing rules
- Match Conditions: Route based on headers, URIs, methods
- Weighted Routing: Traffic splitting across versions
- Redirects and Rewrites: URL manipulation
- Fault Injection: Delay and abort injection
- Retries: Automatic retry configuration
- Timeouts: Request timeout policies
Virtual Service Structure:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3Destination Rules
Destination rules configure policies for traffic after routing:
Key Features:
- Load Balancing: Round robin, random, least request
- Connection Pools: Connection limits and timeouts
- Outlier Detection: Circuit breaker configuration
- TLS Settings: mTLS mode configuration
- Subset Definitions: Version-based service subsets
Common Load Balancing Strategies:
- ROUND_ROBIN: Default, distributes evenly
- LEAST_REQUEST: Routes to instances with fewest requests
- RANDOM: Random distribution
- PASSTHROUGH: Use original destination
Traffic Splitting
Traffic splitting enables gradual rollouts and A/B testing:
Use Cases:
- Canary Deployments: Route small percentage to new version
- Blue-Green Deployments: Switch traffic between versions
- A/B Testing: Split traffic for experimentation
- Dark Launches: Shadow traffic to new version
Progressive Delivery Pattern:
v1: 100% → 90% → 70% → 50% → 20% → 0%
v2: 0% → 10% → 30% → 50% → 80% → 100%Gateway Configuration
Gateways manage ingress and egress traffic:
Ingress Gateway:
- External traffic entry point
- TLS termination
- Protocol-specific routing
- Virtual hosting
Egress Gateway:
- Control outbound traffic
- Security policies for external services
- Traffic monitoring and logging
Resilience Patterns
Circuit Breaker Pattern
Circuit breakers prevent cascading failures by detecting and isolating failing services:
States:
- Closed: Normal operation, requests flow through
- Open: Service failing, requests fail immediately
- Half-Open: Testing if service recovered
Configuration Parameters:
- Consecutive Errors: Errors before opening circuit
- Interval: Time window for error counting
- Base Ejection Time: How long to eject failing instances
- Max Ejection Percentage: Maximum percentage of pool to eject
Benefits:
- Prevents resource exhaustion
- Fails fast instead of waiting for timeouts
- Gives failing services time to recover
- Monitors service health automatically
Retry Logic
Automatic retry with intelligent backoff strategies:
Retry Strategies:
- Fixed Delay: Constant delay between retries
- Exponential Backoff: Increasing delay between retries
- Jittered Backoff: Random jitter to prevent thundering herd
Configuration:
- Attempts: Maximum number of retries
- Per Try Timeout: Timeout for each attempt
- Retry On: Conditions triggering retry (5xx, timeout, refused-stream)
- Backoff: Base interval and maximum interval
Best Practices:
- Only retry idempotent operations
- Use exponential backoff with jitter
- Set maximum retry attempts
- Monitor retry rates
Timeout Policies
Timeout policies prevent indefinite waiting:
Timeout Types:
- Request Timeout: End-to-end request timeout
- Per Try Timeout: Timeout for each retry attempt
- Idle Timeout: Connection idle timeout
- Connection Timeout: Initial connection timeout
Timeout Hierarchy:
Overall Request Timeout
├─ Retry 1 (Per Try Timeout)
├─ Retry 2 (Per Try Timeout)
└─ Retry 3 (Per Try Timeout)Best Practices:
- Set timeouts based on SLA requirements
- Use shorter timeouts for critical paths
- Configure per-try timeouts lower than overall timeout
- Monitor timeout rates and adjust
Bulkhead Pattern
Bulkheads isolate resources to prevent complete system failure:
Implementation:
- Thread Pools: Separate thread pools per service
- Connection Pools: Limited connections per upstream
- Queue Limits: Bounded queues to prevent memory issues
- Semaphores: Limit concurrent requests
Configuration:
- Max Connections: Maximum concurrent connections
- Max Requests Per Connection: HTTP/2 concurrent requests
- Max Pending Requests: Queue size for pending requests
- Connection Timeout: Time to establish connection
Rate Limiting
Rate limiting protects services from overload:
Rate Limit Types:
- Global Rate Limiting: Across all instances
- Local Rate Limiting: Per instance
- User-Based: Per user or API key
- Endpoint-Based: Per API endpoint
Algorithms:
- Token Bucket: Allows bursts while maintaining average rate
- Leaky Bucket: Smooths out traffic spikes
- Fixed Window: Simple time-window based limiting
- Sliding Window: More accurate than fixed window
Load Balancing
Service-Level Load Balancing
Istio provides intelligent Layer 7 load balancing:
Load Balancing Algorithms:
1. Round Robin
- Default algorithm
- Equal distribution across instances
- Simple and predictable
- Good for homogeneous instances
2. Least Request
- Routes to instance with fewest active requests
- Better for heterogeneous instances
- Adapts to varying response times
- Requires request tracking overhead
3. Random
- Random instance selection
- No state required
- Good for large pools
- Statistical distribution over time
4. Consistent Hash
- Hash-based routing (sticky sessions)
- Same client → same backend
- Good for caching scenarios
- Uses headers, cookies, or source IP
Connection Pool Management
Connection pools control resource usage:
TCP Settings:
- Max Connections: Total connections to upstream
- Connect Timeout: Connection establishment timeout
- TCP Keep Alive: Keep-alive probe configuration
HTTP Settings:
- HTTP1 Max Pending Requests: Queue size
- HTTP2 Max Requests: Concurrent streams
- Max Requests Per Connection: Connection reuse limit
- Max Retries: Outstanding retry budget
Health Checking
Active and passive health checking:
Passive Health Checking (Outlier Detection):
- Monitors actual traffic
- No additional probe overhead
- Detects failures automatically
- Ejects unhealthy instances
Active Health Checking:
- Explicit health probe requests
- Independent of traffic
- Configurable intervals
- Custom health endpoints
Security
Mutual TLS (mTLS)
mTLS provides encryption and authentication for service-to-service communication:
mTLS Benefits:
- Encryption: All traffic encrypted in transit
- Authentication: Services authenticate to each other
- Authorization: Service identity for policy enforcement
- Certificate Rotation: Automatic certificate management
mTLS Modes:
- STRICT: Require mTLS for all traffic
- PERMISSIVE: Accept both mTLS and plaintext (migration mode)
- DISABLE: No mTLS enforcement
Certificate Management:
- Automatic certificate issuance via Citadel
- Short-lived certificates (24 hours default)
- Automatic rotation
- SPIFFE-compliant identities
Authorization Policies
Fine-grained access control between services:
Policy Types:
- ALLOW: Explicitly allow traffic
- DENY: Explicitly deny traffic
- CUSTOM: Custom authorization logic
Match Conditions:
- Source: Source service identity, namespace, IP
- Destination: Target service, port, path
- Request: HTTP methods, headers, parameters
- JWT Claims: Token-based authorization
Policy Hierarchy:
Namespace-level default → Service-level → Specific pathsAuthentication Policies
Configure authentication requirements:
Peer Authentication:
- Service-to-service authentication
- mTLS mode configuration
- Per-port settings
Request Authentication:
- End-user authentication
- JWT validation
- Custom authentication providers
- Token forwarding
Observability
Distributed Tracing
Track requests across microservices:
Key Concepts:
- Trace: Complete request journey
- Span: Individual service operation
- Parent-Child Relationships: Service call hierarchy
- Trace Context: Propagated metadata
Tracing Backends:
- Jaeger: CNCF distributed tracing
- Zipkin: Twitter's distributed tracing
- Tempo: Grafana's tracing backend
- AWS X-Ray: AWS distributed tracing
Trace Sampling:
- Always Sample: 100% sampling (development)
- Probabilistic: Sample percentage (e.g., 1%)
- Rate Limiting: Maximum traces per second
- Adaptive: Dynamic sampling based on traffic
Metrics Collection
Istio provides rich metrics automatically:
Service Metrics:
- Request Rate: Requests per second
- Error Rate: Percentage of failed requests
- Duration: Request latency (p50, p95, p99)
- Request Size: Request/response payload sizes
Infrastructure Metrics:
- CPU/Memory: Resource utilization
- Connection Pool: Pool statistics
- Circuit Breaker: Circuit state and events
- Retry/Timeout: Retry and timeout rates
Golden Signals: 1. Latency: How long requests take 2. Traffic: Request rate 3. Errors: Error rate 4. Saturation: Resource utilization
Logging
Structured logging for microservices:
Log Types:
- Access Logs: Request/response logging
- Application Logs: Service-specific logs
- Proxy Logs: Envoy sidecar logs
- Control Plane Logs: Istio component logs
Access Log Format:
{
"timestamp": "2025-10-18T10:30:00Z",
"method": "GET",
"path": "/api/users",
"status": 200,
"duration_ms": 45,
"upstream_service": "user-service-v2",
"trace_id": "abc123",
"user_agent": "mobile-app/2.1"
}Kiali Visualization
Kiali provides service mesh observability:
Features:
- Service Graph: Visual topology of services
- Traffic Flow: Request flow visualization
- Health Status: Service health indicators
- Configuration Validation: Istio config validation
- Distributed Tracing: Integrated Jaeger traces
Best Practices
Service Design
1. Single Responsibility: Each service does one thing well 2. API-First Design: Define APIs before implementation 3. Idempotency: Design idempotent operations for safety 4. Versioning: Support multiple API versions 5. Backward Compatibility: Don't break existing clients
Deployment Strategies
1. Blue-Green Deployment
- Maintain two identical environments
- Switch traffic atomically
- Easy rollback
- Higher resource cost
2. Canary Deployment
- Gradual rollout to subset of users
- Monitor metrics before full rollout
- Lower risk than big-bang
- More complex orchestration
3. Rolling Update
- Gradual replacement of instances
- No additional resources needed
- Kubernetes native support
- Temporary version coexistence
4. Dark Launch
- Route shadow traffic to new version
- Test with production traffic
- No user impact
- Validate before real traffic
Resilience Engineering
1. Design for Failure: Assume services will fail 2. Fail Fast: Don't wait for timeouts 3. Graceful Degradation: Partial functionality better than none 4. Idempotent Retries: Safe to retry operations 5. Bulkhead Isolation: Isolate failure domains 6. Circuit Breakers: Prevent cascading failures 7. Timeouts Everywhere: Never wait indefinitely 8. Chaos Engineering: Test failure scenarios
Configuration Management
1. Namespace Isolation: Separate environments (dev, staging, prod) 2. GitOps: Store configs in Git 3. Validation: Validate configs before applying 4. Incremental Rollout: Test configs in dev first 5. Version Control: Track all config changes 6. Documentation: Document configuration decisions
Security Best Practices
1. mTLS by Default: Always encrypt service traffic 2. Least Privilege: Minimal authorization policies 3. Network Segmentation: Isolate services by namespace 4. Secret Management: Never hardcode secrets 5. Regular Updates: Keep Istio and Envoy updated 6. Audit Logging: Log all authorization decisions
Monitoring and Alerting
1. SLI/SLO/SLA: Define service level objectives 2. Dashboard Design: Focus on actionable metrics 3. Alert Fatigue: Only alert on actionable items 4. Error Budgets: Balance reliability and velocity 5. Runbooks: Document incident response 6. Post-Mortems: Learn from failures
Performance Optimization
1. Connection Pooling: Reuse connections 2. Request Batching: Batch when possible 3. Caching: Cache at multiple levels 4. Compression: Enable response compression 5. Protocol Selection: HTTP/2 or gRPC for efficiency 6. Resource Limits: Set appropriate limits 7. Horizontal Scaling: Scale out, not up
Migration Strategy
Strangler Pattern for monolith migration:
Phase 1: Route some traffic to microservices
Monolith (90%) + Microservices (10%)
Phase 2: Gradually increase microservice traffic
Monolith (70%) + Microservices (30%)
Phase 3: Continue migration
Monolith (40%) + Microservices (60%)
Phase 4: Complete migration
Monolith (0%) + Microservices (100%)Common Patterns
Pattern 1: API Gateway Pattern
Single entry point for all client requests:
Components:
- External gateway (Istio Ingress)
- Virtual services for routing
- Rate limiting and authentication
- TLS termination
Benefits:
- Simplified client interface
- Centralized authentication
- Protocol translation
- Request aggregation
Pattern 2: Backend for Frontend (BFF)
Dedicated backend for each frontend type:
Use Cases:
- Mobile app has different needs than web
- Different data aggregation per client
- Client-specific optimization
- Reduced over-fetching
Implementation:
- Separate BFF service per client type
- Route by user-agent or subdomain
- Optimize responses per client
- Independent scaling
Pattern 3: Saga Pattern
Distributed transaction management:
Choreography-Based:
- Services publish events
- Other services react to events
- No central coordinator
- Loose coupling
Orchestration-Based:
- Central orchestrator
- Explicit transaction flow
- Easier to understand
- Single point of coordination
Pattern 4: CQRS (Command Query Responsibility Segregation)
Separate read and write models:
Benefits:
- Optimized read and write paths
- Independent scaling
- Different data models
- Event sourcing compatibility
Implementation:
- Write service updates data
- Read service queries optimized views
- Event bus for synchronization
- Eventually consistent reads
Pattern 5: Service Registry Pattern
Dynamic service discovery:
Components:
- Service registry (Kubernetes DNS)
- Service registration (automatic)
- Service discovery (Istio pilot)
- Health checking
Benefits:
- Dynamic scaling
- Automatic failover
- No hardcoded endpoints
- Location transparency
Pattern 6: Sidecar Pattern
Deploy auxiliary functionality alongside service:
Common Sidecars:
- Envoy proxy (traffic management)
- Log shipper (centralized logging)
- Metric collector (monitoring)
- Secret manager (credential injection)
Benefits:
- Separation of concerns
- Polyglot support
- Consistent functionality
- Independent updates
Pattern 7: Ambassador Pattern
Proxy for external service access:
Use Cases:
- Legacy system integration
- External API rate limiting
- Protocol translation
- Caching external responses
Implementation:
- Sidecar for external calls
- Circuit breaker for external service
- Retry logic and timeouts
- Monitoring and logging
Pattern 8: Anti-Corruption Layer
Isolate legacy system complexity:
Purpose:
- Translate between domain models
- Protect new architecture
- Gradual migration support
- Legacy system abstraction
Implementation:
- Adapter service layer
- Model translation
- Protocol conversion
- Versioning support
Advanced Techniques
Multi-Cluster Service Mesh
Extend service mesh across multiple clusters:
Use Cases:
- Multi-region deployment
- High availability
- Disaster recovery
- Compliance requirements
Implementation:
- Single control plane or multi-primary
- Service discovery across clusters
- Cross-cluster load balancing
- Consistent policies
Service Mesh Federation
Connect multiple independent service meshes:
Scenarios:
- Multiple teams/organizations
- Merger and acquisition
- Legacy mesh migration
- Different mesh implementations
Chaos Engineering
Proactively test system resilience:
Chaos Experiments:
- Service failures (pods deleted)
- Network latency injection
- Error injection (HTTP 503)
- Resource constraints (CPU/memory)
- DNS failures
- Certificate expiration
Tools:
- Istio fault injection
- Chaos Mesh
- Litmus Chaos
- Gremlin
GitOps for Service Mesh
Declarative configuration management:
Workflow: 1. Config changes in Git 2. Automated validation 3. Review and approval 4. Automated deployment 5. Continuous monitoring
Benefits:
- Version control
- Audit trail
- Disaster recovery
- Consistency
Troubleshooting
Common Issues
Issue 1: Service Not Accessible
- Check sidecar injection
- Verify VirtualService configuration
- Check DestinationRule subsets
- Validate service discovery
- Review authorization policies
Issue 2: High Latency
- Check retry and timeout settings
- Review connection pool limits
- Analyze distributed traces
- Check resource constraints
- Review load balancing algorithm
Issue 3: Circuit Breaker Not Working
- Verify outlier detection config
- Check error thresholds
- Review consecutive errors setting
- Validate base ejection time
- Monitor ejection metrics
Issue 4: mTLS Failures
- Check PeerAuthentication mode
- Verify certificate validity
- Review authorization policies
- Check namespace mesh config
- Validate Citadel operation
Issue 5: Traffic Routing Issues
- Validate VirtualService hosts
- Check subset definitions
- Review match conditions
- Verify gateway configuration
- Check service selector labels
Debugging Tools
1. istioctl: CLI for Istio management
istioctl analyze: Validate configurationistioctl proxy-status: Check proxy sync statusistioctl proxy-config: View proxy configurationistioctl dashboard: Access dashboards
2. kubectl: Kubernetes management
- Check pod status
- View logs
- Port forwarding
- Resource inspection
3. Kiali: Service mesh visualization
- Service graph
- Traffic flow
- Configuration validation
- Distributed tracing
4. Jaeger: Distributed tracing
- Request traces
- Latency analysis
- Service dependencies
- Error identification
5. Prometheus/Grafana: Metrics and visualization
- Service metrics
- Custom dashboards
- Alerting rules
- Historical analysis
Example Scenarios
Scenario 1: E-Commerce Microservices
Architecture:
- Frontend (React SPA)
- API Gateway
- Product Service
- Cart Service
- Order Service
- Payment Service
- Inventory Service
- Notification Service
Traffic Management:
- Canary deployment for new product search
- Circuit breaker on payment service
- Retry logic for inventory checks
- Timeout policies for external payment API
- Rate limiting on API gateway
Resilience:
- Graceful degradation if recommendations fail
- Bulkhead isolation for payment processing
- Fallback to cached product data
- Queue for async notifications
Scenario 2: Streaming Platform
Architecture:
- Video Service (transcoding)
- Metadata Service (content info)
- Recommendation Service (ML-based)
- User Service (profiles)
- CDN Integration
- Analytics Service
Traffic Management:
- A/B testing for recommendation algorithm
- Geographic routing to edge services
- Load balancing based on server capacity
- Traffic splitting for new video player
Performance:
- HTTP/2 for reduced latency
- Connection pooling for database
- Caching at multiple levels
- Adaptive bitrate streaming
Scenario 3: Financial Services Platform
Architecture:
- Account Service
- Transaction Service
- Fraud Detection Service
- Reporting Service
- External Bank Integration
- Audit Service
Security:
- Strict mTLS for all services
- Fine-grained authorization policies
- Audit logging for compliance
- Network segmentation by sensitivity
Resilience:
- Circuit breaker for external banks
- Idempotent transaction processing
- Saga pattern for distributed transactions
- Event sourcing for audit trail
Integration Patterns
Database per Service
Each microservice owns its database:
Benefits:
- Independent scaling
- Technology choice freedom
- Failure isolation
- Clear ownership
Challenges:
- Distributed transactions
- Data consistency
- Query complexity
- Data duplication
Solutions:
- Event-driven architecture
- Saga pattern
- CQRS
- API composition
Event-Driven Architecture
Asynchronous communication via events:
Components:
- Event producers
- Event bus (Kafka, RabbitMQ)
- Event consumers
- Event store
Patterns:
- Event notification
- Event-carried state transfer
- Event sourcing
- CQRS
API Composition
Aggregate data from multiple services:
Implementation:
- API Gateway queries services
- Parallel service calls
- Response aggregation
- Error handling
Optimization:
- Caching
- Request batching
- Partial responses
- Timeout management
Resources and References
Official Documentation
- Istio Documentation: https://istio.io/docs
- Kubernetes Documentation: https://kubernetes.io/docs
- Envoy Proxy: https://www.envoyproxy.io/docs
- CNCF Service Mesh Landscape: https://landscape.cncf.io/card-mode?category=service-mesh
Books and Papers
- "Building Microservices" by Sam Newman
- "Microservices Patterns" by Chris Richardson
- "Production-Ready Microservices" by Susan Fowler
- "The Art of Scalability" by Martin Abbott
Tools and Platforms
- Istio: Service mesh control plane
- Linkerd: Lightweight service mesh
- Consul Connect: HashiCorp service mesh
- AWS App Mesh: AWS-native service mesh
- Kiali: Service mesh observability
- Jaeger: Distributed tracing
- Prometheus: Metrics collection
- Grafana: Visualization
Community Resources
- Istio Blog: https://istio.io/blog
- CNCF Slack: #istio channel
- Stack Overflow: [istio] tag
- GitHub: istio/istio repository
---
Skill Version: 1.0.0 Last Updated: October 2025 Skill Category: Microservices, Service Mesh, Cloud Native, DevOps Compatible With: Istio 1.20+, Kubernetes 1.28+, Envoy Proxy Prerequisites: Kubernetes knowledge, containerization, networking basics
Microservices Patterns - Comprehensive Examples
This document provides detailed, production-ready examples of microservices patterns using Istio and Kubernetes.
Table of Contents
1. Istio Installation and Configuration 2. Basic Service Deployment with Sidecar 3. Virtual Service for Intelligent Routing 4. Destination Rule with Load Balancing 5. Circuit Breaker Implementation 6. Retry and Timeout Policies 7. Canary Deployment with Traffic Splitting 8. Blue-Green Deployment 9. Fault Injection for Chaos Testing 10. mTLS Security Configuration 11. Authorization Policies 12. Gateway Configuration for Ingress 13. Rate Limiting Implementation 14. Distributed Tracing Setup 15. Multi-Cluster Service Mesh 16. Service Mesh Federation 17. Observability with Kiali 18. Advanced Traffic Management 19. Saga Pattern Implementation 20. API Gateway Pattern
---
Example 1: Istio Installation and Configuration
Prerequisites
# Ensure Kubernetes cluster is running
kubectl cluster-info
# Check kubectl version (1.28+ recommended)
kubectl version --clientInstall Istio
# Download Istio (latest stable version)
curl -L https://istio.io/downloadIstio | sh -
# Navigate to Istio directory
cd istio-1.20.0
# Add istioctl to PATH
export PATH=$PWD/bin:$PATH
# Verify istioctl installation
istioctl versionInstall Istio with Custom Profile
# Option 1: Demo profile (for learning/testing)
istioctl install --set profile=demo -y
# Option 2: Production profile
istioctl install --set profile=production -y
# Option 3: Custom configuration
cat <<EOF | istioctl install -y -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istio-controlplane
spec:
profile: production
meshConfig:
accessLogFile: /dev/stdout
enableTracing: true
defaultConfig:
tracing:
sampling: 10.0
zipkin:
address: zipkin.istio-system:9411
components:
pilot:
k8s:
resources:
requests:
cpu: 500m
memory: 2048Mi
hpaSpec:
minReplicas: 2
maxReplicas: 5
ingressGateways:
- name: istio-ingressgateway
enabled: true
k8s:
resources:
requests:
cpu: 500m
memory: 512Mi
hpaSpec:
minReplicas: 2
maxReplicas: 5
service:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http2
- port: 443
targetPort: 8443
name: https
EOFVerify Installation
# Check Istio components
kubectl get pods -n istio-system
# Expected output:
# istio-ingressgateway-xxx 1/1 Running
# istiod-xxx 1/1 Running
# Verify installation
istioctl verify-install
# Check mesh configuration
kubectl get configmap istio -n istio-system -o yamlEnable Sidecar Injection
# Enable automatic sidecar injection for default namespace
kubectl label namespace default istio-injection=enabled
# Verify namespace label
kubectl get namespace -L istio-injection
# Enable for specific namespaces
kubectl label namespace production istio-injection=enabled
kubectl label namespace staging istio-injection=enabledInstall Observability Add-ons
# Install Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons/
# Wait for deployments
kubectl rollout status deployment/kiali -n istio-system
kubectl rollout status deployment/prometheus -n istio-system
kubectl rollout status deployment/grafana -n istio-system
kubectl rollout status deployment/jaeger -n istio-system
# Access dashboards (in separate terminals)
istioctl dashboard kiali
istioctl dashboard prometheus
istioctl dashboard grafana
istioctl dashboard jaeger---
Example 2: Basic Service Deployment with Sidecar
Application Deployment
# deployment.yaml
apiVersion: v1
kind: Service
metadata:
name: product-service
labels:
app: product
service: product
spec:
ports:
- port: 8080
name: http
targetPort: 8080
selector:
app: product
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: product-v1
labels:
app: product
version: v1
spec:
replicas: 3
selector:
matchLabels:
app: product
version: v1
template:
metadata:
labels:
app: product
version: v1
spec:
containers:
- name: product
image: myregistry/product-service:v1
ports:
- containerPort: 8080
env:
- name: VERSION
value: "v1"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5Deploy and Verify Sidecar
# Deploy the service
kubectl apply -f deployment.yaml
# Verify pods have 2 containers (app + sidecar)
kubectl get pods -l app=product
# Expected output:
# NAME READY STATUS RESTARTS AGE
# product-v1-xxx 2/2 Running 0 1m
# Check sidecar injection
kubectl describe pod product-v1-xxx | grep -A 10 "istio-proxy"
# View sidecar logs
kubectl logs product-v1-xxx -c istio-proxy
# Check proxy configuration
istioctl proxy-config listeners product-v1-xxx
istioctl proxy-config routes product-v1-xxx
istioctl proxy-config clusters product-v1-xxxManual Sidecar Injection (Alternative)
# For namespaces without automatic injection
istioctl kube-inject -f deployment.yaml | kubectl apply -f -
# Or generate injected YAML
istioctl kube-inject -f deployment.yaml > deployment-injected.yaml
kubectl apply -f deployment-injected.yaml---
Example 3: Virtual Service for Intelligent Routing
Header-Based Routing
# virtualservice-header-routing.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-routes
spec:
hosts:
- product-service
http:
# Route premium users to v2
- match:
- headers:
user-tier:
exact: premium
route:
- destination:
host: product-service
subset: v2
# Route mobile app to v2
- match:
- headers:
user-agent:
regex: ".*Mobile.*"
route:
- destination:
host: product-service
subset: v2
# Default route to v1
- route:
- destination:
host: product-service
subset: v1URI-Based Routing
# virtualservice-uri-routing.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routes
spec:
hosts:
- api.example.com
http:
# Route /api/v2/* to new service
- match:
- uri:
prefix: /api/v2
rewrite:
uri: /
route:
- destination:
host: api-service-v2
port:
number: 8080
# Route /api/v1/* to legacy service
- match:
- uri:
prefix: /api/v1
rewrite:
uri: /
route:
- destination:
host: api-service-v1
port:
number: 8080
# Redirect old paths
- match:
- uri:
exact: /old-api
redirect:
uri: /api/v2
authority: api.example.comMethod-Based Routing
# virtualservice-method-routing.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-routes
spec:
hosts:
- order-service
http:
# Read operations to read-optimized service
- match:
- method:
exact: GET
route:
- destination:
host: order-read-service
# Write operations to write service
- match:
- method:
regex: "POST|PUT|DELETE"
route:
- destination:
host: order-write-serviceApply and Test
# Apply virtual service
kubectl apply -f virtualservice-header-routing.yaml
# Test header-based routing
kubectl run -it --rm test-pod --image=curlimages/curl --restart=Never -- \
curl -H "user-tier: premium" http://product-service:8080/
# Verify routing
istioctl proxy-config routes product-v1-xxx --name 8080 -o json---
Example 4: Destination Rule with Load Balancing
Round Robin Load Balancing
# destinationrule-roundrobin.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: product-lb
spec:
host: product-service
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 50
http2MaxRequests: 100
maxRequestsPerConnection: 2
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2Least Request Load Balancing
# destinationrule-leastrequest.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: recommendation-lb
spec:
host: recommendation-service
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST
leastRequestLbConfig:
choiceCount: 2 # P2C (Power of Two Choices)
connectionPool:
tcp:
maxConnections: 50
connectTimeout: 5s
tcpKeepalive:
time: 7200s
interval: 75s
http:
http2MaxRequests: 100
maxRequestsPerConnection: 5Consistent Hash Load Balancing
# destinationrule-consistenthash.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: session-lb
spec:
host: session-service
trafficPolicy:
loadBalancer:
consistentHash:
# Option 1: Hash by HTTP header
httpHeaderName: "user-id"
# Option 2: Hash by cookie
# httpCookie:
# name: "session-cookie"
# ttl: 3600s
# Option 3: Hash by source IP
# useSourceIp: trueApply and Monitor
# Apply destination rule
kubectl apply -f destinationrule-roundrobin.yaml
# Verify configuration
istioctl proxy-config cluster product-v1-xxx --fqdn product-service.default.svc.cluster.local -o json
# Monitor load balancing
kubectl logs -l app=product -c istio-proxy --tail=100 -f---
Example 5: Circuit Breaker Implementation
Comprehensive Circuit Breaker
# destinationrule-circuitbreaker.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: payment-circuit-breaker
spec:
host: payment-service
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 50
http2MaxRequests: 100
maxRequestsPerConnection: 2
idleTimeout: 60s
outlierDetection:
consecutiveGatewayErrors: 5
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
minHealthPercent: 40
splitExternalLocalOriginErrors: true
subsets:
- name: v1
labels:
version: v1
trafficPolicy:
outlierDetection:
consecutiveGatewayErrors: 3
consecutive5xxErrors: 3
interval: 20s
baseEjectionTime: 60sTest Circuit Breaker
# Deploy test client
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: load-test
spec:
containers:
- name: fortio
image: fortio/fortio
command: ["/bin/sh", "-c", "sleep 3600"]
EOF
# Wait for pod
kubectl wait --for=condition=Ready pod/load-test
# Test normal load
kubectl exec load-test -c fortio -- \
fortio load -c 2 -qps 0 -n 20 -loglevel Warning \
http://payment-service:8080/
# Test circuit breaker triggering
kubectl exec load-test -c fortio -- \
fortio load -c 10 -qps 0 -n 1000 -loglevel Warning \
http://payment-service:8080/
# Check ejected instances
istioctl proxy-config endpoints load-test | grep payment-service
# View circuit breaker stats
kubectl exec load-test -c istio-proxy -- \
curl localhost:15000/stats | grep payment-service | grep outlierCircuit Breaker Monitoring
# servicemonitor.yaml (for Prometheus)
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: circuit-breaker-monitor
spec:
selector:
matchLabels:
app: payment
endpoints:
- port: http-envoy-prom
interval: 15sKey Metrics to Monitor:
# Ejection rate
sum(rate(envoy_cluster_outlier_detection_ejections_active[5m]))
# Consecutive errors
sum(rate(envoy_cluster_outlier_detection_ejections_consecutive_5xx[5m]))
# Overflow requests (circuit open)
sum(rate(envoy_cluster_upstream_rq_pending_overflow[5m]))---
Example 6: Retry and Timeout Policies
Comprehensive Retry Configuration
# virtualservice-retry-timeout.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-resilience
spec:
hosts:
- order-service
http:
- route:
- destination:
host: order-service
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset,connect-failure,refused-stream,retriable-status-codes
retryRemoteLocalities: true
timeout: 10s
fault:
delay:
percentage:
value: 0.1
fixedDelay: 5sPer-Route Timeout Policies
# virtualservice-route-timeouts.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-timeouts
spec:
hosts:
- api-service
http:
# Fast endpoint with short timeout
- match:
- uri:
prefix: /api/fast
route:
- destination:
host: api-service
timeout: 1s
retries:
attempts: 2
perTryTimeout: 500ms
# Slow endpoint with longer timeout
- match:
- uri:
prefix: /api/slow
route:
- destination:
host: api-service
timeout: 30s
retries:
attempts: 1
perTryTimeout: 15s
# Default
- route:
- destination:
host: api-service
timeout: 5sExponential Backoff Configuration
# envoyfilter-retry-backoff.yaml
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: retry-backoff
spec:
workloadSelector:
labels:
app: order
configPatches:
- applyTo: HTTP_ROUTE
match:
context: SIDECAR_OUTBOUND
routeConfiguration:
vhost:
name: order-service.default.svc.cluster.local:8080
patch:
operation: MERGE
value:
route:
retry_policy:
retry_back_off:
base_interval: 0.5s
max_interval: 10s
num_retries: 5Test Retry and Timeout
# Deploy test service with delays
kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
name: slow-service
spec:
selector:
app: slow
ports:
- port: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: slow-service
spec:
replicas: 2
selector:
matchLabels:
app: slow
template:
metadata:
labels:
app: slow
spec:
containers:
- name: httpbin
image: kennethreitz/httpbin
ports:
- containerPort: 80
EOF
# Test timeout
kubectl run -it --rm test --image=curlimages/curl --restart=Never -- \
curl -v http://slow-service:8080/delay/15
# Monitor retries
kubectl logs -l app=order -c istio-proxy --tail=100 | grep -i retry---
Example 7: Canary Deployment with Traffic Splitting
Initial Setup - Deploy v1
# product-v1-deployment.yaml
apiVersion: v1
kind: Service
metadata:
name: product-service
spec:
selector:
app: product
ports:
- port: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: product-v1
spec:
replicas: 3
selector:
matchLabels:
app: product
version: v1
template:
metadata:
labels:
app: product
version: v1
spec:
containers:
- name: product
image: myregistry/product:v1
ports:
- containerPort: 8080Deploy Canary v2
# product-v2-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: product-v2
spec:
replicas: 1 # Start with 1 replica for canary
selector:
matchLabels:
app: product
version: v2
template:
metadata:
labels:
app: product
version: v2
canary: "true"
spec:
containers:
- name: product
image: myregistry/product:v2
ports:
- containerPort: 8080Traffic Splitting Configuration
# canary-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-canary
spec:
hosts:
- product-service
http:
- match:
- headers:
canary:
exact: "true"
route:
- destination:
host: product-service
subset: v2
- route:
- destination:
host: product-service
subset: v1
weight: 95
- destination:
host: product-service
subset: v2
weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: product-canary
spec:
host: product-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2Progressive Rollout Script
#!/bin/bash
# canary-rollout.sh
# Stage 1: 5% canary
echo "Stage 1: 5% traffic to v2"
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-canary
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
subset: v1
weight: 95
- destination:
host: product-service
subset: v2
weight: 5
EOF
echo "Monitoring for 5 minutes..."
sleep 300
# Check error rates
ERROR_RATE=$(kubectl logs -l app=product,version=v2 -c istio-proxy --tail=1000 | \
grep -c "HTTP/1.1\" 5[0-9][0-9]")
if [ $ERROR_RATE -gt 10 ]; then
echo "High error rate detected! Rolling back..."
kubectl delete virtualservice product-canary
exit 1
fi
# Stage 2: 25% canary
echo "Stage 2: 25% traffic to v2"
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-canary
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
subset: v1
weight: 75
- destination:
host: product-service
subset: v2
weight: 25
EOF
sleep 300
# Stage 3: 50% canary
echo "Stage 3: 50% traffic to v2"
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-canary
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
subset: v1
weight: 50
- destination:
host: product-service
subset: v2
weight: 50
EOF
sleep 300
# Stage 4: 100% canary
echo "Stage 4: 100% traffic to v2"
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-canary
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
subset: v2
weight: 100
EOF
# Scale down v1
kubectl scale deployment product-v1 --replicas=0
echo "Canary rollout complete!"Monitor Canary Deployment
# Monitor traffic distribution
watch -n 1 'kubectl logs -l app=product -c istio-proxy --tail=50 | grep "HTTP/1.1" | tail -10'
# Check metrics in Prometheus
# v1 traffic
sum(rate(istio_requests_total{destination_service="product-service",destination_version="v1"}[1m]))
# v2 traffic
sum(rate(istio_requests_total{destination_service="product-service",destination_version="v2"}[1m]))
# Error rate comparison
sum(rate(istio_requests_total{destination_service="product-service",destination_version="v2",response_code=~"5.."}[1m]))---
Example 8: Blue-Green Deployment
Setup Blue (Current) and Green (New) Deployments
# bluegreen-deployment.yaml
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
ports:
- port: 8080
---
# Blue deployment (current production)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
deployment: blue
template:
metadata:
labels:
app: myapp
deployment: blue
version: v1
spec:
containers:
- name: app
image: myregistry/myapp:v1.0
ports:
- containerPort: 8080
---
# Green deployment (new version)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
deployment: green
template:
metadata:
labels:
app: myapp
deployment: green
version: v2
spec:
containers:
- name: app
image: myregistry/myapp:v2.0
ports:
- containerPort: 8080Blue-Green Traffic Control
# bluegreen-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-bluegreen
spec:
hosts:
- app-service
http:
- route:
- destination:
host: app-service
subset: blue
weight: 100
- destination:
host: app-service
subset: green
weight: 0
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: app-bluegreen
spec:
host: app-service
subsets:
- name: blue
labels:
deployment: blue
- name: green
labels:
deployment: greenSwitch Traffic to Green
#!/bin/bash
# switch-to-green.sh
echo "Switching traffic from blue to green..."
# Switch all traffic to green
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-bluegreen
spec:
hosts:
- app-service
http:
- route:
- destination:
host: app-service
subset: green
weight: 100
EOF
echo "Traffic switched to green deployment"
echo "Blue deployment still running for quick rollback if needed"
# Monitor for 30 minutes before scaling down blue
echo "Monitoring green deployment..."
sleep 1800
# If all good, scale down blue
read -p "Scale down blue deployment? (y/n) " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
kubectl scale deployment app-blue --replicas=0
echo "Blue deployment scaled down"
fiInstant Rollback
# rollback-to-blue.sh
#!/bin/bash
echo "Rolling back to blue deployment..."
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-bluegreen
spec:
hosts:
- app-service
http:
- route:
- destination:
host: app-service
subset: blue
weight: 100
EOF
# Scale up blue if needed
kubectl scale deployment app-blue --replicas=3
echo "Rollback complete - traffic routed to blue"---
Example 9: Fault Injection for Chaos Testing
HTTP Delay Injection
# fault-injection-delay.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-delay
spec:
hosts:
- reviews-service
http:
- match:
- headers:
test-fault:
exact: "delay"
fault:
delay:
percentage:
value: 100
fixedDelay: 7s
route:
- destination:
host: reviews-service
- route:
- destination:
host: reviews-serviceHTTP Abort Injection
# fault-injection-abort.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: payment-abort
spec:
hosts:
- payment-service
http:
- match:
- headers:
test-fault:
exact: "abort"
fault:
abort:
percentage:
value: 100
httpStatus: 503
route:
- destination:
host: payment-service
- route:
- destination:
host: payment-serviceGradual Fault Injection (Chaos Engineering)
# chaos-engineering.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: cart-chaos
spec:
hosts:
- cart-service
http:
- fault:
delay:
percentage:
value: 10 # 10% of requests
fixedDelay: 5s
abort:
percentage:
value: 5 # 5% of requests
httpStatus: 500
route:
- destination:
host: cart-serviceTest Fault Injection
# Test delay injection
kubectl run -it --rm test --image=curlimages/curl --restart=Never -- \
time curl -H "test-fault: delay" http://reviews-service:8080/
# Test abort injection
kubectl run -it --rm test --image=curlimages/curl --restart=Never -- \
curl -v -H "test-fault: abort" http://payment-service:8080/
# Monitor impact on dependent services
kubectl logs -l app=frontend -c istio-proxy --tail=100 -fAdvanced Chaos Testing
# multi-fault-chaos.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-chaos-test
spec:
hosts:
- order-service
http:
# Simulate database slowdown
- match:
- uri:
prefix: /api/orders
fault:
delay:
percentage:
value: 30
fixedDelay: 2s
route:
- destination:
host: order-service
timeout: 5s
retries:
attempts: 2
perTryTimeout: 2s
retryOn: 5xx
# Simulate payment gateway failures
- match:
- uri:
prefix: /api/payment
fault:
abort:
percentage:
value: 20
httpStatus: 503
route:
- destination:
host: order-service---
Example 10: mTLS Security Configuration
Enable Mesh-Wide mTLS (STRICT Mode)
# mtls-strict.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICTNamespace-Level mTLS
# mtls-namespace.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: production-mtls
namespace: production
spec:
mtls:
mode: STRICT
---
# Staging with permissive mode (for migration)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: staging-mtls
namespace: staging
spec:
mtls:
mode: PERMISSIVEService-Level mTLS
# mtls-service.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: payment-mtls
namespace: default
spec:
selector:
matchLabels:
app: payment
mtls:
mode: STRICT
portLevelMtls:
8080:
mode: STRICT
8090:
mode: DISABLE # Health check portDestination Rule for mTLS
# destinationrule-mtls.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: backend-mtls
spec:
host: backend-service
trafficPolicy:
tls:
mode: ISTIO_MUTUAL # Use Istio-generated certificates
connectionPool:
tcp:
maxConnections: 100Verify mTLS Configuration
# Check mTLS status for all services
istioctl authn tls-check product-v1-xxx payment-service
# Expected output:
# HOST:PORT STATUS SERVER CLIENT AUTHN POLICY DESTINATION RULE
# payment-service.default.svc.cluster.local:8080 OK STRICT ISTIO_MUTUAL /default payment-service/default
# View certificates
istioctl proxy-config secret product-v1-xxx -o json | jq '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | sed 's/"//g' | base64 -d | openssl x509 -text -noout
# Monitor mTLS metrics
kubectl exec product-v1-xxx -c istio-proxy -- \
curl -s localhost:15000/stats | grep ssl---
Example 11: Authorization Policies
Deny All Traffic (Secure by Default)
# authz-deny-all.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: production
spec:
{} # Empty spec = deny allAllow Specific Service-to-Service Communication
# authz-service-to-service.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: payment-policy
namespace: default
spec:
selector:
matchLabels:
app: payment
action: ALLOW
rules:
# Allow from order service
- from:
- source:
principals:
- "cluster.local/ns/default/sa/order-service"
to:
- operation:
methods: ["POST"]
paths: ["/api/process-payment"]
# Allow from admin service
- from:
- source:
principals:
- "cluster.local/ns/default/sa/admin-service"
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/*"]Path-Based Authorization
# authz-path-based.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: api-authorization
namespace: default
spec:
selector:
matchLabels:
app: api-gateway
action: ALLOW
rules:
# Public endpoints - no authentication needed
- to:
- operation:
paths:
- "/health"
- "/metrics"
- "/api/public/*"
# Protected endpoints - require authentication
- from:
- source:
requestPrincipals: ["*"]
to:
- operation:
paths: ["/api/protected/*"]
# Admin endpoints - specific principals only
- from:
- source:
principals:
- "cluster.local/ns/default/sa/admin-user"
to:
- operation:
paths: ["/api/admin/*"]Method and Header-Based Authorization
# authz-advanced.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: order-advanced-authz
namespace: default
spec:
selector:
matchLabels:
app: order
action: ALLOW
rules:
# Read operations allowed for all authenticated users
- from:
- source:
requestPrincipals: ["*"]
to:
- operation:
methods: ["GET", "HEAD"]
# Write operations require specific role
- from:
- source:
requestPrincipals: ["*"]
when:
- key: request.auth.claims[role]
values: ["admin", "order-manager"]
to:
- operation:
methods: ["POST", "PUT", "DELETE"]
# Specific IPs for sensitive operations
- from:
- source:
ipBlocks:
- "10.0.0.0/8"
- "172.16.0.0/12"
to:
- operation:
paths: ["/api/sensitive/*"]Deny Policy Example
# authz-deny.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-external-access
namespace: default
spec:
selector:
matchLabels:
app: internal-service
action: DENY
rules:
# Deny traffic not from cluster
- from:
- source:
notNamespaces: ["default", "production", "staging"]
# Deny specific paths
- to:
- operation:
paths:
- "/admin/*"
- "/debug/*"Test Authorization
# Test allowed request
kubectl exec frontend-xxx -c istio-proxy -- \
curl -v http://payment-service:8080/api/process-payment
# Test denied request
kubectl exec unauthorized-pod -c istio-proxy -- \
curl -v http://payment-service:8080/api/process-payment
# Check authorization logs
kubectl logs payment-v1-xxx -c istio-proxy | grep RBAC---
Example 12: Gateway Configuration for Ingress
Basic Ingress Gateway
# gateway-basic.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: app-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "example.com"
- "www.example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-routes
spec:
hosts:
- "example.com"
- "www.example.com"
gateways:
- app-gateway
http:
- match:
- uri:
prefix: /api
route:
- destination:
host: api-service
port:
number: 8080
- match:
- uri:
prefix: /
route:
- destination:
host: frontend-service
port:
number: 3000HTTPS Gateway with TLS
# gateway-https.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: secure-gateway
spec:
selector:
istio: ingressgateway
servers:
# HTTP to HTTPS redirect
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "secure.example.com"
tls:
httpsRedirect: true
# HTTPS endpoint
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: example-com-cert # Kubernetes secret
hosts:
- "secure.example.com"Create TLS Secret
# Create self-signed certificate (for testing)
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes \
-subj "/CN=secure.example.com"
# Create Kubernetes secret in istio-system namespace
kubectl create -n istio-system secret tls example-com-cert \
--key=key.pem \
--cert=cert.pem
# Or use cert-manager for automatic certificate management
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com
namespace: istio-system
spec:
secretName: example-com-cert
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- secure.example.com
- www.secure.example.com
EOFMulti-Host Gateway
# gateway-multi-host.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: multi-host-gateway
spec:
selector:
istio: ingressgateway
servers:
# API subdomain
- port:
number: 443
name: https-api
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: api-example-com-cert
hosts:
- "api.example.com"
# App subdomain
- port:
number: 443
name: https-app
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: app-example-com-cert
hosts:
- "app.example.com"
# Admin subdomain with client cert
- port:
number: 443
name: https-admin
protocol: HTTPS
tls:
mode: MUTUAL
credentialName: admin-example-com-cert
caCertificates: /etc/istio/admin-ca-cert/ca.crt
hosts:
- "admin.example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routes
spec:
hosts:
- "api.example.com"
gateways:
- multi-host-gateway
http:
- route:
- destination:
host: api-service
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-routes
spec:
hosts:
- "app.example.com"
gateways:
- multi-host-gateway
http:
- route:
- destination:
host: frontend-service
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: admin-routes
spec:
hosts:
- "admin.example.com"
gateways:
- multi-host-gateway
http:
- route:
- destination:
host: admin-serviceGet Gateway External IP
# Get LoadBalancer IP/hostname
kubectl get svc istio-ingressgateway -n istio-system
# Test gateway
curl -H "Host: example.com" http://GATEWAY_IP/
# Test HTTPS
curl -k https://secure.example.com/---
Example 13: Rate Limiting Implementation
Local Rate Limiting (EnvoyFilter)
# ratelimit-local.yaml
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: filter-local-ratelimit-svc
namespace: default
spec:
workloadSelector:
labels:
app: api-gateway
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.local_ratelimit
typed_config:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
value:
stat_prefix: http_local_rate_limiter
token_bucket:
max_tokens: 100
tokens_per_fill: 100
fill_interval: 1s
filter_enabled:
runtime_key: local_rate_limit_enabled
default_value:
numerator: 100
denominator: HUNDRED
filter_enforced:
runtime_key: local_rate_limit_enforced
default_value:
numerator: 100
denominator: HUNDRED
response_headers_to_add:
- append: false
header:
key: x-local-rate-limit
value: 'true'Per-User Rate Limiting
# ratelimit-per-user.yaml
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: filter-ratelimit-per-user
namespace: default
spec:
workloadSelector:
labels:
app: api-service
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.local_ratelimit
typed_config:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
value:
stat_prefix: http_local_rate_limiter
token_bucket:
max_tokens: 10
tokens_per_fill: 10
fill_interval: 60s
filter_enabled:
runtime_key: local_rate_limit_enabled
default_value:
numerator: 100
denominator: HUNDRED
filter_enforced:
runtime_key: local_rate_limit_enforced
default_value:
numerator: 100
denominator: HUNDRED
descriptors:
- entries:
- key: header_match
value: user_id
local_rate_limit_per_downstream_connection: falseTest Rate Limiting
# Test without rate limiting
for i in {1..200}; do
curl -s -o /dev/null -w "%{http_code}\n" http://api-service:8080/
done
# Expected: 100x 200, then 100x 429 (Too Many Requests)
# Monitor rate limit stats
kubectl exec api-service-xxx -c istio-proxy -- \
curl -s localhost:15000/stats | grep local_rate_limit---
Example 14: Distributed Tracing Setup
Enable Tracing
# telemetry-tracing.yaml
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: mesh-tracing
namespace: istio-system
spec:
tracing:
- providers:
- name: jaeger
randomSamplingPercentage: 10.0 # 10% sampling
customTags:
environment:
literal:
value: "production"
cluster:
literal:
value: "us-west-1"Deploy Jaeger
# Install Jaeger operator
kubectl create namespace observability
kubectl create -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.51.0/jaeger-operator.yaml -n observability
# Deploy Jaeger instance
kubectl apply -f - <<EOF
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: jaeger
namespace: istio-system
spec:
strategy: production
storage:
type: elasticsearch
options:
es:
server-urls: http://elasticsearch:9200
ingress:
enabled: true
hosts:
- jaeger.example.com
EOFApplication Instrumentation
# Python FastAPI example with trace context propagation
from fastapi import FastAPI, Request
import httpx
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
app = FastAPI()
# Configure tracing
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
agent_host_name="localhost",
agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
BatchSpanProcessor(jaeger_exporter)
)
# Auto-instrument FastAPI
FastAPIInstrumentor.instrument_app(app)
@app.get("/api/orders/{order_id}")
async def get_order(order_id: str, request: Request):
tracer = trace.get_tracer(__name__)
# Create custom span
with tracer.start_as_current_span("fetch-order-details") as span:
span.set_attribute("order.id", order_id)
# Call another service (propagates trace context)
async with httpx.AsyncClient() as client:
# Extract trace context from incoming request
headers = dict(request.headers)
response = await client.get(
f"http://payment-service:8080/payments/{order_id}",
headers=headers # Propagate trace context
)
return {"order_id": order_id, "payment": response.json()}View Traces
# Port forward Jaeger UI
kubectl port-forward -n istio-system svc/jaeger-query 16686:16686
# Open browser
open http://localhost:16686
# Query traces
# - Service: product-service
# - Operation: all
# - Lookback: Last hour
# - Limit: 20Analyze Trace Data
# Get trace statistics
kubectl exec -n istio-system jaeger-xxx -- \
curl -s "http://localhost:16686/api/traces?service=product-service&limit=100" | \
jq '.data[] | {traceID, duration: .spans[0].duration}'
# Find slow traces (>1s)
kubectl exec -n istio-system jaeger-xxx -- \
curl -s "http://localhost:16686/api/traces?service=product-service&minDuration=1000000" | \
jq '.data[] | {traceID, duration: .spans[0].duration, operation: .spans[0].operationName}'---
Example 15: Multi-Cluster Service Mesh
Primary-Remote Cluster Setup
On Primary Cluster:
# Set cluster context
kubectl config use-context primary-cluster
# Install Istio with multi-cluster configuration
cat <<EOF | istioctl install -y -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
meshID: mesh1
multiCluster:
clusterName: primary
network: network1
EOF
# Install east-west gateway
samples/multicluster/gen-eastwest-gateway.sh \
--mesh mesh1 --cluster primary --network network1 | \
istioctl install -y -f -
# Expose control plane
kubectl apply -f samples/multicluster/expose-istiod.yaml
# Expose services
kubectl apply -n istio-system -f samples/multicluster/expose-services.yamlOn Remote Cluster:
# Set cluster context
kubectl config use-context remote-cluster
# Create remote secret on primary
istioctl x create-remote-secret \
--context=remote-cluster \
--name=remote | \
kubectl apply -f - --context=primary-cluster
# Install Istio in remote cluster
cat <<EOF | istioctl install -y -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
meshID: mesh1
multiCluster:
clusterName: remote
network: network1
remotePilotAddress: ${ISTIOD_REMOTE_EP}
EOFDeploy Service Across Clusters
# product-service-multicluster.yaml
# Deploy in both clusters
apiVersion: v1
kind: Service
metadata:
name: product-service
labels:
app: product
spec:
ports:
- port: 8080
name: http
selector:
app: product
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: product
spec:
replicas: 2
selector:
matchLabels:
app: product
template:
metadata:
labels:
app: product
spec:
containers:
- name: product
image: product-service:v1
ports:
- containerPort: 8080Cross-Cluster Traffic Management
# virtualservice-multicluster.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-multicluster
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
port:
number: 8080
weight: 50 # 50% to primary cluster
- destination:
host: product-service.remote.global
port:
number: 8080
weight: 50 # 50% to remote clusterVerify Multi-Cluster Setup
# From primary cluster, check endpoints
istioctl proxy-config endpoints product-xxx | grep product-service
# Should show endpoints from both clusters
# Test cross-cluster communication
kubectl exec -it product-xxx -- curl product-service:8080
# Monitor cross-cluster traffic
kubectl logs -l app=product -c istio-proxy --tail=100---
Example 16: Service Mesh Federation
Setup Federation Between Meshes
Mesh A Configuration:
# mesh-a-federation.yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mesh-b-services
spec:
hosts:
- "*.mesh-b.global"
location: MESH_EXTERNAL
ports:
- number: 443
name: tls
protocol: TLS
resolution: DNS
endpoints:
- address: istio-ingressgateway.mesh-b.svc.cluster.local
ports:
tls: 15443Mesh B Configuration:
# mesh-b-federation.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: mesh-b-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 15443
name: tls
protocol: TLS
tls:
mode: AUTO_PASSTHROUGH
hosts:
- "*.mesh-b.global"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: mesh-b-services
spec:
hosts:
- "payment-service.mesh-b.global"
gateways:
- mesh-b-gateway
tls:
- match:
- sniHosts:
- "payment-service.mesh-b.global"
route:
- destination:
host: payment-service.default.svc.cluster.local---
Example 17: Observability with Kiali
Configure Kiali
# kiali-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: kiali
namespace: istio-system
data:
config.yaml: |
auth:
strategy: anonymous
deployment:
accessible_namespaces:
- '**'
external_services:
prometheus:
url: http://prometheus:9090
grafana:
url: http://grafana:3000
tracing:
enabled: true
in_cluster_url: http://tracing.istio-system:16686
url: http://jaeger.example.com
server:
web_root: /kialiAccess Kiali Dashboard
# Port forward Kiali
kubectl port-forward svc/kiali -n istio-system 20001:20001
# Open browser
open http://localhost:20001
# Or expose via LoadBalancer
kubectl patch svc kiali -n istio-system -p '{"spec":{"type":"LoadBalancer"}}'Generate Traffic for Visualization
# Install test application (Bookinfo)
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
# Generate load
for i in {1..1000}; do
curl -s http://GATEWAY_IP/productpage > /dev/null
sleep 0.5
done---
Example 18: Advanced Traffic Management
Weighted Routing with Headers
# advanced-routing.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: advanced-product-routing
spec:
hosts:
- product-service
http:
# Internal testing - route to v3
- match:
- headers:
x-internal-test:
exact: "true"
route:
- destination:
host: product-service
subset: v3
weight: 100
# Premium users - 50% to v2
- match:
- headers:
user-tier:
exact: "premium"
route:
- destination:
host: product-service
subset: v2
weight: 50
- destination:
host: product-service
subset: v1
weight: 50
# Default - mostly v1
- route:
- destination:
host: product-service
subset: v1
weight: 95
- destination:
host: product-service
subset: v2
weight: 5---
Example 19: Saga Pattern Implementation
Orchestration-Based Saga
# saga-orchestrator.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-saga-orchestrator
spec:
replicas: 2
selector:
matchLabels:
app: order-saga
template:
metadata:
labels:
app: order-saga
spec:
containers:
- name: orchestrator
image: order-saga-orchestrator:v1
env:
- name: INVENTORY_SERVICE_URL
value: "http://inventory-service:8080"
- name: PAYMENT_SERVICE_URL
value: "http://payment-service:8080"
- name: SHIPPING_SERVICE_URL
value: "http://shipping-service:8080"Saga Virtual Services with Compensation
# saga-virtualservices.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: inventory-saga
spec:
hosts:
- inventory-service
http:
- match:
- headers:
x-saga-id:
regex: ".*"
route:
- destination:
host: inventory-service
timeout: 5s
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset---
Example 20: API Gateway Pattern
Complete API Gateway Implementation
# api-gateway-complete.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: api-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: api-cert
hosts:
- "api.example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routes
spec:
hosts:
- "api.example.com"
gateways:
- api-gateway
http:
# Rate limit all endpoints
- match:
- uri:
prefix: /api/
route:
- destination:
host: api-aggregator
timeout: 30s
retries:
attempts: 3
perTryTimeout: 10s
retryOn: 5xx
corsPolicy:
allowOrigins:
- exact: "https://app.example.com"
allowMethods:
- GET
- POST
- PUT
- DELETE
allowHeaders:
- authorization
- content-type
maxAge: 24h
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: api-gateway-authz
spec:
selector:
matchLabels:
app: api-aggregator
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["*"]
to:
- operation:
paths: ["/api/*"]---
Summary
These 20 comprehensive examples cover the most important microservices patterns with Istio:
1. Installation & Configuration - Complete Istio setup 2. Basic Deployment - Service with sidecar injection 3. Virtual Services - Intelligent routing 4. Destination Rules - Load balancing strategies 5. Circuit Breakers - Fault tolerance 6. Retry & Timeout - Resilience policies 7. Canary Deployment - Progressive rollout 8. Blue-Green - Zero-downtime deployment 9. Fault Injection - Chaos engineering 10. mTLS - Security configuration 11. Authorization - Access control 12. Gateway - Ingress management 13. Rate Limiting - Traffic control 14. Distributed Tracing - Observability 15. Multi-Cluster - Cross-cluster mesh 16. Federation - Mesh interconnection 17. Kiali - Visualization 18. Advanced Routing - Complex traffic patterns 19. Saga Pattern - Distributed transactions 20. API Gateway - Complete gateway implementation
Each example is production-ready and includes deployment, configuration, testing, and monitoring steps.
---
Version: 1.0.0 Last Updated: October 2025
Microservices Patterns Skill
A comprehensive guide to building production-ready microservices with service mesh patterns, focusing on Istio, traffic management, resilience engineering, and cloud-native best practices.
Overview
This skill provides in-depth coverage of microservices architecture patterns essential for building scalable, resilient, and observable distributed systems. Whether you're migrating from a monolith or building greenfield microservices, this skill covers the critical patterns and practices needed for production deployments.
What You'll Learn
Service Mesh Fundamentals
- Architecture: Understanding control plane and data plane components
- Istio Components: Istiod, Envoy, Pilot, Citadel, and their roles
- Sidecar Pattern: Transparent traffic interception and management
- Service Discovery: Automatic service registration and discovery mechanisms
- Configuration Model: VirtualServices, DestinationRules, Gateways, and ServiceEntries
Traffic Management
Master sophisticated traffic routing and management capabilities:
- Intelligent Routing: Content-based routing using headers, URIs, and methods
- Traffic Splitting: Percentage-based routing for canary deployments
- Load Balancing: Round robin, least request, random, and consistent hash algorithms
- Gateway Configuration: Ingress and egress gateway patterns
- Protocol Support: HTTP/1.1, HTTP/2, gRPC, TCP, and TLS traffic management
Resilience Patterns
Build fault-tolerant systems with proven resilience patterns:
- Circuit Breakers: Prevent cascading failures with outlier detection
- Retry Logic: Exponential backoff and jittered retry strategies
- Timeout Policies: Request, connection, and idle timeout configuration
- Bulkhead Pattern: Resource isolation through connection pooling
- Rate Limiting: Local and global rate limiting strategies
- Fault Injection: Chaos engineering with delay and abort injection
Security
Secure microservices communication with zero-trust principles:
- Mutual TLS: Automatic certificate management and rotation
- Authentication: Peer authentication and request authentication
- Authorization: Fine-grained access control policies
- Certificate Management: SPIFFE-compliant identity framework
- Security Modes: STRICT, PERMISSIVE, and DISABLE modes for gradual migration
Observability
Gain deep insights into your microservices architecture:
- Distributed Tracing: Request flow across services with Jaeger/Zipkin
- Metrics Collection: RED (Rate, Errors, Duration) and USE (Utilization, Saturation, Errors) metrics
- Access Logging: Structured logging for all service requests
- Service Graph: Visual topology with Kiali
- Golden Signals: Latency, traffic, errors, and saturation monitoring
Getting Started
Prerequisites
Before diving into microservices patterns, ensure you have:
- Kubernetes Knowledge: Understanding of pods, services, deployments, namespaces
- Container Basics: Docker containerization and image management
- Networking Fundamentals: HTTP/HTTPS, TCP/IP, DNS, load balancing
- YAML Proficiency: Comfortable reading and writing YAML configurations
- Command Line: Familiarity with kubectl and basic shell commands
Installation
Install Istio
# Download Istio
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH
# Install Istio with demo profile
istioctl install --set profile=demo -y
# Enable automatic sidecar injection
kubectl label namespace default istio-injection=enabledVerify Installation
# Check Istio components
kubectl get pods -n istio-system
# Verify installation
istioctl verify-install
# Check version
istioctl versionInstall Observability Tools
# Install Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-systemQuick Start Examples
1. Basic Service Deployment
Deploy a simple service with Istio sidecar:
apiVersion: v1
kind: Service
metadata:
name: hello-service
spec:
selector:
app: hello
ports:
- port: 8080
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-v1
spec:
replicas: 3
selector:
matchLabels:
app: hello
version: v1
template:
metadata:
labels:
app: hello
version: v1
spec:
containers:
- name: hello
image: hello-service:v1
ports:
- containerPort: 80802. Virtual Service for Routing
Route traffic based on HTTP headers:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: hello-route
spec:
hosts:
- hello-service
http:
- match:
- headers:
user-type:
exact: premium
route:
- destination:
host: hello-service
subset: v2
- route:
- destination:
host: hello-service
subset: v13. Destination Rule with Circuit Breaker
Configure circuit breaker and load balancing:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: hello-circuit-breaker
spec:
host: hello-service
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 50
http2MaxRequests: 100
maxRequestsPerConnection: 2
outlierDetection:
consecutiveErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2Key Concepts
Service Mesh Value Proposition
A service mesh solves common distributed systems challenges:
Without Service Mesh:
- Each service implements retry logic independently
- Observability requires custom instrumentation
- Security requires per-service configuration
- Traffic management embedded in application code
- Configuration scattered across services
With Service Mesh:
- Centralized traffic management policies
- Automatic metrics, logs, and traces
- Zero-trust security by default
- Platform-level resilience patterns
- Polyglot infrastructure capabilities
Control Plane vs Data Plane
Control Plane (Istiod):
- Configuration management and distribution
- Service discovery and certificate authority
- Policy compilation and distribution
- No direct involvement in request path
- Asynchronous configuration updates
Data Plane (Envoy Proxies):
- Actual request/response handling
- Traffic routing and load balancing
- Policy enforcement (security, resilience)
- Metrics and trace generation
- In the critical request path
Sidecar Injection
Istio automatically injects Envoy proxy sidecars:
Automatic Injection:
# Enable for namespace
kubectl label namespace default istio-injection=enabled
# All pods in namespace get sidecars automaticallyManual Injection:
# Inject into specific deployment
istioctl kube-inject -f deployment.yaml | kubectl apply -f -Sidecar Container:
- Runs alongside application container in same pod
- Intercepts all network traffic via iptables
- Transparent to application code
- Shares pod network and storage
Traffic Flow
Understanding request flow through the mesh:
Client Request
↓
Ingress Gateway (Envoy)
↓
Virtual Service (routing rules)
↓
Service A Sidecar (Envoy)
↓
Service A Application
↓
Service A Sidecar (Envoy)
↓
Destination Rule (load balancing, circuit breaker)
↓
Service B Sidecar (Envoy)
↓
Service B ApplicationArchitecture Patterns
Pattern: API Gateway
Central entry point for all external traffic:
Benefits:
- Single point of authentication and rate limiting
- Protocol translation (REST to gRPC)
- Request aggregation and composition
- Simplified client interface
Implementation:
- Istio Ingress Gateway for external traffic
- Virtual Services for intelligent routing
- Authorization policies for security
- Rate limiting for protection
Pattern: Service-to-Service Communication
Internal service communication patterns:
Synchronous:
- REST APIs (HTTP/1.1)
- gRPC (HTTP/2)
- GraphQL
Asynchronous:
- Message queues (RabbitMQ, Kafka)
- Event-driven architecture
- Pub/sub patterns
Best Practices:
- Use gRPC for internal high-performance calls
- REST for external APIs
- Events for eventual consistency
- Request/response for strong consistency
Pattern: Canary Deployment
Gradually roll out new versions:
Strategy:
Stage 1: v1(95%) v2(5%) - Initial canary
Stage 2: v1(90%) v2(10%) - Monitor metrics
Stage 3: v1(70%) v2(30%) - Increase traffic
Stage 4: v1(50%) v2(50%) - Equal split
Stage 5: v1(0%) v2(100%) - Full rolloutMonitoring:
- Error rates comparison
- Latency percentiles (p50, p95, p99)
- Success rate metrics
- Business metrics (conversions, etc.)
Pattern: Blue-Green Deployment
Zero-downtime deployments with instant rollback:
Process: 1. Blue version serves 100% traffic 2. Deploy green version in parallel 3. Test green version thoroughly 4. Switch traffic from blue to green 5. Keep blue for quick rollback 6. Decommission blue after validation
Advantages:
- Instant rollback capability
- Full environment testing
- Predictable deployment process
Disadvantages:
- Requires 2x resources temporarily
- Database migration complexity
- All-or-nothing switch
Pattern: Strangler Fig
Gradually migrate from monolith to microservices:
Process: 1. Route all traffic to monolith 2. Extract one bounded context to microservice 3. Route subset of traffic to new microservice 4. Gradually increase traffic to microservice 5. Repeat for next bounded context 6. Eventually retire monolith
Benefits:
- Low-risk incremental migration
- Continuous delivery during migration
- Learn and adjust approach
- Maintain business continuity
Common Use Cases
Use Case 1: Multi-Region Deployment
Deploy services across multiple regions for high availability:
Requirements:
- Low latency for users worldwide
- Disaster recovery capability
- Data residency compliance
- Cost optimization
Implementation:
- Multi-cluster Istio mesh
- Geographic routing to nearest region
- Cross-region failover
- Region-specific data storage
Use Case 2: Multi-Tenancy
Isolate tenants in shared infrastructure:
Requirements:
- Resource isolation per tenant
- Security boundaries
- Fair resource allocation
- Tenant-specific routing
Implementation:
- Namespace per tenant
- Authorization policies for isolation
- Resource quotas
- Virtual services with tenant routing
Use Case 3: Legacy System Integration
Integrate microservices with legacy systems:
Challenges:
- Different protocols (SOAP, XML-RPC)
- Authentication mechanisms
- Performance characteristics
- Reliability issues
Solutions:
- ServiceEntry for external services
- Circuit breakers for protection
- Protocol adapters
- Anti-corruption layer pattern
Use Case 4: A/B Testing Platform
Experiment with different features:
Requirements:
- Route users to experiments
- Maintain session consistency
- Measure experiment metrics
- Quick experiment toggle
Implementation:
- Header-based routing (user-id hash)
- Consistent hash load balancing
- Metric collection per variant
- Virtual service routing rules
Troubleshooting Guide
Common Issues
Issue: Sidecar Not Injected
Symptoms: Pod doesn't have Envoy sidecar
Solutions:
# Check namespace label
kubectl get namespace -L istio-injection
# Enable injection
kubectl label namespace default istio-injection=enabled
# Restart pods
kubectl rollout restart deployment/myappIssue: 503 Service Unavailable
Symptoms: Services returning 503 errors
Solutions:
# Check sidecar status
istioctl proxy-status
# Check destination rule subsets
kubectl get destinationrule -o yaml
# Verify service endpoints
kubectl get endpoints
# Check authorization policies
kubectl get authorizationpolicyIssue: mTLS Connection Failures
Symptoms: Services can't communicate
Solutions:
# Check peer authentication
kubectl get peerauthentication -A
# Verify certificates
istioctl proxy-config secret <pod-name>
# Check mTLS mode
kubectl get destinationrule -o yaml | grep -A 5 trafficPolicyDebugging Commands
# Analyze configuration issues
istioctl analyze
# View proxy configuration
istioctl proxy-config route <pod-name>
istioctl proxy-config cluster <pod-name>
istioctl proxy-config listener <pod-name>
# Get proxy logs
kubectl logs <pod-name> -c istio-proxy
# Describe virtual service
kubectl describe virtualservice <name>
# Check mesh configuration
kubectl get configmap istio -n istio-system -o yamlPerformance Considerations
Resource Requirements
Envoy Sidecar:
- CPU: 100-500m (varies with traffic)
- Memory: 128-512Mi
- Disk: Minimal (logs only)
Control Plane (Istiod):
- CPU: 500m-2 cores
- Memory: 2-4Gi
- Scaling: Horizontal for large meshes
Optimization Techniques
1. Connection Pooling: Reuse connections to reduce overhead 2. HTTP/2: Enable for multiplexing and header compression 3. Compression: Enable gzip for large responses 4. Keep-Alive: Reduce connection establishment overhead 5. Resource Limits: Set appropriate limits and requests 6. Metrics Sampling: Sample traces in high-traffic scenarios
Scaling Strategies
Horizontal Scaling:
- Scale application pods based on CPU/memory
- Auto-scaling with HPA (Horizontal Pod Autoscaler)
- Istio handles load balancing automatically
Vertical Scaling:
- Increase pod resource limits
- Optimize application performance
- Consider instance type selection
Migration Strategies
From No Service Mesh
Phase 1: Pilot (1-2 weeks)
- Deploy Istio in one namespace
- Enable sidecar injection
- Monitor metrics and performance
- Train team on Istio concepts
Phase 2: Expand (1 month)
- Roll out to additional namespaces
- Implement basic traffic management
- Enable mTLS in PERMISSIVE mode
- Set up observability dashboards
Phase 3: Harden (ongoing)
- Switch mTLS to STRICT mode
- Implement authorization policies
- Configure circuit breakers and retries
- Chaos engineering tests
From Other Service Mesh
Considerations:
- Feature mapping (Linkerd, Consul, etc.)
- Configuration migration
- Gradual traffic shift
- Dual-mesh operation temporarily
Migration Path: 1. Deploy Istio alongside existing mesh 2. Migrate services incrementally 3. Test thoroughly per service 4. Decommission old mesh
Next Steps
Advancing Your Skills
1. Hands-On Practice: Deploy sample applications with Istio 2. Read Case Studies: Learn from production deployments 3. Contribute: Engage with Istio community 4. Certifications: Consider Istio certification programs 5. Chaos Engineering: Test resilience with fault injection
Recommended Learning Path
Week 1-2: Foundations
- Install and configure Istio
- Deploy sample microservices
- Basic traffic routing
- Service discovery
Week 3-4: Traffic Management
- Advanced routing scenarios
- Canary deployments
- Traffic splitting
- Gateway configuration
Week 5-6: Resilience
- Circuit breakers
- Retry and timeout policies
- Fault injection
- Bulkhead pattern
Week 7-8: Security
- mTLS configuration
- Authorization policies
- Authentication
- Security best practices
Week 9-10: Observability
- Distributed tracing setup
- Metrics and dashboards
- Logging configuration
- Kiali exploration
Week 11-12: Production
- Performance tuning
- Troubleshooting
- Multi-cluster setup
- GitOps workflows
Additional Resources
Official Documentation
Community
Training
Books
- "Istio: Up and Running" by Lee Calcote & Zack Butcher
- "Microservices Patterns" by Chris Richardson
- "Building Microservices" by Sam Newman
- "Production-Ready Microservices" by Susan Fowler
---
Version: 1.0.0 Last Updated: October 2025 Maintained By: Claude Skills Team License: MIT