Custom resources

You can configure your Maistra Service Mesh by modifying the default Maistra custom resource or by creating a new custom resource.

Prerequisites

Maistra Service Mesh custom resources

Note

The istio-system project is used as an example throughout the Maistra documentation, but you can use other projects as necessary.

A custom resource allows you to extend the API in an Maistra Service Mesh project or cluster. When you deploy Maistra it creates a default ServiceMeshControlPlane that you can modify to change the project parameters.

The Maistra operator extends the API by adding the ServiceMeshControlPlane resource type, which enables you to create ServiceMeshControlPlane objects within projects. By creating a ServiceMeshControlPlane object, you instruct the Operator to install a Maistra control plane into the project, configured with the parameters you set in the ServiceMeshControlPlane object.

This example ServiceMeshControlPlane definition contains all of the supported parameters and deploys Maistra Service Mesh 2.1 images based on Red Hat Enterprise Linux (RHEL).

Important

The 3scale Istio Adapter is deployed and configured in the custom resource file. It also requires an active 3scale account (SaaS or On-Premises).

Example ServiceMeshControlPlane resource
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  proxy:
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 128Mi
  tracing:
    type: Jaeger
  gateways:
    ingress: # istio-ingressgateway
      service:
        type: ClusterIP
        ports:
        - name: status-port
          port: 15020
        - name: http2
          port: 80
          targetPort: 8080
        - name: https
          port: 443
          targetPort: 8443
      meshExpansionPorts: []
    egress: # istio-egressgateway
      service:
        type: ClusterIP
        ports:
        - name: status-port
          port: 15020
        - name: http2
          port: 80
          targetPort: 8080
        - name: https
          port: 443
          targetPort: 8443
    additionalIngress:
      some-other-ingress-gateway: {}
    additionalEgress:
      some-other-egress-gateway: {}

  policy:
    type: Istiod # or Mixer
    mixer: # only applies if policy.type: Mixer
      enableChecks: false
      failOpen: false

  telemetry:
    type: Istiod # or Mixer
    mixer: # only applies if telemetry.type: Mixer, for v1 telemetry
      sessionAffinity: false
      batching:
        maxEntries: 100
        maxTime: 1s
      adapters:
        kubernetesenv: true
        stdio:
          enabled: true
          outputAsJSON: true
  addons:
    grafana:
      enabled: true
      install:
        config:
          env: {}
          envSecrets: {}
        persistence:
          storageClassName: ""
          accessMode: ReadWriteOnce
          capacity: 5Gi
        service:
          ingress:
            contextPath: /grafana
            tls:
              termination: reencrypt
    kiali:
      name: kiali
      enabled: true
      install: # install kiali CR if not present
        dashboard:
          viewOnly: false
          enableGrafana: true
          enableTracing: true
          enablePrometheus: true
      service:
        ingress:
          contextPath: /kiali
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch
          memory:
            maxTraces: 100000
          elasticsearch:
            nodeCount: 3
            storage: {}
            redundancyPolicy: SingleRedundancy
            indexCleaner: {}
        ingress: {} # jaeger ingress configuration
  runtime:
    components:
      pilot:
        deployment:
          replicas: 2
        pod:
          affinity: {}
        container:
          resources:
          limits: {}
          requirements: {}
      grafana:
        deployment: {}
        pod: {}
      kiali:
        deployment: {}
        pod: {}

The following table lists the parameters for the ServiceMeshControlPlane resource.

Table 1. ServiceMeshControlPlane resource parameters
Name Description Type

apiVersion

APIVersion defines the versioned schema of this representation of an object. Servers convert recognized schemas to the latest internal value, and may reject unrecognized values. The value for Maistra Service Mesh version 2.0 is maistra.io/v2.

The value for Maistra Service Mesh version 2.0 is maistra.io/v2.

kind

Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to.

Not configurable

metadata

Metadata about this ServiceMeshControlPlane instance You can provide a name for your control plane installation to keep track of your work, for example, basic-install, or production.

string

spec

The specification of the desired state of this ServiceMeshControlPlane. This includes the configuration options for all components that comprise the control plane.

For more information, see Table 2.

status

The current status of this ServiceMeshControlPlane and the components that comprise the control plane.

For more information, see Table 3.

