Kubernetes Workload Groups

EFCX Kubernetes Workload Groups

Companion to efcx-kubernetes-deployment-architecture.drawio (SVG). That diagram stays at node-pool altitude; this doc carries the component-level detail and the placement rationale behind it, single site, production-ready, generic across customers (not Yomo-specific).

Profile ID naming

Each workload group below now carries a stable CX-<Name> profile ID in the leftmost column. This extends the short-code convention EFCX-Hardware-Sizing-Within-a-Site.md already started with CX-Core and CX-Data Platform, applying it consistently to the groups that doc currently leaves unprefixed (WFM, Vault) and to every other group here.

This mirrors standard practice in enterprise Kubernetes reference architectures: AKS, EKS, and GKE all group nodes into named pools (AKS’s system/user pools, GKE named node pools) rather than listing components ad hoc, and platform sizing guides such as VMware Validated Designs and SAP-style sizing docs assign each workload tier a short code precisely so later documents can cite the tier without repeating its full component list. The ID is the citation key; the “Representative components” column stays the source of truth for what’s actually in each group.

Workload groups (in-cluster)

Digital Channels: per-connector profiles

Each channel connector is a separate profile. This also matches what the doc already noted: each connector ships as its own optional Helm chart, so each can be enabled, sized, and scaled independently per deployment.

All fifteen share the same Application node pool and the same placement notes as the category row above (bursty outbound egress to provider APIs, optional DMZ deployment). Numeric sizing is pending for each, same as every other profile - see Open items.

External CX-Profile tag vs. node-pool placement

These are two different, non-conflicting classifications of the same six components (Redis, ActiveMQ/Artemis, Keycloak, APISIX, Grafana, Vault), answering two different questions:

• The External tag answers “who built it?” Expertflow’s component inventory (the Components spreadsheet’s “CX Profiles” column) tags all six with a single External value, meaning: none of them is a first-party CX microservice: they’re third-party or open-source infrastructure bundled with the platform. That’s a one-bucket, packaging/licensing classification. EFCX-Hardware-Sizing-Within-a-Site.md uses this tag as-is, because it sizes at that same packaging altitude.

• Node-pool placement answers “where does it run, and how is it kept HA?” This doc splits the same six components across four different node pools based on their runtime behavior, not their origin: Edge & Identity (Keycloak, APISIX: both edge-facing, auth and API gateway), In-cluster Stateful (Redis, ActiveMQ/Artemis: both PVC-backed, StatefulSets), Observability (Grafana: part of the monitoring stack), and Secrets (Vault: isolated for its own HA/access-control treatment).

A component can be “External” (one licensing bucket) and live in any of four different node pools (a runtime-placement bucket) at the same time. Neither table is wrong; they’re just answering different questions about the same six components.

Outside the Kubernetes cluster

DMZ placement (optional)

Customer Widget and the Digital Channels connectors can optionally be deployed in a DMZ zone outside the core network, for deployments that need public connectivity: Customer Widget is served directly to the end-user’s browser on public-facing websites, and the Digital Channels connectors take inbound traffic directly from public third-party channel providers (WhatsApp, Facebook, etc.). This DMZ topology is a supported deployment option, not an open architecture question; what’s still unresolved is the granularity, see Open items.

Placement rationale

Redis and ActiveMQ/Artemis run in-cluster as StatefulSets on CSI-backed persistent volumes. Both are cache/queue infrastructure tightly coupled to the application pods’ request path - running them in-cluster keeps that latency-sensitive path inside the same network fabric as the services calling them.

PostgreSQL, MongoDB, and S3-compatible object storage are consumed as platform-managed services, outside the Kubernetes workload groups. These are the components a managed cloud-native platform is expected to operate as clustered, HA services in its own right (backup, patching, failover) rather than EFCX re-implementing that operational surface as StatefulSets.

CX SIP Proxy and CX Media Server stay outside the Kubernetes cluster on their own VM pool, because RTP media doesn’t fit ordinary ClusterIP/Ingress networking and needs direct external IPs. They are not, however, an isolated infrastructure silo: they consume the same platform-managed PostgreSQL/MongoDB/object-storage tier and the same cloud-native storage as the in-cluster workloads (for example, voice configuration in PostgreSQL, call recordings in S3-compatible storage) - one shared data platform underneath both the containerised and the VM-based parts of the deployment.

Activities storage: MongoDB → PostgreSQL

Activities (Activity Stream/Activity Store: rooms, conversations, CIMEvents/CIMActivities) are part of the CX Core workload group, not a separate one. They are stored in MongoDB today; a future migration moves this to PostgreSQL. This doc deliberately doesn’t hard-wire MongoDB as the Activities backing store in the workload-group model - CX Core connects to “platform-managed clustered data services” generically, and which specific managed database backs Activities is expected to change without altering the workload-group placement itself.

Reporting pipeline: Airflow → Metabase

The Reporting & Data Platform group runs transflux, an Apache Airflow-based scheduler with dbt transformation models, extracting from the operational stores (MongoDB today, PostgreSQL after the Activities migration) into a reporting schema, which Metabase (this repo’s earlier “CX Analyzer” terminology) then serves dashboards from. The legacy reporting-connector (Talend-based ETL) is deprecated in newer deployments and is not part of this model. Because this group runs scheduled batch jobs rather than always-on request handling, it gets its own data-platform/batch node pool rather than sharing the Application pool’s HPA-driven scaling profile.

Open items

Carried forward as unresolved, not assumed:

• Vault’s exact scope - the component sheet marks it “optional? To confirm.” Whether it’s mandatory in every deployment and what it specifically protects needs confirmation before finalizing the Stateful pool’s sizing.

• Customer widget DMZ granularity - ships as part of CX Core by default; can optionally be deployed in a DMZ zone instead, for deployments needing public connectivity, since it serves customer-facing browser traffic directly. Whether that’s the default for public-facing deployments or purely opt-in isn’t pinned down yet. See DMZ placement.

• Digital channel connectors DMZ granularity - same optional DMZ topology as the customer widget, since these connectors take inbound traffic directly from third-party channel providers. Unresolved: whether all channels move to the DMZ together or per-channel, given each now ships as its own Helm chart. See DMZ placement.

• Numeric sizing - this doc defines workload-group placement and node-pool grouping, not CPU/RAM/replica counts. Per-component resource and replica requirements are still pending. Profile IDs above are the citation key those figures should be attached to once available.

• Site B replication - this model is single-site. Duplicating it for a second site plus cross-site clustering/DR is a later pass, not designed here.

• hardware-sizing-kubernetes.drawio (repo root) is an earlier, in-progress sketch of this same problem. This doc and its companion diagram supersede it as the current reference; the older file is left as-is rather than deleted.