apache / apache/apisix-ingress-controller
feat: As a user, I want to exclude resource types from ADC reconciliation sweeps, so that API-managed resources are not deleted by the controller
- Dominant language
- Go
- Stars
- 1.1k
- Forks
- 390
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 12
Description
### Description
Description:
Currently, the controller's periodic ADC reconciliation sweep (Sync) fetches all resources from APISIX and deletes anything that has no corresponding CRD in the cluster. This means resources created directly via the APISIX Admin API (e.g. consumers managed by an external auth service) are silently deleted on every sync cycle.
There is no way to tell the controller "don't garbage-collect this resource type" — the sweep is all-or-nothing.
As a user, I want to configure a list of resource types to exclude from the reconciliation sweep, so that API managed resources of those types (e.g. Consumer, ConsumerGroup) can coexist with CRD-managed resources without being deleted.
Proposed solution:
Add an exclude_resource_type field to the provider section of config.yaml:
```
provider:
type: "apisix"
sync_period: 1h
exclude_resource_type:
- Consumer
```
This maps to the --exclude-resource-type flag already supported by ADC, which tells it to skip GC for specific resource types during a sync. The controller would pass this flag when
executing the periodic full sync, while per-event reconciliation (update/delete of individual CRDs) remains unaffected.
Backward compatibility: fully backward compatible — defaults to [] (empty), preserving current behavior.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the provider section in config.yaml and the periodic full-sync path that executes ADC, then inspect how the existing --exclude-resource-type flag is passed. Add the configuration with an empty default and verify that exclusions apply to full syncs while per-event CRD reconciliation remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- api, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100