dSSM Database¶

The Cloud-Native Network Functions (CNFs) distributed Session State Management (dSSM) Pods provide centralized and persistent storage for the Traffic Management Microkernel (TMM) Proxy Pods. The dSSM Pods are Redis data structure stores that maintain application traffic data such as DNS/NAT46 translation mappings. The dSSM Pods bind to Kubernetes persistence volumes to persist data in the event of a container restart.

dSSM supports two deployment modes:

Sentinel mode (default) — A primary/replica model using Sentinel Pods for monitoring and failover. This is the default deployment mode.
Cluster mode — A sharded model that distributes data across multiple primary database Pods for horizontal scaling.

This document describes the dSSM Pods, and guides you through configuring and installing the f5-dssm-sentinel and f5-dssm-db containers.

Note: To upgrade the dSSM databases and preserve all persisted data, review the Upgrading dSSM guide.

Deployment modes¶

Sentinel mode (default)¶

The dSSM Pods integrate as a StatefulSet, containing three dSSM Sentinel Pods and three dSSM DB Pods to maintain high availability. The Sentinel Pods elect and monitor a primary dSSM DB Pod, and if the primary dSSM DB Pod fails, a secondary DB will assume the primary role.

In Sentinel mode, all TMM instances connect to the single primary DB Pod through the Sentinel service. This mode works well for deployments with moderate session data requirements.

Component	Count
Sentinel Pods	3
DB Pods (1 primary, 2 replicas)	3
Total Pods	6

Cluster mode¶

Cluster mode distributes session data across multiple primary DB Pods called shards. Each shard handles a portion of the data, which lets dSSM process requests in parallel. The Redis cluster manages failovers without Sentinel Pods.

When you enable cluster mode, the system creates multiple shards with replicas for each. By default, the cluster creates:

Parameter	Default value
Number of shards (primary pods)	3
Replicas per shard	2
Database port	6379

Note

Sentinel Pods are not created in cluster mode. The Redis cluster manages failovers without Sentinel Pods.
Once clustering mode has been installed, changing the shardCount at a later stage requires uninstalling DSSM, deleting the persistent volume claims (PVCs), and reinstalling DSSM. This process will result in data loss.

When to use cluster mode

Consider enabling cluster mode when:

Your deployment includes a large number of TMM instances sharing a single dSSM
The single primary database pod shows signs of resource saturation
You need to scale session data storage horizontally

How data is distributed

Each shard owns a range of hash slots from 0 to 16,383. When TMM performs an operation on a key, it calculates CRC16(key) mod 16384 to determine which shard owns the key. All operations for a given key always route to the same shard.

To keep related keys on the same shard, TMM prepends a hash tag in the format {tag} to keys. Redis uses only the tag portion for slot calculation. This ensures that a primary key and its associated subkeys are stored together. The hash tag is removed before the key is returned to the application.

Automatic failover

The Redis cluster manages failovers without Sentinel pods. If a primary shard becomes unavailable, the cluster promotes one of its replicas to primary. TMM detects the change and reconnects to the new primary.

Additional high availability¶

The dSSM Pods also use the standard Kubernetes node affinity and PodDisruptionBudget features to maintain additional levels of high availability.

Affinity

Each dSSM Sentinel and DB Pod schedules onto a unique cluster node by default. The dSSM scheduling behavior can be modified using the dSSM Helm affinity_type parameter:

Setting	Description
required	Ensures the target cluster node does not currently host a Pod with the `app=f5-dssm-db` annotation (default).
preferred	Attempt to schedule Pods onto unique nodes, but two dSSM Pods may schedule onto a single node when no schedulable nodes exists.
custom	Scheduling behavior may be tuned specifically to the cluster admins requirements using the dSSM `values.yaml` file.

Helm parameter examples:

sentinel:
  affinity_type: "required"

db:
  affinity_type: "required"

Kubernetes Assigning Pods overview.

PodDisruptionBudget

A minimum of 2 dSSM Pods remain available at all times based on the dSSM Helm pod_disruption_budget parameter. This parameter blocks voluntary interruptions to the dSSM Pod’s Running status. For example, if three schedulable nodes are available, and the admin runs oc adm drain on two of nodes in quick succession, the second action will be blocked until another schedulable node is added to the cluster.

Helm parameter examples:

sentinel:
  pod_disruption_budget:
    min_available: 2

db:
  pod_disruption_budget:
    min_available: 2

