Deploy Metric Insights on Kubernetes

Leveraging Kubernetes (K8s) for highly scalable container orchestration is a great option. It's an open-source framework so while there are many Kubernetes providers (Azure, GCP, TKE, etc.), deployment is generally the same across said providers. In summary, initial deployment requires a deployment configuration file and Docker images for each of the Metric Insights services. Let's walk through the process together below.

Deployment process:

  1. Understanding Application Architecture in Kubernetes
  2. Prerequisites
    1. Select Storage Class for Persistent Volumes
    2. Choose Ingress Controller Type
  3. Obtain Docker Registry Credentials
  4. Сreate Secrets for Docker Registry
  5. Deploy Load Balancers for External Communications to Data Processor & Seed
  6. Generate the Deployment Files for the Metric Insights
  7. Create Secrets Files for Each MI Service
  8. Create & Upload Secrets for Each MI Service
  9. Deploy the Metric Insights Application
  10. Apply Valid SSL Certificate for Secure Web Access
  11. Confirm Metric Insights is Deployed in Kubernetes Dashboard
  12. Access Metric Insights Application in Browser
  13. Basic Console Commands

For non-orchestrated environments, see the help article on using Simple Installer.

Starting v6.4.1. services inside containers are run by one unprivileged user. The ownership for the network shared volume must be manually set to www-data, uid: 33 before updating to v6.4.1.

1. Understanding the Metric Insights Application Architecture in Kubernetes

Below is an architectural diagram of Metric Insights deployed in Kubernetes Namespace. A namespace is a virtual cluster that consists of several Nodes (servers). The nodes host Pods which is essentially a Container. Metric Insights consists of services that run inside their own container, rooted to a shared file system for persistence. 

The deployment scheme consists of the following services deployed in individual pods (1 service per pod):

Required services:

  1. Web Master  
  2. Web Slave
  3. Data Analyzer    
  4. Data Processor  
  5. Seed   
  6. Monitoring

Optional services:

  1. Remote Data Processor 1  
  2. Remote Data Processor 2

 Additional items of note:

  • A minimum of 3 Nodes are required for automatic Failover
  • MySQL is required to host the Metric Insights application database, and it should run on a remote server (outside of Kubernetes, on a dedicated database cluster)
  • Persistent storage is required for the shared file system
  • Root user is required for initial deployment of the Web pods for the following reasons:
    • System services are created during pod initialization for use by the application and these require privileged access (root user). These system services are isolated from the application however, so system configuration changes cannot be made through the application.
      • System services that require root: apache2, rsyslog, cron, supervisor 

2. Prerequisites

Ensure that the system requirements for a Metric Insights server are met.

MI deployment manifest supports the following Kubernetes versions:

  • 1.14
  • 1.18
  • 1.19
  • 1.20
  • 1.26.3

 

The following is required to deploy to Kubernetes:

  • Access to the Kubernetes Dashboard (Web UI)
  • Kubectl command-line tool to manage the Kubernetes Cluster
  • Remote database server to host the application database; e.g., MySQL/MariaDB (MariaDB is supported only in MI versions prior to 6.2.0)
  • Persistent shared storage; e.g., NFS, Portworx

 

The following ports must also be open on the network:

  • 80, 443 - HTTP/HTTPS ports for UI access
  • 2550 - TCP port for the Data Processor cluster within the kubernetes namespace
  • 2551 - TCP port for the Seed service within the kubernetes namespace
  • 32550 - TCP port for external access to the Data Processor cluster
  • 32551 - TCP port for external access to the Seed service
  • 3306 - MySQL port
  • 8080, 8443 - HTTP/HTTPS ports for the REST API Data Processor service
  • 8081 - TCP port for the Monitoring Tool
  • 6379 - port that needs to be opened within the namespace (network rules).

 

Kubernetes namespace requirements:

  1. Create a unique namespace for Metric Insights: 
  2. Mount persistent storage volumes to the namespace. See Select a Storage Class for Persistent Volumes below for more.
  3. Configure an ingress controller to allow incoming connections to the namespace (UI access in a browser). See Choose an Ingress Controller type below for more.

The main services (web, data analyzer, data processor, seed, monitoring) can be installed separately depending on the needs of your deployment.

2.1. Configure the Storage Class for Persistent Volumes

Metric Insights supports the following Storage Classes for the application file system, which is shared across pods as persistent volumes. Supported types are NFS and Portworx.

If using an NFS server hosted on Linux, please configure the mounted share as follows:

  • In /etc/exports, set the mounted share to /opt/mi with the following options:
    • rw,fsid=1,crossmnt,no_subtree_check,no_root_squash,async)

If using Portworx, identify the exact class name to use for the deployment.

  • The class name must also be enabled for multi-node volume attachment.

