Avi AKO HostRule Rejected: "FQDN is Already in Use by HostRule" Error When Using a Previously Deleted FQDN as an Alias
search cancel

Avi AKO HostRule Rejected: "FQDN is Already in Use by HostRule" Error When Using a Previously Deleted FQDN as an Alias

book

Article ID: 429331

calendar_today

Updated On:

Products

VMware Avi Load Balancer

Issue/Introduction

  • This issue occurs when an existing Ingress and HostRule are deleted and recreated with a new FQDN, while the previous FQDN is referenced as an alias in the new HostRule configuration. 
    • An Ingress and HostRule are created with the FQDN fqdn1.example.com, and the HostRule status shows Accepted.
    • Later, the Ingress for fqdn1.example.com is deleted and recreated with the new FQDN fqdn2.example.com
    • Next, the existing HostRule for fqdn1.example.com is deleted and recreated with fqdn2.example.com as the FQDN and fqdn1.example.com as the alias.
    • When the HostRule is described, the status shows Rejected with the error:  fqdn1.example.com is already in use by hostrule fqdn1.example.com
                      
    • AKO logs also show validation errors indicating that the FQDN is already in use, causing the HostRule to remain in the Rejected state even though the previous Ingress and HostRule referencing the old FQDN were deleted.
    • The AKO logs can be checked using the following command: kubectl logs ako-0 -n avi-system
2026-03-02T09:22:48.460Z        INFO    status/crd_status.go:68 key: HostRule/default/test-hostrule, msg: Successfully updated the hostrule default/test-hostrule status {"Status":"Rejected","Error":"fqdn1.example.com is already in use by hostrule fqdn1.example.com"}
2026-03-02T09:22:48.461Z        WARN    k8s/crdcontroller.go:178        key: HostRule/default/test-hostrule, msg: Error retrieved during validation of HostRule: fqdn1.example.com is already in use by hostrule fqdn1.example.com
2026-03-02T09:22:48.461Z        DEBUG   k8s/crdcontroller.go:180        key: HostRule/default/test-hostrule, msg: ADD
2026-03-02T09:22:48.466Z        INFO    nodes/dequeue_ingestion.go:38   key: HostRule/default/test-hostrule, msg: starting graph Sync
2026-03-02T09:22:48.466Z        ERROR   nodes/ingress_model_rel.go:594  key: HostRule/default/test-hostrule, msg: Hostrule is not in accepted state
2026-03-02T09:22:48.466Z        INFO    status/crd_status.go:68 key: HostRule/default/test-hostrule, msg: Successfully updated the hostrule default/test-hostrule status {"Status":"Rejected","Error":"fqdn1.example.com is already in use by hostrule fqdn1.example.com"}
2026-03-02T09:22:48.467Z        WARN    k8s/crdcontroller.go:195        key: HostRule/default/test-hostrule, Error retrieved during validation of HostRule: fqdn1.example.com is already in use by hostrule fqdn1.example.com
2026-03-02T09:22:48.467Z        DEBUG   k8s/crdcontroller.go:200        key: HostRule/default/test-hostrule, msg: UPDATE
2026-03-02T09:22:48.472Z        INFO    nodes/dequeue_ingestion.go:38   key: HostRule/default/test-hostrule, msg: starting graph Sync
2026-03-02T09:22:48.472Z        ERROR   nodes/ingress_model_rel.go:594  key: HostRule/default/test-hostrule, msg: Hostrule is not in accepted state

Environment

  • Avi Load Balancer
  • Avi Kubernetes Operator (AKO)

Cause

  • When an Ingress and HostRule that reference fqdn1.example.com are deleted, the corresponding cache entry is not immediately cleared. The stale entry persists until the AKO pod is restarted or a full reconciliation occurs.
  • When a new HostRule is then created with fqdn1.example.com as an alias, AKO checks the cache, finds the old entry still present, treats the FQDN as already in use, and rejects the new HostRule. AKO does not differentiate between a primary FQDN and an alias during this validation — both are subject to the same uniqueness check against the cache.

Resolution

Workaround:

-Restart the AKO pod to clear the stale FQDN cache, allowing the HostRule to be accepted:

kubectl delete pod ako-0 -n avi-system

Note:
Restarting the AKO pod may briefly pause AKO's reconciliation loop. This should not cause downtime for existing Virtual Services, but no new changes will be processed until the pod is back online.

-After the pod restarts, verify that the HostRule is now in the Accepted state:

kubectl describe hostrule <hostrule-name> -n <namespace>

The status should show:

Status:
  Status: Accepted

Resolution:

This issue is fixed starting from AKO version 2.1.2. Refer to the Release Notes for more details.