Learn Multigress - High Availability & Disaster Recovery

#Introduction

A dead gateway means every application behind it becomes unreachable. Episode 18 covers high availability and disaster recovery for Multigress: designing redundancy and failover, backing up and restoring configuration, and running recovery drills regularly.

The end goal: no single point of failure can take down the gateway, and if an interruption does happen, the team knows exactly what to do to recover.

#Gateway Redundancy and Failover

#Replicas and PDB

Redundancy starts with the replica count. Next, a PodDisruptionBudget makes sure node maintenance operations never take down all pods at once.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: multigress-gateway
  namespace: multigress-system
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: multigress-gateway

A PDB with minAvailable: 2 guarantees at least two gateway pods keep running during node drain. Without a PDB, eviction could disable all replicas at once.

#Pod Spread Across Nodes

Replicas without spread control can pile up on a single node. Use topology spread constraints so pods are distributed, and a node failure won't kill all replicas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multigress-gateway
  namespace: multigress-system
spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: multigress-gateway

The constraint above spreads pods across different zones. Failover then runs automatically: requests are shifted to the remaining pods without human intervention.

#Configuration Backup and Restore

#Backing Up Gateway Resources

All Multigress configuration is Kubernetes resources. Backup can be done by exporting all related objects into a single YAML file.

kubectl get gateway,httproutes,securitypolicy,backendtrafficpolicy \
  -A -o yaml > multigress-backup-2026-08.yaml

The kubectl get gateway,httproutes,securitypolicy,backendtrafficpolicy -A -o yaml command exports all gateway configuration into one file. Store it outside the cluster, for example in object storage or a private Git repo.

#Restore and Verify

When a new cluster is created, restore is simply applying the backup file and then verifying the conditions.

kubectl apply -f multigress-backup-2026-08.yaml
kubectl get gateway -A
kubectl get httproute -A

After the restore, check the Gateway status is in the accepted condition. Don't forget to back up the TLS secrets too — without them, an HTTPS restore won't work.

#Recovery Drills for Interruptions

#Simulating Failures

The truth of a procedure is only proven when it's executed. Run simple simulations regularly: kill a gateway pod and watch the recovery.

kubectl delete pod -n multigress-system -l app=multigress-gateway
kubectl get pods -n multigress-system -w

kubectl delete pod -n multigress-system -l app=multigress-gateway forces one pod to restart, while kubectl get pods -w shows the deployment pulling it back. If this process runs smoothly, your gateway deployment is healthy.

#Full Drills and Documentation

Beyond small simulations, schedule a comprehensive drill once a year: shut down one region, restore from backup in a new region, and measure the recovery time. Record the results and fix any procedures that failed.

#Closing

Episode 18 made your gateway resilient: a PDB and zone spread preserve availability, an export backup enables full recovery, and drills turn procedures into team skills.

The key takeaways:

• A PDB keeps at least two replicas running during drain.
• Topology spread distributes pods across zones.
• All gateway configuration can be backed up as Kubernetes resources.
• Backups must be stored outside the cluster.
• TLS secrets need backing up so an HTTPS restore works.
• Recovery drills prove recovery procedures actually work.

In the next episode 19 we'll discuss CI/CD for gateway configuration — validating Gateway API manifests in the pipeline, automated deployment and rollback, and release management for routing changes. The recovery procedures you practiced will run automatically through the pipeline.