Kubernetes Disruptions overview.

Cluster mode

In cluster mode, the Helm chart applies pod anti-affinity rules so that the primary and replica Pods within each shard are deployed on different nodes when possible. This provides node-failure redundancy: if a worker node goes down, the replicas on other nodes can still take over.

Note

In cluster mode:

The affinity_type preferred is recommended unless you have enough nodes available to satisfy the required pod distribution. If the number of available nodes matches or exceeds the total number of database pods (shardCount × (clusterReplicaCount + 1)), you can use affinity_type required.
The default podManagementPolicy is set to Parallel, which means all database pods in the StatefulSet start simultaneously rather than one at a time. This speeds up cluster formation during installation and recovery.

Services¶

Sentinel Service¶

After installing dSSM, a dSSM Sentinel Service is created that receives data from TMM on TCP service port 26379, and forwards to the dSSM DB Pods using the same service port number. Ensure the Service port is available, and the cluster has CoreDNS enabled. In this example, the CNFs components will need to resolve the f5-dssm-sentinel.cnf-gateway hostname.

Example dSSM Service:

Name:              f5-dssm-sentinel
Namespace:         cnf-gateway
IP:                10.106.99.127
Port:              sentinel  26379/TCP
Endpoints:         10.244.1.15:26379,10.244.1.20:26379,10.244.4.3:26379

Note

The Sentinel Service is not created in cluster mode.

DB Service¶

After installing dSSM, a dSSM DB Service is created on the default port 6379. In Sentinel mode, the DB Service is created alongside the Sentinel Service. In cluster mode, the DB Service is the only service created. TMM connects to the DB Service to discover the full list of shards and then establishes direct connections to each shard.

Example dSSM DB Service:

Name:              f5-dssm-db
Namespace:         cnf-gateway
Port:              db  6379/TCP

Resources Management¶

For both Sentinel and cluster mode, the dSSM pods uses standard Kubernetes requests and limits parameters to manage container CPU and memory resources for the f5-dssm container. By default, each Pod allocates the following resources:

Pod/Container	Memory	CPU
f5-dssm-db/f5-dssm	512 Mi	1
f5-dssm-sentinel/f5-dssm (Sentinel mode only)	128 Mi	.5

In cluster mode, the total resource consumption depends on the number of shards and replicas you configure:

Total resources = shardCount × (1 + clusterReplicaCount) × resources_per_pod

For example, the default cluster configuration (3 shards, 2 replicas each) creates 9 DB Pods, each consuming 512 Mi memory and 1 CPU, for a total of 4,608 Mi memory and 9 CPU.

Requirements¶

Ensure you have:

Installed the CNFs software.
Installed the CNFs Cert Manager.
A workstation with OpenSSL and Helm installed.

Install dSSM in Sentinel mode¶

Use the following steps to install the dSSM DB and Sentinel Pods.

Change into the directory containing the latest CNFs Software, and obtain the f5-dssm Helm chart version:

In this example, the CNFs files are in the cnfinstall directory:
```
cd cnfinstall
```
```
ls -1 tar | grep f5-dssm
```
The example output should appear similar to the following:
```
f5-dssm-1.46.0-0.24.0.tgz
```
If you haven’t already, create a new Project for the CNFs Pods using the following command syntax:
```
oc create ns <project name>
```
In this example, a new Project named cnf-gateway is created:
```
oc create ns cnf-gateway
```

Optional: If you want to use node-local storage for dSSM pods to persist data even if the node restarts or fails, see the Set Up Node-Local Storage for dSSM section.

Create a Helm values file named dssm-values.yaml, and set the image.repository parameters:

In this example, Helm pulls the f5-dssm-store images from registry.com:

image:
  repository: registry.com

sentinel:
  fluentbit_sidecar:
    image:
      repository: registry.com

db:
  fluentbit_sidecar:
    image:
      repository: registry.com

cert_client_sidecar:
  image:
    repository: registry.com

Required: If you deployed the Fluentd Logging Pod, you can send logging data to the f5-fluentd container by adding the fluentd.host parameters to the values file:

sentinel:
  fluentbit_sidecar:
    fluentd:
      host: '<fluentd hostname>'

db:
  fluentbit_sidecar:
    fluentd:
      host: '<fluentd hostname>'

In this example, the Fluentd container is deployed to the cnf-gateway namespace:

