Home
MATRIXX Installation and Upgrade
Network Enablers in a Kubernetes Cluster
For Call Control Framework (CCF), only the deployment of Network Enablers (NEs) in a Kubernetes cluster is different from a standard deployment.
Network Enabler Kubernetes Services
A number of Kubernetes services are created by Helm when it creates the engine services to allow connection to and from Network Enablers (NEs).
Engine Processing Pod M3UA Kubernetes Service
The proc-m3ua-s<sid>-e<eid> service defines a Kubernetes service on TCP ports 2901, 2902 and others as needed for connections from Network Enablers (NEs) to Camel Gateways on MATRIXX Engine processing pods.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
- About MATRIXX Installation and Upgrade
  MATRIXX Installation and Upgrade describes the tasks required to install MATRIXX components as containers using Kubernetes and Helm.
- Cloud Native Infrastructure Requirements
  Cloud native MATRIXX deployments have infrastructure requirements for third-party software versions, Kubernetes pod characteristics, and container characteristics. Nodes running MATRIXX components have operating system, memory, networking, and storage requirements.
- Topology Operator and Engine Operator Feature Differences
  Different MATRIXX features are supported depending on whether your installation is based on Topology Operator or Engine Operator.
- Installing MATRIXX
  A cloud native MATRIXX installation consists of containers installed with the MATRIXX Helm chart in a multi-node Kubernetes cluster (or clusters), requiring MATRIXX images and MATRIXX Engine custom resource definitions and controllers.
- Topology Operator Installation and Upgrade Examples
  These examples show how you can configure the installation of multiple MATRIXX Engines in a single namespace, multiple namespaces in a single cluster, and multiple clusters.
- Configuring MATRIXX
  MATRIXX is configured using Helm properties. Questions and answers in create_config.info files can also provide configuration using configuration sources. For information about how to configure MATRIXX, see the discussions of those topics in MATRIXX Configuration.
- Topology Operator
  The Topology Operator method of MATRIXX Engine pod management utilizes multiple custom resources (CRs) and operator pods working together to manage the installation and upgrade of multiple sub-domains and engines across Kubernetes clusters, including the loading of pricing and taxation data.
- Scaling MATRIXX
  Use Helm and Kubernetes to manually add or remove pods as necessary. You can also use Kubernetes to manage resources available to MATRIXX Engine pods.
- Network Enablers in a Kubernetes Cluster
  For Call Control Framework (CCF), only the deployment of Network Enablers (NEs) in a Kubernetes cluster is different from a standard deployment.
  - Network Enabler Deployment Architecture
    Network Enablers (NEs) run inside their own Kubernetes pods, one pod per NE. A number of Kubernetes services are defined to allow connection to and from the NEs.
  - Access Groups and Network Enablers
    Network Enablers (NEs) are deployed in access groups, with all NEs in all access groups being fully meshed with all engines.
  - Network Enabler Kubernetes Services
    A number of Kubernetes services are created by Helm when it creates the engine services to allow connection to and from Network Enablers (NEs).
    - NE Ingress Kubernetes Service
      The ne-ingress-<access_group> service defines a Kubernetes ClusterIP service on SCTP port 2905 for Ingress connections to the listening Network Enablers (NEs), where access_group identifies the access group.
    - NE Crosslink Kubernetes Service
      The ne-<access_group>-<id> service defines a Kubernetes ClusterIP Service on TCP port 29051 for connection between NE pairs, where access_group identifies the access group and <id> identifies the NE.
    - NE Headless Kubernetes Service
      The ne-<access_group> service is a headless Kubernetes service that ensures Network Enablers (NEs) publish their own pod addresses to the DNS.
    - Engine Processing Pod M3UA Kubernetes Service
      The proc-m3ua-s<sid>-e<eid> service defines a Kubernetes service on TCP ports 2901, 2902 and others as needed for connections from Network Enablers (NEs) to Camel Gateways on MATRIXX Engine processing pods.
  - Installing the Multus Plug-in
    The Multus Container Network Interface (CNI) plug-in is a third-party tool for attaching multiple network interfaces (with static or dynamic IP addresses) to a pod. In a Network Enabler (NE) deployment, you use it to attach static IP addresses to the NE pod.
  - Configure Network Enablers
    Make configuration changes to enable Call Control Framework (CCF) in the Kubernetes cluster.
  - Deploying the Network Enabler
    Network Enablers (NEs) in Kubernetes clusters are deployed using the MATRIXX Helm chart. For information, see configuring MATRIXX using Helm.
  - Monitoring Network Enabler with Prometheus
    Network Enabler (NE) SNMP statistics can be monitored with Prometheus.
  - Network Enabler Logging in Kubernetes
    Network Enablers (NEs) log what are normally the contents of the mtx_debug.log file to the Kubernetes logging function.
