IBM Support

Db2U Next Generation

General Page

Preview Db2U Next Generation for Db2 and Db2 Warehouse for RedHat OCP and Kubernetes.
What is Db2U Next Generation?
 
Db2U Next Generation (Next Gen) is a modernized version of the Db2 Universal Operator designed for deploying Db2 and Db2 Warehouse on OpenShift or Kubernetes. It replaces the legacy Operator Lifecycle Manager (OLM) with a Helm-based GitOps-compatible installation model, offering a streamlined experience that better aligns with Kubernetes-native deployment practices. The operator image has a significantly smaller footprint compared to the current version. Key enhancements include a validation webhook for policy enforcement, semantic versioning for independent image updates, a new high availability design, and a storage prechecker to detect misconfigurations. This tech preview supports Db2 version 12.1.3 for non-production deployments only, and can be requested through a Technical Support case.
 
If you are new to the world of containers and Kubernetes and would like to learn more, see the About section of the Red Hat OpenShift documentation site.
 
Db2 Next Gen architecture
Next Gen Flow Chart

 

 
 

The core of the operator is the reconciler, which manages the state of the application in Kubernetes.  The reconciler continuously monitors for changes in the application and takes corrective actions to ensure that the application is in the desired state.

The Next Gen operator enables independent updates to resources, while providing users with clear visibility into each resource's status. This enhances overall performance, improves serviceability, and delivers a better user experience.

How is Next Gen different from the current operator?

The Next Gen operator offers key improvements over the current generation operator offering. This includes improved security posture, Kubernetes resource reduction, and the use of the validation webhook:

Improved security posture

  • Reduced clusterrole privileges.
  • Optionally, bring your own security context constraints (SCC), service account, RBAC (roles, RoleBindings).
  • Fewer images leading to reduced attack surface.
  • Better integration with native certificate managers for Kubernetes.
  • Better integration with identity providers.

Kubernetes resource reduction 

  • Reduced deployment time and resource consumption.
  • Default Db2 configuration settings are embedded into the image.
  • Simplified operator model with fewer intermediary resources required.
  • Removed external dependencies such as etcd.

Validation webhook

The validation webhook is a Kubernetes admission controller that intercepts requests to the API server before they are persisted. It validates incoming requests and rejects those that do not meet predefined criteria. This mechanism helps enforce policies and ensures that only valid resources are created or updated in the cluster.

