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
- Access the gateway service:
- For a virtual gateway, run the following command to access the DataPower
kubectl attach -it <pod_name>
- For a physical gateway, use
sshto connect to the gateway service.
- For a virtual gateway, run the following command to access the DataPower CLI:
- Switch to the API Connect
- Show the current 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
config; gateway-peering-switch-primary <gateway-peering-name-for-apic-gw-service>;
- Flush the apic-gw-service gateway-peering
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
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:
- Open the API Manager.
- Open the Catalog.
- Click .
- Update the Summary field with some text so that it is modified.
- Click Save.
When the event is received, the DRR is initiated.