Skip to content

AV-253651 documentation for HA transition #2016

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
arihantg wants to merge 1 commit into
base: release-2.1.1
Choose a base branch
from
Open

AV-253651 documentation for HA transition #2016

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 17 additions & 2 deletions docs/ako_ha.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@ Fig: AKO High Availability Architecture

Active and passive modes are assigned automatically by performing a leadership election among the AKOs. A lease lock(Kubernetes object) named `ako-lease-lock` in `avi-system` has been used to keep track of the current active AKO. The lease lock object has the identity of the current active AKO and a field named `renewTime` which active AKO periodically refreshes. The passive AKO periodically polls the lease lock object and updates its identity in the lease lock object when the `renewTime` goes beyond the deadline.

**Note:** Lease lock object won't be created when AKO is running with single replica.

Leader election between AKOs occurs as described below:
![Alt text](images/ako_ha_election.png?raw=true)
<div align="center">
Expand All @@ -34,10 +36,23 @@ Passive AKO does the following:

## Steps to run AKO in High Availability

* Change the `replicaCount` in `values.yaml` to two.
* Execute the helm upgrade command and provide the updated `values.yaml` file.
### Transitioning from Single Replica to High Availability

To transition from a single AKO replica to high availability mode, you must follow this specific sequence to ensure proper leader election:

1. **Scale down to zero replicas**: Change the `replicaCount` in `values.yaml` to 0 and execute the helm upgrade command.
2. **Scale up to two replicas**: Change the `replicaCount` in `values.yaml` to 2 and execute the helm upgrade command.

```bash
# upgrade command
Copy link
Contributor

@akshayhavile akshayhavile Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ashishnayak96 This helm upgrade will also change.

helm upgrade ako-1593523840 oci://projects.packages.broadcom.com/ako/helm-charts/ako -f /path/to/values.yaml --version 2.1.1 --set ControllerSettings.controllerHost=<IP or Hostname> --set avicredentials.password=<username> --set avicredentials.username=<username> --namespace=avi-system
```

**Important:** This two-step process is required because:
- When scaling directly from 1 to 2 replicas, the first replica skips leader election (thinking it's still single replica)
- The second replica starts leader election, but the first replica doesn't participate
- This can lead to both replicas becoming active simultaneously
- By scaling to 0 first, both replicas start fresh and properly participate in leader election

**Note:**
1. Currently, more than two replicas are not supported.
Expand Down
Loading