sentinel:
  fluentbit_sidecar:
    fluentd:
      host: 'f5-toda-fluentd.cnf-gateway.svc.cluster.local.'

db:
  fluentbit_sidecar:
    fluentd:
      host: 'f5-toda-fluentd.cnf-gateway.svc.cluster.local.'

Install the dSSM Pods using the following command syntax:

helm install <release> tar/<helm-chart>.tgz \
-f <values>.yaml -n <namespace>

For example:

helm install f5-dssm tar/f5-dssm-1.46.0-0.24.0.tgz \
-f dssm-values.yaml -n cnf-gateway

All dSSM Pods will be available after the election process, which can take up to a minute.

Important: DB entries may fail to be created during the election process if TMM installs prior to completion. TMM will connect after the process completes.

oc get pods -n cnf-gateway

In this example, the dSSM Pods in the cnf-gateway namespace have completed the election process, and the Pod STATUS is Running:

NAME                              READY   STATUS   
f5-dssm-db-0                      3/3     Running   
f5-dssm-db-1                      3/3     Running   
f5-dssm-db-2                      3/3     Running   
f5-dssm-sentinel-0                3/3     Running   
f5-dssm-sentinel-1                3/3     Running   
f5-dssm-sentinel-2                3/3     Running  

The dSSM DB Pods should be bound to the persistent volumes:

oc get pvc -n cnf-gateway

In this example, the dSSM Pod’s PVC STATUS is Bound:

NAME                STATUS   VOLUME                                     
data-f5-dssm-db-0   Bound    pvc-c7060354-64d2-456b-9328-aa38f19b44b5   
data-f5-dssm-db-1   Bound    pvc-8358b993-bf21-4fd7-a0fa-ee84ec420aac  
data-f5-dssm-db-2   Bound    pvc-de65ed0f-f616-4021-a158-e0e78ed4539e   

To securely connect the TMM and dSSM Pods, the CNFs Controller Helm values file requires the following paramaters:

Important: Set the SESSIONDB_EXTERNAL_SERVICE parameter to the namespace of the dSSM Pod. In this example, cnf-utilities.

tmm:
  sessiondb:
    useExternalStorage: "true"

  customEnvVars:
   - name: SESSIONDB_DISCOVERY_SENTINEL
     value: "true"
   - name: SESSIONDB_EXTERNAL_SERVICE
     value: "f5-dssm-sentinel.cnf-gateway"
   - name: SSL_SERVERSIDE_STORE
     value: "/tls/tmm/mds/clt"
   - name: SSL_TRUSTED_CA_STORE
     value: "/tls/tmm/mds/clt"

Once the CNFs Controller has installed, verify connectivity between the dSSM and TMM Pods:

oc logs f5-tmm-bcfd54cb9-tfqqv -c f5-tmm -n cnf-gateway | grep 'server successful'

In this example, the dSSM and TMM Pods have successfully connected.

Feb 04 21:24:41.193114 tmm[36]: redis_sentinel_connected/1004: Connection establishment with REDIS SENTINEL server successful

Install dSSM in cluster mode¶

This section explains how to enable Distributed Session State Manager (dSSM) cluster mode for F5 BIG-IP Next CNF deployments. Cluster mode distributes session data across multiple shards for improved scalability.

By default, dSSM deploys in Sentinel mode. Follow these steps to enable cluster mode during installation.

Before you begin¶

Before you enable dSSM cluster mode, verify the following:

You are performing a new installation. Upgrading from an existing Sentinel-based deployment to cluster mode is not supported in this release.
Your Kubernetes cluster has enough nodes to distribute the database pods. For node-failure redundancy, the primary and replica pods in each shard are placed on different nodes when possible. The preferable number of nodes should match the number of shards.
You have reviewed the resource requirements. Each database pod in cluster mode uses the same amount of CPU and memory as a database pod in Sentinel mode. The total resources required depend on the number of shards and replicas you configure.

Default cluster configuration¶

Parameter	Default value
Number of shards (primary pods)	3
Replicas per shard	2
Database port	6379
Sentinel pods	0 (not created in cluster mode)

Enable cluster mode using Helm¶

Change into the directory containing the latest CNFs Software, and obtain the f5-dssm Helm chart version:

