Home
MATRIXX Installation and Upgrade
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.
Topology Operator Configuration
Configure MATRIXX deployments based on Topology Operator by adding values for properties from the MATRIXX Helm chart to your Helm values files.
Pre-Update Configuration
docker_kubernetes/c_to_pre_delete_config.html#concept_fj5_frw_hvb__table_hvt_vxw_hvb describes the properties available for configuring pre-update instances.

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.
  - Adding or Removing an Engine or Sub-Domain
    Adding a MATRIXX Engine or sub-domain is similar to the processes used for configuration, maintenance, or software upgrades. This should be performed in the following order:
  - Health Checks
    The subdomain-health-checker-sX and engine-health-checker-sXeY pods run multiple containers, each of which is a separate health check.
  - Disaster Recovery
    In multi-cluster installations, if a cluster fails, Topology Operator recovers in different ways depending on whether the cluster contained master instances or not.
  - Changes to Custom Resource Definitions
    MtxSubdomain and MtxEngine custom resource definitions (CRDs) for Pricing Controller, Engine Controller, and Engine Operator-based deployments are in the matrixx.com group. MtxTopology, MtxSubdomain, and MtxEngine CRDs for use with Topology Operator-based deployments are in the matrixx.matrixx.com group.
  - Manually Starting and Stopping Engines
    Do not use the stop_engine and start_engine scripts with Topology Operator-based deployments. Instead, to start or stop MATRIXX Engine, patch the MtxEngine CR. Start and stop actions are then handled by the operators.
  - Scaling MATRIXX Engine Pods with Helm
    In Topology Operator-based installations, increase or decrease the MATRIXX Engine pod replica count with the helm upgrade command, in the same way as any other configuration change.
  - Reconciliation Errors
    Sometimes errors may be seen in the logs of the various different operators as they try to reconcile the current state and target state. In certain cases these errors can be ignored.
  - Uninstalling a Topology Operator-Based Deployment
    To uninstall a Topology Operator-based deployment, uninstall the release, then delete the namespace.
  - Topology Operator Configuration
    Configure MATRIXX deployments based on Topology Operator by adding values for properties from the MATRIXX Helm chart to your Helm values files.
    - Topology Operator Global Configuration
      docker_kubernetes/c_to_config_global.html#concept_awl_gqw_hvb__table_w1k_1tw_hvb describes properties available for configuring the global characteristics of a Topology Operator-based deployment.
    - Multi-Tenancy Configuration
      docker_kubernetes/c_to_config_mt.html#concept_ljw_mrh_gcc__table_dv2_bsh_gcc describes properties available for configuring multi-tenancy characteristics.
    - Transaction Log Deletion Configuration
      docker_kubernetes/c_to_transaction_log_del_config.html#concept_rlp_1xw_hvb__table_mzr_jxw_hvb describes the properties available for configuring transaction log deletion instances.
    - Engine Configuration
      docker_kubernetes/c_to_transaction_log_del_config.html#concept_rlp_1xw_hvb__table_mzr_jxw_hvb describes the properties available for MATRIXX Engine configuration in a Topology Operator-based deployment.
    - Engine Health Checker Configuration
      docker_kubernetes/c_to_config_healthcheck_config.html#concept_hvn_x2w_xxb__table_yl3_fhw_xxb describes the properties available for MATRIXX Engine health checker configuration in a Topology Operator-based deployment.
    - Engine Operator Configuration
      docker_kubernetes/c_to_engine_operator_config.html#concept_e4j_5qw_hvb__table_mvl_nxw_hvb describes the properties available for configuring engine-operator instances in a Topology Operator-based deployment.
    - Engine Starter and Stopper Configuration
      Instances of engine-starter and engine-stopper run the start and stop commands previously handled by Engine Controller.
    - Event Repository Purge Configuration
      docker_kubernetes/c_to_event_repository_purge_config.html#concept_fpy_brw_hvb__table_phq_sxw_hvb describes the properties available for configuring event-purge instances.
    - Pod Monitor Configuration
      docker_kubernetes/c_to_pod_monitor_config.html#concept_fpy_brw_hvb__table_phq_sxw_hvb describes the properties available for configuring pod-monitor instances.
    - Pre-Delete Configuration
      docker_kubernetes/c_to_pre_delete_config.html#concept_fj5_frw_hvb__table_hvt_vxw_hvb describes the properties available for configuring pre-delete instances.
    - Pre-Update Configuration
      docker_kubernetes/c_to_pre_delete_config.html#concept_fj5_frw_hvb__table_hvt_vxw_hvb describes the properties available for configuring pre-update instances.
    - Sub-Domain Health Checker Configuration
      docker_kubernetes/c_to_subdomain_healthcheck_config.html#concept_t2s_bnw_xxb__table_obz_2nw_xxb describes the properties available for sub-domain health checker configuration in a Topology Operator-based deployment.
    - Sub-Domain Operator Configuration
      docker_kubernetes/c_to_subdomain_op_config.html#concept_ik5_lrw_hvb__table_vys_yxw_hvb describes the properties available for configuring subdomain-operator instances.
    - Topology Agent Configuration
      docker_kubernetes/c_to_agent_config.html#concept_yhg_srw_hvb__table_cqc_jyw_hvb describes the properties available for configuring topology-agent instances.
    - Topology Operator Configuration
      docker_kubernetes/c_to_operator_config.html#concept_tkb_vrw_hvb__table_bj1_kyw_hvb describes the properties available for configuring the containers in the topology-operator pod.
    - Engine-Level Traffic Routing Agent Configuration
      docker_kubernetes/c_to_tralb_config.html#concept_otw_yrw_hvb__table_vcw_kyw_hvb describes the properties available for configuring Traffic Routing Agent (TRA-PROC and TRA-PUB) instances in a Topology Operator-based deployment.
    - Topology Operator Pricing Configuration
      docker_kubernetes/c_to_pricing_config.html#concept_h5h_gsw_hvb__table_spv_zzw_hvb describes the properties available for configuring pricing-loader and pricing-controller instances.
    - Topology Operator Tax Configuration
      Set the tax-controller property to true to enable the tax-controller sub-chart. The default value is false.
  - Topology Operator Pod Annotations
    Topology Operator components have pod annotations available to match, including annotations added to preexisting MATRIXX.