The following table lists the specifications for the ServiceMeshControlPlane resource. These parameters configure Maistra Service Mesh for your microservices and apps.

Table 2. ServiceMeshControlPlane resource spec
Name Description Configurable parameters

addons

You use the addons parameter to configure additional features beyond core control plane components, such as visualization, or metric storage.

3scale, grafana, jaeger, kiali, and prometheus.

cluster

The cluster parameter sets the general configuration of the cluster (cluster name, network name, multi-cluster, mesh expansion, etc.)

meshExpansion, multiCluster, name, and network

gateways

You use the gateways parameter to configure ingress and egress gateways for the mesh.

enabled, additionalEgress, additionalIngress, egress, ingress, and openshiftRoute

general

The general parameter represents general control plane configuration that does not fit anywhere else.

logging and validationMessages

policy

You use the policy parameter to configure policy checking for the control plane. Policy checking can be enabled by setting spec.policy.enabled to true.

mixer remote, or type. type can be set to Istiod, Mixer or None.

profiles

You select the ServiceMeshControlPlane profile to use for default values using the profiles parameter.

default

proxy

You use the proxy parameter to configure the default behavior for sidecars.

accessLogging, adminPort, concurrency, and envoyMetricsService

runtime

You use the runtime parameter to configure the control plane components.

components, and defaults

security

The security parameter allows you to configure aspects of security for the control plane.

certificateAuthority, controlPlane, identity, dataPlane and trust

techPreview

The techPreview parameter enables early access to features that are in technology techPreview.

N/A

telemetry

If spec.mixer.telemetry.enabled is set to true, telemetry is enabled.

mixer, remote, and type. type can be set to Istiod, Mixer or None.

tracing

You use the tracing parameter to enables distributed tracing for the mesh.

sampling, type. type can be set to Jaeger or None.

version

You use the version parameter to specify what Maistra version of the control plane to install. When creating a ServiceMeshControlPlane with an empty version, the admission webhook sets the version to the current version. New ServiceMeshControlPlanes with an empty version are set to v2.0. Existing ServiceMeshControlPlanes with an empty version keep their setting.

string

ControlPlaneStatus represents the current state of your service mesh.

Table 3. ServiceMeshControlPlane resource ControlPlaneStatus
Name Description Type

annotations

The annotations parameter stores additional, usually redundant status information, such as the number of components deployed by the ServiceMeshControlPlane. These statuses are used by the command line tool, oc, which does not yet allow counting objects in JSONPath expressions.

Not configurable

conditions

Represents the latest available observations of the object’s current state. Reconciled indicates whether the operator has finished reconciling the actual state of deployed components with the configuration in the ServiceMeshControlPlane resource. Installed indicates whether the control plane has been installed. Ready indicates whether all control plane components are ready

string

components

Shows the status of each deployed control plane component.

string

appliedSpec

The resulting specification of the configuration options after all profiles have been applied.

ControlPlaneSpec

appliedValues

The resulting values.yaml used to generate the charts.

ControlPlaneSpec

chartVersion

The version of the charts that were last processed for this resource.

string

observedGeneration

The generation observed by the controller during the most recent reconciliation. The information in the status pertains to this particular generation of the object. The status.conditions are not up-to-date if the status.observedGeneration field doesn’t match metadata.generation.

integer

operatorVersion

The version of the operator that last processed this resource.

string

readiness

The readiness status of components & owned resources

string

ServiceMeshControlPlane parameters

The following examples illustrate use of the ServiceMeshControlPlane parameters and the tables provide additional information about supported parameters.

Important

The resources you configure for Maistra Service Mesh with these parameters, including CPUs, memory, and the number of pods, are based on the configuration of your OpenShift cluster. Configure these parameters based on the available resources in your current cluster configuration.

Istio global example

Here is an example that illustrates the Istio global parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Note

In order for the 3scale Istio Adapter to work, disablePolicyChecks must be false.

Example global parameters
  istio:
    global:
      tag: 1.1.0
      hub: registry.redhat.io/openshift-service-mesh/
      proxy:
        resources:
          requests:
            cpu: 10m
            memory: 128Mi
          limits:
      mtls:
        enabled: false
      disablePolicyChecks: true
      policyCheckFailOpen: false
      imagePullSecrets:
        - MyPullSecret
