Architecture

This section provides descriptions of the software components that comprise Voithos, what information it collects, and network interactions it has with your control plane and the Virtex API. Fig. 1 provides an architecture diagram as a guide.

See the Data Privacy section to learn about what information Voithos shares with the Virtex API.

Fig.1 Voithos Software Architecture

Software Components

Storage layer

We built Voithos with a custom metrics stack to bypass the limitations of Prometheus. Voithos uses Cassandra as its backend storage for both metric timeseries data as well as to cache it’s internal representation of the cluster. Timeseries data injestion and egress is handled by KairosDB, which is a TSDB frontend can use any CQL conforming backend.

Controller

The Voithos controller is a Kubernetes deployment that implements the central control loop of Voithos. It maintains an internal representation of the cluster, associates voithosautoscalinggroup custom resources with the workload resources they reference, schedules and dispatches autoscaling tasks, publishes autoscaling recommendations, patches workloads, and performs periodic api key validation and product usage reporting.

The controller interacts with both the Kubernetes control plane (Fig. 1, #2) and with the Virtex API (Fig. 1, #1). See the Network Interactions and RBAC sections for a finegrained list of the information it accesses / sends.

Collector

The collector is a daemonset that scrapes cadvisor on each cluster node and publishes container metrics to Voithos storage.

The collector interacts with the Kubernetes control plane (Fig. 1, #3). See the Network Interactions sections for a list of the information it accesses.

See the Metrics sections for a list of container metrics that the Voithos collector scrapes from cadvisor.

Autoscaler

The autoscaler implements the resource allocation algorithm. The autoscaler exposes a Kubernetes service with a load balancer that distributes task requests from the controller across its instances. The autoscaling engine shards itself as needed to match its throughput to the desired throughput of the system (based on the control loop interval and the number of workloads).

Internal API

Voithos exposes an internal API (cluster.local.voithos-system.svc.api) that exposes object patches and extra fields that are ommited from the vitex.ai/v1/voithosautoscalinggroup API. The table below lists the endopints it exposes.

Description	Method	path
view workload	GET	/namespaces/<namespace>/<kind>/<name>
view workload patch	GET	/namespaces/<namespace>/<kind>/<name>/patch
view workload hpa patch	GET	/namespaces/<namespace>/<kind>/<name>/hpas/<hpa-name>/patch
list autoscaling groups	GET	/autoscalinggroups
view autoscaling group	GET	/autoscalinggroups/<name>

Dashboard

Voithos provides a Grafana Dashboard with namespace, workload, and container levels views of your resources. See the tutorial section for usage details.

Note: Voithos uses an older version of Grafana (v2.6.0) because it has a plugin for KairosDB, which is incompatible with newer versions. While it isn’t our top priority, we plan to modernize the dashboard.

Data Privacy

While Voithos does collect container resource metrics along with the relevant resource objects required to associate that metric data with workloads, this data is never transmitted outside of your cluster. With that said, Voithos does require access to its APIs (#1 in Fig 1.) during operation for license validation and billing purposes. This external communication consists of a periodic request made by the Voithos agent to our API. The communication includes, and is strictly limited to, the following data elements:

- A UID generated by Voithos
- Kubernetes version
- Number of vCPUs
- Number of memory bytes
- Number of workloads
- Number of voithosautoscalinggroup resource objects
- Voithos software version
- Timestamp

Note: This communication is end-to-end encrypted