- 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.
- 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

Pre-Update Configuration

Pre-Delete Configuration Properties describes the properties available for configuring pre-update instances.

Table 1. Pre-Update Configuration Properties
Property	Description
engine.operatorV2.preUpdate.affinity	The affinity configuration used by the pre-update pods. The value is of type Affinity.
engine.operatorV2.preUpdate.image.nameOverride	The name of the image used for the pre-update pods.
engine.operatorV2.preUpdate.image.versionOverride	The tag value of the image used for the pre-update pods.
engine.operatorV2.preUpdate.labels.podLabels	Labels added to the pre-update pods. These would be in addition to the labels specified with the `global.labels.podLabels` property which are applied to all pods.
engine.operatorV2.preUpdate.nodeSelector	The node selector configuration used by the pre-update pods.
engine.operatorV2.preUpdate.podSecurityContext	The pod security context configuration used by the pre-update pods. The value is of type PodSecurityContext. The default value is `fsGroup: 1000`.
engine.operatorV2.preUpdate.resources	The resource configuration used by the pre-update pods. The value is of type ResourceRequirements.
engine.operatorV2.preUpdate.securityContext	The container security context configuration used by the pre-update pods. The value is of type SecurityContext. The default value is: `allowPrivilegeEscalation: false privileged: false runAsNonRoot: true runAsUser: 1000`
engine.operatorV2.preUpdate.serviceAccount.annotations	These annotations are added to the service account when the `engine.operatorV2.preUpdate.serviceAccount.create` property is set to `true`.
engine.operatorV2.preUpdate.serviceAccount.create	When set to `true`, a service account is created with the specified name and annotations in the master namespace. Otherwise, a service account with the specified name must be manually created in the master namespace. The default value is `true`.
engine.operatorV2.preUpdate.serviceAccount.name	A service account with this name is created in the master namespace when the `engine.operatorV2.preUpdate.serviceAccount.create` property is set to `true`. Otherwise, a service account with this name must be manually created in the master namespace. The default value is `topology-operator-pre-update`.
engine.operatorV2.preDelete.tolerations	The tolerance configuration used by the pre-update pods. The value is a list of type Toleration.