Table 4. Global parameters
Parameter Description Values Default value

disablePolicyChecks

This parameter enables/disables policy checks.

true/false

true

policyCheckFailOpen

This parameter indicates whether traffic is allowed to pass through to the Envoy sidecar when the Mixer policy service cannot be reached.

true/false

false

tag

The tag that the Operator uses to pull the Istio images.

A valid container image tag.

1.1.0

hub

The hub that the Operator uses to pull Istio images.

A valid image repository.

maistra/ or registry.redhat.io/openshift-service-mesh/

mtls

This parameter controls whether to enable/disable Mutual Transport Layer Security (mTLS) between services by default.

true/false

false

imagePullSecrets

If access to the registry providing the Istio images is secure, list an imagePullSecret here.

redhat-registry-pullsecret OR quay-pullsecret

None

These parameters are specific to the proxy subset of global parameters.

Table 5. Proxy parameters
Type Parameter Description Values Default value

Resources

cpu

The amount of CPU resources requested for Envoy proxy.

CPU resources, specified in cores or millicores (for example, 200m, 0.5, 1) based on your environment’s configuration.

10m

memory

The amount of memory requested for Envoy proxy

Available memory in bytes(for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.

1024Mi

Limits

cpu

The maximum amount of CPU resources requested for Envoy proxy.

CPU resources, specified in cores or millicores (for example, 200m, 0.5, 1) based on your environment’s configuration.

2000m

memory

The maximum amount of memory Envoy proxy is permitted to use.

Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.

128Mi

Istio gateway configuration

Here is an example that illustrates the Istio gateway parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example gateway parameters
  gateways:
    egress:
      enabled: true
      runtime:
        deployment:
          autoScaling:
            enabled: true
            maxReplicas: 5
            minReplicas: 1
    enabled: true
    ingress:
      enabled: true
      runtime:
        deployment:
          autoScaling:
            enabled: true
            maxReplicas: 5
            minReplicas: 1
Table 6. Istio Gateway parameters
Parameter Description Values Default value

gateways.egress.runtime.deployment.autoScaling.enabled

This parameter enables/disables autoscaling.

true/false

true

gateways.egress.runtime.deployment.autoScaling.minReplicas

The minimum number of pods to deploy for the egress gateway based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

1

gateways.egress.runtime.deployment.autoScaling.maxReplicas

The maximum number of pods to deploy for the egress gateway based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

5

gateways.ingress.runtime.deployment.autoScaling.enabled

This parameter enables/disables autoscaling.

true/false

true

gateways.ingress.runtime.deployment.autoScaling.minReplicas

The minimum number of pods to deploy for the ingress gateway based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

1

gateways.ingress.runtime.deployment.autoScaling.maxReplicas

The maximum number of pods to deploy for the ingress gateway based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

5

Cluster administrators can refer to Using wildcard routes for instructions on how to enable subdomains.

Istio Mixer configuration

Here is an example that illustrates the Mixer parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example mixer parameters
mixer:
  enabled: true
  policy:
    autoscaleEnabled: false
  telemetry:
    autoscaleEnabled: false
    resources:
    requests:
      cpu: 10m
      memory: 128Mi
      limits:
Table 7. Istio Mixer policy parameters
Parameter Description Values Default value

enabled

This parameter enables/disables Mixer.

true/false

true

autoscaleEnabled

This parameter enables/disables autoscaling. Disable this for small environments.

true/false

true

autoscaleMin

The minimum number of pods to deploy based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

1

autoscaleMax

The maximum number of pods to deploy based on the autoscaleEnabled setting.

A valid number of allocatable pods based on your environment’s configuration.

5

Table 8. Istio Mixer telemetry parameters
Type Parameter Description Values Default

Resources

cpu

The percentage of CPU resources requested for Mixer telemetry.

CPU resources in millicores based on your environment’s configuration.

10m

memory

The amount of memory requested for Mixer telemetry.

Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.

128Mi

Limits

cpu

The maximum percentage of CPU resources Mixer telemetry is permitted to use.

CPU resources in millicores based on your environment’s configuration.

4800m

memory

The maximum amount of memory Mixer telemetry is permitted to use.

Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.

4G

Istio Pilot configuration

You can configure Pilot to schedule or set limits on resource allocation. The following example illustrates the Pilot parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example pilot parameters
spec:
  runtime:
    components:
      pilot:
        deployment:
          autoScaling:
            enabled: true
            minReplicas: 1
            maxReplicas: 5
            targetCPUUtilizationPercentage: 85
        pod:
          tolerations:
          - key: node.kubernetes.io/unreachable
            operator: Exists
            effect: NoExecute
            tolerationSeconds: 60
          affinity:
            podAntiAffinity:
              requiredDuringScheduling:
              - key: istio
                topologyKey: kubernetes.io/hostname
                operator: In
                values:
                - pilot
        container:
          resources:
            limits:
              cpu: 100m
              memory: 128M
Table 9. Istio Pilot parameters
Parameter Description Values Default value

cpu

The percentage of CPU resources requested for Pilot.

CPU resources in millicores based on your environment’s configuration.

10m

memory

The amount of memory requested for Pilot.

Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.

128Mi

autoscaleEnabled

This parameter enables/disables autoscaling. Disable this for small environments.

true/false

true

traceSampling

This value controls how often random sampling occurs. Note: Increase for development or testing.

A valid percentage.

1.0

Configuring Kiali

When the Maistra Operator creates the ServiceMeshControlPlane it also processes the Kiali resource. The Kiali Operator then uses this object when creating Kiali instances.

The default Kiali parameters specified in the ServiceMeshControlPlane are as follows:

Example Kiali parameters
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
    kiali:
      enabled: true
      dashboard:
        viewOnlyMode: false
      ingress:
        enabled: true
Table 10. Kiali parameters
Parameter Description Values Default value
enabled

This parameter enables/disables Kiali. Kiali is enabled by default.

true/false

true

dashboard
   viewOnlyMode

This parameter enables/disables view-only mode for the Kiali console. When view-only mode is enabled, users cannot use the console to make changes to the Maistra.

true/false

false

ingress
   enabled

This parameter enables/disables ingress for Kiali.

true/false

true

Configuring Kiali for Grafana

When you install Kiali and Grafana as part of Maistra Service Mesh the Operator configures the following by default:

  • Grafana is enabled as an external service for Kiali

  • Grafana authorization for the Kiali console

  • Grafana URL for the Kiali console

Kiali can automatically detect the Grafana URL. However if you have a custom Grafana installation that is not easily auto-detectable by Kiali, you must update the URL value in the ServiceMeshControlPlane resource.

Additional Grafana parameters
spec:
  kiali:
    enabled: true
    dashboard:
      viewOnlyMode: false
      grafanaURL:  "https://grafana-istio-system.127.0.0.1.nip.io"
    ingress:
      enabled: true

Configuring Kiali for Jaeger

When you install Kiali and Jaeger as part of Maistra Service Mesh the Operator configures the following by default:

  • Jaeger is enabled as an external service for Kiali

  • Jaeger authorization for the Kiali console

  • Jaeger URL for the Kiali console

Kiali can automatically detect the Jaeger URL. However if you have a custom Jaeger installation that is not easily auto-detectable by Kiali, you must update the URL value in the ServiceMeshControlPlane resource.

Additional Jaeger parameters
spec:
  kiali:
    enabled: true
    dashboard:
      viewOnlyMode: false
      jaegerURL: "http://jaeger-query-istio-system.127.0.0.1.nip.io"
    ingress:
      enabled: true

Configuring Jaeger

When the Maistra Operator creates the ServiceMeshControlPlane resource it also creates the Jaeger resource. The Jaeger Operator then uses this object when creating Jaeger instances.

The default Jaeger parameters specified in the ServiceMeshControlPlane are as follows:

Default all-in-one Jaeger parameters
  apiVersion: maistra.io/v1
  kind: ServiceMeshControlPlane
  spec:
    istio:
      tracing:
        enabled: true
        jaeger:
          template: all-in-one
Table 11. Jaeger parameters
Parameter Description Values Default value
tracing
   enabled

This parameter enables/disables tracing in Maistra. Jaeger is installed by default.

true/false

true

jaeger
   template

This parameter specifies which Jaeger deployment strategy to use.

  • all-in-one- For development, testing, demonstrations, and proof of concept.

  • production-elasticsearch - For production use.

all-in-one

Note

The default template in the ServiceMeshControlPlane resource is the all-in-one deployment strategy which uses in-memory storage. For production, the only supported storage option is Elasticsearch, therefore you must configure the ServiceMeshControlPlane to request the production-elasticsearch template when you deploy Maistra within a production environment.

Configuring Elasticsearch

The default Jaeger deployment strategy uses the all-in-one template so that the installation can be completed using minimal resources. However, because the all-in-one template uses in-memory storage, it is only recommended for development, demo, or testing purposes and should NOT be used for production environments.

If you are deploying Maistra and Jaeger in a production environment you must change the template to the production-elasticsearch template, which uses Elasticsearch for Jaeger’s storage needs.

Elasticsearch is a memory intensive application. The initial set of nodes specified in the default OpenShift Container Platform installation may not be large enough to support the Elasticsearch cluster. You should modify the default Elasticsearch configuration to match your use case and the resources you have requested for your OpenShift Container Platform installation. You can adjust both the CPU and memory limits for each component by modifying the resources block with valid CPU and memory values. Additional nodes must be added to the cluster if you want to run with the recommended amount (or more) of memory. Ensure that you do not exceed the resources requested for your OpenShift Container Platform installation.

Default "production" Jaeger parameters with Elasticsearch
  apiVersion: maistra.io/v1
  kind: ServiceMeshControlPlane
  spec:
    istio:
      tracing:
      enabled: true
      ingress:
        enabled: true
      jaeger:
        template: production-elasticsearch
        elasticsearch:
          nodeCount: 3
          redundancyPolicy:
          resources:
            requests:
              cpu: "1"
              memory: "16Gi"
            limits:
              cpu: "1"
              memory: "16Gi"
Table 12. Elasticsearch parameters
Parameter Description Values Default Value Examples
tracing:
  enabled

This parameter enables/disables tracing in Maistra. Jaeger is installed by default.

true/false

true

ingress:
  enabled

This parameter enables/disables ingress for Jaeger.

true/false

true

jaeger
   template

This parameter specifies which Jaeger deployment strategy to use.

all-in-one/production-elasticsearch

all-in-one

elasticsearch:
  nodeCount

Number of Elasticsearch nodes to create.

Integer value.

1

Proof of concept = 1, Minimum deployment =3

requests:
  cpu

Number of central processing units for requests, based on your environment’s configuration.

Specified in cores or millicores (for example, 200m, 0.5, 1).

1Gi

Proof of concept = 500m, Minimum deployment =1

requests:
  memory

Available memory for requests, based on your environment’s configuration.

Specified in bytes (for example, 200Ki, 50Mi, 5Gi).

500m

Proof of concept = 1Gi, Minimum deployment = 16Gi*

limits:
  cpu

Limit on number of central processing units, based on your environment’s configuration.

Specified in cores or millicores (for example, 200m, 0.5, 1).

Proof of concept = 500m, Minimum deployment =1

limits:
  memory

Available memory limit based on your environment’s configuration.

Specified in bytes (for example, 200Ki, 50Mi, 5Gi).

Proof of concept = 1Gi, Minimum deployment = 16Gi*

* Each Elasticsearch node can operate with a lower memory setting though this is not recommended for production deployments. For production use, you should have no less than 16Gi allocated to each pod by default, but preferably allocate as much as you can, up to 64Gi per pod.

Procedure
  1. Log in to the OpenShift Container Platform web console as a user with the cluster-admin role.

  2. Navigate to OperatorsInstalled Operators.

  3. Click the Maistra Service Mesh Operator.

  4. Click the Istio Service Mesh Control Plane tab.

  5. Click the name of your control plane file, for example, basic-install.

  6. Click the YAML tab.

  7. Edit the Jaeger parameters, replacing the default all-in-one template with parameters for the production-elasticsearch template, modified for your use case. Ensure that the indentation is correct.

  8. Click Save.

  9. Click Reload. OpenShift Container Platform redeploys Jaeger and creates the Elasticsearch resources based on the specified parameters.

Configuring the Elasticsearch index cleaner job

When the Maistra Operator creates the ServiceMeshControlPlane it also creates the custom resource (CR) for Jaeger. The Jaeger operator then uses this CR when creating Jaeger instances.

When using Elasticsearch storage, by default a job is created to clean old traces from it. To configure the options for this job, you edit the Jaeger custom resource (CR), to customize it for your use case. The relevant options are listed below.

  apiVersion: jaegertracing.io/v1
  kind: Jaeger
  spec:
    strategy: production
    storage:
      type: elasticsearch
      esIndexCleaner:
        enabled: false
        numberOfDays: 7
        schedule: "55 23 * * *"
Table 13. Elasticsearch index cleaner parameters
Parameter Values Description

enabled

true/ false

Enable or disable the index cleaner job.

numberOfDays

integer value

Number of days to wait before deleting an index.

schedule

"55 23 * * *"

Cron expression for the job to run

For more information about configuring Elasticsearch with OpenShift Container Platform, see Configuring the log store.

3scale configuration

Here is an example that illustrates the 3scale Istio Adapter parameters for the Maistra Service Mesh custom resource and a description of the available parameters with appropriate values.

Example 3scale parameters
threeScale:
  enabled: false
  PARAM_THREESCALE_LISTEN_ADDR: 3333
  PARAM_THREESCALE_LOG_LEVEL: info
  PARAM_THREESCALE_LOG_JSON: true
  PARAM_THREESCALE_LOG_GRPC: false
  PARAM_THREESCALE_REPORT_METRICS: true
  PARAM_THREESCALE_METRICS_PORT: 8080
  PARAM_THREESCALE_CACHE_TTL_SECONDS: 300
  PARAM_THREESCALE_CACHE_REFRESH_SECONDS: 180
  PARAM_THREESCALE_CACHE_ENTRIES_MAX: 1000
  PARAM_THREESCALE_CACHE_REFRESH_RETRIES: 1
  PARAM_THREESCALE_ALLOW_INSECURE_CONN: false
  PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS: 10
  PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS: 60
  PARAM_USE_CACHED_BACKEND: false
  PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS: 15
  PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED: true
Table 14. 3scale parameters
Parameter Description Values Default value

enabled

Whether to use the 3scale adapter

true/false

false

PARAM_THREESCALE_LISTEN_ADDR

Sets the listen address for the gRPC server

Valid port number

3333

PARAM_THREESCALE_LOG_LEVEL

Sets the minimum log output level.

debug, info, warn, error, or none

info

PARAM_THREESCALE_LOG_JSON

Controls whether the log is formatted as JSON

true/false

true

PARAM_THREESCALE_LOG_GRPC

Controls whether the log contains gRPC info

true/false

true

PARAM_THREESCALE_REPORT_METRICS

Controls whether 3scale system and backend metrics are collected and reported to Prometheus

true/false

true

PARAM_THREESCALE_METRICS_PORT

Sets the port that the 3scale /metrics endpoint can be scrapped from

Valid port number

8080

PARAM_THREESCALE_CACHE_TTL_SECONDS

Time period, in seconds, to wait before purging expired items from the cache

Time period in seconds

300

PARAM_THREESCALE_CACHE_REFRESH_SECONDS

Time period before expiry when cache elements are attempted to be refreshed

Time period in seconds

180

PARAM_THREESCALE_CACHE_ENTRIES_MAX

Max number of items that can be stored in the cache at any time. Set to 0 to disable caching

Valid number

1000

PARAM_THREESCALE_CACHE_REFRESH_RETRIES

The number of times unreachable hosts are retried during a cache update loop

Valid number

1

PARAM_THREESCALE_ALLOW_INSECURE_CONN

Allow to skip certificate verification when calling 3scale APIs. Enabling this is not recommended.

true/false

false

PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS

Sets the number of seconds to wait before terminating requests to 3scale System and Backend

Time period in seconds

10

PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS

Sets the maximum amount of seconds (+/-10% jitter) a connection may exist before it is closed

Time period in seconds

60

PARAM_USE_CACHE_BACKEND

If true, attempt to create an in-memory apisonator cache for authorization requests

true/false

false

PARAM_BACKEND_CACHE_FLUSH_INTERVAL_SECONDS

If the backend cache is enabled, this sets the interval in seconds for flushing the cache against 3scale

Time period in seconds

15

PARAM_BACKEND_CACHE_POLICY_FAIL_CLOSED

Whenever the backend cache cannot retrieve authorization data, whether to deny (closed) or allow (open) requests

true/false

true