In this example, the CNFs files are in the cnfinstall directory:
```
cd cnfinstall
```
```
ls -1 tar | grep f5-dssm
```
The example output should appear similar to the following:
```
f5-dssm-1.46.0-0.24.0.tgz
```
If you haven’t already, create a new Project for the CNFs Pods using the following command syntax:
```
oc create ns <project name>
```
In this example, a new Project named cnf-gateway is created:
```
oc create ns cnf-gateway
```
Optional: If you want to use node-local storage for dSSM pods to persist data even if the node restarts or fails, see the Set Up Node-Local Storage for dSSM section.

Create a Helm values file named dssm-values.yaml, and set the image.repository parameters:

In this example, Helm pulls the f5-dssm-store images from registry.com:

image:
  repository: registry.com

sentinel:
  fluentbit_sidecar:
    image:
      repository: registry.com

db:
  fluentbit_sidecar:
    image:
      repository: registry.com

cert_client_sidecar:
  image:
    repository: registry.com

Set the cluster mode feature flag to enable clustering:

  clustering:
    enabled: true
    shardCount: 3
    clusterReplicaCount: 2

(Optional) Adjust the number of shards and replicas per shard based on your scaling requirements. The minimum number of shards is three, and each shard must have at least one replica.

Note

When enabling cluster mode, ensure that the pod count aligns with the required value: shardCount * (clusterReplicaCount + 1) when scaling up or down. In environments with PVCs enabled, after scaling down, ensure all volume attachments associated with the scaled-down database pods have been removed before scaling up again. This will prevent Multi-Attach errors.

Required: If you deployed the Fluentd Logging Pod, you can send logging data to the f5-fluentd container by adding the fluentd.host parameters to the values file:

sentinel:
  fluentbit_sidecar:
    fluentd:
      host: '<fluentd hostname>'

db:
  fluentbit_sidecar:
    fluentd:
      host: '<fluentd hostname>'

In this example, the Fluentd container is deployed to the cnf-gateway namespace:

sentinel:
  fluentbit_sidecar:
    fluentd:
      host: 'f5-toda-fluentd.cnf-gateway.svc.cluster.local.'

db:
  fluentbit_sidecar:
    fluentd:
      host: 'f5-toda-fluentd.cnf-gateway.svc.cluster.local.'

Install the dSSM Pods using the following command syntax:

helm install <release> tar/<helm-chart>.tgz \
-f <values>.yaml -n <namespace>

For example:

helm install f5-dssm tar/f5-dssm-1.46.0-0.24.0.tgz \
-f dssm-values.yaml -n cnf-gateway

Verify that all database pods are running and the cluster has formed:

oc get pods -n cnf-gateway

Note

In clustering mode, no sentinel pods will be deployed. The total number of database pods will be calculated as: shardCount × (clusterReplicaCount + 1).

In this example, the database pods are running.

oc get pods -n cnf-gateway

Sample output:

NAME                                          READY    STATUS   
dssm-f5-dssm-db-0                             2/2     Running   
dssm-f5-dssm-db-1                             2/2     Running   
dssm-f5-dssm-db-2                             2/2     Running   
dssm-f5-dssm-db-3                             2/2     Running   
dssm-f5-dssm-db-4                             2/2     Running   
dssm-f5-dssm-db-5                             2/2     Running   
dssm-f5-dssm-db-6                             2/2     Running   
dssm-f5-dssm-db-7                             2/2     Running   
dssm-f5-dssm-db-8                             2/2     Running   
dssm-f5-dssm-db-9                             2/2     Running

In this example, the persistent volume claims are bound.

oc get pvc -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,VOLUME:.spec.volumeName | grep -E '^NAME|data-f5-dssm-db'

Sample output:

NAME                      STATUS   VOLUME
data-f5-dssm-db-0         Bound    pvc-8576e455-843b-405e-9f6e-6b669d45a1af
data-f5-dssm-db-1         Bound    pvc-c91b0779-d9bb-499d-a973-c89d4dce2e00
data-f5-dssm-db-2         Bound    pvc-f0edf321-2cad-4287-8cad-b00293e61076
data-f5-dssm-db-3         Bound    pvc-2a2663bc-2424-4efe-b7e0-1e6d3337ad6a
data-f5-dssm-db-4         Bound    pvc-1d4a10f3-3df3-41cc-9a00-9f1312537b0b
data-f5-dssm-db-5         Bound    pvc-42c83c7e-25c5-46e2-a68c-02516afcebc4
data-f5-dssm-db-6         Bound    pvc-818bb72c-e44a-4301-8438-c959271ff55f
data-f5-dssm-db-7         Bound    pvc-57789cad-8ae7-4f46-9c07-c2faa746e49e
data-f5-dssm-db-8         Bound    pvc-e3040f5a-ce75-4688-84e2-bb8d765f1d17

