Deploying Container Observability shared services

The global section sets values that apply across all shared-services components, including the Global View endpoint and the platform shared services that CO uses.

global:
  environment: "app"
  machine_type: "small" 
  secret_source: "valuesfile" 
  dockerRegistryCredentials: 
    DOCKER_SERVER: "https://index.docker.io/v2/"
    DOCKER_USERNAME: "username"
    DOCKER_PASSWORD: "password"

  controlplane:
    endpoint: <GV-HOSTNAME>
  envoy:
    enabled: false
  platform_shared_services:
    namespace: platform-shared-services
    cp_metric:
      service:
        enabled: true
    kafka:
      service:
        enabled: true
    configevent:
      service:
        enabled: true
    victoriametrics:
      service:
        enabled: true
    cassandra:
      service:
        enabled: true
    logs:
      service:
        enabled: true
    logs_data_receiver:
      service:
        enabled: true

The following table describes each field of above YAML file:

Configure resource allocations, persistence, and scaling parameters for the core shared infrastructure components: Cassandra Shared, Platform Kafka Service, and Container Observability Configuration & Events Service.

Add the following configuration block in your shared services values file:

cassandra-shared:
  replicaCount: 6
  persistence:
    enabled: true
    storageClass: ""  
    size: 100Gi
  resources:
    requests:
      cpu: 2
      memory: 16Gi
    limits:
      cpu: 2
      memory: 16Gi
  cassandra:
    heap_maxsize: "12G"
    heap_newsize: "2400M"

platform-kafka-service:
  controller:
    replicaCount: 3
    persistence:
      size: 50Gi
    resources:
      requests:
        cpu: 200m
        memory: 2Gi
      limits:
        cpu: 1
        memory: 2Gi
    kafka:
      listener:
        type: loadbalancer

co-config-events-service-shared:
  solr:
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: 2
        memory: 4Gi
    persistence:
      size: 50Gi
    zookeeper:
      persistence:
        size: 8Gi
      resources:
        requests:
          cpu: 250m
          memory: 512Mi
        limits:
          cpu: 500m
          memory: 2Gi

The following table describes each field of the above YAML file:

This section configures the metrics service behavior (Kafka listener concurrency) and auto-scaling. It also defines a shared nodeSelector anchor you can reuse.

cp-metrics-service:
  global:
    nodeSelector: &nodeSelector {}
  env:
    KAFKA_LISTENER_CONCURRENCY: "2"
  horizontalPodAutoscaler:
    enabled: true
    maxReplicas: 5
    minReplicas: 2

The following table describes each field of above YAML file:

This section configures VictoriaMetrics cluster following components:

Each component supports scheduling controls and autoscaling where applicable.

victoria-metrics-cluster:
  vmstorage:
    replicaCount: 4
    retentionPeriod: 1
    persistentVolume:
      storageClassName: ""
      size: 100Gi
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi
    nodeSelector: {}
    tolerations: []
  vmselect:
    horizontalPodAutoscaler:
      minReplicas: 2
      maxReplicas: 10
    nodeSelector: {}
    tolerations: []
  vminsert:
    horizontalPodAutoscaler:
      minReplicas: 2
      maxReplicas: 10
    nodeSelector: {}
    tolerations: []
platform-logs-service:
  loki:
    loki:
      limits_config:
        retention_period: 168h
    minio:
      persistence:
        enabled: true
        size: 250Gi

The following table describes each field of above YAML file:

To migrate existing log data from an earlier Loki deployment to the Platform Logs Service, the log reader requires explicit mapping between your tenant IDs and their corresponding Kubernetes namespaces. Configuring this file ensures that the platform-logs-service can locate, read, and attribute historical log streams correctly across tenants and environments during and after the migration.

Create a new file named loki-migration.yaml and add the following configuration, and replace the placeholder values with your actual environment details:

platform-logs-service:
  log_reader:
    loki:
      migration:
        tenants:
          # Env: <ENVIRONMENT_NAME> # Tenant alias: <TENANT_ALIAS>
          <TENANT_UUID>: 
            namespaces:
              self-monitoring: <SELF_MONITORING_NAMESPACE> 
              co-dev-01: <CO_NAMESPACE>                   

The following table describes each field of the above YAML file:

Update the Helm repository in your terminal and list available versions of the controller chart:

helm repo update
helm search repo virtana-repo/virtana-co-controller

To list all available chart versions instead of only the latest version, add the --versions flag to the helm search repo command. Choose the deployment tag for your release that enables the CO shared-services components, depending on the virtana-co-controller chart version that you deploy. Starting with release 2026.6.1, the tag changed from tags.oc_shared_services to tags.platform. The chart version is the same as the release number. Use --set tags.platform=true (with --skip-crds) in place of --set tags.oc_shared_services=true in the following deploy commands. Update any deployment that still uses the previous tag. For example, chart version 2026.6.1 belongs to release 2026.6.1.

The following table lists the deployment tag for each release:

You can add this as an optional setting in your terminal if your cluster cannot pull images from the default public registry locations.

Add the following command to app-mon-shared-services-values.yaml and replace the example.io with your registry:

cp-metrics-service:
  image:
    registry: example.io

oc-shared-kafka:
  image:
    registry: example.io
    repository: kafka

victoria-metrics-cluster:
  vminsert:
    image:
      repository: example.io/vminsert
  vmselect:
    image:
      repository: example.io/vmselect
  vmstorage:
    image:
      repository: example.io/vmstorage

On Red Hat OpenShift, set the security contexts for the shared-services components so that they run within the UID, GID, and fsGroup range that OpenShift allows for the namespace. Create a file named app-mon-shared-services-scc.yaml with the security contexts, and add it to the Helm deploy command.

First, find the allowed UID, GID, and supplemental-group range for the namespace:

oc describe ns oc-shared-services | egrep "uid-range|supplemental-groups"

The runAsUser, runAsGroup, and fsGroup values you set must fall within the range that this command reports. Set the security contexts in app-mon-shared-services-scc.yaml:

cassandra-shared:
  securityContext:
    pod:
      runAsUser: <user_id>
      runAsGroup: <group_id>
      fsGroup: <fsgroup_id>

platform-kafka-service:
  podSecurityContext:
    fsGroup: <fsgroup_id>
  securityContext:
    runAsUser: <user_id>
    runAsGroup: <group_id>
  strimzi-kafka-operator:
    podSecurityContext:
      fsGroup: <fsgroup_id>
    securityContext:
      runAsGroup: <group_id>
      runAsUser: <user_id>

co-config-events-service-shared:
    podSecurityContext:
      fsGroup: <fsgroup_id>
    securityContext:
      runAsGroup: <group_id>
      runAsUser: <user_id>
    zookeeper:
      podSecurityContext:
        fsGroup: <fsgroup_id>
      securityContext:
        runAsGroup: <group_id>
        runAsUser: <user_id>

The Helm chart overrides assign a Kubernetes security context to each platform service and its sub-components. The same set of parameters recurs across the services, applied at either the pod level or the container level. The following table describes each parameter, the level at which it applies, and the value it takes.