mohammed firdous

Kubernetes Multicluster Deployment Samples

May 2026 │ source

A set of PipeCD deployment manifests that tests multicluster pipeline patterns — canary, baseline, traffic shifting, Kustomize overlays, and Helm — across clusters in different regions.

What changed

  • Tested canary, baseline, and primary rollout strategies across two clusters in different regions (cluster-eu, cluster-us).
  • Showed per-stage cluster filtering, so canary traffic stays in one region until the full rollout starts.
  • Covered StatefulSet, DaemonSet, Init Container, and CronJob workload types alongside standard Deployments.

What I worked on

  • I wrote the app manifests and PipeCD pipeline configs for each deployment pattern.
  • I checked partial failure handling, so one failed cluster does not stop the full multi-target rollout.

PipeCD's kubernetes_multicluster plugin deploys one application to several clusters at once. This repo tests it. Each folder is a self-contained app with a pipeline config (app.pipecd.yaml) and Kubernetes manifests, and together they cover the strategies the plugin supports.

Besides the rollout strategies above, the samples cover:

  • Canary with and without service creation, and baseline deployments for A/B tests
  • Traffic shifting with both PodSelector and Istio VirtualService
  • Kustomize per-target overlays, Helm charts with custom values, and Go Template manifests

What I learned

  • Keeping traffic in one region needs explicit per-stage target filtering. Rolling out to every cluster at once is riskier than it looks.
  • Focused manifests for each pattern catch more than end-to-end tests alone.
  • What counts as "success" in a multi-target rollout, every cluster or a quorum, is a design choice, and it changes how rollback works.