In this example, the Redis cluster information is retrieved from the first database pod.

oc exec dssm-f5-dssm-db-0 -- redis-cli -p 6379 --tls   --cacert /tls/dssm/mds/svr/ca.crt --cert /tls/dssm/mds/svr/tls.crt   --key /tls/dssm/mds/svr/tls.key cluster info

Sample output:

Defaulted container "f5-dssm" out of: f5-dssm, cert-client
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:9
cluster_size:3
cluster_current_epoch:9
cluster_my_epoch:1
cluster_stats_messages_ping_sent:224
cluster_stats_messages_pong_sent:231
cluster_stats_messages_sent:455
cluster_stats_messages_ping_received:223
cluster_stats_messages_pong_received:230
cluster_stats_messages_meet_received:8
cluster_stats_messages_received:461
total_cluster_links_buffer_limit_exceeded:0
cluster_slot_migration_active_tasks:0
cluster_slot_migration_active_trim_running:0
cluster_slot_migration_active_trim_current_job_keys:0
cluster_slot_migration_active_trim_current_job_trimmed:0
cluster_slot_migration_stats_active_trim_started:0
cluster_slot_migration_stats_active_trim_completed:0
cluster_slot_migration_stats_active_trim_cancelled:0

In this example, the Redis cluster nodes are listed.

oc exec dssm-f5-dssm-db-0 -- redis-cli -p 6379 --tls   --cacert /tls/dssm/mds/svr/ca.crt --cert /tls/dssm/mds/svr/tls.crt   --key /tls/dssm/mds/svr/tls.key cluster nodes

Defaulted container "f5-dssm" out of: f5-dssm, cert-client
a0a8840d75a3798d508475366921c538d0dca737 dssm-f5-dssm-db-7.dssm-f5-dssm-db.default:6379@16379 slave a3173bfe9394a8039ff4256748c909ab4b411b86 0 1787809249512 2 connected
932d617e77f86388ee229dac26061e95d9bc251b dssm-f5-dssm-db-2.dssm-f5-dssm-db.default:6379@16379 master - 0 1787809250115 3 connected 10923-16383
9024c32be41660346974680471037c0450b23725 dssm-f5-dssm-db-6.dssm-f5-dssm-db.default:6379@16379 slave a3173bfe9394a8039ff4256748c909ab4b411b86 0 1787809249512 2 connected
ec87f223bab5e7726cf73524a0b41b09fffc81fa dssm-f5-dssm-db-3.dssm-f5-dssm-db.default:6379@16379 slave 932d617e77f86388ee229dac26061e95d9bc251b 0 1787809250514 3 connected
11a0c7e98192302957a703b9ff034c5e647b133b dssm-f5-dssm-db-4.dssm-f5-dssm-db.default:6379@16379 slave d80bfff70bb9f03aab016113899cfb3a2e0f0ee7 0 1787809250614 1 connected
a3173bfe9394a8039ff4256748c909ab4b411b86 dssm-f5-dssm-db-1.dssm-f5-dssm-db.default:6379@16379 master - 0 1787809249110 2 connected 5461-10922
d1b9e79f056649e29e89d86585e74651f4563d06 dssm-f5-dssm-db-5.dssm-f5-dssm-db.default:6379@16379 slave d80bfff70bb9f03aab016113899cfb3a2e0f0ee7 0 1787809250000 1 connected
d80bfff70bb9f03aab016113899cfb3a2e0f0ee7 dssm-f5-dssm-db-0.dssm-f5-dssm-db.default:6379@16379 myself,master - 0 0 1 connected 0-5460
d45c548d335bfd648948f6dd349f610e631c6abc dssm-f5-dssm-db-8.dssm-f5-dssm-db.default:6379@16379 slave 932d617e77f86388ee229dac26061e95d9bc251b 0 1787809250000 3 connected

To securely connect the TMM and dSSM Pods, the CNFs Controller Helm values file requires the following paramaters:

Important: Set the SESSIONDB_EXTERNAL_SERVICE parameter to the namespace of the dSSM Pod. In this example, cnf-utilities.

