Installing Db2 Operator V2

You can install the Db2 Operator V2 by using Helm through the command line.

Before you begin

Note: This topic is for Db2 Operator V2 deployments. If you are currently using a legacy deployment, refer to the documentation in Legacy deployment documentation. If you are unsure which deployment type you are using, use the version checker.
Note:

Db2 Operator V2 can optionally be deployed by using a GitOps approach with Argo CD and Helm. This method uses Git as the single source of truth for Kubernetes deployments, enabling automated, declarative, and version-controlled operations. Argo CD continuously syncs Git changes to the cluster and corrects any drift from the defined state. This ensures real-time visibility, consistent deployments, and simpler rollbacks and auditing.

For a comprehensive guide on deploying Db2 Operator V2 using GitOps principles with Argo CD and Helm, see Next-Gen IBM Db2 on Kubernetes: A GitOps Journey with Argo CD and Helm.

Before you install the Db2 Operator V2, ensure you have the following:
  • A Red Hat OpenShift or Kubernetes cluster.
  • Cluster access configured for kubectl or co.
  • Helm CLI version 3.0 or later.
  • Cert-manager version 1.13.0 or later installed in your cluster.
  • Cluster-admin permissions
    Note: Cluster-admin permissions are required to install cluster-scoped resources. After cluster-scoped resources are installed, cluster-admin permissions are not required for subsequent operator installations.
  • An IBM Entitlement Key to pull operator images from the IBM Container Registry.
    • To obtain the IBM Entitlement Key:
      1. Login to the IBM Container Library using your IBM Id.
      2. Find an existing entitlement key or click Add New Key.
      3. Copy the key for use in this procedure.
  • The Db2 Operator V2 Helm charts extracted or available locally. You can acquire the Helm charts by following one of the following methods:
To download the Helm charts from IBM Helm Chart repository:
  1. Run the following command:
    helm repo add ibm-helm https://raw.githubusercontent.com/IBM/charts/master/repo/ibm-helm
    helm pull ibm-helm/db2-operator-cluster-scoped 
    helm pull ibm-helm/db2-operator-standalone
    The resulting chart tarballs are:
    db2-operator-cluster-scoped-2.0.0.tgz
    db2-operator-standalone-2.0.0.tgz
  2. On the bastion host or system with cluster access, extract the Helm chart archive:
    tar -xzf db2-operator-cluster-scoped-2.0.0.tgz
    tar -xzf db2-operator-standalone-2.0.0.tgz
    This creates db2-operator-cluster-scoped and db2-operator-standalone directories containing the chart files.
  3. Verify the chart structure:
    ls -la db2-operator-cluster-scoped/
    ls -la db2-operator-standalone/
    You should see the chart directory structure including Chart.yaml, values.yaml, and the templates/ directory.
Alternatively, the charts can be installed directly from the IBM Helm Chart repository by prepending ibm-helm/ to the chart name, for example:
helm repo add ibm-helm https://raw.githubusercontent.com/IBM/charts/master/repo/ibm-helm

helm template db2-operator-cluster-scoped ibm-helm/db2-operator-cluster-scoped  \
  --set global.operatorNamespace="${OPERATOR_NAMESPACE}" \
  | ${KCTL} apply -f -

helm upgrade --install db2-operator ibm-helm/db2-operator-standalone \
  --namespace "${OPERATOR_NAMESPACE}" \
  -f overrides.yaml \
  --set db2u.operator.image.tag="${OPERATOR_TAG}"

About this task

Helm is an open-source package manager for Kubernetes. You use the Helm command-line interface (CLI) to install the Db2 Operator V2 Helm charts. For more information on Helm, see Introduction to Helm.

The Db2 Operator V2 installation uses two Helm charts:
  • db2-operator-cluster-scoped: Installs cluster-scoped resources including Custom Resource Definitions (CRDs), Security Context Constraints (SCCs) for Red Hat OpenShift, and webhook configurations.
  • db2-operator-standalone: Installs the operator deployment, namespace-scoped RBAC, and supporting services.

Procedure

