Anatomy of Abuse Shield Services

The services that are deployed as part of the installation are integral to the operation of the service; this section will explain how each of those services is used.

wforce Service

The wforce service is used to allow access to the wforce pods REST API using HTTP(S). Normally access would be via an Ingress, and the Chart provides a way to configure an Ingress - see Configuration. See the following diagram for an example:

The wforce service type defaults to ClusterIP, but if Ingress is not being used, then it can be changed to NodePort or LoadBalancer for direct access to the wforce pods.

The wforce service also allows access to the /metrics endpoint to access Prometheus metrics; by default this endpoint is password protected, but this specific endpoint can be opened to anyone by setting wforce.config.metricsNoPassword: true.

wforce-replication Service

The wforce-replication service is integral to enabling replication between the wforce pods. The service is headless, meaning it has no IP address configured, and the service is only used as a selector for endpoints. All the endpoints associated with this service are the pods that participate in cluster replication - this includes: wforce pods, syncdb pods and replfwd pods. A special container that runs in every pod, wforce-agent, continually monitors the endpoints associated with the wforce-replication service, and if any endpoints change, the new set of endpoints are dynamically updated so that replication can continue uninterrupted with the new set of endpoints.

This process is shown in the following figure:

wforce-syncdb Service

Like wforce-replication, the wforce-syncdb service is headless, which means that lookups to the service will return the set of endpoints behind the service rather than the IP address of the service itself. The wforce pods use this property to discover syncdb pods on startup, so that they can download a copy of the statsdb before becoming operational.

Of course the wforce binary itself has no knowledge of kubernetes or the wforce-syncdb service; however the wforce configuration file is based on Lua, and so this is used to perform the relevant DNS lookups to create the configuration for selecting the syncdb servers.

wforce-syncdb-external Service

The wforce-syncdb-external service is provided so that the REST API of the syncdb pods can be accessed directly, for example for debugging. However this should not be used for production queries, as that defeats the point of the syncdb pods being separate from the wforce pods.

wforce-replfwd Service

The wforce-replfwd service is provided to allow access to the replication port(s) of the replfwd pod from services external to the cluster, i.e. replfwd services located in other clusters. It is anticipated that this service will typically be modified to be of type LoadBalancer, with an external IP address, or perhaps NodePort.