Kubernetes common configuration parameters
You can configure the Custom Resource YAML for your desired configuration during or after deployment.
Custom Resource values
The following table describes the values that you can specify in the Kubernetes custom resource to configure your deployment. For a complete list of options, refer to the custom resource definition for the Turbonomic Operator in the CRD YAML file.
All parameters are in the global
section of the custom resource unless otherwise
specified.
Some of these parameters might be required for your Kubernetes cluster.
Configuration |
Parameter |
Modification |
Default value |
---|---|---|---|
Disabling the default ingress |
|
You can configure your own ingress to route requests to the Turbonomic server.
To use your own ingress, disable
For more information, see Platform Provided Ingress and Red Hat OpenShift Routes. Note:
(Red Hat OpenShift requirement) Since |
|
Enabling targets |
|
All enabled target probes use the following format: For a list of supported target probes and the parameters that are required to enable the target, see this sample CR. |
None enabled |
Specifying private repository and image pull credentials |
|
Once the images are pulled in to your private registry, update the registry and repository
location of the Turbonomic server container images in the custom resource YAML.
Edit the custom resource to include the repository and registry attributes. For example::
For more information, see Working with a Private Repository and Image Pull Secrets |
|
Specifying non-default storage class |
|
The Turbonomic deployment uses the cluster's default storage class if one is
defined. If you want to use a different storage class, specify the name of the storage class in
For more information, see Storage Class Requirements |
Use the cluster’s default storage class |
Enabling an external database |
|
You can install Turbonomic directly to a Red Hat OpenShift or Kubernetes
cluster (instead of installing the VM image), and you can provide your own historical database by
setting the
For more information, see Configuring a Remote Database. |
None; local containerized DB and PV |
Specifying the group ID for all pods |
|
Components need read/write access to Persistent Volumes (PVs) and may use a range of fsGroup ids.
Where required, security context for which UIDs are to be used for a pod to write to its PV is
configured using the project's SCC UID, obtained from the project's properties and supplied to the
Turbonomic deployment through the Custom Resource YAML. Specify this information
in the
Note:
Security Context is a requirement for Red Hat OpenShift. For more information, see Determine the Security Context Constraints (SCC) UID range and Set the Security Context Constraints. See information related to storage classes for all other Kubernetes deployments. |
|
Adding IAM role support for AWS Mediation |
|
Connection to AWS through an IAM role is supported when a Turbonomic instance is deployed to Kubernetes in AWS through Red Hat OpenShift Service on AWS (ROSA) or Amazon EKS. For these deployments, cluster configurations must support an OIDC provider and webhooks. (Best Practice) Manually create a separate service account for the AWS Mediation pods to use. You must then modify the Custom Resource YAML to specify this service account to the AWS Mediation components. For example:
For more information, see this topic. |
IAM user |
Enabling NGINX service annotations |
|
To modify the
For more information, see NGINX Service Configuration Options and Using Platform Provided Ingress. |
None |
Using a self-signed certificate for UI HTTPS |
|
Relevant for provided Using AWS Certificate Manager, you can leverage ACM to provide a certificate to
the AWS LoadBalancer created for the Turbonomic
For more information, see Self-Signed Certificates and AWS Certificate Manager if you are running in AWS and have AWS Certificate Manager (ACM). |
Unsigned cert |
Enabling secure LDAP integration |
|
If your company policy requires secure access, you can use a certificate with your LDAP service to set up secure access for your users. For example, you can configure Active Directory (AD) accounts to manage external authentication for users or user groups. The user interface to enable AD includes a Secure option, which enforces certificate-based security. Configure LDAP first in the UI, then update the Turbonomic configuration after deployment to apply the certificate. For more information, see Enforcing Secure Access via LDAP. |
None; configure after deployment |
Enabling SSO integration |
|
If your company policy supports Single Sign-On (SSO) authentication, you can configure Turbonomic to support SSO authentication via either Security Assertion Markup Language (SAML) 2.0 or OpenID Connect 1.0. For more information, see Single Sign-On Authentication. |
Not enabled; configure after deployment |
Enabling self-monitoring for Kubeturbo |
|
You can enable Kubeturbo using the following format: |
Not enabled |
Enabling monitoring of other Kubernetes clusters |
You can deploy Kubeturbo through YAML, Helm, or an operator. For more information, see Connecting to Kubernetes Clusters. |
||
Enabling Turbonomic on Turbonomic APM example |
|
Start with the sample custom resource YAML to enable
|
Not enabled |
Enabling SaaS Reporting |
The Turbonomic platform includes an optional SaaS-based reporting component that you can choose to enable. You can use SaaS reporting to understand trends in application resource management and to share insights with stakeholders through reports and Liveboards. SaaS reporting for on-prem environments is not currently available. For more information, see Enabling SaaS Reporting. |
Not enabled |
|
Enabling Embedded Reporting |
|
The Turbonomic platform includes an Embedded Reporting component that you can choose to enable when you install the platform. Embedded Reporting stores a history of your managed environment and then presents selective snapshots of this history with a set of standard dashboards and reports. To enable Embedded Reporting, find the For more information, see Enabling Embedded Reporting. |
Not enabled |
Enabling Data Exporter |
|
You can enable just the Data Exporter feature, which is the data export without postures or
grafana. To enable the Data Exporter, find the
Note:
If you already have |
|
Enabling audit log forwarding |
|
Organizations can redirect the audit log to their centralized logging systems for analysis and tamper resistance. Turbonomic supports the syslog protocol, which enables it to easily integrate logging with many third-party logging solutions, such as Splunk. For more information, see Redirecting Audit and Container Logs. |
All logging centralized to |
NGINX service configuration options
The default Turbonomic configuration sets up an nginx
deployment in the Turbonomic namespace, creates the service
“nginx
” (type: LoadBalancer, externalTrafficPolicy: Local)
, and
attempts to get a public external IP. You have several options on how to have both the routing logic
defined in the nginx
service, and the flexibility to define an ingress/route to Turbonomic, or annotate load balancer configurations.
Option 1: NGINX as proxy and bring your own ingress or route
-
You can configure
nginx
as a ClusterIP type service, allowing you to use your own ingress or route, and still maintain the Turbonomic internal routing rules and leveragenginx
as a proxy. -
This is required to leverage Embedded Reporting on your Turbonomic instance with your own ingress or route. You must set the
nginxIsPrimaryIngress
parameter tofalse
.
You do not need this configuration if you are running Embedded Reporting with the Turbonomic provided nginx
service as the ingress.
kind: XL
metadata:
name: xl-release
spec:
nginx:
nginxIsPrimaryIngress: false
#use openshiftingress and nginxingress if you would like Turbonomic to create a single route that will point to the nginx service
#openshiftingress:
# enabled: true
#nginxingress:
# enabled: true
To create your own ingress
, see Using Platform Provided Ingress and
the Ingress minimum requirements.
Option 2: NGINX as a LoadBalancer service type and customize annotations
Turbonomic does not deploy an ingress controller; it deploys
nginx
as a Kubernetes service which can create a cloud provider LoadBalancer
(external type) or be used as a internal clusterIP service type to use behind a customer (platform)
provided ingress.
Things to consider:
-
The types of LoadBalancers that are available based on your cloud or infrastructure provider.
-
Understand all available service annotations and understand what is required for your environment.
-
Turbonomic has an opinion on LoadBalancer.
To modify the nginx
LoadBalancer type service to use an internal IP address on your LoadBalancer, use the required
annotation depending on your Kubernetes platform and version, and environment.
nginx
service the proper annotations you have determined are required for your
LoadBalancer in this place in the XL Custom Resource: global:
ingress:
annotations:
#provide the correct annotations based on the LoadBalancer and properties you want.
Option 3: NGINX external traffic policy
In some environments where you are using the nginx
service as your ingress (as
LoadBalancer
type), you will want to change the
externalTrafficPolicy
from the default of Local
to a value like
Cluster
. Add this parameter under nginx
and combine with any other
parameters you may have defined here:
spec:
global:
ingress:
annotations:
nginx:
externalTrafficPolicy: Cluster
Self-signed certificates and AWS Certificate Manager (ACM)
You can deploy the Turbonomic Server on a Kubernetes cluster running in AWS,
using the Turbonomic provided nginx
as a
LoadBalancer
type service.
You can leverage AWS Certificate Manager to provide a certificate to the AWS
LoadBalancer created for the Turbonomic
nginx
service using an annotation of
service.beta.kubernetes.io/aws-load-balancer-ssl-cert
with the ACM Amazon Resource
Name (ARN) on the service.
If you want to modify a deployed CR, you must apply the CR change then delete the existing
nginx Service
. The Operator recreates the nginx Service
with the
certificate annotation.
-
Create an AWS ARN Certificate.
-
In the Turbonomic custom resource (CR), under
ingress: annotations
, specify theaws-load-balancer-ssl-cert
annotation and ACM ARN. The LoadBalancer created for thenginx Service
uses this certificate for TLS termination at the LoadBalancer that would be combined with another service annotation required for your LoadBalancer type that you have chosen.Refer to the AWS documentation for the exact syntax for the required annotation.
-
Apply the CR.
Turbonomic creates the
nginx Service
that references the certificate to be used for TLS termination on the LoadBalancer.