velero-io/velero

AWS ALB target of source EKS cluster getting drained while applying the source cluster backup to target EKS cluster using velero

Open

#9,576 opened on Mar 5, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Go (1,550 forks)auto 404
Area/Cloud/AWSHelp wanted

Repository metrics

Stars
 (10,111 stars)
PR merge metrics
 (PR metrics pending)

Description

I tried to take a backup of a specific namespace in source EKS cluster using velero backup create backup-${BUILD_ID} --kubeconfig=SOURCE_KUBECONFIG_FILE --include-namespaces $NAMESPACE.

Then when I apply it to target cluster, the alb ingress yaml gets applied with same group name, causing the source cluster target to get drained(This happens due to the reconsiliation logic according to my knowledge). I changed the logic to not include ingress during both backup and restore creation using below commands.

velero backup create backup-${BUILD_ID} --kubeconfig=SOURCE_KUBECONFIG_FILE --include-namespaces $NAMESPACE --exclude-resources ingresses velero restore create --kubeconfig=TARGET_KUBECONFIG_FILE --from-backup=backup-${BUILD_ID} --existing-resource-policy=update --include-namespaces $NAMESPACE --exclude-resources ingresses

Even after doing this , even though there is no ingress created in that namespace, the target draining happens. This does not occur when I apply the kubernetes resources manually.

Note:- The source and target EKS clusters are in separate VPCs of the same account.

Contributor guide

Research direction
Investigate why excluding ingresses from Velero backup and restore still causes AWS ALB target group draining. Check if Velero creates resources that trigger ALB reconciliation (e.g., Service or IngressClass), or if the AWS Load Balancer Controller reacts to changes in target groups. Trace the Velero restore process to see what resources are being created or updated that affect ALB targets.
Tech stack
go
Domain
backendinfrastructurecloud
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
KubernetesVeleroAWS
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30