Installing on Red Hat OpenShift Clusters
Supported versions
Red Hat OpenShift 4.8.x or higher
Installation methods
To install the Turbonomic Server on Red Hat OpenShift, we recommend installing a Turbonomic Platform Operator from OperatorHub using the Red Hat OpenShift Container Platform console as this is the certified and tested method recommended by Red Hat.
The user deploying the Turbonomic Platform should have sufficient privileges to create a namespace and deploy from the OperatorHub. If you are airgapped or running a disconnected cluster, ensure you can use the OperatorHub by following Red Hat documentation applicable for your version of the Red Hat OpenShift Container Platform. See Using Operator Lifecycle Manager on restricted networks in the Red Hat OpenShift documentation for details.
Planning the deployment
Review the prerequisites and resource recommendations before proceeding with installing the Operator.
To install the Turbonomic platform on an existing Red Hat OpenShift cluster, your environment must support the listed prerequisites, which are requirements and additional configurations that will require modification of the default Custom Resource YAML (cr.yaml).
The amount of resources required to run Turbonomic is related to the complexity and type of entities it will manage (virtual machines, containers/pods, cloud accounts, and so on) in your environment.
The Turbonomic Platform Operator will install the latest version in a single namespace. Before installation, you should decide which approval strategy you want: Automatic or Manual. See Understanding OperatorHub and Installing Operators in your namespace in the Red Hat OpenShift documentation for details.
You should also review the following options before deployment, which include services configured outside of Turbonomic. If you want to use one of these setup options, review the links for more details.
-
Private container registry: See Working with a Private Repo & Image Pull Secrets
-
Configuration Options contains other common setup options, most of which can also be configured post deployment
Remote database server configurations
Turbonomic supports a remote database for historical data. This configuration allows for high availability, backups, and handling larger IO demands for larger environments or from remote SQL Server queries (for reporting and so on).
Turbonomic supports using MariaDB version 10.5.20 and MySQL 8.0.x for the historical database. This support includes comprehensive testing and quality control for Turbonomic usage.
Before deploying Turbonomic, you must configure a remote database server for historical data. If you are not going to use an existing database server, you must first create a new database server and then configure it as noted in this section.
-
If creating a new database server to use with Turbonomic, create a remote database using the recommended settings for a MariaDB or MySQL instance as noted below.
-
Preference: MariaDB 10.5.20; MariaDB 10.2 for Azure DB Services is tolerated.
-
Cluster configuration: master/replica where Turbonomic communicates to a single replica
-
MariaDB 10.5 minimally requires 10.5.20
Important:Because of a known issue, you must never use MariaDB versions 10.5.14, 10.5.15, 10.6.7, 10.7.3, or 10.8.2.
-
-
Select network and security policies that allow communication between the Kubernetes cluster and the Database server; the default DB port is 3306
-
Minimum memory: 8 GB memory/2 vCPU
-
Storage: 100 GB (set to auto-increase) or provide 1024 GB (or 1TB)
-
Encryption (SSL) is supported
-
-
Configure the Database service's server configuration (in Amazon Web Services (AWS), create a new RDS Parameter Group). Database configuration should start from the default configuration, and then include the specific parameters listed below.
Parameter
Value
log_bin_trust_function_creators
1
event_scheduler
on
max_allowed_packet
1GB
sql_mode
ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
explicit_defaults_for_timestamp
off
wait_timeout
28800
character_set_client, character_set_connection, character_set_database, character_set_results, character_set_server
utf8
-
If you are working with your own DB Server / DB Service, create a Turbonomic admin user that will be used by the deployment to create application users and grant privileges. You can define your own password, but it should be reflected in the Custom Resource YAML. Using a MySQL client or CLI, run the following commands, substituting your credentials, against your database server:
CREATE USER 'turboadmin'@'%' IDENTIFIED BY 'vmturbo'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'turboadmin'@'%' WITH GRANT OPTION;
-
If you are using AWS RDS or an Azure DB service, see AWS RDS DB Service –Additional Configuration or Azure DB Service –Additional Configuration. You will need to create the application database users, databases (empty schema), and grant privileges.
The database server should now be ready to be included in your Turbonomic installation.
For information on using Kubernetes secrets for DB app username and password credentials, see Kubernetes Secrets for DB Credentials.