Learn Multigress - CI/CD for Multigress Configuration

#Introduction

Manual routing changes are a major source of production incidents. Episode 19 covers CI/CD for Multigress configuration: validating Gateway API manifests in the pipeline, deploying and rolling back automatically, and managing releases for routing changes.

We extend the context from episode 11: not just storing manifests in Git, but executing them through a tested pipeline.

#Validating Gateway API Manifests in CI

#Schema Validation with kubeconform

The pipeline must reject bad configuration from the start. kubeconform validates manifests against the Kubernetes schema and the available CRDs.

kubeconform -strict -summary \
  -kubernetes-version 1.30 \
  gateway.yaml httproutes.yaml

The kubeconform -strict -summary command flags manifests that don't match the schema. Run it on every commit so YAML errors and field typos are caught before reaching the cluster.

#Dry-Run Against the Cluster

A valid schema doesn't mean the object is accepted by the cluster. Use a server dry-run to check whether the resources can be created on the real cluster.

kubectl apply --dry-run=server -f config/ -o name
kubectl apply --dry-run=client -f config/ -o name

kubectl apply --dry-run=server tests against the API server without writing any changes. This catches issues like namespaces that don't exist or fields rejected by an admission webhook.

#Automated Deployment and Rollback

#Pipeline in CI

Once validation passes, changes can be deployed automatically. The simple pipeline below runs validation, then applies the manifests.

name: validate-and-deploy
on:
  push:
    branches:
      - main
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validasi skema
        run: kubeconform -strict -summary ./gateway/
  deploy:
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - uses: actions/checkout@v4
      - uses: azure/k8s-set-context@v4
        with:
          kubeconfig: ${{ secrets.KUBECONFIG }}
      - run: kubectl apply -f gateway/

The deploy job only runs if the validate job succeeds, so broken manifests will never reach production.

#Automated and Manual Rollback

Rollback must be fast and measured. For Helm-based deployments, the chart version history provides a clear path backward.

helm list -n multigress-system
helm rollback multigress 2 -n multigress-system

The helm rollback multigress 2 command returns the release to its second revision. The key to a good rollback is old configuration that can always be rebuilt — not relying on human memory.

Rollback can also be triggered automatically: if the error rate spikes a few minutes after a deploy, the pipeline reverts to the previous revision without waiting for a human.

#Release Management for Routing Changes

#Versioning and Changelog

Gateway configuration is a release artifact. Give every routing change a version number and record it in a changelog, so every gateway behavior can be tied to a specific version.

Semantic versioning applies here too: a routing behavior change that could break users is a breaking change deserving a major version, while adding a route without changing existing behavior is just a minor version. In other words, gateway configuration releases are maintained as strictly as application code releases.

#Approval for Sensitive Changes

Not all changes carry the same risk. Add a manual review gate for high-impact changes like traffic shifting or TLS changes, while letting small changes flow automatically. Start with changes that shift large amounts of traffic or touch certificates, then expand the list as your team gains experience.

#Closing

Episode 19 turned gateway configuration into an artifact managed like code: validated in CI, deployed automatically, rollback-capable, and released with versions and reviews.

The key takeaways:

• kubeconform rejects schema-invalid manifests from the commit stage.
• A server dry-run verifies against the real cluster without writing.
• Automated deployment only runs after validation passes.
• Helm rollback provides a fast path backward.
• Every routing change gets a version and a changelog entry.
• Sensitive changes pass through a manual review gate.

In the next episode 20 we'll discuss observability at scale — monitoring route performance and latency, tracing through ingress and backends, and building dashboards for traffic SLIs. The pipeline you built will be monitored with deeper metrics.