f5-tmm:
  tmm:
    customEnvVars:
    - name: SESSIONDB_DISCOVERY_SENTINEL
      value: "false"
    - name: SESSIONDB_EXTERNAL_SERVICE
      value: "dssm-f5-dssm-db.default.svc.cluster.local"
    - name: SESSIONDB_CLUSTER_MODE
      value: "true"

The dSSM DB Pods should be bound to the persistent volumes:

oc get pvc -n cnf-gateway

In this example, the dSSM Pod’s PVC STATUS is Bound:

NAME                STATUS   VOLUME                                     
data-f5-dssm-db-0   Bound    pvc-c7060354-64d2-456b-9328-aa38f19b44b5   
data-f5-dssm-db-1   Bound    pvc-8358b993-bf21-4fd7-a0fa-ee84ec420aac  
data-f5-dssm-db-2   Bound    pvc-de65ed0f-f616-4021-a158-e0e78ed4539e   

Verify cluster health using the Redis CLI:

redis-cli -p 6379 --tls --cacert /tls/dSSM/mds/svr/ca.crt --cert /tls/dSSM/mds/svr/tls.crt --key /tls/dSSM/mds/svr/tls.key cluster info

Enable cluster mode using F5 Lifecycle Orchestrator (FLO)¶

Open the FLO deployment configuration for dSSM.

Set the cluster mode flag to enable clustering.

clustering:
  enabled: true
  # When clustering.enabled is true, the db StatefulSet replica count is
  # computed as shardCount * (clusterReplicaCount + 1) and the top-level
  # `replicaCount` is ignored. Minimums enforced by init_dSSM.go:
  # shardCount >= 3, clusterReplicaCount >= 1.
  shardCount: 3
  clusterReplicaCount: 2

(Optional) Adjust the number of shards and replicas per shard.
Deploy dSSM using FLO.
Verify that all database pods are running and the cluster has formed.

Verify TMM connectivity¶

After the cluster is running, verify that TMM instances can connect to the dSSM cluster:

Check the TMM logs for dSSM connection messages. In cluster mode, the logs include cluster slot IDs to identify which shard each connection belongs to.

conn-cdb/<slot-range> - Redis db connection established

In this example, the TMM logs for dSSM connection messages are shown.

oc logs -f f5-tmm-777568895c-6742p | grep "Redis db connection established"
Defaulted container "f5-tmm" out of: f5-tmm, debug, blobd
Aug 26 05:03:20.769071 tmm[24] conn-cdb/3277:6553 - Redis db connection established
Aug 26 05:03:20.769767 tmm[24] conn-cdb/0:3276 - Redis db connection established
Aug 26 05:03:20.769891 tmm[24] conn-cdb/9830:13106 - Redis db connection established
Aug 26 05:03:20.787546 tmm1[122] conn-cdb/3277:6553 - Redis db connection established
Aug 26 05:03:20.789124 tmm1[122] conn-cdb/0:3276 - Redis db connection established
Aug 26 05:03:20.790443 tmm1[122] conn-cdb/9830:13106 - Redis db connection established
Aug 26 05:03:20.811525 tmm1[122] conn-cdb/6554:9829 - Redis db connection established
Aug 26 05:03:20.832692 tmm1[122] conn-cdb/13107:16383 - Redis db connection established
Aug 26 05:03:20.835297 tmm[24] conn-cdb/13107:16383 - Redis db connection established
Aug 26 05:03:20.835439 tmm[24] conn-cdb/6554:9829 - Redis db connection established

Verify that session operations complete without errors.

Modifying default resources¶

The limits parameter is not set by default to accommodate potential peak traffic in customer deployments. However, the user can modify it as needed, as explained below:

Modifying the default resource request/limit globally through overrides:

This configured setting applies both to DB and Sentinel pods simultaneously.

resources:
  requests:
    cpu: "1"
    memory: "512Mi"
  limits:
    cpu: "2"
    memory: "2Gi"      

Modifying the default resource request/limit for db and sentinel pods through overrides:

This setting applies to DB and Sentinel pods as configured in the overrides.

db:
 resources:
   requests:
     cpu: "1"
     memory: "512Mi"
   limits:
     cpu: "2"
     memory: "2Gi"      

sentinel:
 resources:
   requests:
     cpu: ".5"
     memory: "128Mi"
   limits:
     cpu: "1"
     memory: "512Mi"      

Note: The global resource setting takes precedence over the resource settings at the DB/Sentinel.

Next step

Continue to the CNFs CWC installation guide.

Supplemental