Implementing Multi-Cluster Deployments
1. Understanding Multi-Cluster Patterns
| Pattern | Detail |
|---|---|
| Hub-and-spoke | Central control plane (Argo CD, Flux) drives many clusters |
| Federated | Each cluster independent; same chart, env-specific values |
| Active-active | Same workload across regions with global LB |
| Active-passive | Standby cluster with replicas=0 until failover |
2. Managing Kubeconfig Contexts
Example: Per-cluster commands
helm --kube-context prod-us-east upgrade api ./chart -f values-us-east.yaml
helm --kube-context prod-eu-west upgrade api ./chart -f values-eu-west.yaml
kubectl config get-contexts3. Using Environment-Specific Values
Example: Layered values
helm upgrade api ./chart \
-f values.yaml \
-f values-prod.yaml \
-f values-prod-us-east.yaml \
--kube-context prod-us-east4. Implementing GitOps Workflow
| Tool | Approach |
|---|---|
| Argo CD | ApplicationSet generates per-cluster Apps from cluster list |
| Flux | HelmRelease + Kustomization per cluster |
| Rancher Fleet | Bundle-based delivery to many clusters |
5. Synchronizing Releases Across Clusters
Example: Argo CD ApplicationSet
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: { name: api }
spec:
generators:
- clusters: {}
template:
metadata: { name: 'api-{{name}}' }
spec:
source:
repoURL: https://github.com/acme/charts
path: api
helm:
valueFiles: [values.yaml, 'values-{{name}}.yaml']
destination: { server: '{{server}}', namespace: api }6. Handling Cluster-Specific Configuration
| Concern | Solution |
|---|---|
| DNS / Ingress | Per-cluster hostname value |
| Storage class | Override global.storageClass per cluster |
| Image registry | Regional mirror via global.imageRegistry |
| Replica count | Sized per cluster capacity |
7. Managing Cross-Cluster Dependencies
| Cross-cluster need | Tool |
|---|---|
| Service discovery | Submariner / Istio multicluster / Cilium ClusterMesh |
| Secrets propagation | External Secrets with central backend |
| Global LB | External-dns + Route53 / Cloudflare |
8. Implementing Blue-Green Deployments
Example: Two releases + traffic switch
helm upgrade --install api-blue ./chart -f values.yaml --set color=blue
helm upgrade --install api-green ./chart -f values.yaml --set color=green
# Switch Service selector or Ingress
kubectl patch svc api -p '{"spec":{"selector":{"color":"green"}}}'9. Managing Canary Releases
| Approach | Detail |
|---|---|
| Two releases | Stable + canary, weighted via Ingress / service mesh |
| Argo Rollouts | Rollout resource replaces Deployment with built-in canary |
| Flagger | Automated progressive delivery with metric checks |
10. Monitoring Multi-Cluster Deployments
| Layer | Tool |
|---|---|
| Release status | Argo CD UI / flux get hr -A |
| Cluster federation | Prometheus + Thanos / VictoriaMetrics cluster |
| Logging | Loki / Elastic with cluster label |
| Tracing | OpenTelemetry collector per cluster → central backend |