Deployment Architecture
This document describes the deployment architecture of Expertflow CX managed through any Kubernetes distribution.
A Kubernetes platform is one of the solution prerequisites for deploying Expertflow CX. Expertflow is not responsible for managing or supporting the underlying Kubernetes distribution.
Technical Overview
The following diagram describes the Expertflow solution deployment. The architecture diagram shows internal components of Expertflow CX. In any Kubernetes distribution, the individual solution components are deployed as pods which may contain one more containers within different namespaces. The following namespaces exists in our solution:
All Expertflow CX services are deployed in one of the following Kubernetes namespaces.
| Namespace | Description |
|---|---|
| expertflow | For all of the Expertflow developed and managed set of services |
| ef-external | For all the 3rd-party application services such as databases and file storage etc |
| cti | For CTI and other connectors to 3rd party applications |
PODs in expertflow
| Name | Description |
|---|---|
| 360-connector | WhatsApp channel connector for Dialog360. It should better be in the connectors namespace. |
| file-engine | |
| ccm | |
| bot-framework | |
| routing-engine | |
| cim-customer | |
| agent-manager | |
| unified-admin | |
| license-manager | |
| business-calendar | |
| web-channel-manager | |
| customer-widget | |
| twillio-connector | |
| unified-agent | |
conversation-controller | |
conversation-manager | |
facebook-connector | |
realtime-reports | |
reporting-connector | |
state-event-logger | |
web-widget |
PODs in external
| POD | Description |
|---|---|
| minio | |
| mongo | |
| activemq | |
| redis | |
| keycloak | |
| grafana | |
| postgresql | |
| superset |
PODs in cti
| POD | Description |
|---|---|
Expertflow CX Deployment on Kubernetes
Expertflow CX may be deployed in one of the following three configurations. To see details of the configurations and their respective guide, click here.
| Config | |
|---|---|
| Single node | The complete solution is deployed on a single node with no redundancy. This mode is good for dev and staging environments. |
| Multi node | |
| High availability |
Single node (without HA)
A Kubernetes Single-Node (without HA) configuration refers to setting up a Kubernetes cluster with only one master node, without high availability (HA) features. In this configuration, there is a single control plane node that manages the cluster's operations, including scheduling, scaling, and orchestrating containerized applications. However, since there is no HA, if the master node fails, the entire cluster may become inaccessible.
Are there 2 Pods in it?
