General Page

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:
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.
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.- 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. - Other user-provided settings in the CR
For example, validating theitemsarray that defines required certificates in the secret when SSL is enabled in the CR.
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
spec.image: icr.io/db2u/db2u.<DBTYPE>:VRMF-CSBicr.io/db2u/db2u.db2wh:12.1.3.0New 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_CONTEXTAt 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 environment:
prechecker:
enabled: true
disabledPrechecks:
- WRITE_SPEED
- SELINUX_CONTEXTFeatures 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.
| Category | Available in preview |
|---|---|
| Platform | Standalone on Kubernetes or OpenShift only. |
| Deployment type | OLTP, Warehouse (SMP, MPP). |
| Install method | Installation via Helm. |
| Version support | Db2 version 12.1.3 support only. |
| Update/Upgrade | Fresh deployments only with ability to reinstall and redeploy to pick-up vulnerability fixes. |
| Backup and restore | Backup/Restore via native Db2 commands. |
| Configuration | Db2 configuration changes via Db2 ADMIN_CMD procedure. Db2 config changes are driven through db2 ADMIN_CMD except at deployment time. |
| Scaling | Vertical scaling (cpu/memory). |
| High availability | New and improved HA design. |
| User management | User authentication is provided through external LDAP configured at deployment time. |
| Datalake feature | OpenDataFormat (Datalake). |
| Storage | Includes a Prechecker to validate storage misconfigurations. The prechecker is disabled by default and can be enabled in the Db2uInstance CR. |
| Placement | Dedicated nodes Kubernetes/OpenShift workers. |
| Wire encryption | Choice to enable SSL at deployment time (user must provide certificate). |
| OpenShift SCC | Unrestricted deployments. |
| Image name | Image tag | Image digest |
|---|---|---|
| icr.io/db2u/db2-operator | 0.1 | sha256:4eeb63064fd135cb6f8f3d3ed8ad44adf7d129290560a48dbe7122966362c7fd |
| icr.io/db2u/db2u.db2oltp | 12.1.3.0 | sha256:847373ea58d9402b9ac0c79faccfa21b634abccbefd8b0a9aeafd39a865b8589 |
| icr.io/db2u/db2u.db2wh | 12.1.3.0 | sha256: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.yaml3. Extract the Helm chart tarball:
tar -zxvf db2-operator-0.1.tar.gz
cd 0.14. 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: K8S5. 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:
- db2u8. 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.1Where <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:4eeb63064fd135cb6f8f3d3ed8ad44adf7d129290560a48dbe7122966362c7fd10. 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
- 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:
- Container image: db2u.db2oltp:12.1.3.0.
- Database name: BLUDB.
- 2 CPUs.
- 8 GB of memory.
- 3 storage volumes (meta, data, archivelogs). (For more information on storage, see Configuring database storage for Db2 or Db2 Warehouse on OpenShift.)
- LDAP disabled.
- SSL disabled.
Note: The container image can optionally also include the image digest:
image: icr.io/db2u/db2u.db2oltp:12.1.3.0@sha256:847373ea58d9402b9ac0c79faccfa21b634abccbefd8b0a9aeafd39a865b8589Sample YAML
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: templateWhere <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.yamlMonitor 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 8sOnce 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.
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: templateFor 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:
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.- Inspect the CR to ensure the configuration matches your goals.
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.yamlkubectl -n <db2-instance-ns> apply -f ./db2-instance/renders/db2-instance/templates/db2-oltp.yamlFor more information, refer to the README.md in the ./db2-instance directory.
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-
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-genFor OpenShift
$ oc project <db2-operator-ns>$ helm uninstall db2-operator
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 db2runner3. If your Db2uInstance deployment has the opendataformats add-on enabled, pause the associated bigsql services:
sv pause bigsql-metastore bigsql-scheduler4. 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 db2runner6. 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-scheduler7. Verify that the HA service status is unpaused:
sv status db2runner8. 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
Was this topic helpful?
Document Information
Modified date:
02 December 2025
UID
ibm17248226