Dynamically re-registering and reconfiguring a Gateway service in a Kubernetes deployment

In API Connect, Gateway services do not persist their configuration settings by default. Instead, the master configuration is stored on the Management server and the Dynamic Reregistration and Reconfiguration (DRR) mechanism resynchronizes configuration data when needed. The DRR process is used when proper High Availability/Disaster Recovery (HA/DR) is not configured, or if a manual resynchronization is required.

If a Gateway service is not configured properly for resiliency and is restarted, the gateways in the Gateway service will lose the configuration from the Management server. Configuration data from the Management server is maintained on the gateway service according to the gateway peering configuration on the gateways.

Preventing the loss of configuration data

For high availability in production environments, use a minimum of three gateways in the Gateway service.

Forcing re-population of the configuration data

To repopulate the configuration data, complete the steps in the following section to trigger an outage-less DRR.

Triggering an outage-less DRR

To force a Dynamic Reregistration and Reconfiguration across a peer group from within the gateway service without requiring a restart, complete the following steps using the CLI. This process flushes the primary peering object configured for the apic-gw-service. This task can only be performed with CLI, and requires the default admin ID for running the diag command.

Access the gateway service:
- For a virtual gateway, run the following command to access the DataPower CLI:
```
kubectl attach -it <pod_name>
```
- For a physical gateway, use ssh to connect to the gateway service.
Switch to the API Connect application:
```
switch <APIC_APP_DOMAIN>
```
Show the current gateway-peering-status:
```
show gateway-peering-status
```
If the server that you connected to is not primary for the apic-gw-service gateway-peering object, force this server to become primary:
```
config; gateway-peering-switch-primary <gateway-peering-name-for-apic-gw-service>;
```
Flush the apic-gw-service gateway-peering object:
```
diag; gateway-peering-flush <gateway-peering-name-for-apic-gw-service>; exit
```
When prompted, confirm the operation.

Disable and then re-enable the apic-gw-service object for every member of the gateway service:

config; apic-gw-service; admin-state disabled; exit
apic-gw-service; admin-state enabled; exit; exit

Confirm that the apic-gw-service was flushed and is now waiting for gateway service registration:
Look in the debug log target for the apic-gw-service, located in logtemp:/// and check for a message similar to the following example:

20200618T232339.332Z [0x88e000d7][apic-gw-service][notice] apic-gw-service(default): tid(2653): Waiting for gateway service registration.

The DRR will be triggered by the next arrival of a webhook event. The Management server sends a heartbeat to the gateway at five-minute intervals, prompting the gateway to check whether it has lost its configuration and if so, trigger a DRR. In addition, if the Management server has previously marked a Catalog or cloud as being unavailable for a particular gateway service, a successful heartbeat triggers synchronization for that Catalog or cloud on that gateway service.
If you attached to a virtual gateway, you can detach by pressing Ctrl+P and then pressing Ctrl+Q.
(Optional) Force a BAU webhook event to be sent from API Manager to trigger the DRR:
If you do not want to wait for the Management server to send a heartbeat, you can trigger the DRR manually by completing the following steps:
1. Open the API Manager.
2. Open the Catalog.
3. Click Settings > Edit.
4. Update the Summary field with some text so that it is modified.
5. Click Save.

When the event is received, the DRR is initiated.

Confirm that DRR is complete by testing your APIs. You can also use the health check API.