To install the Db2 Operator V2

  1. Verify that cert-manager is installed and running in the cluster:
    ${KCTL} get pods -n cert-manager
    1. If no cert-manager pods are found, install cert-manager. For more information, see Installation. For example:
      ${KCTL} apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml
  2. Set the following environment variables:
    For Red Hat Openshift
    export KCTL=oc 
    export OPERATOR_NAMESPACE=db2-operator 
    export OPERATOR_TAG=v2.0.0 
    export ENTITLEMENT_KEY=<your-entitlement-key>
    For Kubernetes
    export KCTL=kubectl 
    export OPERATOR_NAMESPACE=db2-operator 
    export OPERATOR_TAG=v2.0.0 
    export ENTITLEMENT_KEY=<your-entitlement-key>
    Where <your-entitlement-key> is your IBM Entitlement Key.
  3. Create the namespace where you want to install the operator:
    ${KCTL} create namespace "${OPERATOR_NAMESPACE}" 
    
  4. Create an image pull secret in the operator namespace to authenticate with the IBM Container Registry:
    ${KCTL} -n "${OPERATOR_NAMESPACE}" create secret docker-registry ibm-entitlement-key \ 
      --docker-server=icr.io \ 
      --docker-username=cp \ 
      --docker-password="${ENTITLEMENT_KEY}" 
    
  5. Create a values file named overrides.yaml with your installation configuration:
    global: 
      metaNamespace: $OPERATOR_NAMESPACE 
      licenseAccept: true 
    If you are using a Kubernetes cluster, add the following platform setting:
    db2u: platform: K8S
    Note: The global.metaNamespace field specifies the namespace where the operator is installed. If global.watchNamespace is not set, the operator watches only its own namespace. In this default configuration, create Db2uInstance resources in the operator namespace.
    1. If you have a deployment with a large number of nodes and partitions, such as those in IBM CloudRack, increase the resources allocated to the operator by adding the following resources section to the overrides.yaml:
      global: 
        metaNamespace: $OPERATOR_NAMESPACE 
        imagePullPrefix: icr.io/db2u 
        licenseAccept: true 
       
      db2u:
        resources:
          limits:
            cpu: 1
            memory: 1000Mi
          requests:
            cpu: 500m
            memory: 500Mi
  6. Install the cluster-scoped resources by using the helm template and applying the rendered manifests:
    helm template db2-operator-cluster-scoped ./charts/db2-operator-cluster-scoped \
      --set global.operatorNamespace="${OPERATOR_NAMESPACE}" \
      | ${KCTL} apply -f -
    Important: Do not install the db2-operator-cluster-scoped chart as a Helm release. Use helm template and kubectl apply to install these resources independently of the operator release.
  7. Install the operator by using the standalone chart:
    helm upgrade --install db2-operator ./db2-operator-standalone \
      --namespace "${OPERATOR_NAMESPACE}" \
      -f overrides.yaml \
      --set db2u.operator.image.tag="${OPERATOR_TAG}"
    
  8. Verify the installation:
    1. Run the following command to verify that the operator deployment is available:
      ${KCTL} wait deployment/db2-database-operator-controller-manager \
        -n "${OPERATOR_NAMESPACE}" \
        --for=condition=Available \
        --timeout=300s
      The command returns when the deployment becomes available
    2. Run the following command to check the operator pods:
      ${KCTL} get pods -n "${OPERATOR_NAMESPACE}"
      The operator pod should be in a Running state with all containers ready.
    3. Run the following commands to check the operator logs:
      ${KCTL} logs -n "${OPERATOR_NAMESPACE}" \
        deployment/db2-database-operator-controller-manager \
        -c manager
      The logs should show normal startup and reconciliation activity.
  9. Optionally, you can configure the operator to watch multiple namespaces:
    1. Override the global.watchNamespace field in your values file:
      global: 
        watchNamespace: 
          - db2-team-a 
          - db2-team-b 
          - db2-team-c 
      
    2. Upgrade the operator release:
      helm upgrade db2-operator ./charts/db2-operator-standalone \ 
        --namespace "${OPERATOR_NAMESPACE}" \ 
        -f overrides.yaml \ 
        --set db2u.operator.image.tag="${OPERATOR_TAG}"
      Note: The operator automatically includes its own namespace in the watch list. You do not need to add the operator namespace to global.watchNamespace.

Results

Db2 Operator V2 is installed in the specified operator namespace.
Important: In Db2 12.1.5 and later, the Deployment and Usage Data collection and transmission functionality is enabled by default. This functionality collects data about program or feature usage and the deployment environment, and uses this data to manage, support, improve, and offer IBM products and service
You can opt out of using the tool in one of two ways:
Opt out by using your overrides.yaml file
Add the following configuration to your values override file:
db2-ums-collector:
  enabled: false
Run the following command:
helm install db2-operator db2-operator-standalone/ -f overrides.yaml
Opt out by using the the --set flag
Run the following command:
helm install db2-operator db2-operator-standalone/ --set db2-ums-collector.enabled=false
If you want to disable the Db2 UMS metrics collector after installation, you can opt out during uplift. For more information, see Uplifting legacy operator Db2 instances to Db2 Operator V2.

What to do next

If verifying the installation is unsuccessful, refer to the following troubleshooting methods:
Check the Helm release status
Run the following command to check the Helm release status:
helm status db2-operator -n "${OPERATOR_NAMESPACE}"
Check for failed jobs
Check whether any Helm hook jobs or installation jobs failed:
Check whether any Helm hook jobs or installation jobs failed: 

${KCTL} get jobs -n "${OPERATOR_NAMESPACE}"
Review the logs for any failed job:
${KCTL} logs job/<job-name> -n "${OPERATOR_NAMESPACE}"
Verify cert-manager
Run the following command to verify that cert-manager is installed and running:
${KCTL} get pods -n cert-manager
Check webhook configuration
If the operator is not reconciling resources, verify that the webhook configuration is correct by running the following command:
${KCTL} get validatingwebhookconfigurations 
${KCTL} get mutatingwebhookconfigurations