The Db2u validation webhook is used to enforce certain policies on the Db2uInstance custom resource. This includes the following policies:

  1. The Db2uInstance Custom Resource (CR) must have a valid image 

    The webhook checks the Db2uInstance CR to ensure that the image specified in the spec.image field is valid for the particular operator version. If the image is not valid, for example if it violates the semantic versioning scheme, the webhook will reject the request..

    The webhook also rejects any image that is not from the icr.io registry. This is to ensure that only images from the IBM Container Registry are used in the cluster. The webhook will also check the image name and reject any image that does not match the pattern icr.io/db2u/*. However, for air-gapped deployments, this can be bypassed by setting the imageRegistryOverride config in the Db2uInstance CR.

  2. The Db2uInstance CR must be annotated to allow changes that cause downtime


    The webhook looks for the maintenance annotation in the CR:

    db2u.databases.ibm.com/maintenance: "true"
    

    It only allows changes that cause a downtime if the annotation is present. The flow for this process is as follows:

    · If the annotation is present: the webhook allows changes that cause downtime. For example scale up/down, cpu/memory changes or update/upgrade, and restore.
    · If the annotation is not present, but the changes can be done online, for example labels or annotations: the webhook allows the changes.

  3. Changes to db and dbm config variables will only be allowed via ADMIN_CMD post CR creation
    The webhook checks the Db2uInstance CR to ensure that changes to the db and dbm variables are only allowed on CR creation. Any changes to these variables after CR creation must be done through the ADMIN_CMD procedure. This provides a more consistent experience to native Db2 externals.
  4. Other user-provided settings in the CR
    For example, validating the items array that defines required certificates in the secret when SSL is enabled in the CR. 
 
Simplified installation and deployment
 
The Next Gen operator introduces a more streamlined approach to installation and deployment.
 
Helm based installation

The current gen operator uses Operator Lifecycle Manager (OLM) to install and manage the operator. The Next Gen operator evolves on this by using Helm instead of OLM. Helm offers a more straightforward installation experience and includes the following advantages:
  • Reduces reliance on cluster-admin permissions during installation and upgrade.
  • Eliminates the need for OpenShift global pull secrets and image content source policies (ICSPs).
  • Removes cluster-level RBAC for operators wherever feasible and allows administrators to provide their - own RBAC resources, such as SCC, service accounts, roles, and role bindings.
  • Compatibility with GitOps tools, including Argo CD.

Independent image and operator updates

  • Db2 images can be updated independently of the operator, enhancing security and simplifying upgrades.
  • Operator updates are only required for new features or security fixes that affect the operator.

Semantic versioning 

The Next Gen operator follows the Db2 semantic versioning scheme for the container images. The image format is:
 
spec.image: icr.io/db2u/db2u.<DBTYPE>:VRMF-CSB
Where V is version, R is release, M is Modpack, F is Fixpack, and CSB is Cumulative Special Build. For example:
 
icr.io/db2u/db2u.db2wh:12.1.3.0
The versioning scheme allows for separate upgrade of the operator and Db2u containers, within limits/ranges enforced by the webhook.

New high availability design 
 

Next Gen replaces the current gen Wolverine high-availability (HA) framework with a new framework built on an efficient runit daemon and native Kubernetes probes. Unlike the current gen design which relies on Wolverine and etcd for high availability and recovery, the new approach improves recovery times during both planned and unplanned outages and removes the dependency on etcd, reducing complexity. The updated HA model also introduces independent failure detection and recovery, allowing each pod to autonomously detect and respond to failures, enabling a more decentralized approach.

Storage prechecker

The Next Gen operator includes a storage prechecker which validates the configured storage at deployment time. By default, this feature is not enabled.
To enable this feature, set the prechecker field to true under the env section in the Db2uInstance CR:

environment:
  prechecker:
    enabled: true

 

Note: If you are deploying on Kubernetes, you must disable the SELINUX_CONTEXT check. For example:

environment:
  prechecker:
    enabled: true
    disabledPrechecks:
      - SELINUX_CONTEXT

At deployment time during the pod startup, an init container is launched which performs a set of checks for known storage misconfigurations. If any of the storage checks fail, the prechecker container fails and the init container goes into a restart loop until the misconfiguration is corrected.

For example:

Events:
  Type     Reason             Age               From                Message
  ----     ------             ----              ----                -------
  Warning  BackOff            17s               kubelet             Back-off   restarting failed container prechecker in pod c-db2-example-db2u-0_db2-instance-ns(0145c43f-a114-4df6-81c2-9d98f35339a1)

To investigate the failures, check the precheck container logs on the associated pod, for example:

$ kubectl -n <db2-instance-ns> logs c-db2-example-db2u-0 -c prechecker  
[2025-09-08 12:12:37,414] - INFO: Executing storage precheck... 
[2025-09-08 12:12:37,426] - WARNING: [NFS_VERSION] - NFS is configured with a version which is not fully supported: 4 
[2025-09-08 12:12:37,680] - ERROR: [SELINUX_CONTEXT] - NFS missing in SELinux context 
[2025-09-08 12:13:05,533] - INFO: [WRITE_SPEED] - Storage write speed: 38.9 MB/s (BS=1M count=1024) 
[2025-09-08 12:13:12,911] - INFO: [WRITE_SPEED_LIGHT] - Storage write speed (lite): 574 kB/s (BS=4K count=1024) 
[2025-09-08 12:13:12,919] - INFO: Storage prechecks executed in 35.493459s 
[2025-09-08 12:13:12,927] - ERROR: Prechecker failed: At least one critical precheck did not pass 
To bypass a particular test, set the disabledPrechecks field to include the tests to bypass and redeploy, for example:
 
environment:
  prechecker:
    enabled: true
    disabledPrechecks:
      - WRITE_SPEED
      - SELINUX_CONTEXT
 

Features available in the Next Gen tech preview

A subset of current gen Db2U features are available in the Next Gen tech preview. The following table outlines which features are available in the tech preview.

CategoryAvailable in preview
PlatformStandalone on Kubernetes or OpenShift only.
Deployment typeOLTP, Warehouse (SMP, MPP).
Install methodInstallation via Helm.
Version supportDb2 version 12.1.3 support only.
Update/UpgradeFresh deployments only with ability to reinstall and redeploy to pick-up vulnerability fixes.
Backup and restoreBackup/Restore via native Db2 commands.
ConfigurationDb2 configuration changes via Db2 ADMIN_CMD procedure. Db2 config changes are driven through db2 ADMIN_CMD except at deployment time.
ScalingVertical scaling (cpu/memory).
High availabilityNew and improved HA design.
User management User authentication is provided through external LDAP configured at deployment time.
Datalake featureOpenDataFormat (Datalake).
StorageIncludes a Prechecker to validate storage misconfigurations. The prechecker is disabled by default and can be enabled in the Db2uInstance CR.
PlacementDedicated nodes Kubernetes/OpenShift workers.
Wire encryption Choice to enable SSL at deployment time (user must provide certificate).
OpenShift SCCUnrestricted deployments.
 
How to obtain the Next Gen operator 
 
Open a technical Support Case and request the Db2U Next Gen Helm chart tarball. Include details of the target Openshift or Kubernetes version, whether your interest is in OLTP or Warehouse, and whether you are already using the current generation of Db2U.
 
List of images
 
Image nameImage tagImage digest
icr.io/db2u/db2-operator0.1sha256:4eeb63064fd135cb6f8f3d3ed8ad44adf7d129290560a48dbe7122966362c7fd
icr.io/db2u/db2u.db2oltp12.1.3.0sha256:847373ea58d9402b9ac0c79faccfa21b634abccbefd8b0a9aeafd39a865b8589
icr.io/db2u/db2u.db2wh12.1.3.0sha256:c4de196d543448986f5855f86e49729ce4dcf44c6d634cabfd4bc4c75f4a1cf2
 
How to install Next Gen

Note: The Db2 Next Gen tech preview is for non-production deployments only. It cannot be deployed on an existing OpenShift or Kubernetes cluster where a current gen operator is installed. Instead, Db2 Next Gen must be installed on a dedicated fresh OpenShift or Kubernetes Cluster. 

The Db2 next gen operator is installed using Helm. To install Next Gen:

1.  Download and install the helm utility.
 

2. Following the steps found in Installation to deploy a cert-manager. For example:

$ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml

3. Extract the Helm chart tarball:

tar -zxvf db2-operator-0.1.tar.gz
cd 0.1

4. Helm values can be overridden by using a YAML file or by using the --set parameter. To keep track of persistent overrides, create a file to store the changes called overrides.yaml and apply overrides with the -f flag when installing the helm chart.

    a. For Kubernetes users, add the following additional setting to your overrides YAML:

platform: K8S

5. Create a target namespace for the operator and target Db2uInstance:

$ kubectl create ns <db2-operator-ns> 
$ kubectl create ns <db2-instance-ns> 

6. Add watchNamespace to your overrides.yaml so that the operator can monitor Db2uInstance resources deployed in other namespaces. For example:

namespace: <db2-operator-ns>
image:
  repository: icr.io/db2u/db2-operator
watchNamespace:
  - <db2-instance-ns>

7. If you are installing in an air-gapped environment, create the Kubernetes image pull secret in the operator and target namespace you created:

$ kubectl -n=<db2-operator-ns/db2-instance-ns> create secret docker-registry db2u --docker-server=localregistry.io --docker-username=cp --docker-password='<secret-key>'

  a. Add the image pullsecret to your overrides.yaml. For example:

imagePullSecrets:
  - db2u

8. Target the operator namespace:

On OpenShift:

$ oc project <db2-operator-ns> 

 

On Kubernetes:

$ kubectl config set-context --current --namespace=<db2-operator-ns>

9. Install the Helm chart

helm install db2-operator ./db2-operator -f overrides.yaml --set image.tag=0.1

     Where <tag> is the version and architecture of the operator, for example: 0.1.

    NOTE: the image.tag can optionally include the digest, for example:

image.tag=0.1@sha256:4eeb63064fd135cb6f8f3d3ed8ad44adf7d129290560a48dbe7122966362c7fd

 10. After a few seconds, confirm that the pod has successfully started and is in a Running state by running the following command:

$ kubectl get po 

 

Providing your own custom SCC and RBAC resources
 

When you install the Db2 or Db2 Warehouse service, custom SCCs are automatically created for the service. You can also manually pre-create an SCC, service account, role and role binding for the Db2 or Db2 Warehouse service. For more information, refer to How to provide your own custom SCC and RBAC resources.

Enabling SSL connections to Db2

To enable SSL (wire encryption) for Db2 or the Datalake (opendataformat) add-on, you must configure your Db2uInstance Custom Resource (CR) to reference a custom SSL secret that contains the required certificates. This configuration must be included at the time of instance creation.

For more information, refer to Enabling SSL connections to Db2

Enabling LDAP authentication 

To enable external user authentication via LDAP or Active Directory (AD), you must configure the Db2uInstance Custom Resource (CR) and provide an associated ConfigMap during deployment.

For more information, see Setting up LDAP on Db2U Next Generation.

Deploying a containerized Db2 instance using the Next Gen operator (OLTP)
 

Before you begin

You can deploy a Db2 instance by running a Db2uInstance Custom Resource (CR) using a YAML script. This can be done through:

  • Red Hat OpenShift CLI: oc
  • Kubernetes CLI: kubectl
Ensure the following tasks are complete:
  • Have a dedicated Kubernetes or OpenShift cluster not currently shared with the current gen operator
  • Install the Helm CLI
  • Deploy cert-manager
 

Example configuration

The following example shows the CR YAML to deploy a Db2uInstance for Db2 OLTP. The CR creates a Db2 instance with the following configuration:

Note: The container image can optionally also include the image digest:

image: icr.io/db2u/db2u.db2oltp:12.1.3.0@sha256:847373ea58d9402b9ac0c79faccfa21b634abccbefd8b0a9aeafd39a865b8589

Sample YAML
 
The following YAML provides a configuration template for a Db2 OLTP instance.
apiVersion: db2u.databases.ibm.com/v1
kind: Db2uInstance
metadata:
  name: db2-oltp-next-gen
spec:
  image: icr.io/db2u/db2u.db2oltp:12.1.3.0
  environment:
    databases:
    - name: BLUDB
    dbType: db2oltp
  license:
    accept: true
  nodes: 1
  podTemplate:
    db2u:
      resource:
       db2u:
         limits:
           cpu: 2
           memory: 8Gi
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: <storage-class-fs>
    type: create
  - name: archivelogs
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: <storage-class-fs>
    type: create
  - name: data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: <storage-class-block>
    type: template

Where <storage-class-fs> is a placeholder for filesystem storage and <storage-class-block> is a placeholder for block storage, for example ocs-storagecluster-cephfs and ocs-storagecluster-ceph-rbd.
 

Deploying the instance

Run the following command to apply the YAML and create the instance. In this example, the instance is created in the namespace <db2-instance-ns>:

$ kubectl -n <db2-instance-ns> apply -f db2uinstance_oltp.yaml
 

Monitor the deployment status

While the instance deploys, the Db2uInstance resource shows a converge state:

$ kubectl -n <db2-instance-ns> get db2uinstance
NAME STATE MAINTENANCESTATE AGE
db2-oltp-next-gen converge 8s

Once the deployment is ready, the state changes to Ready:

$ kubectl -n <db2-instance-ns> get db2uinstance
NAME STATE MAINTENANCESTATE AGE
db2-oltp-next-gen Ready 4m58s


Deploying a containerized Db2 Warehouse instance using the Next Gen operator (MPP)

Example configuration
 

This example shows how to deploy a Db2 Warehouse (MPP) instance using a Db2uInstance Custom Resource (CR). The CR creates a Db2 instance with the following configuration:

  • Multi-node configuration (3 nodes, 6 partitions).
  • SSL enabled.
  • Datalake (OpenDataFormat) add-on enabled.
Note: You must enable SSL before using the Datalake add-on.  For more information, see Enabling SSL connections to Db2
apiVersion: db2u.databases.ibm.com/v1
kind: Db2uInstance
metadata:
  name: db2-wh-next-gen
spec:
  image: icr.io/db2u/db2u.db2wh:12.1.3.0
  addOns:
    opendataformats:
      enabled: true
  environment:
    ssl:
      fromVolumeSource:
        secret:
          secretName: db2ssl-certs
          items:
            - key: tls.crt
              path: tls.crt
            - key: tls.key
              path: tls.key
            - key: ca.crt
              path: ca.crt
    partitionConfig:
      total: 6
    authentication:
      ldap:
        enabled: false
    databases:
    - name: BLUDB
    dbType: db2wh
  license:
    accept: true
  nodes: 3
  podTemplate:
    db2u:
      resource:
        db2u:
          limits:
            cpu: 2
            memory: 12Gi
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: <storage-class-fs>
    type: create
  - name: archivelogs
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: <storage-class-fs>
    type: create
  - name: data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 200Gi
      storageClassName: <storage-class-block>
    type: template
 
Steps to deploy and monitor deployment are the same as for OLTP deployments. 
 

For more information on the sections of the Db2uInstance CR, refer to Db2uInstance Custom Resource Configuration (Next Gen Operator).

Helm templates

Templates for convenient, preconfigured deployments are included in the Helm charts.

To use these templates to generate a Db2uInstance CR: 

  1. Run the following command:

    helm template ./db2-instance --set name=mynewdb2instance --set storageclassname.rwx=managed-nfs-storage --set storageclassname.rwo=managed-nfs-storage --set image.repository="icr.io/db2u" --set image.tag="12.1.3.0" --output-dir ./db2-instance/renders


    Note: Set the values for storageclassname to match the storage on your cluster.

  2. Inspect the CR to ensure the configuration matches your goals.
  3. Apply one or both of the following commands as required:

    kubectl -n <db2-instance-ns> apply -f ./db2-instance/renders/db2-instance/templates/db2-wh.yaml
    kubectl -n <db2-instance-ns> apply -f ./db2-instance/renders/db2-instance/templates/db2-oltp.yaml
    For more information, refer to the README.md in the ./db2-instance directory.
Connecting to Db2

There are various ways to make a connection to Db2 in order to interact with the engine and drive workloads. For more information, see Connecting to Db2 or Db2 Warehouse.

How to begin driving workloads
 

Once you make a connection to Db2, you can create tables, load data, access existing data on object storage, and so on. 

If you have enabled the OpenDataFormat feature to interact with Datalake tables, refer to Using Datalake tables for more information.

Scaling the instance 

You can run a script to add more memory and CPU to the Db2 service on Red Hat OpenShift to increase processing capacity.

Since this is a disruptive operation to any workload in-progress, you must first set the maintenance annotation in the CR to true:

​​​​​​db2u.databases.ibm.com/maintenance: "true"


The following is an example of the commands required to scale the CPU cores to 4 and the memory to 16GiB:

namespace=<namespace of Db2uInstance>
db2uinstance=<db2uinstance name>
   kubectl -n ${namespace} annotate db2uinstance ${db2uinstance} db2u.databases.ibm.com/maintenance="true"
   kubectl patch db2uinstance ${db2uinstance} -n ${namespace} --type merge --patch '{"spec": { 
   "podTemplate": {
       "db2u": {
           "resource": {
               "db2u": {
                   "limits": {
                       "cpu": "4",
                       "memory": "16Gi"
                   }
               }
           }
       }
 
   }
   }}'

Once the scaling operation is complete and the Db2uInstance has returned to a Ready state, the maintenance annotation can be removed:

kubectl -n ${namespace} annotate db2uinstance ${db2uinstance} db2u.databases.ibm.com/maintenance-
 
Deleting an instance


To delete an instance, run the following commands:
 

namespace=<namespace of Db2uInstance>
                                                                                                                                                                                                                                                                                                            db2uinstance=<db2uinstance name>
kubectl -n ${namespace} delete db2uinstance ${db2uinstance}


Wait for the pod(s) to terminate and associated resources to be removed.

Uninstalling the operator

To uninstall the operator, run one of the following commands:

For Kubernetes

helm uninstall db2-operator --namespace db2u-next-gen

For OpenShift

$ oc project <db2-operator-ns>
$ helm uninstall db2-operator
 
 
FAQ and troubleshooting

 

How to provide your own custom SCC and RBAC resources

When you install the Db2 or Db2 Warehouse service, custom SCCs are automatically created for the service.
You can also manually pre-create an SCC, service account, role and role binding for the Db2 or Db2 Warehouse service by following the steps in Manually creating an SCC, service account, role, and role binding. See also, Db2 or Db2 Warehouse SCC capabilities, for more information.

Then, when installing the Helm chart, you can add some or all of the following overrides to not automate the creation of the SCC, the cluster/operator level RBAC resources, and instance-level (instanceRbac) resources:

scc:
  create: false
rbac:
  create: false
instanceRbac:
  create: false


How to exec into a Pod 

For more information on how to exec into the pod, see Exec into the Db2 pod.

Pausing Db2 or Db2 Warehouse High Availability (HA) in order to perform maintenance tasks

Db2 or Db2 Warehouse comes with a built-in High Availability (HA) solution that monitors and triggers recovery actions if there is a problem with Db2 or Db2 Warehouse database services. The built-in HA monitoring must be temporarily paused before performing certain maintenance or administration operations such as stopping the service.

To pause HA:

1. Exec into the pod.

2. Pause the HA runit service for db2:

sv pause db2runner

3. If your Db2uInstance deployment has the opendataformats add-on enabled, pause the associated bigsql services:

sv pause bigsql-metastore bigsql-scheduler

4. Perform the required maintenance activity, for example stopping and starting db2 or restoring a database.

5. When the maintenance activity is over, resume the HA: 

sv cont db2runner

6. If you paused the associated bigsql services for the opendataformats add-on, run the following to resume the associated bigsql services:

sv cont bigsql-metastore bigsql-scheduler

7. Verify that the HA service status is unpaused:

sv status db2runner

8. If the OpenDataFormats add-on is enabled, run the following:

sv status bigsql-metastore bigsql-scheduler
 


 Related links


Db2uInstance Custom Resource Configuration (Next Gen Operator)

Setting up LDAP on Db2U Next Generation

 

[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m3p000000LPvoAAG","label":"Openshift"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"12.1.3"}]

Document Information

Modified date:
02 December 2025

UID

ibm17248226