Running the installer to set the storage class for the deployment configuration file:

$ ./installer.py kubernetes --storage-class <nfs/portworx>

2.2. Choose an Ingress Controller type

Metric Insights supports the following Ingress Controller Types for incoming traffic from outside of the namespace. For example, users opening the application in a browser will be routed through the Ingress Controller. Supported types are:

  • Nginx
  • Traefik v1.7

Note, for Traefik v1.7, TCP ports are not supported. So for external communications to Seed and Data Processor, additional load balancers must be deployed. See Deploy Load Balancers for external communications to Data Processor & Seed for more.

Running the installer to set the ingress controller type for the deployment configuration file:

$ ./installer.py kubernetes --ingress-controller-type <nginx/traefik>

3. Obtain Docker Registry Credentials

Contact MI Support for access to the official Metric Insights Docker Registry. Credentials are needed to pull Docker images for each Metric Insights service.

  • Note, the MI Docker Registry address (docker.metricinsights.com)  is specified in the deployment configuration file: metricinsights-6.x.x.yml.

4. Сreate the Secret for Docker Registry

Before deploying to Kubernetes, Docker Registry credentials must be registered as Secret for K8s to reference. Metric Insights uses a secret labeled docker-registry to authenticate against a Docker registry to pull Docker images.

  • Note, Secret is Kubernetes Object for storing and managing sensitive information like passwords and OAuth tokens. See Kubernetes Secrets for more.

Create Secret for Docker Registry credentials using kubectl:

kubectl --namespace <MI-namespace> create secret docker-registry <secret-name> --docker-server <docker-registry-url> --docker-username <username> --docker-password <password> --docker-email <email-address>

5. Deploy Load Balancers for External Communications to Data Processor & Seed

This step is critical if you plan on integrating with BI Tools that require a Remote Data Processor to run on a Windows machine (e.g., Power BI, Qlik Sense, Tibco Spotfire, etc.)

For the Remote Data Processor to communicate with the Local Data Processor in Kubernetes, deploy additional Load Balancers to handle external TCP traffic. Make sure the following ports are open on the load balancers:

  • 32550 (data processor)
  • 32551 (seed)

Note, additional load balancers are needed because K8 Ingress Controller types like Traefik only handle HTTP/HTTPS traffic and not TCP. Comparatively, for an ingress controller like Nginx, you can use a combination of the ingress controller + nodeports for external communications, or deploy load balancers as their own service (separate pods).

For the public hostname, we recommend using the hostname of the K8 master node and adding "dataprocessor" or "seed" to the name to keep things simple. For example, if the hostname of the master node (the hostname by which users will access the UI in a browser) is customName.companyName.com then you can map the following for the Data Processor LB: customName-dataprocessor.companyName.com.

Once the load balancers are deployed and a public hostname is set, update the following parameters in either the Data Processor secrets file (dataprocessor.env) or in the K8 deployment manifest file (metricinsights-6.x.x.yml):

  • DATAPROCESSOR_HOSTNAME
  • DATAPROCESSOR_SEED_HOSTNAME

Here's an example for the deployment configuration file:

...
        env:
          - name: SPRING_PROFILES_ACTIVE
            value: "singleton,swagger,admin"
          - name: DATAPROCESSOR_HOSTNAME
            value: "metricinsights-dataprocessor"
          - name: DATAPROCESSOR_SEED_HOSTNAME
            value: "metricinsights-seed"
          - name: DATAPROCESSOR_SEED_BIND_PORT
            value: "2551"
...

6. Generate the Deployment Files for the Metric Insights

It is possible to:

Generate the Deployment File by the Installer

To create a Kubernetes Deployment configuration file (also called a manifest), use the MI installer to generate a yaml file. Here's an example where we are setting the following values:

  • Storage Type = NFS
  • Ingress Controller = Nginx
  • Private Docker Registry
  • Data Processor Hostname

If the remote DB server has the same timezone as MI app:

./installer.py kubernetes --storage-class nfs --nfs-server-address <nfs.example.com> --ingress-controller-type nginx --hostname <MI-hostname> --dp-hostname <dataprocessor_hostname> --registry <registry-url> --timezone  <MI app timezone> -o <manifest filename>.yml

If the remote DB server has a different timezone than MI app:

./installer.py kubernetes --storage-class nfs --nfs-server-address <nfs.example.com> --ingress-controller-type nginx --hostname <MI-hostname> --dp-hostname <dataprocessor_hostname> --registry <registry-url> --timezone <MI app timezone> --mysql-timezone <remote database server timezone> -o <manifest filename>.yml

The key here is using the -o option for the output file and then specifying a file name with a *.yml extension (yaml file).

Use ./installer.py kubernetes -h for more options. See Basic Console Commands section.

