Install

Prerequisites Copied

The following must be installed before installing the Centralised Config app:

The following are the Geneos component requirements:

Install Copied

Caution

Before upgrading to Centralised Config 2.1.0, you must first uninstall all Obcerv apps. Due to a breaking change in a core library (Spring Boot), you need to upgrade all Obcerv apps at the same time. Make sure that you reinstall the latest mutually compatible versions of Obcerv apps. See the Obcerv Compatibility Matrix.

To install the Centralised Config app, you must first create a Helm values file with the appropriate configuration parameters for your environment.

Create a file, such as centralised-config.yaml with content similar to the following:

ingress:
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.org/mergeable-ingress-type: "minion"

Your ingress controller may require custom annotations on the ingress (this example is for ingress-nginx)

The app uses a PVC to store Gateway archives and binaries used when validating Gateway setup. The PVC is not removed during uninstall to prevent the loss of the binaries when reinstalling the app (which supports changing a configuration option or upgrading). To configure the PVC, add the following parameters to the Helm values file:

daemon:
  persistence:
    size: "5Gi"
#  storageClass: ""

Note

Setting the storage class (storageClass) to an empty string will dynamically provision the volume and subsequent re-installs/upgrades of the app will require the value to be set to the dynamically-assigned storage class name. Leaving the option out (default) will cause the storage class to be dynamically assigned and subsequent re-installs/upgrades may continue to omit this parameter.

Install using Helm:

helm install -f centralised-config.yaml obcerv-app-centralised-config \
itrs/obcerv-app-centralised-config \
--version 2.1.0 -n <namespace> --wait

Uninstall Copied 

helm uninstall obcerv-app-centralised-config -n <namespace>

Upgrade Copied

To upgrade the app, first uninstall and then install it again using the new version.

Performance tuning Copied

The app consists of three deployments:

Defaults Copied

By default, the deployments have the following resource requests and limits:

UI Daemon REST Server Total
CPU Request 200m 1 100m 1300m
CPU Limit 1 2 300m 3300m
Memory Request 256MiB 512MiB 128MiB 996MiB
Memory Limit 1GiB 2GiB 256MiB 2304MiB

You can verify the current resource requests or limits of your deployment by running the following command:

Note

Running the command requires jq. 
kubectl get pod -n <namespace> \
-l app.kubernetes.io/instance=obcerv-app-centralised-config \
-o json | jq -r \
"[.items[] | \
  { \
    pod: .metadata.name, containers: .spec.containers[]  | \
    [ \
      { \
        container: .name, \
        resources: .resources \
      } \
    ] \
  } \
]"

The only CPU-intensive task performed by the app is Gateway validation, which is done by the obcerv-app-centralised-config-daemon deployment. It involves running a Gateway binary to validate a full Gateway setup.

For example, if the contents of a common include file used by 50 Gateways are modified as part of a setup change, then the app will validate the modified common include against all 50 Gateways that use it. With the default configuration, each validation should take approximately 80–100ms given the node has enough CPU headroom to allocate all 2 CPU cores to it.

Validations are performed in parallel and the number of validator threads can be set through the following parameter:

daemon:
  numValidatorThreads: 3

Validation performance can be tuned by increasing the CPU request or limit of the obcerv-app-centralised-config-daemon deployment and setting the numValidatorThreads to the ceiling of the new CPU core limit. For example, if you set the limit to 4500m, then numValidatorThreads should be set to 5.

Advanced configuration Copied

The app can be configured with the values shown below. You are not required to change any of these configuration options unless advised to do so by ITRS.

grpcCompression:
  # Enables gRPC compression between the REST Server and the app's backend daemon.
  enabled: true

# The maximum amount of time to wait for gRPC calls to complete, expressed as an ISO-8601 duration.
grpcTimeout: "PT30S"

grpcLogging:
  # Enables gRPC request logging.
  enabled: false
  # Enables logging of gRPC responses
  responses: false

###################################
# Backend gRPC Daemon Configuration
###################################
daemon:
  # The daemon's log level
  logLevel: INFO

  # PVC settings for storage and caching of Gateway archives and binaries
  # used for Gateway validation.
  persistence:
    accessMode: "ReadWriteOnce"
    size: "5Gi"
  #  storageClass: ""

  # The maximum amount of time a Gateway validation can take before being aborted by the app,
  # expressed as an ISO-8601 duration.
  gatewayValidationTimeout: "PT30S"

  # The number of Gateway validation threads. Increasing this number can increase the number of
  # validations that can occur in parallel. However, it may have a negative impact on performance
  # if the app's allocated CPU resources are not sufficient, and it is being throttled by Kubernetes.
  # Increase this parameter only if the CPU utilisation of the daemon's pod is not close to its limit.
  numValidatorThreads: 3

  # The app holds a cache of current and recent validations in order to avoid constantly interrogating
  # the Obcerv Platform for its state. The purpose of the cache is to cover the most common use case
  # when a user validates and saves the validated changes shortly after.
  validationCache:
    # How long to wait before evicting validations that have been created but not read after
    # completion. This could happen if the client application unexpectedly terminated.
    expireAfterCreate: "PT1H"
    # How long to wait before evicting completed validations after they have been read for the last
    # time. This timer resets every time a validation has been read after completion. The purpose of
    # this setting is to accommodate the most common use case which is to perform a setup change
    # shortly after a validation is completed.
    expireAfterRead: "PT5M"

  # The max inbound gRPC message size. Entries from the Obcerv Platform that are returned to the app
  # in batches may exceed the default gRPC inbound message size. Increase this if the app backend
  # logs or returns gRPC exceptions with status RESOURCE_EXHAUSTED.
  # !! Note: The value must be quoted to prevent it from being converted to scientific notation
  # !!       by the YAML parser.
  maxInboundGrpcMessageSizeBytes: "20971520" # 20MiB

  # How often to poll for Gateway archives that have been copied into the pod.
  gatewayArchivesPollInterval: "PT5S"

###########################
# REST Server Configuration
###########################
restServer:
  # The REST server's log level.
  logLevel: INFO

  # Logs all REST API requests. This has a negative impact on the performance 
  # of the server and should only be used to diagnose an issue.
  requestLogging: false

  # The maximum request entity size
  # !! Note: The value must be quoted to prevent it from being converted to scientific notation
  # !!       by the YAML parser.
  maxMessageSizeBytes: "10485760" # 10 MiB
["Obcerv"] ["Obcerv > Centralised Config"] ["Technical Reference"]

Was this topic helpful?