OX Abuse Shield Cloud Control is designed to make deploying Abuse Shield into a Kubernetes Cluster extremely easy. The chart automates all of the tasks of setting up and managing a wforce cluster, enabling administrators to concentrate on what they want the cluster to do, and not on the minutiae of how to manage a cluster of servers.

For an overview of wforce, it's purpose and architecture, see the wforce GitHub repo, and more specifically the documentation page.

A simple (non-kubernetes) deployment would consist of a set of wforce servers collaborating in a cluster; to achieve this the admin needs to configure each wforce server with the IP addresses of the other servers (siblings). Then if servers are added or removed, the configuration needs to be manually updated by the administrator.

With Cloud Control, all of these tasks are completely automated, since every wforce Pod contains an agent that monitors the deployment, and automatically adds/removes siblings when necessary, including when Pods crash, are restarted, or when the deployment is scaled up or down.

Cloud Control also replaces most of the Lua-based configuration with YAML configuration, making configuration much more straightforward and less error-prone. Lua is still required for wforce policy, either by writing your own from scratch as described in the Wforce GitHub README or using the Lua policy framework described in the Wforce Policy Documentation. The wforce image used in the charts includes the wforce-policy Lua scripts, which greatly simplifies the process of creating and managing wforce policies.

Cloud Control also manages the deployment and configuration of special wforce instances for DB synchronization. When enabled, these instances are used to pre-populate new wforce instances with DB data automatically, but they are never used to answer queries.

Finally Cloud Control also supports the deployment of the replication forwarder; a special instance that is used to send and receive replication messages between wforce clusters.