Fusion Microservices
Overview
The table below lists the Fusion microservices deployed by our Helm chart. Recognize that Fusion is a complex distributed application composed of many stateful and stateless services designed to support demanding search-oriented workloads at high scale.
| Microservice | Protocol | Deployment or StatefulSet | Node Pool Assignment | Autoscaling Supported | Description |
|---|---|---|---|---|---|
|
REST/HTTP |
Deployment |
|
Not required. Minimum of 1 but 2 pods are recommended for HA |
Exposes endpoints for admin tasks, such as creating applications and running jobs. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves static Web assets for the admin UI. |
|
HTTP |
Deployment |
|
Yes (CPU or custom metric) |
Orchestrates parallel jobs on Kubernetes. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Stores logs and prior Argo workflow runs. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves static Web assets for the login form. |
|
HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Synchronizes config between GitHub and Fusion. |
|
REST/HTTP |
StatefulSet |
|
Yes (CPU or custom metric) |
REST service for supporting non-RPC connector plugins. |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Routes REST API requests to connectors-classic and connectors-rpc. |
|
gRPC |
Deployment |
|
Yes (CPU or custom metric) |
gRPC service for managing SDK-based connector plugins. |
|
HTTP/TCP |
Deployment |
|
Yes (CPU or custom metric) |
Deployment for each connector plugin type. Note: There is a base deployment, |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves static Web assets for the DevOps UI. |
|
REST/HTTP |
Deployment |
|
Yes (CPU or custom metric) |
Processes indexing requests. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves the App Insights UI |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Configures and aunches the Spark driver pod for running Spark jobs |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Performs admin tasks for creating and running Spark jobs. |
|
HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Jupyter notebook for ad hoc analytics and visualization. |
|
HTTP |
StatefulSet |
|
Not required. Minimum of 1 but 2 pods are recommended for HA |
Collects logs from the other microservices and either indexes into system_logs or ships them to an external service like Elastic |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Dense Vector Search Engine for ML models active. |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Handles metadata for Milvus service active. |
|
REST/HTTP and gRPC |
Deployment |
|
Yes (CPU or custom metric) |
Exposes gRPC endpoints for generating predictions from ML models. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves static Web assets for the Predictive Merchandiser app. |
|
HTTP |
Deployment |
|
Not required. Minimum of 1 but 2 pods are recommended for HA |
Performs authentication, authorization, and traffic routing. |
|
HTTP |
StatefulSet |
|
Atleast 3 nodes in HA, you need to run 3 or 5 to ensure a quorum |
Write Ahead Log (WAL) used for persistent message storage. |
|
HTTP and TCP |
Deployment |
|
Atleast 3 nodes in HA |
Contains REST API for managing administration and dispatcher for handling all message transfers. |
|
REST/HTTP |
Deployment |
|
Yes (CPU or custom metric) |
Processes query requests. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves static Web assets for the Rules UI. |
|
Web |
Deployment |
|
Not required. Minimum of 1 but 2 pods are recommended for HA |
Load balancing and proxy for Seldon Core deployments. |
|
REST/GRPC |
Deployment |
|
Yes (CPU or custom metric) |
Serves models built in any model building framework. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Maintains Seldon Core deployments for ML model serving active. |
|
HTTP |
StatefulSet |
At least 3 nodes in |
Yes (CPU or custom metric) |
Search engine. |
|
n/a |
single pod per job |
|
1 per job |
Launched by the job-launcher to run a Spark job |
|
n/a |
one or more pods launched by the Spark driver for executing job tasks |
|
depends on job configuration; controlled by the spark.executor.instances setting |
Executes tasks for a Spark job |
|
REST/HTTP and JDBC |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Performs admin tasks for creating and managing SQL catalog assets. Exposes a JDBC endpoint for the SQL service. |
|
Web |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Retrieves and renders Predictive Merchandiser templates. |
|
REST/HTTP |
Deployment |
|
Not required; only 1 pod should be sufficient for most clusters |
Serves App Studio-based Web apps. |
|
TCP |
StatefulSet |
|
No, you need to run 1,3, or 5 Zookeeper pods to ensure a quorum; HPA should not be used for scaling ZK |
Stores centralized configuration and performs distributed coordination tasks. |
Transport Layer Security (TLS)
Fusion microservices can be configured to use Transport Layer Security (TLS).
When enabled, Fusion generates a TLS certificate for each pod when the pod starts. This allows Fusion to use the Kubernetes endpoints API to reach each pod by its IP address and perform load balancing, circuit breaking, and retries in the Fusion microservices.