Fusion Microservices
Fusion is comprised of microservices that drive features and functionality within a deployment. The services running in your deployment depend on the version of Fusion and the features you have enabled.
Get deployment details
You can view your deployment details using kubectl.
-
First, verify that you have access to your cluster, replacing the example values with your parameters. This example is for a Fusion instance deployed using GKE.
gcloud container clusters get-credentials EXAMPLE-CLUSTER --region EXAMPLE-REGION --project EXAMPLE-PROJECT -
Get the ports and services:
kubectl get svc -n EXAMPLE-NAME -
Get the StatefulSets:
kubectl get statefulsets -n EXAMPLE-NAME -
Get the deployments:
kubectl get deploy -n EXAMPLE-NAME
Overview
The table below lists the Fusion microservices deployed by the Helm chart. It also include Kubernetes services that manage traffic to microservices.
| Fusion is a complex distributed application composed of many stateful and stateless services designed to support demanding search-oriented workloads at high scale. |
For Docker image versions associated with microservices, see the list of Docker images and versions for each Fusion release.
Microservices
Below is a list of microservices used in Fusion 5.12.
| Microservice | Required for Fusion | Protocol | Deployment or StatefulSet | Node Pool Assignment | Autoscaling Supported | Description |
|---|---|---|---|---|---|---|
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves static Web assets for the admin UI. |
|
Yes |
REST/HTTP |
Deployment |
analytics or system |
Not required. One pod is enough for most clusters. |
Tracks Fusion entitlement license and consumption. |
|
No |
HTTP |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Separates document crawling and parsing. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves static Web assets for the login form. |
|
No |
HTTP/TCP |
Deployment |
analytics or system |
Yes (CPU or custom metric). |
Deployment for each connector plugin type. Note: There is a base deployment, connector-plugin with 0 replicas. This is used as a deployment template for each connector plugin type. It should not be deleted or scaled. |
|
No |
REST/HTTP |
Deployment |
analytics or system |
Not required. One pod is enough for most clusters. |
Routes REST API requests to connectors-classic and connectors-rpc. |
|
No |
gRPC |
Deployment |
analytics or system |
Yes (CPU or custom metric). |
gRPC service for managing SDK-based connector plugins. |
|
No |
REST/HTTP |
StatefulSet |
analytics or system |
Not supported. |
REST service for supporting non-RPC connector plugins. This microservice was previously named classic-rest-service. |
|
Yes |
REST/HTTP |
Deployment |
system |
Not required. Minimum of 1, but 2 pods are recommended for high availability (HA). |
Exposes endpoints for admin tasks, such as creating applications and running jobs. This microservice was previously named admin. |
|
Yes |
REST/HTTP |
Deployment |
search or analytics depending on write-volume |
Yes (CPU or custom metric). |
Processes indexing requests. This microservice was previously named indexing. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Stores logs and prior Argo workflow runs. |
|
No |
HTTP |
StatefulSet |
system |
Required. One pod is enough for most clusters. |
Contains incoming data for Solr. |
|
No |
HTTP |
StatefulSet |
system |
Required. One pod is enough for most clusters. |
Contains incoming data for Solr. |
|
No |
Web |
Deployment |
system |
Not required. Minimum of 1, but 2 pods are recommended for high availability. |
Load balancing and proxy for Seldon Core deployments. |
|
No |
Web |
Deployment |
system |
Not required. Minimum of 1, but 2 pods are recommended for high availability. |
Handles metadata for Milvus service. |
|
Yes |
HTTP |
StatefulSet |
At least 3 nodes in search, 2 in analytics, and 2 in system |
Yes (CPU or custom metric). |
Search engine. |
|
Yes |
HTTP |
StatefulSet |
At least 3 nodes in search, 2 in analytics, and 2 in system |
Yes (CPU or custom metric). |
Search engine. |
|
Yes |
HTTP |
StatefulSet |
At least 3 nodes in search, 2 in analytics, and 2 in system |
Yes (CPU or custom metric). |
Search engine. |
|
Yes |
HTTP |
StatefulSet |
At least 3 nodes in search, 2 in analytics, and 2 in system |
Yes (CPU or custom metric). |
Search engine. |
|
Yes |
TCP |
StatefulSet |
system |
No. You need to run 1, 3, or 5 ZooKeeper pods to keep quorum. Do not use HPA for scaling ZooKeeper. |
Stores centralized configuration and performs distributed coordination tasks. |
|
Yes |
TCP |
StatefulSet |
system |
No. You need to run 1, 3, or 5 ZooKeeper pods to keep quorum. Do not use HPA for scaling ZooKeeper. |
Stores centralized configuration and performs distributed coordination tasks. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves the App Insights UI |
|
Yes |
HTTP |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Controls job execution and stores job history. |
|
No |
REST/HTTP |
Deployment |
analytics |
Not required. One pod is enough for most clusters. |
Configures and launches the Spark driver pod for running Spark jobs |
|
No |
REST/HTTP |
Deployment |
analytics |
Not required. One pod is enough for most clusters. |
Performs admin tasks for creating and running Spark jobs. |
|
No |
REST/HTTP |
Deployment |
analytics or system |
Not required. One pod is enough for most clusters. |
Dense Vector Search Engine for ML models active. |
|
No |
REST/HTTP |
Deployment |
analytics or system |
Not required. One pod is enough for most clusters. |
Handles metadata for Milvus service active. |
|
No |
REST/HTTP and gRPC |
Deployment |
search |
Yes (CPU or custom metric). |
Exposes gRPC endpoints for generating predictions from ML models. |
|
No |
REST/HTTP and gRPC |
Deployment |
search |
Yes (CPU or custom metric). |
Exposes gRPC endpoints for generating predictions from ML models. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves static Web assets for the Predictive Merchandiser app. |
|
Yes |
HTTP |
Deployment |
search |
Not required. Minimum of 1, but 2 pods are recommended for high availability. |
Performs authentication, authorization, and traffic routing. |
|
Yes |
REST/HTTP |
Deployment |
search |
Yes (CPU or custom metric). |
Processes query requests. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves static Web assets for the Rules UI. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Maintains Seldon Core deployments for ML model serving active. |
|
No |
Web |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Retrieves and renders Predictive Merchandiser templates. |
|
No |
REST/HTTP |
Deployment |
system |
Not required. One pod is enough for most clusters. |
Serves App Studio-based Web apps. |
Ports used by Fusion
Below you will find the list of pod ports for intra-cluster communications.
| Service | Port |
|---|---|
|
8765 |
|
8080 |
|
9025 |
|
9005 |
|
2746 |
|
8080 |
|
9020, 5701 |
|
9010 |
|
8771 |
|
9000 |
|
2746 |
|
9092, 9093 |
|
9092, 9093 |
|
80, 443 |
|
3306 |
|
8983 |
|
8983 |
|
8983 |
|
8983 |
|
2181, 2281 |
|
2181, 3888, 2888, 2281 |
|
8765 |
|
8080 |
|
9016 |
|
8083 |
|
8081 |
|
19530, 19121 |
|
6565 |
|
8086 |
|
8080 |
|
6764 |
|
8787 |
|
8080 |
|
443 |
|
5250 |
|
8780 |
Transport Layer Security (TLS)
In Fusion releases 5.11.0 and later, 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.