Generate the Deployment Files by the Installation Wizard

To generate the set of files required for the Metric Insights deployment, refer to Generate the Deployment Files by the Installation Wizard article.

7. Create Secrets Files for Each MI Service

This step is required only in case you have generated the deployment file by the Installer.

There are files templates for creating secrets files for each service in MetricInsights-Installer-v6.x.x-Full/utils/orchestration/kubernetes/secrets/:  

Template File  Service
data-analyzer.env.j2
 Data Analyzer
dataprocessor.env.j2
 Data Processor
monitoring.env.j2
 Monitoring
mysql.secret.j2
 MySQL
seed.env.j2
 Seed
web.env.j2
 Web Service

It is required to create the secrets files from the templates:

  1. Copy each file template without .j2 extension from the installer directory to desired directory.
  2. Open each file in an editor and customize all variables. Ensure passwords are consistent between files. You can encode passwords of our choice or create random passwords:
    • to encode, run echo -n '<password>' | base64
    • to generate a random password, use openssl rand -base64 8 | tr -d /=+ | cut -c -11

8. Create & Upload Secrets for Each MI Service

Create the secrets for each service by uploading each file to the namespace using kubectl:

$ kubectl --namespace <MI-namespace> create secret generic metricinsights-web --from-file web.env
$ kubectl --namespace <MI-namespace> create secret generic metricinsights-dataprocessor --from-file dataprocessor.env
$ kubectl --namespace <MI-namespace> create secret generic metricinsights-seed --from-file seed.env
$ kubectl --namespace <MI-namespace> create secret generic metricinsights-mysql-root-password --from-file mysql.secret
$ kubectl --namespace <MI-namespace> create secret generic metricinsights-data-analyzer --from-file data-analyzer.env 
$ kubectl --namespace <MI-namespace> create secret generic metricinsights-monitoring --from-file monitoring.env

9. Deploy the Metric Insights Application

Next, deploy the Metric Insights application to the K8s namespace using the newly created deployment configuration file:

$ kubectl --namespace <MI-namespace> apply -f <deployment_file>.yml

You should see the services and pods being created as soon as the yaml file is applied. The kubectl apply output should look something like this:

$ kubectl --namespace <MI-namespace> apply -f <manifest filename>.yml 
service/metricinsights-web created
deployment.apps/metricinsights-web-master created
deployment.apps/metricinsights-web-slave created
service/metricinsights-seed created
deployment.apps/metricinsights-seed created
service/metricinsights-dataprocessor created
service/metricinsights-data-analyzer created
deployment.apps/metricinsights-data-analyzer created
persistentvolume/metricinsights-v613-data created
persistentvolumeclaim/metricinsights-v613-data created
persistentvolume/metricinsights-v613-ssl created
persistentvolumeclaim/metricinsights-v613-ssl created
persistentvolume/metricinsights-v613-external-libs created
persistentvolumeclaim/metricinsights-v613-external-libs created
ingress.extensions/metricinsights-ingress-nginx created 
.
.
.

If you need to customize some processes after the application deployment, see Configuring Custom Components article.  

10. Apply Valid SSL Certificate for Secure Web Access

Once Metric Insights is deployed to the Kubernetes namespace and a valid DNS name is mapped, we need to apply a valid SSL certificate to the namespace for secure web access. The easiest way is to get both the SSL certificate and associated certificate private key and create a TLS secret by running:

kubectl create secret tls my-tls-secret --key <certificate private key> --cert <ssl certificate> 

For instructions on how to generate an SSL certificate (if one is not ready), please see: Set up Web SSL Certificate for Metric Insights  article.

11. Confirm Metric Insights is Deployed in Kubernetes Dashboard

Once the deployment is complete, log into the Kubernetes Dashboard to confirm Metric Insights is available. See the image below as a reference.

12. Access Metric Insights Application in Browser

Now that Metric Insights is up and running in Kubernetes, the web UI is accessible through the requested Hostname or IP Address:

  • The hostname and ip address can be for the Ingress Controller or the Kubernetes worker node + port 80/443 on which the Web pod is running.

To learn how to administer Metric Insights in Kubernetes, see Administering Metric Insights in Kubernetes.

13. Basic Console Commands

Basic console commands can be checked by running ./installer.py kubernetes --help.

The following list of utilities are available to use on the host.

Note, all of these tools become available only if the Web Component is installed.

Optional Parameters
--registry REGISTRY Docker registry URL, that will be used for deploying MI components. Example: <hostname> or <hostname>:<port>. (default: None)
--hostname HOSTNAME Web service additional hostname (default: None). The option is used to assign 127.0.0.1 to the Web container. It helps the Metric Insights application to interact with its internal components faster inside the container.