Belajar Kubernetes - Episode 43 - Pengenalan dan Penjelasan Service Mesh
Di episode ini kita akan coba bahas Service Mesh untuk manage service-to-service communication di Kubernetes. Kita akan mempelajari Istio, Linkerd, traffic management, security, dan observability feature dari service mesh.
#Pendahuluan
Catatan
Untuk kalian yang ingin membaca episode sebelumnya, bisa click thumbnail episode 42 di bawah ini
Episode 42Di episode sebelumnya, kita menjelajahi Observability, yang enable Anda untuk understand apa yang terjadi di dalam Kubernetes cluster Anda. Sekarang kita akan mendalami Service Mesh, yang manage service-to-service communication.
Catatan: Disini saya akan menggunakan Kubernetes Cluster yang di install melalui K3s.
Ketika microservice grow, manage communication antar service menjadi complex. Service Mesh adalah dedicated infrastructure layer yang handle service-to-service communication. Pikirkan seperti traffic controller untuk microservice Anda - ini manage routing, security, dan observability tanpa require change di application code.
#Memahami Service Mesh
Service Mesh adalah configurable infrastructure layer yang handle inter-service communication di microservices architecture.
#Service Mesh vs Gateway API
Service Mesh (East-West Routing atau Service-to-Service) vs Gateway API (North-South Routing atau Public Facing)#Service Mesh Observability
Service Mesh Observability#Kubernetes Deployment Strategies
Kubernetes Deployment Strategies#Mengapa Service Mesh Penting
1. Traffic Management
Control bagaimana traffic flow antar service.
2. Security
Enforce mutual TLS dan authorization policy.
3. Observability
Automatic metrics, logs, dan traces untuk service communication.
4. Resilience
Circuit breaking, retries, dan timeout.
5. Load Balancing
Intelligent load balancing across service instance.
6. Canary Deployment
Gradually roll out new version.
7. Compliance
Meet security dan compliance requirement.
#Service Mesh Architecture
#Component
┌─────────────────────────────────────┐
│ Control Plane │
│ - Policy management │
│ - Configuration │
│ - Certificate management │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Data Plane │
│ - Sidecar proxies │
│ - Service-to-service routing │
│ - Traffic management │
└─────────────────────────────────────┘#Control Plane vs Data Plane
Control Plane
Manage configuration dan policy.
Data Plane
Execute traffic management dan security policy.
#Istio
Istio adalah most popular service mesh untuk Kubernetes.
#Installation
# Download Istio
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.19.0
# Install Istio
./bin/istioctl install --set profile=demo -y
# Enable sidecar injection
kubectl label namespace default istio-injection=enabled#Istio Component
Istiod
Control plane component yang manage configuration.
Envoy Proxy
Sidecar proxy yang handle traffic.
Ingress Gateway
Entry point untuk external traffic.
Egress Gateway
Exit point untuk external traffic.
#Sidecar Injection
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
istio-injection: enabled
---
apiVersion: v1
kind: Pod
metadata:
name: app-pod
namespace: production
spec:
containers:
- name: app
image: myapp:latest#Virtual Service dan Destination Rule
#VirtualService
Route traffic ke service:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- match:
- uri:
prefix: "/api"
route:
- destination:
host: web-app
port:
number: 8080
subset: v1
weight: 90
- destination:
host: web-app
port:
number: 8080
subset: v2
weight: 10#DestinationRule
Define load balancing dan connection pooling:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: web-app
spec:
host: web-app
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 100
maxRequestsPerConnection: 2
loadBalancer:
simple: ROUND_ROBIN
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2#Traffic Management
#Canary Deployment
Gradually shift traffic ke new version:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- match:
- headers:
user-agent:
regex: ".*Chrome.*"
route:
- destination:
host: web-app
subset: v2
- route:
- destination:
host: web-app
subset: v1
weight: 95
- destination:
host: web-app
subset: v2
weight: 5#Retry Policy
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- route:
- destination:
host: web-app
retries:
attempts: 3
perTryTimeout: 2s#Timeout
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- route:
- destination:
host: web-app
timeout: 10s#Security
#PeerAuthentication
Enforce mutual TLS:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICT#AuthorizationPolicy
Control access antar service:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: web-app-policy
spec:
selector:
matchLabels:
app: web-app
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/api-service"]
to:
- operation:
methods: ["GET"]
paths: ["/api/v1/*"]
- from:
- source:
principals: ["cluster.local/ns/default/sa/admin-service"]
to:
- operation:
methods: ["*"]#Linkerd
Linkerd adalah lightweight service mesh alternative ke Istio.
#Installation
# Install Linkerd CLI
curl https://run.linkerd.io/install | sh
# Install Linkerd
linkerd install | kubectl apply -f -
# Verify installation
linkerd check
# Enable automatic sidecar injection
kubectl annotate namespace default linkerd.io/inject=enabled#Linkerd vs Istio
| Aspek | Linkerd | Istio |
|---|---|---|
| Complexity | Simple | Complex |
| Resource Usage | Low | High |
| Features | Core features | Comprehensive |
| Learning Curve | Easy | Steep |
| Performance | Fast | Slower |
| Community | Growing | Large |
#Contoh Praktis
#Blue-Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-blue
spec:
replicas: 3
selector:
matchLabels:
app: web-app
version: blue
template:
metadata:
labels:
app: web-app
version: blue
spec:
containers:
- name: web-app
image: myapp:1.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-green
spec:
replicas: 3
selector:
matchLabels:
app: web-app
version: green
template:
metadata:
labels:
app: web-app
version: green
spec:
containers:
- name: web-app
image: myapp:2.0
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- route:
- destination:
host: web-app
subset: blue
weight: 100
- destination:
host: web-app
subset: green
weight: 0#Circuit Breaker
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: web-app
spec:
host: web-app
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
minRequestVolume: 5#Request Routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web-app
spec:
hosts:
- web-app
http:
- match:
- uri:
prefix: "/admin"
route:
- destination:
host: web-app
subset: admin
- match:
- uri:
prefix: "/api"
route:
- destination:
host: web-app
subset: api
- route:
- destination:
host: web-app
subset: web#Kesalahan dan Jebakan Umum
#Kesalahan 1: Over-Engineering
Problem: Menggunakan service mesh untuk simple deployment.
Solution: Start simple, add service mesh ketika needed:
# Start dengan basic Kubernetes
# Add service mesh ketika manage multiple service#Kesalahan 2: Not Understanding Sidecar Overhead
Problem: Unexpected performance degradation.
Solution: Monitor sidecar resource usage:
kubectl top pods -n default
kubectl describe pod pod-name#Kesalahan 3: Misconfiguring mTLS
Problem: Service tidak bisa communicate karena TLS issue.
Solution: Verify mTLS configuration:
istioctl analyze
kubectl get peerauthentication -A#Kesalahan 4: Not Monitoring Service Mesh
Problem: Can't troubleshoot service mesh issue.
Solution: Enable observability:
# Install Kiali untuk visualization
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.19/samples/addons/kiali.yaml#Kesalahan 5: Ignoring Network Policy
Problem: Service mesh tidak replace network policy.
Solution: Gunakan both service mesh dan network policy:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: web-app-policy
spec:
podSelector:
matchLabels:
app: web-app
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: api-service#Praktik Terbaik
#1. Start dengan Observability
# Install observability addon
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.19/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.19/samples/addons/grafana.yaml#2. Implement Gradual Rollout
# Gunakan canary deployment
weight: 90 # 90% ke v1
weight: 10 # 10% ke v2#3. Gunakan Namespace Isolation
# Separate namespace untuk different environment
namespaces:
- production
- staging
- development#4. Monitor Resource Usage
# Check sidecar resource consumption
kubectl top pods -n default#5. Implement Circuit Breaking
outlierDetection:
consecutive5xxErrors: 5
interval: 30s#6. Gunakan Mutual TLS
mtls:
mode: STRICT#7. Document Policy
# Service Mesh Policy
## mTLS
- Enabled: STRICT mode
- Certificate rotation: Automatic
## Traffic Management
- Canary: 10% ke new version
- Timeout: 10s#8. Test Failure Scenario
# Simulate service failure
kubectl delete pod pod-name
# Verify circuit breaker activate
kubectl logs pod-name#Service Mesh Observability
#Kiali Dashboard
Visualize service mesh:
# Access Kiali
kubectl port-forward -n istio-system svc/kiali 20000:20000
# Open http://localhost:20000#Metrics
# Request rate
rate(istio_requests_total[5m])
# Error rate
rate(istio_requests_total{response_code=~"5.."}[5m])
# Latency
histogram_quantile(0.95, rate(istio_request_duration_milliseconds_bucket[5m]))#Kapan Gunakan Service Mesh
Gunakan Service Mesh Ketika:
- Multiple microservice yang communicate
- Need advanced traffic management
- Require mutual TLS enforcement
- Want automatic observability
- Need canary deployment
Jangan Gunakan Service Mesh Ketika:
- Simple monolithic application
- Few service dengan simple communication
- Resource constraint
- Team lacks expertise
- Early-stage project
#Kesimpulan
Pada episode 43 ini, kita telah membahas Service Mesh di Kubernetes secara mendalam. Kita sudah belajar tentang Istio, Linkerd, traffic management, security, dan observability feature.
Key takeaway:
- Service Mesh manage service-to-service communication
- Istio - Most popular service mesh
- Linkerd - Lightweight alternative
- Control Plane - Manage configuration
- Data Plane - Execute policy via sidecar proxy
- VirtualService - Route traffic antar service
- DestinationRule - Define load balancing
- Traffic Management - Canary, blue-green, retries
- Mutual TLS - Automatic encryption
- AuthorizationPolicy - Control service access
- Circuit Breaking - Prevent cascading failure
- Observability - Automatic metrics dan traces
- Kiali - Visualize service mesh
- Start simple - Add complexity gradually
- Monitor overhead - Watch resource usage
Service Mesh powerful untuk manage complex microservices architecture tapi require careful planning dan implementation.