- Deploying Cloud Native CAMEL Gateway
  When deploying CAMEL Gateway as part of the reference architecture, you can use any namespace within the Kubernetes clusters. You can make multiple deployments into multiple namespaces, for example, to have different environments for testing and production.
- Enabling MEF Publishing
  An SSH key, used for password-less SSH login, is required to enable _glossary/mef.html publishing in Kubernetes. A secret holds the SSH private key, and the key is specified in Helm values. The SSH key allows administrators to write to a target directory in a secure manner without having to enter a passphrase.
- Encrypted Interface Engine Replay Overview
  Transport-layer security (TLS) encryption can be enabled for replay between processing and publishing pods and between engines.
- MATRIXX Reference for MongoDB
  Cloud native MATRIXX deployments support MongoDB as an event store using the MongoDB Enterprise Operator for Kubernetes.
- MATRIXX Reference for Apache Kafka
  The Event Streaming Framework provides a connector for sending event stream data to Apache Kafka. Using 5G event streaming also requires Apache Kafka, which is not provided with MATRIXX. You can use a Helm chart to install and configure Apache Kafka.
- MATRIXX Reference for Ingress
  A Kubernetes Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
- Debugging and Failure Recovery
  MATRIXX components store log files in persistent storage on the node by default, in a persistent volume (PV) at the location specified in global.storage.localStorageDir property (/home/data by default).
- Upgrading Engine Operator-Based MATRIXX Installations
  Upgrading cloud native MATRIXX has several stages.
- Migrating to Topology Operator
  This example shows migration from a MATRIXX version XXXX deployment managed by Engine Operator to a deployment managed by Topology Operator. The same approach applies when migrating from Engine Controller.
- Migration from a Bare Metal to a Cloud Native Deployment
  Migrating from a bare metal MATRIXX deployment to a cloud native deployment (from the same MATRIXX version) requires temporarily using a hybrid platform made up of components from both deployments. This hybrid environment allows migration to the cloud native deployment without disruption of services.
- The Admin Service
  Operations teams can use the Admin Service to administer a MATRIXX deployment with domain-specific commands based on the components that are installed. It allows administration of the installation without providing unrestricted direct access to the Kubernetes cluster. You can secure commands based on user roles and audit command usage.
- Uninstall MATRIXX Engine with Helm
  Use the helm uninstall command to uninstall MATRIXX Engine components installed from the Helm chart.
- Appendixes
MATRIXX Configuration
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Engine Processing Pod M3UA Kubernetes Service

The proc-m3ua-s<sid>-e<eid> service defines a Kubernetes service on TCP ports 2901, 2902 and others as needed for connections from Network Enablers (NEs) to Camel Gateways on MATRIXX Engine processing pods.

One instance of this service is required per processing pod. Each service must be configured with as many ports as processing pods in the engine. Engines can have different numbers of pods.

Ports for processing pod services are named: m3ua-<processing_blade_id>, where <processing_blade_id> identifies the processing pod. In the following example, the DNS service name for M3UA for processing pod 0 in engine 1 in sub-domain 1 is: proc-m3ua-s1e1-0.matrixx.svc.cluster.local.

If this engine had two processing pods (0 and 1), the port DNS names would be:

proc-m3ua-s1e1-0.matrixx.svc.cluster.local
proc-m3ua-s1e1-1.matrixx.svc.cluster.local

These services are defined independently of engine services, allowing them to be defined before engine start-up. The services are created by Helm when it creates the engine services, before the NE pods are started. Defining these services outside the engine allows services to join NEs and engines regardless of the order in which their pods are deployed.

Engines in Local Clusters

Engine processing pod services provide ClusterIP services for connecting local NEs to engines in the same Kubernetes cluster. In multi-cluster deployments the services also provide LoadBalancer services to NEs connecting from remote clusters using LoadBalancer and NodePorts. For more information about load balancing, see the discussion about MATRIXX cloud native reference architecture ingress load balancing in MATRIXX Architecture.

Engines in Remote Clusters

In remote clusters (where the NE is not in the same cluster as the engine), processing pod services are instead defined as ExternalName services that point to the DNS name of the LoadBalancer service providing the same service in the cluster local to the engine.