Route AWS ALB Ingress traffic to a maintenance response with a high-priority ALB listener rule while preserving existing application Ingress routing, redirects, and backend rules.
app-maintenance-operator creates a temporary higher-priority ALB IngressGroup overlay. AWS Load Balancer Controller reconciles that generated Ingress into an ALB listener rule that returns an HTTP 503 maintenance page while the original application Ingress stays untouched.
Use it for immediate or scheduled maintenance windows with AWS Load Balancer Controller, ALB IngressGroups, and Kubernetes custom resources.
Use this when platform teams know the shared AWS Load Balancer Controller group name.
Use this when application teams know the existing ALB Ingress name.
Set either albGroupName or targetIngress, not both. Both modes create one generated maintenance Ingress that AWS Load Balancer Controller turns into one high-priority catch-all ALB listener rule.
Console-side listener edits and one-off fixed-response rules can drift from Kubernetes and weaken rollback accountability.
Maintenance mode should not require rewriting application-owned paths, redirects, actions, or backend service rules.
Start and end times should be declared, reconciled, and auditable instead of depending on a manual change-window toggle.
Maintenance custom resources describe the desired state; the controller handles the ALB overlay lifecycle.
The operator recreates or removes generated resources based on the current spec, schedule, and lifecycle state.
Application teams keep their Ingress definitions; platform teams get a controlled maintenance workflow.
albGroupNameUse this mode when the ALB IngressGroup name is part of the platform contract.
Maintenance resource is in the same namespace as the group member Ingresses.spec.ingressClassName: alb or kubernetes.io/ingress.class: alb.alb.ingress.kubernetes.io/group.name.alb.ingress.kubernetes.io/listen-ports.CreateRule, DeleteRule, ModifyRule, SetRulePriorities, DescribeRules, and DescribeListeners.targetIngressUse this mode when the application team knows one existing ALB Ingress name.
Maintenance resource.spec.ingressClassName: alb or the ALB ingress-class annotation.alb.ingress.kubernetes.io/group.name.Maintenance target; reconciliation handles the update.The operator owns a separate maintenance Ingress instead of patching business routing state during an outage window.
It relies on AWS Load Balancer Controller IngressGroup ordering and fixed-response actions.
Enable, disable, and scheduled windows are handled through a Kubernetes custom resource.
Maintenance resources and creates a managed overlay Ingress.
The application Ingress stays business-owned. The operator manages only the temporary overlay Ingress that AWS Load Balancer Controller publishes as the maintenance listener rule.
| Preference | Field | When to use it |
|---|---|---|
| Target a known ALB IngressGroup | spec.albGroupName |
Best for platform teams and shared ALB groups. This is the clearest AWS Load Balancer Controller workflow. |
| Target a known application Ingress | spec.targetIngress |
Best for app teams that know the Ingress name. The operator derives the ALB group from that Ingress. |
The target cluster must support the operator CRD and controller runtime behavior.
The application Ingresses must be ALB-managed, and the controller IAM role must allow listener rule create, modify, reprioritize, describe, and delete operations.
At least one application Ingress must already define alb.ingress.kubernetes.io/group.name.
Start in a non-production namespace first. IngressGroup access can affect routing for every Ingress in the same group.